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.
#####################################