RE: QC certificates and Nationality

["David P. Kemp" <dpkemp@xxxxxxxxxxxxxx>]

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