Re: [Acme] ACME -06: HTTPS authorization

On Tue, May 30, 2017 at 11:32 AM, Yaron Sheffer wrote: > I'm not sure I understand why the section that describes HTTP validation > so specifically forbids using HTTPS. > This was because of the default-vhost attack. https://ietf-wg-acme.github.io/acme/#rfc.section.11.2 Given that we don't rea

Re: [Acme] ACME -06: revocation

On Tue, May 30, 2017 at 11:42 AM, Yaron Sheffer wrote: > When we allow the issued certificate to revoke itself, this has major > implications, in particular for delegated certificates. But even for > regular certs, it is the account's private key that's more secure (it is > managed by the securit

Re: [Acme] ACME -06: HTTPS authorization

nd the client doesn't know what to expect. So if my port 80 > is firewalled, I'm still not in good shape. > > Thanks, > > Yaron > > On 30/05/17 18:38, Richard Barnes wrote: > > > > On Tue, May 30, 2017 at 11:32 AM, Yaron Sheffer > wrote: > >&g

Re: [Acme] ACME -06 - notBefore/notAfter

""" The server MUST return an error if it cannot fulfill the request as specified, and MUST NOT issue a certificate with contents other than those requested. """ https://ietf-wg-acme.github.io/acme/#rfc.section.7.4 On Tue, May 30, 2017 at 11:51 AM, Yaron Sheffer wrote: > In the "Applying for C

Re: [Acme] Call for adoption STAR (short-term automatically-renewed) certificates

I don't think we should adopt this until the Recurring Orders stuff has been split out. I'm still not convinced of the need for the other interface here, much less the need to do it in this WG. On Fri, Jun 9, 2017 at 4:47 PM, Russ Housley wrote: > > > On 08/06/2017, 20:56, "Acme on behalf of Ru

Re: [Acme] Consensus -- CAA draft to WGLC?

Couple of minor comments: - It might be useful to specify validation methods even without ACME. The CAB Forum is working on whittling down the space of available mechanisms to an enumerated list, and while these might not completely overlap with ACME methods, it will be a small enough list to enu

[Acme] v2

(Everyone get your bike shed paint out) In talking with a few folks around the community, I've heard people refer to the IETF version of ACME as "v2", where implicitly "v1" is the initial version deployed by Let's Encrypt and its clients right now. How would people feel about reflecting this

Re: [Acme] Bypassing the intended purpose of requiring 128 bits of entropy for the http-01 token

Hey Zach, Thanks for submitting a PR on this. I just filed a review with some specific comments: https://github.com/ietf-wg-acme/acme/pull/312#pullrequestreview-43769669 This change seems fine to me, especially if we make the change I propose in there to digest the whole key authorization inste

Re: [Acme] Bypassing the intended purpose of requiring 128 bits of entropy for the http-01 token

ut it seems like the regularity it provides will help simplify analysis and make implementation easier, so I'm inclined to do it. Thanks, --Richard On Tue, Jun 13, 2017 at 1:23 PM, Ilari Liusvaara wrote: > On Tue, Jun 13, 2017 at 11:59:21AM -0400, Richard Barnes wrote: > >

Re: [Acme] v2

the LE proprietary protocol any >> special status other than by acknowledging provenance. >> >> This is the IETF version of ACME, and as such it needs no version >> qualification. I doubt that there will be any confusion from this >> being deployed alongside the proprietary

Re: [Acme] Rolling keys and pending validations

This seems sensible; rolling keys shouldn't invalidate things in transit any more than changing your Gmail password should delete your drafts folder. I would have a little bit of a hard time calling this "purely editorial", since it specifies server behavior. But it seems like you're just codifyi

Re: [Acme] v2

OK, I'm not hearing any real enthusiasm for this idea (except from Daniel). So I'm going to close the PR. On Wed, Jun 14, 2017 at 6:39 PM, Richard Barnes wrote: > For some context: https://letsencrypt.org/2017/06/14/acme-v2-api.html > > To be clear about my opinion

Re: [Acme] Fw: acme-06: Yet more editorial issues plus one real protocol thing

Thanks for the PRs. I merged them. I don't think that PUT is appropriate for really any requests that ACME uses. Quoth RFC 7231: """ The PUT method requests that the state of the target resource be created or replaced with the state defined by the representation enclosed in the request

Re: [Acme] Bypassing the intended purpose of requiring 128 bits of entropy for the http-01 token

I'm going to retract my earlier proposal that we address this issue. While the idea of better aligning the challenges is aesthetically appealing, there seems to be agreement that there's not a major security issue here. And the spec has already passed WGLC with the existing set of challenges. So

Re: [Acme] Rolling keys and pending validations

gt; I would expect that latter semantics would be hairier for server > implementors, because they’d need to keep multiple credentials alive and > associated with the account for the maximum lifetime of any extant tokens. > > > On 6/19/17, 2:44 PM, "Ilari Liusvaara" wrot

Re: [Acme] Automated procedure for DNS challenge records?

There isn't anything in the current spec(s), and it doesn't really seem in scope for this work. That is, I don't think it's worthwhile to make a one-off solution for updating the DNS with records for ACME, vs. improving the state of DNS management in general. That said, you can certainly integrat

Re: [Acme] Consensus -- CAA draft to WGLC?

There's no listing going on here, since there's no registry for the values. CABF could put tokens in their documents if they like. On Tue, Jun 13, 2017 at 1:33 PM, Salz, Rich wrote: > > The two last ones are editorial, but the first about enumerating all BR > > methods isn't (since it needs new

Re: [Acme] Consensus -- CAA draft to WGLC?

https://github.com/ietf-wg-acme/acme-caa/pull/2 On Wed, Jul 5, 2017 at 11:47 AM, Salz, Rich wrote: > > There's no listing going on here, since there's no registry for the > values. CABF could put tokens in their documents if they like. > > Okay, please propose wording (or did you? Sorry if so)

Re: [Acme] Consensus -- CAA draft to WGLC?

Just for context here: I think the original operating model for CAA was that the CA would tell the customer what values to put in there in order to authorize issuance. So it was safe to use arbitrary values because it was basically a closed loop CA -> Customer -> CAA -> CA. Nonetheless, I sympath

Re: [Acme] Consensus -- CAA draft to WGLC?

t would create the semantic I mention above. That part should probably go into a separate minor update spec, though, not in this spec. --Richard > > Thanks, > > Yaron > > > On 06/07/17 00:17, Richard Barnes wrote: > >> Just for context here: I think the original o

Re: [Acme] Consensus -- CAA draft to WGLC?

On Thu, Jul 6, 2017 at 11:57 AM, Salz, Rich wrote: > So let's see. Can we live with this? > > Create a spec-required registry for validation method names. > I share Hugo's concern about divergence here. Should we maybe just put these in the ACME challenge types registry? It is already Spec-Re

Re: [Acme] Rolling keys and pending validations

On Wed, Jul 5, 2017 at 6:03 PM, Jacob Hoffman-Andrews wrote: > On 06/30/2017 09:54 AM, Dunning, John wrote: > > Based on your description below, I think door A makes more sense to me. > My paraphrase of it is that key authorizations get bound at creation time, > and thus get “grandfathered” in af

Re: [Acme] Consensus -- CAA draft to WGLC?

On Fri, Jul 7, 2017 at 9:33 AM, Hugo Landau wrote: > >On Thu, Jul 6, 2017 at 11:57 AM, Salz, Rich <[1]rs...@akamai.com> > wrote: > > > > So let's see. Can we live with this? > > > > Create a spec-required registry for validation method names. > > > >I share Hugo's concern about

Re: [Acme] Rolling keys and pending validations

On Fri, Jul 7, 2017 at 2:06 PM, Jacob Hoffman-Andrews wrote: > On 07/07/2017 06:42 AM, Richard Barnes wrote: > > C) Instead of using *key* authorizations, use *account* > > authorizations. Instead of the object being of "token.H(key)", make > > it "tok

Re: [Acme] Fwd: I-D Action: draft-ietf-acme-acme-07.txt

etf-acme-acme-07.txt >> To: i-d-annou...@ietf.org >> Cc: acme@ietf.org >> >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Automated Certificate Management >> Environment o

Re: [Acme] Minutes from IEtf 99

changed pictures or not J >> >> >> >> -- >> >> Senior Architect, Akamai Technologies >> >> Member, OpenSSL Dev Team >> >> IM: richs...@jabber.at Twitter: RichSalz >> >> >> >> *From:* Richard Barnes [mailto:r..

Re: [Acme] Issuing a cert with a superset of requested identifiers

Yeah, I agree that the intent here is for the CSR to match the certificate in all material respects. This does require the client to know what it wants, so it knows what to put in the CSR. Do you have a use case where that's not the case? On Thu, Aug 17, 2017 at 9:54 AM, Salz, Rich wrote: > >

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 autho

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

ssue now" request (vs. the GET poll). --Richard On Wed, Sep 20, 2017 at 1:22 PM, Richard Barnes wrote: > 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

Re: [Acme] AD review of draft-ietf-acme-acme

Hi Kathleen, Thanks for the review. Some responses inline. I've started a PR to respond to these comments here: https://github.com/ietf-wg-acme/acme/pull/345 I agree with Daniel that we should hold off on IETF LC until we've addressed the issues around proactive issuance / caching of CSRs. Th

[Acme] Another round of ACME PRs

[[ An ACME editor emerges from hibernation... ]] Hey all, I've spent a few minutes today processing pull requests. I've merged several that I didn't think merited WG discussion, but I'm reflecting them here for visibility (including a couple that Jacob approved as well): TYPOS: #327 - Remove "t

Re: [Acme] Consensus -- CAA draft to WGLC?

Picking this up after a long gap... On Sat, Jul 8, 2017 at 4:44 AM, Hugo Landau wrote: > > > https://github.com/ietf-wg-acme/acme/pull/332 > Alright, if the ACME spec wants to genericise its validation methods > registry, I'm okay with the validation-methods change as-is. > > Questions: > > 1. S

Re: [Acme] Consensus -- CAA draft to WGLC?

On Thu, Oct 19, 2017 at 2:21 PM, Hugo Landau wrote: > > > With regard to ACME-CAA PR#2: Is a "vendor" validation method, rather > > > than a prefix, really that useful? > > > > > > > It seems like something we're likely to need at some point, given that > > there's still some diversity in validat

Re: [Acme] Allowable mailto contacts

Good catch, Logan. Suggested fix: https://github.com/ietf-wg-acme/acme/pull/346 On Thu, Oct 19, 2017 at 4:52 PM, Logan Widick wrote: > I was not involved with RFC 6068 in any way. However, from my > understanding of the RFC, that subset ("mailto:us...@example.com";) might > (roughly) look some

Re: [Acme] 'new-order' Implementation in node.js

On Wed, Oct 25, 2017 at 4:40 AM, Prasheel Soni wrote: > Hi Devs, > > I recently tried to implement the 'new-order' process in Node.JS and came > across several confusions which are required to be cleared before we can > move on: > Hi Prasheel, In case it's helpful, here's my node.js implementat

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

On Mon, Oct 30, 2017 at 10:15 AM, Daniel McCarney wrote: > > 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 t

Re: [Acme] I-D Action: draft-ietf-acme-acme-08.txt

Certificate Management > Environment WG of the IETF. > > Title : Automatic Certificate Management Environment > (ACME) > Authors : Richard Barnes > Jacob Hoffman-Andrews > James Kasten >

Re: [Acme] AD review of draft-ietf-acme-acme

ng came up, sorry for the delay and this was a > good reminder. > > On Thu, Oct 19, 2017 at 12:45 PM, Richard Barnes wrote: > > Hi Kathleen, > > > > Thanks for the review. Some responses inline. I've started a PR to > respond > > to these comments here: &

Re: [Acme] AD review of draft-ietf-acme-acme

On Mon, Oct 30, 2017 at 9:37 PM, Kathleen Moriarty < kathleen.moriarty.i...@gmail.com> wrote: > Hi Richard, > > On Mon, Oct 30, 2017 at 6:27 PM, Richard Barnes wrote: > > > > > > On Mon, Oct 30, 2017 at 5:00 PM, Kathleen Moriarty > > wrote: > >> &

Re: [Acme] AD review of draft-ietf-acme-acme

On Tue, Oct 31, 2017 at 4:39 PM, Eric Rescorla wrote: > > > On Tue, Oct 31, 2017 at 12:51 PM, Richard Barnes wrote: > >> >> >> On Mon, Oct 30, 2017 at 9:37 PM, Kathleen Moriarty < >> kathleen.moriarty.i...@gmail.com> wrote: >> >>> Hi

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

CA isn't willing to issue at the time of > finalization. > > There also isn't a CAA-PKP so we're bikeshedding about impact on features > that are both unspecified & unimplemented. > > - Daniel / cpu > > On Mon, Oct 30, 2017 at 3:33 PM, Richard Barnes wrote:

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

ed in the finalize request, we're OK for CA bloat -- the CA can throw away the first CSR after it parses it and produces the authorizations. Or rather, they should keep around a hash of the CSR so that they can verify that the second CSR is the same. Since we should require that. --Ri

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

gt;> the process. 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 immediat

Re: [Acme] Missing rationale for the Authorization "scope" field

I think the intent when we implemented it was to communicate to clients that an authz was only good for a single issuance, so that if a client was doing pre-authorization, they would know that that authorization wouldn't be reused. Given that all issuance now goes through new-order, it's probably

Re: [Acme] AD review of draft-ietf-acme-acme

On Fri, Nov 3, 2017 at 12:59 PM, Kathleen Moriarty < kathleen.moriarty.i...@gmail.com> wrote: > On Tue, Oct 31, 2017 at 3:51 PM, Richard Barnes wrote: > > > > > > On Mon, Oct 30, 2017 at 9:37 PM, Kathleen Moriarty > > wrote: > >> > >> Hi

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

CSR first / CSR last). Thanks, --Richard On Wed, Nov 8, 2017 at 9:05 AM, Daniel McCarney wrote: > 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

Re: [Acme] Returning multiple errors

This sounds pretty inoffensive to me. Want to send a PR? Following Daniel's lead on looking for implementation: Is this something LE would be implementing? On Thu, Nov 16, 2017 at 9:23 AM, Jacob Hoffman-Andrews wrote: > In previous versions of ACME, there was sometimes a need to return > multi

Re: [Acme] Landing PR#342 (proactive issuance with identifier-first)

I think this is fine to land now. It's not my favorite approach, but there's clear consensus. I filed Issue #356 [1] to track the lost functionality here, and how we might want to add it back. https://github.com/ietf-wg-acme/acme/issues/356 On Mon, Nov 27, 2017 at 3:04 PM, Jacob Hoffman-Andrews

Re: [Acme] Landing PR#342 (proactive issuance with identifier-first)

Using my editor's prerogative, I went ahead and merged this PR. On Tue, Nov 28, 2017 at 1:05 PM, Richard Barnes wrote: > I think this is fine to land now. It's not my favorite approach, but > there's clear consensus. I filed Issue #356 [1] to track the lost > functi

Re: [Acme] Landing PR#342 (proactive issuance with identifier-first)

might be able to provide further insight. But like I said, this is not blocking anything for the base spec any more. It's just a possible extension if someone shows up and asks for the feature. --Richard [1] https://sslmate.com/help/api/rest > > - Daniel / cpu > > > On

Re: [Acme] TSV-ART review of draft-ietf-acme-acme-08

Thanks for the review, Martin. I've posted responses in a PR, along with a couple of other minor fixes: https://github.com/ietf-wg-acme/acme/pull/357 On Tue, Nov 28, 2017 at 5:38 AM, Martin Stiemerling wrote: > Hi all, > > I've reviewed this document as part of the transport area review team's

[Acme] Clarifications around external account binding

Hey all, I just posted a PR adding a "meta" field and an error code that allow a CA to enforce external account binding: https://github.com/ietf-wg-acme/acme/pull/359 This is a pretty minor change, but I think it will make some use cases flow better. Please chime in if you think this is a bad i

Re: [Acme] Landing PR#342 (proactive issuance with identifier-first)

On Wed, Nov 29, 2017 at 12:43 PM, Mary Barnes wrote: > My comments below [MB]. > > Regards, > Mary > > On Wed, Nov 29, 2017 at 11:23 AM, Andrew Ayer > wrote: > >> On Tue, 28 Nov 2017 13:28:08 -0500 >> Daniel McCarney wrote: >> >> > > >> > > The canonical example for me here is SSLMate [1], whic

Re: [Acme] Question about the new finalizeURL approach, and the order object format after finalizeURL

I would like to keep it around. Part of the idea of the order and authorization objects is to provide some possibility of accounting for how a certificate was issued. Removing the "csr" would remove some of that transparency. As Jacob points out, CAs are already required to keep around CSRs in a

Re: [Acme] Camel vs. kebab-case

Good observation. I would be OK moving everything to camelCase [1], since it seems like that's a more natural fit for programming language bindings. This also seems like a less disruptive change than some other things we've been doing lately (finalization). At best, it's a string change; at wors

Re: [Acme] new-authz, new-order and examples

On Wed, Dec 6, 2017 at 3:38 PM, Jacob Hoffman-Andrews wrote: > On 12/05/2017 03:07 PM, Sophie Herold wrote: > > Having mentioned new-authz: The definition of new-authz is now a subset > > of new-order. Is there any reason to keep the new-authz resource at all? > > Would there be any difference in

Re: [Acme] I-D Action: draft-ietf-acme-acme-09.txt

the Automated Certificate Management > Environment WG of the IETF. > > Title : Automatic Certificate Management Environment > (ACME) > Authors : Richard Barnes > Jacob Hoffman-Andrews > Daniel McCarney &g

Re: [Acme] 7.1. Resources "typical sequence of requests"

+1 On Fri, Dec 15, 2017 at 10:24 AM, Daniel McCarney wrote: > Hi Sophie, > > I think there are two "mistakes" in this example: > > > Agreed on both mistakes. Thanks for flagging! > > To avoid unnecessary confusion, I suggest that the table could look something >> like this: > > > I like your pr

Re: [Acme] Discussion of draft-ietf-acme-ip

On Wed, Dec 20, 2017 at 4:27 PM, Jacob Hoffman-Andrews wrote: > On 11/16/2017 02:28 PM, Roland Bracewell Shoemaker wrote: > > The point of the draft is to provide a method for validating the control > > of IP addresses in the same way that the ACME draft does for DNS names. > > This allows ACME i

Re: [Acme] Clarify that newAuthz endpoint is optional

Why not a MUST? If you don't implement preauthorization, there's no need for a value. I guess you could provide "null", but ... don't. On Fri, Jan 5, 2018 at 2:33 PM, Daniel McCarney wrote: > Hi Ilari, > > >> This impiles that if pre-authorization is not supported, newAuthz better >> be absent

Re: [Acme] Clarify that newAuthz endpoint is optional

over SHOULD. Updated in 5fcaa6c on my > PR branch. > > - Daniel / cpu > > On Fri, Jan 5, 2018 at 4:24 PM, Richard Barnes wrote: > >> Why not a MUST? If you don't implement preauthorization, there's no need >> for a value. I guess you could provide "null&quo

Re: [Acme] Usage of "unspecified" reason code in CRL / OCSP

Good point. Posted a PR: https://github.com/ietf-wg-acme/acme/pull/385 On Fri, Jan 5, 2018 at 6:03 PM, Jörn Heissler wrote: > Hello, > > https://ietf-wg-acme.github.io/acme/draft-ietf-acme-acme. > html#rfc.section.7.6 > states: > > If this field is not set the server SHOULD use the unspecif

Re: [Acme] Fixing the TLS-SNI challenge type

On Fri, Jan 19, 2018 at 4:38 PM, Ilari Liusvaara wrote: > On Fri, Jan 19, 2018 at 09:51:33AM -0500, Daniel McCarney wrote: > > > > > > I agree this approach will limit compatible TLS servers but luckily > > > HAProxy should be fully compatible. > > > > > > Alas, there's nothing like hitting send

Re: [Acme] ALPN based TLS challenge

+1 This approach is a major improvement from earlier efforts at a TLS-based challenge. It follows normal TLS processing logic much more closely, differing only in the fact that the certificate presented has an extra extension. Minimizing the differences w.r.t. normal behavior seems like a good a

[Acme] "Status" field clarification

Hey all, We had a couple of GitHub issues and mailing list posts expressing confusion about the "status" field in ACME objects. To try to clear all of that up, I've posted a PR that lays out required state transitions and aligns the field descriptions with that description. All the description s

Re: [Acme] Specify which JWS serialization is used

Hey all, I merged #395 last night (thanks, Logan!). While I was reviewing that, I noticed that we need to cover the case where the client sends an encoding that the server doesn't understand. So I've posted a follow-on that adds an error code and requires its usage. LMK if you have any objectio

Re: [Acme] "Status" field clarification

hard On Fri, Mar 2, 2018 at 9:31 AM, Logan Widick wrote: > Are challenge retries still supported? If so, how will retries affect the > state transitions? What state would a server use to indicate that something > had an error but could be retried later? > > Sincerely, > > Loga

Re: [Acme] Optional "Wildcard" authorization field

Daniel: I don't have a strong objection here, but could you elaborate what the client is expected to do differently based on this flag? On Fri, Mar 2, 2018 at 12:22 PM, Daniel McCarney wrote: > Hi folks, > > There is a slight disconnect with the current specification between > identifiers in new

Re: [Acme] Optional "Wildcard" authorization field

This is seeming like a lot of work for a pretty minor use case. I would propose we stick with a simpler solution here. While Sophie's solution does seem more general, in the interest of getting the spec shipped, I would propose we just add the boolean flag and write an extension spec if a more ge

Re: [Acme] Specify which JWS serialization is used

sagree? --Richard > > Logan > > > On Mar 2, 2018 9:47 AM, "Felipe Gasper" wrote: > > Could there be some way of using a header like “Accept” for a server to > indicate whether it supports jose, jose+json, or both? > > -F > > > On Mar 2, 2018, at

Re: [Acme] Example requests

Hey Joern, This is a probably a good thing to have. I think that rather than putting these in the main spec, it might be better to have them in a second draft. This is a pretty common pattern. For example, for TLS 1.3, there's a "test vectors" document separate from the main spec [0]. There are

Re: [Acme] Specify which JWS serialization is used

The lengths of the emails in this thread illustrate the complexity risk here :) In the interest of simplicity, I would really like to stick to Flattened JSON unless someone has **strong** objections. Logan, to your point about library compatibility, two notes: (1) it's OK if we front-run librarie

Re: [Acme] Specify which JWS serialization is used

ent, so yes. > See rfc7694 for details. > > 406 is for failed conneg. Not something you expect to see much here. > > > On 5 Mar. 2018 09:25, "Richard Barnes" wrote: > > The lengths of the emails in this thread illustrate the complexity risk > here :) > >

Re: [Acme] Specify which JWS serialization is used

p with httpbis. I think that's an > error, though probably only an error of omission. 7694 was so fixated > on solving the content-coding issue, it neglected the obvious > accompanying fix. > > On Mon, Mar 5, 2018 at 9:38 AM, Richard Barnes wrote: > > How about Accept?

Re: [Acme] Concerning alternative formats …

Thomson: Could h2 push replace some of the polling here? On Mon, Mar 5, 2018 at 4:50 PM, Felipe Gasper wrote: > > > On Mar 5, 2018, at 1:13 PM, Matthew D. Hardeman > wrote: > > > > Especially with CT logging being a pragmatic requirement, > time-to-delivery for certificates is likely to increas

Re: [Acme] Draft agenda

I'm not sure we have material for 30min on the main document. AFAIK, all the open issues are closed. On Fri, Mar 9, 2018 at 8:56 AM, Salz, Rich wrote: > We are meeting Weds, 15:20-16:50 90 minutes > > > > Agenda bashing + Blue sheets + Note Well (5 min) > Status update (chairs - 5 min) >

Re: [Acme] Certificate chains including roots

This matches my understanding. ACME cannot be prescriptive on this, not least because the notion of a "root certificate" is not well defined for the server -- the server doesn't know what the client does or does not trust. On Mon, Mar 12, 2018 at 11:26 AM, Martin Thomson wrote: > The usage mod

Re: [Acme] Question about finalizing an order

Yoav: I'm going to propose we wait until IETF LC ends, and cut a new draft before sending it to the IESG. Merging PRs is just the modern way of doing accepting LC comments and addressing them before IESG evaluation. On Mon, Mar 26, 2018 at 8:00 PM, Daniel McCarney wrote: > Richard: Will you tak

Re: [Acme] Question about finalizing an order

On Tue, Mar 27, 2018 at 8:26 PM, Sophie Herold wrote: > > On 23/03/18 15:43, Daniel McCarney wrote: > > My preference here is no. This would introduce two ways to check for the > > same thing: whether an order is ready. One by checking the status == > > "ready" and one by checking if there is a f

Re: [Acme] Question about finalizing an order

be too busy > this week having just come back to work from IETF week. So I’d rather any > changes that we know are happening should be published before the > directorates get started on their reviews. > > Yoav > > > On 27 Mar 2018, at 22:09, Richard Barnes wrote: > >

Re: [Acme] Reminder: Orders List

On Tue, Mar 27, 2018 at 9:16 PM, Sophie Herold wrote: > On 27/03/18 22:54, Daniel McCarney wrote: > > Are you also > > proposing that authorizations should be retrieved only by authenticated > > POST? > > The information contained in an order will be (more or less) part of the > certificate. Ther

Re: [Acme] Comments on ACME draft

Here's a quick PR implementing Tim's proposed changes. https://github.com/ietf-wg-acme/acme/pull/420 Personally, these seem fine to me. I would be in favor of merging the PR. On Wed, Apr 11, 2018 at 4:41 PM, Tim Hollebeek wrote: > > I think the draft is in very good shape. > > Unfortunately

Re: [Acme] don't assume sort order of "authorizations", "identifiers" and "challenges" in responses.

I'm generally skeptical of trying to enumerate what clients should **not** do. But this seems fine. I approved the PR. On Tue, Apr 17, 2018 at 12:53 PM, Daniel McCarney wrote: > There has been some confusion[0][1] around the relationship between the > "identifiers" and "authorizations" arrays

Re: [Acme] Genart last call review of draft-ietf-acme-acme-11

Hi Dale, Thanks for the review. Responses inline below; changes in this PR: https://github.com/ietf-wg-acme/acme/pull/424 On Wed, Apr 18, 2018 at 9:03 PM, Dale Worley wrote: > Reviewer: Dale Worley > Review result: Ready with Issues > > I am the assigned Gen-ART reviewer for this draft. The

Re: [Acme] Genart last call review of draft-ietf-acme-acme-11

Hi Dale, Thanks for the review. Responses inline below; changes in this PR: https://github.com/ietf-wg-acme/acme/pull/424 On Wed, Apr 18, 2018 at 9:03 PM, Dale Worley wrote: > Reviewer: Dale Worley > Review result: Ready with Issues > > I am the assigned Gen-ART reviewer for this draft. The

Re: [Acme] AD Review: draft-ietf-acme-acme-12

[ Adding the mailing list ] Thanks for the thorough review, EKR. I've posted a PR with proposed resolutions: https://github.com/ietf-wg-acme/acme/pull/425 You do hit on a couple of moderately technical points, some of which I would like the WG to take a quick look at. Those are highlighted wi

Re: [Acme] AD Review: draft-ietf-acme-acme-12

On Tue, May 15, 2018 at 2:37 AM Ilari Liusvaara wrote: > On Tue, May 15, 2018 at 01:20:14AM +0000, Richard Barnes wrote: > > [ Adding the mailing list ] > > > > > S 6.6. > > > > | > > | | > >

Re: [Acme] AD Review: draft-ietf-acme-acme-12

On Tue, May 29, 2018 at 4:02 PM Eric Rescorla wrote: > > > On Mon, May 28, 2018 at 9:57 PM, Russ Housley > wrote: > >> Eric: >> >> >> > > Do you want to specify a set of acceptable signature algorithms here? > > I am inclined not to. We have already forbidden "none" and MAC. We

Re: [Acme] Do we need/want mandatory-to-implement signature algorithms?

On Wed, May 30, 2018 at 5:41 PM Stephen Farrell wrote: > > Hi Russ, > > On 30/05/18 22:31, Russ Housley wrote: > > It seems to me that ACME is being used to support certificate > > enrollment for many different applications, so the same approach > > seems appropriate. > I agree with your descript

Re: [Acme] Do we need/want mandatory-to-implement signature algorithms?

On Thu, May 31, 2018 at 5:09 PM Eric Rescorla wrote: > > > On Thu, May 31, 2018 at 2:03 PM, Richard Barnes wrote: > >> >> >> On Wed, May 30, 2018 at 5:41 PM Stephen Farrell < >> stephen.farr...@cs.tcd.ie> wrote: >> >>> >>> Hi R

Re: [Acme] AD Review: draft-ietf-acme-acme-12

I went ahead and posted a PR implementing EKR's suggestion: https://github.com/ietf-wg-acme/acme/pull/429 On Wed, May 30, 2018 at 4:23 PM Daniel McCarney wrote: > We have multiple CA’s that support it, and other implementations as well. > > > Of the multiple CAs that support ACME, which suppor

Re: [Acme] AD Review: draft-ietf-acme-acme-12

Richard Barnes wrote: > I went ahead and posted a PR implementing EKR's suggestion: > > https://github.com/ietf-wg-acme/acme/pull/429 > > > On Wed, May 30, 2018 at 4:23 PM Daniel McCarney > wrote: > >> We have multiple CA’s that support it, and other imple

Re: [Acme] Confirming consensus

On Thu, Jul 19, 2018, 17:05 Ilari Liusvaara wrote: > On Thu, Jul 19, 2018 at 01:03:14PM -0700, Roland Shoemaker wrote: > > One thing that I forgot to bring up during the meeting was an issue > > that was brought up with regards to the order in which the ACME-TLS-ALPN > > and ACME-IP drafts are st

Re: [Acme] Consensus on WGLC for draft-ietf-acme-star-03

As a point of order, I'm pretty sure the chairs don't need consensus to move to WGLC, they can just do it. On Wed, Jul 18, 2018 at 3:53 PM Salz, Rich wrote: > For context: this is draft-ietf-acme-star-03 as mentioned in the Subject > but not the body. > > > > *From: *Rich Salz > *Date: *Wednesd

Re: [Acme] I-D Action: draft-ietf-acme-ip-03.txt

You beat me to it. On Wed, Jul 25, 2018 at 1:59 PM Salz, Rich wrote: > Use ip-addr.arpa names? > > > ___ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > ___ Acme mailing lis

Re: [Acme] DE review comment draft-ietf-acme-acme

Seems reasonable. I filed , which I'll handle with the rest of LC comments in a couple of days. On Tue, Aug 7, 2018 at 7:59 PM Jim Schaad wrote: > It would be nice to have the description for the JOSE header 'url' be more > descriptive that the st

Re: [Acme] Last Call: (Automatic Certificate Management Environment (ACME)) to Proposed Standard

Without looking at them in context that seem pretty reasonable. Happy to review a PR. On Wed, Aug 8, 2018, 21:03 Sean Turner wrote: > These are all minor so I didn’t send them to i...@ietf.org. Also, once > we settle on whether these are okay, I can submit a PR if you’d like (or > not if that

Re: [Acme] Last Call: (Automatic Certificate Management Environment (ACME)) to Proposed Standard

e/pull/433 >> >> And three issues: >> >> https://github.com/ietf-wg-acme/acme/issues/434 >> https://github.com/ietf-wg-acme/acme/issues/435 >> https://github.com/ietf-wg-acme/acme/issues/436 >> >> spt >> >> > On Aug 8, 2018, at 21:48,

Re: [Acme] optional MIME parameter for application/pem-certificate-chain

Hi Felix, Thanks for reflecting this back to the list. The concrete implementation concerns are helpful. I'm concerned that the need here is more than just a simple MIME parameter. The MIME parameter is just an aspect of the media type; it just tells you what's in the object you're looking at.

Re: [Acme] I-D Action: draft-ietf-acme-acme-14.txt

; This draft is a work item of the Automated Certificate Management > Environment WG of the IETF. > > Title : Automatic Certificate Management Environment > (ACME) > Authors : Richard Barnes > Jacob Hoffman-Andrews >

  1   2   3   4   5   >