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

[Denis Pinkas <[e-mail]>]

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.
> 
> 
>