On Fri, 02 Mar 2007 14:41:03 -0000, Hallam-Baker, Phillip
<pbaker(_at_)verisign(_dot_)com> wrote:
Since we are drafting a requirement here we do not need to give the
explanation in the detail given on the list.
The signing policy statement MUST be capable of fully describing a
signing practice in which multiple signatures are always provided such
that the policy is of utility to any verifier is capable of verifying
any of the signatures that are always provided.
+1
Such a mechanism MUST NOT
* Require the verifier to perform any additional DNS lookups.
Yes
* Require duplication of configuration data
Yes, but SHOULD would be enough
* In particular not require the policy record to provide for the
description of any cryptographic or cannonicalization algorithm
Not clear exactly what that means. For sure you need to identify various
cryptographic or cannonicalization algorithms that you might want to say
you always/whatever use.
Actually, since the various tags in a Dkim-Signature between them show
clearly what variety of such algorithms have been used, it would suffice
for the SSP to be able to say
"When we sign, our signatures will containg the following tags"
(doesn't have to account for _every_ tag).
Then, if you have several ways of signing, each covered by such a set of
tags, you can then combine those statements with a variety of AND and OR
operators.
So that allows you to say
"We always sign with THESE tags and THOSE tags"
which was your original example that started these threads, but it also
leaves open other things that you might want to express in the future.
Recall, that one of the features I want to see in SSP is that the notation
can be broad and extensible, so that it can accomodate requirements and
exploits which noone has thought of yet.
--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131
Web: http://www.cs.man.ac.uk/~chl
Email: chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html