[prev in list] [next in list] [prev in thread] [next in thread]
List: ietf-tls
Subject: [TLS] SCVP Path Validation and OCSP Status Request
From: Ashley Kopman <akopman () conceptsbeyond ! com>
Date: 2022-10-11 16:44:05
Message-ID: 820916C1-FCCA-457A-99E2-DC31F7E0DFD3 () conceptsbeyond ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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
[Attachment #5 (unknown)]
<html><head><meta http-equiv="Content-Type" content="text/html; \
charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: \
space; line-break: after-white-space;" class=""><div class="">Our work on TLS \
extension for SCVP Path Validation <a \
href="https://datatracker.ietf.org/doc/draft-segers-tls-cert-validation-ext/" \
class=""><span style="color: #dca10d" \
class="">https://datatracker.ietf.org/doc/draft-segers-tls-cert-validation-ext/</span></a> has \
been paused for now due to concerns by the aviation community with possible patent \
infringement on a Motorola Solutions patent <span style="color: rgb(220, 161, 13);" \
class=""><a href="https://patents.google.com/patent/US20130159703" \
class="">https://patents.google.com/patent/US20130159703</a>.</span> 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.</div><div class=""><div style="margin: 0px; font-stretch: \
normal; line-height: normal; min-height: 15px;" class=""><br class=""></div><div \
style="margin: 0px; font-stretch: normal; line-height: normal;" class="">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 (<a \
href="https://datatracker.ietf.org/doc/html/draft-ietf-pkix-ocsp-valid-00" \
class=""><span style="color: #dca10d" \
class="">https://datatracker.ietf.org/doc/html/draft-ietf-pkix-ocsp-valid-00</span></a> \
<a href="https://datatracker.ietf.org/doc/html/draft-ietf-pkix-ocsp-dpvdpd" \
class=""><span style="color: #dca10d" \
class="">https://datatracker.ietf.org/doc/html/draft-ietf-pkix-ocsp-dpvdpd</span></a> \
<a href="https://datatracker.ietf.org/doc/html/draft-ietf-pkix-ocspv2-02" \
class=""><span style="color: #dca10d" \
class="">https://datatracker.ietf.org/doc/html/draft-ietf-pkix-ocspv2-02</span></a>) \
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?</div><div \
style="margin: 0px; font-stretch: normal; line-height: normal; min-height: 15px;" \
class=""><br class=""></div><div style="margin: 0px; font-stretch: normal; \
line-height: normal;" class="">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.</div></div><div style="margin: 0px; \
font-stretch: normal; line-height: normal;" class=""><br class=""></div><div \
style="margin: 0px; font-stretch: normal; line-height: normal;" class="">Thank \
you,</div><br class=""><div class=""> <div>Ashley Kopman</div><div class=""><br \
class=""></div><br class="Apple-interchange-newline">
</div>
<br class=""></body></html>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic