Re: Some possible rqmt/design points

Joe,

Joseph M. Reagle Jr. wrote:
> 
>  >- 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.

I agree the thread has digressed a little, but I think the question (and
Richard has done a good job of describing this) is whether there is a
need to associate some additional information with the signature (vs.
the content).  I would expect it to be an XML structure (I wasn't
alluding to any special use of attribute other than as a generic
property or type/value pair).  I'm not sure I'm clear on what you meant
by the last sentence on trust relationships.

>  >- 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.

Agreed, its just a cautionary reminder when we get to actually defining
the syntax.

>  >- 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>

As in a separate note, my goal is to not introduce unintended
crytographic incompatibility as a result of finding the right algorithm
spec.  I'm not as concerned about the syntax for indicating "what he
said"

>  >- 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?

This relates back to possible implementation architectures.  In some
cases, where the signature processing function is distinct from the
content processing, it can be helpful to provide clues on what to do
with the content.  Its probably not strictly necessary.

>  >  - explicit hash calculation between content elements and attributes
> 
> What does this mean?
 
Another cautionary note.  In designing signature solutions in the past,
lots of time has been spent getting agreement (and then writing clear
language) on how to calculate the hash input to the signature.  If the
signature is calculated over a variety of elements, how you do hash of
hashes, what tags are or are not included, etc., require more
specificity than was in earlier drafts.  

In addition, we may need to deal with the canonicalization question
separately for the manifest (or whatever its called) vs. the documents
to which the manifest points.  In particular, it may be useful to pick a
single c14n solution for calculating the hash over the manifest.

>  >- 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.

Modulo the attribute discussion, I agree.

Dave

Received on Wednesday, 16 June 1999 21:46:56 UTC