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

["Nick Pope" <pope@secstan.com>]

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.

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

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.

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.

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

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.

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

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


> -----Original Message-----
> From: Juan Carlos Cruellas Ibarz [mailto:cruellas@ac.upc.es]
> Sent: 04 May 2004 14:30
> To: dss@lists.oasis-open.org
> Subject: [dss] Discussion on outstanding issues for the core.
>
>
>
> Dear all,
>
> We are sending this email for completing the action point put on
> the chairs of starting the discussion on the outstanding issues for the
> core (which
> were summarised by Ed and Trevor in the conf. call of 4 May 2004) and
> encouraging members to participate, so that we can come to a resolution
> as soon as possible (ideally for the next conf. call).
>
> We reproduce below a previously sent message that summarises the issues
> and the proposal raised by Ed.
>
> Regards
>
> Nick and Juan Carlos.
>
> -------------------------------------------
>
>
>
> At the last DSS meeting it was agreed that Trevor and Ed would take
> discussions forward on how CMS support would be covered in the Core and
> extend the core as necessary.
>
> As a result of these discussions a possibly approach was identified (see
> Possible Approach below).  However, there was disagreement as to whether
> this approach fitted in with the current direction being taken in
> the Core.
> Some issues arose regarding support for CMS within the core which it is
> considered the views of the whole group be sought before progressing
> further.
>
> The discussion has been around the following 3 points:
>
> 1) to what extent is CMS supported in the core, and what changes
> to the spec
> will this mandate
> More specifically:  Allowing "enveloping CMS" signatures in
> <SignatureObject>
> requires making <InputDocuments> optional.
>
> 2) can the "single signature in single document" scenario be
> improved on by
> making it easier for the client
> More specifically: We could allow the client to omit the <SignatureObject>
> when
> only a single XML-DSIG is present in a single input document.
>
> 3) should multi-signature documents be specified in the core should
> implementations wish to "optionally" support them ?
> More specifically: Should clients be able to verify multiple
> signatures in a
> single request/response?
>
> The approach given below is based on a "yes" to all of the above.
>
> Nick Pope, Juan Carlos
>
> Possible Approach
> -----------------
>
> In 1.3 I would clarify the degree of support provided in the core and the
> role of the profiles as it pertains to CMS. Notes unchanged below.
>
> - support only basic CMS signature handling in the core
>      - 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)
>
>
> In section 4.3 we could enumerate the processing steps for CMS as well.
> Perhaps a 4.3.1 and 4.3.2 The CMS equivalent steps are much simpler and
> would probably need to include only the CMS equivalent steps corresponding
> to steps 1, 5, and 6 from XMLDSIG.
>
> In section 4.1 add text to explain the following:
>
> - mark InputDocuments as [Optional] to support single signature verify
> scenario (CMS)
> - mark SignatureObject as optional to support single signature verify
> scenario (XMLDSIG)
>
> Further semantics could be included as follows:
>
> There are cases when SignatureObject or InputDocuments can be omitted from
> the Verify request. When only one signature contained in one InputDocument
> exists, XMLDSIG verification can omit the SignatureObject for enveloped or
> enveloping signatures. Similarly for CMS verification of single
> signatures,
> requests can omit the InputDocuments when Verifying CMS enveloping
> signatures. The SignaturePtr construct is intended for use when either 1)
> verification of a specific XMLDSIG signature is requested, or 2) multiple
> XMLDSIG signatures are present in an InputDocument and multi-signature
> verification is NotSupported by the implementation, and the request is
> forced to specify which signature is to be Verified.
>
> If more than one XMLDSIG signature appears in the only
> InputDocument and the
> SignatureObject is omitted, the DSS implementation must either 1)
> Verify all
> signatures, or 2) return urn:oasis:names:tc:dss:1.0:result:NotSupported if
> they cannot perform the Verify. If multiple InputDocuments exist, the
> WhichDocument element can be used by the implementation, although this is
> also optional. Please refer to section 3.4 OptionalInputs and Outputs for
> specific semantics on OptionalInput processing when multiple
> signatures are
> present.
>
>
> In section 2.5 add text to explain the fact that should multiple input
> documents be present and one of them contains the signature(s), that the
> WhichDocument element would be sufficient to point the implementation at
> where signature validation should start. This would be true for either
> single signature present, or multiple signatures present in the document
> pointed to by WhichDocument.
>
> - allow WhichDocument to be used without an XPath element (i.e. make XPath
> optional within SignaturePtr)
>
>
> The suggestion below has not been fleshed out by the team as yet.
>
> - allow requests to specify the presence of multiple signatures in an
> InputDocument through either 1) new SignatureType URNs (e.g.
> multi) or 2) a
> new OptionalInput element. This would represent a more explicit expression
> of request details on the client's part, but would help improve the
> readability of the semantics and any policy/profile specific handling. I
> believe it would simplify things for the implementation as well.
> SignatureType is not presently envisioned for use in the Verify and would
> have to be added for option 1). Option 2) might be a little more
> consistent
> given that it is by definition an optional input. The team (4 of
> us) should
> decide.
>
>
> Section 4.5.2 should state that this would apply to all signatures should
> more than one exist.
>
> Section 4.5.3 should state that
> urn:oasis:names:tc:dss:1.0:result:NotSupported should be returned if
> multiple signatures are present in any of the InputDocuments.
>
> Section 4.5.5 should state that
> urn:oasis:names:tc:dss:1.0:result:NotSupported should be returned if
> multiple signatures are present in any of the InputDocuments.
>
> Section 4.5.6 should state that
> urn:oasis:names:tc:dss:1.0:result:NotSupported should be returned if
> multiple signatures are present in any of the InputDocuments.
>
> Section 4.5.7 should state that either 1) all signatures will be
> updated as
> instrcuted, or 2) that
> urn:oasis:names:tc:dss:1.0:result:NotSupported should
> be returned if multiple signatures are present and the implementation is
> unable to update all the signatures.
>
> Section 4.5.8 should state that
> urn:oasis:names:tc:dss:1.0:result:NotSupported should be returned if
> multiple signatures are present in any of the InputDocuments.
>
> Section 4.5.4 ProcessingDetails should stated that
> implementations (not just
> profiles) are free to use the unbounded sub-elements of ProcessingDetails
> and the extensible DetailType element to handle which signature
> the details
> apply to when more than one signature exists in an InputDocument. Other
> suggestions are welcome.
>
>
>
>
> 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_wor
kgroup.php.