>With that in mind, the PEM/MIME document does not care which
>version of certificate is used. The certificate is one
>mechanism among a few that facilitates the
>validation/distribution of a public key, a process which is
>explicitly independent of the support of the security services.
>Thus, what is required is the exchange of public keys. If that
>happens via certificate, there may be interoperability issues,
>but that is outside the scope of this specification.
How should I interpret that statment with respect to the
CRITICAL flag for extextions in v3? Are you seem to be saying
that you will pick out the public key part of the certificate,
and ignore everything else?! Am I reading you correctly?
Bob,
Almost. Let me try to say it yet another way.
The management of the certificate is explicitly outside the scope of the
PEM/MIME specification. PEM/MIME specification does not care where the
public key came from. It is the user's responsibility to figure that
out.
If the key came from a certificate, then something must have validated
the certificate and something must make the public key in the
certificate available to a PEM/MIME implementation. If the something
does not understand v3 certificates, then I agree it should properly
fail. In any case, the version of certificate in deployment is not
relevant to the PEM/MIME specification. If and when certificates are
deployed for real, by X.500, it will be an issue for X.500.
Actually, except for the fact that certificates are more complex objects than
most other attributes (attribute values -- thank,s Mark), there will be little
or no impact on X.500 until X.500 starts doing strong authentication itself.
Implementations that compile, as oppose to interpret, the ASN.1 may have to be
recompiled. Likewise, there may be a slight impact on Directory User Agents.
but in general both the DSAs and the DUAs will treat the certificate just like
any other payload entry. It might as well be a package of fish.
I think we're in agreement, Bob. We're just trying to understand the
words we're each using.
Jim
Jim,
I am a little confused, perhaps because of your (legitimate) separation of
specification from implementation issues, and perhaps also by the degree to
which the spec is at least somewhat dependent upon the underlying 1422
mechanisms.
What I THINK you are saying, with respect to the PEM/MIME spec, is that you
don't care what is done to or with the certificate -- that that is the
responsibility of the underlying RFC1422 layer. "You", i.e., the upper(?) layer
of the PEM/MIME portion merely pick up the public key from the "1422" code, and
somehow find the private key, and proceed to do your thing. In the case of bare
keys, you skip the "1422" stuff, and proceed to manipulate the keys directly.
Is that approximately correct?
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? 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.
This morning I was trying to think of some socially redeeming uses :-) of a
bare key, and I thought of one possible example. It might be useful if you
could walk me through how this would be handled, both for the bare key and for
the certificate case.
Suppose that I am an abortion doctor, and extremely concerned about my safety.
My clinic is a fortress, and I don't even display my medical degrees, etc.
where my patients can see them. I am generally known by my patients and staff
by my alias or persona, Dr. X. Of course my professional collegues and
personal friends know me by my real name, but they generally don't know my
alias, where I work, etc.
Sometimes someone who meets me at the clinic wants to continue a social or
professional relationship, and they would like to know my e-mail address and
public key so they can send private e-mail to my "real" identity.
They drop a note to me asking for my real key or certificate and send it to me
encrypted (if necessary) in my Persona key which they already have, and include
their own key or certificate.
I am willing to disclose this information to them but not to the whole world,
so I send my real key or real certificate to them, encrypted in their public
key or certificate so as to avoid disclosing my real identity, and then sign it
using my Persona key to confirm the binding between the two identities, if
necessary. (Maybe I'm a spy or a mafia member, instead of a doctor.)
I'm assuming the PEM/MIME won't have any problem wrapping a certificate (or a
bare key and some identity information) in a security multipart, and then
encrypting that in the recipient's key, but could you walk me through all of
this would be unraveled by the recipient, and either the certificate or the
bare key and identity information neatly stashed away? Would this happen
automatically, or would a lot of manual processing be required?
Bob
--------------------------------
Robert R. Jueneman
GTE Laboratories
40 Sylvan Road
Waltham, MA 02254
FAX: 1-617-466-2603
Voice: 1-617-466-2820