Re: [Acme] Practical concerns of draft-ietf-acme-ari

Rob Stradling wrote: >> > Ah, so a CA's Subject DN does have to be globally unique then! So >> if >> >> No, it does not. It does not even need to be unique within the CA. >> And if you think about it, if someone wants a new certificate before >> the old one expires, one

Re: [Acme] Practical concerns of draft-ietf-acme-ari

bject: Re: [Acme] Practical concerns of draft-ietf-acme-ari CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Rob Stradling wrote: >> > Is it required that a

Re: [Acme] Practical concerns of draft-ietf-acme-ari

Rob Stradling wrote: >> > Is it required that a CA's Subject DN must be globally unique? No. >> >> RFC 5280, section 4.1.2.2: "It [the serial number] MUST be unique for >> each certificate issued by a given CA (i.e., the issuer name and >> serial number identify a unique cer

Re: [Acme] Practical concerns of draft-ietf-acme-ari

section 4.1.2.2. From: Acme on behalf of Ilari Liusvaara Sent: 26 July 2023 20:20 To: acme@ietf.org Subject: Re: [Acme] Practical concerns of draft-ietf-acme-ari CAUTION: This email originated from outside of the organization. Do not click links or open attachme

Re: [Acme] Practical concerns of draft-ietf-acme-ari

On Wed, Jul 26, 2023 at 03:56:12PM +, Rob Stradling wrote: > Is it required that a CA's Subject DN must be globally unique? No. RFC 5280, section 4.1.2.2: "It [the serial number] MUST be unique for each certificate issued by a given CA (i.e., the issuer name and serial number identify a uni

Re: [Acme] Practical concerns of draft-ietf-acme-ari

to reinvent the (CertID) wheel? [1] https://mailarchive.ietf.org/arch/msg/acme/QHNxo0L89XS6Y9VNF1oD6X907UY/ From: Q Misell Sent: 26 July 2023 17:52 To: Rob Stradling Cc: Aaron Gable ; Ilari Liusvaara ; acme@ietf.org Subject: Re: [Acme] Practical concerns of draft-ie

Re: [Acme] Practical concerns of draft-ietf-acme-ari

l we need to be concerned with here. From: Corey Bonnell Sent: Wednesday, July 26, 2023 18:04 To: Rob Stradling; Aaron Gable; Ilari Liusvaara Cc: acme@ietf.org Subject: RE: [Acme] Practical concerns of draft-ietf-acme-ari * However, we're defining ARI in the context of IETF, not CABForum; a

Re: [Acme] Practical concerns of draft-ietf-acme-ari

ments. Thanks, Corey From: Acme On Behalf Of Rob Stradling Sent: Wednesday, July 26, 2023 11:56 AM To: Aaron Gable ; Ilari Liusvaara Cc: acme@ietf.org Subject: Re: [Acme] Practical concerns of draft-ietf-acme-ari > > For reasons I outlined in > > https://mailarchive.ietf.

Re: [Acme] Practical concerns of draft-ietf-acme-ari

t; > [1] psql -h crt.sh -p 5432 -U guest -d certwatch -c "select count(*), > min(name), max(name) from ca group by public_key having count(*) > 1 and > min(name) != max(name) order by count(*);" > > -- > *From:* Acme on behalf of Aaron Gable

Re: [Acme] Practical concerns of draft-ietf-acme-ari

ARI client would not be able to locate a copy of the issuer certificate? [1] psql -h crt.sh -p 5432 -U guest -d certwatch -c "select count(*), min(name), max(name) from ca group by public_key having count(*) > 1 and min(name) != max(name) order by count(*);" __

Re: [Acme] Practical concerns of draft-ietf-acme-ari

On Fri, Jul 21, 2023 at 2:00 PM Matthew Holt wrote: > I simply do not think there is a way to offer a wider renewal window than > the full lifetime of the certificate by offering a narrower renewal window. > I know that sounds silly, but since "backoff and retry" is the One Way to > reliably gett

Re: [Acme] Practical concerns of draft-ietf-acme-ari

Hi all, Thank you for the constructive discussion -- I'm glad others are seeing this. 😅 Aaron, thank you especially for the thoughtful reply and engaging in the discussion. Replying inline: I'm confused by the statement that "with ARI the window is reduced to just > a few minutes, hours, or day

Re: [Acme] Practical concerns of draft-ietf-acme-ari

> > This is an interesting point. ARI was first conceived > > as a way to > > improve business continuity across mass revocation events, and grew from > > there. The idea that 10-day certs might be a reality, and that revocation > > would

Re: [Acme] Practical concerns of draft-ietf-acme-ari

> Maybe it would be best to state "Hey, the CA generated its own Issuer Key IDs, it can be expected to recognize them too", and make the request simply IssuerKeyID + Serial, in some simple concatenate+base64url format. Issuer Key ID plus serial makes a lot of sense to me, and I think should be the

Re: [Acme] Practical concerns of draft-ietf-acme-ari

On Thu, Jul 20, 2023 at 08:38:23AM -0700, Aaron Gable wrote: > On Wed, Jul 19, 2023 at 11:16 PM Ilari Liusvaara > wrote: > > > E.g., the client might be deterministically generating renewal time > > from window (the client I wrote does this). This works nicely if the > > renewal window does not s

Re: [Acme] Practical concerns of draft-ietf-acme-ari

On Wed, Jul 19, 2023 at 11:16 PM Ilari Liusvaara wrote: > E.g., the client might be deterministically generating renewal time > from window (the client I wrote does this). This works nicely if the > renewal window does not shift around. However, it becomes heavily > biased toward beginning of the

Re: [Acme] Practical concerns of draft-ietf-acme-ari

On Thu, Jul 20, 2023 at 06:31:08AM -0400, Deb Cooley wrote: > > Issuer key hash: Is this not in the Authority Key ID extension? Or is > this extension not used? > > If these things are not the same, my recommendation would be to use > Authority Key ID value as a way to ID the issuing CA. AFAIC

Re: [Acme] Practical concerns of draft-ietf-acme-ari

> Issuer key hash: Is this not in the Authority Key ID extension? Or is this extension not used? If I'm understanding it correctly the AKI is what's needed. -- Any statements contained in this email are personal to the author and are not necessarily the statements of

Re: [Acme] Practical concerns of draft-ietf-acme-ari

bject" '. From: Acme on behalf of Aaron Gable Sent: 19 July 2023 23:05 To: Tim Hollebeek Cc: Matthew Holt ; acme@ietf.org Subject: Re: [Acme] Practical concerns of draft-ietf-acme-ari CAUTION: This email originated from outside of the organization

Re: [Acme] Practical concerns of draft-ietf-acme-ari

Only one small point: snip.. > 4) Crafting the URL is convoluted. As Peter Cooper described it, "The core > > issue is that the URL you need to construct is based on an OCSP structure > > identifying the certificate, which requires taking one's existing > > certificate and parsin

Re: [Acme] Practical concerns of draft-ietf-acme-ari

On Wed, Jul 19, 2023 at 03:05:52PM -0700, Aaron Gable wrote: > Hi Matt, > > On Fri, Jun 23, 2023 at 9:21 AM Matthew Holt wrote: > > > But when a renewal window does change, what does that mean? Well, > > something is wrong. Either the certificate is being revoked, or the CA > > anticipates downt

Re: [Acme] Practical concerns of draft-ietf-acme-ari

Hi Matt, Agreed with Tim, receiving practical feedback from implementers of the draft standard is very useful. I'll put my thoughts, comments, and questions in-line. On Fri, Jun 23, 2023 at 9:21 AM Matthew Holt wrote: > > With respect to ARI, ACME servers and clients have conflicts of interest.

Re: [Acme] Practical concerns of draft-ietf-acme-ari

Ilari, > On Jul 6, 2023, at 5:35 AM, Ilari Liusvaara wrote: >> On Fri, Jun 23, 2023 at 1:44 PM Michael Sweet > 40msweet@dmarc.ietf.org> wrote: >> >>> In a somewhat-related situation for printing, we have an event >>> notification interface (RFC 3996) where the printer can report back a time

Re: [Acme] Practical concerns of draft-ietf-acme-ari

On Mon, Jul 03, 2023 at 07:32:15AM -0400, Deb Cooley wrote: > We are happy to have more participation in the acme working group. The > IETF is based on development of standards by rough consensus. If you are > willing to roll up your sleeves and participate (by reviewing/commenting on > the draft

Re: [Acme] Practical concerns of draft-ietf-acme-ari

Matthew Holt Sent: Friday, June 23, 2023 12:21 PM To: acme@ietf.org Subject: [Acme] Practical concerns of draft-ietf-acme-ari Hi all, I don't normally participate in these mailing lists, and last time I did I feel like the lack of discussion was discouraging, as what little discussion did

Re: [Acme] Practical concerns of draft-ietf-acme-ari

We are happy to have more participation in the acme working group. The IETF is based on development of standards by rough consensus. If you are willing to roll up your sleeves and participate (by reviewing/commenting on the drafts, and contributing to discussion) we are happy to have you. It is

Re: [Acme] Practical concerns of draft-ietf-acme-ari

FWIW, I agree with Matthew's comments and conclusions. In a somewhat-related situation for printing, we have an event notification interface (RFC 3996) where the printer can report back a time interval (in seconds) when the client should re-contact the printer to get more events. This is flexi

[Acme] Practical concerns of draft-ietf-acme-ari

Hi all, I don't normally participate in these mailing lists, and last time I did I feel like the lack of discussion was discouraging, as what little discussion did occur wasn't taken seriously and was laced with complacency. Just stating up front that I don't have much hope for this message to be