Comments on WD-xmlenc-core-20011018

Hi Joseph,

some comments for the current version of XML Encryption Syntax and 
Processing (WD-xmlenc-core-20011018).
I did not follow the discussion the last weeks, so if I duplicated some 
effort - sorry.

Best regards
Christian

#####################################

In 2.1.5 there is an XPath expression in the line before the last example: 
it reads

//EncryptedData[@ID='ED1']

but there is no xenc prefix and the Attribute has a large I:

//xenc:EncryptedData[@Id='ED1']

#####################################

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

...#3des-cbc ' should be ...#3des-cbc'

#####################################

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

Now it reads:
Features described in this section are mandatory to implement unless 
otherwise noted.

Maybe we should say:
Features described in this section are mandatory to implement (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.

#####################################

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.

#####################################

In 3.2.1 CipherReference, there is stated (HTML) in the second block:

"sequence of <CODE>Transforms</CODE>, the "

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>

#####################################

In 3.4 Extensions to ds:KeyInfo Element (HTML):

elements of ds:<CODE>KeyInfo</CODE>

should be

elements of <CODE>ds:KeyInfo</CODE>

#####################################

In 3.6 EncryptionProperties:

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

#####################################

In 4.1 Encryption point 2.1 Obtain and represent the key:

"construct the ds:KeyInfo as appropriate (e.g. ... ds:KeyValue, 
ds:KeyRetrievalMethod)"

ds:KeyValue is obviously not allowed for security reasons (plaintext key), 
correct?
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?

#####################################

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.

instead of

Process decrypted data of the 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.

#####################################

Received on Friday, 26 October 2001 08:41:40 UTC