2018-01-23 8:09 GMT+01:00 Ilari Liusvaara :
> On Mon, Jan 22, 2018 at 05:09:53PM -0800, Jacob Hoffman-Andrews wrote:
> >
> > To fix that, the CA could assist the user by providing narrowly-scoped
> > DNS hosting: It would serve only TXT records used in validating DNS
> >
2018-01-11 20:36 GMT+01:00 Ilari Liusvaara :
> On Thu, Jan 11, 2018 at 08:23:26PM +0100, Sophie Herold wrote:
> > Hi,
> >
> > challenge tokens "MUST have at least 128 bits of entropy", at the same
> > time it seems trivial to guess order and authorization URLs like the
>
2017-11-21 19:55 GMT+01:00 Jacob Hoffman-Andrews :
> On 11/20/2017 08:24 PM, Martin Thomson wrote:
> > Is this better cast as "sub" problems, or just "additional" problems?
>
> I think "additional" is the wrong semantic, because it implies that the
> first error is hoisted to the
One potential issue I can see with embedding certificates with the
currently proposed format directly into orders are alternative chains.
Chains usually do not change between orders, so they could be kept with
separate URIs for cachability and less bloat in the order response.
e.g.
>
> Sean,
>
> The working group felt pretty clearly that the BEGIN/END base64 encoding
> was the format used by "all" web servers and that anything else would
> require the client to translate into that format.
>
That's true, but using a format that can just be dumped without inspection
makes
>From RFC 2616:
A client MUST include a Host header field in all HTTP/1.1 request messages
. If the requested URI does not include an Internet host name for the
service being requested, then the Host header field MUST be given with an
empty value.
I guess an IP address is not considered an
I'm resending this message as there were no responses and nothing changed.
-- Forwarded message --
Morning,
the current draft contains a few inconsistencies in the resource naming.
1) https://ietf-wg-acme.github.io/acme/#rfc.section.6.1 mentions
"revoke-certificate", while it's
Morning,
the current draft contains a few inconsistencies in the resource naming.
1) https://ietf-wg-acme.github.io/acme/#rfc.section.6.1 mentions
"revoke-certificate", while it's called "revoke-cert" in the rest of the
document.
2) There's "new-account", but the account resource is called
>
> I would argue that we don't need to support it explicitly, because
> returning an error with a link to an out-of-band URL for re-agreeing is
> sufficient, and matches the most likely flow.
This is an interesting idea. Maybe that's also something we could to
for the initial registration?
2016-09-08 23:56 GMT+02:00 Jacob Hoffman-Andrews :
> On 09/08/2016 02:32 PM, Richard Barnes wrote:
>
> So what, we should just delete it? Are you arguing that this
> functionality is unnecessary?
>
> I'm arguing for the changes in https://github.com/ietf-wg-acm
> e/acme/pull/167,
The following PR has been merged:
2016-09-09 0:15 GMT+02:00 Jacob Hoffman-Andrews :
> > #163 - Make duplicate new-reg return 200
>
It should return a status code 200 now and the URI in a content-location
header.
I have two questions:
1. Should we reallly use
2016-08-08 4:07 GMT+02:00 Richard Barnes :
>
>
> 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
2016-07-26 23:03 GMT+02:00 Richard Barnes :
> 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
2016-07-20 11:51 GMT+02:00 Yaron Sheffer :
> Hi,
>
> At the LURK BoF this week there was some interest in having a solution
> where a domain owner can delegate to some other entity (which we will
> call "the TLS server") the authority to terminate TLS connections on its
>
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 values which
> creates
> > a burden for the ACME server. This PR would certainly reduce the number
> of
> > unused nonces.
>
2016-06-09 19:12 GMT+02:00 Jacob Hoffman-Andrews :
> 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.
>
What's the issue with it? I think it's fine. It saves setting up redirects
to
I updated the PR to be compatible with sliding rate limit windows.
The current draft doesn't allow clients to warn before the rate limit is
hit, but at least they can show more useful information once the rate limit
is hit.
2016-03-21 9:53 GMT+01:00 Philipp Junghannß :
> adding to this some parts of rate limits should be maybe made a bit
> clearer if not already (e.g. if you have multiple different domains in a
> SAN which will get the count, just the CN? or all of them?
> also it would be
different clients.
https://github.com/ietf-wg-acme/acme/pull/104
Best Regards,
Niklas Keller
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
2016-02-03 20:55 GMT+01:00 Phillip Hallam-Baker :
> I think Terminology and Dependencies should also have a mention of
> HTTP / HTTPS, also RFC3339 (time format).
>
> What I would like to get to eventually is some external document
> describing a particular style of JOSE
2015-12-15 17:27 GMT+01:00 Richard Barnes :
> 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
Hello,
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
2015-12-05 20:38 GMT+01:00 Jacob Hoffman-Andrews :
> > 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
It's an issue with shared hosting where users have shell access but no root
access.
2015-11-24 17:49 GMT+01:00 Eliot Lear :
> Yes, thanks, Yoav. Apologies to Randy and Kathleen for my terseness.
>
> Eliot
>
>
> On 11/24/15 5:46 PM, Yoav Nir wrote:
> > I think Eliot meant RFC
2015-11-19 20:23 GMT+01:00 Salz, Rich :
> Ø I'd prefer that currently, way better than having a lot of different
> specs with only minimal differences.
>
> We’re not going to have lots of different specs, we’re just bumping the
> version number because there are already
+1 for .txt, there are servers configured to serve only specific file
extensions.
Regards, Niklas
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
f.org> wrote:
>
>> Sounds like we have emerging consensus around this version of 3b. Does
>> anyone know of anything it breaks?
>>
>> On Wed, Nov 18, 2015 at 05:51:55PM +0100, Niklas Keller wrote:
>> > +1 for .txt, there are servers configured to serve only speci
Hello,
how are issues on GitHub handled? Should they always be brought to the
list? Seems like there isn't that much activity there.
I opened a few while implementing my PHP client with no answers during the
last few days.
https://github.com/ietf-wg-acme/acme/issues/31
28 matches
Mail list logo