RE: [dss] Discussion on outstanding issues for the core.

[Trevor Perrin <trevp@trevp.net>]

At 02:47 PM 5/6/2004 +0100, you wrote:
>I give below my personal views on the issues raised :
>
>
>Issue 1
>---------
>
>Looking into how CMS signatures works:
>
>CMS has a signed data structure which is used in two ways:
>  a) SignedData structure includes encapsulated content and the signature
>with certificates etc (cf: XML enveloped)
>  b) SignedData structure with no encapsulated content with just signature,
>certificates etc (cf XML Detached)
>
>Since a very common CMS structure is SignedData with encapsulated content as
>we are supporting CMS, I can see no reason for it not to be supported in
>DSS.

I'm not sure it's that's common.  Code-signing uses detached.  S/MIME uses 
detached or enveloping, but S/MIME messages can be large, so clients will 
probably want to convert enveloping sigs -> detached sigs so they can do 
client-side hashing.

I'd be more comfortable if there was a good use case for this.


>Since in such cases there is no separate input document is see no choice but
>to make <InputDocuments> optional for DSS verify.

The other choice is to require the client to convert the enveloped sig to a 
detached sig, by deleting a single ASN.1 element.  This puts more work on 
the client in this case (but I think it's a rare case), but has less impact 
on the protocol and server.  So it's a trade-off.

You, Ed, and Juan Carlos support one side, so I'll take that as the 
consensus for the next draft, unless things change.


>In addition, for 3.3.1 defines procedures for creating enveloping XML
>signatures.  Hence, I see it as reasonable to for support for verifying
>enveloping XML Signatures which also requires <InputDocuments> to be
>optional.

Right now, the server uses the Input Document's RefURI attribute to match 
up input documents with <ds:Reference>s.  With what you're suggesting, the 
server would have to dereference the <ds:Reference>s himself.

This requires the server to know the schema of any enveloped input 
documents, so it can identity ID attributes.  It may also require the 
server to know the base URI of the enveloping signature, so it can identify 
explicit self-references.  It also requires the server to process XPointer 
statements in ds:Reference/@URI, which it doesn't have to do otherwise.

So we'd either have to add limitations on when this could be used, or add 
new ways for the client to indicate the schema of the enveloped documents 
and the base URI of the signature.  I don't think it's worth the complication.


>However, I do agree that the processing rules should make it very clear in
>what situations this should be used.
>i.e. <InputDocuments> shall be present unless the SignatureObject is
>enveloping or encapsulating the signed document.
>
>
>Issue 2
>-------
>
>This issue is not relevant to CMS as I do not believe that there is a
>structure defined in CMS which is equivalent to XML Enveloped Signature.
>
>However, 3.3.2 defines procedures for creating enveloped signatures.  Hence
>I suggest that it is reasonable to support verification of enveloped
>signatures.

We do, with SignatureObject/SignaturePtr.


>Thus, I suggest that this is made optional but has processing rules which
>make it explicit when SignatureObject is not present.

What exactly are the processing rules?  That the server already knows where 
the enveloped signature is?  Or it's expected to search for it?  What if 
there's multiple signatures, so the server might not verify the one the 
client expects?  Is the server expected to search the document just to make 
sure there's only one signature?  Or is the client expected to do that?

I don't see the benefit of omitting the <SignatureObject>.  It loosens the 
syntax so makes our schema less useful, and necessitates more text to 
explain the different cases.  And the semantics of it seem way too 
complicated.


>Issue 3
>-------
>
>I suggest that the Core should not preclude handling of multiple signatures
>in profiles.  However, I think that it is reasonable for the results
>returned if the SignatureObject contains multiple signatures to be left
>undefined in the Core.

If you're verifying something, that means you're worried about malicious 
modification.  That modification may include such things as adding extra 
signatures.  So leaving the behavior in this case undefined seems a 
security risk.

(In other words: the client may *think* there's only 1 signature, so that 
server behavior is defined, but be wrong, because the bad guy added another 
signature).


>Comments on Possible Approach
>-----------------------------
>
>I suggest that something is added to the 1.3 to the effect that
>
>"Specific procedures and structures are defined for the support of XML
>Signatures including detached, enveloped and enveloping signatures as well
>as CMS signature with and without encapsulated data.  Also, specific
>procedures are defined for the verification of documents with a single
>signature. The handling of other forms of signature are left undefined by
>this specification, but may be specified in profiles extending the
>procedures and / or data structures defined in this specification."
>
>----
>
>I also suggest that 3.3 defines specific extensions to the procedures for:
>
>3.3.1 XML Enveloping Signatures
>  (as is)
>3.3.2 XML Enveloped Signatures
>  (as is)
>3.3.3 XML Detached Signatures
>  (??? Any further procedures necessary)

I don't think so.

>3.3.4 CMS Signatures with Encapsulated Data
>  (text to be produced)
>This should include the description of how CMS SignedData structure is
>encoded into the Base64Signature structure in SignatureObject.
>3.3.5 CMS Signatures without Encapsulated Data
>  (text to be produced)
>
>---
>I suggest that procedures are added to 4.3 to describe the verification of
>the five forms of signature.

Agreed, we should at least have the equivalent of 3.3.1 and 3.3.2, plus CMS.


>For CMS I suggest that the CMS terms are used instead of enveloping /
>detached as above.

Which are what?  external vs. non-external?


Trevor