RE: encryption in XML & in SMIME

> 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

> 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