Re: [Acme] Revisiting Proactive Issuance & new-order CSR

On 11/09/2017 02:18 PM, Richard Barnes wrote: > Since people don't seem happy about either of these alternatives > (identifiers+CSR because of legacy issues; CSR+CSR because of > fragility), here's one last attempt at a different approach: > Draft PR: https://github.com/ietf-wg-acme/acme/pull/350

Re: [Acme] Revisiting Proactive Issuance & new-order CSR

2017 15:03 To: Richard Barnes <r...@ipv.sx> Cc: Ilari Liusvaara <ilariliusva...@welho.com>; Brad Warren <b...@eff.org>; Hugo Landau <hlan...@devever.net>; IETF ACME <acme@ietf.org> Subject: Re: [Acme] Revisiting Proactive Issuance & new-order CSR Since pe

Re: [Acme] Revisiting Proactive Issuance & new-order CSR

On Fri, Nov 10, 2017 at 09:03:03AM -0500, Daniel McCarney wrote: > > > > Since people don't seem happy about either of these alternatives > > (identifiers+CSR because of legacy issues; CSR+CSR because of fragility), > > here's one last attempt at a different approach: > > > I think this is a

Re: [Acme] Revisiting Proactive Issuance & new-order CSR

> > Since people don't seem happy about either of these alternatives > (identifiers+CSR because of legacy issues; CSR+CSR because of fragility), > here's one last attempt at a different approach: I think this is a mis-characterization. What are the legacy issues that can't be handled with

Re: [Acme] Revisiting Proactive Issuance & new-order CSR

Since people don't seem happy about either of these alternatives (identifiers+CSR because of legacy issues; CSR+CSR because of fragility), here's one last attempt at a different approach: 1. Add an error code for new-order, say "authorizationFirst", which means "I only accept orders with all

Re: [Acme] Revisiting Proactive Issuance & new-order CSR

Hi Ilari, I guess if you find any use for the key at all depends on if authorizations > are order-scoped or account-scoped. See this follow-up thread[0] - it seems like "scope" on orders is unnecessary & confusing. I vote it be removed and Richard Barnes seems to be supportive of that. There

Re: [Acme] Revisiting Proactive Issuance & new-order CSR

On Thu, Nov 02, 2017 at 10:29:58AM -0400, Daniel McCarney wrote: > > I understand that these corner cases aren't a super convincing line of > argument, but I also don't think a slight preference for double CSR > strictly because it allows delivering a public key rejection error slightly >

Re: [Acme] Revisiting Proactive Issuance & new-order CSR

On Wed, Nov 1, 2017 at 7:10 PM, Richard Barnes wrote: > > > On Wed, Nov 1, 2017 at 6:12 PM, Brad Warren wrote: > >> As a client developer, I slightly prefer submitting the CSR twice. In >> addition to making the request logic a bit simpler, it causes the client to >>

Re: [Acme] Revisiting Proactive Issuance & new-order CSR

> > - There's not that much time between new-order and finalize (is there?), > so it doesn't seem tremendously likely that there will be a change in > security posture [ citation needed ] A. Do all the checks on the first shot, at the cost of possibly doing a > revocation later Is this the

Re: [Acme] Revisiting Proactive Issuance & new-order CSR

On Thu, Nov 2, 2017 at 9:51 AM, Daniel McCarney wrote: > This was mentioned in another thread on this topic, but to provide a >> concrete example of where this might be useful, Let's Encrypt currently >> refuses to issue for CSRs containing a weak key. By initially

Re: [Acme] Revisiting Proactive Issuance & new-order CSR

> > This was mentioned in another thread on this topic, but to provide a > concrete example of where this might be useful, Let's Encrypt currently > refuses to issue for CSRs containing a weak key. By initially providing the > CSR, the server is able to immediately reject the request rather than >

Re: [Acme] Revisiting Proactive Issuance & new-order CSR

On Wed, Nov 1, 2017 at 6:12 PM, Brad Warren wrote: > As a client developer, I slightly prefer submitting the CSR twice. In > addition to making the request logic a bit simpler, it causes the client to > provide more information about the cert it would like to obtain earlier in >

Re: [Acme] Revisiting Proactive Issuance & new-order CSR

As a client developer, I slightly prefer submitting the CSR twice. In addition to making the request logic a bit simpler, it causes the client to provide more information about the cert it would like to obtain earlier in the process. This was mentioned in another thread on this topic, but to

Re: [Acme] Revisiting Proactive Issuance & new-order CSR

Some of us have been discussing this off-list, and where we got to was basically as follows: 1. We should have some sort of explicit "finalize" request that triggers issuance of a certificate 2. The finalize request will need to have the CSR attached to it, so that the CA doesn't have to cache

Re: [Acme] Revisiting Proactive Issuance & new-order CSR

> > Wouldn't it be a lot better not to do the validations at all if you can > tell at new-order time that you're not going to be willing to issue? Yes, that would be better in this one capacity. However I don't think it comes close to justify the scaling issues associated with accepting the CSR

Re: [Acme] Revisiting Proactive Issuance & new-order CSR

> Example: Suppose that CAA-PKP got added (restrict issuance on SPKI key). Implementing that without knowing the public key at validation time is annoying. Can you expand on "annoying"? It seems completely possible to reject the order finalization message based on a CAA-PKP property. In-fact, we

Re: [Acme] Revisiting Proactive Issuance & new-order CSR

Hi Hugo, Providing the CSR up-front allows the CA to predicate order processing on > aspects of that CSR, both with regard to the present protocol and any > future extensions, both now and in the future in ways that we can and > cannot foresee. I don't think it's appropriate to defer giving

Re: [Acme] Revisiting Proactive Issuance & new-order CSR

On Tue, Oct 24, 2017 at 05:17:32PM +0300, Ilari Liusvaara wrote: > On Tue, Oct 24, 2017 at 02:45:01PM +0100, Hugo Landau wrote: > > > > The ACME protocol should permit CAs to implement policy as far as is > > reasonably practicable with regard to the workflows around which the > > protocol is

Re: [Acme] Revisiting Proactive Issuance & new-order CSR

On Tue, Oct 24, 2017 at 02:45:01PM +0100, Hugo Landau wrote: > > The ACME protocol should permit CAs to implement policy as far as is > reasonably practicable with regard to the workflows around which the > protocol is organised. Providing the CSR up-front allows the CA to > predicate order

Re: [Acme] Revisiting Proactive Issuance & new-order CSR

My thoughts: - Requiring an explicit action against the order after the fulfilment of authorizations to cause issuance seems fine to me. - I think moving the submission of the CSR to the end of this process is a mistake. The ACME protocol should permit CAs to implement policy as far as is

Re: [Acme] Revisiting Proactive Issuance & new-order CSR

Hi again, Richard: Do you have any subsequent thoughts now that Roland and myself have given feedback on your proposed changes and why we still prefer the suggestions I made initially? Andrew's original support of proactive issuance was the most constructive vote for why that behaviour was

Re: [Acme] Revisiting Proactive Issuance & new-order CSR

FWIW, I previously expressed support for proactive issuance because I thought it would lay the groundwork for a better renewal process, especially for short-lived certificates. However, this idea never gained traction and the other necessary bits weren't added. Instead, STAR seems to be

Re: [Acme] Revisiting Proactive Issuance & new-order CSR

I've proposed a first cut at implementing the changes I described in my original post as an ACME PR https://github.com/ietf-wg-acme/acme/pull/342 On Fri, Sep 22, 2017 at 7:19 PM, Roland Bracewell Shoemaker < rol...@letsencrypt.org> wrote: > Broad points: > > I understand that this group has

Re: [Acme] Revisiting Proactive Issuance & new-order CSR

RE: #1 - this does help, but will require changing the spec to clarify. The current wording does not support this behaviour and cleary indicates the server MUST issue for any order that has been satisfied. RE: #2 - a CA relying on the new-authz flow to avoid the cost of accepting a CSR up front

Re: [Acme] Revisiting Proactive Issuance & new-order CSR

On Fri, Sep 22, 2017 at 4:40 AM, Richard Barnes wrote: > Daniel noted that there might be some issues with GET idempotency here, but > I don't think this actually makes GET non-idempotent. It's still idempotent, because doing the GET twice has the same effect as doing it once. You

Re: [Acme] Revisiting Proactive Issuance & new-order CSR

If the suggestion is fine with Daniel, I think editorial clarification and a new error code can be added without disrupting the cycle and I am strongly in favor of that. ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Revisiting Proactive Issuance & new-order CSR

I talked a bit with Daniel about this off-list. Here's a summary of where we got to: 1. In the current "new-order" flow, the server doesn't *really* have to be proactive -- instead of updating an order object when an authz changes state, it can wait to update/issue until the client polls for the

Re: [Acme] Revisiting Proactive Issuance & new-order CSR

Hey Daniel, Thanks for the input. I can see why you might be feeling some pain here, but I'm not sure the proposed solution is quite right. Note that ACME already has the "new-authorization" flow, which does pretty much exactly what you're proposing. The only difference is that instead of

Re: [Acme] Revisiting Proactive Issuance & new-order CSR

On 09/19/2017 01:34 PM, Logan Widick wrote: > Would it be possible to extract the key and identifiers from the CSR, > add the key to the database if it doesn't already exist, find or > create the authorizations for the identifiers, not store the CSR, and > then assemble the certificate from the

Re: [Acme] Revisiting Proactive Issuance & new-order CSR

On Tue, Sep 19, 2017 at 03:34:50PM -0500, Logan Widick wrote: > Would it be possible to extract the key and identifiers from the CSR, add > the key to the database if it doesn't already exist, find or create the > authorizations for the identifiers, not store the CSR, and then assemble > the

Re: [Acme] Revisiting Proactive Issuance & new-order CSR

Would it be possible to extract the key and identifiers from the CSR, add the key to the database if it doesn't already exist, find or create the authorizations for the identifiers, not store the CSR, and then assemble the certificate from the (valid) authorizations and key later? Alternatively,

[Acme] Revisiting Proactive Issuance & new-order CSR

Hi folks, Just over a year ago in a thread titled "Proactive vs On-Finalization Certificate Issuance"[0] we reached the consensus on the question of whether to issue a certificate "on-finalization" or "proactively" with the conclusion to standardize on proactive issuance. Implementation