[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
-------------------------------------------------------------------