RE: encryption in XML & in SMIME

I don't quite understand the issue being raised here.

CMS is derrived from PKCS#7, not the other way round.

I don't believe that not signing the list of encrypted message
recipients is a security flaw in PKCS#7.

Encryption is intrinsically a confidentiality service. A
single 'message' may be encrypted and decrypted and re-encrypted
repeatedly as it is processed. It is entirely appropriate that
the encryption wrapper change at each and every stage.

What is inappropriate is for a recipient to rely upon as
trustworthy any information that is outside the signature
envelope. If information needs to be signed in CMS it can
always be added as an additional signed attribute.

In the case of a one step exchange this may mean that the
recipient information occurs twice. That is not exactly
a disaster.

I really do not see that Sign (Encrypt (Sign ())) does anything
usefull at all - in CMS, PKCS#7 or any other spec. If you
want data to be trustworthy put it inside the signature
envelope.

As a practical matter Encrypt (Sign (X)) is most likely to be
useful in multi step message processing.


		Phill

> -----Original Message-----
> From: Don Davis [mailto:don.davis@systemexperts.com]
> Sent: Thursday, August 31, 2000 9:35 PM
> To: Philip Hallam-Baker
> Cc: xml-encryption@w3.org
> Subject: RE: encryption in XML & in SMIME
>
>
> > With S/MIME there is a structural problem that only a part
> > of the mail message is actually signed. Not only is there
> > possibly important but unsigned information in the To: field,
> > but the subject field is also unsigned (and unencrypted).
>
> hi, dr. hallam-baker --
>
> i agree that s/mime could have solved the problem i describe
> by requiring that the "To" & "From" lines be signed.  but,
> that solution wouldn't help pkcs#7,  which inherits the sign
> & encrypt defect from the cms spec.  similarly, signing an
> naming header won't apply, when XML application developers
> want to use naïve sign & encrypt to prepare secure XML documents.
>
> though s/mime could have fixed this problem by signing an smtp-
> style header (& without resorting to the fixes i've described),
> your recharacterization of the problem doesn't help us under-
> stand or fix cms/pkcs#7's basic sign/encrypt problem, where no
> standard naming header is available.  of course, a pkcs#7
> application is free to include a naming header in the body, but
> basic out-of-the-box pkcs#7 sign & encrypt is as insecure as
> s/mime's sign & encrypt.
>
> > it is a problem with the S/MIME spec rather than the structural
> > CMS issue suggested. S/MIME provides good payload security but
> > as with PGP the integration to the SMTP message transport is
> > lousy.
>
> i'm sorry, but i disagree.  cms (s/mime's & pkcs#7's payload
> security) does provide sound signatures, but cms' encryption
> doesn't tell the s/mime recipient anything about who has seen
> the message, even when the author's signature is present.  in
> fact, the message-bodies you cite below as "broken" are perfectly
> compliant cms/pkcs#7 documents:
>
> > The problem comes with
> >   From:    alice
> >   Subject: hello
> >   Body:    Encrypt ( Bob, Sign (Alice,  "Body: Hello world"))
> > and the different but equally broken
> >   From:    alice
> >   Subject: hello
> >   Body:    Sign ( Alice, Encrypt (Bob,  "Body: Hello world"))
>
> the problem here is that naïve "sign & encrypt" is not by itself
> a strong security primitive, though it is often seen as such.
> i'm emphasizing this point here on the XML-Enc list, because
> i'm hoping this WG, when it's formed, won't repeat cms' mistake.
>
> btw, thanks for mentioning that s/mime should be encrypting the
> subject line for private messages;  i never noticed this defect,
> when i analyzed the spec.
>
> 					- don davis, boston
>
>
>
>
> -
>
>