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


Help: OASIS Mailing Lists Help | MarkMail Help

dss-x message

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

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

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.<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.


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.


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


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


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.

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