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

[Trevor Perrin <trevp@trevp.net>]

Ed,

There's good points here.  I still think we shouldn't graft these things 
onto the current protocol, it's too messy.  But maybe we should *replace* 
the current Verify protocol with an approach based on the client sending 
documents and DTDs and the server resolving <ds:Reference>s himself, 
instead of having the client spoon-feed the input documents to the server.

Well, I dunno.  That's a lot to think about.  All I'm saying now is, maybe 
this is better viewed as an alternative to our current way of doing things, 
instead of an addition.


Trevor



At 10:44 PM 5/6/2004 -0400, Edward Shallow wrote:
>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
>.
>
>
>
>
>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.