Subject: RE: Qualified Certificates draft - Country name

From: Stefan Santesson <[email-masked]>
Date: Mon, 22 Feb 1999 15:49:04 +0100

Sue,

You have a point. We have had this issue up before (with NATO as example,
brougt up by Al Arsenault) and we said "-Well lets start with countryName
mandatory and see what reactions we get"

I feel rather convinced now that countryName should NOT be mandatory.

We will discuss this issue on the next IETF meeting.

/Stefan

At 09:03 AM 2/22/99 -0500, Miklos, Sue A. wrote: 
RE: SEIS:  RE: Comments to Qualified Certificates draft 

Please forgive what may be an ignorant question, but when I saw the Country
= mandatory, I became confused.   

I am thinking about international organizations (Red Cross, NATO, etc) that
do not wish to include a country in the name, as there is no singular
country 'owning' that name space.  The implementations have left that field
blank and go directly to the Organization = element of the name.   

Is this configuration supported?  If you are only working in the individual
name space, please forgive my potentially misinformed comment.   

Sandi 

---------- 
From:   Stefan Santesson[SMTP:[email-masked]] 
Sent:   Friday, February 19, 1999 10:07 AM 
To:     Anders Rundgren 
Cc:     'SEIS-List'; [email-masked]; [email-masked] 
Subject:        SEIS:  RE: Comments to Qualified Certificates draft 

--- Message on the SEIS mailing list ([email-masked]) 

Sorry, My fault. 

You are right. Country IS mandatory. 
Guess we have to think about that. I still think it makes sence to keep it 
there. 

/Stefan 

At 03:26 PM 2/19/99 +0100, Anders Rundgren wrote: 
>Hi,  
>Verbatim from the draft: 
>
>The subject field SHALL include one of the following choices of sets of 
>mandatory attributes: 
>Choice  I:  countryName commonName 
>Choice II:  countryName givenName surname 
>
>>The CountryName attribute is optional. If you find it redundant, then leave 
>>it out. There are on the other hand many certificates that do use this 
>>attribute so I would not prevent it from being used. 
>
>So SHALL and mandatory is to be interpreted as optional?  Mandatory is 
equivalent to MUST 
>at least outside of the PKIX-world. 
>
>>The purpose of the example certificate is only to show an example of how 
>>the profile may be implemented. It does NOT imply that the present 
>>attributes SHALL be present in any speciffic application. 
>
>I just wanted to express my view that the example was "untypical" . 
>
>For those who are a little bit leaning towards the practical side of 
things it does not 
>hurt with more than one example and maybe even mention what the example
could 
>be used for.  Naturally stating that they are just an examples and should 
not be 
>interpreted as policies, rules, recommendations, or whatever. 
>
>>>On a physical card personal data may be of interest to establish the 
>>connection between the person and 
>>>the card/certificate.  But what is inside the certificate, is a different 
>>story. 
>
>>I guess I lost you here. 
>
>What I said was just that the contents of a QC do not have to match its 
container in the way a SEIS ID-card does. 
>This is indeed very interesting to discuss given all projects in the 
making (SEIS, Germany, Finland, and Estonia). 
>
>>>Just my 2 öres. 
>>(What does this mean???? ;-) ) 
>
>I think it means something like "My opinion for what it is worth" 
>
>Anders Rundgren 
>Senior Internet e-commerce Architect 
>
>
>
------------------------------------------------------------------- 
Stefan Santesson                <[email-masked]> 
Accurata Systemsäkerhet AB      
Lotsgatan 27 D                  Tel. +46-40 152211               
216 42  Malmö                   Fax. +46-40 150790               
Sweden                        Mobile +46-70 5247799 

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0 
------------------------------------------------------------------- 

----------------- SEIS mailing list ([email-masked]) 
Info about this list:
<http://www.nc-forum.com/seis>http://www.nc-forum.com/seis 
SEIS Contact: [email-masked] 

-------------------------------------------------------------------
Stefan Santesson                <[email-masked]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. +46-40 152211              
216 42  Malmö                   Fax. +46-40 150790              
Sweden                        Mobile +46-70 5247799

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------

---

From: [email-masked]
Date: Mon, 22 Feb 1999 12:05:21 -0500

If the major reason for DN's without country names is to allow
international organizations to avoid specifying a home country, one could
define a country code (probably "00") to mean that the organization
specified is international.  This is approximately what X.400 did with the
Administrative Management Domain field, which was originally mandatory.  If
corporations are to be permitted to declare themselves trans-national for
directory purposes (although very possibly they should not), they would get
a different numeric country code.

          Tom Gindin

These opinions are mine, and are not necessarily those of my employer.

---

From: "Bob Jueneman" <[email-masked]>
Date: Mon, 22 Feb 1999 12:08:46 -0700

Deja vu all over again.

As in nearly all of these issues, it is important to understand what 
you are trying to accomplish, and in particular what the semantics
are.

I can think of three or four reasons why one might want to have a country
listed in a DN:

1. To provide a globally unambiguous name or reference.  Generally 
speaking, neither corporate names nor geopolitical names are unique
across countries -- Georgia could be a state within the United States, or
a state within the former USSR. IBM Corp is probably IBM Corp 
throughout the world, because they are vigilant about enforcing their
trademark.  But if the Laird McDonald has anything to say about it,
McDonalds may be a protected name in every country but Scotland.

2.  To provide a pointer to the country where an organization is incorporated.
This is related to the unambiguous naming problem, but it may also have a legal
connotation regarding choice of laws, legal/cultural nomenclature and other
references, as well as providing some indication of where you should send any
official legal notices.  In the case of a residential person, this might be used to 
indicate the citizenship of the individual (in which case, what should be done 
about those who have dual citizenship?), which might also have legal and 
tax consequences.

3.  To define the particular location where some entity actually resides and/or 
does business.  For example, I don't believe that Novell has a subsidiary that
is incorporated in Saudi Arabia, but I wouldn't be surprised if we had a sales office
there.  Should we then say c=Saudi Arabia, o=Novell?  Probably not.  Instead,
maybe c=US, o=Novell, Inc., ou="Europe, Africa, Middle East", c=Saudi Arabia, 
ou="Sales Office 123" should be used.  In the case of a residential person, 
the country code might indicate his country of residence, at least for the purposes
of this certificate.  

If you really want to go off the deep end, consider someone 
who has dual citizenship in one of the two countries, but the other country refuses
to recognize the other country, and therefore refuses to recognize the individual's
second citizenship.  The individual maintains a primary domicile for purposes of 
taxes, driver's licenses, etc., and intends eventually to return there, but that 
domicile is in yet a third country.  The individual is presently residing in a 
fourth country on a temporary basis -- perhaps attending school there. 
But while visiting a fifth country for three months on a back-packing 
vacation with no fixed address, he decides he needs an Internet 
connection and subscribes to one located in a sixth country, which 
he accesses via an Iridium link.  What country code or codes
should he include in his qualified certificate?

Once you have answered that question, consider what to use in the 
case of a stateless person such as who was a citizen of a country which 
no longer exists, who has no permanent domicile, but who is presently 
living and working on an off-shore oil tower located in international waters.

Oh, and don't forget such interesting anomalies as the Federated Islands 
of Micronesia, which operate under a compact of free association with 
the United States, and have a postal code corresponding to that of a state 
or territory within the US, but yet they are a sovereign country.

And I haven't even mentioned international organizations, some of which 
fall under the auspices of the United Nations and some of which do not,
but yet are not subsidiaries of an organization that is incorporated in a
traditional country.  A multinational organization of scientists living in
Antarctica would be an interesting case to speculate about, for example,
in addition to NATO, the World Health Organization, etc.

What problem are you trying to solve?

Bob

>>> <[email-masked]> 02/22/99 10:05AM >>>

          Tom Gindin

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 02 Mar 1999 19:09:54 +0100

I interpret the ruff consensus to be that countryName should NOT be mandatory.

I have seen many reasons presented on why it would be wise to use the
country name (I agree to many of them). What I try to figure out is if it
would be any problem for those using countryName if it also would be
allowed not to.

I can't find any such problems, espesially not when there is no absolute
relation between attributes in the subject field and the location of a
certificate in a directory. Further the policy/CPS may provide semantics
which otherwise would be unclear due to an absent countryName value.

If any one else can find real problems, I would like to know, otherwise I
suggest that we remove the mandatory requirement.

/Stefan

---

From: [email-masked]
Date: Tue, 2 Mar 1999 19:34:33 -0500

Does this consensus apply to issuer name as well as to subject name?
Certificate verifiers are expected to perform real-time retrieval of CRL's
with no information other than the issuer name when the
CRLDistributionPoint extension is not used.  Most of the discussion on this
thread seems equally applicable to issuer names and to subject names.
     While there is no absolute relation between subject attributes and
directory entries, a certificate is usually expected to be found in no
other directory entry than that whose name matches the subject.  While the
policy or CPS could provide information about the semantic usage of
country, it is not intended to point to the physical directory.

          Tom Gindin

Stefan Santesson <[email-masked]> on 03/02/99 01:09:54 PM

To:   [email-masked]
cc:    (bcc: Tom Gindin/Watson/IBM)
Subject:  RE: Qualified Certificates draft - Country name

I interpret the ruff consensus to be that countryName should NOT be
mandatory.

/Stefan

---

From: Alan Lloyd <[email-masked]>
Date: Fri, 5 Mar 1999 06:22:51 +1100

For my two bobs worth - I think that making the global business
community comply to an RFC that dictates the global positioning and
representation of its information system names into a business market is
a nonsense.

What stops organisations like Pepsi, Msoft, Ford, etc spending billions
on an IT a directory/509/transaction infrastructure - applying global
org names and putting services and products all over it and giving their
customers loyalty based certficates to use such service/products.
Absolutely nothing !

And if such a company asked a huge IT orgainsation to build it - would
they go kicking and screeming that a country name must be used... NO

One cannot force names on business organisations through the use of RFCs
or standards .... remember GOSIP !

regards alan 
PS Country names just HAVE to be optional.

---

From: "Bob Jueneman" <[email-masked]>
Date: Thu, 04 Mar 1999 12:04:02 -0700

David,

Flat is not necessarily bad, although the performance of 
typical directory implementations may be a concern.

But hashing the certificate or public key a la SPKI is 
in my opinion NOT the way to go, for reasons that were 
argued extensively on that list (even if Carl Ellison 
remains unconvinced).

I wouldn't mind such a technique as an alias, if aliases 
weren't such a headache, but I don't think it would be 
acceptable as the primary DN, because people want to be
able to look up lots of other things about someone than
their certificate, and they want to be able to do so for a 
very long period of time.

The only problem I have with using an employee number
as the primary index is the tendency to use a master dossier
index such as the SSN for that purpose -- a privacy concern.

Even if we used a SHA-1 hash of a canonical form of the 
employee's birth certificate (which would be a perfectly 
lousy "name"), it might still become a dossier locator.

Employee ID is probably about the best that can be done, but it 
should not be global in scope, but rather unique only within the
naming organization.

Maybe we partition the employee ID space for efficiency,
perhaps by including the first letter of the (original) name,
or something similar. 

Bob (J.1234567)

>>> "David P. Kemp" <[email-masked]> 03/04/99 08:42AM >>>
> From: [email-masked] (Arnoud "Galactus" Engelfriet)
> 
> The number of .com domains is now well over 3 million. It's hardly
> a meaningful top-level domain anymore.

Au contraire.  What is meaningful about it is that those 3 million
domains are registered in a single place, and as a result a given
name can be resolved unambiguously.

The longer I look at naming heirarchies, the more my goodness metric
becomes "the flatter, the better".  It would be fine with me if
certificates were indexed by hash value (as stored in AKI), and
one could find every certificate on the Internet by looking it up
in The Directory by that value.

Bob, that's my suggestion for your magic bullet.  Efficiency may demand
CIDR-style partitioning of the AKI space (or something along the lines
of Tony's a.b.c.d prefix, applied to AKI instead of DN), but that could
work by migrating certificates to the appropriate directory server(s)
by prefix WITHOUT any pre-arranged AKI partitioning of CAs.
EE certs could be referred to by "cert hash" instead of (or in addition
to) Issuer/Serial, and retrieved from the Directory the same way.

---

From: "David P. Kemp" <[email-masked]>
Date: Fri, 5 Mar 1999 14:40:22 -0500 (EST)

> From: "Bob Jueneman" <[email-masked]>
> 
> David,
> 

I see two different scenarios for looking up certificates:

1) I receive an S/MIME message (or an IPSEC/IKE connection request)
containing only an EE cert or (preferably) no cert at all, just a
certID.  I look for the issuer cert path (and perhaps also the EE cert)
in my local ram cache and my local disk cache. If they aren't cached, I
do a repository fetch, which chains as required from my company's or
ISP's directory cache on up to the Internet Root.  For this purpose, a
certID should be an "address" (i.e. something meaningless and
politically non-controversial like a hash) with the sole purpose of
enabling the fetching to occur.

2) I have a "name" of someone I want to communicate with and don't
already have any information about him (such as a certID, DN, or cert)
in my address book.  For that, I need a white pages directory.

The first "repository" scenario is the one I'm addressing.
It is easy to solve, and the IETF should solve it by defining
the protocols and standing up the infrastructure root, because
it is purely a technical engineering exercise.

The second "directory" scenario is too hard.  People were
arguing about directories and naming schemes before I was born
and will be doing so after I'm gone. More importantly, directories
should IMHO be regarded as layered *on top of* repositories,
providing metadata about the repository's contents, but not
being necessesary for the repository to operate.  Just as if
DNS fails I can make a TCP connection to a dotted-quad IP address,
if "The Directory" fails or is never established or information owners
filter what it is allowed to reveal, I should still be able to
fetch a cert by ID.

I'm not signing up to the SPKI philosophy that the cert itself
needs no name.  I'm just saying that the cert should be retrievable
by an ID that is not necessarily a name.

---

From: "Zahid Ahmed" <[email-masked]>
Date: Fri, 5 Mar 1999 05:33:50 -0800

I agree that is should be retrievable via ID that is not a name.
But I don't understand what this is ID to fetch the cert 
should be? and how we will include this in exisiting
X.509 certificates? what extensions will work with
exisiting X.509 certs?

---

From: "Bob Jueneman" <[email-masked]>
Date: Fri, 05 Mar 1999 14:57:44 -0700

David,

You have a certain point.

It would be sufficient to find the certificate to have 
Issuer name plus serial number, or authorityKeyId, 
if you know where to look for that information. 
Obviously a hash alone would also work, again 
if you know where to look.

It may come down to what information is most readily available 
in the particular S/MIME, IKE, signed document, or whatever,
and perhaps someone who is more familiar with the Cryptographic 
Message Syntax specs could help out here.

My admittedly unfounded assumption was that if the 
"payload" does not include the E-E certificate, that it is
at least quite likely to include the signer/user's name in
some form, probably more or less in the form of a DN,
perhaps an RFC822 name, but not necessarily.

That's why I was trying to use the DN more or less 
"as is", and to attach a prefix that would indicate 
where to look (and maybe how to look) for the directory
or repository.

Bob

>>> "David P. Kemp" <[email-masked]> 03/05/99 12:40PM >>>