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 Tuesday, 15 June 1999 17:42:51 UTC