Jueneman(_at_)gte(_dot_)com writes:
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.
Since X.509v3 has not yet been finalized, and the current proposal does not
address certification formats or policy, I'm not sure I see why it is so
important. That is, I understand why X.509v3 is important--I just don't see
why discussion or endorsement of it needs to be placed into the document
currently on the table.
I'm trying to be very success-oriented, and am assuming that PEM/MIME will sell
like hotcakes once the implementations start rolling out. Once that happens, of
course, those systems will become the legacy systems of the future, and we won't
be able to implement any new features or options, even noncritical ones, as
easily, because those implementations won't have implemented support for v3 and
will therefore reject it. New features would have to be introduced almost all at
once, instead of more gradually.
I don't feel that the lack of final, final finalization of v3 is really that
much of an issue. After all, the v1 CRL changed after the fact, because of
problems that we pointed out. In addition, if it is necessary we can specify the
format as a completely self-contained attribute with an IANA OID, and later,
when v3 has been ratified, then _surprise_ we change our OID to the standard and
everyone is happy. Or we leave the OID alone and support two otherwise identical
certificate formats.
I'm NOT trying to hold up the current spec until this gets done -- if I had only
one silver bullet I would probably reserve it for the key selector issue :-) --
but that assumes that we can make these kinds of rather minor editorial changes
while the spec is progressing along the standards track. As long as there is
agreement-in-principal along those lines, and ou and Ned, at least have
indicated your concurrence, I'm willing to go ahead on this issue on that basis.
As I understand it, since the current spec makes no mention of the certificate
format, the implication is that it is defined by RFC1422. Since RFC1422 is
already much further along the standards track (true?), I assume that it will
take more work to revise it.
Therefore, if we are going to revise 1422 at all, my preference would be to
decouple the two specs, and use the rewrite of 1422 as the place to incorporate
some of the more advanced concepts that we have discussed in the past but
deferred because of the impact on the certificate format, notably the
authentication chain idea that would remove the name subordination requirement,
and perhaps some other ideas that will occur when we see the proposed entension
attributes. But working out those revised certification mechanisms, convincing
ourselves that we are doing a good thing, updating the documents, etc. will take
time -- perhaps six months or even a year. We certainly wouldn't want to wait
that long before giving at least some guidance on the basic v3 issue to PEM/MIME
-- I'm hoping that within a year the PEM/MIME implementations will be
proliferating like crazy (at least if we can come to closure on the only
remaining issue on the table, the key selector/bare key issue.)
I'm therefore proposing a leap-frogging of the two standards. Update PEM/MIME to
include the bare-bones v3 format in an appendix -- without any extensions but
with support for the CRITICAL flag -- just as fast as we can write the text and
include it, either before or after it moves to standards track. Then take 6
months to a year to devise more sophisticated and powerful mechanisms to make
use of the v3 certificates, to be included in RFC1422. Finally, after those
issues are finally settled, we would come back to PEM/MIME with a set of agreed
upon mandatory extensions, both critical and non critical, and perhaps some
additional optional or recommended extensions, and revise the PEM/MIME RFC at
that time.
Does this seem like a workable plan to everyone?
Bob
Robert R. Jueneman
GTE Laboratories
40 Sylvan Road
Waltham, MA 02254
617/466-2820
Jueneman(_at_)GTE(_dot_)COM