[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Comments on EPM-profile
Dear Ed, I have read the EPM profile that you submmitted some days ago. Please find my comments in the text file attached to this email. Regards Juan Carlos.
Dear Ed, I have read the EPM profile that you submmitted some days ago. What follows below is a set of comments and questions that have come up to my mind as I have gone through this very good document. This is why this message may be a bit lengthy. Sorry about that. 1. COMMENTS ON OVERLAP WITH XAdES Profile. I've decided to start with this set of comments for obvious reasons. After my first reading, I have identified a number of common things that EPM and XAdES profile may do. a. Both profiles allow for requesting and issuing Time-stamps on signature,ie, on <ds:SignatureValue> element. The main differences are: 1. Ways of requesting its computation: a. XAdES-prof. makes usage of <SignatureForm> optional input containing an URI that identifies the signature form that contains this specific time-stamp. b. EPM-prof. uses <AddTimeStamp> element. (XAdES-prof. uses this element for requesting time-stamps on documents to be signed). The profile also allows generate time-stamps on the signature value by requesting PostmarkedReceipt, but this is an operation whose semantics are beyond the scope of XAdES profile. 2. Types of time-stamps returned. a. Beign XAdES-prof. fully addressed to deal with XAdES and TS 101733 (RFC 3126) signatures, this profile allows the inclusion, within a XMLDSIG signature, of a XML time-stamp OR a RFC3161 (as xades:TimeStampType defined in XAdES spec shows). However, what is not allowed is to include within a TS101733 a XML time-stamp. The reason is obvious: when XAdES spec was written there was not a proposed XML time-stamp format in any standardization body. b. EPM prof. links the format of the signature with the format of the time-stamp. QUESTION #1: Could not also be useful, even as an interim solution to allow the inclusion of a RFC3161 time-stamp within a XMLDSIG signature? 3. Ways of incorporating these time-stamps. a. XAdES signatures define a standard way of incorporating the time-stamp. They even give a specific name identifying this time-stamp as one covering only the <ds:SignatureValue> element. XAdES-profile establishes the generation of XAdES or TS 101 733 signatures with their well-defined ways of incorporating them to the signatures. b. It seems to me that when the siganture is a CMS it mandates to proceed as stated by TS 101733, as it even makes usage of the OID defined there. However, when talking about XMLDSIG, nothing is said on how to incorporate it to the <ds:Signature> structure. Section 3.2.4.3 seems to give a different treatment: include it within the signature according to TS101733, and returning the isolated time-stamp for XML signatures... SUGGESTION #1: give indication on how the server will incorporate the time-stamp within a XMLDSIG. SUGGESTION #2: although this may be going too far, could it be possible to suggest incorporation according XAdES spec? SUMMARY: EPM-prof and XAdES-prof allow for requesting the same time-stamp. They make usage of different elements for requesting it. They allow different combinations in formats of time-stamps and signatures. They share the same kind of incorporation for CMS-based signatures (hte TS 101733 way), but it is not clear for XMLDSIG-based signatures. QUESTION#2 Should we try to agree one common way of managing this type of time-stamp for both profiles? b. Both profiles allow to include in a the response validation data, ie, CRL inforamtion or OCSP responses information. The main differences are: 1. Ways of requesting it: a. XAdES-prof. uses the <SignatureForm> element to request a signature that contains itself such an information. b. EPM-prof uses the <ReturnX509Info> flag. 2. Type of information returned. a. XAdES-prof. relies on XAdES and TS101733 signature structures. They allow to incorporate references to validation data (they contain hash values of CRLs or OCSP or other data, as well ass identifiers of these pieces of data), or validation data themselves (CRL values, OCSP responses values, etc.). b. EPM-prof allows to return values of OCSP responses and a set of values extracted from a CRL. But it seems that no CRL value itself may be returned. 3. Ways of returning them. a. XAdES-prof. allows returning this information directly incorporated in the Signature, as specified in XAdES and TS 101733. b. EPM-profl allows returning this information within the <epm:X509Info> element, separated from the signature. SUMMARY: EPM-prof and XAdES-prof allow both for requesting validation data to the servers. They differ in the way of doing that, the type of information returned and the way in which it is returned. MY personal view is that these differences are less relevant as the former ones on the time-stamp, as in fact, it is not even clear that within the context of EPM usage the validation data should be incorporated within the structure of the signature. If this was the case, then perhaps we could talk of that. 2. COMMENTS ON THE DOCUMENT ITSELF. Below follows a number of comments and questions that have come up to my mind as I have gone through the document. COMMENT#1. Section 3.1.2.3. SignaturePlacement. I find the text in the first paragraph a bit confusing, mainly because it seems to be jumping from one case to the other. See below: "When creating RFC3275-compliant XML Digital Signatures as indicated by the <SignatureType> optional input element, the <SignaturePlacement> optional input element is not required. The EPM will assume an enveloped signature unless an <EnvelopingSignature> optional input is present. The resultant ds:Signature will be returned in the <SignatureObject> as per [DSSCore]." --->The first sentence is dealing with enveloped signatures. The second says what to do for getting envelopind signatures, and the third says where the enveloping signatures will appear but without mentioning that it is talking of enveloping signatures. " Additionally, the resultant signature will be inserted after the last child of the root node of the <Document> element of <InputDocuments> and will be returned in the <DocumentWithSignature> element. " ---> Now the text jumps again and says where the enveloped signature will be returned. This is default handling. For <EnvelopingSignature>’s the EPM requires the <Document>’s RefURI and ID attributes to construct the <DocumentWithSignature>. The standalone ds:Signature will also be placed in the <SignatureObject>. ---> And finally here it comes back to talk about enveloping.... SUGGESTION#3: Could it be possible to reorganize the text and give all the information for each case packed in the same paragraph? COMMENT#2. Section 3.1.2.4 and its relationships with examples in section 6. QUESTION#3. I understand that even the XML input document is encoded in Base64, am I OK?. If this is OK, should not the examples start with <DocumentWithTemplate> instead with <Document>? QUESTION#4: From the text in third paragraph I understand that in a request you have <Document> or <DocumentWithTemplate> element... am I right? COMMENT#3: Section 3.1.4.6 <SignatureObject> as optional input This section says: "This optional input is only used when users are requesting a timestamp <SignatureType>, and additionally would like that timestamp embedded into an existing signature they may have in their possession." QUESTION#5: should not be better to make use of the protocol verify with the option of updating a signature? I guess that you may answer me that in this way you are not requesting to verify the signature, but only incorporating the time-stamp, isn't it? But then are not you open the door to a situation where a time-stamp may be added to a signature that has not been verified? COMMENT#4: Section 3.2.3.4 Editorial: "Correspondingly, when the EPM issues a PostMarkedReceipt as a result of a Verify operation using <ReturnUpdatedSignature> or <IssuePostMarkedReceipt>, the EPM is attesting to both the validity of both the verified ..." QUESTION#6: are the two "both" at the end intentional? QUESTION#7: Doesthe <TimeStampToken> element contain a RFC3161 time-stamp? This is what I have concluded from the text, but it is not explicitly said there. Shoudl not be better to clearly indicate this? COMMENT#7: Section 4.1.1.7 QUESTION#8: Does the text: "If this receipt is required, the user must pass in the single signature to be verified along with its associated document in a single <Document> element without either a <SignaturePtr> or a <SignatureObject>." mean that this is only for enveloped signatures? COMMENT#6: Sections 4.2.2 and 4.2.3.1. QUESTION#9:Text in both sections are the same. I must confess that I had lost a number of details when I arrived here, but is it possible that <SignatureObject> and <DocumentWithSignature> may both be returned on the same conditions in the request?. From the examples and what I have read, I think that if <ReturnUpdatedSignature> is added, only the second one may be generated? Well, I think that these are my comments and questions so far. Sorry by this lengthy message..... Regards Juan Carlos.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]