Hi Alvaro, all,
Speaking for myself the reason for the delay is that I underestimated the
impact of the new OIDs on deployability of this algorithm. I also meant to talk
to all interested parties about this in person in Chicago, but unfortunately my
father was hospitalised at the time (all good now!).
All that said I will work on an update of this document following Alvaro’s
review. This document will define an additional validation algorithm, but not
update the existing one. We can finish this work first and then have a
structured discussion about deployment - I propose that we take this work to
SIDROPS.
I canceled all my meetings today so I should have updated text to share with my
co-authors soon. Will then send a new version to the WG asap.
Tim
> On 15 Jun 2017, at 17:02, Alvaro Retana (aretana) <aret...@cisco.com> wrote:
>
> Dear authors:
>
> Hi!
>
> It’s been 3 months since this e-mail, which was the last of the thread
> started from my review.
>
> I am expecting a revised ID – what are the plans to move forward?
>
> Thanks!
>
> Alvaro.
>
>
>
> On 3/15/17, 10:24 AM, "sidr on behalf of Tim Bruijnzeels"
> <sidr-boun...@ietf.org on behalf of t...@ripe.net> wrote:
>
> Hi Chris,
>
>> On 13 Mar 2017, at 15:21, Chris Morrow <morr...@ops-netman.net> wrote:
>>
>> but, having 2 versions of the validation
>> algorithm and seeing published data for both OID sets for a single
>> prefix/publication bundle will be very problematic. There's no
>> proscribed 'prefer new over old' action here, so a CA must only
>> publish one version of their data.
>
> Why is this a problem, really?
>
> The OIDs are set on a per certificate basis by the issuing CA. FWIW, in our
> hosted set up we *will* be able to pro-actively re-issue everything using the
> new OIDs without user interaction, but there are cases in hosted CA
> deployments where a hosted CA can automatically re-issue manifests, but ROAs
> can only be re-issued by explicit user request, one by one.
>
> So we may see hosted CAs with products like this:
>
> 1 CRL (validation algorithm does not apply)
> 1 MFT (new validation, although it won't matter because inherit is used)
> 1 ROA with new validation (which has been re-issued by the user)
> 1 ROA with old validation (which has NOT yet been re-issued)
>
> This might seem confusing, but since the OIDs make it very explicit which
> algorithm the CA intended to use, I really do not see any ambiguity here.
>
> My main concern is that we need to be quite confident that new RP code that
> understands the new OIDs has been available and is deployed. Because old RPs
> will reject EVERYTHING once CAs start using the new OIDs.
>
> That is why I would have preferred to not need new OIDs, and just agree on a
> day that the new algorithm should be preferred. Rob seems adamant that the
> RFC3779 extension library code does not have access to the context of the
> full certificate with the RPKI CP OID - so there is no way to have something
> like:
>
> if (FULL certificate has RPKI CP OID && Date is after 'switch' day) {
> do NEW on RFC3779 extension
> } else {
> do OLD on RFC3779 extension
> }
>
> The impact of RP software not using the new library on 'switch' day is fairly
> limited. They would not reject the full repository, but only reject the
> exceptional cases where certificates ARE over-claiming. And of course the
> date check can be removed in releases of the library after 'switch' day..
>
> It seems to me that this is a design issue with OpenSSL itself, but be that
> as it may - it may be unsurmountable. Rob knows this code much better than I
> do.
>
> Still the consequence of all this is is that we will have to have a mix, and
> that despite our best efforts to warn everyone to upgrade their RP software I
> expect that we WILL see a number of operators that suddenly find that their
> old RP software has reject our full repository when start using the new OIDs.
>
> If it can't be avoided than so be it, but I believe this perspective should
> be considered as well.
>
>
>
> Cheers
>
> Tim
>
>
>
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
