[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]