Re: [Uta] [art] [Last-Call] Artart last call review of draft-ietf-uta-rfc7525bis-09

Show my share

On Sat, Jul 16, 2022, 12:01 AM Anjam Saqib <anjamsaqib10@gmail.com> wrote:

> Ok done
>
> On Fri, Jul 15, 2022, 10:56 PM Rob Sayre <sayrer@gmail.com> wrote:
>
>>
>>
>> On Fri, Jul 15, 2022 at 10:47 AM Benjamin Kaduk <kaduk@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 <
>>> > noreply@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
>> art@ietf.org
>> https://www.ietf.org/mailman/listinfo/art
>>
>