Comments to PDF Advanced Electronic Signatures Profile of the OASIS DSS Version 1.0 wd0.3

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

Dear all,

Please find below my comments to the PAdES profile wd03..... I think that it is good enough as to start progressing it as soon as some of the questions below are discussed and agreed.

Best regards

Juan Carlos.

3.3.2.1<InputDocumenta>

TBD: Do we want to address the usage of <DocumentHash> for privacy concerns where the PDF cannot be sent to the server? As this use case cannot involve any specific PDF signature features (there's no document to add a visible signature field for instance), briefly mentioning the possibility should suffice?

JC: I would personally include it, unless there is a good reason for not including it, although I am not able to think of what would the fact that a document is a PDF document instead an XML document, imply in terms of use cases for not allowing it.

<SuggestedDigestAlgorithm>

JC: My personal view is that if there are good reasons for having it in the PAdES  profile, there are likely the same good reasons for any other signature format: suggest to move it to the core.

<SignatureQualityLevel>.

JC: should check STORK levels. Question, does this anything to do with the EU Regulation ( advanced electronic signatures, advanced electronic signatures/seals based on a qualified certificate for electronic signatures/seals, and qualified electronic signatures/seals)?

Optional Input <SignatureType> 

Only one? I mean at present we have now at least two sets of PAdES signatures: the one specified by ETSI TS 102 778, ETSI TS 103 172 and the ones specified by ETSI EN 319 142-1 and -2.....By the way, this is also true for CAdES and XAdES....

Optional Input <SignatureLevel>

Same as above: two sets of specs with two sets of different acronyms for levels...and this is also true for CAdES and XAdES

 <SignedProperties> 

I agree with what is stated there...and also with supporting XML representations of properties....will work on this.

Element <VisibleSignatureItemsConfiguration>

The ideas listed in this clause seem reasonable to me...they should be soon developed

1.1.1.1.1.1     Element <GenerateUnderSignaturePolicy>

I agree that this could have an impact on the appearance of the SignaturePolicyIdentifier signed property, apart from the fact that the adherence to a certain signature policy has impact on how the signature is generated. Will take a look and provide comments.

In addition to that, would not this be also something general to other formats?...I would go further: there was a signature policies profile that has not been progressed but could now be progressed as a way of allowing that this kind of features could also be incorporated in requests for C/XAdES

Use of UsedSignaturePolicy/SupportedSIgnaturePolicy: would suggest to progress and consolidate the SignaturePolicy profile and leave them out from the PAdES

<InputDocument>

Leaving just InputDocument with the signature would make it easier, isn't it? No place for errors in pointers if we allow SignatureObject with SignaturePtr....

<VisibleInformationFormat>. ...

I would initially leave it out.

<VerifyUnderSignaturePolicy>: propose to progress the signature policy profile and leave it out.