Re: Some possible rqmt/design points

Barb,

I think there are two flavors of attribute, those that apply to the
content and those that apply to the signature (process).  For the
former, I agree that they should be part of the content (even if a
separate item in the manifest).  For the latter (and smaller set),
attributes of the signature, I think they need to be part of the
signature syntax.  I'm also skeptical about our ability to explictly
include all such signature attribute types in the specification (hence a
bucket of type/value pairs).

Taking signing time or signing device info as an example, if I want to
have multiple signatures calculated over the same underlying document
I'd end up potentially having to create multiple encapsulated and/or
composite documents, probably blurring the semantics.  Further, pending
definition of how manifest processing ties into the signature validation
process, its not clear what the implications of such a construct would
be.  

Finally, signature control related attributes should be easily located
by the signature validation logic, and embedding them in the content
would require greater parsing of that document by the signature logic
(both for generation and validation), which doesn't seem like a good
idea.

On the topics of OIDs for algorithm identifiers, all I meant to suggest
is that it would be nice if the identification somehow made it obvious
that "yes, its the same definition of RSA with SHA1 that PKIX points to"
so we don't repeat all the "which definition is it" debates.

Dave

Barb Fox (Exchange) wrote:
> 
> Sorry, Dave, but dragging XML signatures into this particular PKCS7/CMS
> quagmire (attributes) seems to me to be exactly the wrong thing to do. There
> is no compelling need for attributes (authenticated or not) when you already
> have the expressive power of XML. If a signer wants to make qualified
> statements about a particular XML blob, then the signer should make those
> statements in XML (perhaps including a strong reference/hash of the original
> blob) and sign *that*.  In any event, you're always signing a particular XML
> object.
> 
> --Barb
> 
> p.s. We already know that OIDs are a non-starter due to the de-referencing
> problem. They *assume* a priori agreement on their meaning.
> 
> -----Original Message-----
> From: David Solo [mailto:david.solo@citicorp.com]
> Sent: Tuesday, June 15, 1999 2:45 PM
> To: IETF/W3C XML-DSig WG
> Cc: david.solo@citicorp.com
> Subject: Some possible rqmt/design points
> 
> Additional thoughts from my notes on the requirements front.  Some of
> these may be in between requirements and design, and aren't in a
> particular order.  Also, they're in the spirit of trying to leverage
> much of the CMS experience.  I think attention to the validation logic
> is  particularly important. (By the way, I know I included the "no
> criticality" point twice)
> 
> - Ability to associate attributes with the signature
>   - there should be support for both authenticated attributes (covered
> by the signature) and unauthenticated attributes (not covered by the
> signature)
>   - attributes should be treated consistently (i.e. not specifying some
> in the base signature structure and others in an attribute bucket - put
> them all in the bucket)
>   - attributes are a type and value combination
>   - some set of standard attributes should be defined, but adding others
> must be straightforward (list in Brown is a good start)
>   - NO criticality flags
> 
> - Ability to carry a range of explicitly typed infrastructure
> credentials including
> public key certificates, attribute certificates, KM tokens,
> revocation/status data objects
> 
> - Ability to specific algorithms independently and to reference the
> algorithms linked to standard algorithm specifications (e.g. OIDs)
> 
> - Provide a content structure (manifest) supporting multiple objects,
> references, entries should include explicit content type information
> 
> - Specify unambiguous validation rules including:
>   - rules on expansion of link/references (probably none)
>   - explicit hash calculation between content elements and attributes
>   - default minimum semantics and pass/fail criteria (mathematical
> signature validation).  Additional semantics via attached attributes
>   - NO criticality flags
>   - how to handle multiple signatures (valid if all signatures are OK)
> 
> - 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
> 
> - From an implementation perspective, the ability to leverage existing
> cryptographic (and infrastructure?) provider primitives is desirable.
> 
> All for now,
> Dave

Received on Wednesday, 16 June 1999 09:19:35 UTC