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
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 Kop
,
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
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
edback.
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
> te
That is a fair point. I will make the update and submit a new draft.
Thank you for the feedback.
Ashley Kopman
>
> On Jul 25, 2022, at 4:25 PM, Russ Housley wrote:
>
> I was thinking the same thing during the presentation. An extension for
> SCVP seems fine to me. The
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 wr
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:
>
> A
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
tps://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 remov
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
nd 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, ou
> 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 p
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
_
14 matches
Mail list logo
