Re: Some possible rqmt/design points

• 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>
• Message-Id: <3.0.5.32.19990616170411.00af2dc0@localhost>

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:
        https://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   https://w3.org/People/Reagle/

Received on Wednesday, 16 June 1999 17:04:15 UTC