Re: Emailing: comentarios-perfil-epm-with-comments.rtf

[Juan Carlos Cruellas <cruellas@ac.upc.es>]

Dear Ed,

Sorry for the late reaction... it takes time to re-start
things after holidays....
Anyway, below follow my reactions to your reply.
Thanks

Juan Carlos.


{\rtf1\ansi\ansicpg1252\deff0{\fonttbl{\f0\fnil\fcharset0 Courier New;}{\f1\fmodern\fprq1\fcharset0 Courier New;}}
{\colortbl ;\red0\green0\blue255;\red255\green0\blue0;}
\viewkind4\uc1\pard\lang1033\f0\fs20 Dear Ed,\par
\par
I have read the EPM profile that you submmitted some days ago.\par
\par
What follows below is a set of comments and questions that have\par
come up to my mind as I have gone through this very good document.\par
This is why this message may be a bit lengthy. Sorry about that.\par
\par
1. COMMENTS ON OVERLAP WITH XAdES Profile.\par
\par
I've decided to start with this set of comments for obvious reasons.\par
After my first reading, I have identified a number of common things that EPM\par
and XAdES profile may do.\par
\par
a. Both profiles allow for requesting and issuing Time-stamps on signature,ie,\par
on <ds:SignatureValue> element. The main differences are:\par
\par
\tab 1. Ways of requesting its computation:\par
\par
\tab\tab a. XAdES-prof. makes usage of <SignatureForm> optional input containing\par
\tab\tab    an URI that identifies the signature form that contains this \par
\tab\tab    specific time-stamp. \cf1\b\f1 Good\cf0\b0\f0\par
\par
\tab\tab b. EPM-prof. uses <AddTimeStamp> element. (XAdES-prof. uses this element\par
\tab\tab    for requesting time-stamps on documents to be signed). The profile\par
\tab\tab    also allows generate time-stamps on the signature value by requesting\par
\tab\tab    PostmarkedReceipt, \cf1\b\f1 True, but the PostMarkedReceipt acts as receipting mechanism\par
 \tab\tab    to the fact that the EPM is holding evidence data for the customer \par
\tab\tab\tab\cf2 <JC>Yes, I understood the purpose</JC>\tab\cf1\tab\tab\par
\tab\tab    \cf0\b0\f0 but this is an operation whose semantics are beyond\par
\tab\tab    the scope of XAdES profile.\par
\par
\tab 2. Types of time-stamps returned.\par
\par
\tab\tab a. Beign XAdES-prof. fully addressed to deal with XAdES and TS 101733 (RFC 3126) \par
\tab\tab    signatures, this profile allows the inclusion, within a XMLDSIG signature,\par
\tab\tab    of a XML time-stamp OR a RFC3161 (as xades:TimeStampType defined in XAdES\par
\tab\tab    spec shows). However, what is not allowed is to include within a TS101733\par
\tab\tab    a XML time-stamp. The reason is obvious: when XAdES spec was written there\par
\tab\tab    was not a proposed XML time-stamp format in any standardization body.\par
\par
\tab\tab b. EPM prof. links the format of the signature with the format of the\par
\tab\tab    time-stamp. \cf1\b\f1 Not entirely true. On a Verify, EPM implementations are free to \par
\tab\tab    to use RFC3161 binary timestamps instead of including the TstInfo reference.\par
\tab\tab    See 3.2.3.4 last 2 paragraphs. \par
\par
\tab\tab    \cf2 <JC>You are rigth: My wording was not good. What I meant is that in the Sign operation\par
\tab\tab    this freedom does not exist for the returned signature: section 3.1.2.2 \par
\tab\tab    clearly states that depending on the\par
\tab\tab    signature requested the time-stamp will be RFC3161 or DSS...it is under this \par
\tab\tab    perspective that I made the comment.</JC>\par
\tab\tab    <JC>In addition section 3.2.3.4 only refer to <PostMarkReceipt>, not to \par
\tab\tab    <SignatureObject></JC>\par
\cf1\tab\tab    \cf0\b0\f0\par
\par
\tab    QUESTION #1: Could not also be useful, even as an interim solution to allow\par
\tab    the inclusion of a RFC3161 time-stamp within a XMLDSIG signature? \cf1\b\f1 Yes, this is provided \par
\tab    for in the profile, see above answer. \par
\cf2\tab    <JC>Sorry, but I do not see it when speaking of the time-stamp of a signature. I\par
\tab    see it for the PostMarkReceipt, as you mention, but not for the signature...\par
\tab    I think that if you mean that EPM servers may generate a XMLDSIG and include a RFC3161\par
\tab    base-64 encoded within it, then the place for saying that is section 3.1.2.2,\par
\tab    the first one that mentions the generation of a signature AND its corresponding\par
\tab    signature time-stamp, and gives rules on how\par
\tab    to compute it. If your requirements do not contemplate it, then this is a\par
         different story, but taking into account that XMLDSIG are there, that RFC3161\par
\tab    time-stamps are there, and that DSS XML time-stamps are not yet there, although\par
\tab    they may appear soon, perhaps this is a strong constrain</JC>\par
\b0\f0\par
\cf0\par
\tab 3. Ways of incorporating these time-stamps.\par
\par
\tab\tab a. XAdES signatures define a standard way of incorporating the time-stamp. They\par
\tab\tab    even give a specific name identifying this time-stamp as one covering     \par
\tab\tab    the <ds:SignatureValue> element. XAdES-profile establishes the generation\par
\tab\tab    of XAdES or TS 101 733 signatures with their well-defined ways of incorporating\par
\tab\tab    them to the signatures.\par
\par
\tab\tab b. It seems to me that when the siganture is a CMS it mandates to proceed as\par
\tab\tab    stated by TS 101733, as it even makes usage of the OID defined there.\par
\tab\tab    \cf1\b\f1 Actually there are 3 different variations supported on timestamping for the Sign \par
\tab\tab    protocol. They are outlined in sections 3.2.4.1 thru 3.2.4.3. Only the last\par
\tab\tab    describes embedding of timestamps in the incoming signature. The first two \par
\tab\tab    approaches both return standalone timestamps.\par
\par
\tab\tab\tab\cf2 <JC>Before going further, I will summarize my interpretation of the text:\par
\tab\tab\tab secion 3.1.2.2 is talking about the case when the  client requests to\par
\tab\tab\tab sign something and as additional input also requests to add the signature\par
\tab\tab\tab time-stamp value. Apart from that I tend to think that sections\par
\tab\tab\tab 3.2.4.1 thru 3.2.4.3 refer to situations where the client requests only\par
\tab\tab\tab the time-stamp of a document, its hash or even a signature already existing. </JC>\par
\tab\tab    \tab\par
\tab\tab\tab <JC>I think that I did not circunscribe the scope of my comment. \par
\tab\tab\tab This comment was restricted to the case when the client requests to\par
\tab\tab\tab sign something and as additional input also requests to add the signature\par
\tab\tab\tab time-stamp value. It did not addressed the requesting of a time-stamp of a\par
\tab\tab\tab document, a hash or a previously generated signature.\par
\tab\tab\tab And in section 3.1.2.2 it is written: \par
\tab\tab\tab "The RFC3161 timestamp token will be added as an unauthenticated attribute, as\par
\tab\tab\tab defined above, of the generated signature. The result will be returned in \par
\tab\tab\tab <SignatureObject>". This seems to say that whenever you use the <AddTimeStamp>\par
\tab\tab\tab and an RFC3161 is generated then the TS101733 signature will be generated with\par
\tab\tab\tab the corresponding siganture timestamp field.</JC>\b0\f0\par
\cf0\par
\tab\tab    However, when talking about XMLDSIG, nothing is said on how to incorporate it to the\par
\tab\tab    <ds:Signature> structure. \cf1\b\f1 Clearly stated in 3.2.4.1 thru 3.2.4.3 \par
\tab\tab    XMLSig is handle as per DSSCore section 5.1.1 \par
\tab\tab\tab\par
\cf2\tab\tab\tab <JC>Well, section 3.2.4.3 heading is: "Embedding a signature timestamp into a user-provided\par
\tab\tab\tab <SignatureObject>", but I was not talking of this case, \par
\tab\tab\tab but the one treated in section 3.1.2.2: request of a \par
\tab\tab\tab signature generation and the corresponding \par
\tab\tab\tab timestamp.</JC>\par
\tab\tab\tab <JC>In addtion In this section you say that when the client requests a time.stamp\par
\tab\tab\tab of an already existing XML signature, then \par
\tab\tab\tab "dss:SignatureObject of type ds:Signature is used for returning XMLSig\par
\tab\tab\tab timestamps including the TSTInfo type as child of the referenced Object\par
\tab\tab\tab element as per section 5.1.1".. What about saying: \par
\tab\tab\tab "for returning the\par
\tab\tab\tab embedded XML timestamps in the XMLSig sent by the client. These timestamps\par
\tab\tab\tab will include...."?\par
\tab\tab\tab The idea is that what is returned is the XMLSig sent by the client that contains\par
\tab\tab\tab somehow the time-stamp... and now I still have the question: how this XML timestamp\par
\tab\tab\tab is embedded the XMLSig?.</JC>\par
\par
\cf1\tab\tab    \cf0\b0\f0 Section 3.2.4.3 seems to give a different treatment:\par
\tab\tab    include it within the signature according to TS101733 \cf1\b\f1 no mention of TS101733 is made\cf0\b0\f0 , \par
\cf1\b\f1\tab\tab\tab\par
\cf2\tab\tab\tab <JC>Not, but I think that there is an implicit mention: in "dssSignatureObject\par
\tab\tab\tab of type dss:Base64Signature is used for returning RFC3161 timestamps embedded within\par
\tab\tab\tab a signature"... as the only mechanism described in the document for doing this is\par
\tab\tab\tab the one present in section 3.1.2.2 that is clearly the one specified in T101733.</JC>\b0\f0\par
\cf0\tab\tab    \par
\tab\tab and returning the isolated time-stamp for XML signatures ... \cf1\b\f1 ??? \par
\par
\cf2\tab\tab\tab <JC>Rigth: nothing to do with isolated timestamps.Sorry</JC>\par
\cf1\par
\tab\tab    clearly states "... as per section 5.1.1 of DSSCore ..." in 3.2.4.3\par
\par
\cf2\tab\tab\tab <JC>Section 5.1.1 of DSSCore does not say how to embed a XML timestamp\par
\tab\tab\tab within a XMLSignature, this is all I mean</JC>\par
\cf1\tab\tab\tab\par
\cf0\b0\f0\par
\tab    SUGGESTION #1: give indication on how the server will incorporate the time-stamp\par
\tab    within a XMLDSIG. \cf1\b\f1 Already done, see above. This is the reason for sections 3.2.4.1 thru 3.2.4.3\par
\tab    which exist solely to clarify timestamp handling in the Sign protocol.\par
\par
\cf2\tab\tab <JC>Sorry, I still do not see it...</JC> \b0\f0\par
\cf0\par
\tab    SUGGESTION #2: although this may be going too far, could it be possible to suggest\par
\tab    incorporation according XAdES spec? \cf1\b\f1 Possibly, but only 1 of the 3 timestamp variations\par
\tab    would be supported via XAdES. \par
\tab\tab\par
\cf2\tab\tab <JC>If my interpretation is OK, then the two isolated cases are out of the scope of\par
\tab\tab XAdES, as the timestamps of these two cases are isolated</JC>\par
\cf1\par
\tab    I Assumed a signature timestamp is pretty conventional and \par
\tab    is also used in RFC3126 and therefore is not specific to XAdES. The EPM is however \par
\tab    contemplating explicit support of several XAdES forms. At that time we could make specific \par
\tab    reference to the XAdES schema. Comments ?\par
\par
\tab\tab <JC>What XAdES forms? Is the one with <SignatureTimeStamp> one of them? If so, we\par
\tab\tab can make reference to it. And this could be one way of embedding the signature\par
\tab\tab timestamp within a XMLSig.</JC>\cf0\b0\f0\par
\par
\par
\tab SUMMARY: EPM-prof and XAdES-prof allow for requesting the same time-stamp. They make\par
\tab usage of different elements for requesting it. They allow different combinations in\par
\tab formats of time-stamps and signatures. They share the same kind of incorporation for\par
\tab CMS-based signatures (hte TS 101733 way) \cf1\b\f1 this is not the only way\cf0\b0\f0 , \par
\par
\cf2\b\tab\tab <JC>The timestamps may be returned isolated but with regards to embedded timestamps\par
\tab\tab I only see one explictly described in the document: the TS101733...perhaps I have\par
\tab\tab not been able to identify the other(s),... could you point out which else appear?</JC>\tab\par
\cf0\b0\par
\tab but it is not clear \par
\tab for XMLDSIG-based signatures. \cf1\b\f1 "... as per section 5.1.1 of DSSCore ..." in 3.2.4.3\cf0\b0\f0  \par
\par
\cf2\b\tab\tab <JC>See my comments above...</JC>\par
\cf0\b0\par
\tab QUESTION#2 Should we try to agree one common way of managing this type of time-stamp\par
\tab for both profiles? \cf1\b\f1 the only overlap is the 3rd variation as described in 3.2.4.3.\par
\tab We could explore this small level of integration, but again I do not believe that \par
\tab CMS-based timestamp embedding is exclusive to XAdES and would rather keep it generic for \par
\tab now. Comments ?\par
\cf2\tab\tab <JC>You are right: it is not exclusive to XAdES (well, to TS101733) but in fact\par
\tab\tab it is the first one that standardizes the integration of the time-stamp within\par
\tab\tab the CMS signature, and I have not heard from any other standard to do that... \par
\tab\tab if there is a standard way of doing that, why do not use it?\par
\tab\tab In addition, the EPM has to do it in one way or the other... what you are saying\par
\tab\tab is that EPM will give freedom to implementers on how to embedd timestamps within\par
\tab\tab the signatures? would not be better to use it? In addition, you are mandating its\par
\tab\tab usage in section 3.1.2.2 although you do not mention TS101733</JC>\f0\par
\cf0\b0\par
b. Both profiles allow to include in a the response validation data, ie, CRL inforamtion or OCSP\par
responses information. The main differences are:\par
\par
\tab 1. Ways of requesting it:\par
\par
\tab\tab a. XAdES-prof. uses the <SignatureForm> element to request a signature that contains\par
\tab\tab    itself such an information.\par
\par
\tab\tab b. EPM-prof uses the <ReturnX509Info> flag.\par
\par
\tab 2. Type of information returned.\par
\par
\tab\tab a. XAdES-prof. relies on XAdES and TS101733 signature structures. They allow to incorporate\par
\tab\tab    references to validation data (they contain hash values of CRLs or OCSP or other data,\par
\tab\tab    as well ass identifiers of these pieces of data), or validation data themselves (CRL\par
\tab\tab    values, OCSP responses values, etc.).\par
\par
\tab\tab b. EPM-prof allows to return values of OCSP responses and a set of values extracted from\par
\tab\tab    a CRL. But it seems that no CRL value itself may be returned.\par
\tab\tab    \cf1\b\f1 The\cf0\b0\f0  \cf1\b\f1 ValidationData element is actually extensible in the EPM schema, and can be used to \par
\tab\tab    house any appropriate information based on implementor preferences. It is essentially a \par
\tab\tab    less specific way of doung things as compared to the XAdES. This was done to support \par
\tab\tab    EPMs with different Validation Authority setups (e.g. OCSP versus no OCSP, etc ...). Almost\par
\tab\tab    anyhting can be placed in ValidationData based on implementor-specific policy.\par
\tab\tab\tab\par
\cf2\tab\tab\tab <JC>Understood. OK</JC>\b0\f0\par
\cf0\par
\tab 3. Ways of returning them.\par
\par
\tab\tab a. XAdES-prof. allows returning this information directly incorporated in the Signature,\par
\tab\tab    as specified in XAdES and TS 101733.\par
\par
\tab\tab b. EPM-profl allows returning this information within the <epm:X509Info> element, separated\par
\tab\tab    from the signature.\par
\par
\tab SUMMARY: EPM-prof and XAdES-prof allow both for requesting validation data to the servers. They\par
\tab differ in the way of doing that, the type of information returned and the way in which it is\par
\tab returned.\par
\par
\tab MY personal view is that these differences are less relevant as the former ones on the time-stamp,\par
\tab as in fact, it is not even clear that within the context of EPM usage the validation data should\par
\tab be incorporated within the structure of the signature. If this was the case, then perhaps we\par
\tab could talk of that.\par
\par
\par
2. COMMENTS ON THE DOCUMENT ITSELF.\par
Below follows a number of comments and questions that have come up to my mind as I have gone through\par
the document.\par
\par
COMMENT#1. Section 3.1.2.3. SignaturePlacement.\par
\par
I find the text in the first paragraph a bit confusing, mainly because it seems to be jumping from\par
one case to the other. See below:\par
\par
"When creating RFC3275-compliant XML Digital Signatures as indicated by the <SignatureType> optional \par
input element, the <SignaturePlacement> optional input element is not required. The EPM will assume \par
an enveloped signature unless an <EnvelopingSignature> optional input is present. The resultant \par
ds:Signature will be returned in the <SignatureObject> as per [DSSCore]."\par
\par
--->The first sentence is dealing with enveloped signatures. The second says what to do\par
for getting envelopind signatures, and the third says where the enveloping signatures will appear\par
but without mentioning that it is talking of enveloping signatures. \par
\par
" Additionally, the resultant \par
signature will be inserted after the last child of the root node of the <Document> element of \par
<InputDocuments> and will be returned in the <DocumentWithSignature> element. "\par
\par
---> Now the text jumps again and says where the enveloped signature will be returned.\par
\par
\par
\par
This is default \par
handling. For <EnvelopingSignature>\rquote s the EPM requires the <Document>\rquote s RefURI and ID attributes \par
to construct the <DocumentWithSignature>. The standalone ds:Signature will also be placed in the \par
<SignatureObject>.\par
\par
\par
---> And finally here it comes back to talk about enveloping....\par
\par
SUGGESTION#3: Could it be possible to reorganize the text and give all the information for\par
each case packed in the same paragraph?\par
\par
\cf1\b\f1 Yes this should be clarified. I agree. I will work on this.\cf0\b0\f0\par
\par
COMMENT#2. Section 3.1.2.4 and its relationships with examples in section 6.\par
\par
QUESTION#3. I understand that even the XML input document is encoded in Base64, am I OK?. If\par
this is OK, should not the examples start with <DocumentWithTemplate> instead with <Document>?\par
\par
\cf1\b\f1 Yes, you are right. \cf0\b0\f0\par
\par
QUESTION#4: From the text in third paragraph I understand that in a request you have <Document>\par
or <DocumentWithTemplate> element... am I right?\par
\par
\cf1\b\f1 Yes, you are right.\cf0\b0\f0\par
\par
\par
COMMENT#3: Section 3.1.4.6 <SignatureObject> as optional input\par
\par
This section says:\par
"This optional input is only used when users are requesting a timestamp <SignatureType>, \par
and additionally would like that timestamp embedded into an existing signature they may \par
have in their possession."\par
\par
QUESTION#5: should not be better to make use of the protocol verify with the option\par
of updating a signature? I guess that you may answer me that in this way you are not\par
requesting to verify the signature, but only incorporating the time-stamp, isn't it?\par
\par
\cf1\b\f1 Yes, you are right. This is how I would respond.\par
\cf0\b0\f0\par
But then are not you open the door to a situation where a time-stamp may be added\par
to a signature that has not been verified?\par
\par
\cf1\b\f1 This is why we have the PostMarkedReceipt which carries that extra contractual binding.\par
The receipt concept parallels the physical world. A timestamp is just a timestamp to the EPM.\cf0\b0\f0  \par
\par
\cf2\b <JC>Understood. OK</JC>\par
\cf0\b0\par
\par
COMMENT#4: Section 3.2.3.4\par
\par
Editorial: \par
"Correspondingly, when the EPM issues a PostMarkedReceipt as a result of a Verify \par
operation using <ReturnUpdatedSignature> or <IssuePostMarkedReceipt>, the EPM is \par
attesting to both the validity of both the verified ..."\par
\par
QUESTION#6: are the two "both" at the end intentional?\par
\par
\cf1\b\f1 Yes, they are. The EPM supports both methods of asking for the PostMarkedReceipt. In both cases\par
the results are the same. A PostMarkedReceipt is returned. \par
\par
\tab <JC>But you have suppressed the first one....probably I did not \par
\tab correctly word my question. Anyway, I now agree with the text in\par
\tab version 03. </JC>  \par
\cf0\b0\f0\par
\par
QUESTION#7: Doesthe <TimeStampToken> element contain a RFC3161 time-stamp? This is what\par
I have concluded from the text, but it is not explicitly said there. Shoudl not be better\par
to clearly indicate this?\par
\par
\cf1\b\f1 It is already indicated. See 3.2.3.4 last 2 paragraphs.\cf0\b0\f0\par
\par
\cf2\b\tab <JC>OK in the third version.</JC>\par
\cf0\b0\par
\par
\par
COMMENT#7: Section 4.1.1.7 \par
\par
QUESTION#8: Does the text:\par
"If this receipt is required, the user must pass in the single signature to be verified \par
along with its associated document in a single <Document> element without either a \par
<SignaturePtr> or a <SignatureObject>." mean that this is only for enveloped signatures?\par
\par
\cf1\b\f1 I guess we could state that the PostMarkedReceipt would have to be standalone for \par
enveloping signatures ? Do you agree with this ?\cf0\b0\f0\par
\par
\cf2\b\tab <JC>If you want to also issue PostMarkedReceipt of enveloping signatures you can\par
\tab keep the PostMarkedReceipt standalone or create a new document with the enveloping\par
\tab signature and the PostMarkedReceipt being detached:\par
\par
\tab\tab <PostMarkedReceiptAndSignature>\par
\tab\tab\tab <PostMarkedReceipt>...</PostMarkedReceipt>\par
\tab\tab\tab <ds:Signature>...</ds:Signature>\par
\tab\tab </PostMarkedReceiptAndSignature>\par
\tab </JC>\par
\cf0\b0\par
COMMENT#6: Sections 4.2.2 and 4.2.3.1.\par
\par
QUESTION#9:Text in both sections are the same. I must confess that I had lost a number of details\par
when I arrived here, but is it possible that <SignatureObject> and <DocumentWithSignature>\par
may both be returned on the same conditions in the request?. From the examples and what I have\par
read, I think that if <ReturnUpdatedSignature> is added, only the second one may be generated?\par
\par
\cf1\b\f1 <ReturnUpdatedSignature> and <IssuePostMarkedReceipt> do/return the exact same thing, which is \par
influenced by <SignatureType>. Is there still an outstanding problem with this ?\par
\par
\cf2\tab <JC>Yes, you are right... I missunderstood the whole thing. Sorry.</JC>\b0\f0\par
\cf0\par
\par
Well, I think that these are my comments and questions so far.\par
Sorry by this lengthy message.....\par
\par
Regards\par
\par
Juan Carlos.\par
}