Re: [Acme] Proposal for adding arbitrary CA-specific name-value pairs to registration object

On Tue, Nov 22, 2016 at 1:33 PM, Ray Cheng wrote: > We are using a "ca-account-secret" with the "new-reg" request to make an > association between the ACME account key and a CA account. > > We have implemented additional security measures around our >

Re: [Acme] Proposal for adding arbitrary CA-specific name-value pairs to registration object

quot;" Values and their meanings must be documented in a permanent and readily available public specification, in sufficient detail so that interoperability between independent implementations is possible. """ > > > Ray > > > > *From:* Richard Barnes [mailto

[Acme] IETF 97 follow-up PRs

Hey ACME folks, I've posted a few PRs implementing decisions made at the F2F: #207 - Change agreementRequired to userActionRequired https://github.com/ietf-wg-acme/acme/pull/207 #208 - Remove the 'requirements' abstraction https://github.com/ietf-wg-acme/acme/pull/208 #209 - Add an external

Re: [Acme] Combine "requirements" and "authorizations."

== valid could be represented by reference, as in { "status": "valid", "url": "..." }. Happy to hear folks' thoughts on the list here, and talk F2F tomorrow. --Richard On Tue, Nov 15, 2016 at 1:02 PM, Jacob Hoffman-Andrews <j...@eff.org> wrote: > On

Re: [Acme] IETF-97 Agenda

Reminder: Meeting is tomorrow! 13:30 Seoul 20:30 San Francisco 23:30 New York 04:30 London Meetecho: http://www.meetecho.com/ietf97/acme/ Audio stream: http://ietf97streaming.dnsalias.net/ietf/ietf978.m3u On Sat, Oct 29, 2016 at 7:32 AM, Richard Barnes <r...@ipv.sx> wrote: > > &

Re: [Acme] Application -> order

I really don't care. If people like "order", we can do a global search and replace, and hope the RFC Editor will catch the ones we miss. While we're at it, the bikeshed I've been caching is "registration" -> "account". Seems like normal people think of "registration" as something you do once,

Re: [Acme] Combine "requirements" and "authorizations."

On Fri, Oct 28, 2016 at 8:55 PM, Jacob Hoffman-Andrews wrote: > Let me put it a different way: Offering the same value in multiple > places is really bad API design. I'm trying to fix that. We could remove > the inlined authorization status, leaving the requirements with an >

Re: [Acme] Combine "requirements" and "authorizations."

On Fri, Oct 28, 2016 at 6:34 PM, Jacob Hoffman-Andrews <j...@eff.org> wrote: > On 10/28/2016 03:18 PM, Richard Barnes wrote: > > I think the crux of our disagreement is actually above. You seem to > > be arguing that authz for different identifier types are as different

Re: [Acme] IETF-97 Agenda

On Wed, Oct 26, 2016 at 2:58 PM, Salz, Rich wrote: > Here’s the current agenda draft for IETF-97. Please reply to the list if > you want any changes. > > -- Rich and Ted. > > > > ACME at IETF-97 > > > > Wed Nov 16, 2016 at 13:30-15:00 > For those who might be

Re: [Acme] Combine "requirements" and "authorizations."

ce the URL in the requirements array before you figure out what the specific task is (from the "type" in the authorization object), as opposed to being able to figure it out from a requirement object. --Richard On Wed, Oct 26, 2016 at 2:27 PM, Jacob Hoffman-Andrews <j...@eff.org> wrote:

Re: [Acme] issuance to eTLDs

Ultimately, it's up to the CA to decide what names it's willing to issue for. (There are other controls on those decisions, such as the CABF Baseline Requirements [1].) Typically, CAs refuse to issue for names on the PSL, or at least have big procedural fences around such issuance. But if a CA

Re: [Acme] Default to PEM with chain for certificates

Ayer <a...@andrewayer.name> wrote: > On Sun, 2 Oct 2016 11:49:47 -0400 > Richard Barnes <r...@ipv.sx> wrote: > > > This change seems to suppose that there is One True Cert Chain, and > > the CA is the one to provide it. Clearly neither of these is true. > &g

Re: [Acme] Simplifying ToS agreement

On Tue, Sep 13, 2016 at 11:56 AM, Jacob Hoffman-Andrews wrote: > > > Anything that isn't tested Will be broken. We can't fix that in the > > protocol, but we can fix it by adding tests :) > We can also fix it by deleting unnecessary things, which is the best and > most reliable

Re: [Acme] Combine "requirements" and "authorizations."

I'm worried that we're losing a lot of useful, clear semantics here in order to save a few bytes. I understand the impulse here; it is challenging to have multiple status values that could conflict with each other, and it's a pain for the client to have to go fetch a separate authorization

Re: [Acme] URI-based CAA account binding

Thanks for the draft, Hugo. In general, the idea of making CAA more precise seems like a good vein to explore, and to the dimensions of precision overlap with ACME semantics, it makes sense to do it here. The other case (besides account URI) that I've heard folks talk about is allowing the

Re: [Acme] Application/Authorization statuses

This sounds fine to me too, though I have some quibbles with the PRs. - We should get rid of "processing" globally (#186 leaves it for authorizations) - It seems duplicative to have "deactivated", "revoked", and "invalid". Maybe we can keep "invalid" as "this failed without ever being valid", but

Re: [Acme] Pre-authorization approach

Not seeing any blockers on this from the subsequent discussion. Chairs, what say you? On Fri, Aug 26, 2016 at 5:17 PM, Eric Rescorla wrote: > > > On Fri, Aug 26, 2016 at 1:33 PM, Roland Bracewell Shoemaker < > rol...@letsencrypt.org> wrote: > >> On 08/26/2016 12:25 PM, Eric

Re: [Acme] Terms of service agreement changes

> > > -Original Message- > > From: Jacob Hoffman-Andrews [mailto:j...@eff.org] > > Sent: Monday, August 29, 2016 2:36 PM > > To: Salz, Rich; Richard Barnes > > Cc: acme@ietf.org > > Subject: Re: [Acme] Terms of service agreement changes &g

Re: [Acme] PRs for unparallelization and new-nonce

These three (#164, #181, #185) have now been merged. On Fri, Aug 26, 2016 at 11:04 PM, Richard Barnes <r...@ipv.sx> wrote: > One more, pretty trivial one, but throwing it out there in case people > have bike shed paint they want to use: > > #185 - Change 'url' field on OOB

Re: [Acme] IDN encoding

Yeah, there's no reason to use U-labels here. Let's just require that the names be in ASCII. I don't think there's really a need to require anything further than that (servers can do case folding). Note that this only affects Authorization.identifier.value for Authorization.identifier.type ==

Re: [Acme] PRs for unparallelization and new-nonce

, there are both "uri" and "url" fields, which seemed destined to lead to confusion. So this PR changes the "url" field to "href", as in . On Fri, Aug 26, 2016 at 1:16 PM, Richard Barnes <r...@ipv.sx> wrote: > Hey all, > > Going through PRs today, tr

Re: [Acme] Clarifying "new-x" resources paragraph

This looked fine to me, so I just merged it. On Thu, Aug 25, 2016 at 4:20 PM, Daniel McCarney wrote: > Hello again, > > I've taken a crack at clarifying what I found to be a confusing paragraph > from > Section 6.1 "Resources"[0]: > > > For the "new-X" resources

Re: [Acme] Proactive vs On-Finalization Certificate Issuance

On Thu, Aug 25, 2016 at 5:41 PM, Andrew Ayer wrote: > On Thu, 25 Aug 2016 13:57:25 -0400 > Daniel McCarney wrote: > > > In the earlier "Re: [Acme] Preconditions" thread[2] Andrew Ayer seems > > to agree > > that there should be only one issuance

Re: [Acme] Proactive vs On-Finalization Certificate Issuance

Hey Daniel, Thanks for doing the research so I didn't have to find those threads :) I admit to also being in the "go-ahead-and-issue" camp. To recap, that would mean: 1. Client submits a new application 2. Server sends back some authorizations 3. Client fulfills authorizations 4. Server issues

Re: [Acme] Implicit vs. explicit keys (was Re: Unparallelizing roll-over)

PM, Jacob Hoffman-Andrews <j...@eff.org> wrote: > On 08/19/2016 01:02 PM, Richard Barnes wrote: > > Just for clarity, I assume the proposal would be to require something > > like { "account": "accountURL" } in the JWS header instead of the "

[Acme] Implicit vs. explicit keys (was Re: Unparallelizing roll-over)

[Forking this into two threads] [Fork 1 of 2] On Fri, Aug 19, 2016 at 2:30 PM, Jacob Hoffman-Andrews <j...@eff.org> wrote: > On 08/19/2016 09:31 AM, Richard Barnes wrote: > > Actually I thought of another reason, which is more compelling: There's > > no specified algorit

[Acme] Inner nonces for key-change (was Re: Unparallelizing roll-over)

[Forking this into two threads] [Fork 2 of 2] On Fri, Aug 19, 2016 at 2:30 PM, Jacob Hoffman-Andrews <j...@eff.org> wrote: > On 08/19/2016 09:31 AM, Richard Barnes wrote: > > On further thought, I think I would like to propose that we go back to > > not c

Re: [Acme] Remove "contact channel" from threat model?

I hesitate to remove it. I agree that since we removed contact-based recovery, it's less central, but since the "contact" field is still there, CAs will need to consider the risks if they ever use it. On Thu, Aug 18, 2016 at 4:53 PM, Jacob Hoffman-Andrews wrote: > Here's a PR

Re: [Acme] Unparallelizing roll-over

On Sat, Aug 6, 2016 at 2:16 PM, Jacob Hoffman-Andrews <j...@eff.org> wrote: > On 08/06/2016 11:03 AM, Richard Barnes wrote: > > - Less bloat > > I think that's not a concern for this rarely used endpoint. > > - Implementations are already going to need to have a thumbpr

Re: [Acme] Add a special token parameter in ACME registration

On Tuesday, August 16, 2016, Martin Thomson <martin.thom...@gmail.com> wrote: > On 17 August 2016 at 06:48, Richard Barnes <r...@ipv.sx> wrote: > > a. Infer the certificate type from the CSR. For example, if the Subject > in > > the CSR has (C, O, CN), infer that

Re: [Acme] Add a special token parameter in ACME registration

There are two clearly separable problems here: 1. Associating an ACME account key to an account in some other system 2. Determining when to issue an EV certificate (and with what contents) Let's address them each separately. (Note that Andy filed https://github.com/ietf-wg-acme/acme/issues/170

Re: [Acme] Post-IETF-96 PRs

On Sun, Aug 7, 2016 at 8:29 PM, Martin Thomson <martin.thom...@gmail.com> wrote: > On 8 August 2016 at 12:39, Richard Barnes <r...@ipv.sx> wrote: > > So I'm honestly not that convinced that we need versioning at all here. > > Maybe we could get away with just versi

Re: [Acme] Post-IETF-96 PRs

On Sun, Aug 7, 2016 at 7:28 PM, Martin Thomson wrote: > On 7 August 2016 at 03:46, Jacob Hoffman-Andrews wrote: > >> #162 - Add a protocol version > >> https://github.com/ietf-wg-acme/acme/pull/162 > > > > Still thinking about this one. Seems sound at

Re: [Acme] Post-IETF-96 PRs

On Sat, Aug 6, 2016 at 12:57 PM, Peter Bowen <pzbo...@gmail.com> wrote: > On Thu, Jul 28, 2016 at 2:52 PM, Richard Barnes <r...@ipv.sx> wrote: > > Hey all, > > > > I just posted several PRs implementing agreements from the IETF meeting. > > > > #161 -

Re: [Acme] Terms of service agreement changes

On Sun, Aug 7, 2016 at 8:34 AM, Hugo Landau wrote: > On Sat, Aug 06, 2016 at 11:30:25AM -0700, Jacob Hoffman-Andrews wrote: > > Let's Encrypt recently did its first update of its Subscriber Agreement, > > and ran into some incompatibility. The current spec makes it seem like

Re: [Acme] Nonces for GETs

On Sat, Aug 6, 2016 at 2:55 PM, Jacob Hoffman-Andrews wrote: > At IETF 96 it was proposed to drop this issue: > https://www.ietf.org/proceedings/96/minutes/minutes-96-acme. > > The rationale from the notes is that nonces are not a scarce resource. > However, cachability and

Re: [Acme] Unparallelizing roll-over

On Sat, Aug 6, 2016 at 12:53 PM, Jacob Hoffman-Andrews <j...@eff.org> wrote: > On 07/28/2016 02:54 PM, Richard Barnes wrote: > > #164 - Unparallelize signatures on key-change > > https://github.com/ietf-wg-acme/acme/pull/164 > I don't like the JWS approach of "

Re: [Acme] Pre-authorization approach

On Sat, Aug 6, 2016 at 1:36 PM, Jacob Hoffman-Andrews wrote: > Having both new-application and new-authz seems simple enough from a > server perspective, but I think it will create interoperability problems > for clients. Specifically, most clients will choose to implement one >

Re: [Acme] Post-IETF-96 PRs

Two more: #165 - Re-add new-authz as pre-authorization https://github.com/ietf-wg-acme/acme/pull/165 #166 - Clarify 'url' field processing https://github.com/ietf-wg-acme/acme/pull/166 On Thu, Jul 28, 2016 at 5:52 PM, Richard Barnes <r...@ipv.sx> wrote: > Hey all, > > I just

Re: [Acme] Pre-authorization approach

On Wed, Jul 27, 2016 at 5:52 AM, Ilari Liusvaara <ilariliusva...@welho.com> wrote: > On Tue, Jul 26, 2016 at 02:29:54PM -0700, Andrew Ayer wrote: > > On Tue, 26 Jul 2016 23:03:18 +0200 > > Richard Barnes <r...@ipv.sx> wrote: > > > > > - Add an &qu

Re: [Acme] Schedule for WGLC (was Minutes and verifying some decisions)

On Thu, Aug 4, 2016 at 11:32 PM, Ron wrote: > On Thu, Jul 28, 2016 at 08:24:13PM +, Salz, Rich wrote: > > * Request to the mailing list "hey, if you have a post-v1-WGLC, tell > > us or this may not exist further!" > > > > That last item deserves some more explanation. We

Re: [Acme] Contact URIs

ave a slight preference for filtering. We went the hard-fail way with new-cert (now new-app), but in this case, the client can fix things by updating the registration, so it seems like less of a big deal. --Richard > > > On Jul 28, 2016, 3:25 PM -0700, Richard Barnes <r...@ipv.s

Re: [Acme] Contact URIs

> > This was the intention of the original ticket I filled, although maybe not > as coherently. > > > On Jul 28, 2016, 3:17 PM -0700, Ted Hardie <ted.i...@gmail.com>, wrote: > > Hi Richard > > On Thu, Jul 28, 2016 at 2:42 PM, Richard Barnes <r...@ipv.sx> wrote

[Acme] Post-IETF-96 PRs

Hey all, I just posted several PRs implementing agreements from the IETF meeting. #161 - Drop the OOB challenge https://github.com/ietf-wg-acme/acme/pull/161 #162 - Add a protocol version https://github.com/ietf-wg-acme/acme/pull/162 #163 - Make duplicate new-reg return 303

[Acme] Contact URIs

Roland filed an issue proposing removal of any URIs other than "mailto:;. https://github.com/ietf-wg-acme/acme/issues/159 I really strongly disagree with this. At the level of this protocol, we should allow clients to specify whatever types of contact they want, as long as it can be specified

Re: [Acme] Minutes and verifying some decisions

On Thu, Jul 28, 2016 at 4:24 PM, Salz, Rich wrote: > I’ve posted the minutes here: > https://www.ietf.org/proceedings/96/minutes/minutes-96-acme > > > > Please review them. > > > > At the meeting, we came to consensus on several items, summarized here: > > * support both old

[Acme] Pre-authorization approach

Hey folks, At the IETF meeting, EKR pointed out the need to have a "pre-authorization" function in ACME, where the client can get authorization to issue for certain names without causing a certificate to be issued. Having thought about this a bit on the way home from the meeting, I'd like to get

Re: [Acme] Attribute Certificates Re: Short term certificates - two options

On Fri, Jul 22, 2016 at 12:52 PM, Yaron Sheffer wrote: > On 21/07/16 12:36, Sean Leonard wrote: > >> >> On Jul 20, 2016, at 2:51 AM, Yaron Sheffer wrote: >>> >>> Option 2: Certificate Delegation >>> >>> This option moves more of the responsibility

Re: [Acme] Economize on nonces

Looking at this further, I don't really see what the benefit is. On the one hand, it's trivial to implement a nonce scheme where it's free to issue as many nonces as you want, and you only have to store nonces that actually get used [1]. The thing that's costly is using nonces, which this

Re: [Acme] Economize on nonces

On Saturday, July 9, 2016, Niklas Keller wrote: > 2016-07-09 18:57 GMT+02:00 Ron >: > >> On Fri, Jul 08, 2016 at 04:02:36PM -0700, James Kasten wrote: >> > I agree that there are a large number of wasted nonce

Re: [Acme] Simplifying key rollover

On Fri, Jul 8, 2016 at 4:04 PM, Jacob Hoffman-Andrews <j...@eff.org> wrote: > On 07/08/2016 10:09 AM, Richard Barnes wrote: > > You missed the part in Karthik's email where he said that both keys > > have to sign both keys :) The current structure has a copy/paste >

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

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

Re: [Acme] Preconditions

OK, I have updated the preconditions PR to reflect this discussion. It's more invasive than I thought going in, but I think it hangs together. https://github.com/ietf-wg-acme/acme/pull/124 If there are not major objections before tomorrow morning EST, I'm going to go ahead and merge it. We can

Re: [Acme] Preconditions

So to be blunt: You're saying that some of what we want could be achieved by hacks within the existing model, rather than getting all of what we want by changing the model :) I really think it's cleaner at this point to change the model. There's not that much deployed code yet, so we should go

Re: [Acme] Preconditions

On Thu, Jul 7, 2016 at 5:10 PM, Jacob Hoffman-Andrews <j...@eff.org> wrote: > Re-adding the list. I dropped it by accident. > > On 07/07/2016 01:50 PM, Richard Barnes wrote: > > > > On Thu, Jul 7, 2016 at 3:38 PM, Jacob Hoffman-Andrews < <j...@eff.org> > j..

Re: [Acme] Preconditions

On Wed, Jul 6, 2016 at 2:38 PM, Jacob Hoffman-Andrews wrote: > I think the general concept is good, and if we go this route I agree > that it should replace new-authz. However, I think there are significant > details to be worked out, and Eric's feedback is good. I don't want to >

Re: [Acme] Preconditions

On Wed, Jul 6, 2016 at 2:54 PM, Jonathan Rudenberg wrote: > It seems that there are potentially multiple valid sets of authorizations > that are mutually exclusive. > > Consider a request for a certificate that has three SANs: a.example.com, > b.example.com, c.example.com

Re: [Acme] Preconditions

On Wed, Jul 6, 2016 at 12:52 PM, Eric Rescorla <e...@rtfm.com> wrote: > > > On Wed, Jul 6, 2016 at 8:01 AM, Richard Barnes <r...@ipv.sx> wrote: > >> In preparation for the impending draft deadline, I'm trying to finalize >> close this out. It seems

Re: [Acme] Revert "Allow the client to give a preference for a specific IP in http-01"

I agree with Niklas that this extension seems harmless. It seems like we could make it safe to ignore just by tweaking the verification rules so that the server is only required to check the containment if it's going to use the "address" field as a guide. Jacob: Could you clarify whether you

Re: [Acme] SSRF possible in ACME through http-01 using HTTP redirects (#136)

Hey Blake, Thanks for bringing this up. I agree that this would be good to document in the Security Considerations, or maybe within the Operational Considerations below. Would you like to take a shot at a PR? Thanks, --Richard On Thu, Jun 9, 2016 at 8:30 PM, Blake Burkhart

Re: [Acme] [acme] Account deletion for security currently useless if rolled over

You can already revoke with the cert key. On Mon, Apr 18, 2016 at 12:30 PM, Philipp Junghannß < teamhydro55...@gmail.com> wrote: > In my opinion it would be also nice if you could revoke with the cert key > making it possible to remove the cert even if the acc is down. > Am 18.04.2016 18:15

[Acme] Reminder: ACME F2F this afternoon, with dial-in

Just wanted to make sure everyone is aware that there's an ACME F2F meeting happening at the IETF this afternoon, 17:40-19:40 Argentina Time (13:40-15:40 US Pacific, 20:40-22:40 UTC). https://tools.ietf.org/agenda/95/ Remote participation is possible. You can find links to audio streaming, XMPP

Re: [Acme] Simplifying key rollover

On Thu, Mar 31, 2016 at 5:27 PM, Jacob Hoffman-Andrews wrote: > I'd like to propose some changes to how we do account key roll-over. I > think the current approach is too complex. The current version is > included below for reference. > > Instead I'd like to propose: > > To update

Re: [Acme] On multiple CAs and contact-based recovery

ACME client. > > The attack described here is on account recovery, but a similar attack > appears if we allow email-based > domain validation. A malicious ACME server or man-in-the-middle can then > get certificate issued for C’s > domains with its own public key, without compromising the &

Re: [Acme] On multiple CAs and contact-based recovery

On Thu, Mar 24, 2016 at 5:42 AM, Ron wrote: > On Thu, Mar 24, 2016 at 04:45:06PM +1100, Martin Thomson wrote: > > On 24 March 2016 at 09:33, Karthik Bhargavan > > wrote: > > > Emails with clickable links are *BAD*; we should enhance their >

Re: [Acme] HTTP and DNS Challenge string

On Mon, Mar 21, 2016 at 3:43 PM, Ilari Liusvaara <ilariliusva...@welho.com> wrote: > On Mon, Mar 21, 2016 at 03:36:49PM -0400, Richard Barnes wrote: > > Having the token also lets the validation server operator specify which > > names the key is being authorized for. I might

Re: [Acme] HTTP and DNS Challenge string

Having the token also lets the validation server operator specify which names the key is being authorized for. I might have virtual hosting box with 200 names on it; I don't want to authorize any given key for all of them. On Mon, Mar 21, 2016 at 12:51 PM, Ilari Liusvaara

Re: [Acme] Agreement integrity checksum

Thanks for the PR! I agree that having an integrity hash is overkill, and we should focus on advising CAs. That said, the considerations for how CAs track agreements are very much specific to each CA, so I'm hesitant to have MUST-level requirements. If you change it to a SHOULD, then I think

Re: [Acme] PR for account key rollover

My intent was for that "JSON object signed as JWS" to be the JSON object shown above. Would it be clearer to frame the example as follows? ~~ POST /acme/reg/asdf HTTP/1.1 Host: example.com { "resource": "reg", "newKey": { "header": { "jwk": /* JWK form of the new key */, ... },

[Acme] PRs from IETF 94

Hey all, I just finished posting a bunch of PRs that I believe reflect the agreements we reached during the ACME meeting at IETF 94. I went ahead and merged those that were either editorial or well-discussed in the room: https://github.com/ietf-wg-acme/acme/pull/40

Re: [Acme] Content-Type and file extensions for HTTP01 challenges

Sorry if I pulled the trigger on that one a bit early. Happy to revise, as always. I think there was pretty feeling in the room at the IETF meeting that Content-Type checking was not doing much. Are we aware of any actual scenarios where untrusted entities can write to .well-known directories?

Re: [Acme] Open issues on GitHub

Yup. I'm working up PRs on the issues we resolved at the F2F last week. I'll take a look at these issues next. On Thu, Nov 12, 2015 at 5:43 PM, Martin Thomson wrote: > Others might disagree, but those look largely editorial to my reading. > My guess is that the

Re: [Acme] New draft and DANGER

7:04 PM, Andrew Ayer <a...@andrewayer.name > <javascript:_e(%7B%7D,'cvml','a...@andrewayer.name');>> wrote: > >> On Wed, 30 Sep 2015 21:48:32 -0700 >> Richard Barnes <r...@ipv.sx> wrote: >> >> > The authorized key object is JSON, which means that the n

Re: [Acme] New draft and DANGER

I have implemented this solution in this PR: https://github.com/ietf-wg-acme/acme/pull/13 Last call for comments... On Fri, Oct 2, 2015 at 5:00 PM, Richard Barnes <r...@ipv.sx> wrote: > How about something like this: > > Authorized key object is TOKEN.FINGERPRINT, where: > *

Re: [Acme] New draft and DANGER

On Wed, Sep 30, 2015 at 7:32 PM, Andrew Ayer <a...@andrewayer.name> wrote: > On Mon, 28 Sep 2015 15:01:57 -0400 > Richard Barnes <r...@ipv.sx> wrote: > >> I opened a few PRs over the weekend that address recently-raised >> issues: >> >> * "

Re: [Acme] New draft and DANGER

Dear WG, I opened a few PRs over the weekend that address recently-raised issues: * "Address signature reuse vulnerability" - https://github.com/ietf-wg-acme/acme/pull/6 * "Address default virtual host risks" - https://github.com/ietf-wg-acme/acme/pull/7 * "Add explicit versioning to challenges"

Re: [Acme] New draft and DANGER

On Mon, Sep 28, 2015 at 4:43 PM, Ted Hardie <ted.i...@gmail.com> wrote: > On Mon, Sep 28, 2015 at 12:01 PM, Richard Barnes <r...@ipv.sx> wrote: >> >> Dear WG, >> >> * "Add explicit versioning to challenges" - >> https://github.com/ietf-w

Re: [Acme] Signature misuse vulnerability in draft-barnes-acme-04

On Thu, Aug 13, 2015 at 2:40 AM, Rob Stradling rob.stradl...@comodo.com wrote: On 13/08/15 02:58, yan wrote: snip I see James is already fixing this: https://github.com/letsencrypt/acme-spec/pull/217/files. Shouldn't that work be happening at... https://github.com/ietf-wg-acme/acme

Re: [Acme] Signature misuse vulnerability in draft-barnes-acme-04

will be easy for them. Akamai typically doesn't, so they might want to do an HTTP-based challenge. -- Eric On Thu, Aug 13, 2015 at 1:21 AM, Richard Barnes r...@ipv.sx wrote: On Wed, Aug 12, 2015 at 4:04 PM, Andrew Ayer a...@andrewayer.name wrote: On Tue, 11 Aug 2015 22:52:05 -0700 Richard Barnes

Re: [Acme] Signature misuse vulnerability in draft-barnes-acme-04

Hey Andrew, Thanks for the really thoughtful analysis here. I'm not 100% sure I agree that there are non-trivial cases where RSA allows one to find a key that will verify a given (message, signature) pair. (I would note, however, that you don't even need to find the modular inverse d of e --

[Acme] JOSE usage (was Re: WG meeting at IETF 93)

Dealing with JOSE nuances is not germane to this WG. Yes, JOSE has failings -- pretty much all of which were pointed out during the JOSE WG process, and dismissed at the time. They are not so bad, however, as to render JOSE as-is unusable. Certainly the cure described in

Re: [Acme] Validation Vulnerabilities

On Friday, June 5, 2015, Salz, Rich rs...@akamai.com wrote: FWIW, IMHO, and whatever other fla's are appropriate: I think it makes sense to at least detail the attacks, since relying on DNS is one of the methods supported by ACME. We should document these risks, but we should be clear that

Re: [Acme] Proposed ACME Charter Language

On Wed, May 13, 2015 at 7:36 PM, Ted Hardie ted.i...@gmail.com wrote: On Wed, May 13, 2015 at 4:22 PM, Randy Bush ra...@psg.com wrote: ACME certificate management must provide automated methods for revocation parallel to those use to request a certificate? what the heck does parallel

Re: [Acme] Want client-defined callback port

On Wed, Apr 22, 2015 at 9:51 PM, Phillip Hallam-Baker ph...@hallambaker.com wrote: I think this discussion is getting way too deep into the weeds of policy. That isn't a concern IETF has generally taken a definitive stand on. If it had there would not have been the need to set up CABForum

Re: [Acme] Considerations about ACME BoF

On Tue, Mar 31, 2015 at 4:22 AM, Scott Rea scott@digicert.com wrote: G'day Yaron, I will make 2 brief observations: a) Max and I actually proposed some usability focused work around TLS certs to the PKIX WG about 6 or 7 years ago, when PKIX was still going strong, and we were told that

Re: [Acme] ACME BoF in Dallas -- call for agenda items, issues, speakers

I would be happy to give an overview of draft-barnes-acme-*, and some of the design rationales for what's in there. It would be good to have some input form other folks who have designed and deployed cert automation stuff, e.g., CAs and hosting/server/CDN operators. In terms of goals for the

<    1   2   3