If someone sends you his key without any kind of a certificate, then
YOU are responsible for binding the claimed identity or other information
to that public key.
Correct. We just disagree about whether or not this is desirable or not.
Forget business communication for a moment--anything with legal implications
clearly has a use for certificates, just as it does currently for physical
forms of ID (in fact, one of the interesting services the USPS says it will
offer is a biometrically assured certificate--much higher assurance than
any PCA currently operating...).
However, part of what Ned and I have been trying to get across is that the
assumptions that hold for business and legal communication do not necessarily
hold for other uses of security services. I'll bring up my example of
sending secure email to my mom; other examples might be someone sending
mail to their therapist, spiritual advisor, etc. In these cases, direct
key exchange is easier, of higher assurance, and more emotionally satisfying
than using certificates. It doesn't matter so much whether or not you *can*
do equivalent things with self-signed certificates, as whether or not people
will be willing to do them that way. I'd rather let my users decide--I may
try to educate them as much as possible, but I've found that restricting
their options "for their own good" just makes them annoyed and buy other
peoples' products :)...
Well, that's a good question. Of course, classic PEM includes some support for
symmetric key operation, and somewhere there might even be someone who thinks
that is worthwhile. :-)
I do, in fact. I was annoyed to see symmetric key management drop out of
MIME/PEM, but I figure that uncertified key exchange and key selectors will
serve most of the same purpose, with greater economy of mechanism.
Ned and Jim
having been extremely dogmatic about the general un-workability of the
certificate structure, the difficult of getting it started, etc.
So what? They didn't put up any roadblocks to its use. It's not as though
Jim or Ned's skepticism will have any effect on the deployment of CA
infastructure or lack thereof. I am not as concerned with anyone's private
opinions as I am the document itself. No one's saying you have to
disbelieve in certification to implement MIME/PEM :).
My concern continues to be whether
the IETF, in giving the current RFC the imprimature of a Proposed Standard,
Draft Standard, or Standard, eventually, would end up disrupting other efforts
along these lines and compromise the emerging public-key infrastructure and a
potentially enormous suite of compatible applications.
Hmm. I must admit having few worries along these lines.
The edge may be blunted and nicked a little, but who would you claim is moving
more rapidly towards a concensus in this area?
I don't know. We seem to be about at the same point we were a month ago.
I don't think so. The issues of what makes up a "good" distinguished name are
still going to be with us, as Ned's message illustrates. Just becasue the Post
Office is willing to act as a PCA or CA won't relieve the lawyer's from
arguing
over who has the right to use a given name, and what the implications are of
identifying a user as an organizational person. and based on the discussions
within the NADF, I think they are as confused as anyone as to how to deal with
the issue of residential persons and some of the questions of privacy that
have
arisen. I haven't seen any schema described for their X.500 directory yet (if
they intend to offer X.500).
For all that this is true, I think it is irrelevant to MIME/PEM. This is
getting back into policy and the semantics of signatures and certificates.
I would be happy to help work on such issues, but AFTER we nail down how to
represent secure MIME messages and body parts.
but I'm not conceding the playing field quite yet.
They're building a PCA. They are getting ready to issue certificates.
At least they're *on* the field, as you put it :).
Amanda Walker
InterCon Systems Corporation