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,
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
While I realize the thinking is with regards to the recent serial number
issue, a few questions emerge:
1) Based on the software vendor reporting, they don’t view this as a
software defect, but a CA misconfiguration. Do you believe the current
policy, as worded, addresses that ambiguity?
2)
As I mentioned last week [1], the "serial number entropy" issue has
identified some improvements that could be made to Mozilla's guidance for
CAs on revocation when responding to an incident. These are relatively
minor clarifications and in no way do they represent a fundamental change
in our
On Fri, Mar 15, 2019, at 10:58, bstephens822--- via dev-security-policy wrote:
> On Wednesday, February 27, 2019 at 10:28:00 AM UTC-5,
> michel.le...@gmail.com wrote:
> > Hello,
> >
> > I noticed this certificate
> > https://crt.sh/?id=1231965201=cablint,x509lint,zlint that has an
> > invalid
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
> Lastly, it was identified\discussed since we were STARTING with 64bits it was
> acceptable. Therefore, GoDaddy was in compliance prior to 3/7. After this
> discussion we changed back to the pre 3/7 configuration on 3/13.
Thanks for the additional explanation, greatly appreciated.
>From
On Friday, March 15, 2019 at 12:53:15 PM UTC-7, Daymion Reynolds wrote:
> On Friday, March 15, 2019 at 12:45:39 PM UTC-7, Ryan Sleevi wrote:
> > On Fri, Mar 15, 2019 at 3:35 PM Daymion Reynolds via dev-security-policy <
> > dev-security-policy@lists.mozilla.org> wrote:
> >
> > > > On Wednesday,
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
To echo Tim's remarks, this is really two issues:
1) A failure of controls (the current incident report)
2) A failure to revoke
I'm rather concerned about #2 and the lack of detail presently provided
regarding it, as well as the one week wait to filing the incident report
for #1.
What is the rationale for waiting until March 20th for revocation given that
the issue was noticed on March 7th?
-Tim
> -Original Message-
> From: dev-security-policy
On
> Behalf Of Bruce via dev-security-policy
> Sent: Friday, March 15, 2019 4:59 PM
> To:
On March 7, 2019, Entrust Datacard discovered that SSL certificates with the
wrong Organization value were issued to a customer. The investigation was
completed 15 March 2019.
Details of the incident report can be found here,
https://bugzilla.mozilla.org/show_bug.cgi?id=1535735.
All
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
On Friday, March 15, 2019 at 12:45:39 PM UTC-7, Ryan Sleevi wrote:
> On Fri, Mar 15, 2019 at 3:35 PM Daymion Reynolds via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > > On Wednesday, March 13, 2019 at 8:17:00 PM UTC-4, Daymion Reynolds wrote:
> > >
> > > > In
On Fri, Mar 15, 2019 at 3:35 PM Daymion Reynolds via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> > On Wednesday, March 13, 2019 at 8:17:00 PM UTC-4, Daymion Reynolds wrote:
> >
> > > In accordance with our conversations to date, prior to 3/7 6:30pm AZ
> we utilized raw
On Friday, March 15, 2019 at 12:35:47 PM UTC-7, Daymion Reynolds wrote:
> On Friday, March 15, 2019 at 12:25:37 PM UTC-7, ad...@adamcaudill.com wrote:
> > Daymion,
> >
> > (Apologies in advance if I've missed something that led to these results.
> > These results rely on the crt.sh database,
On Friday, March 15, 2019 at 12:25:37 PM UTC-7, ad...@adamcaudill.com wrote:
> Daymion,
>
> (Apologies in advance if I've missed something that led to these results.
> These results rely on the crt.sh database, which I will admit to being less
> familiar with than I would like.)
>
> While
Daymion,
(Apologies in advance if I've missed something that led to these results. These
results rely on the crt.sh database, which I will admit to being less familiar
with than I would like.)
While recently looking at some randomly selected recent certificates from this
CA:
On Fri, Mar 15, 2019 at 8:54 AM Andrew via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Perhaps the solution should be to amend the BRs to allow for more flexible
> handling of situations such as this.
>
>
After a long debate, the BR revocation requirements were recently
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
Perhaps the solution should be to amend the BRs to allow for more flexible
handling of situations such as this.
I understand that'd be rather difficult to formalize, since we can't just trust
the CAs to decide for themselves when mass revocation doesn't make sense (as
they have a vested
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
I think open source is great, but it's not a panacea.
While there are many CAs and several root programs, this community is a
relatively small one in the grand scheme.
Prior events suggest that there are not enough people with the necessary
skill overlap to parse both the rules and the code to
Hello,
While this is at its core a DNS question, since it's about CAA records
and cert issuance, I thought to post it here as well. If this is viewed
as off-topic, my apologies.
It seems to me that the behavior in combination with CNAMEs is
suboptimal at best. I believe we need to allow CAAs to
On Thursday, March 14, 2019 at 11:54:52 PM UTC+1, James Burton wrote:
> Let's Encrypt CA software 'Boulder' is open source for everyone to browse
> and check for issues. All other CAs should follow the Let's Encrypt lead
> and open source their own CA software for everyone to browse and check for
On Wednesday, February 27, 2019 at 10:28:00 AM UTC-5, michel.le...@gmail.com
wrote:
> Hello,
>
> I noticed this certificate
> https://crt.sh/?id=1231965201=cablint,x509lint,zlint that has an invalid
> domain `mail.xinhua08.con` in SANs. This looks like a typo and
> `mail.xinhua08.com` is
Hi,
It might have been found, but there's a good chance it would have been bypassed
anyhow. Since it was not a bug in the code, you would have to had analyzed it
in the context of the discussions around b164, which I think there are probably
very few people who could/would. I may be wrong, and
29 matches
Mail list logo
