Comments on EPM-profile

[cruellas@ac.upc.es]

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.