OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: XML time-stamp processing text for time-stamp profile (II)


Dear all,

After reading Ed's text on binary time-stamp, I have modified the 
proposal for xml time-stamps in the time-stamp profile for making an 
explicit mention to the two scenarios described by Ed. This time I copy 
below the text for both sections. The first one has not suffered any change.

Regards

Juan Carlos.

3.3 Processing for XML time-stamps

If the <dss:SignatureType> content is 
“oasis:names:tc:dss:1.0:core:schema:XMLTimeStampToken” or when this 
element is not present and the server decides to generate a XML 
time-stamp, it MUST follow the rules established in the core for 
generating digital signatures (section 3.3 of [DSSCore]) with the 
changes mentioned below.

The server MUST perform the following steps between steps 2 and 3 of 
[DSSCore] section 3.3.1:

2.a Generate a dss:TSTInfo element as defined in [DSSCore] section 5.1.2 
with the suitable contents, and envelope it within a new ds:Object.
2.b Generate a new ds:Reference element referencing (explicitly or 
implicitly) the aforementioned ds:Object enveloping the TSTInfo. Set its 
“Type” attribute to 
“urn:oasis:names:tc:dss:1.0:core:schema:XMLTimeStampToken”.
2.c Insert this ds:Reference element within the ds:SignedInfo and the 
ds:Object element within the resulting ds:Signature element as mandated 
by [XMLSig]


4.3 Processing for XML time-stamps

There are two scenarios under which this profile can verify a timestamp. 
In both cases the timestamp to be verified is included in the 
SignatureObject as specified by [DSSCore]. The scenarios are as follows:

1. Only the timestamp is present in the Verify request, and the data 
that was timestamped is not present
2. Both the timestamp and the timestamped data are present in the 
request with the timestamped data passed in as an input document

In the second scenario the server MUST proceed as follows:

1. Extract the dss:TimeStamp element from the dss:SignatureObject element.
2. Proceed as indicated in section 4.3.2.2 steps 2 to 6 (both included) 
of [DSSCore]. This ensures that the arrived signature is a XML 
time-stamp as defined in [DSSCore] section 5.1.2 and that it envelopes 
and signs the corresponding dss:TSTInfo element.
3. Proceed as indicated in section 4.3 steps 2 to 4 (both included) of 
[DSSCore] for each of the rest of ds:Reference elements within the 
ds:SignedInfo element. This will allow the server to retrieve the 
time-stamped documents from the corresponding ds:Reference elements, to 
extract them from the request, to validate their digests, to verify the 
signature value, and to generate the corresponding result value.

In the first scenario the server MUST:

1. Perform steps 1 and 2 above.
2. Proceed as indicated in section 4.3 step 3 and builds up the 
corresponding result.

It should be noted that under scenario 1 above, it is assumed that the 
client is taking the responsibility for proceeding as indicated in 
section 4.3 step 2 themselves. Under scenario 2, the server is 
performing this step for the client caller.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]