Re: Misc. suggestions/corrections to 09/19 xmlenc draft

[Resulting doc
  http://www.w3.o rg/Encryption/2001/Drafts/xmlenc-core/
  $Revision: 1.55 $ on $Date: 2001/09/20 22:13:18 $
]


On Wednesday 19 September 2001 17:43, Blair Dillaway wrote:
> Here are some miscellaneous suggestions/corrections based 

Thanks! All patched except for the following:

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

It's actually supposed to be the URI identifying the EncryptedKey type, 
which I had not defined (and now have done, see below).

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

The dsig spec says they refer to the same key, so it's not really 
"implicit." I added /+same+/ to the existing sentence.

> 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

Oops, I moved the type attribute to the parent type, but forgot to move its 
text.

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

Should read ds:RetrievalMethod.

> 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?

Good question. What do the crypto/NIST weenies say on the time frame now? 
Otherwise, we might have to pursue an exception by calling these 
non-normative/Informational, as we're considering with XML/schema 
validation in dsig...

> 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?

Ok, added a new reference.

Received on Thursday, 20 September 2001 18:19:50 UTC