- From: Joseph M. Reagle Jr. <reagle@w3.org>
- Date: Tue, 24 Aug 1999 12:45:14 -0400
- To: "Phillip M Hallam-Baker" <pbaker@verisign.com>
- Cc: "Donald E. Eastlake 3rd" <dee3@torque.pothole.com>, "IETF/W3C XML-DSig WG" <w3c-ietf-xmldsig@w3.org>
At 11:48 99/08/24 -0400, Phillip M Hallam-Baker wrote: >Nobody is arguing against support for c14n FOR THOSE APPLICATIONS WHICH >NEED IT. The question here is one common of specifications that are unclear of what they are specifying things over. I try to be specific with each requirement in the RD, and preface it all in the abstract by saying, "It includes requirements as they relate to the signature syntax, data model, format, cryptographic processing, and external requirements and coordination." Quite a lot, but necessary. (And one that could use improvement.) This issue is: are we willing to specify an application-feature requirement? While this isn't necessary for ensuring intoperability over the wire, people sometimes add these because not being clear about the features an application will support (if optional) is a disservice to the implementors. I'm not going to use a feature, if I'm not confident other people will implement it. Sometimes you let it evolve through extensibility, sometimes you need to align the implementors expectation's over the feature set at the start to get a critical mass of usefulness. So, for this issue: Acknowledged: there is no requirement to use c14n for signature generation -- we can finish the discussion on the signature itself next week. Questioned: even if not, is there an requirement that Signature applications have a normative c14n algorithm handy in case the sender uses it? Philllip, are you opposed to using it in your signature generation and/or having to implement it regardless? I suspect this is a case that if we don't have a mandatory to implement, then we will have lots of signatures that won't interoperate (or no one will c14n). If we do have it, the use of the c14n will spread according to its usefulness. I don't think the first case is one many people would be happy with; the second case requires more work, but can make everyone much happier. _________________________________________________________ Joseph Reagle Jr. Policy Analyst mailto:reagle@w3.org XML-Signature Co-Chair http://w3.org/People/Reagle/
Received on Tuesday, 24 August 1999 12:45:20 UTC