Misc. suggestions/corrections to 09/19 xmlenc draft

Here are some miscellaneous suggestions/corrections based on review of
the the 2001/09/18 xmlenc-core spec and 2001/09/18 Section 5 update
posted to the list by Donald.

Section 2.2.1  
	[s1] in 1st sentence, change "... represented as an attribute
value as an aid in decryption..." to "... represented as an attribute
value to aid in decryption..."

	[s4-s5] change text to "The symmetric key has an associated name
'John Smith'."

	[s6] change text to "CipherData contains a CipherValue, which is
a base64 encoded octet sequence.  Alternately, it could contain a
CipherReference, which is a URI reference along with transforms
necessary to obtain the encrypted data as an octet sequence."

Section 2.2.2

	[t04]  shouldn't "&xenc;EncryptedKey" be "xenc:EncryptedKey"?

	[t05] add to end "It is implict that both mechanisms refer to
the same key value."

Section 3.1.
	- in the schema for EncryptedType, shouldn't the attribute
'Type' be removed and defined in for the EncryptedData subtype?  Its not
discussed in this section but is discussed in Section 3.3.    If it does
belong here then it needs to be defined in the text for this section and
then also discussed for EncryptedKey in Section 3.4.1

Section 3.6
	- I don't believe the parenthetical comment "(this can be used
within a ds:Reference element to identify the referent's type)"
belongs here.  I especially don't understand why a remark regarding
ds:Reference elements would be in this spec at all since xmlenc doesn't
use them.

Section 4.2
	- Step 4 text should start "4. Processing decrypted data..." not
"Decrypt data".
	- Step 5 text should start "5. Processing decrypted data"
	decryption processing happens in step 3 not in these steps

Section 5, Table of Algorithms
	- my understanding is that stds are not published defining
AES-xxx KeyWrap consistent with the statements in Section 5.6.3.  Since
2 of these algs are listed as REQUIRED is this going to become a
blocking issue for this spec?  We can't demonstrate 2 independent
implementations for a TBD std. Is there some way we can explicity exempt
ourselves from the implementation requirement while still indicating we
believe folks should implement these once defined?

Section 5.5.2
	- 3rd to last paragraph, last sentence reads "'foo' is the bse64
.." should be "'foo' is the base64.."

Section 5.6.2
	- under encryption Step 2 ref to Section 5.5.1 should be 5.6.1
	- under decryption Step 7, ref to Section 5.5.1 should be 5.6.1

Section 6.1
	- bullet #2 in 3rd paragraph .  Shouldn't a link to "Decryption
Transform for XML Signature" be added rather than the current vague
reference to a separate specification? 

Regards,
Blair

Received on Wednesday, 19 September 2001 17:46:42 UTC