[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]