Hallam-Baker, Phillip wrote: > 6.3 > 11. The Protocol MUST NOT be required to be invoked if a valid first party > signature is found. > > Should be: > > The Protocol MUST NOT be required to be invoked if a valid first party > signature that satisfies the cryptographic criteria of the recipient is > found. > > > If I look at the email and find a satisfactory signature I am done. If I > don't find any signature at all *or I find only a weak signature* I need to > look at the policy. > I don't see why we need to introduce shades of grey (i.e., valid but weak signatures) here. The verifier is able to decide what it considers to be a valid signature. If a signature uses an algorithm that the verifier considers to be too weak, it should just consider the signature to be invalid. Then the original #11 is sufficient. > Otherwise the requirements of 5.7 are unmet. > > > This requirement only starts to have real effect when we have a serious > enough compromise of SHA or RSA1024 to mean that verifiers would reject weak > signatures. I don't expect to get there until 2015 but I do expect to get > there eventually. > > > > Also I would like to reword 12: > > [PROVISIONAL] A domain holder MUST be able to publish a Practice which > enumerates the acceptable cryptographic algorithms for signatures purportedly > from that domain. > > To be > > 12a [PROVISIONAL] A domain holder MUST be able to publish a Practice which > specifies the acceptable application of cryptographic algorithms for > signatures purportedly from that domain. > > 12b [PROVISIONAL] A domain holder MUST be able to publish a Practice which > specifies the application of multiple signatures with different cryptographic > algorithms for messages purportedly from that domain. > I disagree with #12 entirely. This addresses a case where there is a signature that references a key record within the domain. There is already a tag/value in the key record to specify the algorithm(s) that are associated with the key. If there are algorithms that the domain has abandoned using because they're too weak, they just don't publish any key records for that algorithm. There's no reason we need to get this information from a Practice record.
I don't remember all the details, but we discussed whether key records should describe the application of multiple signatures (other signatures in addition to the one referencing the key record). We decided not to do that, and I don't think SSP should be trying to do the same thing again. -Jim > > The difference here is key to the distinction between my proposal and the > existing one. A mere enumeration of the acceptable algorithms does not allow > the upgrade/downgrade attack to be effectively defeated. Merely saying 'I > support SHA-256' does not in fact strengthen the policy. > > Also the term 'enumeration' expresses the assumption that the algorithms will > be listed in the policy record. I don't think they should go there. The > proper place for them is in the key record. This avoids the need to duplicate > the information and is in any case necessary to meet requirement 11 which can > only be met if the key records effectively enumerate the set of acceptable > algorithms. > > > _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
