Thanks for the info about mozilla::pkix. I think that webpki looks like it might be the right answer for a certificate library.
I 100% understand the desire to use a pure Rust TLS library for Servo, but I think we need to not ignore the fact that there isn't one right now. Ring implements the crypto primitives, not the protocols. Rustls is promising, but it's brand new and lacks a number of features required to be a full TLS library (and that's if the owner/community decide to allow insecure algorithms for the sake of web compatibility). I don't think that Servo has the resources to majorly contribute to a new TLS library in Rust. This leaves a few options: 1. Continue with OpenSSL bindings until there's a more mature rust TLS implementation 2. Create bindings for another library >From this point, I think we should look at the resource problem. How much work will it take to maintain/improve the OpenSSL bindings? Who can do this? Ditto for the bindings for another library. This leads me to the reason that I proposed NSS in the first place--I spoke to the NSS team and they're interested in having Rust bindings, so they can help create them (thus alleviating the resource problem). Personally, I think this would be beneficial to the Rust community as well as Servo. On Tue, Sep 6, 2016 at 10:38 PM, Jack Moffitt <j...@metajack.im> wrote: > > Outside of the NSS team, who has more confidence in NSS than *ring* + > > webpki + Rustls, BoringSSL, or OpenSSL? And, what is the reasoning? > > I think the assumption here is that many people outside the current > Rust community would have more confidence in NSS, BoringSSL, or > OpenSSL than Ring + rusttls + webpki. I think the reason behind that > is age, and that reason will not be true indefinitely. You've made > good points elsewhere in this thread that the bindings may introduce > some confidence problems of their own, and perhaps that invalides some > of the assumption. > > I don't think Diane's proposal intended to imply we have more > confidence in NSS over BoringSSL. The choice of NSS was due to other > factors like BoringSSL having no stable API and being discouraged for > wider use. > > jack. > _______________________________________________ > dev-servo mailing list > dev-servo@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-servo > -- Diane Hosfelt avadacatavra _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
