On 3/16/2017 3:16 AM, tjw ietf wrote:
All
We've had a lot of WG discussion on this, and it seems relevant to do
a formal call for adoption. If there are outstanding issues raised
during the CfA, time in Chicago will be set aside to have those
discussions.
This starts a Call for Adoption for:
draft-hardaker-rfc5011-security-considerations
The draft is available here:
https://datatracker.ietf.org/doc/draft-hardaker-rfc5011-security-considerations/
Please review this draft to see if you think it is suitable for
adoption by DNSOP, and comments to the list, clearly stating your view.
I've no objection to placing this as a WG item for work.
However, as I've indicated to Wes and Warren, it's currently missing the
point.
Here's the alternate abstract text I proposed to them:
This document describes the math behind the minimum time-length a DNS
zone publisher must wait after publishing a new trust anchor before
having a reasonable belief that all operational, well-behaved 5011
clients have installed that new trust anchor at their zone trust
point. As publisher guidance, this is also the minimum time the
publisher should wait before revoking the complete set of previously
published/installed trust anchors and depending on the newly published
trust anchor as the sole point of trust and the minimum time the
publisher should continuing publishing a revoked key (and its
signature) after revocation.
The timing issue you need to resolve is not when you begin providing
RRSigs with the new key, but when you revoke all of the other keys at
the trust point.
The document as currently drafted still assumes there is only one trust
anchor key as steady state. That's a) a bad assumption, and b) a bad
operational policy.
Mike
Please also indicate if you are willing to contribute text, review, etc.
If there are
This call for adoption ends: 30 March 2017
Thanks,
tim wicinski
DNSOP co-chair
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
