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

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

More comments inter-mixed. 

-----Original Message-----
From: Trevor Perrin [mailto:trevp@trevp.net] 
Sent: May 6, 2004 3:32 PM
To: Nick Pope
Cc: dss@lists.oasis-open.org
Subject: RE: [dss] Discussion on outstanding issues for the core.

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.

<ed>
Just as common in my experience. Size is an implementator issue, best left
to the specific DSS implementation. Constraining it by ruling it out is not
the answer. Client-side hashing is often implemented using the document hash
"AS" the data to be signed thus allowing a conventional Verify which works
transparently regardless of what was signed. See www.authentidate.com.  
</ed>

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

<ed>
I'd rather question the desire to rule it out, since the only motive seems
to be that our current spec doesn't support it. 
</ed>

>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

<ed>absolutely</ed>

 (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.

<ed>
Excellent.
</ed>

>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.

<ed>
Not an issue with single document, single signature. Besides, this challenge
is entirely our own making.
</ed>

This requires the server to know the schema of any enveloped input 
documents, so it can identity ID attributes.
<ed>
Many (most ?) toolkits allow inline or referenced DTDs identifying ID
attributes. Usually a line or 2. Very normal.
</ed>

  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.

<ed>
In the case of a totally self-contained enveloped/enveloping single
signature document, please let me know what toolkit requires/forces this.
</ed>

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.

<ed>
I don't see this complexity, and have sent much more complicated signed XML
to the list which Verifies easily. Finding signatures is also pretty
straightforward with todays XML librairies which support things like
findNode by name, and findNode by name qualified by namespace, etc ...
Besides, this is really the implementors' challenge. Let them decide if they
want to mandate SiganturePtr or not. Why are you forcing it on them ?
</ed>


>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.

<ed>
I think Nick means "as contained in the InputDocument" with SignatureObject
optional.
</ed>


>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?
<ed>
- If there is only one InputDocument containing that signature ... not to
hard.
- If there is only one InputDocument containing all the signature references
... still not to hard. (Remember InputDocuments do not "HAVE" to line up
with References). Check the spec, is says "usually". I even doubt that is an
appropriate choice of words.
- If some client has the massocistic tendency to give us 3 InputDocuments,
one of which contains the signature, and the other 2 match up to References
... we have the SignaturePtr for implementations to optionally use. I dare
say it is this that is the exception.
</ed>

  Or it's expected to search for it?  What if 
there's multiple signatures,

<ed>
If in same InputDocument, Verify them all. Would the client expect anything
less ?
</ed>

 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?

<ed>
I suggested the possible use of a new SignatureType (e.g. -multi or
something). Please work with suggestions.
</ed>

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.
<ed>
The spec is pretty shy on text and semantics as it is. I see not problem
with a few more paragraphs, especially when they make things easier for the
predominant use-cases, as opposed to being optomized for the exceptions.
</ed>

  And the semantics of it seem way too 
complicated.
<ed>
Not if 95 out of 100 users read the "Simplified Scenario Semantics". That is
one InputDocument containing one Signature. DSS Implementors have to be more
savvy obviously, but can always respond "NotSupported" wherever the core
allows, and implement what they feel to be the "bang-for-the-buck"
scenarios.
</ed>

>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.

<ed>
And Verifying only one of the 2 Signatures present is more secure ???
</ed>

(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).

<ed>
First of all it is the client that sent up this payload. It is probable that
it was the DSS implementation that created them in the first place. Given
the plethora of physical world multi-signed documents, adding signatures is
likely and will be a reality. The EPM has the concept of
ParticipatingParties to control things in closed-community scenarios. But
that is for the profiles. What is your point ?
</ed>


>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.

<ed>
Nick is simply suggesting structure for the placement of the semantics. It
is probably better than spreading it everywhere. 
</ed>

>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.

<ed>
I'm all for good document organization.
</ed>


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

Which are what?  external vs. non-external?

<ed>
I would just prefix the adjective with CMS-
Example: CMS-Detached
Example: CMS-Enveloping
</ed>

Ed


To unsubscribe from this mailing list (and be removed from the roster of the
OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/dss/members/leave_workgroup.php
.