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

Hi Andreas,

'Signature Quality' makes sense to me, as along as it is optional.

Digest Algo:
Cuts both ways: You are causing problem with restricting as well as
leaving it to the creator's choice. My proposal would be : leave the
choice to the requestor, define a derived profile if you want to narrow
down to e.g. EU compliance.


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

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 

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