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?
I have asked the same question. If the recipient already has a
certificate or other binding for the name and key, there is no need
for all that information. And if the recipient doesn't already have a
binding, then the recipient must process the Originator-ID as an
implicit certification request. It seems inappropriate to me to put a
certification request in the Originator-ID for a regular message.
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.
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 makes sense to me to move this information - specifically, to move
it to the application/pemkey-data Content-Type. This body part
already defines explicit (rather than ambiguous and implicit)
mechanisms for establishing and transmitting name/key bindings. This
is also where X.509 certificates are carried (as they were in
Originator-Certificate and Issuer-Certificate fields in RFC 1421).
- Jeff