Now, as to the matter of conforming implementations being required to support
v3 certs. This simply is NOT the case.
RFC1422 permits the acceptance of later versions (section 3.3.1) of X.409.
[sic -- X.509, presumably]
However, there is absolutely no requirement I can find anywhere that support
for later versions ever be implemented by anyone. In fact the document goes
out
of its way to specify the one version that you have to support (X.509-1988).
This is one case where I agree with Ned. The issue came up with version 2, and
it was decided at that time to postpone consideration of the updated standard
until an "appropriate" time.
It is a matter of policy that RFCs specify particular services whose forms are
controlled by the IETF process. Specifying services whose form is defined
externally is fine, as long as change control resides with the IETF and no
longer with the external definer. As such, we can specify that X.509-1988 or
X.509-1992 or whatever be used, but we cannot specify that "whatever the
ISO/ITU/whoever decides in the fullness of time" must be supported.
Agreed. This "automatic" update might be tolerable within a fairly carefully
controlled suite of protocols such as X.400, X.500, etc., but would be
problematic even there. It would lead to too much instability, IMHO, for this
notion to be applied across more distant standards efforts. Instead of
encouraging standardization, the probably result would be for every group such
as ours to uniquely specify their own version of an alomst identical standard,
but with subtle differences.
So much for mandatory support of v3 certs in RFC1422. You can use them if
you want to, but it is possible to have an entirely conforming implementation
without them. This will not change until a standards-track document comes
along and says otherwise.
Since RFC 1422 specifically says that the version is version 1, I'm not even
sure that this is true. The appropriate thing to do is to revise or replace
1422.
As the 1992 procedures are amended by defect, the proecedures for
implementations conformantly handling the syntax are well specified, as
per your contributions on criticality handling to this list. for the
purposes of 1422 which limits itself to issue of certificate attribute
syntax, I also find the discussion of X.500 conformance, and attribute
type OIDs not relevant, or even necessarily correct. it can be ignored,
here.
I agree that the OID discussion is not relevant to any of this.
I brought up the OID discussion when the timelines for the ISO standard being
adopted were not quite so clear, in hopes that we could move forward more
quickly, doing exactly what I compalined about above, i.e., creating an "almost
identical" varient of the ISO version for PME, then catching up later.
However, There is scope for further work to 1422, whereby the 1422
procedures might make use of the std extensions. 1422 is "poor"
currently, in that it suggests use of the issuerUniqueIdentifier as a
qualifier for identitying the parent-CA key to be used to validate a CA
certificate. A defect to 1422 needs to be issued to change or facilitate
better
handling of 1992 certificates to utilise the new standard extensions
which specifically have the function of solving the issue of a single CA
certificate being signed by multiple PCAs. The exploitation of a specific
syntactic and semantic contruct whose function it is to allow
originator selection between the available authentication channels
does extend 1422 certificate chain handling. I see this as a fallout of the
defect process, rather than a flaw of 1422.
There is certainly work that could be done along these lines, in particular to
remove the rather onerous requirement for name subordination and replacement
with an exp[licit indication of the PCA-CA-user chain.
The question of a single CA certificate being signed by multiple PCAs, or a
single user being signed by multiple CAs, I find more problematic. This will
take a lot more discussion.
The IETF doesn't do defect work the same way that ISO/ITU does. These
things can be handled in three ways in the IETF process:
(1) Revise the specification and reissue it on the standards track.
(2) Write a standards-track amendment to the specification.
(3) Write an applicability statement that describes the change.
The difference betwen (2) and (3) are subtle but important, but in this
case the proposed standard status of RFC1422 probably precludes using an
AS in any case.
An informational RFC is required only, specifying the use of the std
extension, as a defect, and exampling how multiple CA key sets and
multiple CA certificates for the same key cam be used to select a
unique authenication channel despite a CA being within multiple PCA
domains.
Such a document has no status whatsoever, and is therefore meaningless. For
example, I could issue an informational document that amended RFC1422 so that
all ASN.1 for certs had to be coded in reverse. Would you implement it?
If we were only going to upgrade the version number to permit v3, perhaps
clarify the optional or nonoptional status of nextUpdateDate, and discuss the
implementation of the critical flag, a standards track amendment would be the
way to go.
But my sense is that it is time for some more extensive revisions, including
updating the certificate chain to stop at one or more trusted root keys,
instead of the PCA or IPRA necessarily, the PCA-CA-user hierarchy, and probably
a number of other extensions.
I would actively support such an revision effort, and suggest that we do
whatever is necessary to charter a work group to address this issue.
--------------------------------
Robert R. Jueneman
GTE Laboratories
40 Sylvan Road
Waltham, MA 02254
FAX: 1-617-466-2603
Voice: 1-617-466-2820