- From: Don Davis <dtd@world.std.com>
- Date: Fri, 1 Sep 2000 19:49:43 -0500
- To: Philip Hallam-Baker <pbaker@verisign.com>
- Cc: xml-encryption@w3.org
> CMS is derrived from PKCS#7, not the other way round. hi, dr. hallam-baker -- please forgive my mistake. i first encountered the cms RFC as part of the s/mime suite, and i looked at pkcs#7 only later. i was careless not to have read up on the history, or at least to have checked the dates. > I don't believe that not signing the list of encrypted > message recipients is a security flaw in PKCS#7. the problem is that for human-signed, human-readable encrypted documents, not signing a To-list makes the encryption step meaningless to the recipient. a PKI- savvy recipient concludes that someone else could have received, read, and re-encrypted the message, while a security-naïve recipient concludes incorrectly that noone else could have seen the plaintext. so, know- ledgeable recipients get no guarantee, and naïve recip- ients infer an incorrect guarantee. this is not a happy outcome, especially when it would have been easy to standardize a full & correct guarantee of security for signed & encrypted documents. it may be that automated message-processing has a use for sign & wrap, where the recipient doesn't care about the original sender's privacy intent. but, i think such utility is unlikely. i suggest that one can't trust the privacy of a decrypted plaintext, unless one knows who encrypted it. note the asymmetry: * when i send you a signed & wraspped msg, i know only you can read it, because i trust you not to divulge it, but -- * when you receive my signed & wrapped msg, you can't know how many hands it has passed through, even if you trust me to be careful. > If information needs to be signed in CMS it can > always be added as an additional signed attribute. it's not particularly useful that CMS only _allows_ correct behavior. CMS should have made it obligatory for applications to choose some way to authenticate the sender's To-list, or to guarantee to the recipient that he is the intended recipient. as it is, the net result is that the secure mail implementors didn't understand the problem, and wrote flawed s/mime mail clients, because the spec didn't tell them what the problem was, nor how to address the problem. what the CMS spec did tell them was "There are security ramifications to choosing whether to sign first or encrypt first." this is just a variant of your comment: > What is inappropriate is for a recipient to rely > upon as trustworthy any information that is outside > the signature envelope. my translation is, "this stuff is hard; we are trained professionals, do not try this at home." that answer made sense 10-15 years ago, but it surely doesn't make sense now. an s/mime recipient _has_to_ rely on insecure clues about who encrypted the message, because a vanilla s/mime implementation gives him no secure information about who encrypted it. the right answer here is for standards to make it as straightforward as possible for implementors to support users' security expectations. for business & commercial users, crypto and security have to be a turn-key affair. it's unrealistic to expect a financial-industry trader or a manufacturing executive not to overinterpret the security of a nominally "secure" message or document. these people have specialties of their own, and they don't have the time or inclination to learn about our specialty, just in order to communicate on the net. what's more, i'm seeing that even programmers who write "secure" applications don't understand such cryptographic nuances, and for the same reason: the programmers are concentrating on their application-area (finance, or mail- transport, etc), and don't have time to think hard about someone else's specialty. the programmers, like the trader and the executive, are correct. the programmers should be able to trust that if they implement the minimal recommendations of a "security standard," then their program will in some sense be secure. security standards should not assume that implementors will know where and how to supplement the minimal compliance requirements, in order to attain full and true security. > It is entirely appropriate that the encryption wrapper > change at each and every stage. ... I really do not see > that Sign (Encrypt (Sign ())) does anything useful at > all. ...As a practical matter Encrypt (Sign (X)) is most > likely to be useful in multi-step message processing. i agree that s/w/s is a klooge, and that it's wasteful for automated multistep processing. but, s/w/s has one virtue for user-to-user secure mail: CMS specifies that every s/mime mail client has to support such extra levels of nesting, so s/w/s can be received, processed, and interpreted by existing s/mime mail programs. this means that an s/mime product can send s/w/s messages without violating the s/mime spec, and without confusing other s/mime products. note that putting a To-list into a signed attribute, as you suggest, won't necessarily be comprehensible to other s/mime products, because CMS doesn't stipulate that such an attribute is mandatory. BTW, s/w/s does guarantee, even in the absence of a To-list, that the signer and the encryptor are the same person. so, even a naïve recipient can safely conclude that he is intended to be the recipient, and hence that no-one else but the sender has seen the plaintext. naïve recipients will of course assume this quite unconsciously, but expert recipients can conclude it confidently. and that's our goal; give users secure stuff, without getting underfoot. - don davis, boston -
Received on Friday, 1 September 2000 19:53:13 UTC