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,
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
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
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
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
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.