Comment on "Open Issue 4"

>http://lists.w3.org/Archives/Public/xml-encryption/2000Dec/att-0024/01-XMLEncryption_v01.html#_Toc501424273
>... The alternate proposal is to only allow an EncryptedKey element as a 
>child of a KeyInfo element.

Thinking about this logically, I would like to advocate that EncryptedKey be 
considered a child of KeyInfo (instead of a sibling).

1. The present proposal states, "A KeyInfo may not contain an EncryptedKey 
child element, though a reference to an EncryptedKey is allowed within an 
EncryptedData element context." This is not supported by the ds:KeyInfo 
schema (which we are relying upon in this instance) since it has an open 
content model -- someone *could* stick a EncryptedData in KeyInfo.
2. The present content model permits EncryptedKey and KeyInfo as siblings. 
EncryptedKey to me seems like a type of KeyInfo. The present structure 
permits a KeyInfo *and* EncryptedKey to appear together as siblings and I 
don't know what this means. (However, if we wish to keep EncryptedKey as a 
child of EncryptedData this might be remedied by using a <choice/> between 
KeyInfo and EncryptedKey.)

I'm not sure of the implications of this logical thinking are on the syntax, 
but that can be straightened out once we figure out what we are trying to say.


(We have options where we might represent this as:

1. Element instances are in the encryption namespace but based on the 
ds:ComplexTypes in the schema:
<enc:EncryptedData>
   <enc:KeyInfo>
     <enc:EncryptedData>

2. or, Element instances are kept in their original namespace:
<enc:EncryptedData>
   <ds:KeyInfo>
     <enc:EncryptedData>
)

__
Joseph Reagle Jr.                 http://www.w3.org/People/Reagle/
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/Signature
W3C XML Encryption Chair          http://www.w3.org/Encryption/2001/

Received on Friday, 23 February 2001 18:37:25 UTC