Hi Rob, all, > On 13 Mar 2017, at 14:11, Rob Austein <s...@hactrn.net> wrote: > > At Mon, 13 Mar 2017 10:55:56 +0100, Tim Bruijnzeels wrote: >> >> So, to me it seems that having new OIDs makes perfect sense as long >> as there is a choice of two validation algorithms. Then having an >> explicit flag set by CAs tells RPs decide which way to go. Because >> of this I also do not see an immediate need to have a time line for >> all CAs to use the new protocol for all its products. It's all >> explicit. >> >> Now, if the ambition is to have reconsidered as the only algorithm >> for doing RPKI validation, then I think that the RPKI Certificate >> Policy OID is enough (section 4.8.9 of RCF4587 - which delegates to >> section 1.2 of RFC6484). I realise that RFC3779 section 2.3 has text >> on path validation as well, but I think could can recognise that a >> different algorithm should apply in the context of *RPKI* >> validation. >> >> If I understand Rob's concerns though he feels that this will cause >> issues, and that therefore the RFC3779 OID cannot be used. Rob, is >> this correct? Why can't RP/OpenSSL code just make the switch based >> on the CA certificate profile? > > The problem is that there are one or two things out there besides RPKI > which use X.509, and it would be nice to avoid breaking them.
I understand that. I meant to say that the switch should be based on the RPKI CA certificate policy qualifier. That is specific to RPKI so, other applications would not break. Non-RPKI use of RFC3779, would not have this same OID, and therefore would still have the path validation from section 2.3 in RFC3779. > The OIDs which MUST be changed are the ones labeling the extensions > themselves. The semantics of X.509v3 critical extensions says, > basically, "If you don't understand the meaning of this extension, you > MUST consider this certificate invalid". Changing the meaning of the > extensions while retaining the existing OIDs would break this: there > is code out there which thinks it does understand the RFC 3779 > extensions, but which would now be incorrect, because the RFC 3779 > OIDs would now be used to label things that are not RFC 3779 > extensions. > > Granted, the probability that some random X.509 CA is going to include > RFC 3779 extensions in certificates for any purpose other than RPKI is > fairly low, but it would be nice to avoid creating a situation in > which users of such certificates got inconsistent results depending on > which version of a stock library they happened to use. If this were > OpenSSL doing something stupid I wouldn't care so much, but this was > OpenSSL implementing an IETF proposed standard to the best of the > author's ability, and you're talking about retroactively breaking that > for gratuitous reasons. This is irresponsible. Don't do it. > > I don't understand why we're wasting time debating this (again). OIDs > are cheap, and (I thought) this was a done deal. Can we please just > admit that we're talking about new extensions with new semantics which > borrow syntax from the existing extensions, label them accordingly, > and move on? The reason why I keep talking about this, is because other people indicated that it could be desirable that validation reconsidered is not a choice (that would need flagging, so OIDs are appropriate) - but should become the default. In that case it's much simpler to have a switch on the unique RPKI CP OID from section 1.2 of RFC6484. The proposed OIDs itself are cheap, and the code changes are simple. The difficulty is that we need a deployment plan: 1= RPs MUST support new OIDs, before 2= CAs MAY use new OIDs and an open question still is whether there needs to be a later 3= CAs MUST use new OIDs and RPs MUST reject old OIDs Step 2 has operational impact if operators did not upgrade their RP software. Step 3 has operational impact in case a CA cannot re-issue certain objects. If we need to end up in a place where 'validation reconsidered' is the default, then these operational impacts can be minimised. It would boil down to deciding a date X by which RPs MUST use reconsidered when they encounter the RPKI CP OID, and a date Y (before X) that these should be available. Operators that don't upgrade before date X could find that they consider certain objects invalid, that would be (partially) valid. In any case, I know that you know more about how the openssl code works. So if there is a reason why the switch cannot work on the RPKI CP OID without affecting non-RPKI use, or if there is a strong reason for having both algorithms alongside each other, than I am (still) open to the OIDs that I painstakingly added to the document. Tim _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
