Hi, 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? Cheers Tim > On 13 Mar 2017, at 07:16, Declan Ma <m...@zdns.cn> wrote: > > Speaking as the representative of RPSTIR team, > > We are working on RPSTIR update in order to make it use the new algorithm to > do INR validation. > > Before RP performs the new validation process, it needs to get the INRs from > certificates. And we found a bug of OPENSSL library when using OPENSSL to > get resource sets from certificates, so we wrote our own code to do so. > > It seems to me that the only concern on OID is about using OPENSSL to get > resource sets for further validation process. If the WG has decided to > deprecate the original by using the Validation Reconsidered, why bother to > bring a new OID ? > > Declan(Di) Ma > > ZDNS > >> 在 2017年3月13日，02:28，Chris Morrow <morr...@ops-netman.net> 写道： >> >> At Sat, 11 Mar 2017 17:25:27 -0500, >> Rob Austein <s...@hactrn.net> wrote: >>> >>> At Thu, 9 Mar 2017 18:44:58 +0000, Alvaro Retana (aretana) wrote: >>>> >>>> I just finished reading this document. My review is predicated on >>>> the assumption that the intent of the WG is to define an additional >>>> validation process, and not amend/change/update/deprecate the >>>> existing one?yet, which is why there are not only process changes >>>> specified, but also new OIDs. >>> >>> Alvaro, >>> >>> I will let the WG chairs and authors speak to intent regarding the >>> existing validation process. >>> >> >> I think the intent of the WG is still to add the new validation >> process, then deprecate the original once all users are on code which >> supports the 'new' way. >> >> -chris >> >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
