All,
I am sorry that the group is not willing to accept this request for extensibility of a specific attribute. I believe that as you evolve to work the attribute certificate attribute type issues, you will be faced with being able to support a significant number of differing attribute types that the " ... 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" will not support.
Maybe when folks are ready to extend the schema to support, for example, the attributes in the ECMA 209 (?) privilege attribute certificate syntax, the idea of allowing more than one way of representing a nationality (nationalities) will seem a bit trivial.
As an additional note, the ISO 3166-1 contains 3 indexes - 11 is the alpha-2 code elements, 12 is the alpha-3 code elements and 12 is the numeric-3 code elements; all indexes are in both English and French, which is consistent with ISO and ITU standards practice. If there are IETF documents in other languages, please point me towards the repository, as I certainly cannot afford to be English (or worse, US) centric in engineering such large scales systems.
Regards,
Sandi Miklos
-----Original Message-----
From: Stefan Santesson [mailto:stefan@accurata.se]
Sent: Wednesday, November 03, 1999 7:12 AM
To: Bob Jueneman; samiklo@missi.ncsc.mil; barzin@secude.com
Cc: ietf-pkix@imc.org; housley@spyrus.com
Subject: RE: QC certificates and Nationality
I agree with Bob.
We should stay compatible with coding in the X.520 country attribute.
/Stefan
At 06:42 PM 11/2/99 -0700, Bob Jueneman wrote:
>Sandy,
>
>The digraph encoding of country codes is also an ISO standard, just a
>different one. ISO currency codes, for example, are digraphs or
>alternatively a numeric code -- yet another alternative. 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
>
>Although I'm reasonably sympathetic to MISSI's desires and role here,
>this is really a presentation layer API function, and not an
>architectural/protocol issue, at least to my mind.
>
>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?
>
>US == USA == 840. Anyone who can handle ASN.1 ought to be
>able to handle the necessary conversions for a desired presentation
>style, IMHO.
>
>With respect,
>
>Bob
>
>>>> "Miklos, Sue A." <samiklo@missi.ncsc.mil> 11/02/99 12:48PM >>>
>Petra,
>
>The answer to the tri- versus di-graph is a bit detailed. Trigraphs are
>believed to be more intuitive for an operator to determine which nation is
>referenced, as opposed to digraphs. Thus, several security policies now
>mandate the use of the trigraph when populating the "Release To" field in a
>security label, or when populating the nationality (or multiples thereof) of
>an authorization (or 'clearance') attribute. Implementation plans
>(including training classes, etc.) are well underway. Therefore, going back
>and re-writing policy to reflect a digraph is not an acceptable alternative.
>
>>From an information management perspective, the idea of maintaining (yet
>another) piece of code that translates digraphs to trigraphs every time the
>"Release To" field is used, or the authorization authority populates the
>nationality field in an attribute, adds to the configuration management
>difficulties associated with implementing a security policy. This piece of
>code could reside in up to millions of nodes (clients, servers, gateway
>devices, etc.)
>
>Writing the translation code, distributing it (securely) and ensuring that
>all components were on the same version is going to be difficult enough for
>the access control decision function algorithm. We would like to avoid
>(wherever possible) extending the information management space to semantic
>content.
>
>We would like to use existing information management processes to the
>greatest extent possible. A majority opinion holds that ISO does the
>information maintenance quite well and at a reasonable cost when compared to
>the security domain managers maintaining the conversion tables approach.
>ISO rapidly conveys changes when a nation is 'born' or 'renamed'. Thus, an
>operations manual can be upgraded much more quickly and at a lower cost than
>any installed module that performs conversions. The cost of ISO membership
>and subsequent re-distribution of changes is minimal in the overall scheme.
>
>An additional aspect is associated with performance impacts. When one adds
>up all the processing associated with integrity and access control, it gets
>becomes noticeable. Any area where 'translation' or additional lookup can
>be optimized is useful.
>
>If you see any other way out of this 'challenge' or flaws in the thinking,
>please respond!
>
>Regards,
>Sandi
>
>-----Original Message-----
>From: Petra Barzin (Gloeckner) [mailto:barzin@secude.com]
>Sent: Tuesday, November 02, 1999 12:55 PM
>To: Miklos, Sue A.
>Cc: Russ Housley; ietf-pkix@imc.org; 'SEIS-List'; Stefan Santesson
>Subject: Re: QC certificates and Nationality
>
>
>Hi Sandi,
>
>the definition of our countryOfCitizenship attribute fulfils your first
>requirement. But why would you want to use trigraphs? The two letter
>codes cover all countries, don't they?
>If your application needs the three letter codes, you can easily map
>the two letter codes to the respective three letter codes.
>
>Regards - Petra
>
>> "Miklos, Sue A." wrote:
>>
>> All,
>>
>> I would like to request the attribute that represents a subject's
>> nationality be structured so that dual citizenship is allowed (default
>> Multivalued, which I believe is supported by countryOfCitizenship and,
>> that this attribute be populated with the ISO-3166-1 (trigraph) if
>> that is consistent with the domain using this piece of information.
>>
>> I have requirements for both. That is, I have a requirement for an
>> attribute that can indicate a subject is a citizen of both Country A
>> and Country B (country of domicile is not relevant at this point) and,
>> that the citizenship be indicated with a trigraph (USA, CAN, NZL,
>> etc.)
>>
>> Regards,
>> Sandi Miklos
>>
>> -----Original Message-----
>> From: Petra Barzin (Gloeckner) [mailto:barzin@secude.com]
>> Sent: Tuesday, November 02, 1999 4:32 AM
>> To: Russ Housley
>> Cc: ietf-pkix@imc.org; 'SEIS-List'; Stefan Santesson
>> Subject: Re: QC certificates and Nationality
>>
>> Russ Housley wrote:
>> >
>> > What goes into the QC when a person is a citizen of more than one
>> country?
>> >
>> > Russ
>>
>> Hello Russ,
>>
>> very good point! The wording in chapter 3.2.1 doesn't fit to the
>> definition of the attribute.
>>
>> Right now, you have to add the attribute multiple times. I suggest
>> that
>> we replace the definition by the following:
>>
>> countryOfCitizenship ATTRIBUTE ::= {
>> WITH SYNTAX SEQUENCE OF PrintableString(SIZE (2))
>> -- IS 3166 codes only
>>
>> ID id-at-countryOfCitizenship }
>>
>> countryOfResidence ATTRIBUTE ::= {
>> WITH SYNTAX SEQUENCE OF PrintableString(SIZE (2))
>> -- IS 3166 codes only
>>
>> ID id-at-countryOfResidence }
>>
>>
>> Best regards - Petra
-------------------------------------------------------------------
Stefan Santesson <stefan@accurata.se>
Accurata AB http://www.accurata.se
Slagthuset Tel. +46-40 108588
211 20 Malmö Fax. +46-40 150790
Sweden Mobile +46-70 5247799
PGP fingerprint: 89BC 6C79 5B3D 591B 8547 1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------