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

From: "Manger, James H" <[email-masked]>
Date: Mon, 19 Jul 2004 15:07:53 +1000

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

---

From: "Anders Rundgren" <[email-masked]>
Date: Mon, 19 Jul 2004 11:52:12 +0200

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

I believe examples like this are very good in order to achieve some
genuine understanding (beyond ASN.1).

But is this not actually a prime example of a scheme using TWO PIs?

This would however also require an updated specification where
something like an optional "instanceNumber" would be featured to
point out the actual serialNumber to use.

Anders

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 20 Jul 2004 16:00:49 +0200

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.

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

> " -- 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: Russ Housley <[email-masked]>
Date: Wed, 21 Jul 2004 11:02:43 -0400

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.
>
>"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 definition of the PI has been changed to allow to 
> use the serialNumber attribute from the subject DN.

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 21 Jul 2004 18:00:35 +0200

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 }
> 
> 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.
> 
> 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
> 
> 
>> 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.  
>> "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 
>> 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 definition of the PI has been changed to allow 
>> to use the serialNumber attribute from the subject DN.
> 
> 
>

---

From: Russ Housley <[email-masked]>
Date: Wed, 21 Jul 2004 12:14:07 -0400

Denis:

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

Russ

At 12:00 PM 7/21/2004, Denis Pinkas wrote:
>>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 }
>>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.
>>series of documents.  The informative information that was once present 
>>was removed because some implementors treated it as normative.
>>Russ
>>
>>>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.
>>>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.
>>>have any sematic value so shouldn't have any impact on the assigner 
>>>field (or vice versa).
>>>
>>>
>>>
>>>3.

---

From: "David P. Kemp" <[email-masked]>
Date: Wed, 21 Jul 2004 15:57:54 -0400

Denis,

Your two conditions below are logical but unnecessarily
restrictive.

Consider James' original (correct) example:

[1] cn="John Doe" serialNumber=12345, o="Acme Ltd"
    serialNumber="DUNS 554433", c=US

and a modification (poorly-structured, but legal) that uses
only single-valued RDNs:

[2] cn="John Doe", serialNumber=12345, o="Acme Ltd",
   serialNumber="DUNS 554433", c=US

and your example:

[3] cn="John Doe", o="Acme Ltd", serialNumber="DUNS 554433", c=US

I do not believe it is necessary to prohibit [2] in order to
prevent [3].  Instead, if the SAN identifierValue is absent:

1 - if there are one or more RDNs containing a serialNumber
     attribute (alone or accompanied by other attributes), then
     the value contained in the serialNumber of the deepest
     such RDN shall be used as the identifierValue.

2 - otherwise, the CA is in error.

X.501 (02/2001) section 9.3, which appears to be normative,
not informative, prohibits a given attribute type from
appearing more than once in the same RDN.  The origin of
Russ' comments regarding the possibility of multiple
serialNumber attributes in a single RDN is unclear.

Dave

---

From: Russ Housley <[email-masked]>
Date: Thu, 22 Jul 2004 08:08:12 -0400

Dave:

I reread it, and you are correct.

The first time I read it, the part that stuck with me was: "The set that 
forms an RDN contains exactly one AttributeTypeAndDistinguishedValue for 
each attribute which contains distinguished values in the entry ..."  Which 
made me think that non-distinguished values could employ a second instance 
of the same attribute type.  Not so.  It goes on to say: "... that is, a 
given attribute type cannot appear twice in the same RDN."

My issue is resolved.

Russ

---

From: "Michael Myers" <[email-masked]>
Date: Thu, 22 Jul 2004 11:42:54 -0700

Trevor,

Section 3.2.10, extracted below, is a good step forward to closure on
the issue.  Given its definition as a BOOLEAN in Query syntax, I am
comfortable with its default to TRUE.

The second paragraph however needs an implementable definition of DPD
vice DPV with respect to SCVP ASN.1 in order to assert that that a
request is in error if it asks for a validation assertion in the context
of signResponse set to FALSE.

Mike

3.2.10 signResponse

  The signResponse specifies if the client requires the server to
  sign a response to the validation request. If the client is
  performing full chain validation on the response and it is not
  concerned about the authenticity of the source of the data, then
  the client does not benefit from the signature on the response in
  which case it can indicate to the server that the signature is
  unnecessary via the signResponse value.

  SCVP clients that support DPD MUST support setting this value to
  FALSE. Since DPV responses must be signed, DPV only SCVP clients
  MUST NOT to support this value. SCVP servers SHOULD support
  returning unsigned responses. It is a local policy decision on the
  part of the server to return signed or unsigned responses if this
  value is set to FALSE.