Subject: [dnsext] SEP bit

From: John Dickinson <[email-masked]>
Date: Wed, 29 Apr 2009 17:06:24 +0100

Whilst trying to explain the meaning of the SEP bit in a document I am  
writing I found that

RFC4033 says "This document and its two companions obsolete <snip>  
[RFC3757]"

However, I can not see where this is done in any of 4033-35.

In fact 4033 goes on to say:

"Key signing keys are discussed in more detail in [RFC3757]."

4034 says:
"Bit 15 of the Flags field is the Secure Entry Point flag, described  
in [RFC3757]"
"and bit 15 (the Secure Entry Point flag (SEP) bit; see [RFC3757])"
"This flag is only intended to be a hint to zone signing or debugging  
software as to the intended use of this DNSKEY record; validators MUST  
NOT alter their behavior during the signature validation process in  
any way based on the setting of this bit." which by my reading doesn't  
seem to contradict 3757.
Is RFC3757 really obsolete?
RFC 4641(bis) goes on to recommend "In this document, we assume a one- 
to-one mapping between KSK and SEP keys and we assume the SEP flag to  
be set on all KSKs." This seems reasonable unless you don't want to  
use a KSK.
Are there scenarios where 4641 is not true? It seems that the SEP bit  
is in danger of taking on meaning that it does not have. Most signers  
already call it the KSK flag.
I am thinking that 4641bis might want to say something like - The SEP  
bit may be used locally only to aid signers in deciding what RRSets to  
sign with a given key. However, when signing it would be better to be  
explicit about which keys sign which RRSets. It should not be used  
even between cooperating parties such as a parent and child for  
indicating which key to use for a DS or as a TA. It should be ignored  
by all other systems especially validators.
John
---
John Dickinson
http://www.jadickinson.co.uk

I am riding from Lands end to John O'Groats to raise money for  
Parkinson's Disease Research. Please sponsor me here http://justgiving.com/pedalforparkinsons2009

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Michael StJohns <[email-masked]>
Date: Wed, 29 Apr 2009 16:04:42 -0400

Except see RFC5011. Keys with the SEP bit set are the only ones tracked by the key rollover mechanism described there.

At 12:06 PM 4/29/2009, John Dickinson wrote:
>RFC 4641(bis) goes on to recommend "In this document, we assume a one- to-one mapping between KSK and SEP keys and we assume the SEP flag to

---

From: John Dickinson <[email-masked]>
Date: Thu, 30 Apr 2009 14:27:21 +0100

On 29 Apr 2009, at 21:04, Michael StJohns wrote:

> Except see RFC5011. Keys with the SEP bit set are the only ones  
> tracked by the key rollover mechanism described there.

Sorry for my almost unreadably formatted message (it looked OK until I  
pressed send) and for bringing 4641 into the wrong list.

Perhaps it would be useful if draft-ietf-dnsext-dnssec-bis-updates  
clarified this and section 5.2 included something to the effect that:

RFC3757 is not obsolete, that it is updated by RFC5011 and that  
although the SEP bit plays no part in the validation process it may be  
used in the automated key rollover process as described in RFC5011.

Reading 5011 and dnssec-bis-updates again also made me wonder how the  
operator of a validator is supposed to know that the zone owner is  
doing RFC5011 and using the SEP bit in a meaningful way? Should dnssec- 
bis-updates make some comment on that?

John

>> RFC 4641(bis) goes on to recommend "In this document, we assume a  
>> one- to-one mapping between KSK and SEP keys and we assume the SEP  
>> flag to

---
John Dickinson