FW: Progressing on CMS issue - rev2

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

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.