Ned Freed writes:
If I read the document correctly, it says "Don't accept the Public
Key/ID-Subset association at face value." The PEM-MIME document goes on to
say
(page 17 again):
"... It is incumbent upon a recipient to verify the authenticity and
accuracy
of the data received prior to its use."
I agree with all this but ask "Why bother transferring the public key with
the
name form if that public key is not to be trusted?" Doesn't this provide
the
unsuspecting user with the opportunity to make a SERIOUS error?
Sure, and that's why the warning is in there. Just because a public key is
present and happens to verify doesn't mean that the particular public key in
question is good for anything at all. You may require that it be a particular
key to be valid. Or that it validate along a particular certificate path. Or
whatever. This is equally true under classic PEM.
Instead, why not require the key/name form to be transmitted separately and
validated before use. Please don't say this is an implementation issue.
Sure, but how many of your users are going to read that document and understand
this point? They're going to assume that MIME-PEM is acting reasonably on
theirbehalf. Allowing INCORRECT name/key associations to be treansmitted is
not
reasonablhavior (IMHO).
It is actually less of an implementation than a policy issue. An
implementation
is only required to verify and present the result of that verification. The
interpretation of that result is a matter of local policy.
If a sender (and recipeint) wanted to send the key/name form association
along
with a signed message then could this be accomplished with another
Content-Type
within the same multipart message? This way, sender and receiver take
conscious steps when using an unvalidated public key.
It certainly can be done this way, and I expect that it will be done this way
in some cases.
I have a similar question regarding use of certificates. In Classic PEM,
the
originator certificate and cert chain was transmitted along with the signed
(and optionally encrypted) message.
Incorrect. It can be transmitted this way in classic PEM. However, doing so
was
optional, and in practice it often wasn't done this way. (This is assuming
that
the few messages I've seen in classic PEM represent any sort of viable sample
of how issuer-certificate fields are used, of course.)
One advantage of this was it enabled a
recipient to validate the certificate with information in the message.
That is,
the originator certificate and cert chain were there to be traversed and
evaluated. This is a nice feature for mobil users (with notebook pc's) who
want
to read secure e-mail while travelling. They need only the public key of
any
trusted root(s), their own private key, and the PEM software to do this.
Sure. But since there was no guarantee that the cert chain would be included,
this only worked part of the time. There are also cases when only a partial
chain was included. The specification allows for the inclusion of anything
from
no chain at all to a full chain to the root.
Based on the MIME-PEM document, the sender can specify an issuer name/serial
number identifier. Is it anticipated that the certchain will be transmitted
with this identifier or will it be retrieved from receiver's certificate
data
base?
To the best of my knowledge this works the same way as it does in classic PEM.
You can transmit the chain or leave it out, as you so desire and as usage
dictates. The only differences are that a separate bodypart
(application/pemkey-data) is used to transfer this information, and that a
specific means of requesting this information (application/pemkey-request) is
provided. This allows for the request and transmission of just a certificate
chain and nothing else, which can be quite useful.
For mobil users, access to a non-local cert data base is problematic. It
means that every signed message must be evaluated before disconnecting from
the
certificate data base or certificates are maintained locally (bad idea
IMHO).
How is this addressed in MIME-PEM?
See above. It is slightly more flexible than classic PEM in this regard, but
the services are basically the same.
Ned
OK. It's an option in Classic PEM. How will that option be exposed in
MIME-PEM? A good way to address this might be to take the example PEM messages
on pages 21 and 23 (in my copy) of rfc1421 and map them to MIME-PEM and post
THOSE examples. That would help translate the functionality offered by rfc1421
to that offered by MIME-PEM. Anyone else agree?
BTW, thanks for the prompt responses.
Phil Smiley