>
> If you are going to do this, you might as well go the whole hog and
> provide a mechanism that allows the client to say if it already has a cert
> on file for that particular host, e.g. by means of a digest.
>
If clients cache intermediates as they go, then reporting that list to a
server is a
Looks like a slippery slope to me. Hang on, I will get my skis.
If you are going to do this, you might as well go the whole hog and provide
a mechanism that allows the client to say if it already has a cert on file
for that particular host, e.g. by means of a digest.
Another approach to consider
On Tue, Jul 11, 2023 at 09:37:19PM +0100, Dennis Jackson wrote:
> Hi Ilari,
>
> On 10/07/2023 20:19, Ilari Liusvaara wrote:
> >
> > And an alternative idea:
> >
> > [...]
> >
> > 1) Where if next certificate in chain is also not found, zstd uses
> > empty dictionary. Otherwise it uses dictio
ompressing the leaf fields
does not buy us anything.
-Original Message-
From: Dennis Jackson
Sent: Friday, July 14, 2023 6:28 AM
To: Kampanakis, Panos ; TLS List
Subject: RE: [EXTERNAL][TLS] Abridged Certificate Compression
CAUTION: This email originated from outside of the organizati
things:
https://github.com/dennisjackson/draft-jackson-tls-cert-abridge/pull/9.
From: TLS on behalf of Dennis Jackson
Sent: 14 July 2023 11:30
To: TLS List
Subject: Re: [TLS] Abridged Certificate Compression
CAUTION: This email originated from outside of the organizat
On 13/07/2023 02:31, Kampanakis, Panos wrote:
Btw, in 3.1.1 I noticed
- "Remove all intermediate certificates which are not signed by root certificates
still in the listing."
That could eliminate some 2+ ICA cert chains. Any reason why?
Whoops, that's a good spot. The intent here was just to r
cluding the tag and length octets).
*From:* TLS on behalf of Tim Hollebeek
*Sent:* 12 July 2023 19:29
*To:* Kampanakis, Panos ; Dennis
Jackson ; TLS List
*Subject:* Re: [TLS] Abridged Certificate Compression
CAUTION:
023 12:39 PM
To: Kampanakis, Panos ; TLS List
Subject: RE: [EXTERNAL][TLS] Abridged Certificate Compression
CAUTION: This email originated from outside of the organization. Do not click
links or open attachments unless you can confirm the sender and know the
content is safe.
On 12/07/2023 04:34, Ka
nakis, Panos
> Sent: Wednesday, July 12, 2023 9:31 PM
> To: Dennis Jackson ; TLS List
>
> Subject: Re: [TLS] Abridged Certificate Compression (dictionary versioning)
>
> I wish there was a study of the certs issued by newly introduced CAs in CCADB
> and how quickly they ramp up
log's public key to a (minimum 4-byte)
DER-encoded OID (excluding the tag and length octets).
From: TLS on behalf of Tim Hollebeek
Sent: 12 July 2023 19:29
To: Kampanakis, Panos ; Dennis Jackson
; TLS List
Subject: Re: [TLS] Abridged Certificate Compre
reason why?
-Original Message-
From: Dennis Jackson
Sent: Wednesday, July 12, 2023 1:01 PM
To: Kampanakis, Panos ; TLS List
Subject: RE: [EXTERNAL][TLS] Abridged Certificate Compression (dictionary
versioning)
CAUTION: This email originated from outside of the organization. Do not cl
>
> On Wed, Jul 12, 2023, 11:31 AM Tim Hollebeek 40digicert@dmarc.ietf.org> wrote:
>
>> SCTs have always seemed surprisingly large to me, and it has always seemed
>> like there should be a more compact representation that has the same
>> security
>> properties, but I've never found the time to
dnesday, July 12, 2023 2:23 PM
> > To: Dennis Jackson ; TLS List
> >
> > Subject: Re: [TLS] Abridged Certificate Compression
> >
> > > The performance benefit isn't purely in the ~1KB saved, its whether it
> brings
> > the chain under the QUIC
ze of SCTs would be quite
helpful.
-Tim
> -Original Message-
> From: TLS On Behalf Of Kampanakis, Panos
> Sent: Wednesday, July 12, 2023 2:23 PM
> To: Dennis Jackson ; TLS List
>
> Subject: Re: [TLS] Abridged Certificate Compression
>
> > The performance benefi
look forward to thinking more about and discussing
in a few weeks.
-Tim
> -Original Message-
> From: TLS On Behalf Of Kampanakis, Panos
> Sent: Wednesday, July 12, 2023 2:01 PM
> To: Dennis Jackson ; TLS List
>
> Subject: Re: [TLS] Abridged Certificate Compression (server
#x27;t have the
luxury of CT logs. But we would still want to option of compressing / omitting
the ICAs by using CCADB.
-Original Message-
From: Dennis Jackson
Sent: Wednesday, July 12, 2023 12:39 PM
To: Kampanakis, Panos ; TLS List
Subject: RE: [EXTERNAL][TLS] Abridged Certi
o bad.
-Original Message-
From: TLS On Behalf Of Dennis Jackson
Sent: Wednesday, July 12, 2023 1:16 PM
To: Kampanakis, Panos ; TLS List
Subject: RE: [EXTERNAL][TLS] Abridged Certificate Compression (server
participation)
CAUTION: This email originated from outside of the organization. Do not click
On 12/07/2023 05:02, Kampanakis, Panos wrote:
The abridged certs draft requires a server who participates and fetches
dictionaries in order to make client connections faster. As Bas has pointed out
before, this paradigm did not work well with OSCP staples in the past. Servers
did not chose to
On 12/07/2023 04:54, Kampanakis, Panos wrote:
Hi Dennis,
Appendix B.1 talks about 100-200 new ICA and 10 Root certs per year. In the
past I had looked at fluctuations of CCADB and there are daily changes. When
checking in the past, I did not generate the ordered list as per pass 1 on a
daily
On 12/07/2023 04:34, Kampanakis, Panos wrote:
Thanks Dennis. Your answers make sense.
Digging a little deeper on the benefit of compressing (a la Abridged Certs
draft) the leaf cert or not. Definitely this draft improves vs plain
certificate compression, but I am trying to see if it is worth
On Wednesday, 12 July 2023 06:02:09 CEST, Kampanakis, Panos wrote:
Hi Dennis,
One more topic for general discussion.
The abridged certs draft requires a server who participates and
fetches dictionaries in order to make client connections faster.
As Bas has pointed out before, this paradigm di
On 12/07/2023 11:01, Ilari Liusvaara wrote:
On Tue, Jul 11, 2023 at 09:37:19PM +0100, Dennis Jackson wrote:
TLS Certificate Compression influences the transcript for the decompressing
party, as the output is the Certificate message which is used in the
transcript.
RFC 8879 does not alter how t
On Tue, Jul 11, 2023 at 09:37:19PM +0100, Dennis Jackson wrote:
> Hi Ilari,
>
> On 10/07/2023 20:19, Ilari Liusvaara wrote:
> > What does "Note that the connection will fail regardless even if this
> > step is not taken as neither certificate validation nor transcript
> > validation can succeed."
Hi Dennis,
One more topic for general discussion.
The abridged certs draft requires a server who participates and fetches
dictionaries in order to make client connections faster. As Bas has pointed out
before, this paradigm did not work well with OSCP staples in the past. Servers
did not chose
ially change often?
-Original Message-
From: TLS On Behalf Of Kampanakis, Panos
Sent: Tuesday, July 11, 2023 11:34 PM
To: Dennis Jackson ; Dennis Jackson
; TLS List
Subject: RE: [EXTERNAL][TLS] Abridged Certificate Compression
CAUTION: This email originated from outside of the organizatio
ssage-
From: Dennis Jackson
Sent: Monday, July 10, 2023 7:23 AM
To: Kampanakis, Panos ; Dennis Jackson
; TLS List
Subject: RE: [EXTERNAL][TLS] Abridged Certificate Compression
CAUTION: This email originated from outside of the organization. Do not click
links or open attachments unless you can co
On Tue, Jul 11, 2023 at 2:09 PM Dennis Jackson
wrote:
> On 11/07/2023 21:17, Eric Rescorla wrote:
>
> I wouldn't want to 'permanently' encode the root programs, CT
> trusted log lists or end entity compressed extensions for example.
>
>
> Arguably it will be necessary to encode the database in th
On 11/07/2023 21:17, Eric Rescorla wrote:
I wouldn't want to 'permanently' encode the root programs, CT
trusted log lists or end entity compressed extensions for example.
Arguably it will be necessary to encode the database in the final RFC.
Otherwise, you have what is effectively a normative
Hi Ilari,
On 10/07/2023 20:19, Ilari Liusvaara wrote:
What does "Note that the connection will fail regardless even if this
step is not taken as neither certificate validation nor transcript
validation can succeed." mean? TLS certificate compression does not
do anything special with transcript,
On Tue, Jul 11, 2023 at 12:45 PM Dennis Jackson wrote:
> On 11/07/2023 15:48, Thom Wiggers wrote:
>
> > I enjoyed reading this draft. I think it is well-written. Aside from
> > some to-be-figured-out details that have already been pointed out, it
> > seems very practical, which is rather nice.
>
On 11/07/2023 15:48, Thom Wiggers wrote:
I enjoyed reading this draft. I think it is well-written. Aside from
some to-be-figured-out details that have already been pointed out, it
seems very practical, which is rather nice.
Thanks!
The one thing that makes me frown a bit is the intended vers
On 11/07/2023 01:00, Eric Rescorla wrote:
My sense is that we would be better off getting the data from CCADB,
as CAs will have a clear incentive to populate it, as their customers
will get better performance.
However, I think this is a question the WG is well suited to resolve
and that we c
Hi Dennis,
I enjoyed reading this draft. I think it is well-written. Aside from some
to-be-figured-out details that have already been pointed out, it seems very
practical, which is rather nice.
The one thing that makes me frown a bit is the intended versioning scheme.
I don't think consuming iden
On Mon, Jul 10, 2023 at 10:54 AM Dennis Jackson
wrote:
>
> On 07/07/2023 21:28, Eric Rescorla wrote:
>
> S 3.2.1
>> How much value are you getting from the CT logs? It seems like
>> additional complexity. I agree with your comment about having
>> this submitted to CCADB.
>>
>> It seemed the faire
On Thu, Jul 06, 2023 at 11:18:01PM +0100, Dennis Jackson wrote:
> Hi all,
>
> I've submitted the draft below that describes a new TLS certificate
> compression scheme that I'm calling 'Abridged Certs' for now. The aim is to
> deliver excellent compression for existing classical certificate chains
On 07/07/2023 21:28, Eric Rescorla wrote:
S 3.2.1
How much value are you getting from the CT logs? It seems like
additional complexity. I agree with your comment about having
this submitted to CCADB.
It seemed the fairest repeatable way to check whether a CA was
offer
com/dennisjackson/e1dccfef104cabc1e4151c47338bc9b2
[MTC]
https://davidben.github.io/merkle-tree-certs/draft-davidben-tls-merkle-tree-certs.html
-Original Message-
From: TLS On Behalf Of Dennis Jackson
Sent: Thursday, July 6, 2023 6:18 PM
To: TLS List
Subject: [EXTERNAL] [TLS] Abridged Certif
Is it worth the compression/decompression effort?
Rgs,
Panos
[1]
https://github.com/csosto-pk/tls-suppress-intermediates/issues/17#issue-1671378265
-Original Message-
From: TLS On Behalf Of Dennis Jackson
Sent: Thursday, July 6, 2023 6:18 PM
To: TLS List
Subject: [EXTERNAL] [TLS] Abrid
On Fri, Jul 7, 2023 at 1:21 PM Dennis Jackson
wrote:
> Thank you for the comments. I'll fix most of them - responses inline for
> the rest:
>
> On 07/07/2023 17:38, Eric Rescorla wrote:
>
> S 3.1.2.
>
>7. Order the list by the date each certificate was included in the
>CCADB, breakin
> I don't follow your comment about the handling of extensions, the code
doing the compression and decompression isn't aware of what an extension
is or handling them specially, its just swapping strings. In order to
compress the larger strings which issuers add to end entity certificates
So, yo
Thank you for the comments. I'll fix most of them - responses inline for
the rest:
On 07/07/2023 17:38, Eric Rescorla wrote:
S 3.1.2.
7. Order the list by the date each certificate was included in the
CCADB, breaking ties with the lexicographic ordering of the
SHA256 certific
On 07/07/2023 17:42, Salz, Rich wrote:
I would love to get feedback from the working group on whether the draft is
worth developing further.
I read your document [1] and found it very interesting.
Thanks Rich!
I found the handling of extensions complicated, although I admit to reading
tha
> I would love to get feedback from the working group on whether the draft
is worth developing further.
I read your document [1] and found it very interesting. I found the handling
of extensions complicated, although I admit to reading that part very quickly.
How much simpler would things b
Document: draft-jackson-tls-cert-abridge-00.txt
Hi Dennis,
Thanks for sending this. This seems like great work and
a big improvement. I have a number of comments below,
mostly minor.
S 1.1.
The existing compression schemes used in [TLSCertCompress] have been
shown to deliver a substantial
Hi all,
I've submitted the draft below that describes a new TLS certificate
compression scheme that I'm calling 'Abridged Certs' for now. The aim is
to deliver excellent compression for existing classical certificate
chains and smooth the transition to PQ certificate chains by eliminating
the
45 matches
Mail list logo
