Re: Bug#40394: forwarding an encrypted PGP message is useless

[[e-mail] (Peter Gutmann)]

Sam Roberts <[e-mail]> writes:

>S/MIME only uses the signed and enveloped types from CMS, but RFC2630
>specifies authenticated as well. Its not well described there, but it is a
>way of "signing" something using a key agreement algorithm, such that the
>signature can ONLY be verified by using the sender or the receiver's
>private key.

Hmm, are you sure you're not interpreting a bit too much into this
data type?  The intent is to allow MAC'ing of data, and to do that you
need to share a key with the other side, which is why you need a key
exchange to precede it.  One of those happens to be X9.42.  There are
two issues with this:

1. The only implementation which is known to support X9.42 in any
   useful manner is the SFL.
2. There don't seem to be any implementations which support
   authenticatedData, or at least that was the case when I asked on 
   the S/MIME list a while back for someone to do some interop testing 
   with.

(Oh, and the obvious third point: If you're doing a PKC operation for
 the key exchange anyway, you may as well just sign the thing directly.
 At best, you can claim that this gives you a signature capability
 using an encryption-only key).

I've always seen the only real use for this data type as password-
based integrity protection for data you're carrying around, using in
conjunction with passwordRecipientInfo.

>What this gives you is repudiation. If I authenticate something to
>you, you know I authenticated it. But if you forward it somebody
>else, they can't verify the signature, they have no way of knowing
>for sure that I authenticated it, and I can deny it. Even if the
>recipients private key is compromised, they still can't prove
>that *I* authenticated it, since either one of us can create the
>"signature", all they know is one of us made the authenticated data.

Well, only if you use some of the obscure X9.42 options which don't
identify sender and receiver.  The default is to list both, although
there are a pile of optional parameters and with only one known
implementation who knows what will happen in real life.

Peter.