Re: CAA record checking issue

2019-05-11 Thread Nick Lamb via dev-security-policy
On Fri, 10 May 2019 02:05:17 +
Jeremy Rowley via dev-security-policy
 wrote:

> https://bugzilla.mozilla.org/show_bug.cgi?id=1550645
> 
> Anyway, let me know what questions, comments, etc you have.

Thanks Jeremy,

If DigiCert is able to retrospectively achieve confidence that issuance
would have been permitted (because their records are good enough to go
back and see the CAA DNS records that were fetched but not used or at
the least the assessment made of those records at the time) I personally
think there is no need to revoke certificates that were in some sense
legitimately issued. To revoke them in these circumstances seems
perverse.

This also rewards keeping high quality issuance records that let you go
back and understand what went wrong. The BRs mandate some record
keeping, but we definitely don't always see evidence of good quality
record keeping in incident reports (I would count ISRG / Let's Encrypt
here definitely).


If DigiCert turns out not to have the records, or checking isn't done
for whatever reasons then I think all 1053 affected certs should be
revoked, without trying to justify narrowing it down further.

In the margins, e.g. if DigiCert can see that some cases have no CAA,
but in cases with CAA it's not possible to be sure if it would have
permitted issuance, I think we need to ask for all 1053 to be revoked
for consistency rather than making complicated decisions that have the
effect of penalizing some subscribers for doing the Right Thing.


I don't endorse the plan of revoking 16 certs based on CAA information
that's far (perhaps more than 12 months) newer than the issuance, I
don't think this is compatible with the declared philosophy of the CAA
and so it makes the message about what CAA is or is not for too
muddled. Revoking all 1053 makes more sense than revoking 16 on this
basis.


Nick.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


RE: Certificates with subject stateOrProvinceName "Some-State"

2019-05-11 Thread Cristian Garabet via dev-security-policy








Hi Alex,


Thank you for reporting this issue. The certificate has been revoked. We will provide an incident report after the internal investigation is finished.


Kind regards,
Cristian Garabet 
CISO




Sent from my Samsung Galaxy smartphone.



___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Certificates with subject stateOrProvinceName "Some-State"

2019-05-11 Thread Alex Cohn via dev-security-policy
Inspired by Nick Lamb's comment a week or so ago on m.d.s.p about "Default
City" being an OpenSSL default value in CSRs, I ran some more searches on
the OpenSSL defaults and found almost 100 certificates with a
stateOrProvinceName of "Some-State". BR section 7.1.4.2.2(f) requires this
field to be verified if present in a certificate.

Affected CAs are Sectigo, DigiCert, SwissSign, Government of Turkey,
T-Systems, Telia, SecureTrust, and certSIGN.

Here's the batch: https://misissued.com/batch/53/

Alex
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: CAA record checking issue

2019-05-11 Thread Han Yuwei via dev-security-policy
This raised a question:
 How can CA prove they have done CAA checks or not at the time of issue? 

在 2019年5月10日星期五 UTC+8上午10:05:36,Jeremy Rowley写道:
> FYI, we posted this today:
> 
>  
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1550645
> 
>  
> 
> Basically we discovered an issue with our CAA record checking system. If the
> system timed out, we would treat the failure as a DNS failure instead of an
> internal failure. Per the BRs Section 3.2.2:
> 
> "CAs are permitted to treat a record lookup failure as permission to issue
> if: 
> 
> . the failure is outside the CA's infrastructure; 
> 
> . the lookup has been retried at least once; and 
> 
> . the domain's zone does not have a DNSSEC validation chain to the ICANN
> root"
> 
>  
> 
> The failure was not outside our infrastructure so issuance was improper. 
> 
>  
> 
> We checked all the applicable CAA records and found 16 where the CAA record
> would not permit us to issue if we were issuing a new cert today. What we
> are proposing is to revoke these certificates and reissue them (if they pass
> all the proper checks). The rest would pass if we issued today so we were
> going to leave these where they are while disclosing them to the Mozilla
> community. 
> 
>  
> 
> Other suggestions are welcome. 
> 
>  
> 
> The issue was put into the code back when CAA record checking became
> mandatory (Sept 2017).  We generally have a peer review of our code so that
> at least one other developer has looked at the system before release. In
> this case, neither PM nor a second reviewer was involved in the development.
> We've since implemented more stringent development processes, including
> ensuring a PM reviews and brings questions about projects to the compliance
> team. 
> 
>  
> 
> Anyway, let me know what questions, comments, etc you have.
> 
>  
> 
> Thanks!
> 
> Jeremy

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Reported Digicert key compromise but not revoked

2019-05-11 Thread Han Yuwei via dev-security-policy
Thanks for that. So now I should send another email to rev...@digicert.com or 
just wait for revocation? And who should I contact if this address doesn't work?
在 2019年5月10日星期五 UTC+8上午8:26:09,Jeremy Rowley写道:
> No argument from me there. We generally act on them no matter what.
> Typically any email sent to supp...@digicert.com requesting revocation is
> forwarded to rev...@digicert.com. That's the standard procedure. This one
> was missed unfortunately.
> 
> -Original Message-
> From: dev-security-policy  On
> Behalf Of Daniel Marschall via dev-security-policy
> Sent: Thursday, May 9, 2019 4:16 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: RE: Reported Digicert key compromise but not revoked
> 
> I personally do think that it matters to this forum. A CA - no matter what
> kind of certificates it issues - must take revocation requests seriously and
> act immediately, even if the email is sent to the wrong address. If an
> employee at the help desk is unable to forward revocation requests, or needs
> several weeks to reply, then there is something not correct with the CA, no
> matter if the revocation request is related to a web certificate or code
> signing certificate. That's my opinion on this case.
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Certinomis Issues

2019-05-11 Thread okaphone.elektronika--- via dev-security-policy
On Friday, 10 May 2019 19:00:11 UTC+2, Wayne Thayer  wrote:

...

> I share the concern that option #2 sends a confusing message. As Jonathan
> stated, why should we distrust a CA for all but the most important websites
> they secure?
 
I'd say that both "too big to fail" and "too important to fail" are not 
particularly good reasons for trusting something/somebody.

It's understandable that as a browser you'd want to limit the collateral damage 
of distrusting a CA, but your first priority should definitely be limiting the 
possible damage from trusting a CA that has turned out not to be trustworthy.

CU Hans
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy