Re: [Sidrops] I-D Action: draft-ietf-sidrops-signed-tal-00.txt

[Tom Harrison <[e-mail]>]

Hi Tim,

On Wed, Dec 06, 2017 at 02:59:51PM +0100, Tim Bruijnzeels wrote:
> I think that there may be merit in an explicit json, or XML (to be
> consistent with 6492 and 8181) format, e.g.:
> 
> <tal>
>    <uris>
>      <uri>https://rpki.example.org/rpki/hedgehog/root.cer</uri>
>      <uri>rsync://rpki.example.org/rpki/hedgehog/root.cer</uri>
>    </uris>
>    <subjectPublicKeyInfo>
>       ...
>    </subjectPublicKeyInfo>
> </tal>
> 
> A structure like this will make it easier to add tags or attributes
> to communicate other things.

This approach looks good.  Would this structure be specific to the
signed TAL, with the 'standard' TAL remaining as-is?

> If we need an explicit staging time, rather than require this
> implicitly by publishing it, then I think we are better off with a
> valid object and an XML structure like above with an additional tag
> like:
> 
> <notBefore>2019-01-01T00:00:00.000Z</notBefore>

Agreed, this approach makes more sense. 

>> Section 6.3 has "[t]he TA SHOULD preserve a Signed TAL for the old key
>> after the staging period as a hint for RPs that missed the key roll".
>> Although (I think) the only sensible way to read this is that the
>> signed TAL to which this is referring is that pointing to the new TA,
>> "for the old key" might make people think the signed TAL should be for
>> the deprecated key instead.  Something like "[t]he TA SHOULD preserve
>> the Signed TAL pointing to the new TA after the staging period..."
>> could work.
> 
> So, here there is a lot of implicit stuff again.
> 
> We could also think of this differently.. maybe extending the
> structure to something like this could help:
> 
> <ta>
>   <oldKeys>
>      <subjectPublicKeyInfo>MIIBIjANBgk…</subjectPublicKeyInfo>
>      <subjectPublicKeyInfo>MIIBIjdfkhjfd…</subjectPublicKeyInfo>
>   </oldKeys>
    ...
> </ta>
> 
> This way we can communicate explicitly which previous keys have been
> expired. And what the current key is at the time of publishing this.
> 
> If this is published by old keys in the form of long-lived objects
> and CRLs, then RPs could still find their way to the current key. An
> argument can also be made that RPs should not care about staleness
> of MFT/CRL or expired MFT/TAL EE certificates in this case.

What's the motivation for explicitly listing the previous keys in the
signed TAL?  If each deprecated TA publishes a long-lived signed TAL
that points to the TA that superseded it, then anybody who is using a
deprecated TA will be able to find the current TA, and I can't think
of other instances where knowing the previous keys would be useful.

>> I think 24 hours for the staging period is too short, mainly because
>> people who don't update their validators to support this may not take
>> action on the new validation error (something like "unknown type of
>> object: {name}.tal") within that short a time period.
> 
> Okay, it’s not clear to me that this is related to the staging period.
> 
> But, before any of this could be deployed we do need to be sure that
> RP software can be upgraded to support it, or at least not choke on
> it. If people do not upgrade their RP software they can still find
> out that a new TAL should be used through other means (e.g. mailing
> lists). And let me be devil’s advocate here.. if people never, ever
> upgrade their RP software, then breaking it and forcing them to
> upgrade could be considered a feature by some. Of course, after a
> reasonable time..
>
>> There are also other instances like this where manual action might
>> be required, e.g.  where operations staff insist that the validator
>> not have write access to its configuration and that all updates
>> happen manually.  A week or a month as a mandatory period would be
>> better.
> 
> I believe that we should insist that key rolls like this are fully
> automated and not done manually. I also believe that it would be
> prudent that if && when we agree on a mechanism for this, it is done
> regularly - at least in some environments to ensure that this works.
> In short: I think a planned key roll, signed by a trusted TA, should
> be a normal thing. If we leave this as paperware then there will be
> no guarantee that it works when we need it.

OK, sounds good.

> And as a final thought.. it would be good if the planned and
> unplanned key roll processes are similar.

One option here is for planned rollover to be handled by having the
'staging' key details include an additional 'transition date' field,
indicating that the TA operator expects to be using the staging key as
its TA key by that date.  That would allow the 'staging period' from
6.2 to remain as-is, while also providing for more advance notice to
be given by way of the 'transition date' field.

-Tom