Show my share On Sat, Jul 16, 2022, 12:01 AM Anjam Saqib <anjamsaqi...@gmail.com> wrote:
> Ok done > > On Fri, Jul 15, 2022, 10:56 PM Rob Sayre <say...@gmail.com> wrote: > >> >> >> On Fri, Jul 15, 2022 at 10:47 AM Benjamin Kaduk <ka...@mit.edu> wrote: >> >>> On Fri, Jul 15, 2022 at 10:30:55AM -0700, Rob Sayre wrote: >>> > On Fri, Jul 8, 2022 at 7:19 AM Cullen Jennings via Datatracker < >>> > nore...@ietf.org> wrote: >>> > >>> > >>> > > I see no evidence of any >>> > > discussion of how that will work out for things that use HTTP but >>> are not >>> > > browsers. >>> > > >>> > >>> > There just aren't that many implementations on the client side. Not >>> only do >>> > you have to implement all of the HTTP versions and TLS, but you have to >>> > maintain all of the PKI stuff as well. Obviously, people do it, but >>> they >>> > are not the ones that need to read this document. >>> > >>> > If the TLS library is not one also used by the OS and a browser (NSS, >>> > SecureTransport, etc), it's probably OpenSSL. I don't think this is an >>> > oversight in the document. >>> >>> I think we need to be really careful with what we're considering as the >>> relevant population of clients when making statements like this, >> >> >> Sorry, I tried to leave a caveat in there for exactly this concern, but >> that seems to have failed. >> >> >>> Mbed TLS (Apache licensed, just like current OpenSSL) is much more >>> appropriate in those environments, >>> >> >> I don't think people that write programs like that will get a lot out of >> this document. I think they're not the audience (they will drop TLS 1.2 or >> support TLS 1.1 if they want/need to). >> >> thanks, >> Rob >> >> _______________________________________________ >> art mailing list >> a...@ietf.org >> https://www.ietf.org/mailman/listinfo/art >> >
_______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
