This is the Aviation use case I mentioned in earlier mails.
I will be submitting a BOF request tomorrow, performa.
Of course it is for the ADs to decide if this is a standalone BOF or a
20min slot in SECDISPATCH.
How much time people want to discuss it is in large measure related to
the discussion we engender here.
Thank you for your attention. And thank you for reviewing and making
this a solid design that we can get deployed for avaiation Air-to-ground
and any similar use case.
Bob
On 5/26/22 19:43, Ashley Kopman wrote:
The use case for the D(TLS) Path Validation extension in civil
aviation has been submitted
https://www.ietf.org/archive/id/draft-segers-tls-cert-val-ext-use-case-00.txt there
is also referenced slide deck available
http://conceptsbeyond.com/resources/SCVPValidationRequest_UseCase_CB.pdf
Thank you,
Ashley Kopman
On May 26, 2022, at 8:36 AM, Ashley Kopman
<akop...@conceptsbeyond.com> wrote:
Ilari,
Thank you for your feedback.
You are correct in assuming that this was designed after the OCSP
status_request extension. It is a valid point that the extension can
likely be omitted from the server hello. The intent was to
communicate to the client that the server supports the extension and
will respond with the path validation information. However, since it
is allowed for the server to respond with the extension and then not
supply the path validation, it is not very useful overhead. I will
remove the extension from the server hello.
You are also correct that sending the certificate chain becomes
unnecessary. It was my intent to communicate that, but looking back
at the draft, I don’t think I made it clear. I will add it.
Thank you,
Ashley
On May 25, 2022, at 2:23 PM, Ilari Liusvaara
<ilariliusva...@welho.com> wrote:
On Wed, May 25, 2022 at 12:40:13PM -0400, Ashley Kopman wrote:
Hi TLS,
I have just submitted a draft TLS Extension for Path Validation
https://www.ietf.org/archive/id/draft-segers-tls-cert-validation-ext-00.txt
<https://www.ietf.org/archive/id/draft-segers-tls-cert-validation-ext-00.txt>
The proposal is for a Path Validation Extension to provide a new
protocol for TLS/DTLS allowing inclusion of certificate path
validation information in the TLS/DTLS handshake. Specifically, it
covers the use of Server-based Certificate Validation Protocol
(SCVP) for path validation.
Looking at how this is integrated to (D)TLS:
For (D)TLS 1.2, the server extension does not seem to be technically
necressary, and omitting it could simplify things. Yes, this design
is the same as one used for OCSP stapling (status_request), but I
found the server hello extension in OCSP to be seemingly unnecressary
extra complexity.
For (D)TLS 1.3, why there are seemingly two server extensions, one in
server hello, which is usually only used for low-level crypto stuff,
which this is not, and another in certificate message (which makes
sense for certificate-related thing.
And this is maybe a stupid question, but I didn't find an answer by
quickly looking at the draft nor the SCVP RFC, does the server need to
send the certificate chain to the client if it sends the SCVP response,
or just the end-entity certificate? Omitting the chain could save
quite a bit of handshake size.
-Ilari
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
