[TLS] SCVP Path Validation and OCSP Status Request

[Ashley Kopman <[e-mail]>]

Our work on TLS extension for SCVP Path Validation https://datatracker.ietf.org/doc/draft-segers-tls-cert-validation-ext/ <https://datatracker.ietf.org/doc/draft-segers-tls-cert-validation-ext/> has been paused for now due to concerns by the aviation community with possible patent infringement on a Motorola Solutions patent https://patents.google.com/patent/US20130159703 <https://patents.google.com/patent/US20130159703>. I believe the Motorola approach is different. Their approach requires changes to the SCVP protocol and responder to create a SCVP Staple Generator. Our approach makes no changes to the SCVP protocol or responder and only uses a TLS extension. But regardless, it is similar enough that we do not want to risk infringing on IP and I have been asked to look into alternate approaches to providing path validation. Thank you to everyone who provided feedback.

A possible approach that we have come across is using the OCSP status request extension and modifying the OCSP responder to perform delegated path validation. There was work done in the early 2000s on using OCSP for DPV (https://datatracker.ietf.org/doc/html/draft-ietf-pkix-ocsp-valid-00 <https://datatracker.ietf.org/doc/html/draft-ietf-pkix-ocsp-valid-00> https://datatracker.ietf.org/doc/html/draft-ietf-pkix-ocsp-dpvdpd <https://datatracker.ietf.org/doc/html/draft-ietf-pkix-ocsp-dpvdpd> https://datatracker.ietf.org/doc/html/draft-ietf-pkix-ocspv2-02 <https://datatracker.ietf.org/doc/html/draft-ietf-pkix-ocspv2-02>) but as far as I can tell none of these made it past early drafts. Does anyone know if there was a technical issue, a lack of interest, or something else?

To make the OCSP status request extension work for our needs, I believe I will need to use the OCSPStatusRequest ResponderID field to specify the OCSP responder(s) trusted by the TLS Client (aircraft in our case). I believe generally the AIA field in the certificate is used to determine the URI for the OCSP responder. But this field would point to the OCSP responder in the server domain (ground system in our case) rather than the client domain. By using the ResponderID field of the request we should be able to provide an OCSP response signed by a OCSP responder trusted by the client. But, unlike the AIA which contains an access location, the ResponderID is a choice of a relative distinguished name sequence or key hash. How is the TLS server intended to use the ResponderID to map to a OCSP responder URI? Ideally the server would not need to have prior knowledge of the OCSP responder trusted by the client.

Thank you,

Ashley Kopman