Joseph Salowey <[email protected]> wrote:
    > On Fri, Oct 30, 2020 at 4:44 AM Michael Richardson <[email protected]>
    > wrote:

    >>
    >> Joseph Salowey <[email protected]> wrote:
    >> >> I suggest:
    >> >>
    >> >> “EAP-TLS servers supporting TLS 1.3 that use OCSP to do certificate
    >> >> recovation checks,  MUST implement Certificate Status Requests
    >> using OCSP
    >> >> stapling as specified in Section 4.4.2.1 of [RFC8446].
    >>
    >> > [Joe] Thanks Michael,  I think your suggestion is a better way to
    >> phrase it
    >>
    >> Just so that we are clear:  this mandates OCSP+stapling for systems that 
do
    >> revocation checks.
    >>
    >> Systems that don't do revocation checks (current mbedtls), therefore 
don't
    >> need to do OCSP or stapling.
    >>

    > [Joe] That's not how I read your text.  I think your text mandates
    > OCSP+stapling for systems that use OCSP for revocation.

    > TLS 1.3 RFC 8446 does not mandate a particular revocation mechanism 
either,
    > as revocation is part of PKIX.

I thought that someone said that it did.
In which case, we are under no additional compulsion to support revocation
than we were before.

Hannes and Eliot have brought up significant operational challenges in
supporting OCSP in some environments.  I think that it should be a local 
decision.

    > Also to be clear you text does not mandate that either servers or clients
    > support OCSP Stapling.

    > I think it would be appropriate to modify your text to replace "use" with
    > support.

    > "EAP-TLS servers supporting TLS 1.3 that support OCSP to do certificate
    > revocation checks,  MUST implement Certificate Status Requests using OCSP
    > stapling as specified in Section 4.4.2.1 of [RFC8446]."

okay.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email protected]  http://www.sandelman.ca/        |   ruby on rails    [






    >> --
    >> Michael Richardson <[email protected]>   . o O ( IPv6 IøT consulting 
)
    >> Sandelman Software Works Inc, Ottawa and Worldwide
    >>
    >>

    > ----------------------------------------------------
    > Alternatives:

    > ----------------------------------------------------

--
Michael Richardson <[email protected]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide




Attachment: signature.asc
Description: PGP signature

_______________________________________________
Emu mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/emu

Reply via email to