I think that it is one thing to cite a standard such as X.509 which contains a
specific version, but something else to cite RFC1421/23 for the definitions
and
semantics. X.509 v1 isn't going to change, but RFC1422 might, leaving the
certificate format for PEM/MIME iomplementations somewhat ambiguous.
I think you have this exactly backwards. RFC1422 isn't going to change. RFCs
never do. They can be obsoleted by other RFCs, in which case it is up to the
replacement RFC to deal with any and all RFC refernences to the obsoleted
specification. And the replacement will be reviewed for consistency, accuracy,
and lack of ambiguity. As such, this provides us with a way to control quite
precisely how things work in PEM. There is no reason for any of this to
be ambiguous in any way.
Direct references to outside standards, on the other hand, have no flexibility
at all. It is not reasonable for us to expect (nor would the IETF recognize it)
outside standards to update foreign documents that happen to reference them.
Referencing outside certificate specifications in this way in both PEM and
MIME/PEM means that both will have to be updated when any changes are made.
This opens the door to ambiguity a heck of a lot wider than the current
approach.
If it were only a difference in a data template it might not make much
difference. But supporting the CRITICAL extensions requires support in the
code, not just a recompilation somewhere down the line, and I think that it is
VERY important to get that functionality included at this juncture. (I
understand that versions that do not support v3 should reject the entire
certificate, whether or not they udnerstand certain extensions. But that will
just make it much harder to add support later on, since most implementations
won't support it. In partiuclar, it will make it impossible to add optional,
non-critical extensions on an incremental basis.
Well, as I said before, you cannot get there from here. The v3 certificate
specification is in draft. Substantantive references to it are therefore not
allowed in any standards-track document.
I realize that Warwick has assured us that these extensions will be adopted in
a timely fashion, and I hope he's right about this, but all the assurances in
the world will not change the rules we have to abide by. As such, we are back
to the same two choices I described earlier: (1) Wait. (2) Describe the v3
certificate format ourselves and hope like hell it doesn't change before
standardization is completed.
Since citing RFC1422 would probably have the effect of making it much harder
to
get v3 adopted, I think that if we want to move forward on the standards track
(several years after the orignal v1 was adopted for PEM), we should explicitly
specify the appropriate ASN.1 encodings, etc. for v3 in the PEM/MIME spec
itself at this time.
I have no problem at all with doing this. I have a major problem, however, with
holding up MIME/PEM while this is done. Writing and approving the prose that
specifies the V3 certificate structure and how it is to be used in PEM and
MIME/PEM is going to take some time. In fact, given the speed at which this
Working Group has operated in the past (most glaciers are faster), its only
fair to say that I think there's a good chance that the new X.509 will be
approved before we can get the documents out as an RFC. You may take issue with
this characterization. However, the best way to prove me wrong is, by applying
your writing talents to the construction of new specifications rather than to
to requesting lots of additions to old ones.
This again brings us back to the approach I originally suggested when you first
brought this up: If you think the V3 certificate format is so important, then
by all means write a specification for it that updates RFC1422 as well as
updating the MIME/PEM specification's references to RFC1422. There should be no
need to actually update any of the content of MIME/PEM at all to deal with
this. If you're fast you can get this in front of the Working Group before the
area director shuts it down. If not, well, don't say I didn't warn you!
It is not reasonable to expect the authors of MIME/PEM to do all this for you.
It is not within the present scope of the MIME/PEM work, nor should it be
brought into this scope during last call. Focus is the key here, not
expansion of old efforts into new areas.
Ned