RE: [dss] CMS

["Edward Shallow" <ed.shallow@rogers.com>]

Trevor,

     Here is a succinct summary of my suggestion:

Background
**********
- SignaturePtr (WhichDocument, Xpath) does not handle CMS Verify
- single signature, single document Verify scenario makes SignaturePtr
superfluous
- freedom to support Verify of more than one signature in document should
not be constricted by core
- delineation of CMS support, in core versus in profile needs better
treatment and explanation
- SignatureType refinement required to support the 2 basic CMS signature
types, detached and enveloping


Recommendations
***************
- support only basic CMS signature handling in the core (consistent with
Requirements)
     - Sign
          - create enveloping CMS/PKCS7 signature
          - create detached CMS/PKCS7 signature
     - Verify
          - verify single enveloping signature in incoming SignedData
CMS/PKCS7
          - verify single detached signature in incoming SignedData
CMS/PKCS7 and InputDocument
          - ReturnUpdatedSignature (e.g. add timestamp as unauthenticated
attribute to exisiting CMS/PKCS7, already supported in spec)
- leave extended CMS signature handling to the profiles
     - counter-signature creation and verification
     - multi-signed (co-signed) signature creation and verification
     - verification of both CMS/PKCS7 and any embedded timestamp
     - creation of CMS signatures using client-side hashing
     - verification of specific signatures within a multi-signed CMS/PKCS7
(perhaps using Trevor's SignedInfo suggestion)     
- explain degree of CMS support clearly in spec
- mark InputDocuments as optional to support single signature verify
scenario (CMS)
- mark SignatureObject as optional to support single signature verify
scenario (XMLDSIG)
- allow WhichDocument to be used without an XPath element (i.e. make XPath
optional within SignaturePtr)
- allow requests to specify the presence of multiple signatures through new
SignatureType URNs (e.g. multi) or a new OptionalInput element
- specify that implementations must return the NotSupported URN should they
be unable to honor an OptionalInput when multiple signatures present
- write up semantics associated with the above and include in spec


Outstanding
***********
- should ProcessingDetails be enhanced to support results scope (as opposed
to restricting profiles from reporting on multiple signature statuses)

Tweaking welcome !!!

Ed




  

-----Original Message-----
From: Trevor Perrin [mailto:trevp@trevp.net] 
Sent: April 21, 2004 6:36 AM
To: Ed Shallow
Subject: RE: [dss] CMS


>[Trevor]
>In your proposal, the client sends a SignedData.  When a SignedData 
>contains multiple SignerInfos (co-signatures or counter-signatures), 
>what does the server do?

Hi Ed -

actually, if you could answer the above question (to me or on list,
whichever), I'll send out a summary of both CMS approaches and request other
opinions (or send out the summary yourself).

I think we've reduced this issue to 2 clear, reasonable proposals (and good
for us for doing that!), so we might as well put it to a vote.

Trevor