[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dss] EPM use cases: some questions and one requeriment.
Trevor, I see the signature profile as you describe it is one component of a signature policy. The signature policy as a whole looks across the whole creation / validation process and covers the all that is needed to be know to define what is a valid signature. We may need to concentrate on just the signature creation / validation profiles and not worry too much specifying what is in the overall signature policy. The dynamic signature parameters such as keys etc are outisde what I would consider as a policy which is more of a static specification based on user requirements and risk analysis. Nick > -----Original Message----- > From: Trevor Perrin [mailto:trevp@trevp.net] > Sent: 25 June 2003 18:54 > To: Nick Pope; dss@lists.oasis-open.org > Subject: RE: [dss] EPM use cases: some questions and one requeriment. > > > At 12:29 PM 6/25/2003 +0100, Nick Pope wrote: > >Content-Transfer-Encoding: 7bit > > > >Juan carlos, Trevor, > > > >Looking at this I realise that we have confusion over what is a > "signature > >policy" & "validation policy". Currently, the Signature Policy > as described > >in ETSI covers validation requirements. > > Yeah, 3.4.4 is the "signing policy" and 3.6.2 bullet 1 mentions the > "verification/validation policy", but this bullet should be raised to its > own section, and probably we should name these something different from > "policy", because then they get confused with the SignaturePolicy that is > included as an attribute of the signature itself, whereas the > signing/validation policies are only used by the client to control the > server's behavior. > > Also, it seems like we're grouping 2 different types of parameters into > these policies - things that are related to the overall "signature > profile", like EPM vs. eNotary vs. whatever, and things that are > related to > particular settings within a signature profile, like "trust settings". > > So eventually we might want to break these policies into 2 > separate things: > > - Signature Profile Identifier > - Whether/how requestor identity is included > - Whether/how signing time is included > ... > - Signature Parameters Identifier > - What key/certificate is used to sign > - What validation/key info is used to sign > ... > > I.e., a client product built to support eNotary would have the Signature > Profile Identifier hardcoded, but the user could change the Signature > Parameters Identifier to request variations in service. > > I'd rather not put this into the requirements document, because this is > just a detail of how we're trying to satisfy the requirements, > and because > we probably won't know what's the best idea here until we get > further into > things, but it's something to think about. > > > >Do we want to have a signature policy which comprises the creation and > >validation policy components? Also, is it validation or verification? > > I don't know. Right now the document uses verification. At times people > have suggested validation. Should I change it? > > Trevor > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]