Comments to PAdES profile

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

Dear all,

Below follow some comments to the PAdES profile

1. <InputDocuments>. Technical comment.
"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?"

--> Reaction: The PAdES signature is actually a PDF dictionary in its most simple instantiation, or a set of dictionaries (if it includes LTV stuff). If we do not send the PDF document to be signed, I wonder how this(these) dictionary(ies) would be handed back to the requestor... would say that this feature would require further profiling of the returned material and would leave to the client the work of including the dictionary(ies) returned....not sure it would pay the price....

2. <SuggestedDigestAlgorithm> Editorial
What if the specification starts saying what is the content of this element, then clearly state that it only serves as a hint and consequently servers may ignore its contents, and finalize maybe with a note containing the text that now appears in the first sentence?

3. <SignatureQualityLevel>. Editorial:
"A server MAY offer clients to choose from different signature quality levels "

What about "A server MAY be able to generate different signature quality levels....". The idea of offer might lead to think of a kind of exchange between clients and servers in order to know the offer before sending the actual signing request....

4. <SignatureType>. Technical
Indeed the usage of the profile clearly indicates this is a request for a PAdES signature... however I would define it and keep it optional...

5. <SignatureForm> Technical
Agree in including new identifiers for the Baseline Profile levels (the new term for the old form word is "level" in the latest version of AdES).


6. <SignedProperties>

Would say that AllDataObjectsTimeStamp is not the name of a property for PAdES based on CMS....In fact would say that is something like content-time-stamp or so...could you please check it?

I would also agree in allowing also XML representations for signed properties. I think that it is a good idea.

7. <VisibleSignaturePolicy>.

Agree in removing it.

8. <VisibleSignatureItemsConfiguration>
"TBD: Do not support the <Item> with <ItemName> equal to “SignatureValue” as it is impossible for PDF signatures. "

Not sure what this means...

Would agree in restrcting the date formats to xsd:DateTime

Changing the structure: about the flattening proposal, the proposal is to make IncludeCaption and Orientation attributes of IncludeAttribute (which would be more or less the former VisibleSignatureItem) instead elements....
The structure today is:
<VisibleSignatureItemsConfiguration>
    <VisibleSignatureItem>
        <ItemName>...</ItemName>
        <ItemPosition><x>..</x><y>..</y></ItemPosition>
        <ItemValue>....</value>
    </VisibleSignatureItem>
... ... ... ...
    <VisibleSignatureItem>
        <ItemName>...</ItemName>
        <ItemPosition><x>..</x><y>..</y></ItemPosition>
        <ItemValue>....</value>
    </VisibleSignatureItem>
    <IncludeCaption>...</IncludeCaption>
    <Orientation>....</Orientation>
</VisibleSignatureItemsConfiguration>

In what is the proposal structure more flat? not sure to see it: it seems that in the new structure, the name, position, and guess value are also children of IncludeAttribute, and that there are several IncludeAttribute children within VisibleSignatureItems...

Indeed the new structure makes IncludeCaption and Orientation to be required at the level of each item...I am not experienced in PDF visual representation of signatures...is this degree of granularity a benefit?

Other comment: what does w.r.t.a stands for?

9. <GenerateUnderSignaturePolicy>
Agree with the proposal

10. Optional Inputs that should not be used

I guess that in the final version the should not will be changed by a shall not....

11. Optional Outputs tha should not be used

I also guess that in the final version the should not will be changed to a shall not....

Profile of verifying protocol

12. <InputDocuments>

Refer to "signed PDF document" instead to only "PDF document"

13. <FieldName>
TBD: What happens in the multi-verification case if multiple documents contain a field of the same name, but not all of them should be verified?

So this would be the case of more than one signed PDF documents with fields with the same name....wouldn't be better just to forbid multidocument validation?

14. <VisibleIndicationFormat>
In fact this is related with what in former Part 6 of PAdES is called The visual representation of AdES signature verification ...I do not think that is misleading?

15. Optional Inputs that should not be used

I guess that in the final version the should not will be changed by a shall not....

16. Optional Outputs tha should not be used

I also guess that in the final version the should not will be changed to a shall not....


Regards

Juan Carlos.