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

[Denis Pinkas <[e-mail]>]

> 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


> Regards.
> Antoine Alberti.
> 
> 
>>-----Message d'origine-----
>>De : [e-mail]
>>[mailto:[e-mail]]De la part de Denis Pinkas
>>Envoyé : mercredi 21 juillet 2004 18:01
>>À : Russ Housley
>>Cc : Manger, James H; [e-mail]
>>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:         [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.
>>>
>>>
>>>
>>
>>
>