On Thu, Apr 23, 2015 at 11:28 AM, Phillip Hallam-Baker < [email protected]> wrote:
> On Thu, Apr 23, 2015 at 10:16 AM, Richard Barnes <[email protected]> wrote: > > > We can design mechanisms here that we believe have a sufficient level of > > security. CABF and the individual CAs are free to opine on whether those > > mechanisms are suitable for a given context. > > > > In other words, it is my earnest hope that the validation methods listed > in > > Section 11.1.1 of the BRs [1] will not be designed by the CABF, but > selected > > from a list that IETF defines. CABF is not an engineering organization, > > after all. > > I think we can decide on a mechanism. But getting into long arguments > as to whether ports other then 443 should be accepted or if so which > ones seems to be unnecessary. > > IETF should deliver > > * A mechanism with sufficient agility and flexibility > * Security considerations explaining the consequences of a CA > permitting various approaches > I think what we're arguing about here is what constitutes "sufficient flexibility". That is, if there's not a need to open up arbitrary ports, then a scheme with a single reserved non-443 port might provide sufficient flexibility. --Richard > > Then let the decision of which ports are to be allowed and when to > CABForum. > > This is exactly what happens with crypto algorithms. IETF has > described dozens of algorithms and curves for ECC, CABForum has chosen > RSA plus three of the NIST curves. > > > What I am saying is let CABForum select the color to paint the bike > shed but point out where the choice has consequences. >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
