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.
All right, I stand corrected. Having not been directly involved in the
writing/editing of the RFCs, I was not sure exactly when an RFC becomes frozen,
or what the process is to update/replace them.
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.
I certainly agree. But we didn't rewrite the specs for ASN.1, or IA5, etc.,
etc., and yet some of those standards have changed since the first PEM RFC. I'm
not quibbling, but I am not familiar with the process through which the IETF
harmonizes its work with ANSI, ISO, etc. (Someone who knows can educate me
privately, rather than waste more bandwidth if most of the rest of the people
on this list are more up to speed on this than I am.)
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.
The "outside" certificate specification (ISO/ITU X.5-09 version 1) is currently
specified by reference, if I understand Mark correctly. As I recall, not having
the RFC in front of me at home, the format is also described in the RFC, so
there is essentially a dual specification.
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.
In the past, it was the ISO/ITU spec that changed to conform to PEM, so there
is some history of accommodation between the two efforts. But I understand your
point from a formal, mechanistic standpoint.
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!
That's fair enough. Perhaps I wasn't listening carefully enough, but I hadn't
really heard those words of approval-in-spirit from you, or from Jim, and there
wasn't much point at all in pursuing such a track if some of the key
implementors were ultimately going to take a position of "Not only no, but hell
no." If you and Amanda, at least, are now on record as being in favor of such a
change (or at least not adamantly opposed), then I will take on the job of
trying to make the appropriate revisions.
Maybe I can get some help from Warwick and Mark (please, guys?), or at least
some moral support and guidance as to how to shepard such changes through the
IETF processes. The specification of the format itself should require a minimal
effort. Specifying some of the finer points may require the involvement of the
IANA. Working out the details of "how it is to be used in PEM and PEM/MIME"
will probably require substantially more effort, in particular if we consider
some of the new approaches to certification authority chain management that the
new certificate format will support. But I view the adoption of the bare-bones
format as the first and more important issue, since it potentially impacts a
lot of other infrastructure -- in particular certificate generation and
certification. Implementing the various new features can come later.
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.
Well, I might disagree slightly there, but only slightly. To the extent that
essentially all work stopped on classic PEM while people went off in a
significantly different direction (my words, not necessarily yours), then I
think it might have been reasonable to incorporate such changes. The ball has
essentially been in your court for the last year, and the rest of us have been
waiting for the ink to dry on the final result. However, I will concede that
Warwick's work was in a different venue, and it might have been asking too much
for you guys to keep up with everything.
In any case, I definitely AM trying to focus, and to move the ball forward, and
I agree that holding everything in abeyance while we debate and wrangle about
the finer points of X.509 v3 and how it shuuld be implemented and interpreted
would not help the cause that we are all presumably working toward. But I
assume that moving PEM/MIME forward on as a proposed standard does not preclude
that kind of mid-course correction.
Bob
--------------------------------
Robert R. Jueneman
GTE Laboratories
40 Sylvan Road
Waltham, MA 02254
FAX: 1-617-466-2603
Voice: 1-617-466-2820