[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. Greetings, 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 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 >> > > > --------------------------------------------------------------------- > 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]