[cabfpub] Revising CAA: meeting at 7pm PST / 10pm EST

Meeting agenda is at https://datatracker.ietf.org/meeting/agenda/. Video URL is http://www.meetecho.com/ietf100/lamps/. The IETF LAMPS group will be discussing a revision of the CAA specification this evening (morning Singapore time). Hopefully this will codify the tweaks to CAA we wound up

Re: [cabfpub] Path forward for DV cert subjects

On Fri, Nov 3, 2017 at 2:37 PM, Peter Bowen via Public wrote: > What do others think? Is it reasonable to allow DV certificates with > countryName in the subject? > I think this is a reasonable and good path forward. I would like it if we could choose a value for

Re: [cabfpub] Ballot 208 - dnQualifiers

Let's Encrypt votes YES to ballot 208. On Fri, Oct 20, 2017 at 3:17 PM, Peter Bowen via Public wrote: > > We could move to serialNumber or assign new object identifier which can > be used for this purpose, but is would have no more meaning than > dnQualifier for all known

Re: [cabfpub] CAA working group description

On Mon, Oct 9, 2017 at 4:04 PM, Geoff Keating wrote: > I don’t think any of these apply at the IETF level; I’m sure the IETF is > not going to specify a ‘what if you only wanted a little bit of DNSSEC’ > configuration > Why not? If DNSSEC is not deployable in practice by CAs,

[cabfpub] Clarification on DNAME erratum

Andrew Ayer reported an erratum on RFC 6844, separately from the erratum 5065 tree-climbing issue: https://www.rfc-editor.org/errata/eid5097 The current RFC 6844 says: > Let CAA(X) be the record set returned in response to performing a CAA > record query on the label X, P(X) be the DNS label

Re: [cabfpub] CAA working group description

> I know there’s a CAA document going through ACME. Is this also going LAMPS? The ACME WG is already working on account UIR and validation-methods parameters. Given that this represents two of the four parameters suggested during the F2F, should we add the other two there? There are two CAA

Re: [cabfpub] CAA working group description

On Thu, Oct 5, 2017 at 11:09 AM, Phillip wrote: > What somewhat worries me is a situation in which I have ten CABForum > members tell me that they really want X in a CABForum group and then I > report that into the IETF WG and three people say they have other ideas and >

Re: [cabfpub] CAA working group description

With respect, I would suggest that there is already a CAA working group: the IETF LAMPS WG at https://datatracker.ietf.org/wg/lamps/charter/. It has the advantage of being open for anyone to join and post, so CAs can more easily have conversations with Subscribers and Relying Parties. If half of

Re: [cabfpub] CAA look up failures and retry logic

You make a good point. To reiterate the language from the BRs: > CAs are permitted to treat a record lookup failure as permission to issue if: > • the failure is outside the CA's infrastructure; > • the lookup has been retried at least once; and > • the domain's zone does not have a DNSSEC

Re: [cabfpub] Fix to CAA ballot

This also looks good to me. On Mon, Sep 25, 2017 at 6:32 AM, Tim Hollebeek via Public < public@cabforum.org> wrote: > This looks good to me and we would support it. > > > > *From:* Public [mailto:public-boun...@cabforum.org] * On Behalf Of > *philliph--- > via Public > *Sent:* Saturday,

Re: [cabfpub] Fixing our voting process, again

This seems like a good change. On Mon, Sep 25, 2017 at 7:48 AM, Gervase Markham via Public < public@cabforum.org> wrote: > On 21/09/17 01:54, Kirk Hall via Public wrote: > > Technically, the Discussion period ended at 22:00 UTC today (which was > > 3:00 pm Pacific Time). Josh, as the Proposer

Re: [cabfpub] Voting has started on Ballot 214 - CAA Discovery CNAME Errata

voting on Ballot 214 as originally proposed* (see below). If > there is a need for a transition period, I think it’s best if it’s proposed > by a separate ballot with specific language. > > > > > > *From:* Public [mailto:public-boun...@cabforum.org > <public-boun...

[cabfpub] Updates on CAA deployment

Hi all, I wanted to share my recent post from Let's Encrypt's forums regarding our experiences implementing CAA. In particular I'd like to draw attention to RFC6844's potential for loops, which I brought up during previous discussion of the problems with legacy RFC6844. This is preventing us from

[cabfpub] Ballot 214: CAA Discovery CNAME Errata

Kicking off the official discussion period for ballot 214 today per discussion with Phillip. The following motion has been proposed by Phillip Hallam-Baker of Comodo Group Inc. and endorsed by Gervase Markham of Mozilla and Mads Egil Henriksveen of Buypass. -- MOTION BEGINS -- In the Baseline

Re: [cabfpub] CAA: Interpretation of 3.2.2.8 + 3.2.2.5

On Mon, Aug 28, 2017 at 2:56 PM, Ryan Sleevi via Public wrote: > As such, if you desire an IP-address bearing certificate, there is no > means you can use to limit the CAs who can issue or (by virtue of the > CA-specific extensions) any policies that the issuing CAs use to

Re: [cabfpub] FW: [Errata Held for Document Update] RFC6844 (5065)

Phillip, you said last week: On Fri, Aug 25, 2017 at 9:00 AM, Phillip wrote: > ​I will endorse for Comodo but I don’t think we are quite there yet :) > In your opinion, what else needs to happen before starting the ballot process on this? It looks ready to me.

Re: [cabfpub] FW: [Errata Held for Document Update] RFC6844 (5065)

This looks good to me. On Fri, Aug 25, 2017 at 9:00 AM, Phillip wrote: > ​ > > I will endorse for Comodo but I don’t think we are quite there yet :) > > > Some further wordsmithing: > > > As part of the issuance process, the CA MUST check for a CAA record for > each dNSName

Re: [cabfpub] Ballot 202 - Underscore and Wildcard Characters

Let's Encrypt votes YES on Ballot 202. On Wed, Jul 12, 2017 at 10:24 AM, Ben Wilson via Public wrote: > *Ballot 202 - Underscore and Wildcard Characters* > > The current Baseline Requirements do not expressly allow underscore > characters in Subject Alternative Names. This

Re: [cabfpub] Ballot 202 - Underscore and Wildcard Characters

If people are curious, as I was, about why RFC 5890 restricts use of Reserved LDH Labels, here is what I believe to be the relevant paragraph: https://tools.ietf.org/html/rfc5890#page-8 > Labels within the class of R-LDH labels that are not prefixed with > "xn--" are also not valid IDNA labels.

Re: [cabfpub] [Ext] .well-known and re-directs

I disagree with Paul's interpretation. At Let's Encrypt we have always followed HTTP redirects, and consider it an important part of validating by HTTP. Consider, for instance, a web site that redirects all "http:" URLs to "https:" URLs. If that site were required to inhibit redirects for

Re: [cabfpub] empty set -- RFC 6844

On Thu, Jun 15, 2017 at 7:49 PM, y-iida--- via Public wrote: > Hello, public. > > I'd like to make it clear the cases when CAA RR set is empty. > > The first paragrapth of chapter 4 of RFC 6844 reads: > If such a record set exists > and it means that the certificate

Re: [cabfpub] CAA final errata proposed text

I posted separately on the IETF LAMPS / SPASM mailing list saying I think this version is good: https://mailarchive.ietf.org/arch/msg/spasm/SzxQoAOVluz5B_QfJ34U16epq_A. I'd encourage folks here who are interested in CAA and agree that this is a good revision to join that mailing list and post in

[cabfpub] OCSP Requests and Do Not Track

Forwarding on behalf of a colleague at EFF who is working on the Do Not Track standard: Forwarded Message Subject: OCSP Requests and Do Not Track Date: Mon, 15 May 2017 16:22:58 -0400 From: Alan Toner To: Jacob Hoffman-Andrews , Peter Eckersley

Re: [cabfpub] Ballot 195 - CAA Fixup is in the DISCUSSION period (ends April 10)

On Mon, Apr 10, 2017 at 11:20 AM, philliph--- via Public < public@cabforum.org> wrote: > Discussion in the LAMPS WG indicated that the consensus was to replace the > search algorithm completely with one that uses prefixes. > I participated in the LAMPS WG via videoconference at IETF 98, and read

Re: [cabfpub] Certificate encoding

On 03/04/2017 07:25 AM, Peter Bowen via Public wrote: > X.509 (10/2012) Section 6.3 (Distinguished encoding of Basic Encoding Rules) says " In order to enable the validation of SIGNED and SIGNATURE types in a distributed environment, a distinguished encoding is required. A distinguished encoding

Re: [cabfpub] Ballot 187 - Make CAA Checking Mandatory

Let's Encrypt votes YES. During the discussion period, I voiced some concerns about the clarity of the CAA RFC, but I think those don't cause serious problems with this ballot. ___ Public mailing list Public@cabforum.org

Re: [cabfpub] Ballot 187 - Make CAA Checking Mandatory

On Sun, Feb 26, 2017 at 7:02 PM, Ryan Sleevi wrote: > You're imposing a particular deployment of DNS in order to gain advantage > of CAA, and I'm hesitant to suggest that the CA/Browser Forum is the right > venue for that - both in terms of scope and in terms of knowledge. >

Re: [cabfpub] Durations

On Sun, Feb 5, 2017 at 1:34 PM, Kirk Hall via Public wrote: > Many of us have complex validation and issuance programming already based > on months and anniversaries, and there doesn't seem to be a good reason to > reprogram all this to a set number of days Peter's

Re: [cabfpub] CAA concerns (and potential solutions)

On Fri, Oct 28, 2016 at 9:52 AM, Peter Bowen via Public wrote: > OK. I used a machine with a locally running caching resolver. I then did > the following as a test: > > Fetch top-1m.csv.zip > Unzip it > head -n 200 top-1m.csv | cut -d, -f2 | sed -r -e ’s/^/www./‘ >

Re: [cabfpub] Continuing the discussion on CAA

On Tue, Oct 25, 2016 at 11:52 PM, Jeremy Rowley via Public < public@cabforum.org> wrote: > Basically, I’d like a way for the domain owner to opt-out of CAA checks for performance reasons, which I think resolves the concerns you raised. The performance problems may not be as bad as you think, with

Re: [cabfpub] Continuing the discussion on CAA

On Tue, Oct 18, 2016 at 1:44 PM, Gervase Markham wrote: > > our investigations we've found that 0.1% of domains with a current Let's > > Encrypt certificate return SERVFAIL for CAA. > > Does that tend to be a permanent or a temporary condition? > In this particular

Re: [cabfpub] Continuing the discussion on CAA

On Mon, Oct 17, 2016 at 11:11 AM, Rick Andrews via Public < public@cabforum.org> wrote: > Posting to public list (seems to have been dropped) > > I'll need to poll folks internally, but Symantec would probably support > this. > How do other CAs feel? > > -Rick > > -Original Message- >