Following is my response to Bob's latest private message on this subject which
Bob received too late to incorporate into the summary he posted to pem-dev.
---forwarded-message---->
1995 Jan 18 at 10:36
to: Jueneman(_at_)gte(_dot_)com (BNR400)
copies to: amanda(_at_)intercon(_dot_)com (BNR400)
subject: Re: Are we a standards committee?
Bob:
I should clarify what I was saying re DNs and "identifier". I realize the
problems which existed with v1/v2 certificates - about the only useful field
was
DN so all sorts of semantics needed to be squeezed into it to make the
certificate useful.
However, I am now talking about v3 where we have some extra fields. A very
important one for this discussion is subjectDirectoryAttributes, which allows
any X.500 attributes of the subject (as chosen by the CA) to be carried in the
certificate, separate to the DN. What the CA is now doing is binding together
the public key, the DN, and the attributes.
This allows us to stop trying to attach semantics to the DN. The DN is now
simply a directory entry name in the sense X.500 always intended, i.e., it
identifies the subject's directory entry. The internal structure of the DN
will
be influenced by such factors as name space administration, but not by anything
to do with CAs.
The CA comes into it by selecting a set of attribute values to bind to that
name
(e.g., organizational role, postal address, whatever). There is no requirement
that these attributes also be in the directory entry, although that will
probably frequently occur.
Using the DN to support nameSpace constraint and nameSubordination provides
added options which may prove useful to CAs. The nameSpace constraint allows a
CA which certifies another CA to specify the set of names for which the subject
CA can issue certificates. This can be any set of (possibly chopped) DIT
subtree specifications, i.e., it can describe any arbitrary set of pieces of
the
DIT. The nameSubordination constraint may prove useful in many scenarios,
depending upon the naming approach used in the part of the DIT involved.
Any CA can specify nameSpace and/or nameSubordination constraints in its
CA-certificates. There is no need for RFC 1422 to specify any particular
"rules" - just to state that these optional extensions should be supported.
BTW, the v3 system obviates the need for the strict IPRA-PCA-CA structure - any
CA in a chain can stipulate policy restrictions to apply to the chain.
I shall be posting the ISO PDAM text tomorrow; sorry for the delay but I want
to be sure any last-minute comments from the review team are included.
Warwick