Re: [dss-x] Comments to PAdES profile

[Andreas Kuehne <kuehne@trustable.de>]

Hi Juan Carlos,

regarding the first topic:
Iirc we discussed it in a call some time ago. My position was that using
a DocumentHash renders the profile useless. As you pointed out many of
the important task dealing with the PDF cannot be done just with a hash.

An approach with respect to document privacy would be to send the inner
hash and do a blind signing on this. The major work of dealing with
PAdES is left to the client.
The server would just offer a PKCS 1 style signature.  Maybe this is
worth of an additional profile, maybe not. Such a server doesn't really
deserve the name 'signing server' ...
 
No comments on your other remarks.

Greetings,

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


-- 
Andreas Kühne 
phone: +49 177 293 24 97 
mailto: kuehne@trustable.de

Trustable Ltd. Niederlassung Deutschland Ströverstr. 18 - 59427 Unna Amtsgericht Hamm HRB 5868

Directors Andreas Kühne, Heiko Veit

Company UK Company No: 5218868 Registered in England and Wales