Re: Signature Properties

Hi Frederick,

Some comments to your proposal:

1. XAdES spec actually specifies a number of what you call properties.

2. In the simplest case, all the XAdES properties occur within a 
ds:Object as indicated below:

<ds:Object>
   <xades:SignedProperties Id="..."> ...... </xades:SignedProperties>

   </xades:UnsignedProperties> ..... </xades:UnsignedProperties>

3. Properties within <xades:SignedProperties> element are actually 
signed by the signature itself, ie, there is a ds:Reference element that 
refers to this element -note the Id attribute in xades:SignedProperties-

4. Properties within <xades:UnsignedProperties> are not covered by the 
signature and this is the place where the verifier may add, at 
verification time, verification information -certificates, CRLs, OCSP 
responses and other material used for verifying the signature-, and 
preservation information -time-stamps for securing all the material as 
time goes by for getting long-term signatures.

5. Below follows the list of signed properties, i.e. properties that the 
signer may incorporate  to the XML Sig structure and sign with the 
signature.

a. SigningTime (indication -not secured by a trusted third party- by the 
signer when the signature was purportedly created).

b. SignatureProductionPlace (indication where the signature was generated)

c. CommitmentTypeIndication: indication of the commmitment endorsed by 
the signed when signing a certain data object.

d. DataObjectFormat: indicationo f the format of the data object signed.

e. SignaturePolicyIdentifier: URI (or OID) of a policy indicating the 
rules that govern the creation of the signature and the verification of 
such signature. BTW, this seems to me quite the like of what you call 
"Usage property". The property also contains information of where the 
document may be downloaded and even the digest value of the electronic 
document specifying these rules. It even allows some additional 
qualifiers (for instance a message that could be displayed to the human 
being running hte verification application reporting the policy that is 
being used).

f. SignerRole. This is a property indicating the role played by the 
signer: this role may be claimed by the signer, or may be certified by a 
trusted third party (attribute authority).

g. A time-stamp on all the signed data objects or time-stamps on 
selected signed data objects. These properties allow to prove that the 
signed data objectes existed before the time indicated within the 
corrseponding time-stamp.

6. Below follows the list of properties that may be added after the 
computation of the ds:SignatureValue (ie after the actual signature 
computation)

a. SignatureTimeStamp. This is a time-stamp token actually produced by 
the TSA. XAdES is able to incorporate here RFC-3161 (ASN.1) and DSS 
(XML)  time-stamp token. I would say that this is related with the 
TimeStampTYpe you specify -btw, that element only contains two times, 
but nothing htat provides security, like a signature by a TSA as in 
actual time-stamp tokens....

b. CompleteCertificateRefs and COmpleteRevocationRefs. These elements 
contain identifiers and digest values of all the certificates and 
revocation related material (CRLs or OCSP responses) respectively, used 
in the verification process. They also may provide URI attributes 
indicating where they may be retrieved.

c. SignatureAndReferencesTimeStamp: A time-stamp on the orginal 
signature plus the references aforementioned. The inclusion of this 
time-stamp serves to prove when the verifier has gained access to the 
verification material and has actually verified the signature.

d. CertificateValues and RevocationValues. This time, if one wants to 
preserve the signature for a number of year (in certain European 
scenarios this may be required for about 10 to 15 years), these 
properties incorporate all the certificates and revocation values used 
by the verifier for carrying out the verification.

e. ArchiveTimeStamp: this is a property containing a time-stamp on 
everything that appears within the XML signature structure before its 
addition. As time goes on, new ArchiveTimeStamps are added to the 
signature to counter the expiration of the revocation material and also 
to counter the break of certain algorithms and key material.

After this brief summary I would suggest to approach the problem of the 
XML signature properties in the following way:

1. We identify requirements for properties.

2. We check if these requirements are satisfied for properties in other 
specifications (XAdES is only one, might be others, but specially XAdES)

3. If there exist properties in XAdES that already satisfy these 
requirements, then I would personaly propose to make reference to this 
specification...it could even be envisaged the possibility that if it is 
thought that a certain degree of improvement of a certain XAdES property 
should be achieved, to establish contacts with ESI TC in ETSI and try to 
reach some agreement.

4. If there is not any property in XAdES (or other specs) addressing a 
certain requirement, then proceed to specify a new one.

The rationale for this strategy is that there are a number of XAdES 
implementations around the world (not only in Europe, but also in 
Asia...at the last remote plugtests organized by ETSI more than 20 XAdES 
implementations participated), and I personaly think that seeing 
different properties covering the same needs in different standards 
would introduce a high degree of concern and would not help 
implementers, and would also be negative for W3C and ETSI themselves.

Having said that, I would initially say that the two properties that you 
mention in your document overlap with the 
xades:SignaturePolicyIdentifier property and with xades:SigningTime 
or/and xades:SignatureTimeStamp....may I suggest to take a close look to 
those ones before takign a final decission on that?


Regards

Juan Carlos.

Frederick Hirsch escribió:
> 
> I believe it would be useful for the XML Security WG to produce a 
> specification that defines some basic Signature Properties so that 
> various communities that need such properties are able to use a 
> consistent set of definitions and avoid rework.
> 
> To this end I've created a draft for consideration.
> 
> 1. Does the WG agree this would be a useful deliverable
> 
> 2. Can we release this at the same time as 1.1 (but it has its own 
> namespace)
> 
> 3. Please review and comment on the draft at
> 
> http://www.w3.org/2008/xmlsec/Drafts/xmldsig-properties/
> 
> Thanks
> 
> regards, Frederick
> 
> Frederick Hirsch
> Nokia
> 
> 
> 
>

Received on Thursday, 11 December 2008 16:23:41 UTC