Re: [IETF-PKIX] Subject/Issuer Name Population

[Andreas Berger <aberger@xxxxxxxxxxxxxxxx>]

Tim Polk wrote:
> 
> I have attached proposed text for the issuer and subject name sections.
> 
> Highlights:
> 
> (1) issuer name is required (that is, may not be an empty SEQUENCE).
Do we need this or can we loosen it a little? I am thinking of CAs that
just have DNS name (which is also hierarchical and unique and thus
similar to a DN)? Should we say that the name should be globally unique
and that only on alternative name should be present if the DN is empty?

> (2) subject name is required for CA certs.  (This means you never chain off
> altnames!)
see above.

> (3) Name comparison rules are greatly relaxed from the X.520 text.  Binary
> comparison of attribute values is permitted for everything except
> PrintableString. That is, no white space compression or case conversion in
> BMP or UTF8.
> 
> (Rationale for PrintableString:  It has already been implemented, and is
> used in practically all certificates.  Upper and lowercase country codes,
> etc. will break if we don't support it.)
> 
> Please take the time to review the text.
Regarding the subject name in end entity certificates:

   Where it is non-null, the subject name field shall contain an X.500
   distinguished name (DN). The DN must be unique for each subject
   entity certified by the one CA as defined by the issuer name field.
   (A CA may issue more than one certificate with the same DN to the
   same subject entity.)

I think we should not make requirements for the DN stored in the subject
field, since too many implementations out there use the DN
(subject/issuer) with any kind of semantic they want.

Question:

Isn't the alternative name field "directoryName" the right place to
state that "This is a Distinguished Name in the X.500 sense, additional
information about the subject can be found here".

A different question:

Has anybody "real world" solutions for identifying subject of
certificate (i.e. end-entities). I am thinking of the following cases:

- a person with a company affiliation (most of X.500 seems to be fixed
on this).
Problems: Name ambiguities, do we give people a number...?

- a person with no company affiliation, but with place and date of
birth. While the generic attributes of DNames can be (somewhat hard)
pressed to store this kind of information, I do not think this is a
satisfactory solution

- a person with an address. Same problems as above.

- a person with an address and an addtional qualifier (such as medical
doctor).

The lowest common denominator between implementations usually is the
subject name (display to the user) and hopefully the PKIX alternative
names. So when specific application domains want to be compatible with
the generic PKIX structure, most of the information probably needs to go
into the subject name. So it is (other than in closed user groups) not
advisable to extend the alternative name construct to contain important
information.

Example:

We are working on a specification for certificates that are to be used
with the German Signature Law. The X.509 profile for this application
should be compatible with PKIX requirements (we are trying to do this).
This would allow people to use their Signature certificate with all
applications, especially electronic mail. This implies that PKIX
implementations should be able to verify signatures associated with SigG
(Signature Law) certificates.

Our solution so far is to give examples of how to construct the subject
Distinguished Name to contain the necessary attributes. The goal here is
that the information about the subject is similar to information used in
the physical world (i.e. street address). This information is - in the
technical sense - not unique (cannot be used as a DN in X.500). But for
all practical purposes, it is.

Andreas
-- 
Erst kommt das Fressen, dann kommt die Moral
 -- Bertolt Brecht