Text as action on me from the last skype call with Konrad and Carlos.

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

Dear all,

As agreed please find below the outcome of my work on the action got 
from the skype call with Konrad and Carlos.

First of all I would like to mention that after reviewing the text htat 
I produced some time ago, in my opinion there is a mistake in the 
minutes. The action as collected there is:

Action [JC] Reword 3.4.9


However, there is no 3.4.9 section in the core.
What I actually updated was not the unexistent 3.4.9 but section 4.6.9.

Instead of marking what to change I have just copied the proposed text 
for the whole section:

Regards


Juan Carlos
----------------------------------

4.6.9 Optional Input <ReturnTimestampedSignature> and Output 
<TimestampedSignature>

The <ReturnTimestampedSignature> element within a <VerifyRequest> 
message indicates that the client wishes the server to update the 
signature after its verification by embedding a signature timestamp 
token as an unauthenticated attribute (see "unauthAttrs" in section 9.1 
on page 29 [RFC 3369]) or *unsigned* property (see section 6.2.5 "The 
UnsignedSignatureProperties element" or section 7.3 "The 
SignatureTimeStamp element" [XAdES]) of the supplied signature. The 
timestamped signature will be returned within the <TimestampedSignature> 
optional output.

The timestamp token will be on the signature value in the case of 
CMS/PKCS7 signatures or the <ds:SignatureValue> element in the case of 
XML signatures.

The Type attribute, if present, indicates what type of timestamp to 
apply. This document defines two values for it, namely:

   a. urn:ietf:rfc:3161 for generating a RFC 3161 timestamp token on the 
signature
   b. urn:oasis:names:tc:dss:1.0:core:schema:XMLTimeStampToken, for 
generating a XML timestamp token as defined in section 5 of this document.

Profiles that use this optional input MUST define the allowed values, 
and the default value, for the Type attribute (unless only a single type 
of timestamp is supported, in which case the Type attribute can be 
omitted).

Below follows the schema definition for these elements

<xs:element name="ReturnTimestampedSignature" 
type="dss:UpdateSignatureInstructionType"/>
<xs:element name="TimestampedSignature" type="dss:UpdatedSignatureType"/>

Procedures for handling RFC 3161 and XML timestamps are as defined in 
3.5.2.1 and 3.5.2.2.
Note: Procedures for handling other forms of timestamp may be defined in 
profiles of the Core.  In particular, the DSS XAdES profile 
[DSS-XAdES-P]defines procedures for handling timestamps against the 
document being signed, and the DSS Timestamp profile [DSS-TS-P] defines 
procedures for handling standalone timestamps.


--------------------------

Comments:

1. First paragraph. Two main changes: name of the element 
<ReturnUpdatedSignature>, and the last sentence indicating where the 
timestamped signature must go.

2. Third paragraph. Introduced explicit mention to the two URI values 
for Type attribute.

3. Sentence preceding the schema

As for the rest is basically the same.

Now, after finishing the text, something came to my mind. The former 
<AddTimeStamp> element was also used by profiles for requesting other 
types of timestamps... now the name of the element is 
<ReturnTimestampedSignature>, and now my question is if this element, 
with his name could also be further profiled by profiles for requesting 
timestamps, not on the signature value, but of other signature 
components... It is the name itself what makes me to doubt, because is 
asking for timestamping the signature, but what if the timestamp is not 
that one? would you say that the name in these other cases is misleading 
or could the name fit these other purposes?.

In fact, I have left the text on the profiles as it was, but just 
because I was uncertain and I wanted to check it with you, so that we 
all agree in one name, as we tend to be more accurate with the names 
selection....

Regards

Juan Carlos.