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

Re: Comments on WD-xmlenc-core-20011018

From: Joseph Reagle <reagle@w3.org>
Date: Wed, 21 Nov 2001 15:39:32 -0500
To: Christian Geuer-Pollmann <geuer-pollmann@nue.et-inf.uni-siegen.de>
Cc: XML Encryption WG <xml-encryption@w3.org>
Message-Id: <20011121203932.BEAF61040@policy.w3.org>
  $Revision: 1.74 $ on $Date: 2001/11/21 20:39:12 $ GMT by $Author: reagle $

On Friday 26 October 2001 07:43, Christian Geuer-Pollmann wrote:
> some comments for the current version of XML Encryption Syntax and
> Processing (WD-xmlenc-core-20011018).

Thanks for the comments and sorry for my tardy response! 

> Should we add a note into section "3.1 EncryptedType" that it is not
> allowed (or could cause problems) if an EncryptedData element becomes the
> DocumentElement of a now Document with @Type="ElementContent" ? I mean,
> if the decrypted result is not well-formed (what could happen with
> ElementContent), decrypting such an EncryptedData document could cause
> trouble. Just to tell that people should think about it if they encrypt
> multiple Element children and place the result into a new document.

On the teleconf we agreed to add some text. The right text doesn't come to 
my mind immediately, so I'll think on it, but I'm also open to proposals! 

> In 2.1.5 there is an XPath expression in the line before the last
> //xenc:EncryptedData[@Id='ED1']


> In 2.2.1 example line 's2' there is a space appended to the algorithm
> name:


> In section 3, maybe we should add a little sentence (only a suggestion):

Tweaked: "Features described in this section MUST be implemented unless 
otherwise noted. "

> The schema prefix in section 3 states:
> <schema .... version='0.1'
> I'm not a schema crack; should this be version='1.0' ?


> Section 2 describes this regex-style XML structure. There is no
> EncryptionProperties in this rough structure. But the Schema in 3.1
> EncryptedType introduces this Element.

I think this was fixed earlier.

> In 3.2.1 CipherReference, there is stated (HTML) in the second block:
> but should be
> "sequence of <CODE>Transform</CODE>s, the "


> #####################################
> In 3.2.1 CipherReference, there is in the example:
> <ds:XPath xmlns:rep="http://www.example.org/repository">
>   self::text()[parent::CipherValue[@id="example1"]]
> </ds:XPath>
> but the rep namespace is not used in this example. Additionally, the Id
> attribute has a small 'I'.
> <ds:XPath>
>   self::text()[parent::CipherValue[@Id="example1"]]
> </ds:XPath>

The intent was to show there was some other "repository" namespace and 
structure that held lots of CipherValues, so I kept the namespace but fixed 
the Xpath.

          <ds:XPath xmlns:rep="http://www.example.org/repository">

> In 3.4 Extensions to ds:KeyInfo Element (HTML):
> should be
> elements of <CODE>ds:KeyInfo</CODE>


> In 3.6 EncryptionProperties:
> Do we say something about the xenc:EncryptionProperties/@Target
> attribute?

Added, "The Target attribute identies the EncryptedType structure being 

> In 4.1 Encryption point 2.1 Obtain and represent the key:
> ds:KeyValue is obviously not allowed for security reasons (plaintext
> key), correct?

It could be a ds:KeyValue that is subsequently encrypted in EncryptedKey, 

> ds:KeyRetrievalMethod should read ds:RetrievalMethod


> In 4.1 Encryption, we don't mention the Nonce handling in point 4
> "Building the EncryptedType"


> In 4.2 Decryption, point 3.3 we say: "If a nonce was prepended to the
> plaintext, remove it". Should we say that the decryptor has to check
> whether the nonce matches the given one before removing it?

We don't represent the whole nonce in the plaintext, only its length.

> In 4.2 Decryption, point 5 the sentence makes no sense: Maybe it should
> read
> Process decrypted data is unspecified id Type is not Element or Element
> Content.

Now: "Process decrypted data if Type is unspecified or is not Element or 
Element Content."

> In 5.5.2 (last sentences (HTML))
> the b <INS>a</INS>se64


> In 5.7.2 SHA256
>    5.7.3 SHA512
>    5.7.4 RIPEMD-160
> we always mention that the Identifier is in encryption namespace but the
> examples use signature namespace.



Joseph Reagle Jr.                 http://www.w3.org/People/Reagle/
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/Signature/
W3C XML Encryption Chair          http://www.w3.org/Encryption/2001/
Received on Wednesday, 21 November 2001 15:39:34 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:32:02 UTC