- From: Joseph M. Reagle Jr. <reagle@w3.org>
- Date: Wed, 07 Mar 2001 15:21:00 -0500
- To: "IETF/W3C XML-DSig WG" <w3c-ietf-xmldsig@w3.org>
- Cc: TAMURA Kent <kent@trl.ibm.co.jp>, Brian LaMacchia <bal@microsoft.com>
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