On 07/14/2018 04:38 PM, Tobias Fiebig wrote:
Back when we submitted Cloud Strife [0] to NDSS, we reached out to the list on
pushing our mitigations toward a recommendation/best practices RFC. Given that
with the Birge-Lee paper, there is now a second attack vector, we (Kevin
Borgolte and I, bu
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 : Automatic Certificate Management Environment (ACME)
Authors : Richard Barnes
At IETF102 we had extremely strong consensus to merge this, to address the last
open AD review comment.
As Richard said, if you have concerns or objections, please speak up NOW.
/rich, co-chair
From: Richard Barnes
Date: Tuesday, July 17, 2018 at 6:00 PM
To: "c...@letsencrypt.o
and based on feedback at the meeting, I went ahead and merged this. I
understand that EKR will be issuing an IETF last call soon, so if you have
concerns about this change, please raise them there. Or on this thread,
but in any case, ASAP.
Thanks,
--Richard
On Tue, Jul 17, 2018 at 4:27 PM
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
Hi Ilari,
Unfortunately, the situation is even more grave than allowing 0-length
whitespace delimiters, as section 3 and section 5.2 of RFC 6844 contradict each
other in regard to the delimiter (section 3 specifies the parameter delimiter
as a semicolon, whereas in section 5.2 it's "0 or more wh
Yeah, I'm not particularly picky on the solution as long as we agree on a
solution
that works. I believe that parameter usage is pretty rare in the wild right
now,
so I think we have time to come to a consensus about what the right behavior
is,
and document it via fixing examples or errata or what
On Tue, Jul 17, 2018 at 01:08:28PM +, Tim Hollebeek wrote:
> Yes, the RFC 6844 grammar is a mess, and it has significantly impeded
> efforts to improve CAA. It's one of the things I think is most important to
> fix in 6844bis.
The main problem in my opinion with RFC6844 grammar is the example
>- Change reference to RFC6844bis.
A standards-track document cannot reference a draft. So either we wait, or we
wait for an errata to be written and accepted, or we do this:
>- Fix examples (and other text) to be consistent with the RFC6844
grammar (which pretty obviously splits
On Tue, Jul 17, 2018 at 01:25:51PM +, Salz, Rich wrote:
> Ilari,
>
> That is a very impressive discussion of the issues, and examples. Thank you
> very much!
>
> So, what should the WG do with the CAA challenge document?
I think either:
- Change reference to RFC6844bis.
- Fix examples (
My personal opinion is that the WG should try to come up with something that
makes sense and complies with the intent of 6844 and its examples, instead
of trying to be overly strict about complying with the current grammar as
written.
We can then file an errata and work with LAMPS to fix up the gr
Ilari,
That is a very impressive discussion of the issues, and examples. Thank you
very much!
So, what should the WG do with the CAA challenge document?
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
Yes, the RFC 6844 grammar is a mess, and it has significantly impeded
efforts to improve CAA. It's one of the things I think is most important to
fix in 6844bis.
It is particularly troubling because CABF rules point to 6844, and some
people have been sticklers about requiring very strict complian
On Mon, Jul 16, 2018 at 08:08:24PM -0700, Roland Shoemaker wrote:
> I know this is quite late but could we reserve some time for a
> discussion of the (possible) pending issues with regard to the
> parameter format mismatch between ACME-CAA and 6844 and possible
> solutions.
I took a look at the i
14 matches
Mail list logo
