[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: AW: AW: [dss-x] Groups - Signature Policy Profile of the OASIS Digital Signature Services (oasis-dssx-1.0-profiles-sigpolicy-wd.doc) uploaded
Hallo Juan Carlos, your proposal looks fine. Nevertheless we would need to define what happens, if there are multiple indications of a signature policy without signature pointer. In this case it might be appropriate to return some warning, that the second indication was ignored etc. BR, dh > -----Ursprüngliche Nachricht----- > Von: Juan Carlos Cruellas [mailto:cruellas@ac.upc.edu] > Gesendet: Freitag, 9. Mai 2008 17:19 > An: Huehnlein, Detlef > Cc: dss-x@lists.oasis-open.org > Betreff: Re: AW: [dss-x] Groups - Signature Policy Profile of > the OASIS Digital Signature Services > (oasis-dssx-1.0-profiles-sigpolicy-wd.doc) uploaded > > Hi Detlef, > > Thank you for your email and sorry for not having reacted before. > > I would agree with you in general. > I have one comment to your schema: > > ORIGINAL: <element name="SignatureIdentifier" > type="vr:SignatureIdentifierType" /> > > > PROPOSAL: <element name="SignatureIdentifier" > type="vr:SignatureIdentifierType" minOccurs="0"/> > > If this is the case then I would establish the following rules: > > 0. General principle: if the signature itself has a Signature > Policy Identifier (as in XAdES or CAdES) then the server > verifies that signature with this policy. > > 1. If the verify request has includes an indication of a > Signature Policy but not linked to any Signature (ie, only > one IndividualPolicy but no SignatureIdentifier, then this is > used by default for any signature without signature policy > indication. But 0 applies for the rest of signatures. > > 2. If there is any pair of > SignaturePolicyIdentifier-SignatureIdentifier, then the > server uses the policy identified in the request. But if the > signature itself has a signaturepolicy identifier different, > then 0. applies again and the server notifies this fact to the client. > > What do you think? > > Regards > > Juan Carlos. > Huehnlein, Detlef escribió: > > Hallo Juan Carlos, > > > > it seems to me that for "typical use cases" it might be > sufficient to > > have a single policy for multiple signatures related to a > document and > > hence the simple option below might be sufficient. Do you have a > > specific use case in mind, where multiple signatures need to be > > verified with different policies? > > > > On the other side it would be easy to allow the combination of both > > options: > > > > <element name="VerifyUnderSignaturePolicy" > type="VerifyUnderSignaturePolicyType"/> > > <complexType name="VerifyUnderSignaturePolicyType"> > > <sequence> > > <element name="DefaultPolicy" > type="SignaturePolicyDetailsType" minOccurs="0"/> > > <sequence maxOccurs="unbounded" minOccurs="0"> > > <element name="SignatureIdentifier" > type="vr:SignatureIdentifierType" /> > > <element name="IndividualPolicy" > type="SignaturePolicyDetailsType" /> > > </sequence> > > </sequence> > > </complexType> > > > > > > In this case it would be possible to specify a > default-policy, which > > will be applied, iff no other policy-indication (within the > signature, > > or in the element above) "overrules" this default. > > > > > > BR, > > Detlef > > > >> -----Ursprüngliche Nachricht----- > >> Von: cruellas@ac.upc.edu [mailto:cruellas@ac.upc.edu] > >> Gesendet: Freitag, 25. April 2008 17:45 > >> An: dss-x@lists.oasis-open.org > >> Betreff: [dss-x] Groups - Signature Policy Profile of the OASIS > >> Digital Signature Services > >> (oasis-dssx-1.0-profiles-sigpolicy-wd.doc) uploaded > >> > >> Dear all, > >> > >> I have uploaded an initial and uncomplete version of the signature > >> policy profile for DSS protocol. > >> > >> It is uncomplete because the part profiling the > verification protocol > >> is missing. This is due to the fact that I am still > thinking how to > >> manage the situations when the <dss:VerifyRequest> > contains more than > >> one signature. > >> > >> > >> If there is only one signature, the thing is easy, the > client sends > >> an identifier of the policy that the server must > use....but if there > >> are several... > >> > >> Some very initial thoughts: > >> > >> 1. The simplest option: pass to the server one policy > identifier and > >> if there is more than one signature, then the server use > this policy > >> (or makes whatever it wants and then let the client know?) > >> > >> 2. Pass a list of pairs (Signature policy signature to be > verified). > >> Con: requires identify all the signatures and build > references to > >> each signature. > >> Pro: specifies what signature policy must be used for each > >> signature. > >> > >> 3. In addition to all this, if there are several > signatures this is > >> strongly related with the multisignature verification > >> profile...although I do not see problems in this. > >> > >> Regards > >> > >> Juan Carlos. > >> > >> > >> -- Juan Cruellas > >> > >> The document named Signature Policy Profile of the OASIS Digital > >> Signature Services > >> (oasis-dssx-1.0-profiles-sigpolicy-wd.doc) has been > submitted by Juan > >> Cruellas to the OASIS Digital Signature Services eXtended > (DSS-X) TC > >> document repository. > >> > >> Document Description: > >> Profile for instructing servers to use a certain signature policy > >> when generating or verifying an electronic signature > >> > >> View Document Details: > >> http://www.oasis-open.org/apps/org/workgroup/dss-x/document.ph > > p?document_id=28097 > >> Download Document: > >> http://www.oasis-open.org/apps/org/workgroup/dss-x/download.ph > > p/28097/oasis-dssx-1.0-profiles-sigpolicy-wd.doc > >> > >> PLEASE NOTE: If the above links do not work for you, your email > >> application may be breaking the link into two pieces. > >> You may be able to copy and paste the entire link address into the > >> address field of your web browser. > >> > >> -OASIS Open Administration > >> > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]