Hi Éric, On Mon, Jun 22, 2020 at 10:43:00AM +0000, Eric Vyncke (evyncke) wrote: > As the shepherding AD for this document, I am happy to see recent technical > discussions on this document. OTOH, I do not observe any convergence to > remove the pending DISCUSS. > > > > The 2nd IETF Last Call was completed 2 months ago in April 2020. Joel Halpern > did the review for routing directorate and found a couple of issues (zone-ID, > loopback definition) and it seems that there is now an agreement within the > community for updated the text. > > > > In order to progress the document, a revised I-D is needed to fix Ben’s > DISCUSS points: > > - Use of rfc822Name rather than otherName: the ‘easy’ fix is indeed to use > otherName (even with the section 6.1.2 justifications)
Russ has been helping reach out to more of the PKIX community; one suggestion that came up so far is to consider defining a dedicated URI scheme and using a uniformResourceIdentifier SAN -- did the WG consider that in the initial discussions? > - “MTI cryptographic mechanisms are under-specified” that should not be > controversial and easy to fix Toerless has been doing an incredible job reaching out to the IPsec community and getting this text nailed down. There are still a couple points still under discussion but I'm confident that we will have something good here (and IIRC the TLS stuff has already been polished). > - Clarification about the RPL root I'm pretty sure this is already done -- note that my latest ballot position is only for the -19, so I think I just didn't update it yet. > > > Unsure whether Eric Rescola’s DISCUSS are still applicable (as they were on > -16); but, this would be a plus to fix these points. Indeed. I expect the current SEC ADs to review those when the document comes up on a telechat again. > > > I understand that the authors have worked on this for 6 years and may be > bored but I would love to see this I-D going forward. Again, as many others I > fail to see the reason of using rfc822Name and the fix would be to use > otherName. I do not want to put words in anyone's mouth, but my understanding is that the "obvious alternatives" to otherName are believed to suffer from strong deployment difficulties, whether one attempts to use an existing (commercial, or so-called "public" CA) or COTS CA software to run one's own CA. (There is some question as to whether the "public CA" route is advisable at all, given the legal agreements and policy documents surrounding such CAs and whether issuing certificates intended for ACP use is compatible with those policy documents. Sean's review alluded to some of these topics, and if you manage to catch Ryan Sleevi when he has time, he can talk about them at length.) -Ben > > > May I also suggest to the authors to add new co-authors in order to have > ‘fresh blood’ and energy ? > > > > Regards > > > > -éric > > > > > > _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
