Re: Basic Cert-2-Directory mapping question

[Janus Liebregts <janus.liebregts@xxxxxxxxxx>]

Bob Jueneman wrote:
> The fact is that the semantic definitions of most of the usual DN
> attributes are conspicuously vague.  Consider "serial", "locality", commonName,
> or even "country".  Yes, we all understand what a country is -- it's
> whatever the UN says it is, or isn't, and questions about disputed territories
> are brushed aside.  But that isn't a semantic definition, that is simply a name to
> territory definition or mapping.  The real question is what is the relationship
> between the country and the end-entity identified by the rest of the DN --
> is it merely a directory qualifier, or is it the country of residence?, citizenship?
> place of doing business? location of the home office? country of
> incorporation of an enterprise? If I am referring to a ship, for example, that
> is owned an operated by a UK company, registered in Liberia ,and
> is currently docked in Miami, what country should I use for the RDN
> of that ship?

Bob,

this relationship depends on the context and can have several forms.

1. in a 'doing-business'-pki
2. in a 'legal'-pki or as you call it a 'send-the-sheriff'-pki 
in both cases not the DN of the ship is important, but the company
responsible for the ship and it's representative, I suggest the captain. 

In a 'doing business'-pki what matters is, which authorizations does the
captain have. The captain could be an dutchman acting on behalf of a UK
company and the same person could also act on behalf of another
(Liberian) company.
So the DN of the captain: cn=captain, o=UK-company, c=GB
which has a 'Role Occupant'DN: cn=John Smith, l=Eindhoven, c=NL

in the 'legal'-pki where the ship is operated by a company under the
legal system of Liberia:
cn=captain, o=Liberian-company, c=LR
with the same 'Role Occupant'

in these cases country represents the legal system of UK and Liberia
so cn= operates on behalf of o= which operates under the laws of c=
and cn= operates as a citizen of l= under the laws of c= or laws of
st=,c=

what l= represents depends on local law.

An other possible solution for solving the jurisdiction problem is
defining yet another certificate extension as done in the
'Internet X.509 Public Key Infrastructure Qualified Certificates
Profile' (http://www.ietf.org/internet-drafts/draft-ietf-pkix-qc-06.txt) 
but this requires other law systems to recognize and accept this
extension. This will be the case in the countries of the European Union
by means of the ETSI QCP-standards which implements the EU-directive on
digital signatures. 
According to this ietf-draft:
"A typical statement suitable for inclusion in the Qualified Certificate
Statements extension MAY be a statement by the issuer that the
certificate is issued as a Qualified Certificate in accordance with a
particular legal system"
and
"The issuer field SHALL identify the organization responsible for
issuing the certificate. The name SHOULD be an officially registered
name of the organization"

3. 'access & authorization'-pki
it doesn't matter what is meant by country, any company can make his own
rules for his own domain or even choose some other or mixed naming
scheme. When inter-businnes 'access & authorization' is required, you
have to agree on a naming policy and build a:

4. 'branch oriented A&A'-pki
There we could have the super-branch-organisation (Root) which certifies
members, with names recognized by all it's members (domain) and which
can give some meaning to country. One company can be member of more
branches and can have different names in different domains, so the
branch oriented pki's gather and form a:

5. 'inter branch oriented A&A'-pki

etc....

For building legal pki's, I think governments should take their
responsibility by building national pki's issuing identity certificates
to persons and companies.

>From legal point of view there should be a federation of pki's; one per
legal system.
In the CP of such a national RootCA their should be some lines:
"The issuer name SHOULD be an officially registered name of the person
or organization"
and
"The certificates are issued in accordance with the (fill in your
country) legal system"

The dutch law defines some Naming Authorities (NA)

-NA for persons: local authorities (de gemeente, burgerlijke stand
http://www.wetten.nu/wetgeving/nl00087/nl00087-08.cfm)
-NA for local authorities: the community council (de gemeenteraad
http://www.wetten.nu/wetgeving/nl00096/nl00096-02.cfm#P788_75618)
-NA for companies: chambers of commerce have a delegated task
(Handelsregisterwet 1996 & Handelsnaamwet)
(excuse my bad translations in the above)

The first step in my opinion would be bringing in line the used
Organizational Name in certificates with the name registered with the
local Chamber of Commerce. The Chamber of Commerce could operate their
own CA and doing the task they already do: registering companies,
distinguishing between them and register which person has which
authorization or which people can act on behalf of this organization.

As this infrastructure is not in place yet, I suggest, when building
national or legal pki's, Naming Authorities should bring in line the
used names with the ones as registered with the Chamber of Commerce. The
dutch Chamber of commerce has an on-line register with officially
registered company names: http://www.kvk.nl/kvk/kvk-online.html?type=h
(for using it read Handelsnaam=company name, Plaatsnaam=city, Start
zoeken= start searching)


Step 1. register officially (according to law) the name
Step 2. make a DN from 'officially registered name'
 c=NL (according to dutch law), o= organizational name (according to
chamber of commerce), cn/ou= whatever (according to organization)
 c=NL (according to dutch law), l= community name (according to the
community council), cn=personsname (according to local authorities,
burgelijke stand in the Netherlands)
Step 3. certify the binding public-key/DN

My overall view is, make the contents of a certificate as bare as
possible and store everything else in the ldap-entry belonging to this
certificate. This is an entry which is controlled by the (privacy wishes
of the) subject.

But the basic question is where to find that ldap-entry, not knowing the
starting point. In my point of view every pki can have it's own
bootstrap. Pki's based on dc-naming have their bootstrap in DNS by the
named.root (ftp://ftp.rs.internic.net/domain/named.root) and adding a
SRV-record. I think a legal-pki based on X.521-naming will have some
sort of bootstrap defining the ip-adresses of the top level DSA's in
some similar file. 

We claim to operate the c=NL tree according to SURFnet, which is
according to NameFlow which is our bootstrap
(http://www.nameflow.net/nameflow.html). I would be happy if some other
organizations, also would operate a C=NL tree with some other guarantees
about naming entities. I as a trust builder then could choose my level
of trust, until then let's build the infrastructure on the current
naming policy...

regards,
janus
ldap://ldap.surfnet.nl/cn=Janus Liebregts,o=SURFnet,c=NL