-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/24/2012 05:11 PM, Joe Abley wrote:
> 
> On 2012-07-24, at 07:53, Matthijs Mekking wrote:
> 
>> As you might know, I had this idea of unraveling key states. 
>> Instead of having states that describe the overall state of the 
>> key, we would have states for components of the key. How to
>> divide the key into components is based on the parts that can be 
>> published:
> 
> I am a big fan of this line of thinking.
> 
> I saw you (in Vienna, I think) reduce this logic to a small set of 
> equations which, if all are satisfied, indicates that a particular 
> change for one component is safe (from the perspective of 
> validators), and I think this would be a vast improvement for 
> implementers and operators over the sometimes complicated
> reasoning that is otherwise involved in planning a rollover event.
> This model makes arbitrary key rollovers trivial to plan with
> confidence.

You are confusing me for my colleague Yuri, but we think alike. Yuri
build the logic on top of the idea of unraveled key states. The logic
is based on the timings described in
draft-ietf-dnsop-dnssec-key-timing and
draft-mekking-dnsop-dnssec-key-timing-bis-02.txt.

For more information on the logic, see our paper:

http://nlnetlabs.nl/downloads/publications/satin2012-Schaeffer.pdf

> 
> While dnsop-dnssec-key-timing provides a fairly thorough
> background which promotes understanding of the underlying issues,
> it's still a thorny document to apply to an actual operational
> event.
> 
> I think it would be great if we could present your model (or 
> something similarly robust and simple) in such a way that it
> becomes the normal way of thinking about rollover events, both for 
> implementers of DNSSEC signing platforms and for operators of 
> DNSSEC-signed zones. The world would be a better place.

Thanks.

Matthijs

> 
> 
> Joe
> 
> 
> 
> _______________________________________________ DNSOP mailing list
>  DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
> 


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJQD6XdAAoJEA8yVCPsQCW5K3AIAIT+iJzk9FA+SpFelg1xGAg2
JevKRs/kP+BfaTWGedbJnP4UaHsJdhK+eM6VNAMRB0pjR+ORQv3KwRkzfpop5QVP
v/mRqZqv+pHBwsikrecvH4kER5j9TLjghPnK8gElEVi0tf4wTnkgB6RfstZNN0aw
lxj7lLWTJVvUgMZhl7DNKMmRdO5DS4j5amcQMX7etqn73UHnzArGkswRMttYFh7q
BoPzn02ysXDZlXsRbaS58l4VA93nU31M6MJ4RNXzXSNDP3yWwvPq7UAlJL4ngS6y
15MGejj/GQB4626ao5pXtWoT5IfTq7vQ94hS5A5mSkFa/kL2gOUOKQsWY/+eMsc=
=AP9g
-----END PGP SIGNATURE-----
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to