Terry,
I have two other comments on this draft.
4.1. Algorithm based on jurisdiction
(Roque) My (basic) understanding of the GHOST problem when tackled by the
DNSSEC people is that it end up been a no-problem. A lot of discussions, lot of
waisted time, support for GHOST was added to standards but finally, .RU got
signed using RSA just like the rest of the world. Do we have a summary of the
DNSSEC experience that we could use as reference?
4.2. Algorithm vulnerability
(Roque) We have a procedure in RFC6916. Have you evaluate it? is there a
problem that needs to be fix?
>From your text I cannot figure out if what you are looking for is an emergency
>algorithm rollover. This was discussed and agreed that algorithm roll-over
>will be a long process and no emergency procedure is practically feasible.
5. Key Length
(Roque) I would go for a shorter lifetime until 2030 and keep 2048bits. The
technology is ramping up and migrating to a longer key length at this time
would not be advisable IMHO.
6.1. Protocol support for key rollover events not requiring a change in
cryptographic algorithm
(Roque) I believe you are talking about two things:
- Rollover communication from parent CA to subordinate CA using
top-down protocol (hosted environment is trivial):
IMHO, out-of-band seams to be the right approach. I do not
believe CAs will automate the roll-over request to its parent, so the use of an
in band mechanism will basically triggers a manual action (probably an email)
which is the same communication method used by out-of-band.
- TAL rollover.
You do not mentioned explicitly but I guess that when you refer
to “communicated to validators” you are referring to the TAL file.
There is no magic on how to distribute a new TAL, just like
your DNSSEC keys or a new root cert for your browser. What you normally want is
to have an independent trust anchor that signs that sets the authenticity of
the content. In this case you need to make sure that it is hosted in a TLS
secured site via a trusted certificate authority.
Carlos Martinez had an idea about creating a signed object
signed by the old TA CA that points to the new TAL file. Seams like a good idea
at first view.
Regards,
Roque
On 09 Oct 2014, at 02:21, Terry Manderson <[email protected]> wrote:
> Hi All,
>
> As you are probably aware ICANN has been following the SIDR work fairly
> closely, based in the IAB guidance that a single authoritative trust
> anchor should exist - what we term as the Global Trust Anchor (GTA).
>
> In the process of looking at the implementation of this, the GTA, and the
> technical concerns relating to stability and resiliency, a few questions
> have bubbled to the surface over the past year. Instead of sitting on our
> hands and not communicating to the WG we thought it best to raise what we
> are thinking and seek a discussion. Thus we would very much like the WG
> guidance and advice on these questions.
>
> We have created a draft to raise these discussion points.
>
> http://tools.ietf.org/html/draft-vegoda-manderson-sidr-key-management-00
>
> Are there simple answers? and if so, what are they? Have we
> mis-charatcerised some concerns? How? Are our concerns unfounded? and why?
> Are there more concerns that people see and which we haven't covered here?
>
> Cheers
> Terry and Leo
> _______________________________________________
> sidr mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/sidr
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
