+1
At 04:28 14/03/2017 Tuesday, Roland Shoemaker wrote:
>I'd argue that removing the challenge version numbers adds unnecessary
>complexity to the specification and any existing implementations going
>forward.
>
>Existing servers and clients will need to have some kind of mapping from
>the draft
On Mon, Mar 13, 2017 at 02:00:40PM -0700, Jacob Hoffman-Andrews wrote:
> > by CA/B forum as a "recommendation", which meant that the constraint
> > was meaningless. Rumour has it that CAA will soon be a requirement,
> > so I've now published CAA records. The CAA check is/was easy to
> > make and
Consider this a dry run for eventually rolling out variants that use
SHA-3-?? instead of SHA-256. The code for aliasing should give you
confidence that you can ship new challenges without disrupting
usability.
In a way, it's a shame that the challenges didn't change more often
during development.
I'd argue that removing the challenge version numbers adds unnecessary
complexity to the specification and any existing implementations going
forward.
Existing servers and clients will need to have some kind of mapping from
the draft names to the final un-versioned names and any protocol
revisions
As Rich said, the CA/Browser Forum has indeed voted to mandate CAA. Hooray!
On 03/13/2017 01:14 PM, Viktor Dukhovni wrote:
> I've had complete disinterest in CAA which initially was accepted
> by CA/B forum as a "recommendation", which meant that the constraint
> was meaningless. Rumour has it th
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
> Rumour has it that CAA will soon be a requirement
It just passed their balloting so CA/B forum now requires it. See the LAMPS WG
thread(s) on CAA erratum 4515.
> The CAA check is/was easy to make and crippling it
> by not making it a requirement was IMNSHO a mistake.
...
> I urge the WG to re
On Tue, Mar 07, 2017 at 03:46:00AM +, Salz, Rich wrote:
> > Specifically, it 10.3 use of DNSSEC is a RECOMMENDATION, not a
> > requirement:
> >
> > https://tools.ietf.org/html/draft-ietf-acme-acme-05#section-10.3
> >
> > I would have expected a requirement here.
>
> The WG consensus has
I would prefer we stick with dropping the version number, just because it's
cleaner and the future is bigger than the past.
On Mar 13, 2017 2:27 PM, "Jacob Hoffman-Andrews" wrote:
> Roland posted a PR tweaking the challenge names for the final RFC:
> https://github.com/ietf-wg-acme/acme/pull/27
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
of the IETF.
Title : Automatic Certificate Management Environment (ACME)
Authors : Richard Barnes
Roland posted a PR tweaking the challenge names for the final RFC:
https://github.com/ietf-wg-acme/acme/pull/272.
This raised the question: What do we want the challenge names to be in
the final RFC? I think we've been assuming that "http-01" would become
"http" once the RFC is published. However,
11 matches
Mail list logo
