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

Some possible rqmt/design points

From: David Solo <david.solo@citicorp.com>
Date: Tue, 15 Jun 1999 17:44:34 -0400
Message-Id: <199906152053.QAA23075@egate3.citicorp.com>
To: IETF/W3C XML-DSig WG <w3c-ietf-xmldsig@w3.org>
Cc: "david.solo@citicorp.com" <david.solo@citicorp.com>
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 17:42:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:09:55 UTC