Subject: RE: PI: 10: draft-ietf-pkix-pi-10.txt - single serialNumber attribute

From: "Alberti Antoine" <[email-masked]>
Date: Wed, 21 Jul 2004 18:20:06 +0200

I wonder if it is realistic to set constraints on DNs in the PKI standards: one may not be able to use a DN that existed before the certificate creation or renewal if the DN does not match the new rules. In this case, what does the DN mean if it has to change from time to time, that is to say if it does not identify the owner of the cert (I know it is already the case, but it is not necessarily a reason to make this even more true) ?

Regards.
Antoine Alberti.

> -----Message d'origine-----
> De : [email-masked]
> [mailto:[email-masked]]De la part de Denis Pinkas
> Envoyé : mercredi 21 juillet 2004 18:01
> À : Russ Housley
> Cc : Manger, James H; [email-masked]
> Objet : Re: PI: 10: draft-ietf-pkix-pi-10.txt - single serialNumber
> attribute
> 
> 
> 
> Russ,
> 
> I would think that you wrote this e-mail before getting mine 
> on the same 
> topic. When reading your e-mail, I would believe that the two 
> cases would 
> need to be changed from:
> 
> 1 - if there is one serialNumber attribute alone in a RDN (i.e. no
>      other attribute is present in that RDN), then the value contained
>      in that serialNumber shall be used as the identifierValue;
> 
> 2 - if there is no serialNumber attribute alone in a RDN, then the
>      deepest RDN shall include a serialNumber attribute and the
>      value contained in that serialNumber shall be used as the
>      identifierValue.
> 
> to:
> 
> 1 - if there is one serialNumber attribute alone in a RDN (i.e. no
>      other attribute is present in that RDN), then *there shall
>      only be one such RDN and* the value contained in the
>      serialNumber attribute shall be used as the identifierValue;
> 
> 2 - if there is no serialNumber attribute alone in a RDN, then the
>      deepest RDN shall include a *single* serialNumber attribute
>      and the value contained in that serialNumber shall be used
>      as the identifierValue.
> 
> Denis
> 
> 
> > James:
> > 
> > The authors put the serial number restriction into the document in 
> > response to a comment from me.  In the example that you 
> provide, there 
> > is not a problem.  However, one can construct a 
> distinguished name that 
> > is ambiguous.  The X.500 series of documents give us a very complex 
> > structure for Name:
> > 
> >    Name ::= CHOICE {
> >      RDNSequence }
> > 
> >    RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
> > 
> >    RelativeDistinguishedName ::=
> >      SET OF AttributeTypeAndValue
> > 
> >    AttributeTypeAndValue ::= SEQUENCE {
> >      type     AttributeType,
> >      value    AttributeValue }
> > 
> >    AttributeType ::= OBJECT IDENTIFIER
> > 
> >    AttributeValue ::= ANY DEFINED BY AttributeType
> > 
> > Since RelativeDistinguishedName is a SET, it is possible to 
> have more 
> > than one attribute at the same level.  If this level were 
> to include 
> > more than one SerialNumber attribute, then it would not be 
> clear which 
> > one to use as the permanent identifier.  Since it is a SET, 
> one cannot 
> > rely on order to help resolve this issue.  They would be 
> equally "deep" 
> > in the RDNSequence.
> > 
> > I admit that no one in their right mind would design a 
> schema like this, 
> > but sadly, the structure permits an uninformed person to make some 
> > really bad choices.  Further, guidance in this area was 
> removed from the 
> > X.500 series of documents.  The informative information 
> that was once 
> > present was removed because some implementors treated it as 
> normative.
> > 
> > Russ
> > 
> > 
> > At 01:07 AM 7/19/2004, Manger, James H wrote:
> > 
> >> 1.
> >> The ability to flag a serialNumber attribute value in the 
> subject name 
> >> as a permanent identifier is a nice feature.  Requiring that there 
> >> only be a single serialNumber attribute, however, is unnecessarily 
> >> restrictive.  It seems quite sensible to use serialNumber 
> attributes 
> >> to hold company numbers, org unit ids and/or personal 
> identifiers.  
> >> For example: cn="John Doe" serialNumber=12345, o="Acme Ltd" 
> >> serialNumber="DUNS 554433", c=US.  The PI extension would 
> refer to 12345.
> >>
> >> [Section 2] Change the ASN.1 comment for the 
> identifierValue field of 
> >> PermanentIdentifier to:
> >> " -- if absent, use the deepest serialNumber attribute 
> value in the 
> >> subject DN"
> >>
> >> [Section 2] Change the paragraph that begins "When the 
> identifierValue 
> >> field is absent" to:
> >> "When the identifierValue field is absent, then the deepest 
> >> serialNumber attribute value from the subject DN is the 
> value to be 
> >> taken for the identifierValue.  An attribute is "deeper" 
> if it occurs 
> >> later in the sequence of RDNs that make up the DN.  A "deeper" 
> >> attribute occurs earlier in the string representation of a DN 
> >> [RFC2253], which start encoding the last element of the 
> RDN sequence 
> >> that makes up a DN and moves backwards towards the first.  The 
> >> PermanentIdentifier SHALL NOT be used if there is no serialNumber 
> >> attribute in the subject DN.
> >>
> >>
> >>
> >> 2.
> >> Why can't the assigner field be present but the 
> identifierValue field 
> >> be absent (refer to the serialNumber attribute)?  An absent 
> >> identifierValue is simply "shorthand" to avoid duplicating 
> a value -- 
> >> it doesn't really have any sematic value so shouldn't have 
> any impact 
> >> on the assigner field (or vice versa).
> >>
> >>
> >>
> >> 3.
> >> The security considerations section mentions an 
> identifierType field 
> >> that no longer exists.
> >>
> >>
> >> > ----------
> >> > From:         [email-masked] 
> >> [mailto:[email-masked]]
> >> > Sent: Wednesday, 14 July 2004 6:05 AM
> >> >
> >> >       Title           : Internet X.509 Public Key Infrastructure 
> >> Permanent Identifier
> >> >       Author(s)       : D. Pinkas, T. Gindin
> >> >       Filename        : draft-ietf-pkix-pi-10.txt
> >> >       Date            : 2004-7-13
> >> >
> >> > http://www.ietf.org/internet-drafts/draft-ietf-pkix-pi-10.txt
> >> >
> >> >       ----------
> >> >       From:   Denis Pinkas [mailto:[email-masked]]
> >> >       Sent:   Thursday, 15 July 2004 6:06 PM
> >> >       Cc:     [email-masked]
> >> >
> >>                 ... the definition of the PI has been 
> changed to allow 
> >> to use the serialNumber attribute from the subject DN.
> > 
> > 
> > 
> 
> 
>

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 21 Jul 2004 18:40:40 +0200

> I wonder if it is realistic to set constraints on DNs in the PKI standards: 
 > one may not be able to use a DN that existed before the certificate
 > creation or renewal if the DN does not match the new rules. In this case,
 > what does the DN mean if it has to change from time to time, that is to
 > say if it does not identify the owner of the cert (I know it is already
 > the case, but it is not necessarily a reason to make this even more
 > true) ?

Using a serialNumber attribute is not mandatory to be able to use the PI 
feature. Some forms of DN will be able to support a serialNumber as the 
value of the identifierValue, while some others will not. In such a case, an 
explicit identifierValue can be used.

The proposed text only excludes the case where a RDN sequence would contain 
two or more serialNumber attributes in isolation. This is none of the 
examples given.

The constraint seems thus reasonable.

Denis