Bob certainly doesnt understand that v2 and v3 certificates *are*
wholly permitted (at ISO/ITU ratification time) in PEM.
RFC 1422 permits v3 certificates, without change, once the ISO process
terminates.
3.3.1 Version Number
The version number field is intended to facilitate orderly changes in
certificate formats over time. The initial version number for
certificates used in PEM is the X.509 default which has a value of
zero (0), indicating the 1988 version. PEM implementations are
encouraged to accept later versions as they are endorsed by
CCITT/ISO.
I'm going to download the latest RFC. Perhaps my memory has failed again, or
maybe the changes were inserted during the standards upgrade phase while I want
looking. But I'll assume that the quotation is accurate, and that later
persions are permitted, even encouraged.
Nonetheless, I think that more than just recognition of v3 is required. At a
minimum we have to specify what happens if a v3 certificate is received by an
implementation capable of v1. Should it just refuse to interact at all? Should
there be some sort of a request made for a v1 certificate? Should all CAs issue
both v1 and v3 certificates? Should both forms be included in messages, and
posted in Directories? For how long a time? Is timeToNextUpdate optional or
not, for PEM purposes?
It seems quite likely that we will want to change the semantics of what is
included in a DN, making that much more of a simple pointer back to the
Directory (as it was probably meant to be originally) and put the identity
information in extension attributes. Now, what does such a mix of semantics do
to the Directory schema, if both v1 and v3 has to be accomodated?
In short, I believe that a mix of v1 and v3 certificates in fielded systems
would cause significant confusion and other problems. Since it seeems unlikely
that thousands of PEM v1 implementations are in operation, maybe we should
consider trying to upgrade the spec and the implementations all at once.
Normally, this would be a bad idea in already fielded systems. But incompatible
legacy systems are also not much fun to try to support.
We should also consider how many non-PEM X.509 implmentations there might be in
existance (if any), and to what extent any compatibility issues might exist.
I'm not drawing a final conclusion yet, but we need to think through these
issues based on more than just standards politicing. It isn't the direction
that I am questioning, just the time frame. should be push hard to get the
basic v3 format implemented immediately, including tyhe use of existing
attributes as extensions but no new paradigms for hierarchies, etc., or should
we try to think through all of these issues and revise the spec only once? It
isn't clear to me, at least not yet.
3.3.5 Issuer Name
A certificate provides a representation of its issuer's identity, in
the form of a Distinguished Name. The issuer identification is used
to select the appropriate issuer public component to employ in
performing certificate validation. (If an issuer (CA) is certified
by multiple PCAs, then the issuer DN does not uniquely identify the
public component used to sign the certificate. In such circumstances
it may be necessary to attempt certificate validation using multiple
public components, from certificates held by the issuer under
different PCAs. If the 1992 version of a certificate is employed,
the issuer may employ distinct issuer UIDs in the certificates it
issues, to further facilitate selection of the right issuer public
component.)
Perhaps I misunderstood the question. I was concerned about the situation where
a user can legitimately be certified under two hierarchies, regardless of the
number of CAs involved. Presumably if he is certified by two CAs, he has two
unique certificates. Does he have to sign everything twice in this case to
indicate that he is conforming to both policies simultaneously? (Yes.)
Bob
--------------------------------
Robert R. Jueneman
GTE Laboratories
40 Sylvan Road
Waltham, MA 02254
FAX: 1-617-466-2603
Voice: 1-617-466-2820