Subject: RE: QC certificates and Nationality

From: [email-masked]
Date: Tue, 2 Nov 1999 08:39:05 -0500

I would like to offer the following observation.

Since an ATTRIBUTE is multi-valued by default, there is nothing wrong with
countryOfCitizenship below. The problem seems to be that Name is comprised
of single-valued attribute (i.e., AttributeTypeAndValue), not multi-valued
attributes (i.e., Attribute).

Unfortunately, I do not have a simple solution. I am not comfortable
suggesting Name be changed.

Frank

-----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: "Miklos, Sue A." <[email-masked]>
Date: Tue, 2 Nov 1999 15:09:48 -0500

One of the painful lessons we have learned is that the security policy for
the domain must be applied consistently between those training the users to
populate labels and those creating authorization information if an
automated, label-based access control decision function is to work.  

Weeding out inconsistent application of semantic content is resulting in
significant cultural change.  

I would be grateful if the extension of the attribute definition allows the
use of a trigraph.  It will be another element of information that needs to
be profiled, but that's always the impact of using flexible standards.

Sandi
-----Original Message-----
From: Paul Koning [mailto:[email-masked]]
Sent: Tuesday, November 02, 1999 3:00 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: RE: QC certificates and Nationality

Another way to look at the digraph vs. trigraph issue: given that the
draft refers to the ISO standard, and the latest rev of that standard
has both digraph and trigraph country codes, the obvious thing to do
is to track that standard and support both.

Of course, that does pose an interesting issue.  If a cert shows
citizenship with a digraph country code and a security label has a
trigraph, is that a mismatch?  

If yes, that means that you have to use a single form consistently
across your entire organization -- trigraph or digraph, whichever you
like, but only one.  Is that an acceptable operational restriction?

If no, then you have to implement the conversion anyway, so you can
test for equality between a digraph and a trigraph country code.

	paul

---

From: "Lunow, Pauwl PB SSI-TSIS" <[email-masked]>
Date: Wed, 3 Nov 1999 02:58:05 +0100

For all interested, here's a link to the ISO standard codes:
(ISO 3166-1-Alpha-2 code elements)

http://www.din.de/gremien/nas/nabd/iso3166ma/codlstp1.html

Pauwl

-----Original Message-----
From: Bob Jueneman [mailto:[email-masked]]
Sent: 02 November 1999 19:42
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]

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
>

---

From: "Miklos, Sue A." <[email-masked]>
Date: Wed, 3 Nov 1999 08:30:17 -0500

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,
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:[email-masked]]
Sent: Wednesday, November 03, 1999 7:12 AM
To: Bob Jueneman; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: QC certificates and Nationality

I agree with Bob.

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

/Stefan

existing
>>         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
-------------------------------------------------------------------

---

From: "David P. Kemp" <[email-masked]>
Date: Thu, 4 Nov 1999 10:28:53 -0500 (EST)

Bob,

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

> different one.

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

> There is a long
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?

> code for that conglomeration headed by Queen Elisabeth -- is it UK, 

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.

> able to handle the necessary conversions for a desired presentation 

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

---

From: "Bob Jueneman" <[email-masked]>
Date: Thu, 04 Nov 1999 09:43:48 -0700

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" <[email-masked]> 11/04/99 08:28AM >>>
Bob,

existing

Dave

---

From: "David P. Kemp" <[email-masked]>
Date: Thu, 4 Nov 1999 12:28:56 -0500 (EST)

Bob,

In an ideal world, I too would prefer a single INTEGER type.

But we are living in a world leaning toward XML, where non-validated
character fields reign :-).  How many implementations today actually
contain a table of 3166 digraphs, and how many just accept any two
PrintableString characters for the CountryName attribute?

Look at it as an opportunity to differentiate - if you already support
validation of digraphs, how much harder would it be to extend your
implementation to handle a table of 3-tuples, and do equivalence
matching for free?  IMHO, going from unconstrained 2-character strings
to validated 3166 digraphs is the hard part, and extending that to
handle trigraphs is trivial.

It would make sense to make the QC constraint a bit more specific,
to prevent the use of ASCII numbers:

     (CONSTRAINED BY { -- IS 3166 digraphs and trigraphs only })

Regards,
  Dave

>   [...]

---

From: [email-masked] (Peter Gutmann)
Date: Fri, 5 Nov 1999 07:00:24 (NZDT)

"David P. Kemp" <[email-masked]>

>PrintableString characters for the CountryName attribute?

In case anyone else needs this:

/* Check that a country code is valid */

static BOOLEAN checkCountryCode( const char *countryCode )
	{
	const static char *countryCodes[] = {
		"AD", "AE", "AF", "AG", "AI", "AL", "AM", "AN", "AO", "AQ",
		"AR", "AS", "AT", "AU", "AW", "AZ", "BA", "BB", "BD", "BE",
		"BF", "BG", "BH", "BI", "BJ", "BM", "BN", "BO", "BR", "BS",
		"BT", "BV", "BW", "BY", "BZ", "CA", "CC", "CF", "CG", "CH",
		"CI", "CK", "CL", "CM", "CN", "CO", "CR", "CU", "CV", "CX",
		"CY", "CZ", "DE", "DJ", "DK", "DM", "DO", "DZ", "EC", "EE",
		"EG", "EH", "ER", "ES", "ET", "FI", "FJ", "FK", "FM", "FO",
		"FR", "FX", "GA", "GB", "GD", "GE", "GF", "GH", "GI", "GL",
		"GM", "GN", "GP", "GQ", "GR", "GS", "GT", "GU", "GW", "GY",
		"HK", "HM", "HN", "HR", "HT", "HU", "ID", "IE", "IL", "IN",
		"IO", "IQ", "IR", "IS", "IT", "JM", "JO", "JP", "KE", "KG",
		"KH", "KI", "KM", "KN", "KP", "KR", "KW", "KY", "KZ", "LA",
		"LB", "LC", "LI", "LK", "LR", "LS", "LT", "LU", "LV", "LY",
		"MA", "MC", "MD", "MG", "MH", "MK", "ML", "MM", "MN", "MO",
		"MP", "MQ", "MR", "MS", "MT", "MU", "MV", "MW", "MX", "MY",
		"MZ", "NA", "NC", "NE", "NF", "NG", "NI", "NL", "NO", "NP",
		"NR", "NU", "NZ", "OM", "PA", "PE", "PF", "PG", "PH", "PK",
		"PL", "PM", "PN", "PR", "PT", "PW", "PY", "QA", "RE", "RO",
		"RU", "RW", "SA", "SB", "SC", "SD", "SE", "SG", "SH", "SI",
		"SJ", "SK", "SL", "SM", "SN", "SO", "SR", "ST", "SV", "SY",
		"SZ", "TC", "TD", "TF", "TG", "TH", "TJ", "TK", "TM", "TN",
		"TO", "TP", "TR", "TT", "TV", "TW", "TZ", "UA", "UG", "UM",
		"US", "UY", "UZ", "VA", "VC", "VE", "VG", "VI", "VN", "VU",
		"WF", "WS", "YE", "YT", "YU", "ZA", "ZM", "ZR", "ZW", NULL
		};
	int i;

	/* Check that the country code is present in the table of known codes */
	for( i = 0; countryCodes[ i ] != NULL; i++ )
		if( !strcmp( countryCode, countryCodes[ i ] ) )
			return( TRUE );
	return( FALSE );
	}

This was valid as of a few years back, I'll probably need to update it when
Zklfguifstan, Okjhdfuihrgbec, and the Republic of Msdgfguidfgr declare
independence.

Peter.

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 4 Nov 1999 20:20:44 +0100 (MET)

> >PrintableString characters for the CountryName attribute?

And how many implementation treat  US, us, Us, uS in the same way :-)
> /* Check that a country code is valid */

With Peter's example you cannot validate a document that was signed
in 1990 somewhere in Germany. There was a country code DD. 

I just remember that in 1991 I had to setup a rather strange 
mapping table for an X.400 gateway with one (and almost identical) 
mapping rule for each country. I simply ended up with 26*26 
rules. :-)

Why and where do you actually want to verify a country code?
Well, only if you say, all, except for the following n:
(arbitrary list of your favorites to be included here, WW, NN for example)