RE: encryption in XML & in SMIME

> To me the problem is not with XML nor XML crypto,
> but with the fact that email formats don't use XML.

mr. simon,

   i'm afraid i may have confused you.  the problem lies
neither in XML nor in XML crypto;  the problem is inherent
in PKI's combination of signatures with encryption.  since
the XML community wants to support this combination of PKI
crypto operations, the XML Encryption WG should walk more
carefully than the S/MIME drafters did.

> I would rather avoid using the terms "sender" and "recipient"
> because they are too email-centric.  I would rather go with
> "signer", "verifier", "encryptor", and "decryptor" when
> discussing XML Crypto.

   i agree that "sender/recipient" is not appropriate
for xml; i used them to describe my critique of s/mime,
where those terms are the right ones.  i have no interest
in using xml to prepare secure mail;  s/mime is an
accomplished fact, and trying to overturn it is not
my goal in writing to the xml-encryption list.

> Recognizing the applications where XML is intended to be
> used, the XML Signature WG has even made the <KeyInfo>
> element optional in XML Signatures...
> neither the XML Signature or XML Encryption specs should
> mandate that the signer/encryptor or decryptors/verifiers
> to be stated.

   i'm sorry to disagree with you, but you seem to be saying,
"this so-called security problem is unimportant, because
the purported fix isn't compatible with the way xml does
things."  such a "no compromise" policy will not serve xml's
users well.   the problem i describe arises wherever:

   * signing and public-key encryption are used together,
     and
   * the plaintext document fails to name the signer or
     the intended decryptor.

if, when signing & encrypting are to be used together,
neither XML Signature nor XML Encryption mandates any naming,
then compliant applications will be free to prepare insecure
XML documents, and XML's security extensions will be rendered
impotent.  it's possible to avoid the problem i've described,
without specifying names for all signatures and for all
ciphertexts.  whenever signing and encrypting are to be used
together on a single document, at least one name should be
provided:

   * when signing first, the decryptor's name should
     appear under the signature;
   * when encrypting first, the signer's name should
     appear in the encrypted plaintext.

this "special cased" fix seems cumbersome to me, so i find
it more natural to stipulate that both names should appear
under both crypto layers.  but perhaps the special-cased
fix will be acceptable to the XML community.

					- don davis, boston




-

Received on Monday, 28 August 2000 21:15:24 UTC