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” beca
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
Perhap
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 tha
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 in.
On Friday, March 15, 2019 at 9:26:02 PM UTC-4, Jan Schaumann wrote:
> 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
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 CAA records on t
On Fri, Mar 15, 2019 at 05:40:29PM -0400, Jan Schaumann via dev-security-policy
wrote:
> 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.
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 override
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 fundamenta
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 grou
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 t
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 C
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 do
allow CAA RRs on CNAMEs,
which (currently) violates RFC1912, Section 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
