CMS

[Trevor Perrin <trevp@trevp.net>]

The consensus on the call was that CMS support should be fully spec'd in 
the core.  Here's a proposal:

To recap, a CMS SignedData contains a set of co-signatures, each of which 
could be the root of a *tree* of counter-signatures (not a chain, like I 
thought before).

Each of these sub-signatures is of type SignerInfo.  So far, we've assumed 
the client sends a SignedData for verifying.  I think it would be better to 
send a SignerInfo:
  - SignerInfo is self-contained: it contains signed & unsigned attributes, 
the hash type, and signature value.  A SignerInfo should be easy to extract 
from a SignedData: at best, your library will provide access to it.  At 
worse, you do a bit of ASN.1 parsing.
  - This avoids the difficulty with determining which co-signature or 
counter-signature to verify.  The client just encodes the desired 
SignerInfo inside a <Base64Signature>.
  - This supports enveloping & detached signatures identically, and allows 
for client-side-hashing (via <DocumentHash>) in either case.

On the signing side, we probably still want to return a full SignedData, so 
the client doesn't have to piece one together.

Comments?


Trevor