Subject: RE: Straw Poll: SerialNumber definition

From: Anders Rundgren <[email-masked]>
Date: Thu, 24 Feb 2000 17:34:32 +0100

Steve,

<snip>

>>PS Steve, do you prefer that a solution according to my and Denis lines are
>>taken to PKI-FORUM rather than developed here?  I don't care where as
>>long as it gets done.  DS

>Is this a trick question?  Is it really an offer for you to move your 
>campaign for changes to ITU and IETF standards to an industry 
>consortium? How can I say no?

OK, I will not continue to push Plug'nPlay Certificates in IETF.
A great victory for purity!  "Consensus" rules!

You are free to continue to outlaw DN interpretation support schemes (should include the latest
suggestions by Stefan and David Kemp) in the same way as dnQualifier in spite of the fact that
both belong to current practice and work just fine.

And we will get International standards that contain phrases like "certificates must be compared with care".

Looks like a good time to invest in a PKI-consulting business.  :-)

Anders

---

From: Stephen Kent <[email-masked]>
Date: Fri, 25 Feb 2000 17:53:08 -0500

Anders,

>both belong to current practice and work just fine.

Irrespective of the technical issues we are discussing, there seems 
to be some confusion about the purpose of the IETF standards process, 
and of this WG's charter.

It is NOT the goal of this WG to produce standards primarily based on 
current practice.  If that were the case, we would not have 
depricated the use of the Common Name as a means of expressing an RFC 
822 name or a DNS name.  There is considerable common practice here, 
but its inappropriate and thus 2459 strongly encourages use of the 
appropriate name forms and discourages misuse of the DN name form in 
this fashion. So, I think that we have established the flavor of what 
PKIX tries to do in this regard.

The charter of PKIX stated that we were profiling X.509 standards for 
use in the Internet, extending such standards as needed to meet 
Internet needs.  Sometimes we diverge from X.509, when we think it is 
absolutely necessary, but we usually work with the X.509 folks to 
achieve compatible solutions.  The proposed change to the definition 
of serialNumber is such an example, and, in the recent past, the 
change to the basicConstraints extension.  So, we do take issues at 
times with what X.509 does, and we work to resolve such problems, but 
we do not do so lightly.

The issue that triggered this expending debate was the observation 
that an ID number assigned as part of a DN used in a QC might, in 
many instances, uniquely identify the subject. Moreover, an RP would 
like to take advantage of this feature to compare two QCs issued with 
differing DNs, but by the same CA, to determine if the same entity 
was represented by them, despite differences in the DN.  I can 
appreciate the desire to be able to make such a comparison, but I 
also note that this comparison approach clearly assumes knowledge 
outside of the DN semantics.

What we have here is a desire to have one's cake and eat it too :-). 
You want to make use of the DN syntax because of the ability of 
existing software to parse DNs, but the semantics of what you want to 
express is not really a DN. In other instances we have defined new 
objects to represent other name types, but here, since name would 
make use of the same attributes, it seems less critical to define a 
new object under the GeneralName  structure. The challenge is to 
consider way to resolve this issue, without breaking the existing 
semantics of DNs and while minimizing the need to create new 
software. Fortunately, i think we have a porposal that does that, as 
explained below.

Tom Gindin posed a good set of questions that are related to the 
issue I described above, but also are somewhat independent. I think 
the redefinition of serialNumber addresses the fundamental concern he 
raised.  However, this redefinition, although it allows a unique, 
national ID to be represented, does not change the semantics of a DN 
in support of the comparison goal described above.  To know that a 
serialNumber attribute has the property of uniquely identifying a 
subjetc, all but itself, one has to communicate this in some fashion 
to software operating for RPs.

Dave Kemp provided some good explanatory diagrams in his message this 
week, and suggested a delimiter approach to breaking the DN into a 
prefix that uniquely identifies a subject, vs. a suffix that is just 
for display purposes. This is an example of a much more powerful 
mechanism, that goes beyond the original problem and tries to provide 
a means of generally expressing what parts of a DN are critical for 
uniqueness, vs. what parts are just for display to a user. Peter 
Sylvester suggested the same sort of marker. I'm not comfortable with 
this approach because it represents a fundamental change to the 
semantics of a DN, and others are not happy with it since it 
introduces a new attribute, which could cause backward compatibility 
problems.

Stefan suggested a bit string approach to specifying which attributes 
contribute to the unique part of the DN.  This approach avoids the 
for a new attribute, but suffers from the fact that some of these 
attributes can be replicated in a DN, so that the bit string may not 
be able to express the exact attribute subset unless some constraints 
are imposed on the DN schema. Denis's refinement of this approach 
depends on an old RFC that recommends schema constraints for the DNs. 
I tried to do this sort of thing several years earlier in RFC 1422, 
and was suitably chastised then. I don't think it's any more viable 
now.

Bengt Ohlsson suggested another approach to the general problem, 
putting the "unique" DN in the Subject Alt Name extension, as a 
directoryName. This avoids the need for a new extension, the need to 
create a new attribute,  or the need to impose schema constraints. 
However, the example he provides does not exactly match the scenarios 
we have been describing; he said "if the serialNumber attribute is 
unique by itself, then the SubjectAltName entry will only contain the 
serialNumber."  This example would require that the serialNumber be 
globally unique, not just unique per country.  The QC examples we 
have discussed don't involve globally unique ID numbers, so the 
example probably needs to be modified a bit to represent the 
scenarios we have been discussing. This is a valid approach to the 
issue, so long as the SubjectAltNames are real DNs.

Antonio Lioy seconded this approach and gave examples, but here I am 
a bit confused. Antonio spoke of using a distinct OID for each new 
name he inserted; "Each subjectAltName is distinguished by a unique 
OID and hence each application can look for the one that it is able 
to deal with."   Is the OID for an attribute in a directoryName, or 
is it a new GeneralName name type?  The examples provided don;'t 
sounds like DNs: "we use it to insert our unique University ID but a 
second extension could be added for standard Italian national 
personal code, or for the case where the same individual belongs to 
two different organizations." If one creates new attribute types and 
uses them as stand-alone, single attribute DNs, this does not address 
the backward compatibility concerns raised earlier, and these names 
are probably not really DNs, e.g., without other attributes as a 
prefix, they are not likely to be suitable names in the DIT.

I'm comfortable with the approach Bengt proposed, assuming that the 
SubjectAltNames are real DNs, as I explained above. This seems to 
address the original problem, without introducing a new attribute, 
new extension, etc.
I would avoid constructs that put an arbitrary set of attributes into 
this extension, though, if calling the result a DN would be a 
misnomer. Also, I'm not a big fan of putting in multiple 
SubjectAltNames. Doing so causes added complexity in applying the 
NameConstraints extension and it imposes burdens on CAs to verify 
identity information from a wider range of name spaces.  However, for 
purposes of solving the problem that started this thread, I think we 
have a solution.

Finally, Anders, this does nothing to address your more recent desire 
to impose the concept of a naming domain on DNs.  Since DNs exist in 
the context of a DIT, which establishes naming domains via hierarchic 
refinement (the same way the DNS does), I suspect that what you are 
asking for here is not consistent with the use of a DN anyway.  Maybe 
we're back at the "have your cake and eat it too" stage for this 
issue.

Steve