W3C home > Mailing lists > Public > xml-encryption@w3.org > August 2001

RE: Security Concerns (Was: Surreptitious Forwarding)

From: <edsimon@xmlsec.com>
Date: Sun, 19 Aug 2001 12:45:19 -0400
Message-ID: <3B73133E000039FB@mail.san.yahoo.com>
To: xml-encryption@w3.org
Though I maintain the general comments I made earlier (see "http://lists.w3.org/Archives/Public/xml-encryption/2001Aug/0011.html"
or bottom append to this note),
I can go with the text Joseph has proposed.

Ed
-- Original Message --

>
>I hope (and have reasons to believe) that the following text isn't too

>onerous. So, I suppose I would ask that unless you really have a problem
>with 
>the following, let's move on:
>
>
>http://www.w3.org/Encryption/2001/Drafts/xmlenc-core/Overview.html#sec-Security
>
>...
>Additionally, while the following warnings pertain to incorrect inferences
>by 
>the user about the authenticity of information encrypted, applications
should
>
>discourage user misapprension by communicating clearly which information
>has 
>integrity, or is authenticated, confidential, or non-repudiable when multiple
>
>processes (e.g., signature and encryption) and algorithms (e.g., symmetric
>
>and asymmetric) are used: 
>
>1.When an encrypted envelope contains a signature, the signature does not
>
>necessarily protect the authenticity or integrity of the ciphertext [Davis].
>
>2. While the signature secures plaintext it only covers that which is signed,
>
>recipients of encrypted messages must not infer integrity or authenticity
>of 
>other unsigned information (e.g., headers) within the encrypted envelope,
>see 
>[XMLDSIG, 8.1.1 Only What is Signed is Secure].
>
>
*************************************
From: edsimon@xmlsec.com
Message-ID: <3B5F179F00003157@mail.san.yahoo.com>
Date: Thu, 2 Aug 2001 15:04:53 -0400
To: Joseph M. Reagle Jr. <reagle@w3.org>, Plambeck, Thane <tplambeck@verisign.com>,
Don Davis <ddavis@curl.com>
Cc: 'xml-encryption@w3.org' <xml-encryption@w3.org>
Subject: Re: FW: Fwd: Surreptitious Forwarding

As I said at the July meeting, I think "Surreptitious Forwarding" is almost
superfluous with respect to the XML Encryption spec.  Though I'm wary of
extending the "Security considerations" section of XML Signature too far,
here's the text I would propose if we were going to mention the topic there...

<ProposedText>
Signatures only secure what they sign.  Information not signed by a signature
is not secured by that signature [Security 101].  Applications with user
interfaces that expose the results of a signature verification to the user
should notify users of exactly what is signed if there is a reasonable chance
that users misapprehension of the scope of a signature will affect security.
 If other security operations, such as encryption, were also part of the
user experience, it may be necessary for an application to indicate that
these non-signature security operations do not alter the scope of a signature.[Davis]
</ProposedText>

It seems to me that the topic of "Surreptitious forwarding" largely stems
from the fact that in the world before XML, it was not *practical* to *selectively*
secure data.  Consequently, email systems were built around the idea that
if you wanted to encrypt AND sign, you had to encrypt AND sign the same
data.  Hence, things that perhaps should have been signed (like an email's
recipient list), were left unsigned.

Thankfully, we now live in a world with XML, a world where it is practical
to have more flexibility in what gets encrypted and what gets signed, where
email applications now have the opportunity to enhance their security by
using XML-based security protocols.  

The topic of "Surreptitious Forwarding" provides a good example I think
of what distinguishes XML Signature and XML Encryption from pre-XML security
protocols and this is definitely worth writing about.  However, I would
prefer to keep such non-normative text out of XML Signature and XML Encryption.

Ed

-----------------------------------------------------------------------------------------------
Ed Simon
XMLsec Inc.

Interested in XML Security Training and Consulting services?  Visit "www.xmlsec.com".
Received on Sunday, 19 August 2001 12:46:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:13:04 UTC