Subject: Re: WG Last Call: Permanent Identifier

From: "Tom Gindin" <[email-masked]>
Date: Mon, 3 Jun 2002 01:09:48 -0400

Russ:

      I am not really convinced by point 3 of your technical comments.  The
point of the draft is that DN's are not sufficiently unique for
individuals.  This argument can be extended to organizations in general,
but organizations operating CA's are not all or even most organizations.
In any event, so many general PKI features break if CA's have duplicate
DN's, including CRL location and CMS signatures (the serial number/issuer
combination), that getting this particular feature to work in an
environment where CA's have such DN's is little help.

            Tom Gindin

"Housley, Russ" <[email-masked]>@mail.imc.org on 05/24/2002
05:31:03 PM

Sent by:    [email-masked]

To:    [email-masked]
cc:
Subject:    Re: WG Last Call: Permanent Identifier

I have several comments on the Permanent Identifier Draft.  I have divided
them between technical and editorial.

TECHNICAL

1.  The OID value { id-on 2 } has already been assigned for another
purpose.  Please get fresh one.

2.  It is my understanding that international URIs can be encoded as
IA5String.  This was one of the last issues raised in the development of
RFC 3280.

3.  I do not understand how the identifierType can be optional.  The whole
point of this draft is that distinguished names are not sufficiently
unique.  (I am not trying to reopen this debate; it has been debated at too

great a length already.)  If this is the case, then it would follow that
two CAs could have the same distinguished name.  If two such CAs both
include the proposed extension, then there will be undetectable
collisions.  The resolution seem to be clear.  Make the identifierType
mandatory.

4.  The Security Considerations section is pretty weak.  It mostly restated

the purpose of the extension.  I think that it should contain advice for
implementors that will make use of the identifier as well as advice for the

Assigner Authority.  For example, the Social Security Administration would
be such an authority in the US, and they assign nine digit
indentifiers.  Are 123-45-6789 and 123456789 the same?
(snip)

---

From: Phil Griffin <[email-masked]>
Date: Mon, 03 Jun 2002 06:58:05 -0400

<snip> 
> 4.  The Security Considerations section is pretty weak.  It mostly 
> restated the purpose of the extension.  I think that it should 
> contain advice for implementors that will make use of the identifier
> as well as advice for the
> 
> Assigner Authority.  For example, the Social Security Administration
> would be such an authority in the US, and they assign nine digit

One way to represent a series of integers efficiently is to
use the RELATIVE-OID type:

   SocialSecurity  ::=  RELATIVE-OID

   number  SocialSecurity  ::=  { 233  21  1022 }

   number ::= <SocialSecurity> 233.21.1022 </SocialSecurity>

This requires only one tag octet, and the code to implement
this type is nearly identical to that for OBJECT IDENTIFIER -
the same minus the restriction on the sets of values and the
merging of the first two nodes. 

This example value BER encodes for transfer in only five octets,
and XER encodes in 44 octets. The main drawback is that it requires
use of ASN.1 notation from this century ;-)

Phil

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 03 Jun 2002 14:39:36 +0200

Phil,

>    number ::= <SocialSecurity> 233.21.1022 </SocialSecurity>

This is not the direction we are planning to take. We need to be able to
accept spaces between the digits, we do not want to impose punctuation
marks. So we need loose matching rules where all control characters, spaces,
and punctuation marks can be removed; and then where the values are
compared using CaseIgnoreMatch.

This is this sort of wording that Tom and myself are planning to add to the
draft.

Denis

---

From: "Housley, Russ" <[email-masked]>
Date: Mon, 03 Jun 2002 09:14:04 -0400

Tom:

One of the reasons that has been provided by the advocates of the perm id 
is that DNs are not unique.  I am not one of these advocates.  I do think 
that they should explain why one situation is acceptable and the other is 
not or they should remove the capability that raises the question.

Russ

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 03 Jun 2002 15:27:07 +0200

Russ,

> not or they should remove the capability that raises the question.

The basic question is whether the Permanent Identifier value is specific to
the CA or whether it is chosen from an external name space. When it is
chosen from an external name space, then because of the problem of
uniqueness of names, an OID is being used.

When it is specific to the CA, then it is not necessary to include an OID
to designate unambiguously the external name space, hence why the
identifierType is OPTIONAL.

So I support Tom's position and I believe that the current draft is correct.

To summarize, I would be ready to accept all comments, except comment 3.

Denis

---

From: "Housley, Russ" <[email-masked]>
Date: Mon, 03 Jun 2002 10:16:33 -0400

Denis:

I understand your position.  Please include text that explains your 
position regarding the uniqueness of the CA distinguished name.

Russ

At 03:27 PM 6/3/2002 +0200, Denis Pinkas wrote:
> restated

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 03 Jun 2002 17:42:52 +0200

Russ,
 
> position regarding the uniqueness of the CA distinguished name.

I am not sure that you understand my position, since there is no need for
text explaining the notion of uniqueness of CA distinguished names.
The subject DN is unique to the issuing CA. In the same way the Permanent
identifier, when the identifierType is missing is unique to the issuing CA.

The current text is stating:

   If identifierType is missing, then the permanent identifier is 
   locally unique to the CA.

There is no more to say, otherwise we have a problem of understanding.

Denis

---

From: "Housley, Russ" <[email-masked]>
Date: Mon, 03 Jun 2002 11:51:36 -0400

Denis:

And, the CA is identified by ....

Russ

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 03 Jun 2002 18:04:44 +0200

Russ,

Is it a guess game or a trap game ?

RFC 3280 mentions:

4.1.2.2  Serial number

   The serial number MUST be a positive integer assigned by the CA to
   each certificate.  It MUST be unique for each certificate issued by a
   given CA (i.e., the issuer name and serial number identify a unique
   certificate)

4.1.2.6  Subject

   Where it is non-empty, the subject field MUST 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.

> And, the CA is identified by ....

So would you like:

"If identifierType is missing, then the permanent identifier is locally
unique to the one CA as defined by the issuer name field."

Denis

---

From: "Housley, Russ" <[email-masked]>
Date: Mon, 03 Jun 2002 14:57:36 -0400

Denis:

It is neither a guess game or a trap game.

RFC 3280 also says, in section 4.1.2.4:

    The issuer field identifies the entity who has signed and issued the
    certificate.  The issuer field MUST contain a non-empty distinguished
    name (DN).  The issuer field is defined as the X.501 type Name
    [X.501].

As Tom already pointed out, we expect the issuer field to uniquely identify 
the CA.  CRLs and CMS both rely on this feature.  So, I think you should say:

    If identifierType is missing, then the permanent identifier is
    locally unique to the CA.  The CA is uniquely identified by the
    distinguished name in the issuer field.

Then, I think that you should include a paragraph in the security 
considerations that tell what the consequences are if the issuer 
distinguished name is not unique.  I belive that that they are different 
than the CRL.  With the CRL, the CRL signature will not check if the public 
key associated with the second CA with the same distinguished name is used.

Russ

At 06:04 PM 6/3/2002 +0200, Denis Pinkas wrote:
> > > > > > >unique.  (I am not trying to reopen this debate; it has been 
> debated
> > > > > at too
> > > > > > >
> > > > > > >implementors that will make use of the identifier as well as 
> advice
> > > > > for the
> > > > > > >

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 04 Jun 2002 14:23:11 +0200

Russ,

>     distinguished name in the issuer field.

I would rather prefer to suppress "uniquely" and have the following:

     If identifierType is missing, then the permanent identifier is
     locally unique to the CA.  The CA is identified by the distinguished 
     name in the issuer field.
 
> key associated with the second CA with the same distinguished name is used.

The consideration would be the same as the uniqueness of the Serial Number
or of the Subject field. Unfortunately, RFC 3280 does not contain in the
security considerations section any advice about CA name collisions. 

So I would say that I would like to copy and paste the same warning that
should have been placed in the security considerations section from RFC
3280. Maybe we should ask to one of the co-authors to offer some text. 

:-)

Here is a first shot for an addition to the security considerations section:

Subject names in certificates are chosen by the issuing CA and are mandated
to be unique for each CA; so there can be no name collision between subject
names from the same CA. These names may be an end-entity name, when the
certificate is a leaf certificate or a CA name, when it is a CA certificate.

Since a name is only unique towards its superior CA, unless some naming
constraints are being used, a globally unique name would need to include a
sequence of all the names of the superior CAs. As long as there is one
single trust anchor, then there can be no name collision. 

However, if a relying party trusts more than one trust anchor then name
collisions might still occur between CA names. In such a case the name of 
the trust anchor should be added to the sequence of CA names. 

When the identifierType is omitted and unless some naming constraints apply
to CA names, the identifierValue should be used in conjunction with a
sequence of CA names, from the trust anchor name until the name of the CA
that has issued the end-entity certificate that contains the
PermanentIdentifier.

Denis

---

From: "Housley, Russ" <[email-masked]>
Date: Tue, 04 Jun 2002 08:45:08 -0400

>      name in the issuer field.

Fine with me.

>3280. Maybe we should ask to one of the co-authors to offer some text.

I am sure that you will remember this omission if a revision to RFC 3280 is 
necessary in the future.

>that has issued the end-entity certificate that contains the

You are providing more background than I anticipated. Which is very good, 
and it makes you case clear.  I propose a minor rewording in the last 
paragraph, as follows:

    When the identifierType is omitted and naming constraints do not apply
    to CA names, then the identifierValue ought to be considered in
    conjunction with the sequence of certificate issuer names, from the
    trust anchor name to the name of the CA that has issued the
    certificate that contains the PermanentIdentifier.

Russ