30 messages in org.oasis-open.lists.dssRE: [dss] EPM use cases: some questio...| From | Sent On | Attachments |
|---|---|---|
| Juan Carlos Cruellas | Jun 18, 2003 6:47 am | |
| Trevor Perrin | Jun 18, 2003 7:01 pm | |
| Juan Carlos Cruellas | Jun 19, 2003 12:41 am | |
| Juan Carlos Cruellas | Jun 19, 2003 12:45 am | |
| Trevor Perrin | Jun 19, 2003 3:22 pm | |
| Juan Carlos Cruellas | Jun 20, 2003 3:47 am | |
| Trevor Perrin | Jun 20, 2003 8:14 pm | |
| Juan Carlos Cruellas | Jun 25, 2003 3:01 am | |
| Nick Pope | Jun 25, 2003 4:11 am | |
| Gray Steve | Jun 25, 2003 4:38 am |  .doc |
| Trevor Perrin | Jun 25, 2003 10:16 am | |
| Trevor Perrin | Jun 25, 2003 10:39 am | |
| Trevor Perrin | Jun 25, 2003 11:46 am | |
| Nick Pope | Jun 26, 2003 10:03 am | |
| Trevor Perrin | Jun 30, 2003 2:10 am | |
| jmessing | Jun 30, 2003 7:03 am | |
| Nick Pope | Jun 30, 2003 7:22 am | .pdf |
| Trevor Perrin | Jun 30, 2003 4:22 pm | |
| Juan Carlos Cruellas | Jul 1, 2003 3:19 am | |
| Nick Pope | Jul 1, 2003 5:43 am | |
| Trevor Perrin | Jul 1, 2003 5:52 pm | |
| jmessing | Jul 1, 2003 6:51 pm | |
| Trevor Perrin | Jul 1, 2003 8:14 pm | |
| Nick Pope | Jul 2, 2003 2:50 am | |
| Trevor Perrin | Jul 2, 2003 1:36 pm | |
| Trevor Perrin | Jul 2, 2003 2:08 pm | |
| Gray Steve | Jul 3, 2003 10:12 am | |
| Trevor Perrin | Jul 3, 2003 1:41 pm | |
| Trevor Perrin | Jul 3, 2003 4:26 pm | |
| Juan Carlos Cruellas | Jul 8, 2003 3:26 am |
| Subject: | RE: [dss] EPM use cases: some questions and one requeriment. | |
|---|---|---|
| From: | Nick Pope (po...@secstan.com) | |
| Date: | Jun 26, 2003 10:03:47 am | |
| List: | org.oasis-open.lists.dss | |
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:tre...@trevp.net] Sent: 25 June 2003 18:54 To: Nick Pope; ds...@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