- From: Joseph M. Reagle Jr. <reagle@w3.org>
- Date: Wed, 16 Jun 1999 17:04:11 -0400
- To: david.solo@citicorp.com
- Cc: IETF/W3C XML-DSig WG <w3c-ietf-xmldsig@w3.org>
At 05:44 PM 6/15/99 -0400, David Solo wrote: >Additional thoughts from my notes on the requirements front. Some of David, thanks for these comments. I've tried to reflect some of them in the RD (which I will post once I figure out how to make it look like a W3C NOTE and ietf-draft) but I was not able to reflect all of them since I do not understand them or I think they require further discussion. Once the document is a bit more stable (after the FTF meeting), I will probably ask that requests of additional or alternative requirements be proposed as plug and play amendments to the contemporary draft. Regardless, they prompt useful discussion, couple quick responses. >- Ability to associate attributes with the signature This has generated an interesting and worthwhile thread, though it seemed to meander to a point (time stamps and disclosures) that prompts me to think that we aren't thinking as Web-centric as we could : XML, semantic extensibility through XML name spaces, decentralization/URIs, Web data, signing statements about statements, etc. I suspect your use of "attribute" is a key word used to designate a semantic carrier in traditional crypto -- not what I think of, I think of an XML attribute. I would argue that at the core (which I hope we narrow our focus to at this point), we should be concerned with little more than the syntax necessary for carrying semantics absolutely necessary to check the _validity_ of the signature. Stuff that is necessary for deriving a _trust_ relationship is varied and should be layered on top of the core. >- Ability to carry a range of explicitly typed infrastructure >credentials including >public key certificates, attribute certificates, KM tokens, >revocation/status data objects This is just other Web data used in making trust decisions, and should fit because of design generality rather than exception. >- Ability to specific algorithms independently and to reference the >algorithms linked to standard algorithm specifications (e.g. OIDs) I agree on the independently front, and I'm cautious of OIDS unless they can be cast as URNs, if URNs are URIs. <smile> >- Provide a content structure (manifest) supporting multiple objects, >references, entries should include explicit content type information The manifest will be able to reference anything with a XML locator (often a URI). Why does the manifest have to tell you the content type? >- Specify unambiguous validation rules including: > - rules on expansion of link/references (probably none) I agree, signed-XML applications will be largely if not completely ignorant of the content -- including XML -- though the canonicalization processors they select may not be. The XML Syntax C14N (canonicalization) will likely expand general entities of the XML content. An application might normalize/canonicalize/process the content itself before handing it to the Signature application (and tell Signature not to do anything to the content, just hash the bytes) or place a directive in the Signature syntax (by way of the C14N algorithm "attribute") to have the sig-application invoke the external processor. Or it might even do both: normalize high level application semantics into a XML serialization, and then ask xml-sig to C14N that XML. > - explicit hash calculation between content elements and attributes What does this mean? > - default minimum semantics and pass/fail criteria (mathematical >signature validation). Additional semantics via attached attributes In XML speak, I would say elements, in RDF I'd be thinking statements about statements (along the lines of: http://lists.w3.org/Archives/Public/w3c-xml-sig-ws/1999Apr/0053.html ) > - how to handle multiple signatures (valid if all signatures are OK) That's approaching trust (not validity) stuff, I'd definitely want to defer on (such as getting into thresh-hold declarations.) >- Multiple signature may be included and each signature shall be >associated with information to identify the signer and/or the >cryptographic information required to validate the signature Enough information to assess the validity of the signature. Nothing more is necessary. >- From an implementation perspective, the ability to leverage existing >cryptographic (and infrastructure?) provider primitives is desirable. This is sort of mother-pie, but a useful sort of statement none-the-less, though I might disagree with it, if it is counter to my even more ambiguous mother-pie of decentralization, URIs, Web data, semantic extensibility, statements about statements, etc. _________________________________________________________ Joseph Reagle Jr. Policy Analyst mailto:reagle@w3.org XML-DSig Co-Chair http://w3.org/People/Reagle/
Received on Wednesday, 16 June 1999 17:04:15 UTC