[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.
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.
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]