This seems like a big deal, no? That is, since SNI is one of the few
things not protected in the TLS handshake, it does seem spoofable. If
there's not something I'm missing, it seems like the proposal should
just drop DVSNI altogether.
An attacker who fully controls the network is explicitly not
Yep, I get that. I might be misreading it, but it looked like the
suggestion of a /.well-known URI for account keys would impact all
ACME users, not just those using Simple HTTP validation.
I didn't fully expand the idea, but my assumption was that similar
continuous publication techniques
This is an excellent find, thanks for spotting it and writing it up.
On 08/11/2015 08:52 AM, Andrew Ayer wrote:
To fix this, I propose simply publishing the authorized account public key
(or a hash of it) in the
TXT record (for DNS challenges), in the TLS certificate (for DVSNI), or in
the
I like the idea, and it generalizes to the other queries. For instance,
you can imagine putting up an HTTP validation file that contains a list
of authorized account keys, with no random token.
However, the CA/B Forum validation requirements currently being
discussed include a requirement for a
There are a few issues with the Proof of Possession challenge as
currently spec'ed
(https://github.com/ietf-wg-acme/acme/blob/master/draft-ietf-acme-acme.md#proof-of-possession-of-a-prior-key).
1. A TLS handshake using DHE or ECDHE involves the server automatically
signing something that begins
On 10/30/2015 08:04 AM, Hugo Landau wrote:
> - The expiry date on authorization objects is a date and not a timestamp. This
> seems undesirable; in some cases it may be desired to issue an authorization
> for a very short period of time, such as 30 minutes. Shouldn't this field be
> a
https://github.com/ietf-wg-acme/acme/pull/17
Previously the language was ambiguous about whether the list of error
types was intended to be exhaustive. This clarifies that clients should
handle unknown error types gracefully. It also adds a new `rateLimited`
error type.
On 10/01/2015 07:04 PM, Andrew Ayer wrote:
> Well... previously, the protocol was relying on a non-existent
> property of digital signatures. With a client-constructed authorized
> key object, it would be relying on the second-preimage resistance of
> SHA-256, which is a pretty safe bet, to put
On 10/02/2015 02:00 PM, Richard Barnes wrote:
> Authorized key object is TOKEN.FINGERPRINT, where:
> * TOKEN is the token in the challenge
> * FINGERPRINT is the JWK thumbprint of the account key (per the
> relevant JOSE spec)
This sounds reasonable. I don't see a reason to have the client echo
> what's the reason why "authorizations" and "certificates" are optional
in registration objects? They should both not be optional IMO, because
they can be used nicely to lower the load on the CA, because clients can
reuse prior authorizations and even download lost certificates easily.
This makes
https://github.com/ietf-wg-acme/acme/pull/138
This reverts commit a5cb357
I think we did not reach consensus on the list about this feature.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
> Typical targets for SSRF would be metadata services (like
> 169.254.169.254 in AWS or OpenStack), any not publicly exposed HTTP
> interface of the server's stack (like the HTTP API of the RabbitMQ
> management plugin), or any other internal HTTP server on the server's
> private network.
>
>
(Picking up an old thread)
> >> There's a fairly good solution available with the current
> >> protocol, which is to serve a (long lived) redirect from
> >> /.well-known/acme-challenge/ on all of the servers to a
> >> different URL that is always answered by the machine you run an
> >> ACME client
On 03/31/2016 02: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 the
https://github.com/ietf-wg-acme/acme/pull/137
This reverts commit 556ab4e (pull #75).
Deployment experience has shown that DNS via TCP to remote hosts is too
unreliable to use in practice. Let's Encrypt uses DNS via TCP only
within its own datacenter, and may stop doing that soon too.
On 06/13/2016 04:27 AM, Richard Barnes wrote:
> Jacob: Could you clarify whether you think there's a substantive issue
> here, or just a process issue?
Substantive. I restarted the conversation on the earlier thread about this.
___
Acme mailing list
Any objections to the below? We'd like to start implementing in Boulder
soon.
On 06/09/2016 03:59 PM, Jacob Hoffman-Andrews wrote:
> On 03/31/2016 02: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
https://github.com/ietf-wg-acme/acme/pull/143
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
I've submitted a pull request to add a new rejectedIdentifier error
type, for malformed and blacklisted names:
https://github.com/ietf-wg-acme/acme/pull/142
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
This change brings our use of problem documents more in line with
I-D.ietf-appsawg-http-problem.
https://github.com/ietf-wg-acme/acme/pull/84
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
First question: Do we want to bind the account key thumbprint, or the
account (registration) URL? In the latter case, an entity that rotates
their account key periodically doesn't have to update DNS at the same time.
I see two use cases for this:
1. A domain admin with subdomains pointed at web
I posted this pull request:
https://github.com/ietf-wg-acme/acme/pull/86/files
For some accounts, the list of authorizations or certificates will be
too large to reasonably return in a single request. This adds a notion
of paging: you get an initial list of resources, with a link rel=next
On 04/11/2016 08:23 AM, Yaron Sheffer wrote:
> But that wasn't my question. I understand how a CDN and ACME can
> co-exist. My question was how to prevent a malicious CDN from creating
> a "black" certificate for my server as soon as they control the
> content on www.example.com. The ACME draft
A couple thoughts:
- Probably the "reset" field should be named something else, and should
only be provided when a rate limit was actually hit. Let's Encrypt uses
a sliding window (aka leaky bucket) for rate limits, so reset time is
not well-defined for requests that didn't hit a limit.
- One of
>> #102 Replace in-band account recovery with `meta`
>> https://github.com/ietf-wg-acme/acme/pull/102
> This is pretty ambiguous. In the spirit of the above, I would leave this
> unspecified until we have a clearer idea of what we want out of this.
To clarify my feedback: I am find with removing
On 03/20/2016 07:14 PM, Richard Barnes wrote:
> #101 Remove proof-of-possession challenge
> https://github.com/ietf-wg-acme/acme/pull/101
This looks fine. As an implementer, I think we may want to implement
some proof-of-possession concept in the future, but I think this
mechanism is not quite
> It seems what we'd really want for that is the ability to query for
all current authorisations and to be able to revoke them even if you
aren't in possession of the account key that obtained them (but are in
possession of the key which most recently performed authz).
Another way to achieve
Hi Jason,
I replied on the GitHub issue as well, along the same lines as Rich: the
protocol should not attempt to specify policy.
To add a little more detail: I'm definitely a big advocate of "real"
account deletion, where all records are actually purged after a certain
amount of time. At past
Proposed change: instead of deletion of accounts and authorizations,
specify deactivation. This simplifies both the spec and the
implementation, and leaves data retention choices up to CA policy.
https://github.com/ietf-wg-acme/acme/pull/125
___
Acme
> Should that still say something about the server revoking authz? Since
there is no way to revoke that once the account key is revoked (unless
we do the auto-revoke thing when authz is obtained for another account key).
I think from the previous discussion, the best way to do this is by
On 07/08/2016 04:36 PM, Roland Shoemaker wrote:
> (Playing devils advocate) Why not just remove the nonce system entirely?
>
> The main use of the nonce system is to protect against TLS termination
> at a CDN (or MITM middleboxes) which could, if malicious, replay
> requests. Why not instead just
On 07/08/2016 04:02 PM, James Kasten wrote:
> It seems unfortunate that with this PR, the only guaranteed way to
> begin the ACME process is by posting a failed registration request.
The feedback about sending a failed POST to get your first nonce, and
400's not being recoverable, makes a lot of
On 07/12/2016 01:50 PM, Daniel McCarney wrote:
> What does "equivalence" mean in the context of JSON Web Keys?
This is good feedback, I didn't define it clearly in the code as-is. The
goal is this: Since accounts are uniquely identified by their key, keys
must be unique. Let's Encrypt / Boulder
On 08/07/2016 06:55 PM, Richard Barnes wrote:
> Could you comment a little more specifically on what issues this has
> caused you?
We turned on caching at our CDN, which led to some clients getting
nonces that had already been used by other clients. A lot of clients
didn't implement retries on
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
rush this into the spec because we have a document deadline coming up.
I'd rather
On 07/07/2016 05:18 PM, Salz, Rich wrote:
> That's the LetsEncrypt protocol, not the IETF ACME protocol. We're not
> here to polish the staples and rubber-stamp. /r$, speaking as
> co-chair. -- Senior Architect, Akamai
I agree with this. Let's Encrypt has planned all along to make some
breaking
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
> vulnerability. I went ahead fixed this in the current
> parallel-signature structure...
Good point. I had
Jeff raises a good point. There are a number of people here, including
myself, who are not active in the IETF in general, and so aren't aware
of upcoming meetings and deadlines. From this perspective, progress on
the spec seems to come in sudden spurts of activity without adequate
time for
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
> <mailto:j...@eff.org>> wrote:
>
> On 07/07/2016 11:16 AM, Richard Barnes wrote:
> &g
(Resending mail where the list got dropped, to make the flow of
conversation clearer):
On 07/07/2016 11:16 AM, Richard Barnes wrote:
> That wasn't my intent. Rather, I wanted the CA to be able to say,
> e.g., "you have to provide a contact". Does that much seem useful?
Ah, now I get it. But
(Resending Richard's mail where the list was still dropped, to make the
flow of converstaion clearer):
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 >
> <mailto:j...@eff.org>> wrote: > > On 07/07/20
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 thumbprint
> implementation around for the challenges.
> - Not worried about pinning a hash function because we (1)
On 08/05/2016 12:22 PM, Richard Barnes wrote:
> #165 - Re-add new-authz as pre-authorization
> https://github.com/ietf-wg-acme/acme/pull/165
Gave feedback on a separate thread.
> #166 - Clarify 'url' field processing
> https://github.com/ietf-wg-acme/acme/pull/166
LGTM
>
> #161 - Drop the
> To be clear, in the current spec, the new-app flow is not optional.
> The new-cert endpoint has been eliminated, so clients have to be able
> to at least use new-app to request a certificate.
Right. To rephrase: If part of the rationale for new-application is that
some CAs want all validation
> I would note that the most recent version of the spec to have
> new-authz also used 303 when it found an existing authz. So wherever
> we end up, we should be consistent between those two cases.
Good point.
>
> As far as 3XX (your argument is not specific to 303) -- it seems like
> the
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 "just wrap it in another layer of
base64url," but I agree that this is a bit of an improvement over the
existing scheme.
I agree with Jon that November seems early to go into last call. We will
probably have an updated spec available for use with Let's Encrypt by
then, and some clients will probably have upgraded, but I don't know if
we'll have enough operational experience to conclude that it's solid.
> For better or worse, the state of the industry right now is that not
> everything can be fully automated all of the time. Sometimes CAs need
> for the tools to get a human in the loop for an updated agreement.
I agree not everything can be automated all the time. That's why I think
that ACME
Any further objections to this?
https://github.com/ietf-wg-acme/acme/pull/167/files
On 08/09/2016 12:50 PM, Jacob Hoffman-Andrews wrote:
> On 08/09/2016 12:42 PM, Ron wrote:
>>> - If the CA uses legal auto-update language (most common case by far),
>>> nothing else is re
On 08/16/2016 06:38 PM, Eric Rescorla wrote:
> This text seems like an attempt to triangulate between what's the
> protocol and some notion of user consent (which wasn't really present
> in the original version). If I were to implement this code, I might
> well just do:
Are you talking about
On 08/17/2016 12:33 AM, Ron wrote:
> On Tue, Aug 16, 2016 at 06:25:26PM -0700, Jacob Hoffman-Andrews wrote:
>> Any further objections to this?
>>
>> https://github.com/ietf-wg-acme/acme/pull/167/files
>
> Aside from Eric's remarks, I'm also not too keen on a blanket
&g
On 08/17/2016 10:11 AM, Eric Rescorla wrote:
> Can you tell me more about what you find confusing? Is it just the MUST?
>
> The whole text.
> If so, I'm happy to change it to a SHOULD, with the understanding that
> the server is likely to reject such requests.
>
>
> Again, I'd like
On 08/17/2016 10:47 AM, Eric Rescorla wrote:
> I don't think the current text is very clear, so I think if we're going
> to not change
> that we should keep the text as-is while we discuss what it ought to say.
In other words, don't change the protocol part until we have the legal /
UI part
On 08/17/2016 11:57 AM, Eric Rescorla wrote:
> On Wed, Aug 17, 2016 at 11:27 AM, Jacob Hoffman-Andrews <j...@eff.org
> <mailto:j...@eff.org>> wrote:
>
> On 08/17/2016 10:47 AM, Eric Rescorla wrote:
> > I don't think the current text is very clear, s
On 02/03/2017 10:46 AM, Richard Barnes wrote:
> This is a good question, and I'm not sure what the right answer is.
> It seems like there are basically three options:
>
> 1. Remove the "up" relation
> 2. Have the "up" relation point to the order that created the authz
> (if any)
> 3. Have
so I think it's
important to clarify.
On 01/19/2017 11:55 AM, Jacob Hoffman-Andrews wrote:
> Hi all,
>
> I did a top-to-bottom review of the spec to look for coherency (since
> we've changed a number of concepts), mistakes, and general consistency.
> I filed several pull requ
We've discussed in the past how a domain owner should recover from a
host compromise. I believe we came to a rough consensus that solving a
DV challenge should be sufficient authorization to invalidate extant
authorization on other accounts, and that we can consider each newly
validated authz to
On 01/25/2017 08:28 AM, Niklas Keller wrote:
> I already posted a comment on GitHub, but didn't get a response there,
> so I'm posting here again.
>
> > Standardize on new-account rather than new-acct; previously there
> was a mix.
>
> "authz" and "new-authz" seem to be the only abbreviated
tion
objects.
Introduces an error field for orders. Orders can fail independent of
authorizations because of last-minute CAA checking, failure to submit to
CT logs, timeouts, etc.
>From 7678e4ce122456c8d7c609a3fff99ebfe1ad865b Mon Sep 17 00:00:00 2001
From: Jacob Hoffman-Andrews <git...@hof
On 02/16/2017 02:41 PM, Richard Barnes wrote:
> It seems simplest to me to just register "application/x-pem-file" with
> a pointer to RFC 7468.
Why that as opposed to application/pem-certificate-chain. x-pem-file has
some existing use but it is very small, and pem-certificate-chain is
much more
On 02/17/2017 02:41 PM, Roland Bracewell Shoemaker wrote:
> Splitting the tables up based on where the errors may be encountered is
> useful but adding the new 'error' field to the order object makes this
> slightly confusing. Will the errors on the order be from the first table
> or the second,
On 02/19/2017 06:54 PM, Hugo Landau wrote:
> If a server processes different things in parallel, multiple errors
> could occur. Should the "error" field be an array?
Reading the Problem Document spec, it seems like the expected way to
handle multiple errors is with fields within the problem
Right now, account objects echo back the public key associated with the
account, in the "key" field. However, this is redundant since the only
request types that can return an account object are signed by the
corresponding private key, so the client necessarily knows what its
public key is.
In the WGLC thread, Russ asked:
> In Section 6.5, should the example use different challenges for "http-01",
> "tls-sni-02", and "dns-01"?
(https://ietf-wg-acme.github.io/acme/#rfc.section.6.5)
I assume you meant "token" here, and no, I think the token can be the same
across multiple
On 02/12/2017 10:09 PM, Anders Rundgren wrote:
> JWS is great for what is was originally designed for. ES6 normalization
> nullifies the need for dressing JSON data in Base64Url.
Could you clarify this comment? Are you proposing that ACME should not
wrap internal fields in another layer of
On 02/13/2017 12:20 PM, Russ Housley wrote:
> I do not think it is a risk with the authorizations that have been
> defined. I was wondering about a situation where a client make a
> mistake. If a client tries to fulfill one of the authorizations and
> for some reason is unable to do so completely,
>From the WGLC thread, Russ Housley said:
> Section 6.4.2 says:
> The default format of the certificate is PEM (application/x-pem-file)
> as specified by [RFC7468]. ... The client may request other formats by
> including an Accept header in its request. For example, the client
> may use the
This all looks good to me.
On 02/13/2017 05:49 PM, Roland Shoemaker wrote:
> I propose we remove the 'author', 'revoke', and 'ct-sct' link relations.
> 'author' seems to provide no concrete value, and 'revoke' is already
> provided by the 'directory' endpoint. The 'ct-sct' relation is also
>
Flattened JSON, IMO. And I think we should standardize on that single
representation.
On 02/14/2017 03:39 PM, Logan Widick wrote:
> All,
>
> Which JWS serialization is to be used when implementing? The document
> indicates that the examples are in either flattened JSON or general
> JSON
Martin brought up a section I've been considering removing:
> Clients SHOULD support HTTP public key pinning [RFC7469], and servers
SHOULD emit pinning headers.
Here's my reasoning:
- Public key pinning isn't implemented in most HTTPS libraries outside
of browsers, so this is a considerable
Hi all,
I did a top-to-bottom review of the spec to look for coherency (since
we've changed a number of concepts), mistakes, and general consistency.
I filed several pull requests on GitHub:
https://github.com/ietf-wg-acme/acme/pull/231
https://github.com/ietf-wg-acme/acme/pull/232
https://github.com/ietf-wg-acme/acme/pull/175
The registration object already contains a list of certificate
applications, and
each application contains a link to the resulting certificate if one was
issued.
This reduces the number of primitives that an ACME server has to support.
On 08/18/2016 07:18 PM, Ron wrote:
> It's more that I don't see what we gain from replacing the rich
> interface of:
I'm specifically saying that we should strictly avoid rich interfaces
whenever we don't need them. Complexity is always where brokenness
creeps in.
> while we would lose the
On 08/19/2016 05:32 PM, Ron wrote:
> If the only possible use for it is to include exactly that string,
> then it's just useless verbiage, not an interface.
>
> We might as well just say that sending a request which would fail if
> you didn't include that string indicates acceptance - because
Here are my proposed edits to Richard's current unparallelizing
roll-over branch: https://github.com/ietf-wg-acme/acme/pull/177
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
On 08/21/2016 04:31 PM, Richard Barnes wrote:
> How about this as a compromise proposal: Have the JWS header contain
> *both* the account URL and the account public key. That way you get
> fast rejection based on crypto failures, and you also get protection
> against any issues related to relying
I disagree strongly on this. I've been on vacation last week, and will
be on vacation through Sep 5, but happy to resume the conversation when
I get back.
On 08/26/2016 02:47 PM, Salz, Rich wrote:
>> I'd like to try to close the loop on this. I'm hearing pretty broad
>> agreement here on a few
Restarting the conversation on
https://github.com/ietf-wg-acme/acme/pull/167.
An earlier version of the ACME protocol treated the new-reg URL as the
entry point for all interactions. You'd configure a client with the
new-reg URL, and after creating an account, you'd get URLs for other
resources
> 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 way to avoid bugs. That's why I think this is the right
approach.
> #181 - Add a new-nonce endpoint
> https://github.com/ietf-wg-acme/acme/pull/181
LGTM
> ---
> #164 - Unparallelize signatures on key-change
> https://github.com/ietf-wg-acme/acme/pull/164
>
> We've wandered a little bit in the discussion of this PR, but there
> seems to be agreement on the
On 09/10/2016 04:13 PM, Richard Barnes wrote:
> OK, let me clarify my invariants here: I think we can't get away with
> not supporting the case where the CA updates the terms and needs
> clients to re-agree.
I would argue that we don't need to support it explicitly, because
returning an error with
Currently, Let's Encrypt considers each authorization a one-shot. Once a
client POSTs to a challenge URL, the server validates the challenge and
changes the authorization status to either "valid" or "invalid."
Under the new-application flow, this becomes more awkward. If you
request a certificate
With the combinations array now removed, this is no longer accurate.
https://github.com/ietf-wg-acme/acme/pull/188
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
On 09/21/2016 10:57 AM, Daniel McCarney wrote:
> Section 6.1.2 ("Registration Objects") of the current draft[0] spends
> 5 sentences describing the "applications" field of a registration
> object. I think there was some drift here and parts still refer to
> "authorizations" and the accompanying
On 09/20/2016 01:44 PM, Daniel McCarney wrote:
> Based on the discussion on this thread it seems there is more support
> for the proactive approach. Speaking on behalf of Let's Encrypt and the
> Boulder developers we're willing to compromise and support proactive
> issuance as the sole issuance
On 08/21/2016 06:54 PM, Andy Ligg wrote:
> Sorry, the document still not update in “Registration Objects”, still
> same as Contact.
The pull request is definitely updated. Can you re-check
https://github.com/ietf-wg-acme/acme/pull/172/files?
More to the point, does the proposed change fit your
One of the most common ACME deployment failures observed in practice is
for servers to be configured to serve only the end-entity certificate,
without the intermediate certificates. This is a particularly pernicious
problem because some browsers will still trust the resulting
one-certificate
On 09/24/2016 06:03 PM, Hugo Landau wrote:
>> Very specifically, I am trying to make life easier for clients that
>> hardcode the agreement URL.
> How can hardcoding the URL ever be legitimate?
Sorry, this was one of those worst-case typos. It should have read:
"Very specifically, I am *not*
Does anyone have opinions on how retrying authorizations should work?
I'll work on writing it up, but it would be helpful to have early feedback.
On 09/12/2016 02:27 PM, Jacob Hoffman-Andrews wrote:
> Currently, Let's Encrypt considers each authorization a one-shot. Once a
> client
orization. +1
>
> On Wed, Sep 14, 2016 at 8:56 PM, Jacob Hoffman-Andrews <j...@eff.org
> <mailto:j...@eff.org>> wrote:
>
> https://github.com/ietf-wg-acme/acme/pull/189
> <https://github.com/ietf-wg-acme/acme/pull/189>
>
> Signing with the
On 09/17/2016 02:08 AM, Ron wrote:
>
> And if the answer to that is "we do automate it", then the important
> question is: Does this even remotely satisfy the actual requirement?
IANAL, but the feedback we've gotten so far is it is reasonable for
someone to agree to terms of service through an
Our Threat Model section includes a "Contact channel," but with the
removal of recovery options, the spec no longer has anything to say
about what gets sent to contacts. I think we should probably remove it
from the threat model. Any thoughts?
___
Acme
On 08/18/2016 11:25 AM, Roland Bracewell Shoemaker wrote:
> draft-03 introduces a 'status' field on the registration object with the
> values 'good' or 'deactivated'. I propose two changes to this, using
> 'valid' instead of 'good', which better matches the other statuses used
> elsewhere in the
As the one who asked you to mail the ACME list, no apologies needed.
Glad you've got a path forward!
On 08/18/2016 01:00 PM, Jostein Kjønigsen wrote:
> I would like to thank everyone for their interesting and insightful
> feedback to my email. It has been above and beyond expectations.
>
> I was
Here's a PR removing the contact channel from the threat model:
https://github.com/ietf-wg-acme/acme/pull/174
On 08/17/2016 05:07 PM, Jacob Hoffman-Andrews wrote:
> Our Threat Model section includes a "Contact channel," but with the
> removal of recovery options, the spec no lon
The previous definition of requirements created an awkward extra level
of indirection, with status defined both on requirements and
authorizations. It also created another object type, increasing the
complexity of the protocol.
It was added mainly to provide a concept of an "out-of-band"
I understand the concern, but I think that clients already have to store
a significant amount of state: the ACME directory URL, the private key,
and the domain names, certificates, and private keys of existing
certificates. I think that one more item, the account URL, is not a
heavy burden,
On 09/27/2016 12:17 AM, Hugo Landau wrote:
> But right now you can use Let's Encrypt without providing any means of
> out-of-band communication, so it's not safe to assume that such a
> mechanism — e. mail or otherwise — will be available.
This is exactly why we chose to write our Subscriber
On 09/27/2016 12:26 AM, Hugo Landau wrote:
>> For "DNSName" authorizations, the same constraints still hold - there is
>> a defined DNS name, and the challenges apply to that specific name.
> This looks good. Only a slight nitpick — the label "DNSName" seems
> out-of-kilter with the naming
On 10/02/2016 07:46 AM, Richard Barnes wrote:
> I'm worried that we're losing a lot of useful, clear semantics here in
> order to save a few bytes.
This misunderstands the intent of this change. I'm not trying to save
bytes here, I'm trying to clarify the semantics by (a) having fewer
distinct
1 - 100 of 221 matches
Mail list logo
