ietf-dkim
[Top] [All Lists]

RE: [ietf-dkim] The key record upgrade attack

2006-08-04 10:18:25
Fortunately there is no conflict here.

If you consider RSA1024 secure and you find a valid RSA1024 signature on the 
message then you are done.

If on the other hand you only find an RSA1024 signature and you have reason to 
consider RSA1024 less than satisfactory you MAY decide to take a look at the 
policy record to see if there should also be a signature that offers stronger 
semantics.

This particular constraint has no impact on the deployed base whatsoever since 
it will be a very long time before even an RSA512 signature would not deliver a 
sufficient degree of security for the purposes for which it is currently used. 


If you consider that approach to be incompatible with base that would imply 
that the original assertion that we could separate policy and base was wrong 
and that we cannot go to last call on base until we complete policy. I don't 
think you would want to disappoint the group by making such a false and 
erroneous assertion now, would you?


-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org 
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Paul Hoffman
Sent: Friday, August 04, 2006 12:23 PM
To: ietf-dkim
Subject: Re: [ietf-dkim] The key record upgrade attack

At 8:38 AM -0700 8/4/06, Douglas Otis wrote:
During a transition, it would be important to communicate 
what will be 
offered and what has been deprecated.  Then these options MUST be 
available or the related signatures MUST be ignored.

The SSP document *cannot* change the way implementers of the 
-base document process signatures. "MUST be ignored" changes 
the logic of -base.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html



_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>