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: PDF Advanced Electronic Signatures Profile - Early Draft


Hello all,

I attached a very early draft that hopefully helps to clarify the scope and contents of the profile. The paragraphs starting with "TODO:" are my thoughts on what I would like to address in these sections, paragraphs with "TBD:" are thoughts that I'd probably like to discuss in more detail in order to get a good feeling for what the best approach is.

As a tl;dr here are the (in my opinion) most urgent topics that need further clarification:

#1 Should the profile XSD be able to redefine elements that previously existed, albeit in a more restricted/different form? Or should the XSD just reference existing elements but not alter them? One good example would be the <VisibleSignatureConfiguration> optional input from the Visible Signature Profile: If given the freedom to redefine this element from scratch, it could be targeted towards PDF more nicely, concentrating on PDF properties only and leaving out things that do not apply in a PDF context.

Another advantage would be the ability to overcome minor aesthetical/syntactical problems: 

- there are inconsistent uppercase/lowercase definitions for elements/attributes in the referenced XSDs
- the <other> element in the Visible Signature Profile is mandatory, but probably shouldn't be
-  the Signature Policy Profile XSD cannot be parsed in its current form because there is an issue with the Multi-Signature Verification Reports Profile's XSD that is being referenced
- it would be nice to be able to request a signature policy in the spirit of the AdES profile signed properties

I see two approaches: We could either reference existing profiles and their elements without changing or restricting them (on the XSD level). Or I could redefine the elements as standalone elements allowing the freedom to match the PDF case as closely as possible, and only use the Core Profile XSD as my only reference.

#2 I would like to address how to use the profile for mass signing, extension and verification purposes. These use cases come with their own set of problems, however. Do you think that

- this should be addressed at all?
- we should try to clarify the issues in this profile?
- we should not address it here but in a separate "Mass signing profile" that could possibly be reused in a CAdES or XAdES context?

Thank you for any comments and suggestions!

Best regards,
Martin

Attachment: pades-v1.0-wd01.odt
Description: application/vnd.oasis.opendocument.text



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