contrary to that which Ned asserts, and ignoring all the associated
technical waffle, RFC 1422 already permits the 1992 certificate
attribute syntax, and therefore the v3 certificate once the technical
corrigenda is ratified. as, according to Galvin, MIME/PEM is equivalent
to Classic PEM, the procedures are also available to MIME/PEM
implementations, and must therefore be implemented by complete and conformatn
implementations - assuming the MIME/PEM I-D becomes an RFC soon, that is..
Obviously use of non-standard extensions in MIME/PEM and Classic PEM
profiled by market groups, is a choice of the business involved.
Well, for starters, I asserted nothing of the sort. I have never said a single
word on the issue of what RFC1422 does or doesn't requirement for its
underlying certificate formats. My comments in this context have been entirely
directed at the procedural issues that arise when you try to do IETF work
based on ISO standards, and where such work should be done.
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.
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).
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.
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.
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.
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.
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?
Ned