RE: QC certificates and Nationality

["Bob Jueneman" <BJUENEMAN@xxxxxxxxxx>]

Dave, I confess to not having researched this as carefully as I 
probably should have, in particular not looking up the text of 
ISO 3166, and/or comparing it to the reference used for 
country codes in X.509. I apologize.

If the context is restricted to id-pda-countryOfCitizenship,
and not country codes more broadly, then I am mildly less 
concerned., but perhaps that merely reflects the fact that 
implementing the QC spec is still a ways off on my horizon. :-)

But I don't see a particularly strong architectural justification for using
a different encoding than the country code that is already fairly widely
used in X.509 certificates

However, architecturally I get upset at the thought of 
having to implement two different ways of identifying the same 
functionality.  get particularly upset at the thought of allowing 
either digraph or trigraph, and possibly even numeric codes in 
trigraph form, to be input via a varying string size constraint.

Defining the country code to be a printableString would mean 
that "US", "USA", and "840" would presumably all be valid, 
since they are "constrained by ISO 3166".

And how are such constraints to be enforced, without referencing
a table of allowable codes that is effectively the same kind 
of problem as that presented by a translation table? Is the user
responsible for enforcing this constraint?

If it is absolutely necessary to embed this kind of variability
in the architecture, rather than the API or GUI, then could 
you at least make the code a CHOICE of two or even three, 
specific, different types, so that the rules can be enforced 
during data entry, and type-enforced for 
consistency later on?

With respect to my allegation of English-centricity, I probably 
reacted too quickly.  I assumed, apparently incorrectly, 
that for ease of comprehension in the primarily US military 
environment, that for example "GER" would be the trigraph
for Germany, instead of whatever it is in fact -- "DER"?

If I had a choice, I would prefer a single attribute type, namely 
INTEGER, since such things are obviously the easiest to look 
up in a simple table without having to use either serial 
comparisons or some sort of searching algorithm such as 
a hash.

But I don't like having to be forced to implement three different 
ways to  input and output the same information, or worse yet 
to count the number of characters in order to determine which 
table of allowable codes to use when validating the input.

Guess I'm still unconvinced.

Regards,

Bob

>>> "David P. Kemp" <dpkemp@missi.ncsc.mil> 11/04/99 08:28AM >>>
Bob,

I'm having some difficulty understanding the logic here . . . comments
inline.


> 
> Sandy,
> 
> The digraph encoding of country codes is also an ISO standard, just a 
> different one.

ISO 3166 is a single standard with three country indices - digraphs,
trigraphs, and numeric.


> There is a long
> history of the existing encoding in X.500, X.400, and elsewhere,
> and insufficient justification to warrant a change to a lot of already 
existing
> CA, RP, and directory software.

We were discussing the id-pda-countryOfCitizenship and
id-pda-countryOfResidence attributes defined in the QC draft, which
currently have syntax:

   PrintableString (SIZE(2)) (CONSTRAINED BY { -- ISO 3166 codes only -- })

Sandi has proposed modifying the syntax to:

   PrintableString (SIZE(2..3)) (CONSTRAINED BY { -- ISO 3166 codes only -- })

I don't know of any existing X.500, X.400, or other software which
understands the id-pda-countryOfxxx attributes.  What software
would need to be modified if these two QC attributes were defined to
accommodate both two- and three-character country codes?



> There is another, more subtle issue here as well, and that is the question 
> of being overly English-centric.
> 
> What trigraph is proposed for Germany, for example, or Switzerland,
> or a number of other countries whose English names are not at all
> similar to their native language forms?  For that matter, what is the 
> code for that conglomeration headed by Queen Elisabeth -- is it UK, 
> or GBR?

This argument is way too subtle for me.  The ISO 3166 committee registers
codes as countries are created, partitioned, renamed, etc.  I have no
idea whether the committee is dominated by English-centric members, but
assuming that it is, I see no reason to expect them to apply their
English-centrism to the three-character index while refraining from
applying it to the two-character index.  The digraph for our country
is, after all, "US", not "EU" (as in the French Etats Unis).  If you
want to stamp out English-centrism, you should insist that *only*
numeric codes be allowed in the attributes so that all software would
have to translate for presentation:

  WITH SYNTAX INTEGER (CONSTRAINED BY { -- ISO 3166 codes only -- })

Moreover, if the ISO 3166 committee is indeed grievously
English-centric, it would seem that complaints should be addressed to
the committee, not to the maintainers of scores of standards which
reference 3166.



> US == USA == 840.  Anyone who can handle ASN.1 ought to be 
> able to handle the necessary conversions for a desired presentation 
> style, IMHO.

Sandi has addressed the significant implementation issues involved in
requiring all software which might require countryOfCitizenship to
understand SPIFs or use some other embedded index translation
mechanism.  Whether you are convinced that not requiring embedded
translation tables is simpler than requiring them is beside the point.
(If you believe translation is always practical, you should have no
problem with eating your own dog food and allowing only INTEGER country
codes in these QC attributes, as suggested above).

The point is that significant PKIX constituencies, including NATO, have
policies requiring the use of three-character country codes in HMIs;
at least some implementors believe that it is easier to display what is
contained in a country field directly rather than distributing new
translation tables to applications every time 3166 is updated; and
PKIX, as a generally-applicable standard, should be flexible enough to
accommodate the non-translation approach to three-character country
identifiers for those who choose to use it.


Dave