Re: [dane] Draft for serializing DNSSEC chains

["Osterweil, Eric" <[e-mail]>]

On 6/30/11 11:31 AM, "Phillip Hallam-Baker" <[e-mail]> wrote:

> 
> 
> On Thu, Jun 30, 2011 at 10:51 AM, Osterweil, Eric <[e-mail]>
> wrote:
>> 
>> 
>> 
>> On 6/28/11 2:22 PM, "Adam Langley" <[e-mail]> wrote:
>> 
>>>> As promised. (This is also the format that Chrome is using for it's
>>>> DNSSEC stapled certificate support.)
>>>> 
>>>> http://tools.ietf.org/html/draft-agl-dane-serializechain-00
>> 
>> 
>> I think I may be missing something here, so can someone clarify the
>> following for me: what happens if someone encodes the chain of trust in one
>> of these certs, and then the zones in that chain change their keys
>> (rollovers, revocations, etc.)?  Isn't encoding a dynamic chain of trust in
>> a static cert a requirements mismatch?
> 
> I don't understand the problem here. The RSIG values have an absolute validity
> interval (i.e. not relative)
> 
> This is a pickled RSIG chain from a specific point in time. It says nothing
> about the validity of the chain at any other point in time.
> 
> Unless there is a major flaw in DNSSEC, I can't see where there would be an
> issue here.

Well if you get a cert, and it says, "I'm valid because the following DNSSE
chain is valid," then you are either using THAT chain instead of the current
chain of trust (in which case I ask why), or something else that I don't
understand.  Why are you using a representation of the delegation tree that
may not be current anymore?

Further, are these certs going to be reissued reliably as the root key
changes?  I see in the draft that this is (obviously) predicated on trusting
a root key, but this value will change (albeit slowly).  So, I guess you
have to re-encode your cert when the root key rolls?

Eric