Re: [DNSOP] Expiration impending: <draft-jabley-dnssec-trust-anchor-11.txt>

[manning <[e-mail]>]

Out of band was discussed very early on with DNSSEC.  John Gilmore and I talked about it at the INET’98 conference.
A problem is transitive trust.  At some point you leave the DNS trust hierarchy and have to trust assertions in a different trust domain.
Sometimes several other trust domains…  I think trying to bound the problem space into a single trust domain is prudent, if only because stepping outside that space is quite large and may not be wise for an IETF document.

That said, if the RZM folks don’t document how they handle transitive trust, I would be much more worried.

manning
[e-mail]
PO Box 6151
Playa del Rey, CA 90296
310.322.8102






On 5October2015Monday, at 7:42, George Michaelson <[e-mail]> wrote:

> every time I post a reply to a thread I think a million kittens (for herding) are born Joe, so it evens out. Here's another kitten to kill...
> 
> Something very left field for me, but I believe important, is that we need to also publish the out-of-band publication point of the trust material. 
> 
> I mentioned this to Joe some time ago and was very correctly told "out of scope" but I believe its nonsensical to exclude physical publication, eg in newspapers of record for at least 3 economies worldwide, of the hash of the public key as a standing event. 
> 
> In-band only has some issues for me, if we are talking about trust.
> 
> -George
> 
> On Mon, Oct 5, 2015 at 9:14 AM, Joe Abley <[e-mail]> wrote:
> Hi Paul,
> 
> On 5 Oct 2015, at 9:52, Paul Hoffman wrote:
> 
> Given that the title and abstract of this document disagree with what many people here have said they want the document to discuss, if the WG adopts this work item, please adopt an exact description of what is wanted with the expectation that this draft could be changed to fit the description.
> 
> I still believe the description of the document people want is best done by ICANN because it is ICANN who can describe what the publication process is today.
> 
> I think we're conflating a couple of things that could perhaps be better considered separately.
> 
> 1. This document could be published by ICANN through the IETF if they want to make it part of the historical record (what we did in 2009/2010) and also provide a reference to current practice that is easier to find (and doesn't have DRAFT written all over it) than the current reference that I think is only buried within root-dnssec.org. There's precedent for this, see e.g. RFC 7108 which was published as an individual submission. If we followed the same path, we'd be looking at dnsop to review for clarity and accuracy, but we wouldn't be asking for adoption.
> 
> 2. The current draft was originally written by me as ICANN staff and Jakob as an ICANN contractor. If there's a need to add current ICANN staff to the author list to make it look more official, surely we could do that (as we did with 7108, actually, which was published after I left ICANN).
> 
> 3. If ICANN prefers not to see this draft published in the RFC series, then that's a good reason not to do it. The value in this document (wherever it is published) lies in it being real, which means we need ICANN's support, e.g. through references in the KSK maintainer's DPS. If that's the preference, let's hear so, clearly. Right now it's difficult to distinguish between individual contributors' opinions and the desires of the IANA Functions Operator.
> 
> 4. If there are elements in the current text that don't match current practice, then let's hear what they are. So far comments to that effect are causing some alarm, but without details it's hard to know what to do with them.
> 
> I am not advocating for any particular direction -- I'd just like to move this draft *somewhere*, whether that's towards the IESG or towards the garbage can of history. Every time we rev the doc without just to stop it expiring, another kitten dies.
> 
> 
> Joe
> 
> 
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
> 
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop