[dnssec-key-tf] do we need to do anything for RIPE59?

Jim, all,

> [1] Can we discuss the IANA ITAR on this list and reach a decision?

yes, please.  It remains for us to evaluate the ITAR against the TAR
criteria.  For those, we'd need a public reference.  The TF home page
<http://www.ripe.net/ripe/tf/dnssec-key/index.html> lists a "letter sent to
ICANN" <http://www.ripe.net/ripe/wg/dns/icann-root-signing.pdf>, but that's
the "Get the root signed" plea.  My recollection is that the final
result of the TF is reflected in this mail to the DNS-WG dated 27 April 2008:
<http://www.ripe.net/ripe/maillists/archives/dns-wg/2008/msg00030.html>
It would be good to have a stable reference, matbe even to the communication
with ICANN/IANA.

> [2] Is the IANA ITAR "good enough" for us to consider the TF's work  
> done?

##> [1] The TAR should be technology neutral. It should not exclude or
##> prevent different flavours of trust anchors from being published,
##> provided those trust anchors conform to the relevant standards.

I don't recall what "flavours" we had in mind here, but the IANA ITAR seems
pretty algorithm neutral.

##> [2] The TAR should be OS/DNS implementation neutral. Tools and
##> documentation should be provided for use of the repository with common
##> DNS resolver and name server platforms.

I believe ITAR is vendor neutral.

##> Comment: IANA should publish such documentation and tools, or pointers
##> to them. Once we know details of repository, we can help putting
##> together this documentation.
##> 
##> [3] The TAR should verify that the keying material it receives comes
##> from an authorised source, verify it is correctly formatted and verify
##> it is consistent with what is published in the TLD zone before
##> publishing it. There should also be a secure channel for
##> authenticating the repository and any data it is publishing.

I believe this is the case.

##> Comment: Using the same channels IANA uses to process update requests
##> to the root zone from TLDs should be fine. We do not mean special new
##> channels. https delivery and possibly checksums are sufficient for
##> publication.
##> 
##> [4] A process is needed to revoke a trust anchor and notify those who
##> may be using the now withdrawn or invalid trust anchor.
##> 
##> Comment: An opt-in mailing list for operational news should be
##> sufficient to satisfy this.

<http://mm1.icann.org/mailman/listinfo/itar-announce> provides such a list.

##> [5] The TAR should be clear what support, if any, is available.

<https://itar.iana.org/> still says:

  What is a beta?
  This is a preliminary testing version of the service for the community to try.
  We will take feedback and improve the product before it is considered fully
  production ready. In particular, we appreciate feedback on problems that occur,
  as well as features that could be added to make the service more useful.
  You can send any comments to itar at iana.org.

That sounds like an offer of support to me.

##> [6] The TAR must have a published exit strategy.
##> 
##> Comment: The proposal includes that.

  This is a temporary service until the DNS root zone is signed, at which time
  the keying material will be placed in the root zone itself, and this service
  will be discontinued.

This part might benefit from a clarification.  The political aim is clear
and well stated, but I wonder how "discontinued" will look in practice.
Will the files disappear, will they be empty, will they be replaced by
a file containing only the root TA(s)?

##> [7] The TAR should only publish keying material with the consent of
##> the respective key manager.

I believe that is the case.

> [3] Should we try to physically meet in Lisbon before the WG on  
> Thursday?

That doesn't seem necessary to me.

> [4] Should we open up an Action Item for the WG to review the IANA ITAR?

We can engage into formalities here. Since the TF was created by the DNS WG
it should report back there, make a recommendation and ask for approval
which would dissolve the TF.  There's no further action for the WG.

Of course, the question is: will the ITAR ever leave beta state or is it
waiting for "OBE"?

> [5] Are there any other options or strategies I've overlooked?

Thanks for bringing this up again!

-Peter