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.
The idea of this huge installed base immediately showing up and calcifying
beyond the point of change is, I think, simultaneously way too optimistic and
way too pessimistic. MIME/PEM will either succeed or fail. If it succeeds it
will be because of flexilibility in the user community that allows for the easy
addition of new services. This bodes well for the v3 cert structure, especially
if it addresses limitations that widespread deployment highlights.
But suppose MIME/PEM fails for some reason, and classic PEM does not. In this
scenario your v3 cert work goes down the toilet because of its coupling with
MIME/PEM. Do you really want this to be possible?
A much more likely possibility is that MIME/PEM implementations will come out
slowly but steadily and will be slowly but steadily adopted. And when v3 certs
are ready to go they will slowly and steadily be subsumed into the
infrastructure.
Frankly, I think your bigger problem here is going to be getting the v3 certs
into X.500. X.500-1992 stuff is moving along slightly quicker than deployment of
X.400-1988 did in its day, but only slightly. This does not bode well for
v3 cert support, and I doubt if there's anything we can do about this.
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.
This actually has two effects:
(1) You can't depend on the ISO docs to define things for you. As such, you
are going to need your own specs. And I'm sorry but the idea of simply
blowing out a bunch of ASN.1 followed by a couple of paragraphs is NOT
going to fly. Its going to require more work than this, if previous
IETF work along these lines is any indication.
(2) You are going to have to justify your choice in not waiting for the ISO
work. I don't think this will be hard to do given current IETF sentiments,
but it needs to be done in any case.
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 said before, I have no problem with a parallel document coming out ASAP.
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?),
Well, this depends on how long it takes to finish MIME/PEM (asuming it ever
gets done). If we finish up this month and the IESG takes the usual amount
of time it will put MIME/PEM about 7 months behind classic PEM.
It is not beyond possibility, that a separate document that specifies v3 cert
formats could beat MIME/PEM through the process!
I assume that it will
take more work to revise it.
Depends. And once again this is why a new document is so attractive. Assuming
there are no problems with RFC1422, it can proceed independently to draft and
full standard, which the v3 cert stuff that revises it following along behind.
If you try to combine them, on the other hand, you reset the process to the
beginning.
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.)
The first part of this sounds fine to me.
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?
No. I oppose the inclusion of the v3 cert material in the MIME/PEM spec. There
is some justification in the criticism that the MIME/PEM specification does too
much already.
I would much prefer to get the revision of RFC1422 done NOW, either as an
addendum or as an updated document, and get it started through the process.
This can be done independent of MIME/PEM. If they both succeed then great. If
only one does, well, that's OK too. And who cares what form they're in if they
both fail?
Ned