I have not tried the new TIS/MIME/PEM, in part because the problems I had in
installing the trying to use the previous implementation. I'm glad to hear
your
reaction, however, and will try to find the time to try it again.
I had no problems at all installing it on UNIX systems. I only had problems
using it, and as far as I could tell they were the result of the complexity
of the cert structure rather than anything that would be specific to one
implementation or another.
However, this very reaction tends to underscore my feeling that it may not
have
been PEM that failed to win acceptance, but rather the particular reference
implementation. That's admittedly an over-simplification -- I'm not trying to
deny the complexity in setting up the traditional style of DNs and
hierarchical
certificates, especially when at a time there were a lot of growing pains in
setting up the PCAs and CAs. But I don't think that was the only reason.
Probably not. But that's why comparing with the new version of the same
implementation is so telling.
Now, I could be wrong about this. But allow me to point out that this whole
self-signed cert business is a new solution that has only recently been
proposed. If we're to run with it we're going to have to make some changes
to
the RFC1422 model. (It may not be a divorce, but its at least a trial
separation.) Without these changes MIME/PEM doesn't even allow self-signed
certificates. And since this is exactly what is being proposed, I don't
see that your needs are met by this proposal either.
You may have a valid point here, at least from the standpoint of the RFCs.
Although Jim and Steve Crocker have described their implementation of
self-signed certificates, it is clear that was an implementation extension
beyond RFC1422. Whether those RFCs PROHIBIT such usage is a different
question.
I don't think so, but it is worth a look. I'll certainly grant that they don't
support or describe such an approach, but I think that was considered a "local
matter".
As a matter of fact RFC1422 is quite clear on this point -- it states that the
cert chain must trace all the way to the PCA root. Paragraph 4 of Section 2
makes this clear in the case of selecting a recipient public key for
encryption, and paragraph 6 makes it clear in the case of signature validation.
The requirement that RFC1422 be used is less clear. In fact RFC1421 goes
out of its way to say that RFC1422 should be used if you want things to
interoperate. It could have said "must be used". I suspect this loophole
exists because of the support for symmetric systems.
From this I conclude that self-signed certs are not allowed if you use the cert
mechanisms of RFC1422.
Unless such usage is specifically prohibited (and I doubt that it was, or
Steve
and JIm wouldn't have implemented it, or at least would have screamed),
TIS didn't implement it, at least not in any useful or obvious way.
I don't
see why you would say that MIME/PEM wouldn't allow it. The concept of keeping
some features while discarding others in 1422 doesn't seem to have constrained
you from offering other forms of certification, so this should really be
pretty
much of a non-issue.
I have no problem with discarding features of RFC1422. It is your position
that doing so may weaken things to the point of unusability. My only point
here is that you can't stick with this position and have self-signed
certs as well.
Ned