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

[Denis Pinkas <[e-mail]>]

James,

> 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 5.2.9 from X520 defines the serial Number attribute as follows:

"The serial Number attribute type specifies an identifier, the serial number 
of an objet."

The serial Number attribute applies to the object, not to a RDN component.
Thus, unless it is an error, there can't be multiple serial Number 
attributes in a DN.

> [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"

See above.

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

See above.

 > The PermanentIdentifier SHALL NOT be used if there is no serialNumber
 > attribute in the subject DN.

This could be added as a note.

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

This is a good question.

This combination would mean that the serial Number is not local to the CA 
but is coming from an assigner authority.

Some text proposal follows to support this option:

4 -  The assigner field is present and the identifierValue field is
      absent.

      The assigner field identifies the Assigner Authority and the type
      of permanent identifier being identified. The value of the single
      serialNumber attribute included in the subject DN SHALL be considered
      as the identifier value. The permanent identifier is globally unique
      among all CAs. In such a case, two permanent identifiers of this type
      match if and only if, the contents the serialNumber attributes within
      the subject DN's of those same certificates match using the
      caseIgnoreMatch rule, and the assigner fields match.

      Note: in this case, the PermanentIdentifier SHALL NOT be used
      if there is no serialNumber attribute in the subject DN.


> 3.  The security considerations section mentions an identifierType field 
 >     that no longer exists.

Good catch. Thanks.

Denis

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