On 18/03/2019 16:42, Corey Bonnell wrote:
Perhaps not very elegant, but you can encode an “allow all issuers” CAA
RRSet by specifying a single iodef CAA record without any
issue/issuewild records in the RRSet, which will probably be treated as
permission to issue for CAs. I say “probably”
be
more restrictive and disallow issuance in this case).
Thanks,
Corey
From: Corey Bonnell
Sent: Monday, March 18, 2019 16:42
To: Hector Martin 'marcan'; Jan Schaumann
Cc: dev-security-policy@lists.mozilla.org
Subject: Re: CAA records on a CNAME
Perhaps not very
On 16/03/2019 10:25, Jan Schaumann via dev-security-policy wrote:
someapp.example.com, over which I have control is a CNAME, so I can't
set a CAA record there. Let's say the CNAME points to
ghs.googlehosted.com.
Your suggestion is to contact Google and ask them to please add a CAA
record to
Corey Bonnell via dev-security-policy
wrote:
> If I recall correctly, there was some discussion in late 2017 in the
> IETF LAMPS WG (the working group producing the successor to the
> current CAA RFC 6844)
Thanks for noting this. Sounds like that's the best group to continue
the discussion
E at
> > someone else, then you're delegating to them control of that name. If they
> > set CAA records on the CNAME target (or if they don't), and those CAA
> > records
> > (or lack thereof) do not represent a functioning configuration, you work
> > with them to cha
Matt Palmer via dev-security-policy
wrote:
> I've read through your posts on this topic several times, and I still don't
> understand the problem you're trying to solve. If you point a CNAME at
> someone else, then you're delegating to them control of that name. If they
> set
with the exception of 'someapp.example.com', for which only Let's
> Encrypt can issue a cert.
I've read through your posts on this topic several times, and I still don't
understand the problem you're trying to solve. If you point a CNAME at
someone else, then you're delegating to the
Ryan Sleevi wrote:
> That is, an issue/issuewild parameter tag with a CA-specific property
> defined by the CA/Browser Forum (or by IETF) that detailed specific
> provisions for certain CNAMEs children.
Hmm, maybe something like
example.com CAA 0 issue "digicert.com"
example.com CAA 0
On Fri, Mar 15, 2019 at 4:40 PM Jan Schaumann via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Ryan Sleevi via dev-security-policy
> wrote:
>
> > I don't think we here will really be able to do anything for this; as you
> > note, this is really a question about
Ryan Sleevi via dev-security-policy
wrote:
> I don't think we here will really be able to do anything for this; as you
> note, this is really a question about fundamental DNS specification, and
> whether or not other records can live along-side a CNAME. That seems like
> it'd be IETF's DNS
On Fri, Mar 15, 2019 at 12:31 PM Jan Schaumann via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> I also think that's reasonable, since any number of services might host
> their apps on the provider's platform, so they likely have a large
> number of CNAME records pointing
Ryan Sleevi wrote:
> I?m not sure I follow - when you go someapp.example.com to
> someapp.thirdparty.example, and they point to somewhere.somecdn.example,
> why is the assumption that somewhere.somecdn.example WOULDN?T place a CAA
> record?
It's been my observation that those systems do not set
I’m not sure I follow - when you go someapp.example.com to
someapp.thirdparty.example, and they point to somewhere.somecdn.example,
why is the assumption that somewhere.somecdn.example WOULDN’T place a CAA
record?
Given that somewhere.somecdn.example has the business relationship with the
CA to
2.4. But per RFC2181,
section 10.1, we already allow e.g. SIG, NXT, and KEY RRs on CNAMEs.
Wouldn't it be prudent to also allow CAA records on a CNAME?
-Jan
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
14 matches
Mail list logo
