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: Re: [dss-x] PDF Advanced Electronic Signatures Profile - Early Draft


Dear all,

I just want to raise some issues that came to my mind when going through the draft document.

Signature quality: The specification should contain means to specify the requested signature quality, e.g. as specified by STORK QAA:
   1 No or minimal assurance
   2 Low assurance
   3 Substantial assurance
   4 High assurance

Chapter 3.3.2.2.1.1 Optional Input <DigestAlgorithm>:
I'm not sure at all if it is a good idea to give the client the possibility to choose the digest algorithm at all. Some local infrastructures of European countries and their associated signature creation means may be restricted to certain digest algorithms. Giving clients the possibility to choose, or defaulting to a specific digest algorithm may lock out their systems.

Chapter 3.3.2.2.2.4.4 Element <VisibleSignatureItemsConfiguration>:
Some thoughts on your proposed structure.
I see Position specifications, how do you plan to define the page nr. the coordinates belong to? I'm a bit confused about the Reason element, as the Reason is not directly related to the visualization part of the PDF signature, it's more related to metadata, also for signatures without visualization. Additionally a further element to position one or multiple "free-text" elements is required.

Best regards,
Andreas

Am 05.10.2014 23:31, schrieb Martin Boßlet:
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



---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php




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