Now let me ask the question I really intended to ask. Assuming that
we upgrade to v3, perhaps in six months or so after the ISO spec is
firmed up, and perhaps after we have had a chance to consider how best
to take advantage of it, will your _implementation_, and presumably
any other PEM/MIME implementation, be in a position to implement v3?
I don't see why not. Certificate management is not specific to PEM/MIME, but
is a general PEM issue. I can't speak for Jim's implementation, of course,
but I certainly expect us to support v3 in products that deal with
certificates. It's a clear improvement over the status quo, and I can't
imagine anyone doing certificate management and *not* wanting to support it.
In part, this is a question as to whether the interface between the
PEM/MIME layer and the 1422 layer is designed to pass the
additional extensions. I am particularly concerned about the
correct handling of the CRITICAL extensions.
Since PEM/MIME doesn't interpret the certificate, any other interested layers
get to look at whatever certificate is in the message. This is one of the
advantages of separating certification policy from representation. What
layers get which data seems to me to be strictly a matter of implementation.
This morning I was trying to think of some socially redeeming uses :-)
of a bare key, and I thought of one possible example.
The general class of such uses is basically cases where you want to avoid non-
repudiation. This may sound like a non sequitur, but there are a great many
times when you want secure, authenticated communication but do not want the
messages themselves to be self-authenticating. Your abortion doctor scenario
is one example; there are less contrived ones I can think of, though.
Let us say that you sign an NDA with us, under which we will provide you with
confidential technical information. To save on FedEx costs, we want to do
this in email. To do so, we give you (via FedEx, courier, or some other
delivery vehicle) a public key which we assert will be used for communications
under the aegis of that NDA. This allows you to decrypt and authenticate
email from us, without allowing you to leak it to MacWeek in a way that lets
*them* also authenticate the source. They can claim it to the same degree
they can today, but they can't present information that is unambiguously
signed by us. In short, it provides confidentiality and authentication to
particular parties while also providing repudiation (or at least plausible
deniabilty :)) to third parties or observers.
Some manual operations will of course be necessary, since you are substituting
out of band mechanisms for automated certification, but at least a common
representation lets software present a reasonable UI for such operations.
Amanda Walker
InterCon Systems Corporation