Re: Some possible rqmt/design points

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