Closing Multiple KeyValue

Kent asked [1], "The current specification also permits multiple KeyValue 
elements in a KeyInfo element. What does this mean?"

The natural language in the specification is clear that KeyInfo is about one 
key, the implication of this specification is not accurately reflected in 
the schema design because more than one KeyValue is permitted. However some 
felt that this constraint should be relaxed given that other applications 
may wish to borrow this construct for general key transport. However, given 
the mixed views, a lack of immediate/clear cases where we would hinder 
dependent specs (actually, Encryption borrows the dsig "single key" semantic 
[2]), as well as an interest in not make changes in CR/Proposed the chairs 
feel we should stick with the original meaning and where *possible* tweak 
the schema to reflect the natural language specification. But regardless of 
what we do with the definitions, the natural language specification should 
remain unchanged.

[1] http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2001JanMar/0052.html
[2] http://www.w3.org/Encryption/2001/Meetings/0301-Boston/dillaway.html
"All encryption key info for an encrypted data must refer to the same key"

**Unfortunately, the definition of ds:KeyInfo uses a (1,unbounded) choices 
over mandatory elements to emulate an unordered set of optional elements. 
This does not readily permit us to constrain KeyValue to (0,1). On hindsight 
the use of choice appears to be a bad for a couple reasons which I'll 
address in a subsequent email.

__
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 Wednesday, 7 March 2001 15:21:20 UTC