Just replying on one thing... On Thu, Apr 12, 2018 at 10:03:11AM +0100, Neil Madden wrote: > Hi Brian, > > Thanks for the detailed responses. Comments in line below (marked with ***). > > Neil > > > On Wednesday, Apr 11, 2018 at 9:47 pm, Brian Campbell > > <bcampb...@pingidentity.com (mailto:bcampb...@pingidentity.com)> wrote: > > On Thu, Mar 29, 2018 at 9:18 AM, Neil Madden <neil.mad...@forgerock.com > > (mailto:neil.mad...@forgerock.com)> wrote: > > > 10. The PKI client authentication method > > > (https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-2.1) makes > > > no mention at all of certificate revocation and how to handle checking > > > for that (CRLs, OCSP - with stapling?). Neither does the Security > > > Considerations. If this is a detail to be agreed between then AS and the > > > CA (or just left up to the AS TLS stack) then that should perhaps be made > > > explicit. Again, there are privacy considerations with some of these > > > mechanisms, as OCSP requests are typically sent in the clear (plain HTTP) > > > and so allow an observer to see which clients are connecting to which AS. > > > > I didn't think that a TLS client could do OCSP stapling? > > > > *** I think you are right about this. I always assumed it was symmetric > > (and I think it technically could work), but the spec only talks about > > stapling in the server-side of the handshake.
This changed between TLS 1.2 and TLS 1.3 -- in 1.3, the server can include "status_request" in its CertificateRequest, and the extensions block in the client's Certificate message can include the OCSP staple. -Ben
signature.asc
Description: PGP signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
