Action [Konrad-JC] new wordings for sections 4.6.7 and 4.6.9

[Konrad Lanz <Konrad.Lanz@labs.cio.gv.at>]

Hi Stefan,

please browse trough the following sections and change them in the document.

Konrad

> [...]
> 4.6.7 Optional Input <ReturnUpdatedSignature> and Outputs
> <DocumentWithSignature>,
> <UpdatedSignature>.
> [...]
>
> <UpdatedSignature>/<SignatureObject> [Optional]
> The resulting updated signature or timestamp or, in the case of a
> signature being enveloped in an output document, a pointer to the 
> signature.
This is used in cases 2. and 3. in the following processing.
> A DSS server SHOULD perform the following steps, upon receiving a
> <ReturnUpdatedSignature>. These steps may be changed or overridden by 
> a profile or
> policy the server is operating under. (e.g  For PDF documents 
> enveloping cms
> signatures)
>
>
> 1. If the signature to be verified and updated appears within a 
> <SignatureObject>'s
>    <ds:Signature> (detached or enveloping) or <Base64Signature> then the
>    <UpdatedSignature> optional ouput MUST contain the modified 
> <SignatureObject>
>    with the corresponding <ds:Signature> (detached or enveloping) or
>    <Base64Signature> child containing the updated signature.
> 2. If the signature to be verified and updated is enveloped, and if the
>    <VerifyRequest> contains a <SignatureObject> with a <SignaturePtr> 
> pointing to
>    an <InputDocument> (<Base64XML>, <InlineXML>, <EscapedXML>) 
> enveloping the
>    signature then the server MUST produce the following TWO optional 
> outputs, first
>    a <DocumentWithSignature> optional output containing the document 
> that envelopes
>    the updated signature, second an <UpdatedSignature> optional output 
> containing a
>    <SignatureObject> having a <SignaturePtr> element that MUST point 
> to the former
>    <DocumentWithSignature>.
> 3. If there is no <SignatureObject> at all in the request then the 
> server MUST
>    produce only a <DocumentWithSignature> optional output containing 
> the document
with the updated signature.
> No <UpdatedSignature> element will be generated.
As <DocumentWithSignature>  appears in steps 2. and 3. of the processing
above it is explained  here again:
> The <DocumentWithSignature> optional output (for the schema schema 
> refer to section
> 3.5.8) contains the input document with the given signature inserted. 
> It has one
> child element:
>   <Document> [Required]
>     This returns the given document with a signature inserted in some 
> fashion.
>
> The resulting document with the updated enveloped signature is placed 
> in the optional
> output <DocumentWithSignature>. The server places the signature in the 
> document
> identified using the <SignatureObject>/<SignaturePtr>'s WhichDocument 
> attribute.
> This <Document> MUST include a “same-document” RefURI attribute which 
> references the
> data updated (e.g of the form RefURI=“”).

4.6.9 Optional Input <ReturnTimestampedSignature> and Outputs
<DocumentWithSignature>,
<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" and section 7.3 "The
SignatureTimeStamp element"
[XAdES]) of the supplied signature.

The timestamp token will be on the signature value in the case of
CMS/PKCS7signatures
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"/>

A DSS server SHOULD perform the steps 1. - 3. as indicated in 4.6.7,
upon receiving a
<ReturnTimeStampedSignature> replacing <UpdatedSignature> by
<TimestampedSignature>.

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.