Clearly I am trying to get a (hopefully WG last call ready) version 05 of the document out by the deadline.
Some comments in-line based on specific feedback you provided.
On Aug 5, 2010, at 9:43 AM, Matthijs Mekking wrote:
>
> The KSK RFC5011-based rollover method says that the removed key must be
> post-published as revoked at least holdback timer long. However, that
> parameter is just a management value for the validating resolver. It
> should be post-published as revoked the Maximum Zone TTL long. Proposed
> text:
>
> RFC5011 increases the duration of key rollovers, because the
> key to be removed must first be revoked. Thus, before the DNSKEY1
> removal phase, DNSKEY1 must be published for one more Maximum Zone
> TTL with the REVOKE bit set. The revoked key must be self-signed, so
> in this phase the DNSKEY RRset must also be signed with DNSKEY1.
ACK, this proposed text (modulo some stylistic differences) is added to
version 5.
>
> This is also true for algorithm rollover. Proposed text:
>
> Trust anchor algorithm rollover is as simple as a regular RFC5011
> based rollover. The old trust anchor must be revoked before it is
> removed from the zone.
>
> However, at every RRset there must be at least one signature for
> each algorithm used in the DNSKEY RRset. This means that a different
> key with the same algorithm, other than the revoked key, must
> sign the entire zone. This can be the ZSK. More operations is
> needed if the single type signing scheme is used. Before rolling the
> algorithm, a new key must be introduced with the same algorithm as
> the key that is candidate for revocation. That key can than
> temporarily act as ZSK during the algorithm rollover.
>
ACK. this is added too.
> End proposed text.
> Rolling the algorithm of only the KSK or only the ZSK is in my point of
> view infeasible and useless.
>
> And one more RFC 5011 note: In section 4.2.3 (Compromise of Keys
> Anchored in Resolvers), it might be relevant to mention that RFC5011 can
> also recover from compromised keys, as long as at least one valid
> trust-anchor key remains uncompromised.
Hmm.. but the compromiser can also initiate a rollover. Therefore I am not sure
if the word "recover" is correct in this context.
>
> Finally, some editorial nits in version 4:
> - - You replaced the names of the DNSKEYs in the tables (for example,
> DNSKEY_1 becomse DNSKEY_Z_1), but not in the text.
ACK
>
> - - In the ZSK pre-publish rollover method, at the DNSKEY removal stage,
> the text says re-sign with DNSKEY1. Although not necessary, it should
> also be re-signed with DNSKEY11 (DNSKEY_Z_11), because it does so in the
> table.
>
ACK
> - - In the ZSK double signature rollover method, at the DNSKEY removal
> stage, the text says "The key set now only containing DNSKEY 11, is
> re-signed with DNSKEY 1." Again, also resign with DNSKEY_Z_11. Also, the
> key set also containst DNSKEY_Z_11.
>
ACK
> Below are some more inline comments.
[skip]
On a point about RFC5011 text you remark:
>
> The text now says:
> It is therefore recommended to roll KSKs that are likely to be used
> as trust-anchors if and only if those rollovers can be tracked using
> standardized (e.g. RFC5011) mechanisms.
>
> To avoid confusion, I would add "on a regular basis" here.
ACK
[skip]
--Olaf
________________________________________________________
Olaf M. Kolkman NLnet Labs
Science Park 140,
http://www.nlnetlabs.nl/ 1098 XG Amsterdam
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
