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

[Russ Housley <[e-mail]>]

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:         [e-mail] [mailto:[e-mail]]
> > 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:[e-mail]]
> >       Sent:   Thursday, 15 July 2004 6:06 PM
> >       Cc:     [e-mail]
> >
>                 ... the definition of the PI has been changed to allow to 
> use the serialNumber attribute from the subject DN.