Comments to PAdES profile

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>
    
    
    
    
    
    
    
    
    
  JA
  X-NONE
  
   
   
   
   
   
   
   
   
   
  
  
   
   
   
   
   
   
   
   
   
   
   
  

    

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

    

    
    
    
    
    
    
    
    
    
  JA
  X-NONE
  
   
   
   
   
   
   
   
   
   
  
  
   
   
   
   
   
   
   
   
   
   
   
  

    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.

    

    

    
    
    
    
    
    
    
    
    
  JA
  X-NONE