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 description of the past:-)
I don't agree with not specifying MTI algs though.
> On May 30, 2018, at 3:54 PM, Salz, Rich
> wrote:
>
> Yes, please ask. If I'm going to tell the IESG that no MTI is needed, I want
> to tell them that the WG had consensus.
>
> This came up in the “AD review” thread that many of you have probably just
> seen and skimmed or ignored. :)
>
Various editorial changes and cleanups, mainly looking to clarify the Security
Considerations/Design Rationale sections. The one technical change here is
removing references to keyAuthorization in the challenge update step as this no
longer happens in the ACME draft.
> On May 30, 2018, at 2:07
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
WG of the IETF.
Title : ACME TLS ALPN Challenge Extension
Author : Roland Bracewell Shoemaker
>
> We have multiple CA’s that support it, and other implementations as well.
Of the multiple CAs that support ACME, which support something resembling
the current draft? When I looked last the non-Let's Encrypt ACME server
implementations all seemed to be targeting Certbot and the "ACMEv1" era
* The reason I chose those values is because you're already tied to TLS for
the communications and therefore you necessarily have the TLS MTI cipher
suites, which means you already have those algorithms.
If your toolkit exposes it. If your toolkit is a black box or scripted such as
CURL,
On Wed, May 30, 2018 at 12:56 PM, Salz, Rich wrote:
>
>- Well, we have a fair bit of experience of a lot of people talking to
>Let's Encrypt. That's not really the same as a lot of servers and a lot of
>clients.
>
>
>
> We have multiple CA’s that support it, and other implementations
* Well, we have a fair bit of experience of a lot of people talking to
Let's Encrypt. That's not really the same as a lot of servers and a lot of
clients.
We have multiple CA’s that support it, and other implementations as well.
Certainly LE dominates, but it’s not the only usage. And
* Yes, please ask. If I'm going to tell the IESG that no MTI is needed, I
want to tell them that the WG had consensus.
This came up in the “AD review” thread that many of you have probably just seen
and skimmed or ignored. :)
ACME does not define any mandatory-to-implement signature
On Wed, May 30, 2018 at 11:45 AM, Salz, Rich wrote:
> I believe the working group has decided that MTI algorithms are not
> necessary. If you want that confirmed on the list, we can ask.
>
Yes, please ask. If I'm going to tell the IESG that no MTI is needed, I
want to tell them that the WG had
On Wed, May 30, 2018 at 11:25 AM, Richard Barnes wrote:
>
>
> 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?
> >
>
Apologies for the delay on publishing the latest draft. I'll work on
getting that out today. Thanks for the reminder!
On 05/30/2018 12:17 PM, Corey Bonnell wrote:
Hello,
This development is exciting work in regard to allowing domain owners
to limit which validation methods they want to
Hello,
This development is exciting work in regard to allowing domain owners to limit
which validation methods they want to allow to be used for their domains.
Unfortunately, the validation-methods extension is not compliant with RFC 6844
(the CAA RFC), as parameter tags cannot contain hyphens.
I believe the working group has decided that MTI algorithms are not necessary.
If you want that confirmed on the list, we can ask. ACME isn’t just WebPKI, as
you know, it’s also becoming STIR and some have proposed home environments.
We have many implementations to serve as proof points that
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
Hi folks,
I'm happy to share that Let's Encrypt has deployed support for Hugo
Landau's ACME-CAA "validation-methods" CAA record extension in the staging
environment[0]. Community feedback/review would be most appreciated.
You can find more information in the associated API announcement[1].
16 matches
Mail list logo
