W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > April to June 1999

RE: Some possible rqmt/design points

From: Barb Fox (Exchange) <bfox@Exchange.Microsoft.com>
Date: Tue, 15 Jun 1999 15:47:08 -0700
Message-ID: <4992824A0863D211964B0008C7B1ACB803E1B533@FIFI>
To: "'david.solo@citicorp.com'" <david.solo@citicorp.com>, IETF/W3C XML-DSig WG <w3c-ietf-xmldsig@w3.org>
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


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
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
  - 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,
Received on Tuesday, 15 June 1999 18:47:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:21:31 UTC