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. 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? _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
