On Sat, Mar 18, 2017 at 1:08 PM, Phillip Hallam-Baker wrote:
>
>
> On Tue, Mar 14, 2017 at 2:24 PM, Richard Barnes wrote:
>
>>
>>
>> On Tue, Mar 14, 2017 at 12:24 PM, Hugo Landau
>> wrote:
>>
>>> > > The CAA check is/was easy to make
> Have you seen the thread on the LAMPS (SPASM) mailing list, titled
> "CAA Erratum 4515"? That raises some technical issues, which make me
> (as an individual at least) think it's premature.
I wasn't aware of this.
However, as far as I'm aware mandatory CAA checking is now a done deal:
> I'd agree that the CAA check should be made mandatory. At least, I can't
> think of any good reason why it shouldn't be.
Have you seen the thread on the LAMPS (SPASM) mailing list, titled "CAA Erratum
4515"? That raises some technical issues, which make me (as an individual at
least) think
> > 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 reconsider.
>
> Does anyone else agree with Viktor? Please speak up on the list this week if
> so.
I'd agree that the CAA check should be made mandatory.
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
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
> 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
On Tue, Feb 07, 2017 at 05:27:48PM +, Salz, Rich wrote:
> I put the time period as six weeks, which takes us to just around IETF-98...
>
> PLEASE reply on list if you will review and/or are interested in working on
> interop.
I see there's no reference to use of DNSSEC resolvers by CAs
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
Rich asked to me to divide my comments into technical and editorial. This are
the same comment that I sent earlier with that categorization.
Russ
= = = = = = = =
TECHNICAL
In Section 5.1, I think it is desirable to add a requirement that the ACME
server SHOULD OCSP Staple.
In Section 5.5,
On 2017-02-13 06:26, Martin Thomson wrote:
In the examples below, JWS objects are shown in the JSON or flattened
JSON serialization, with the protected header and payload expressed
as base64url(content) instead of the actual base64-encoded value, so
that the content is readable.
On 11 February 2017 at 05:56, Salz, Rich wrote:
> ACME WGLC
It's been a while since I did a review of this, so I spent a few hours on it.
This document is in pretty good shape. I have a lot of comments (a
LOT), and some of these are serious enough that I'd want to see
another
From: IETF Secretariat [mailto:ietf-secretariat-re...@ietf.org]
Sent: Tuesday, February 07, 2017 12:26 PM
To: draft-ietf-acme-a...@ietf.org; acme-cha...@ietf.org
Subject: IETF WG state changed for draft-ietf-acme-acme
The IETF WG state of draft-ietf-acme-acme has been changed to "In WG
Last
> PLEASE reply on list if you will review and/or are interested in working on
> interop.
Looking for last-minute Valentine's Day plans?
(https://en.wikipedia.org/wiki/Valentine's_Day among others). What could be
more romantic than an evening spent with your loved one reading the ACME WGLC
14 matches
Mail list logo