RE: [dss] EPM use cases: some questions and one requeriment.

["Nick Pope" <pope@secstan.com>]

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
>
>
>