Subject: RE: QC certificates and Nationality

From: "Bob Jueneman" <[email-masked]>
Date: Tue, 02 Nov 1999 18:42:10 -0700

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." <[email-masked]> 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:[email-masked]] 
Sent: Tuesday, November 02, 1999 12:55 PM
To: Miklos, Sue A.
Cc: Russ Housley; [email-masked]; '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:[email-masked]] 
> Sent: Tuesday, November 02, 1999 4:32 AM
> To: Russ Housley
> Cc: [email-masked]; '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

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 03 Nov 1999 13:11:39 +0100

I agree with Bob.

We should stay compatible with coding in the X.520 country attribute.

/Stefan

>>         ID            id-at-countryOfResidence }

-------------------------------------------------------------------
Stefan Santesson                <[email-masked]>
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
-------------------------------------------------------------------