Hi Chris,
> On 13 Mar 2017, at 15:21, Chris Morrow <[email protected]> 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
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
