[TLS] SCVP Path Validation and OCSP Status Request

[Ashley Kopman]

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



___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] New Version for draft-segers-tls-cert-validation-ext

[Ashley Kopman]

I apologize that I misunderstood your point. 

I’m happy to provide an example. I am out of the office for the next few days 
and may need to remove FAA specific details from the data before sending it. I 
will try to send you some examples later this week. 

Thank you,
Ashley

Sent from my iPhone

> On Aug 27, 2022, at 5:16 AM, Peter Gutmann  wrote:
> 
> Ashley Kopman  writes:
> 
>> But I want to be clear that I do not intend to implement a solution and try
>> to sell it to the community.
> 
> Sure, and I wasn't saying that, just pointing out the problems that have
> arisen in other situations where industry bodies have adopted orphan standards
> that ended up requiring custom implementations and support, which gives
> vendors a pretty captive market.
> 
> Speaking of which, the ASN.1 diagnostic tool dumpasn1 doesn't currently have
> any real support for SCVP in it because until now I've never been able to find
> any examples of it.  Do you, or anyone else, have samples of a typical request
> and response, and the accompanying policy request and response, that I could
> use to test dumpasn1 on?  I haven't looked at RFC 5055 for a long time but
> just skimmed it recently and it looks like a prime example of the problems I
> described in my previous message, all SEQUENCE OF SEQUENCE { CHOICE { CHOICE {
> CHOICE { SEQUENCE OF { OPTIONAL, OPTIONAL, OPTIONAL, OPTIONAL, OPTIONAL } } }
> } }, there's so many variants and optional pieces that I'd have no idea what's
> actually used in practice.  That's also why I'm fairly surprised that anyone
> was able to achieve interoperability with that as the spec, unless there's a
> profile of it somewhere that I don't know about.
> 
> Peter.
> 

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] New Version for draft-segers-tls-cert-validation-ext

[Ashley Kopman]

Peter,

Thank you for taking the time to respond and for explaining the history behind 
this. You make some very valid points.

I don’t believe we have sacrificed any functionality by making the extension 
generic enough to be used by others. It has been designed with the global civil 
aviation community's needs in mind. But that is a large community with varying 
needs.

I fully recognize that SCVP is not widely used. I would also not consider it to 
be nonexistent. We have been using it in ground to ground communications. There 
are at least three COTS offerings of SCVP Servers. Not a lot, but some 
competition. I have personally tested interoperability with two of the three. 
This testing was done between FAA and EUROCONTROL with separate vendors and 
client implementations. We found some inconsistencies but overall 
interoperability went quite smoothly. I believe this is because an RFC 
followed. We do not intend to implement our own SCVP Server.

As for this extension, in aviation this will not be implemented by a single 
vendor. It will require implementation by different aircraft,OEM and ground 
system vendors worldwide. ICAO is looking to make support for this a 
requirement for ground systems (optional for aircraft). Admittedly, this is all 
within the global civil aviation community. But I want to be clear that I do 
not intend to implement a solution and try to sell it to the community. My 
implementation will be for testing the viability of the extension and will be 
released open-source. Our business model is not what you describe.

With all of that said, I am here asking for guidance. I am new to this 
community. I am not trying to game any bureaucratic processes. I am excited to 
have the opportunity to interact with the experts in this area and to hopefully 
make a contribution. 

I will follow Rob’s advice and reach out to the Chairs and AD. Any other advice 
is welcomed.

Thank you,

Ashley Kopman


> On Aug 26, 2022, at 6:15 AM, Peter Gutmann  wrote:
> 
> Ashley Kopman  writes:
> 
>> Although our use case is aviation, our goal is to write this draft so that it
>> can be used by other domains.
> 
> Someone has to say this, so I may as well: I don't think you'll have to worry
> about anyone else using it.  The PKIX WG left behind it a long trail of RFCs
> that no-one ever implemented except for maybe one sample attempt by the
> company that commissioned the RFC.  One notorious example is one of the
> protocols with "path validation" in the name somewhere for which the sole
> known sort-of implementation at the time was a set of abandoned patches to
> OpenSSL dating from about 2005 located on an FTP server in a disused lavatory
> in France with a "Beware of the leopard" sign on the door [0].
> 
> The problem is that every now and then some industry body finds one of these
> RFCs and decides that they're exactly what they need without being aware of
> the fact that support for them is essentially nonexistent, thus my surprise
> when mention of SCVP use came up a few months ago, it was one of the many
> protocols that had no known, or at least visible, support anywhere.
> 
> From a vendor point of view this is brilliant because you get paid once to
> implement your guess at some protocol that none of the usual suspects supports
> so it's necessary to commission a custom implementation, and then again for
> each other custom implementation that it has to talk to when you try and
> reverse-engineer what their guess at the protocol was.  Then once it's
> implemented you've got a captive market with very little choice for
> alternatives or competitive pressure.  It's, um, great for business.
> 
> More difficult is when said industry body specifies stuff that's in the spec
> but that absolutely nobody implements, typically because nobody can figure out
> why it's in the spec or what purpose it serves.  If there's five different
> ways of doing the same thing (there usually are in PKIX specs), industry
> bodies have an unerring knack for picking one of the four that no-one
> implements because when you do you realise they don't make any sense, rather
> than the one that does.  This is less good because as an implementer you're
> now stuck between a rock and a hard place.  Technically what's being asked for
> is in the spec so you end up in a long argument over whether the contract
> should be interpreted as "follows the spec" or whether it should be "works in
> practice", and if it's the former, how the other implementation managed to
> create something that appears to work ("accept any old rubbish that arrives"
> seems to be one approach, including in one case a Stalin quote in what was
> supposed to be a security-relevant field).
> 
> After all that, two comments:
> 
> 1. You may as well

Re: [TLS] New Version for draft-segers-tls-cert-validation-ext

[Ashley Kopman]

Rob,

Thank you for your explanation.

Although our use case is aviation, our goal is to write this draft so that it 
can be used by other domains. Since this group has the experts in TLS, any 
suggestions on the technical approach is extremely useful.

As far as approval, it is our hope that this can become an IETF standard. 
Aviation for a long time has relied on custom one-off solutions and is trying 
to use standardized solutions. ICAO has agreed to move forward with this 
approach contingent on its publication as a standard. I am new to this process, 
so please correct me if I have misunderstood, but I believe the first step in 
possibly becoming a standard is to have this work adopted by this group.

In parallel, I am also developing an implementation of this extension that will 
hopefully be brought to the Hackathon in London. We are also engaging aircraft 
and OEM vendors to have others develop independent implementations.

Thank you,

Ashley


> On Aug 24, 2022, at 5:43 PM, Rob Sayre  wrote:
> 
> On Wed, Aug 24, 2022 at 7:52 AM Ashley Kopman  <mailto:akop...@conceptsbeyond.com>> wrote:
> I would greatly appreciate any feedback on this draft as well as any feedback 
> on the next steps for working with the TLS working group.
> 
> Maybe the best thing to remember is that we can only offer suggestions. You 
> don't need approval, but everyone is here to make your draft better, if we 
> can.* Ultimately, internet engineers usually don't have useful things to say 
> about aviation, so it's best to think of it as a supportive environment where 
> the authors ultimately make the decision.
> 
> thanks,
> Rob
> 
> * https://courses.cs.duke.edu/common/compsci092/papers/govern/consensus.pdf 
> <https://courses.cs.duke.edu/common/compsci092/papers/govern/consensus.pdf>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] New Version for draft-segers-tls-cert-validation-ext

[Ashley Kopman]

We received feedback from the aviation community that there is a need for this 
extension to be included in the CertificateRequest message for the case where 
the server rather than the client is the constrained resource (the aircraft in 
our use case). I have updated the draft to reflect the addition of the 
CertificateRequest extension and submitted a new draft 04. I would greatly 
appreciate any feedback on this draft as well as any feedback on the next steps 
for working with the TLS working group.

 https://www.ietf.org/archive/id/draft-segers-tls-cert-validation-ext-04.html 
<https://www.ietf.org/archive/id/draft-segers-tls-cert-validation-ext-04.html>

Thank you,

Ashley Kopman


> On Aug 4, 2022, at 1:51 PM, Ashley Kopman  wrote:
> 
> Hi,
> 
> We presented this work at IETF 114. Thank you to everyone who provided 
> feedback. 
> 
> I have removed the extensibility to future path validation types and limited 
> the scope of this extension to just SCVP. I have also added discussion on how 
> the server should handle it if other path validation extensions are added in 
> the future (at the end of Section 2). Version 03 is available for review 
> https://www.ietf.org/archive/id/draft-segers-tls-cert-validation-ext-03.html 
> <https://www.ietf.org/archive/id/draft-segers-tls-cert-validation-ext-03.html>
> 
> I am new to the IETF, so I apologize in advance if this is not the correct 
> process, but I believe the next step is to ask that this draft be considered 
> for adoption by the TLS Working Group.
> 
> Thank you,
> 
> Ashley Kopman

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] New Version for draft-segers-tls-cert-validation-ext

[Ashley Kopman]

Hi,

We presented this work at IETF 114. Thank you to everyone who provided 
feedback. 

I have removed the extensibility to future path validation types and limited 
the scope of this extension to just SCVP. I have also added discussion on how 
the server should handle it if other path validation extensions are added in 
the future (at the end of Section 2). Version 03 is available for review 
https://www.ietf.org/archive/id/draft-segers-tls-cert-validation-ext-03.html 


I am new to the IETF, so I apologize in advance if this is not the correct 
process, but I believe the next step is to ask that this draft be considered 
for adoption by the TLS Working Group.

Thank you,

Ashley Kopman___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Extensibility in SCVP draft

[Ashley Kopman]

That is a good suggestion. I will look into expanding on the text to address 
this concern.

Thank you,

Ashley

> On Jul 26, 2022, at 1:33 PM, Rob Sayre  wrote:
> 
> On Tue, Jul 26, 2022 at 9:08 AM Ashley Kopman  <mailto:akop...@conceptsbeyond.com>> wrote:
> 
> Are you concerned that if additional validation extensions were added it 
> could lead to multiple validations for the same handshake? If that is the 
> case, I believe that this is somewhat mitigated by it being optional for the 
> server to choose to perform the SCVP validation. If the TLS server were to 
> receive multiple validation requests it could potentially select to perform 
> only one.
> 
> Hi,
> 
> It's correct that this is my concern, and I thought you might consider adding 
> text along these lines to the document.
> 
> I don't feel strongly about this issue, though.
> 
> thanks,
> Rob
> 
> 
> 
> 
>  
> 
> If I have missed your point, please let me know.
> 
> Thank you,
> Ashley Kopman
> 
>> On Jul 25, 2022, at 11:30 PM, Rob Sayre > <mailto:say...@gmail.com>> wrote:
>> 
>> Hi,
>> 
>> Doesn’t it depend on whether it would be easier to do this select* or deal 
>> with multiple validations in the same message? No one’s said that exactly 
>> afaik, but I haven’t watched the meeting yet.
>> 
>> thanks,
>> Rob
>> 
>> * in the recent past, the stuff I’ve worked on has made this easy, but I 
>> agree they’re a bit annoying.
>> 
>> On Mon, Jul 25, 2022 at 13:25 Russ Housley > <mailto:hous...@vigilsec.com>> wrote:
>> I was thinking the same thing during the presentation.  An extension for 
>> SCVP seems fine to me.  Then in the future, if another validation comes 
>> along some day, a new extension can be assigned for that protocol.
>> 
>> Russ
>> 
>> > On Jul 25, 2022, at 4:13 PM, Martin Thomson > > <mailto:m...@lowentropy.net>> wrote:
>> > 
>> > Take this:
>> > 
>> > struct {
>> > PathValidationType path_validation_type;
>> > select (path_validation_type) {
>> >  case scvp: SCVPValidationRequest;
>> > } request;
>> > } PathValidationRequest;
>> > enum { scvp(1), (255) } PathValidationType;
>> > 
>> > This adds a layer of extensibility that doesn't do a lot.  Please consider 
>> > making this less generic.  If we want a different validation design, then 
>> > another extension can be defined.  We have a poor track record of being 
>> > able to use these nested extension points and it will be more efficient to 
>> > just put the SCVP pieces in their own extension.
>> 
>> ___
>> TLS mailing list
>> TLS@ietf.org <mailto:TLS@ietf.org>
>> https://www.ietf.org/mailman/listinfo/tls 
>> <https://www.ietf.org/mailman/listinfo/tls>
> 

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Extensibility in SCVP draft

[Ashley Kopman]

Rob,

I apologize, I am not sure that I fully understand your question. I originally 
created the structure of path_validation_type to make it easier in the future 
to potentially expand the extension to use other protocols for path validation. 
But Martin, Rich and Russ pointed out that this likely adds an unnecessary 
layer of nesting complexity that may never be utilized. 

Are you concerned that if additional validation extensions were added it could 
lead to multiple validations for the same handshake? If that is the case, I 
believe that this is somewhat mitigated by it being optional for the server to 
choose to perform the SCVP validation. If the TLS server were to receive 
multiple validation requests it could potentially select to perform only one.

If I have missed your point, please let me know.

Thank you,
Ashley Kopman

> On Jul 25, 2022, at 11:30 PM, Rob Sayre  wrote:
> 
> Hi,
> 
> Doesn’t it depend on whether it would be easier to do this select* or deal 
> with multiple validations in the same message? No one’s said that exactly 
> afaik, but I haven’t watched the meeting yet.
> 
> thanks,
> Rob
> 
> * in the recent past, the stuff I’ve worked on has made this easy, but I 
> agree they’re a bit annoying.
> 
> On Mon, Jul 25, 2022 at 13:25 Russ Housley  <mailto:hous...@vigilsec.com>> wrote:
> I was thinking the same thing during the presentation.  An extension for SCVP 
> seems fine to me.  Then in the future, if another validation comes along some 
> day, a new extension can be assigned for that protocol.
> 
> Russ
> 
> > On Jul 25, 2022, at 4:13 PM, Martin Thomson  > <mailto:m...@lowentropy.net>> wrote:
> > 
> > Take this:
> > 
> > struct {
> > PathValidationType path_validation_type;
> > select (path_validation_type) {
> >  case scvp: SCVPValidationRequest;
> > } request;
> > } PathValidationRequest;
> > enum { scvp(1), (255) } PathValidationType;
> > 
> > This adds a layer of extensibility that doesn't do a lot.  Please consider 
> > making this less generic.  If we want a different validation design, then 
> > another extension can be defined.  We have a poor track record of being 
> > able to use these nested extension points and it will be more efficient to 
> > just put the SCVP pieces in their own extension.
> 
> ___
> TLS mailing list
> TLS@ietf.org <mailto:TLS@ietf.org>
> https://www.ietf.org/mailman/listinfo/tls 
> <https://www.ietf.org/mailman/listinfo/tls>

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Draft TLS Extension for Path Validation

[Ashley Kopman]

Version -01 of this draft has been submitted 
https://www.ietf.org/archive/id/draft-segers-tls-cert-validation-ext-01.txt 
<https://www.ietf.org/archive/id/draft-segers-tls-cert-validation-ext-01.txt>

It incorporates updates based on the comments we have received so far.
Limit this to (D)TLS 1.3, removed (D)TLS 1.2
Removed extension from Server Hello, only included in Client Hello and 
Certificate messages
Make clear that the server does not need to send the certificate chain when 
sending an SCVP response, only the end-entity certificate.
Thank you to everyone who has provided feedback.

Ashley Kopman


> On Jun 1, 2022, at 9:42 AM, Ira McDonald  wrote:
> 
> Hi Ashley,
> 
> Bear in mind that DTLS 1.3 languished in the RFC Editor's queue for over a 
> year.
> 
> The major TLS libraries have had implementations and have been doing interop 
> testing
> for a long time.  Simply doing software update to current library versions 
> would make
> DTLS 1.3 available in civil aviation.
> 
> FWIW - The Common Criteria standard workgroup for Network Devices (routers, 
> switches, 
> etc.) has approved the mandatory requirement for DTLS 1.3 in their next 
> version (draft in 
> July 2022 for publication in fall 2022).
> 
> Cheers,
> - Ira
> 
> On Tue, May 31, 2022 at 12:32 PM Ashley Kopman  <mailto:akop...@conceptsbeyond.com>> wrote:
> Eric,
> 
> Thank you for your comments.
> 
> My initial concern with limiting this to (D)TLS 1.3 was that the DTLS 1.3 RFC 
> has just been released and support is not yet widely available. However, our 
> use case is for civil aviation and it will take time for the community begin 
> using it. By that time there should be sufficient support for DTLS 1.3. I 
> believe it is possible to limit this to (D)TLS 1.3. I will make the update to 
> the draft.
> 
> Thank you,
> 
> Ashley
> 
> 
>> On May 28, 2022, at 5:27 PM, Eric Rescorla > <mailto:e...@rtfm.com>> wrote:
>> 
>> I took a quick look at this draft. A few comments follow.
>> 
>> 
>> VENUE
>> The correct venue for this work is the TLS WG. This is a relatively
>> straightforward piece of work that is clearly within the TLS WG's
>> charter scope ("This includes extensions or changes that help
>> protocols better use TLS as an authenticated key exchange protocol").
>> To that end, I don't think we need a BOF or SECDISPATCH. I would
>> encourage you to ask for TLS WG time in PHL.
>>  
>> 
>> TECHNICAL
>> In general, we are trying to avoid extending (D)TLS 1.2, so it would
>> be good if we could limit this to (D)TLS 1.3. Is that possible?
>> 
>> I realize that the certificate_status message extension includes a new
>> message, but I think that's proven to be kind of an anti-pattern.
>> If you are going to put this in (D)TLS 1.2, I would just put it in
>> a ServerHello extension, which more closely parallels (D)TLS 1.3.
>> 
>> If you use extensions, then you can register them with Specification
>> Required, which would allow you to publish in the Independent Stream
>> (or some other venue) to register the code points should the TLS
>> WG choose not to take up this work.
>> 
>> -Ekr
>> 
>> 
>> 
>> On Thu, May 26, 2022 at 4:53 PM Robert Moskowitz > <mailto:rgm-...@htt-consult.com>> wrote:
>> 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
>>>  
>>> <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 
>>> <http://conceptsbeyond.com/resources/SCVPValidationRequest_UseCase_CB.pdf>
>>> 
>>> Thank you,
>>> Ashley Kopman
>>> 
>>>> On May 26, 2022, at 8:36 AM, Ashley Kopman >>

Re: [TLS] Draft TLS Extension for Path Validation

[Ashley Kopman]

Eric,

Thank you for your comments.

My initial concern with limiting this to (D)TLS 1.3 was that the DTLS 1.3 RFC 
has just been released and support is not yet widely available. However, our 
use case is for civil aviation and it will take time for the community begin 
using it. By that time there should be sufficient support for DTLS 1.3. I 
believe it is possible to limit this to (D)TLS 1.3. I will make the update to 
the draft.

Thank you,

Ashley


> On May 28, 2022, at 5:27 PM, Eric Rescorla  wrote:
> 
> I took a quick look at this draft. A few comments follow.
> 
> 
> VENUE
> The correct venue for this work is the TLS WG. This is a relatively
> straightforward piece of work that is clearly within the TLS WG's
> charter scope ("This includes extensions or changes that help
> protocols better use TLS as an authenticated key exchange protocol").
> To that end, I don't think we need a BOF or SECDISPATCH. I would
> encourage you to ask for TLS WG time in PHL.
>  
> 
> TECHNICAL
> In general, we are trying to avoid extending (D)TLS 1.2, so it would
> be good if we could limit this to (D)TLS 1.3. Is that possible?
> 
> I realize that the certificate_status message extension includes a new
> message, but I think that's proven to be kind of an anti-pattern.
> If you are going to put this in (D)TLS 1.2, I would just put it in
> a ServerHello extension, which more closely parallels (D)TLS 1.3.
> 
> If you use extensions, then you can register them with Specification
> Required, which would allow you to publish in the Independent Stream
> (or some other venue) to register the code points should the TLS
> WG choose not to take up this work.
> 
> -Ekr
> 
> 
> 
> On Thu, May 26, 2022 at 4:53 PM Robert Moskowitz  <mailto:rgm-...@htt-consult.com>> wrote:
> 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
>>  
>> <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 
>> <http://conceptsbeyond.com/resources/SCVPValidationRequest_UseCase_CB.pdf>
>> 
>> Thank you,
>> Ashley Kopman
>> 
>>> On May 26, 2022, at 8:36 AM, Ashley Kopman >> <mailto: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 >>> <mailto: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>
>>>>>  
>>>>> <https://www.ietf.org/archive/id/draft-segers-tls-cert-val

Re: [TLS] Draft TLS Extension for Path Validation

[Ashley Kopman]

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 
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 
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

Re: [TLS] Draft TLS Extension for Path Validation

[Ashley Kopman]

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  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] Draft TLS Extension for Path Validation

[Ashley Kopman]

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.

We are also finalizing a use case for civil aviation air-to-ground 
communications which should be submitted in the next day.

Please have a look at the draft and provide feedback.

Thank you,

Ashley Kopman



___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls