Re: [cabfpub] CAA working group description

[Jacob Hoffman-Andrews via Public]

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, that's something
the IETF needs to reckon with and include in its specs. We can't allow
DNSSEC deployment problems to become an elephant in the room that nobody
wants to bring to the IETF because there are hard-liners there.

 > I think the IETF RFC should specify fail-closed because that’s the only
fully secure approach

I agree, and I pushed for this when adopting the CAA ballot at CA/Browser
Forum. This is what Let's Encrypt currently implements. However, during
voting on the CAA ballot, some CAs expressed that they couldn't deploy
that, which is why we have an exception for retried failures. This is
exactly why we need those CAs to participate at LAMPS. If deploying
fail-closed CAA is impractical, IETF should acknowledge that and write it
into the next RFC. But that can't happen without LAMPS participation from
CAs that fail open.
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

[cabfpub] Clarification on DNAME erratum

[Jacob Hoffman-Andrews via Public]

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 immediately above
> X in the DNS hierarchy, and A(X) be the target of a CNAME or DNAME
> alias record specified at the label X.

The problem is that DNAME records are not aliases, they are instructions to
generate aliases: https://tools.ietf.org/html/rfc6672#section-3

Andrew's interpretation is that the letter of the RFC says to treat DNAMEs
as direct aliases rather than alias generators, which would mean that the
normal RFC 1034 alias resolution process doesn't work, and additional
DNAME-specific code is needed.

I think there is another reasonable interpretation, which is that "DNAME
alias record" refers to an alias record generated by a DNAME. This results
in the "natural" treatment of DNAMEs and mean the RFC 1034 alias resolution
in off-the-shelf DNS resolvers can be used. This also matches the "CAA
Simplification" draft being discussed at the IETF LAMPS WG.

My question is: Do root programs consider the "natural" interpretation
reasonable?
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Ballot 213 - Revocation Timeline Extension

[Ryan Sleevi via Public]

On Thu, Sep 21, 2017 at 1:38 PM, Gervase Markham  wrote:

> On 20/09/17 01:26, Ryan Sleevi wrote:
> > I appreciate your suggestion of a solution, but I'm not quite sure I
> > understand your concerns. Apologies for that, but it would be great if
> > you could elaborate why you feel it may be "overreaching". I had hoped
> > my explanation provided context how it's both relevant and applicable to
> > the activities of the CA/Browser Forum, and independent of any
> > particular Root Stores perspective.
>
> That was responding to a point made by you; you said it might be
> inappropriate for the CAB Forum to require posting to m.d.s.p. And I
> agree - it's outside the CAB Forum's remit. This is what I meant by the
> "overreaching" I was avoiding. My proposed solution is that the BRs
> require the existence of the report, and the root program requirements
> say where it needs to be placed.
>

Do you see a problem with the BRs requiring it be posted to a CABF list?
That is, could you elaborate on what the advantages are of having multiple
root programs require disclosure versus providing a central clearing house?


> > In this context, I think it's useful to consider what is fundamentally a
> > very simple proposal:
> > - the CA/B Forum can establish a list that allows publishing of such
> reports
> > - The Baseline Requirements require posting such results to that list
>
> I'm ambivalent. It's one more thing for a CA to remember to do, and as
> a root program person who will be requiring them to be sent to me
> anyway, it doesn't add value for me. But I have no strong objection :-)
>

I see - so your position is that even in the existence of a mechanism to
centrally disclose such events, you would still require independent
disclosure?

Would you agree that there is separate value from having a root store
disclosure (which can affect how the root program itself behaves with
respect to a particular member) versus having an open, public disclosure in
a vendor-neutral way (which can allow for improvements to the BRs and
identifying problematic scenarios in a vendor-neutral way)?
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] BRs, EVGLs, and "latest version"

[Frank Corday via Public]

The passing of Ballot 205 also injects further uncertainty for a CA if a 
qualified audit is received.

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Ryan Sleevi via 
Public
Sent: Monday, October 09, 2017 10:20 AM
To: Ben Wilson 
Cc: CA/Browser Forum Public Discussion List 
Subject: Re: [cabfpub] BRs, EVGLs, and "latest version"

You're thinking 
https://aka.ms/auditreqs
 , Section B, I believe.

But if that is the issue, then surely a simpler solution is discussing that 
with Microsoft, rather than proposing that all root programs adopt a stance 
that actually ends up creating significant loopholes.

On Mon, Oct 9, 2017 at 10:27 AM, Ben Wilson 
> wrote:
Ryan,
One issue with the qualified audit,  as was expressed during the face-to-face 
meeting, although I haven’t been able to  find it, is that Microsoft apparently 
requires the WebTrust seal, which is based on an unqualified audit.  If anyone 
can point me to the  requirement, I’d appreciate it.
Thanks,
Ben

From: Public 
[mailto:public-boun...@cabforum.org] On 
Behalf Of Ryan Sleevi via Public
Sent: Monday, October 9, 2017 6:40 AM
To: Gervase Markham >; CA/Browser 
Forum Public Discussion List >
Subject: Re: [cabfpub] BRs, EVGLs, and "latest version"



On Fri, Oct 6, 2017 at 12:07 PM, Gervase Markham via Public 
> wrote:
During the CAB Forum face-to-face in Taipei, it was noted that the BRs
currently state something which implies something which is not true in
practice.

Gerv,

I think it's useful here to distinguish between things which are expected and 
things which are audited. As has been discussed in the Forum for years, the 
audit criteria naturally lag behind the adoption of the BRs - depending on when 
a ballot is adopted, this can be as short as a few months, or as long as a few 
years.

I can think of a number of problems your proposed language would introduce, and 
on that basis, would have difficulty supporting, so it might be useful if you 
could articulate the problem you are trying to solve.

For example, it seems you might be trying to solve what you view as "the CAA 
problem". However, I think it's worth noting that the CAA problem was 
self-inflicted - the Forum had been discussing CAA since 2012, had specifically 
been concerned about potential gotchas and thus introduced the simple mandate 
to require disclosing CAA practices (allowing CAs to gain experience with CAA 
without any risk of BR violations, by virtue of allowing CP/CPS flexibility), 
and then put a CAA requirement 6 months in advance of the actual deadline. The 
issues only manifest because a "deadline" was taken as an "implementation date" 
- that is, all of the flexibility was rejected and deprioritized by CAs, and 
they waited until the last minute.

However, it also seems to be operating on a misguided - and I would argue 
dangerous to the ecosystem - belief that qualified audits represent a fatal 
state. We know, through similar lengthy discussions in the Forum on the nature 
of audits, that not every failure necessarily represents a qualification (as it 
relies on the auditor's opinion as well as the nature of the principles and 
criteria), but we also know that disclosure through audit is far better for the 
ecosystem than relentlessly chasing a 'clean' audit. Indeed, Mozilla's own 
efforts have been to underscore that point - that a qualified audit is not 
fatal - so I admit, it seems somewhat surprising to see you suggest undermining 
both security and the quality of audits in pursuit of unqualified audits.

Could you elaborate on whether there are goals or context that I have missed - 
and the relative value of those goals compared to the ecosystem value? In doing 
so, I'd be happy to elaborate how your proposal would result in less security 
and less transparency, and the ways in which it could be gamed or 
unintentionally overlooked, in a way that would be detrimental to the ecosystem.

Best,
Ryan

___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Ballot 184 - SRVnames

[Gervase Markham via Public]

On 04/10/17 06:38, Jeremy Rowley via Public wrote:
> Probably time to finish this ballot off.  This is the last version I
> have, slightly modified to remove the 822 and other language.  Thoughts?  

Do DNSName name constraints in a TCSC apply to the DNS name part of the
SVRName? I've read section 4 of https://tools.ietf.org/html/rfc4985 but
it doesn't seem clear to me whether the restrictions specced there are a
totally new sort of restriction, or whether they leverage the existing
DNS name restriction abilities for the DNS name part and just add the
ability to also restrict the service name.

Gerv
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

[cabfpub] Spamproofed email addresses

[Gervase Markham via Public]

Just a note to say that email addresses published as the Problem
Reporting Mechanism in the CCADB are now (fairly trivially) spamproofed
in the public reports, as requested at the CAB Forum meeting in Taipei.

See:
https://ccadb-public.secure.force.com/mozilla/CAInformationReport
for examples.

Anyone considering emailing a lot of them at once might want to consider
writing a JS bookmarklet which detects the pattern, changes them back,
and turns them into clickable links ;-)

Gerv
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public