[dnssec-key-tf] clarification of TAR requirements

Hi Jim,

> >>[5] Everybody should sign up to T&C's that hold everyone else  
> >>harmless.

> My idea behind [5] was that anyone directly using the TAR signs up to  
> some T&Cs. ie The TAR says "we make no claims of any sort about this  
> data" (maybe). Those submitting keys to the TAR say something similar  
> and also promise timely updating of the TAR when a new key is  
> introduced. And have responsive point of contacts. Anyone downloading  
> stuff from the TAR agrees the TAR is making no claims about the  
> validity of the data and they take full responsibility for everything  
> they do with the stuff they download.
 
now, if IANA is doing the job, is this still a requirement from our side
(assuming this was to protect the NCC from any liability back then)?
"Users" should actually have meant the parties downloading the TAR, not
end users, so that's fine with me.

> >>[7] The TAR must make it clear what they keying material is for and
> >>   its political significance: eg "we're not undermining IANA" (or
> >>   perhaps not) or "we make no claims about the appropriateness of  
> >>the
> >>   stuff in our TAR" (national sovereignty & competition issues).
> >
> >Given that [11] would mean TAs get inserted only with the consent of  
> >the
> >key maintainer, is "appropriateness" still the right term?
> 
> Yes. eg Not claiming or implying one TLD key or DNSSEC flavour or type  
> of trust anchor is better or worse than another. Or that the  
> hypothetical NCC's TAR was better or worse than one run by some other  
> organisation.

So, setting layer 9+ aside for a second, this would mean there are no
requirements for the crypto algorithms and key lengths used, nor any
requirement to actually have a ZSK/KSK split or have a live KSK with the
SEP flag set?

> >here would be some statement saying that "signing the root" is still a
> >goal (if it is) and that's why the requirements about exit strategies
> >should be kept.
> 
> Let's avoid this rat-hole Peter. I think we're now working on the  
> assumption that the IANA repository is going ahead. So this TF could  
> support that effort with some ideas about that TAR's requirements. If  
> we can get consensus on that, we can ask the WG to endorse that  
> outcome, send it to ICANN and as Daniel says, declare victory and  
> close the TF.

I'm not sure where you see me rat-holing here.  With a non-IANA TAR, having
termination conditions and exit strategies was quite natural.  With an IANA
TAR this requirement may or may not be maintained.  I've "voted" in favor,
what's your opinion?

> >>[8] The TAR should treat all parties equally. Provided they
> >>   demonstrate suitable levels of DNSSEC clue.
> 
> >Not sure what this was up to.
> 
> The TAR would be for all ICANN-recognised TLDs, not just ccTLDs or  
> those TLDs that happened to be in the NCC service region. Or were NCC  
> members. At the same time however, a TLD that comes to the TAR looking  
> for guidance on how to manage its keys or sign its zone should know  
> they should look elsewhere for that assistance. 

So, at the risk of being perceived as Prussian again, lets explain this
a bit more (and avoid "recognized" etc.):

[8] The TAR is open to receive TAs for any delegated TLD.
[?] The TAR maintainers may assist TA/KSK maintainers on a best effort
    basis only. Inetersted parties are encouraged to consult (RFC 4641, ...)
    for technical and operational guidance.

-Peter