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

[Russ Housley <[e-mail]>]

Denis:

Yes, I did write this before I saw your response.

Russ

At 12:00 PM 7/21/2004, Denis Pinkas wrote:
>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:         [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.
>>
>
>