comments on XML Encryption 1.1 draft

I have received the following comment on the XML Encryption 1.1 draft  
(before today's F2F updates), mostly editorial (e.g. spell checking  
pass needed)

regards, Frederick
Nokia
----
3.1 The EncryptedType Element

 > Implementations SHOULD create these XML structures
 > (EncryptedType elements and their descendents/content)

descendants

 > in Normalization Form C [NFC, NFC-Corrigendum].

3.5.1 The EncryptedKey Element

 > The Type attribute inheritted from EncryptedType can be used to  
further

inherited

 > specify the type of the encrypted key if the EncryptionMethod  
Algorithm
 > does not define a unambiguous encoding/representation. (Note, all the
 > algorithms in this specification have an unambigous representation  
for

unambiguous

 > their associated key structures.)

4.1 Encryption

 >   2. Obtain and (optionally) represent the key.
 >         1. If the key is to be identified (via naming, URI, or  
included in
 > a child element), construct the ds:KeyInfo as approriate (e.g.,  
ds:KeyName,

appropriate

 > ds:KeyValue, ds:RetrievalMethod, etc.)

 >            The definition of this type as bound to an identifier  
specifies
 > how to obtain and interpret the plaintext octets after decryption.  
For
 > example, the idenifier could indicate that the data is an instance of

identifier

 > another application (e.g., some XML compression application) that  
must be
 > further processed.

4.2 Decryption
 >   5. Process decrypted data if Type is unspecified or is not  
'element' or
 > element 'content'.
 > MimeType and Encoding are advisory. The Type value is normative as  
it may
 > contain information necessary for the processing or interpration of  
the

interpretation

 > data by the application.

5. Algorithms

 > Levels of requirement specified, such as "REQUIRED" or "OPTIONAL",
 > refere to implementation, not use.

refer

Table of Algorithms

5.6.3 AES KeyWrap

 > "|" represents concatentation so x|y, where x and y and 64-bit  
quantities,

concatenation

 > is the 128-bit quantity with x in the most significant bits and y  
in the
 > least significant bits. AES(K)enc(x) is the operation of AES  
encrypting
 > the 128-bit quantity x under the key K. AES(K)dec(x) is the  
corresponding
 > decryption opteration.

operation

 >   2. Initialize variables:
 >          * Set A to 0xA6A6A6A6A6A6A6A6
 >          * Fori=1 to N,

space please

 >            R(i)=P(i)
 >   3. Calculate intermediate values:
 >          * Forj=0 to 5,

space please

 >                o For i=1 to N,
 >                  t= i + j*N
 >                  B=AES(K)enc(A|R(i))
 >                  A=XOR(t,MSB(B))
 >                  R(i)=LSB(B)
 >   4. Output the results:
 >          * Set C(0)=A
 >          * For i=1 to N,
 >            C(i)=R(i)

6.3 Nonce and IV (Initialization Value or Vector)

 > Different algorithms and modes have further requirements on the
 > characteristic of this information (e.g., randomness and secrecy)  
that
 > affect the features (e.g., confidentiality and integrity) and their
 > resistence to attack.

resistance

Example
 >    enc-example.xml (not cryptographically valid but excercises much  
of

exercises

 > the schema)

10 References

NFC
 >    TR15, Unicode Normalization Forms. M. Davis and M. D?rst.  
Revision 18:
 > November 1999.

the letter here should be reencoded.