Some possible rqmt/design points

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