from:"Jeremy Rowley via dev\\\\\\\-security\\\\\\\-policy"

Re: Misissued/Suspicious Symantec Certificates

2017-02-22 Thread Jeremy Rowley via dev-security-policy

Webtrust doesn't have audit criteria for RAs so the audit request may produce 
interesting results. Or are you asking for the audit statement covering the 
root that the RA used to issue from? That should all be public in the Mozilla 
database at this point.

> On Feb 22, 2017, at 8:33 PM, Ryan Sleevi via dev-security-policy 
>  wrote:
> 
> Hi Steve,
> 
> Thanks for your continued attention to this matter. Your responses open
> many new and important questions and which give serious question as to
> whether the proposed remediations are sufficient. To keep this short, and
> thereby allow Symantec a more rapid response:
> 
> 1) Please provide the CP, CPS, and Audit Letter(s) used for each RA partner
> since the acquisition by Symantec of the VeriSign Trust Services business
> in 2010.
> 
> 
> 
> On Fri, Feb 17, 2017 at 8:32 PM, Steve Medin via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
>> Our third response to questions, including these two below, is posted at
>> Bugzilla, and directly at https://bug1334377.
>> bmoattachments.org/attachment.cgi?id=8838825.
>> 
>> 
>> 
>> 
>> 
>> From: Ryan Sleevi [mailto:r...@sleevi.com]
>> Sent: Friday, February 17, 2017 6:54 PM
>> To: Ryan Sleevi 
>> Cc: Gervase Markham ; mozilla-dev-security-policy@
>> lists.mozilla.org; Steve Medin 
>> Subject: Re: Misissued/Suspicious Symantec Certificates
>> 
>> 
>> 
>> Hi Steve,
>> 
>> 
>> 
>> Two more question to add to the list which is already pending:
>> 
>> 
>> 
>> In [1], in response to question 5, Symantec indicated that Certisign was a
>> WebTrust audited partner RA, with [2] provided as evidence to this fact.
>> While we discussed the concerns with respect to the audit letter,
>> specifically in [3], questions 3 - 6, and while Symantec noted that it
>> would case to accept future EY Brazil audits, I have confirmed with CPA
>> Canada that at during the 2016 and 2017 periods, EY Brazil was not a
>> licensed WebTrust practitioner, as indicated at [4].
>> 
>> 
>> 
>> Given that EY Brazil was not a licensed WebTrust auditor, it appears that
>> Symantec failed to uphold Section 8.2 of the Baseline Requirements, v1.4.1
>> [5], namely, that "(For audits conducted in accordance with the WebTrust
>> standard) licensed by WebTrust", which is a requirement clearly articulated
>> in Section 8.4 of the Baseline Requirements, namely, that "If the CA is not
>> using one of the above procedures and the Delegated Third Party is not an
>> Enterprise RA, then the CA SHALL obtain an audit report, issued under the
>> auditing standards that underlie the accepted audit schemes found in
>> Section 8.1, ..."
>> 
>> 
>> 
>> 1) Was Symantec's compliance team involved in the review of Certisign's
>> audit?
>> 
>> 2) Does Symantec agree with the conclusion that, on the basis of this
>> evidence, Symantec failed to uphold the Baseline Requirements, independent
>> of any action by a Delegated Third Party?
>> 
>> 
>> 
>> [1] https://bug1334377.bmoattachments.org/attachment.cgi?id=8831933<
>> https://clicktime.symantec.com/a/1/6wJmuz5H2ktURSIGjev34ZuuQTad1L
>> RVz1nIlADR7XE=?d=EzdV7X-pe5sih3AYTnIMlzBIT3AaPBWIYQF9w
>> d5LbpGrImaYYowG0inKiozTFwfAeJMk8B2dt_4yENjH4IaBlGSfv3Nbn8GMpSPDtntA
>> Wmyx8q3PfDYHHU_bDfrHZGtmC5XInqf0-ck-FF9e6SGtIxb23Mc2kGZNy8eGAG1jAT
>> 1TAe21ybqhXxIvmlxFXmTHtVMR3YXXvHPdAlcwv8e83_rm24C4_wUeNtE5oJFsBljHikK-
>> 4oZ1OAUbs4kCgGUxt8cWaB75e0ZDlR_fb71_91rphEjG44uTwcWMGyYK07gsGTyfvK
>> sUrvka6LTCQoX9d09q2fHeLb5TL3SPWUKa6B9_V5GfWubr-0rIMxR7-
>> kT2QzmMrkTgl2YGGDT-rtrKWSZ_xCOsOuU3sp_ARcYoRPNHR1FUGD8%
>> 3D=https%3A%2F%2Fbug1334377.bmoattachments.org%2Fattachment.cgi%3Fid%
>> 3D8831933>
>> 
>> [2] https://bug1334377.bmoattachments.org/attachment.cgi?id=8831929<
>> https://clicktime.symantec.com/a/1/pfZiLBH0rxpzxfeiB5YSfvWdOjwpHC
>> 72M_rUahZJxKQ=?d=EzdV7X-pe5sih3AYTnIMlzBIT3AaPBWIYQF9w
>> d5LbpGrImaYYowG0inKiozTFwfAeJMk8B2dt_4yENjH4IaBlGSfv3Nbn8GMpSPDtntA
>> Wmyx8q3PfDYHHU_bDfrHZGtmC5XInqf0-ck-FF9e6SGtIxb23Mc2kGZNy8eGAG1jAT
>> 1TAe21ybqhXxIvmlxFXmTHtVMR3YXXvHPdAlcwv8e83_rm24C4_wUeNtE5oJFsBljHikK-
>> 4oZ1OAUbs4kCgGUxt8cWaB75e0ZDlR_fb71_91rphEjG44uTwcWMGyYK07gsGTyfvK
>> sUrvka6LTCQoX9d09q2fHeLb5TL3SPWUKa6B9_V5GfWubr-0rIMxR7-
>> kT2QzmMrkTgl2YGGDT-rtrKWSZ_xCOsOuU3sp_ARcYoRPNHR1FUGD8%
>> 3D=https%3A%2F%2Fbug1334377.bmoattachments.org%2Fattachment.cgi%3Fid%
>> 3D8831929>
>> 
>> [3] https://bug1334377.bmoattachments.org/attachment.cgi?id=8836487<
>> https://clicktime.symantec.com/a/1/80dDdC7HC5yMdzxfwRS0saqQ2kS5Tv
>> wuo_kNWaXWLCI=?d=EzdV7X-pe5sih3AYTnIMlzBIT3AaPBWIYQF9w
>> d5LbpGrImaYYowG0inKiozTFwfAeJMk8B2dt_4yENjH4IaBlGSfv3Nbn8GMpSPDtntA
>> Wmyx8q3PfDYHHU_bDfrHZGtmC5XInqf0-ck-FF9e6SGtIxb23Mc2kGZNy8eGAG1jAT
>> 1TAe21ybqhXxIvmlxFXmTHtVMR3YXXvHPdAlcwv8e83_rm24C4_wUeNtE5oJFsBljHikK-
>> 4oZ1OAUbs4kCgGUxt8cWaB75e0ZDlR_fb71_91rphEjG44uTwcWMGyYK07gsGTyfvK
>> sUrvka6LTCQoX9d09q2fHeLb5TL3SPWUKa6B9_V5GfWubr-0rIMxR7-
>>

Re: Misissued/Suspicious Symantec Certificates

2017-02-22 Thread Jeremy Rowley via dev-security-policy

I am aware of the requirements but am interested in seeing how an RA that 
doesn't have their own issuing cert structures the audit report. It probably 
looks the same, but I've never seen one (unless that is the case with the 
previously provided audit report).

On Feb 22, 2017, at 8:48 PM, Ryan Sleevi 
> wrote:

On Wed, Feb 22, 2017 at 8:36 PM, Jeremy Rowley 
> wrote:
Webtrust doesn't have audit criteria for RAs so the audit request may produce 
interesting results. Or are you asking for the audit statement covering the 
root that the RA used to issue from? That should all be public in the Mozilla 
database at this point.

Hi Jeremy,

I believe the previous questions already addressed this, but perhaps I've 
misunderstood your concern.

"Webtrust doesn't have audit criteria for RAs so the audit request may produce 
interesting results."

Quoting the Baseline Requirements, v.1.4.2 [1] , Section 8.4
"If the CA is not using one of the above procedures and the Delegated Third 
Party is not an Enterprise RA, then the
CA SHALL obtain an audit report, issued under the auditing standards that 
underlie the accepted audit schemes
found in Section 8.1, that provides an opinion whether the Delegated Third 
Party's performance complies with
either the Delegated Third Party's practice statement or the CA's Certificate 
Policy and/or Certification Practice
Statement. If the opinion is that the Delegated Third Party does not comply, 
then the CA SHALL not allow the
Delegated Third Party to continue performing delegated functions. "

Note that Symantec has already provided this data for the four RA partners 
involved for the 2015/2016 (varies) period, at [2]. Specifically, see the 
response to Question 5 at [3].

"Or are you asking for the audit statement covering the root that the RA used 
to issue from? That should all be public in the Mozilla database at this point."

Again, referencing Question 5 at [3], and the overall topic of the thread, no, 
I am not asking for the audit statement covering the root that the RA used to 
issue from. I'm asking for the audit report, issued under the auditing 
standards that underlie the accepted audit schemes found in Section 8.1, that 
provides an opinion whether the Delegated Third Party's performance complies 
with either the Delegated Third Party's practice statement or the CA's 
Certificate Policy and/or Certification Practice Statement.

[1] https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.4.2.pdf
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1334377
[3] https://bug1334377.bmoattachments.org/attachment.cgi?id=8831933
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: (Possible) DigiCert EV Violation

2017-02-27 Thread Jeremy Rowley via dev-security-policy

I was just going to respond with something similar.

Appendix F:
"A CA may issue an EV Certificate with .onion in the right-most label of the 
Domain Name provided
that issuance complies with the requirements set forth in this Appendix:
1. CAB Forum Tor Service Descriptor Hash extension (2.23.140.1.31) The CAB 
Forum has created an
extension of the TBSCertificate for use in conveying hashes of keys related to 
.onion addresses. The
Tor Service Descriptor Hash extension has the following format:
cabf-TorServiceDescriptor OBJECT IDENTIFIER ::= { 2.23.140.1.31 }
TorServiceDescriptorSyntax ::=
SEQUENCE ( 1..MAX ) of TorServiceDescriptorHash
TorServiceDescriptorHash:: = SEQUENCE {
onionURI UTF8String
algorithm AlgorithmIdentifier
subjectPublicKeyHash BIT STRING
}
Where the AlgorithmIdentifier is a hashing algorithm (defined in RFC 6234) 
performed over the DERencoding
of an ASN.1 SubjectPublicKey of the .onion service and SubjectPublicKeyHash is 
the hash
output."

The requirements don't specify what to do with this information. I know our 
product team interpreted this as part of the validation methods and exchange of 
key information, not something that was included in a certificate. We can 
include this information, but the guidelines are unclear what we do with this. 

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org]
 On Behalf Of Peter Bowen via dev-security-policy
Sent: Monday, February 27, 2017 3:12 PM
To: Ryan Sleevi 
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: (Possible) DigiCert EV Violation

On Mon, Feb 27, 2017 at 1:41 PM, Ryan Sleevi via dev-security-policy 
 wrote:
> The EV Guidelines require certificates issued for .onion include the 
> cabf-TorServiceDescriptor extension, defined in the EV Guidelines, as part of 
> these certificates. This is required by Section 11.7.1 (1) of the EV 
> Guidelines, reading: "For a Certificate issued to a Domain Name with .onion 
> in the right-most label of the Domain Name, the CA SHALL confirm that, as of 
> the date the Certificate was issued, the Applicant’s control over the .onion 
> Domain Name in accordance with Appendix F. "

I don't see anything requiring this extension to be included in certificates. 
(hat tip to Andrew Ayer for noticing the lack of
requirement)

> The intent was to prevent collisions in .onion names due to the use of a 
> truncated SHA-1 hash collision with distinct keys, as that would allow two 
> parties to respond on the hidden service address using the same key.
>
> Last week, a SHA-1 collision was announced.
>
> In examining the .onion precertificates DigiCert has logged, available at 
> https://crt.sh/?q=facebookcorewwwi.onion , I could not find a single one 
> bearing this extension, which suggests these are all misissued certificates 
> and violations of the EV Guidelines.
>
> During a past discussion of precertificates, at 
> https://groups.google.com/d/msg/mozilla.dev.security.policy/siHOXppxE9k/0PLPVcktBAAJ
>  ,  Mozilla did not discuss whether or not it considered precertificates 
> misissuance, although one module peer (hi! it's me!) suggested they were.
>
> This interpretation seems consistent with the discussions during the WoSign 
> issues, as some of those certificates examined were logged precertificates.
>
> Have I missed something in examining these certificates? Am I correct that 
> they appear to be violations?
> ___
> 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

smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: DRAFT - BR Self Assessments

2017-03-29 Thread Jeremy Rowley via dev-security-policy

Hi Kathleen, 

This is a good idea, and I like the phased-in approach. The mapping exercise
is similar to how other communities evaluate inclusion requests and makes it
more apparent how the CA is complying with the various Mozilla requirements.
An extension on this could be to have CAs annually file an updated mapping
with their WebTrust audit. That way it's a reminder that the CA needs to
notify Mozilla of changes in their process and keeps the CAs thinking about
updating practices to stay in-line with  the baseline requirements. Plus, a
practice like that would provide better notice to the public on CA policy
changes and how CAs are responding to new threats.

Jeremy

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Kathleen Wilson via dev-security-policy
Sent: Wednesday, March 29, 2017 11:55 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: DRAFT - BR Self Assessments

All,

As mentioned in the GDCA discussion[1], I would like to add a step to
Mozilla's CA Inclusion/Update Request Process[2] in which the CA performs a
self-assessment about their compliance with the CA/Browser Forum's Baseline
Requirements.

A draft of this new step is here:
https://wiki.mozilla.org/CA:BRs-Self-Assessment

It includes a link to a template for CA's BR Self Assessment, which is a
Google Doc:
https://docs.google.com/spreadsheets/d/1ni41Czial_mggcax8GuCBlInCt1mNOsqbEPz
ftuAuNQ/edit?usp=sharing

Here's how I am considering introducing this new step. Of course, this only
applies to CAs who are requesting the Websites trust bit.

+ For the CAs currently in the queue for discussion, I would ask them to
perform this BR Self Assessment before I would start their discussion.

+ For CAs currently in the Information Verification phase, I would ask them
to perform this BR Self Assessment before we would continue with Information
Verification.

+ For new requests, we would have the BR Self Assessment be the very first
step.


I would greatly appreciate your feedback on adding this step to the root
inclusion/update process, the wiki page draft, and the template.


Thanks,
Kathleen

[1]
https://groups.google.com/d/msg/mozilla.dev.security.policy/kB2JrygK7Vk/Kk7L
e2F7CQAJ
[2] https://wiki.mozilla.org/CA

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


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Mozilla Root Store Policy 2.4.1

2017-03-17 Thread Jeremy Rowley via dev-security-policy

Given that the patent disclosures have been withdrawn, the proposed changes
in ballot 190, and that the validation working group will be working on a
revised ballot for the remaining methods during the face to face, could
Action 1 include methods added/revised in ballots adopted after 1.4.1? That
way the CAs can introduce the revised methods rather than only the methods
in 1.4.1 as written.  

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Gervase Markham via dev-security-policy
Sent: Friday, March 17, 2017 9:41 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Mozilla Root Store Policy 2.4.1

On 06/03/17 15:10, Gervase Markham wrote:
> The next stage in the improvement of the Mozilla Root Store Policy is
> version 2.4.1. This is version 2.4, but rearranged significantly to
> have a more topic-based ordering and structure to it. I have also made
> editorial changes to clean up and clarify language, and improved the
> Markdown markup.

Thanks to Ryan for reviewing this, and I need to come back to his comments.
If anyone else has time to look through it, I would be most grateful. CAs:
this is worth your time, because you don't want a new normative requirement
sprung on you accidentally! ;-)

Gerv

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

smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Symantec: Next Steps

2017-03-16 Thread Jeremy Rowley via dev-security-policy

We have DTP and RA roles slated as part of the validation WG discussion, but
only as they relate to validation. 

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Ryan Sleevi via dev-security-policy
Sent: Thursday, March 16, 2017 7:16 AM
To: Gervase Markham 
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Symantec: Next Steps

On Thu, Mar 16, 2017 at 6:01 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 09/03/17 13:32, Ryan Sleevi wrote:
> > (Wearing Google hat only for this statement) Have you considered 
> > having this discussion in the CA/Browser Forum?
> Google
> > had planned to discuss this very topic at our upcoming F2F about how 
> > to address this, and would be very interested in collaborating with 
> > Mozilla
> on
> > this. I mentioned this recently to Kathleen at the WebTrust TF 
> > meetings, but apologies for not mentioning to you as well.
>
> This sounds like a good idea. Do we want to get this added in an open 
> slot? There may still be time.
>

Unconference future discussion. If CAs aren't interested in it, and it
doesn't get discussed, then that seems like a suitable signal to discuss in
the browser policies, doesn't it?

> > I don't understand why you
> > believe it's relevant the act of "Mozilla requiring disclosure of 
> > the audits". Can you help me understand where, in the policy, that's
> required?
>
> I'm not sure where your text in quotes comes from, and nor can I work 
> out the referent of "it", so I don't understand this question.
>

The quoted text was attempting to summarize the following paragraph from
you:

"""No, because in the case of a sub-CA, we require audits. And when we
receive them, if they were done by unqualified parties, the CA would need to
flag that, and we would make a judgement about that party's suitability at
the time. The issue here arises that, because of the way things are set up,
these RA's audits were not submitted to Mozilla, and so Symantec didn't have
to resolve the Schrodinger's Cat of (qualified|not qualified and need us to
make a judgement)."""

The question here is that it seems you have hinged the
acceptability/unacceptability of the auditor on the basis of whether or not
it was required to be disclosed.

Or, put differently, it sounds as if you suggest the only obligation a CA
has to ensure their DTP auditors are qualified for the task at hand is if,
and only if, Mozilla requests those audits. In the absence of that request,
the CA is allowed to make their own individual determination. Further, it
seems that you are suggesting that if a CA makes that determination, and
it's incorrect, that's not a failure upon the CAs part, because they made 'a
decision', and the relevant portions of Mozilla policy only apply to the
'next' audit.

In effect, it makes the question of 'qualified' auditor one which can never
look retrospectively to prevent issues or instill a duty of care, and it
only applies forward thinking, to the 'next' audits. Or, put differently, it
sounds as if you're suggesting that Symantec, having made a determination of
qualified without input from Mozilla, has sufficiently abided by Mozilla's
policy.

I'm not sure that's a consistent read with the goals or policy stated.
Rather, by making that determination without input from Mozilla, Symantec
has instead taken on full liability for that audit. If, as in this case,
evidence appears that suggests the auditor is not qualified, then the root
issue rests with Symantec for not ensuring that the auditor was qualified.
Similarly, all other CAs who are accepting audits from third-parties
(whether DTPs or sub-CAs), and which are not ensuring those meet the
definition of qualified, similarly accept risk of violation. That risk can
be mitigated - for example, showing that the auditor is appropriately
licensed at the time they conducted the audit, rejecting audits that are
clearly problematic - but it's a risk born through exercising the capability
to delegate.

Put one last way (since this is such a thorny issue), I read your reply in
the above quoted text to say "Mozilla requires that the CA make a decision.
But it doesn't have to be a right one, and it doesn't have to use the same
data we would." I'm trying to push back on that, which is every CA has an
obligation to make the Right Decision - they have the tools at their
disposal to do so, but uncertainty or perceived risk can and should only be
mitigated by public consultation before - not after.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org

RE: Next CA Communication

2017-03-20 Thread Jeremy Rowley via dev-security-policy

I only understand this "independent validation of domain control" because
I'm on the thread. I don't think CAs who aren't actively involved will
understand what it means. DigiCert has an RA. It's DigiCert.  We validate
our certificate orders and submit them to the CA for issuance. I think it
should be clarified that this is referencing a) third-party RAs and b) where
the CA relies on the RA to perform the domain validation function required
under the Baseline Requirements. 

Something like: "Does your CA have any third-party Registration Authority
(RA)s program that the CA relies on to perform the domain validation
required under Section 3.2.2.4 of the Baseline Requirements."

Jeremy

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Kathleen Wilson via dev-security-policy
Sent: Monday, March 20, 2017 2:29 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Next CA Communication

On Monday, March 20, 2017 at 10:59:41 AM UTC-7, Peter Bowen wrote:
> On Mon, Mar 20, 2017 at 10:43 AM, Jeremy Rowley via
> > [JR] This should be limited to SSL certs IMO. With client certs, 
> > you're going to get a lot more RAs that likely function under the 
> > standard or legal framework defining the certificate type.
> 
> What if the question was scoped to "RAs that can do independent 
> validation of domain control" or some such?  e.g. a classic "Enteprise 
> RA" set up where the CA's in-house RA confirms control of a public 
> suffix and then allows the Enterprise to internally confirm 
> certificate requests under the validated domain should not be counted 
> here.

updated

See action 9 here:
https://mozilla-mozillacaprogram.cs54.force.com/Communications/CACommunicati
onSurveySample?CACommunicationId=a050S00G3K2

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


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Symantec Response B

2017-04-12 Thread Jeremy Rowley via dev-security-policy

I am curious about the software requiring the 1024 bit cert off the root.
The dates of mis-issuance are 2013-2014, which is still early in adoption of
the BRs. At that time, the scope of the BRs was confusing and lead to lots
of discussions. Although the term "intended to be used for authenticating
servers" is still the scope of the BRs, everyone seems to agree that this
means all certs with serverAuth are included. This was not the case in 2013.

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Ryan Sleevi via dev-security-policy
Sent: Wednesday, April 12, 2017 6:40 AM
To: Kurt Roeckx 
Cc: mozilla-dev-security-policy

Subject: Re: Symantec Response B

On Wed, Apr 12, 2017 at 4:24 AM, Kurt Roeckx via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> I don't think 2) applies. It's only their software, that obviously 
> can't be updated yet, and so won't enforce such limit. That doesn't 
> prevent the rest of us to set such limit.
>

Hi Kurt,

I appreciate that you're engaged and offering your thoughts. I would
appreciate, however, if you allowed Steve to respond on behalf of Symantec.
I do not agree with your conclusions or interpretation of matters, but more
importantly, the questions are for Symantec. #2 absolutely applies as a
principle.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Symantec Response B

2017-04-13 Thread Jeremy Rowley via dev-security-policy

Because the certificate improperly included Symantec's BR-compliance OID. If
the cert wasn't a BR-covered certificate but included the BR compliance OID,
then the cert was still mis-issued and should be disclosed.

Jeremy 

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Gervase Markham via dev-security-policy
Sent: Thursday, April 13, 2017 7:49 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Symantec Response B

Symantec's bug opens with the words:

"At the end of 2013, Symantec issued a cert to one of its customers that did
not comply with several provisions of the CA/Browser Forum Baseline
Requirements."[0]

So Symantec, at least, thought that this cert fell under the BRs. If their
case was that it did not, why did they feel a need to report?

Gerv

[0] https://bugzilla.mozilla.org/show_bug.cgi?id=966350
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: CA Validation quality is failing

2017-04-19 Thread Jeremy Rowley via dev-security-policy

I’m looking into it right now. I’ll report back shortly. 

 

Jeremy

 

From: Ryan Sleevi [mailto:r...@sleevi.com] 
Sent: Wednesday, April 19, 2017 2:25 PM
To: Mike vd Ent 
Cc: mozilla-dev-security-policy 
; Jeremy Rowley 
; Ben Wilson 
Subject: Re: CA Validation quality is failing

 

 

 

On Wed, Apr 19, 2017 at 3:47 PM, Mike vd Ent via dev-security-policy 
 > wrote:

Ryan,

My answers on the particular issues are stated inline.
But the thing I want to address is how could (in this case Digicert) validate 
such data and issues certificates? I am investigation more of them and afraid 
even linked company names or registration numbers could be false. Shouldn't 
those certificates be revoked?

 

You are correct that it appears these certificates should not have issued. 
Hopefully Jeremy and Ben from DigiCert can comment on this thread ( 
https://groups.google.com/d/msg/mozilla.dev.security.policy/DgeLqKMzIds/ig8UmHT2DwAJ
 for the archive) with details about the issues and the steps taken.



smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Certificate issues

2017-04-18 Thread Jeremy Rowley via dev-security-policy

Hi everyone,

 

On Friday at 1:00 pm, we accidently introduced a bug into our issuance
system that resulted in five serverAuth-code signing certificates that did
not comply with the Baseline Requirements.  The change modified a handful of
code signing certificates into a pseudo- SSL profile. Because they were
intended to be code signing certificates, the certificates issued off a
code-signing intermediate (with code-signing as the sole EKU). The
certificates contain a servauth EKU despite the intermediate's EKU
restriction. The certificates also lack a domain name. Instead, the CN and
dNSName include the code signing applicant's name.  Because the certs lack a
domain name and there is an EKU mismatch between the issuer and end entity
certs, the certs can't be misused. 

 

Our systems detected the issue shortly after the change. We corrected the
code, and revoked the certificates. We already scanned our entire
certificate database to ensure these are only the certificates affected by
the bug.  

 

The certificates in question are:

* 02CD2F16F3CA4FCC7378C917FFD5F6A0

* 09A88902AF0698841167E814DB8B3FB8

* 0D7C350D52821BFD2326270B9215DCE5

* 0356D3A74CFA29BB5E65569E0532F134

* 089FBE93D335ADB8BDFCDCF492083B68

 

The bug was introduced, ironically, in code we deployed to detect potential
errors in cert profiles. This error caused the specified code signing
certificates to think they needed dNSnames and serverAuth. Let me know if
you have questions. 

 

Thanks,

Jeremy 

 

 

 



smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Certificate issues

2017-04-18 Thread Jeremy Rowley via dev-security-policy

Okay - they are all logged to both Google's CT log and DigiCert's CT log. I
can also send the PEM files shortly.

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Gervase Markham via dev-security-policy
Sent: Tuesday, April 18, 2017 10:59 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Certificate issues

On 18/04/17 17:22, Ryan Sleevi wrote:
> On Tue, Apr 18, 2017 at 12:09 PM, Jeremy Rowley via 
> dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
>> code signing certificates into a pseudo- SSL profile. Because they 
>> were intended to be code signing certificates, the certificates 
>> issued off a code-signing intermediate (with code-signing as the sole
EKU).

If this is true, I am not particularly concerned. So as Ryan notes, a
demonstration of this fact would satisfy me that this was not a serious
incident. Thank you for reporting it so promptly.

Gerv

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


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Certificate issues

2017-04-18 Thread Jeremy Rowley via dev-security-policy

They are not currently logged to CT (because they were supposed to be code 
signing certificates). We can add them to our log though.



Jeremy



From: Ryan Sleevi [mailto:r...@sleevi.com]
Sent: Tuesday, April 18, 2017 10:22 AM
To: Jeremy Rowley <jeremy.row...@digicert.com>
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Certificate issues







On Tue, Apr 18, 2017 at 12:09 PM, Jeremy Rowley via dev-security-policy 
<dev-security-policy@lists.mozilla.org 
<mailto:dev-security-policy@lists.mozilla.org> > wrote:

Hi everyone,



On Friday at 1:00 pm, we accidently introduced a bug into our issuance
system that resulted in five serverAuth-code signing certificates that did
not comply with the Baseline Requirements.  The change modified a handful of
code signing certificates into a pseudo- SSL profile. Because they were
intended to be code signing certificates, the certificates issued off a
code-signing intermediate (with code-signing as the sole EKU). The
certificates contain a servauth EKU despite the intermediate's EKU
restriction. The certificates also lack a domain name. Instead, the CN and
dNSName include the code signing applicant's name.  Because the certs lack a
domain name and there is an EKU mismatch between the issuer and end entity
certs, the certs can't be misused.



Our systems detected the issue shortly after the change. We corrected the
code, and revoked the certificates. We already scanned our entire
certificate database to ensure these are only the certificates affected by
the bug.



The certificates in question are:

* 02CD2F16F3CA4FCC7378C917FFD5F6A0

* 09A88902AF0698841167E814DB8B3FB8

* 0D7C350D52821BFD2326270B9215DCE5

* 0356D3A74CFA29BB5E65569E0532F134

* 089FBE93D335ADB8BDFCDCF492083B68



The bug was introduced, ironically, in code we deployed to detect potential
errors in cert profiles. This error caused the specified code signing
certificates to think they needed dNSnames and serverAuth. Let me know if
you have questions.



Thanks,

Jeremy



Thanks for posting this, Jeremy.



Are these certificates logged to Certificate Transparency? While not wanting 
to suggest I'm doubting you, being able to demonstrate that all intermediates 
they chain to are restricted from the serverAuth EKU is useful.



I realize that's asking you to go above and beyond what you've disclosed so 
far. I think if/once we can add clarity to the Baseline Requirements regarding 
the scope, it would likely be clearer that these would be out of scope of the 
Baseline Requirements, and thus any such disclosure only be relative to root 
programs that recognize those paths as code-signing capable.





smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: CA Validation quality is failing

2017-04-19 Thread Jeremy Rowley via dev-security-policy

That was changed in ballot 127.

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Kurt Roeckx via dev-security-policy
Sent: Wednesday, April 19, 2017 5:54 PM
To: Peter Gutmann 
Cc: Ryan Sleevi ;
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: CA Validation quality is failing

On Wed, Apr 19, 2017 at 10:41:33PM +, Peter Gutmann via
dev-security-policy wrote:
> Kurt Roeckx via dev-security-policy
 writes:
> 
> >Both the localityName and stateOrProvinceName are Almere, while the 
> >province is Flevoland.
> 
> How much checking is a CA expected to do here?  I know that OV and DV 
> certs are just "someone at this site responded to email" or whatever, 
> but for an EV cert how much further does the CA actually have to go?

For the EV cert we got we got a phone call asking if she could speak to
someone else to confirm that he works there.

That also wasn't what I expected. I expected that they would at least check
that he has the authority to do so, like asking the CEO.

(It was a code sign certificate, but I expect if it's labeled EV that the
same things apply.)


Kurt

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


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: CA Validation quality is failing

2017-04-19 Thread Jeremy Rowley via dev-security-policy

FYI - still looking into this. I should have a report tomorrow. 

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org]
 On Behalf Of Jeremy Rowley via dev-security-policy
Sent: Wednesday, April 19, 2017 2:27 PM
To: r...@sleevi.com; Mike vd Ent <pasarellaph...@gmail.com>
Cc: Ben Wilson <ben.wil...@digicert.com>; mozilla-dev-security-policy 
<mozilla-dev-security-pol...@lists.mozilla.org>
Subject: RE: CA Validation quality is failing

I’m looking into it right now. I’ll report back shortly. 

Jeremy

From: Ryan Sleevi [mailto:r...@sleevi.com] 
Sent: Wednesday, April 19, 2017 2:25 PM
To: Mike vd Ent <pasarellaph...@gmail.com>
Cc: mozilla-dev-security-policy 
<mozilla-dev-security-pol...@lists.mozilla.org>; Jeremy Rowley 
<jeremy.row...@digicert.com>; Ben Wilson <ben.wil...@digicert.com>
Subject: Re: CA Validation quality is failing

On Wed, Apr 19, 2017 at 3:47 PM, Mike vd Ent via dev-security-policy 
<dev-security-policy@lists.mozilla.org 
<mailto:dev-security-policy@lists.mozilla.org> > wrote:

Ryan,

My answers on the particular issues are stated inline.
But the thing I want to address is how could (in this case Digicert) validate 
such data and issues certificates? I am investigation more of them and afraid 
even linked company names or registration numbers could be false. Shouldn't 
those certificates be revoked?

You are correct that it appears these certificates should not have issued. 
Hopefully Jeremy and Ben from DigiCert can comment on this thread ( 
https://groups.google.com/d/msg/mozilla.dev.security.policy/DgeLqKMzIds/ig8UmHT2DwAJ
 for the archive) with details about the issues and the steps taken.

smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: DigiCert BR violation

2017-03-09 Thread Jeremy Rowley via dev-security-policy

Thanks. This certificate was issued by an employee of DigiCert as a test on
our systems to see if we'd resolved an issue with a path permitting CN
fields greater than 64 characters. Obviously, the issue wasn't resolved and
the JIRA is still open. We're deploying a patch shortly to fix path and
limit the string to 64 characters. All required validation was completed
successfully prior to issuing the certificate. Although we have a policy
against using live certificates for testing, the policy was not followed in
this case. Prior to issuing the certificate, we actually checked to see if
any other certificates existed with a CN length longer than 64 chars
(basically to see if this path had ever been used by a customer). There are
no other certificates with that long of common name, meaning this issue
should be resolved with the patch.

However, I think this discussion raises some very interesting points about
real world scenarios and RFC 5280 that should be addressed.  DigiCert
actually has three items that routinely show up on CABLint:
1)  Use of teletext in strings (although this only occurs in
re-issues/duplicates of previously issued certificates)
2)  Too long of fields, primarily the O and OU fields
3)  Use of underscore characters in certs
 
 We've had an open item to fix these issues for a while, but haven't
prioritized them because:
a)  From a technical standpoint, the WebPKI supports them,
b)  The inclusion of longer names reflects the real world where company
names are often longer than 64 char, especially in Europe and Asia
(translating international names to puny-code rarely results in a nice short
name),  
c)  We haven't felt that there are sufficiently significant risks
associated with the issues to spend resources addressing them considering a
and b compared to higher priorities (like our current project of requiring
only 169 validation methods), and
d)  Lots of CAs have the same or similar issues under RFC 5280 according
to CABLint, and those issues don't seem to be garnering a lot of attention
(perhaps because of higher risk issues taking priority). 
 
DigiCert and its employees observe two guiding principles in our daily
activities: 1) Improve security and 2) Support the customer. Occasionally,
these principles are not compatible.  For example, most of our customers
hate CT. However, we support the CT project because CT and publicly logging
certificates substantially improves the transparency (and thus security) of
the web. Similarly, we haven't removed underscore characters or limited the
O field to 64 characters because the risks seem insignificant compared to
the large number of companies that would not be able to obtain a
certificate. In fact, I think security is improved by providing these
certificates because these customers/domains would remain unsecured without
certificates or be forced to truncate/omit important information. I believe
most CAs have reached the same conclusion after considering the large number
of issues reported through CABLint.

The discussion also raises an interesting question of when issues become
significant enough they need to be addressed on the Mozilla list or require
revocation. For example, one of our cross-signed partners issued a large
number of certificates that lacked the proper OID. Should each of these
certs warrant a discussion and separate revocation decision? The browsers
don't do anything with this information so I'm unsure whether them revoking
all the certs (which the cross-signed partner did) and replacing them with
certs having an appropriate policy OID made a huge difference in the state
of security.  Should we start a thread on the Mozilla list about each cert
with issues detected in CABLint? Even if we assume half are false positives,
that's about 2000 new discussion items for this group. If so, can we
establish a priority ranking by the browsers for these discussions? 
 
Jeremy

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Ryan Sleevi via dev-security-policy
Sent: Wednesday, March 8, 2017 6:09 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: DigiCert BR violation

It appears that DigiCert has violated the Baseline Requirements, as recently
notified to the CA/Browser Forum. 

The certificate at https://crt.sh/?id=98120546 does not comply with RFC
5280.

RFC 5280 defines the upper-bound of the commonName field as 64 characters,
specifically

ub-common-name INTEGER ::= 64
-- Naming attributes of type X520CommonName:
--   X520CommonName ::= DirectoryName (SIZE (1..ub-common-name))
--
-- Expanded to avoid parameterized type:
X520CommonName ::= CHOICE {
  teletexString TeletexString   (SIZE (1..ub-common-name)),
  printableString   PrintableString (SIZE (1..ub-common-name)),
  universalString   UniversalString (SIZE (1..ub-common-name)),
  utf8StringUTF8String  (SIZE

RE: Symantec: Next Steps

2017-03-09 Thread Jeremy Rowley via dev-security-policy

Cut:
> An unwatched RA and a sub-CA are effectively equivalent in power. A 
> watched RA and a sub-CA might not be, if the CA is exercising 
> effective control and limits on their issuance. There is a distinction 
> in the BRs between an RA and a sub-CA, with the RA having less onerous 
> requirements. One could say that the very existence of that 
> distinction implies that CAs have a duty to carefully watch their RAs.

The equivalency of power is not true most of the time.  The term RA/DTP
covers a lot of different roles. For example, four commonly used roles are:
1) An entity that does the translation of documents for the CA as defined in
the EV Guidelines
2) An entity that gathers the validation documents and submits them to the
CA for review in the validation process
3) An entity that identifies the subject identity information for a
certificate (for example, in some schools the department may provide the
identity proofing of a student that is getting a certificate)
4) An entity that provides verification of the entire certificate contents.

Although #3 and #4 should perhaps be audited, by applying a broad
requirement you end up capturing a lot more delegated entities than
intended. The broad and diverse role of DTPs in the ecosystem is why the
audit requirements in Section 8.4 were written to only require audits over
those that provide domain validation.  Whatever policy is decided, I'm
hoping we can exclude translators and entities that are merely gathering
documentation.

Jeremy

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Ryan Sleevi via dev-security-policy
Sent: Thursday, March 9, 2017 6:32 AM
To: Gervase Markham 
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Symantec: Next Steps

On Thu, Mar 9, 2017 at 6:48 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> That seems to make sense to me. Given that the BRs have the concept of 
> a DTP, how can we best align the two in practice? Does requiring every 
> RA to have its own subCA do that?
>

(Wearing Google hat only for this statement) Have you considered having this
discussion in the CA/Browser Forum? Google had planned to discuss this very
topic at our upcoming F2F about how to address this, and would be very
interested in collaborating with Mozilla on this. I mentioned this recently
to Kathleen at the WebTrust TF meetings, but apologies for not mentioning to
you as well.

> > I recognize that Item 2 "replaces" the criteria for Section 8.2, but
> such a
> > replacement is neither reflected within the audit report produced 
> > (when complying with the BRs) with respect to the issuing CA's 
> > oversight of the DTP - that is, you might reasonably expect a 
> > qualification, but for
> Mozilla
> > to ignore said qualification, consistent with Item 2 of "Audit 
> > Requirements".
>
> Can an audit be qualified (in the audit sense) by virtue of the person 
> _doing_ the audit not being formally qualified (in the other sense!) 
> to use those criteria? I would expect audit qualifications to relate 
> to the audit subject, not the auditor.
>

(Back to non-Google hat)
You've misunderstood. An auditor performing an audit is not going to
"self-qualify" because they aren't licensed. HOWEVER, an Auditor examining
the Principles/Criteria of an Issuing CA is going to examine the controls of
that CA relative to the operation of DTPs and sub-CAs, and those
Principles/Criteria are based on the Baseline Requirements. If the "sub"
auditor is not properly licensed - despite that "sub" auditor meeting the
definition of Mozilla's "replacement" 8.2, then the issuing CA should
reasonably be expected to receive a qualification that their controls are
insufficient for the criteria of the Baseline Requirements (which does not
have the replacement 8.2)

Does that make more sense? In the Sub-CA case, this is "Principle 2: SSL
Service Integrity", Criteria 8.2, and for DTPs, Criteria 8.4

> >> Yes, I would expect externally-operated sub CAs to have the correct 
> >> audits from a Mozilla-qualified auditor.
> >
> > Just to be clear: Given the definitions above, you believe it's
> acceptable
> > for sub-CAs to be issued to parties on the basis of the CA's 
> > judgement as to whether there is "sufficient public information 
> > available to determine that the party is competent to judge the CA's 
> > conformance to the stated criteria", and that so long as they do so, 
> > it does not represent any form of violation of Mozilla Policy, even 
> > if the CA makes an error in that judgement?
>
> No, because in the case of a sub-CA, we require audits. And when we 
> receive them, if they were done by unqualified parties, the CA would 
> need to flag that, and we would make a judgement about that party's 
> suitability at the time. The issue here arises that, because of the 
> way things are set up,

RE: DigiCert BR violation

2017-03-13 Thread Jeremy Rowley via dev-security-policy

Although we have a policy
against using live certificates for testing, the policy was not followed in
this case. 

 

Can you share why? Can you share what steps you'll be taking to make sure 
policies are followed in the future? I think we've seen some pretty stark 
examples about what can happen when a CA doesn't follow its policies for test 
certificates - from CNNIC to Symantec.

 

[JR] In this particular case, the cause was training/policy error in this case 
and mostly my fault (as one of the policy drafters). We have technical 
processes in place to prevent the issuance of certificates with test data. We 
have also repeatedly communicated that test certificates cannot be issued. 
However, we do not technically prevent engineers from applying for certificates 
on the domains they own. As such, the term “test certificate” wasn’t 
well-defined (similar to the current BR test certificate definition).  We’ve 
since clarified that the policy not only prohibits certs with bad data but also 
encourages use of private CAs for testing rather than developers registering 
their own domain and getting a real cert through the ordering process.

 

However, I think this discussion raises some very interesting points about
real world scenarios and RFC 5280 that should be addressed.  DigiCert
actually has three items that routinely show up on CABLint:
1)  Use of teletext in strings (although this only occurs in
re-issues/duplicates of previously issued certificates)

 

Is this in the issuer field? Or in the subject information? I can understand if 
your issuer cert has this issue, but I don't think there's any good reason for 
this for the subject information.

 

[JR] Subject field. However, this was mostly a mistake as it was fixed for all 
new certificates but permitted for entities replacing an existing certificate 
with teletext string.  Should be remediated soon. 

 

 

2)  Too long of fields, primarily the O and OU fields
3)  Use of underscore characters in certs 


 -cut-

 

I gotta admit, this sounds pretty disheartening.

 

"We know we have issues, we've known about them for a while, but we've kept 
doing it, because we don't think it's a big deal, and everyone else is doing 
it".

 

The BRs, in part, exist to avoid that judgement call, because we see time and 
time again where CAs are making that judgement call and it's not ending well. 
If you don't think it belongs, then why not propose BR changes? If you don't 
think it's important, then why not propose root policy changes?

 

[JR] If you recall, I did try to change the policy. I was told to change the 
RFC if I didn’t like the requirement. I find trying to change the RFC nearly 
impossible as PKIX is dead and there are too many other issues people would 
also like to change. 

 

I appreciate the effort towards only 169 validation methods, but how are we, 
the relying parties, supposed to know that DigiCert won't, say, deprioritize 
following the BRs on that because y'all decide it's not a big security issue, 
and instead want to focus on a new product offering, since (besides whatever 
revenue benefit it might have), it gets more sites on HTTPS?

 

As for other CAs, shouldn't you be making sure your house is in order first? :) 
But also, if there are other issues, shouldn't you be pushing for greater 
disclosure and transparency? We constantly see this correlation between smoke 
and fire - and if you're seeing smoke, don't you think it should be raised?

 

[JR] Fair point, and I think the issues should be raised (including ours – 
which is why I raised the other issues in response to this post). I didn’t 
really think of the listed reasons as excuses, more an explanation as to what 
our current cablint issues are and why we haven’t resolved all of them yet. We 
do have most of them on the roadmap, and this discussion has helped prioritize 
some of them higher 

 

The discussion also raises an interesting question of when issues become
significant enough they need to be addressed on the Mozilla list or require
revocation. For example, one of our cross-signed partners issued a large
number of certificates that lacked the proper OID. Should each of these
certs warrant a discussion and separate revocation decision? 

 

Discuss the problem - not the certificates.

 

Discuss what you're doing to address the problem. What caused the issue. How 
many certificates did it affect? What steps are you taking? When will those be 
complete?

 

[JR] The issue is already remedied and was logged as a bug with Mozilla. 
However, the number of certificates that required revocation and replacement 
seemed like a waste considering the certificates omitted an OID. Looking back, 
perhaps we can discuss whether some of these “mis-issues” really warrant a 
revoke and replace mechanism rather than simply disclosure to Mozilla and a 
discussion on what to do. Seems like a waste to throw all of those certs on a 
CRL when they function properly with

RE: DigiCert BR violation

2017-03-13 Thread Jeremy Rowley via dev-security-policy

No - there are no clients that need Teletext that I'm aware of. 

ETA on the other issues are the CN field is already fixed to limit the size
to 64 characters. For the others, we wanted to talk to the primary customer
to let them first know the fix is going live. Should be deployed later this
week, but I want to talk to them before committing to a specific date (since
all their company names are super long).

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Ryan Sleevi via dev-security-policy
Sent: Monday, March 13, 2017 3:32 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: DigiCert BR violation

On Monday, March 13, 2017 at 5:12:39 PM UTC-4, Jeremy Rowley wrote:
> I don't disagree that teletext shouldn't be used, and we no longer 
> include it in new certificate requests or renewals.  However, we do 
> include teletext in certificates that originally had teletext strings but
are being re-keyed.
> Teletext inclusion wasn't intentional and should shortly be fixed. 

Are you saying that there are one or more clients that require DigiCert to
support Teletext strings?

Do you have an ETA on the other issues?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Maximum validity of pre-BR certificates

2017-03-04 Thread Jeremy Rowley via dev-security-policy

Yes - several CAs issued 60 month+ certs prior to 1.0. In fact, 10 year certs 
were not especially uncommon. The validity period available depended largely on 
the CA.

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org]
 On Behalf Of Daniel Cater via dev-security-policy
Sent: Saturday, March 4, 2017 1:22 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Maximum validity of pre-BR certificates

On Saturday, 4 March 2017 20:14:09 UTC, Jeremy Rowley  wrote:
> 1.0 is not the definitive version any more.  As of 2015‐04‐01, Section
> 6.3.2 prohibits validity periods longer than 39 months.
> 

Thanks for the prompt reply Jeremy. I realise this. My question relates to what 
the situation was (be it a guideline, policy, or just common practice) prior to 
version 1.0.

The cablint message mentions 120 months and I was wondering where that number 
came from.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Maximum validity of pre-BR certificates

2017-03-04 Thread Jeremy Rowley via dev-security-policy

Common practice amongst certain cas. There were several cas that have always 
opposed cert validity periods longer than three years. This opposition lead to 
the reducing the validity period first to 60 months then to 39 months.

> On Mar 4, 2017, at 2:01 PM, Peter Bowen via dev-security-policy 
>  wrote:
> 
> On Sat, Mar 4, 2017 at 12:22 PM, Daniel Cater via dev-security-policy
>  wrote:
>> On Saturday, 4 March 2017 20:14:09 UTC, Jeremy Rowley  wrote:
>>> 1.0 is not the definitive version any more.  As of 2015‐04‐01, Section
>>> 6.3.2 prohibits validity periods longer than 39 months.
>>> 
>> 
>> Thanks for the prompt reply Jeremy. I realise this. My question relates to 
>> what the situation was (be it a guideline, policy, or just common practice) 
>> prior to version 1.0.
>> 
>> The cablint message mentions 120 months and I was wondering where that 
>> number came from.
> 
> Common practice.
> ___
> 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: Maximum validity of pre-BR certificates

2017-03-04 Thread Jeremy Rowley via dev-security-policy

1.0 is not the definitive version any more.  As of 2015‐04‐01, Section
6.3.2 prohibits validity periods longer than 39 months.

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Daniel Cater via dev-security-policy
Sent: Saturday, March 4, 2017 1:02 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Maximum validity of pre-BR certificates

Hello,

Version 1.0 of the Baseline Requirements stated that:

"Certificates issued after the Effective Date MUST have a Validity Period no
greater than 60 months".

The effective date for this version was 2012-07-01
(https://cabforum.org/wp-content/uploads/Baseline_Requirements_V1.pdf).

I noticed that cablint has a warning stating: "W: Pre-BR certificates should
not be more than 120 months in validity"
(https://github.com/awslabs/certlint/blob/68a2c46f5146025910a0e17f2f34351e3b
4b8802/lib/certlint/cablint.rb#L328).

Was this a technical limitation or a policy of some kind? I can't find any
reference for it.

Any insight the guidelines, rules, or common practices relating to maximum
certificate lifetime prior to the Baseline Requirements would be
appreciated.

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

smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: DigiCert-Symantec Announcement

2017-08-02 Thread Jeremy Rowley via dev-security-policy

Thanks Kathleen. We already offer short-lived certs (anywhere from 8 hours
up), but they are not issued off a dedicated intermediate. It's a great
suggestion, and we'll add it to the DigiCert plan.

Jeremy 

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Kathleen Wilson via dev-security-policy
Sent: Wednesday, August 2, 2017 4:07 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: DigiCert-Symantec Announcement

On Wednesday, August 2, 2017 at 2:13:40 PM UTC-7, Jeremy Rowley wrote:
> Today, DigiCert and Symantec announced that DigiCert is acquiring the 
> Symantec CA assets, including the infrastructure, personnel, roots, 
> and platforms.  At the same time, DigiCert signed a Sub CA agreement 
> wherein we will validate and issue all Symantec certs as of Dec 1, 2017.


Thanks for posting this information here.

Pointer to DigiCert's blog:

https://www.digicert.com/blog/digicert-to-acquire-symantec-website-security-
business/



> Two things I can say we plan on doing (following closing) to address 
> concerns are:
> 
> a.We plan to segregate certs by type on each root. Going forward, we
> will issue all SSL certs from a root while client and email come from 
> different roots.


I would like to see all CAs move in this direction.


> We also plan on limiting the number of organizations on each issuing 
> CA.  We hope this will help address the "too big to fail" issue seen 
> with Symantec.  By segregating end entities into roots and sub CAs, 
> the browsers can add affected Sub CAs to their CRL lists quickly and 
> without impacting the entire ecosystem.  This plan is very much in 
> flux, and we'd love to hear additional recommendations.


I greatly appreciate your consideration in this area!

Perhaps there can be different subCAs for large organizations versus
smaller/individual site operators (that might be covered as different
brands). Of course, I'm always in favor of technically-constrained subCAs
for the large organizations.

And perhaps one (or more) of the subCAs can be dedicated to short-lived SSL
certs, similar to Let's Encrypt?


> b.Another thing we are doing is adding a validation OID to all of our
> certificates that identifies which of the BR methods were used to 
> issue the cert. This way the entire community can readily identify 
> which method was used when issuing a cert and take action if a method 
> is deemed weak or insufficient.  We think this is a huge improvement 
> over the existing landscape, and I'm very excited to see that OID rolled
out.

I would like to see all CAs move in this direction as well.


Looks like you are going to be very busy! :-)

Thanks, and good luck!

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


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: DigiCert-Symantec Announcement

2017-08-02 Thread Jeremy Rowley via dev-security-policy

Hey Nick - I plan to include all relevant OIDs in the cert. I figured that
way relying parties understand the total risk associated with verification
of the certificate, even if they don't know exactly the methods tied to each
listed domain. If a method is eventually deemed less desirable (*cough*
domain authorization letters *cough*), then the entire cert would need to be
replaced anyway to reflect deprecation of that method.

Jeremy 

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Nick Lamb via dev-security-policy
Sent: Wednesday, August 2, 2017 4:57 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: DigiCert-Symantec Announcement

On the use of OIDs to signify the Blessed Method used for validation I
thought it can't hurt to mention the first obstacle for this idea which
occurred to me in respect of Let's Encrypt (and more generally any CA
importing ACME I think)

Suppose an applicant asks for www.example.com, images.example.com and
www.example.org. They demonstrate control over www.example.com using files
in .well-known/ (sorry I'm writing this on my phone in a hotel room, don't
have BR section numbers in front of me) but use DNS to show control over
www.example.org...

Which OID goes in this certificate? Both of them? There are arbitrarily more
complicated examples along these lines, all worth a bit of thought before
setting off I think.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

DigiCert-Symantec Announcement

2017-08-02 Thread Jeremy Rowley via dev-security-policy

Hi everyone, 

 

Today, DigiCert and Symantec announced that DigiCert is acquiring the
Symantec CA assets, including the infrastructure, personnel, roots, and
platforms.  At the same time, DigiCert signed a Sub CA agreement wherein we
will validate and issue all Symantec certs as of Dec 1, 2017.  We are
committed to meeting the Mozilla and Google plans in transitioning away from
the Symantec infrastructure. The deal is expected to close near the end of
the year, after which we will be solely responsible for operation of the CA.
>From there, we will migrate customers and systems as necessary to
consolidate platforms and operations while continuing to run all issuance
and validation through DigiCert.  We will post updates and plans to the
community as things change and progress.  

 

I wanted to post to the Mozilla dev list to:

1.  Inform the public, 
2.  Get community feedback about the transition and concerns, and
3.  Get an update from the browsers on what this means for the plan,
noting that we fully commit to the stated deadlines. We're hoping that any
changes 

 

Two things I can say we plan on doing (following closing) to address
concerns are:

a.  We plan to segregate certs by type on each root. Going forward, we
will issue all SSL certs from a root while client and email come from
different roots. We also plan on limiting the number of organizations on
each issuing CA.  We hope this will help address the "too big to fail" issue
seen with Symantec.  By segregating end entities into roots and sub CAs, the
browsers can add affected Sub CAs to their CRL lists quickly and without
impacting the entire ecosystem.  This plan is very much in flux, and we'd
love to hear additional recommendations. 
b.  Another thing we are doing is adding a validation OID to all of our
certificates that identifies which of the BR methods were used to issue the
cert. This way the entire community can readily identify which method was
used when issuing a cert and take action if a method is deemed weak or
insufficient.  We think this is a huge improvement over the existing
landscape, and I'm very excited to see that OID rolled out.

 

Thanks a ton for any thoughts you offer. 

 

Jeremy



smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: DigiCert-Symantec Announcement

2017-08-02 Thread Jeremy Rowley via dev-security-policy

 

 

* Will there be other players in Symantec's SubCA plan or is DigiCert the only 
one?

 

[DC] Only DigiCert.

 

* ‎Is DigiCert prepared (yet?) to commit to a "first day of issuance" under the 
SubCA plan? That is, when is the earliest date that members of the general 
public may purchase certs that chain up through the new "DigiCert SubCA" to any 
of the Symantec roots? I hope that, for issues that may arise under the new 
system, there is sufficient time to identify and resolve them prior to the 
2017-12-01 deadline.

 

[DC] Not yet. That’s an ongoing discussion.  



* I think the idea of a smart segregation plan for the roots and intermediates 
is a must-have. Such a plan should factor in the clientele who are using the 
different roots and the environments in which they operate. Given how important 
the "ubiquitous roots" are, I would hope to see community involvement and 
"sign-off", if you will.

 

[DC] Okay. We plan to update the community as things solidify.

 

* I think it's appropriate to re-think some of the deadlines, given that we're 
talking less about a carrots-and-sticks model and more of one based on smart 
decision-making, good risk management, and sticks.


[DC] I’ll leave that open to the community discussion, although anything sooner 
than the current deadlines might not have as satisfactory results as the 
current proposal.



Finally, when I went to read the DigiCert blog post, I noticed that John 
Merrill's link for the agreement announcement was a dud. I don't know why but I 
really don't care either. I think it serves as a reminder ‎that mistakes are 
going to be made during this process so it's best to make allowances for that 
in the plans going forward. That, and attention to detail is important.

 

[DC] Egg on my face there. Thanks for finding that.  We’re getting it updated.

 



smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: DigiCert-Symantec Announcement

2017-08-03 Thread Jeremy Rowley via dev-security-policy

We aren't sure at this point. DigiCert already runs two (almost three) logs.
Symantec runs two logs.  Although CT plans are still under discussion, I
don't think the ecosystem needs four CT logs operated by a single CA.
Regardless, we'll do whatever is best to support CT and the DigiCert and
Symantec customer-base. Likely, we'll compare infrastructure and keep the
best performing logs. We'll definitely run a differential between the logs
and consult with the community before anything is done with existing logs. 
Jeremy

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Santhan Raj via dev-security-policy
Sent: Thursday, August 3, 2017 1:36 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: DigiCert-Symantec Announcement

On Wednesday, August 2, 2017 at 6:44:51 PM UTC-7, Peter Bowen wrote:
> On Wed, Aug 2, 2017 at 2:12 PM, Jeremy Rowley via dev-security-policy 
> <dev-security-policy@lists.mozilla.org> wrote:
> > Today, DigiCert and Symantec announced that DigiCert is acquiring 
> > the Symantec CA assets, including the infrastructure, personnel, 
> > roots, and platforms.  At the same time, DigiCert signed a Sub CA 
> > agreement wherein we will validate and issue all Symantec certs as 
> > of Dec 1, 2017.  We are committed to meeting the Mozilla and Google 
> > plans in transitioning away from the Symantec infrastructure. The 
> > deal is expected to close near the end of the year, after which we will
be solely responsible for operation of the CA.
> > From there, we will migrate customers and systems as necessary to 
> > consolidate platforms and operations while continuing to run all 
> > issuance and validation through DigiCert.  We will post updates and 
> > plans to the community as things change and progress.
> >
> > Thanks a ton for any thoughts you offer.
> 
> Jeremy,
> 
> A while ago I put together a list of all the certificates that are or 
> were included in trust stores that were known to be owned by Symantec 
> or companies that Symantec acquired.  The list is in Google Sheets at 
> https://docs.google.com/spreadsheets/d/1piCTtgMz1Uf3SHXoNEFYZKAjKGPJdR
> DGFuGehdzcvo8/edit?usp=sharing
> 
> Can you confirm that DigiCert will be "solely responsible for 
> operation" of all of these CAs once the deal closes?
> 
> Thanks,
> Peter

Hi Jeremy,

A similar question regarding Symantec's CT log infrastructure. Are they part
of the deal and do you plan to continue hosting them?

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


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert-Symantec Announcement

2017-08-03 Thread Jeremy Rowley via dev-security-policy

I believe all of the non expired CAs listed are in scope.

> On Aug 2, 2017, at 7:44 PM, Peter Bowen <pzbo...@gmail.com> wrote:
> 
> On Wed, Aug 2, 2017 at 2:12 PM, Jeremy Rowley via dev-security-policy
> <dev-security-policy@lists.mozilla.org> wrote:
>> Today, DigiCert and Symantec announced that DigiCert is acquiring the
>> Symantec CA assets, including the infrastructure, personnel, roots, and
>> platforms.  At the same time, DigiCert signed a Sub CA agreement wherein we
>> will validate and issue all Symantec certs as of Dec 1, 2017.  We are
>> committed to meeting the Mozilla and Google plans in transitioning away from
>> the Symantec infrastructure. The deal is expected to close near the end of
>> the year, after which we will be solely responsible for operation of the CA.
>> From there, we will migrate customers and systems as necessary to
>> consolidate platforms and operations while continuing to run all issuance
>> and validation through DigiCert.  We will post updates and plans to the
>> community as things change and progress.
>> 
>> Thanks a ton for any thoughts you offer.
> 
> Jeremy,
> 
> A while ago I put together a list of all the certificates that are or
> were included in trust stores that were known to be owned by Symantec
> or companies that Symantec acquired.  The list is in Google Sheets at
> https://docs.google.com/spreadsheets/d/1piCTtgMz1Uf3SHXoNEFYZKAjKGPJdRDGFuGehdzcvo8/edit?usp=sharing
> 
> Can you confirm that DigiCert will be "solely responsible for
> operation" of all of these CAs once the deal closes?
> 
> Thanks,
> Peter
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: DigiCert-Symantec Announcement

2017-08-03 Thread Jeremy Rowley via dev-security-policy

Hi Doug,

We are confident in our ability to hit the deadlines set by both Mozilla and 
Google. Our understanding is that all new validations will be done by DigiCert 
on Dec 1, 2017. We plan to start re-validating information as soon as 
practical under the Sub CA agreement. Our mutual goal is to avoid Symantec 
validation data reuse, avoiding the shorter validity periods required by 
Google.  Both companies believe this will provide the best customer experience 
and give customers the service they are used to.

Jeremy

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+doug.beattie=globalsign@lists.mozilla.org] On Behalf Of
> Jeremy Rowley via dev-security-policy
> Sent: Wednesday, August 2, 2017 10:54 PM
> To: Peter Kurrasch <fhw...@gmail.com>; mozilla-dev-security-policy
> <mozilla-dev-security-pol...@lists.mozilla.org>
> Subject: RE: DigiCert-Symantec Announcement
> * Will there be other players in Symantec's SubCA plan or is DigiCert
> the only one?
>
>
>
> [DC] Only DigiCert.

Jeremy - It's my understanding that as of December 1st every certificate 
issued by Symantec or a Managed CA must have the domains validated by the 
Managed CA (in this case only DigiCert). Is it feasible that DigiCert 
revalidate every domain in use by Symantec Enterprise customs between now and 
then, and to keep up with all reissues/renewals and new Retail and Partner 
orders?  It seems like a huge challenge, especially given that you are not 
able to use Symantec employees or systems for this.  Maybe my assumptions are 
not accurate.



smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: DigiCert-Symantec Announcement

2017-08-03 Thread Jeremy Rowley via dev-security-policy

Hey Peter, 



 I think the Mozilla and Google plans both stand as-is, although probably need 
an updated based on this announcement.  I'm hoping that the high-level concepts 
remain unchanged:

- Migrate to a new infrastructure

- Audit the migration and performance to ensure compliance

- Improve operational transparency so the community has assurances on what 
is happening. 



 Jeremy

 

 

From: dev-security-policy 
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org]
 On Behalf Of Peter Kurrasch via dev-security-policy
Sent: Wednesday, August 2, 2017 8:01 PM
To: mozilla-dev-security-policy 
Subject: Re: DigiCert-Symantec Announcement

 

This certainly shakes things up! I've had my concerns that Symantec's plan was 
complicated and risky, but now I'm wondering if this new path will be somewhat 
simpler--yet even more risky? I'm not suggesting we shouldn't take this path 
but I am hoping we make smart, well-thought-out decisions along the way.

 

Some thoughts:

 

* Will there be other players in Symantec's SubCA plan or is DigiCert the only 
one?

 

* ‎Is DigiCert prepared (yet?) to commit to a "first day of issuance" under the 
SubCA plan? That is, when is the earliest date that members of the general 
public may purchase certs that chain up through the new "DigiCert SubCA" to any 
of the Symantec roots? I hope that, for issues that may arise under the new 
system, there is sufficient time to identify and resolve them prior to the 
2017-12-01 deadline.





* I think the idea of a smart segregation plan for the roots and intermediates 
is a must-have. Such a plan should factor in the clientele who are using the 
different roots and the environments in which they operate. Given how important 
the "ubiquitous roots" are, I would hope to see community involvement and 
"sign-off", if you will.

 

* I think it's appropriate to re-think some of the deadlines, given that we're 
talking less about a carrots-and-sticks model and more of one based on smart 
decision-making, good risk management, and sticks.









Finally, when I went to read the DigiCert blog post, I noticed that John 
Merrill's link for the agreement announcement was a dud. I don't know why but I 
really don't care either. I think it serves as a reminder ‎that mistakes are 
going to be made during this process so it's best to make allowances for that 
in the plans going forward. That, and attention to detail is important.





Thanks.



smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: SRVNames in name constraints

2017-08-15 Thread Jeremy Rowley via dev-security-policy

Ah.  Sorry about that.  I agree that no CA can issue those yet.

-Original Message-
From: Peter Bowen [mailto:pzbo...@gmail.com]
Sent: Tuesday, August 15, 2017 9:04 AM
To: Jeremy Rowley 
Cc: Gervase Markham ; Ryan Sleevi ; Peter 
Bowen ; mozilla-dev-security-policy 

Subject: Re: SRVNames in name constraints

On Tue, Aug 15, 2017 at 8:01 AM, Jeremy Rowley  
wrote:
> I realize use of underscore characters was been debated and explained
> at the CAB Forum, but I think it's pretty evident (based on the certs
> issued and responses to Ballot 202) that not all CAs believe certs for
> SRVNames are prohibited. I realize the rationale against underscores
> is that 5280 requires a valid host name for DNS and X.509 does not
> necessarily permit underscores, but it's not explicitly stated. Ballot
> 202 went a long way towards clarification on when underscores are
> permitted, but that failed, creating all new confusion on the issue.
> Any CA not paying careful attention to the discussion and looking at
> only the results, would probably believe SRVNames are permitted as
> long as the entry is in SAN:dNSName instead of otherName.

Jeremy,

I was assuming the definition of "SRVname" meant an otherName type entry. 
Obviously a dNSName of _xmpp.example.com would have name constraints applied, 
so I don't think that there is an issue there.

Thanks,
Peter


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: SRVNames in name constraints

2017-08-15 Thread Jeremy Rowley via dev-security-policy

I realize use of underscore characters was been debated and explained at the
CAB Forum, but I think it's pretty evident (based on the certs issued and
responses to Ballot 202) that not all CAs believe certs for SRVNames are
prohibited. I realize the rationale against underscores is that 5280
requires a valid host name for DNS and X.509 does not necessarily permit
underscores, but it's not explicitly stated. Ballot 202 went a long way
towards clarification on when underscores are permitted, but that failed,
creating all new confusion on the issue.  Any CA not paying careful
attention to the discussion and looking at only the results, would probably
believe SRVNames are permitted as long as the entry is in SAN:dNSName
instead of otherName.   

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Peter Bowen via dev-security-policy
Sent: Tuesday, August 15, 2017 8:51 AM
To: Gervase Markham 
Cc: Ryan Sleevi ; Peter Bowen ;
mozilla-dev-security-policy 
Subject: Re: SRVNames in name constraints

On Tue, Aug 15, 2017 at 4:20 AM, Gervase Markham via dev-security-policy
 wrote:
> On 06/07/17 16:56, Ryan Sleevi wrote:
>> Relevant to this group, id-kp-serverAuth (and perhaps 
>> id-kp-clientAuth)
>
> So what do we do? There are loads of "name-constrained" certs out 
> there with id-kp-serverAuth but no constraints on SRVName. Does that 
> mean they can issue for any SRVName they like? Is that a problem once 
> we start allowing it?
>
> I've filed:
> https://github.com/mozilla/pkipolicy/issues/96
> on this issue in general.

Right now no CA is allowed to issue for SRVName.  Part of the CA/Browser
Forum ballot I had drafted a while ago had language that said something like
"If a CA certificate contains at least one DNSName entry in NameConstraints
and does not have any SRVName entries in NameConstraints, then the CA MUST
NOT issue any certificates containing SRVname names."

However this is a morass, as it is defining what a CA can do based on
something outside the CA's scope.  I'm not sure how to deal with this, to be
honest.

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

smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Certificates with reserved IP addresses

2017-08-14 Thread Jeremy Rowley via dev-security-policy

Hey Ryan, 

Here's the report from CTJ:

Number of affected certificates:
One.  After receiving the revocation request from DigiCert, CTJ scanned their 
certificate database for additional certificates.  This is the only active 
certificate with a reserved IP.  CTJ issued the g2-sanfull01.ctjssl.info for 
its own use. 

Cause of missing the revocation:
This certificate was identified as requiring revocation back in February 2016. 
When this issued, they had already blocked all renewals and issuance of 
certificates with internal names/IP addresses.  Although the certificate was 
scheduled for revocation after CTJ moved away using the IP address, they forgot 
to revoke this last cert. Because it was one certificate, CTJ did not automate 
the revocation, making it subject to human error and forgetfulness.  

Remediation actions:
CTJ is revoking this cert.  CTJ is also implementing a CABLint-like process to 
check all certificates each time industry standards change.  They are scanning 
crt.sh daily to verify the compliance of all new certs.

Jeremy

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org]
 On Behalf Of Ryan Sleevi via dev-security-policy
Sent: Saturday, August 12, 2017 8:56 PM
To: Ben Wilson 
Cc: Jonathan Rudenberg ; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Certificates with reserved IP addresses

Do you have an estimate on when you can provide an explanation to the community 
about how/why this happened, how many certificates it affected, and what steps 
DigiCert is taking to prevent these issues in the future? Do you have details 
about why DigiCert failed to detect these, and what steps DigiCert has in place 
to ensure compliance from its subordinate CAs?

On Sat, Aug 12, 2017 at 10:19 PM, Ben Wilson via dev-security-policy < 
dev-security-policy@lists.mozilla.org> wrote:

> Thanks.  We've sent an email to the operators of the first two CAs (TI 
> Trust Technologies and Cybertrust Japan) that they need to revoke 
> those certificates.
> Thanks again,
> Ben
>
> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-bounces+ben=
> digicert@lists.mozilla.org] On Behalf Of Jonathan Rudenberg via 
> dev-security-policy
> Sent: Saturday, August 12, 2017 7:53 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Certificates with reserved IP addresses
>
> Baseline Requirements section 7.1.4.2.1 prohibits ipAddress SANs from 
> containing IANA reserved IP addresses and any certificates containing 
> them should have been revoked by 2016-10-01.
>
> There are seven unexpired unrevoked certificates that are known to CT 
> and trusted by NSS containing reserved IP addresses.
>
> The full list can be found at: https://misissued.com/batch/7/
>
> DigiCert
> TI Trust Technologies Global CA (5)
> Cybertrust Japan Public CA G2 (1)
>
> PROCERT
> PSCProcert (1)
>
> It’s also worth noting that three of the "TI Trust Technologies”
> certificates contain dnsNames with internal names, which are 
> prohibited under the same BR section.
>
> Jonathan
> ___
> 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
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Symantec Update on SubCA Proposal

2017-08-14 Thread Jeremy Rowley via dev-security-policy

Hi Jakob, 

Your below description raises two questions of general interest (though not of 
interest to the Mozilla root program):

1. Will DigiCert establish cross-signatures from the old/historic
   Symantec roots to continuing DigiCert roots and subCAs?

[JR]  We won’t be cross-signing from DigiCert to Symantec.  For cross-signs the 
other way, we plan on supporting the community’s needs and would love to hear 
more online and offline about what cross-signs to DigiCert are needed for 
compatibility and interoperability. Mozilla proposed distrusting Symantec’s 
roots in 2018 so we’ll work towards that goal. Once it’s removed, the one-way 
trust from Symantec to DigiCert will fall out of scope.  Prior to that, the 
cross-sign will be operated per the BRs and subject to the Google and Mozilla 
proposals.

2. Will DigiCert continue those Symantec services that were not trusted
   by Mozilla/Google and which have no functional alternative elsewhere.

This includes a number of situations where Microsoft and other
   companies are enforcing that things are signed exclusively by specific
   Symantec issuance systems.  Known examples include: The original SHA-1
   time stamping service for code signing (needed for compatibility with
   older Windows and Internet Explorer versions).  The special signing
   portal for Windows Mobile (the original product line, not the new
   renamed Windows 10 Phone product line).  The "hosted" signing service
   for Android Apps.  Possibly any remnants of the Geotrust-based
   services for the old Nokia platforms (Symbian S60 etc.). Etc.

[JR] As you mentioned, none of these are trusted by Mozilla or Google so that 
discussion is better held elsewhere.  However, I can say that we plan to 
support Symantec communities to the extent possible.  The only planned 
deprecation is the Symantec publicly-trusted Web PKI.  

Jeremy


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Certificates with invalidly long serial numbers

2017-08-10 Thread Jeremy Rowley via dev-security-policy

Not really - most CAs reuse validation information for the time period
specified under the BRs, which is currently 825 days under section 4.2.1.
The hardest part of the whole process is typically contacting the customer
to start the replacement process. The problem is probably worse for fully
automated CAs who don't necessarily have a close relationship with the
customer, perhaps only an email address that can be used to let them know
their website is about to go down.   

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Jakob Bohm via dev-security-policy
Sent: Thursday, August 10, 2017 3:40 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Certificates with invalidly long serial numbers

But that would require the issuer of the replacement cert (which might not
be a fast-issue DV cert) to complete validation in something like 36 hours,
which is much shorter than the normal time taken to do proper OV and/or EV
validation.

I have previously suggested 14 days for live certificates that don't cause
actual security issues.  This would be enough for most subscribers to either
get a reissued certificate (for free) from the original CA or set up an
account with a competing CA and get at least a basic OV cert.

On 10/08/2017 03:02, Jeremy Rowley wrote:
> No objection to 72 hours v. 1 business day.  I agree it should be 
> short and
> 72 hours seems perfectly reasonable .
> 
> -Original Message-
> From: dev-security-policy
> [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.m
> ozilla .org] On Behalf Of Paul Kehrer via dev-security-policy
> Sent: Wednesday, August 9, 2017 4:57 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Certificates with invalidly long serial numbers
> 
> On Wednesday, August 9, 2017 at 9:20:02 AM UTC-5, Jeremy Rowley wrote:
>> All CAS are required to maintain the capability to process and 
>> receive
> revocation requests 24x7 under the baseline requirements. The headache 
> is not with the CA. Rather, it's notifying the customer that their 
> certificate will be revoked before the start of the next business day. 
> Having a one to two business day rule  instead of 24 hours for non 
> compromise issues gives the end entity time to receive the 
> notification and replace their certificate with a compliant version.
> 
> I'm sure many customers would absolutely prefer that and on the 
> surface it does sound like a good solution. However, I think it's 
> another example of the general difference of opinion between people on 
> this list around whether we should be holding CAs to the highest 
> standards or not. These mis-issued certificates are typically not a 
> security concern, but they speak to either ignorance on the part of CA 
> operators or a pattern of lackadaisical controls within the issuance 
> systems. Neither of these is acceptable behavior at this juncture.
Conformance with the BRs has been mandatory for over 5 years now.
> Customers need to be made aware of the failures of their chosen 
> providers and the responsibilities incumbent upon them as subscribers, 
> and if their own certificate installation/replacement processes are 
> sufficiently archaic as to make it difficult to replace a certificate 
> in an automated fashion then they should rectify that immediately.
> 
> That said, to continue the thought experiment, what does "1-2 business
days"
> really mean?Does the CA get 1-2 business days followed by 1-2 for the 
> customer? What if there's a holiday in the CA's country of operations 
> followed by a holiday in the customer's home country? How quickly does 
> this window extend to 2+ weeks? If you were to go down this path I'd 
> strongly prefer it to be a hard deadline (e.g. 72 hours) and not 
> anything related to business days.
> 


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com Transformervej
29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10 This public discussion
message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Certificates with metadata-only subject fields

2017-08-10 Thread Jeremy Rowley via dev-security-policy

A couple of people also pointed out that we previously discussed these exact
certs here:
https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/DgeLqKMzId
s/E9--gj5WEAAJ

The decision then was that we should prevent further issuance of certs with
N/A and other metadata but that revocation was not necessary in this case.

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Jeremy Rowley via dev-security-policy
Sent: Thursday, August 10, 2017 12:24 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: RE: Certificates with metadata-only subject fields

On this particular issue, it's questionable whether these are a violation of
a strict reading of the BRs. Section 7.1.4.2.2(i) defines the OU field.
Section 7.1.4.2.2(j) defines "Any other subject".

Section 7.1.4.2.2(J) :
"All other optional attributes, when present within the subject field, MUST
contain information that has been verified by the CA. Optional attributes
MUST NOT contain metadata such as ‘.’, ‘‐‘, and ‘ ‘
(i.e.   space) characters, and/or any other indication that the value is
absent, incomplete, or not applicable."

Because OU is not "all other optional attributes", j doesn't apply. I think
this gives the wrong results and am for disallowing metadata in the OU
field. However, if we're going to be persnickety on the 24 hour rule, we
should be persnickety on the other ones as well.

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Alex Gaynor via dev-security-policy
Sent: Thursday, August 10, 2017 7:20 AM
To: Ryan Sleevi <r...@sleevi.com>
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Certificates with metadata-only subject fields

As a friend of mine sagely points out, fundamentally the current incentives
for a CA are, "Issuing certs gets us money, not issuing certs does not get
us anything". That's an incentive structure that badly needs correction --
CAs should be accountable for what they issue.

Without speaking to particular revocation timelines, I expect CAs to be
fixing the bugs in their issuance pipelines that allowed these non-compliant
certs to be issued, and I expect them to send post-portems to mdsp
explaining what the root cause for these issues was and how they corrected
it.

Alex

On Wed, Aug 9, 2017 at 8:37 PM, Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Wednesday, August 9, 2017 at 5:50:43 PM UTC-4, Peter Bowen wrote:
> > The point of certlint was to help identify issues.  While I
> > appreciate it getting broad usage, I don't think pushing for
> > revocation of every certificate that trips any of the Error level
> > checks
is productive.
> > This reminds of me of people trawling a database of known
> > vulnerabilities then reporting them to the vendors and asking for a
> > reward, which happens all too often in bug bounty programs.
> >
> > I think it would be much more valuable to have a "score card" by CA
> > Operator that shows absolute defects and defect rate.
>
> In one of the few times I think it's happened, I think I disagree with
> you, Peter.
>
> I appreciate the perspective that revocation of these certificates
> externalizes the cost of misissuance from the CA (responsible for it)
> onto the customer (who purchased the certificate), and thus a
> viewpoint that suggests this is somehow unjust (since it's the victim
> of misissuance who suffers), but I think an argument that suggests
> these shouldn't be revoked is similar to an argument that says those
> who purchased stolen merchandise should get to keep it, as long as
> they
didn't know it was stolen.
>
> That is, if we look at it from a lens of incentives, CAs have little
> incentive to properly issue the certificates if the consequence of
> misissuance is not an immediate result, but one of potential future
action.
> Sadly, humans are terrible at recognizing those potential long-term
> costs (c.f. obesity/heart disease/dental care/global warming as all
> examples of long-term costs with short-term benefits).
>
> While I don't disagree we should keep a scoreboard, I think it's also
> the right incentive - for CAs, and the overall ecosystem - to ensure
> that any misissuance is revoked in a timely fashion (which is
> currently 24 hours), because it helps encourage a market where the
> best step a CA can take to minimize risk to their subscribers, the
> ones actually paying them money and engaging in a business
> relationship with them, is to simply not misissue the certificates.
> ___
> dev-security-policy mailing list
> dev-se

RE: Certificates with less than 64 bits of entropy

2017-08-10 Thread Jeremy Rowley via dev-security-policy

Hi Jonathan, 

InfoCert's sub CA was revoked on August 1, 2017. We'll reach out to Siemens. 
They moved to Quovadis a while ago and are no longer issuing from that Sub CA.

Jeremy

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org]
 On Behalf Of Jonathan Rudenberg via dev-security-policy
Sent: Thursday, August 10, 2017 9:26 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Certificates with less than 64 bits of entropy


> On Aug 10, 2017, at 11:20, Jonathan Rudenberg via dev-security-policy 
>  wrote:
> 
> QuoVadis (560)
>Siemens Issuing CA Internet Server 2016 (560)
> 
> D-TRUST (224)
>D-TRUST SSL Class 3 CA 1 2009 (178)
>D-TRUST SSL Class 3 CA 1 EV 2009 (45)
>D-TRUST Root Class 3 CA 2 EV 2009 (1)
> 
> DigiCert (85)
>Siemens Issuing CA Class Internet Server 2013 (82)
>InfoCert Web Certification Authority (3)
> 
> Izenpe S.A. (62)
>EAEko Herri Administrazioen CA - CA AAPP Vascas (2) (62)
> 
> Government of The Netherlands, PKIoverheid (Logius) (55)
>Digidentity Services CA - G2 (55)
> 
> Government of Turkey, Kamu Sertifikasyon Merkezi (Kamu SM) (38)
>Cihaz Sertifikası Hizmet Sağlayıcı - Sürüm 4 (38)

It looks like my summary missed one QuoVadis intermediate:

Bayerische SSL-CA-2016-01 (3)

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


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Certificates with metadata-only subject fields

2017-08-10 Thread Jeremy Rowley via dev-security-policy

On this particular issue, it's questionable whether these are a violation of
a strict reading of the BRs. Section 7.1.4.2.2(i) defines the OU field.
Section 7.1.4.2.2(j) defines "Any other subject".

Section 7.1.4.2.2(J) :
"All other optional attributes, when present within the subject field, MUST
contain information that has been verified by the CA. Optional attributes
MUST NOT contain metadata such as ‘.’, ‘‐‘, and ‘ ‘
(i.e.   space) characters, and/or any other indication that the value is
absent, incomplete, or not applicable."

Because OU is not "all other optional attributes", j doesn't apply. I think
this gives the wrong results and am for disallowing metadata in the OU
field. However, if we're going to be persnickety on the 24 hour rule, we
should be persnickety on the other ones as well.

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Alex Gaynor via dev-security-policy
Sent: Thursday, August 10, 2017 7:20 AM
To: Ryan Sleevi 
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Certificates with metadata-only subject fields

As a friend of mine sagely points out, fundamentally the current incentives
for a CA are, "Issuing certs gets us money, not issuing certs does not get
us anything". That's an incentive structure that badly needs correction --
CAs should be accountable for what they issue.

Without speaking to particular revocation timelines, I expect CAs to be
fixing the bugs in their issuance pipelines that allowed these non-compliant
certs to be issued, and I expect them to send post-portems to mdsp
explaining what the root cause for these issues was and how they corrected
it.

Alex

On Wed, Aug 9, 2017 at 8:37 PM, Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Wednesday, August 9, 2017 at 5:50:43 PM UTC-4, Peter Bowen wrote:
> > The point of certlint was to help identify issues.  While I
> > appreciate it getting broad usage, I don't think pushing for
> > revocation of every certificate that trips any of the Error level checks
is productive.
> > This reminds of me of people trawling a database of known
> > vulnerabilities then reporting them to the vendors and asking for a
> > reward, which happens all too often in bug bounty programs.
> >
> > I think it would be much more valuable to have a "score card" by CA
> > Operator that shows absolute defects and defect rate.
>
> In one of the few times I think it's happened, I think I disagree with
> you, Peter.
>
> I appreciate the perspective that revocation of these certificates
> externalizes the cost of misissuance from the CA (responsible for it)
> onto the customer (who purchased the certificate), and thus a
> viewpoint that suggests this is somehow unjust (since it's the victim
> of misissuance who suffers), but I think an argument that suggests
> these shouldn't be revoked is similar to an argument that says those
> who purchased stolen merchandise should get to keep it, as long as they
didn't know it was stolen.
>
> That is, if we look at it from a lens of incentives, CAs have little
> incentive to properly issue the certificates if the consequence of
> misissuance is not an immediate result, but one of potential future
action.
> Sadly, humans are terrible at recognizing those potential long-term
> costs (c.f. obesity/heart disease/dental care/global warming as all
> examples of long-term costs with short-term benefits).
>
> While I don't disagree we should keep a scoreboard, I think it's also
> the right incentive - for CAs, and the overall ecosystem - to ensure
> that any misissuance is revoked in a timely fashion (which is
> currently 24 hours), because it helps encourage a market where the
> best step a CA can take to minimize risk to their subscribers, the
> ones actually paying them money and engaging in a business
> relationship with them, is to simply not misissue the certificates.
> ___
> 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

smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Certificates with metadata-only subject fields

2017-08-10 Thread Jeremy Rowley via dev-security-policy

Not really – and I don’t object to the certificate problem reports. I greatly 
appreciate the work Alex and Jonathan are doing.

I disagree that finding small issues indicates larger issues as a whole. 
There’s no support for that claim.  It’s just as likely that larger issues are 
going ignored because of noise as the smaller issues are indicators of 
something like domain validation going wrong. I doubt they speak equally to 
CA’s ability to execute on best practices as well.  Seems like a failure to do 
validation would be way more severe than ensuring the OU field doesn’t have 
metadata. 

From: Ryan Sleevi [mailto:r...@sleevi.com] 
Sent: Thursday, August 10, 2017 12:24 PM
To: Jeremy Rowley <jeremy.row...@digicert.com>
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Certificates with metadata-only subject fields

Can you provide an example of what you believe is a bigger issue that has been 
masked? Otherwise, it sounds like you're saying "Ignore the obvious errors, 
because maybe someone will find something non-obvious, and we don't want to 
miss out" - but that's a deeply flawed argument, and I would hope isn't the 
substance of what you're saying.

Note: I still disagree with you about the artificial ontology; all of these 
errors equally speak to the CA's ability to execute on Best Practices, such as 
using available tools that have been evangelized for over a year as something 
that can (and arguably should) be integrated into issuance pipelines. 
Discussions at this point are extremely relevant, as they speak to how well the 
CA is staying abreast of changes, as well as how effectively they're managing 
their subsidiaries - both issues that are key to public trust.

On Thu, Aug 10, 2017 at 2:17 PM, Jeremy Rowley via dev-security-policy 
<dev-security-policy@lists.mozilla.org 
<mailto:dev-security-policy@lists.mozilla.org> > wrote:

I strongly disagree. The discussion around errors like these masks the
bigger issues in the noise.  If there are bigger issues, let's find those.

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley 
<mailto:dev-security-policy-bounces%2Bjeremy.rowley> =digicert.com@lists.mozilla

.org] On Behalf Of David E. Ross via dev-security-policy
Sent: Wednesday, August 9, 2017 4:35 PM
To: mozilla-dev-security-pol...@lists.mozilla.org 
<mailto:mozilla-dev-security-pol...@lists.mozilla.org> 
Subject: Re: Certificates with metadata-only subject fields

On 8/9/2017 2:54 PM, Jonathan Rudenberg wrote:
>
>> On Aug 9, 2017, at 17:50, Peter Bowen <pzbo...@gmail.com 
>> <mailto:pzbo...@gmail.com> > wrote:
>>
>> The point of certlint was to help identify issues.  While I
>> appreciate it getting broad usage, I don't think pushing for
>> revocation of every certificate that trips any of the Error level checks
is productive.
>
> I agree, and I don't really have a position on the revocation of
certificates with errors that do not appear to have any security impact like
these.
>
> Jonathan
>
>

I strongly disagree.  Errors like this make me question whether the
certification authority is sufficiently competent to be trusted.  Small
errors can indicate an increased likelihood of serious errors.

--
David E. Ross
<http://www.rossde.com/>

President Trump demands loyalty to himself from Republican members of
Congress.  I always thought that members of Congress -- House and Senate --
were required to be loyal to the people of the United States.  In any case,
they all swore an oath of office to be loyal to the Constitution.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org 
<mailto: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 
<mailto:dev-security-policy@lists.mozilla.org> 
https://lists.mozilla.org/listinfo/dev-security-policy

smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Certificates with metadata-only subject fields

2017-08-10 Thread Jeremy Rowley via dev-security-policy

Thinking about it more, this particular issue is the most annoying one because:

1.  There’s not a limited defined set of items that encompass what the OU 
may include,
2.  The OU is generally the dumping ground for information, and
3.  There’s no requirement this information is verified other than ensuring 
it doesn’t have org/address info. 

Building a rule set to shore up this particular issue is difficult as the 
parameters are not well defined like they are with domain and identity 
validation.

From: Ryan Sleevi [mailto:r...@sleevi.com] 
Sent: Thursday, August 10, 2017 12:24 PM
To: Jeremy Rowley <jeremy.row...@digicert.com>
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Certificates with metadata-only subject fields

Can you provide an example of what you believe is a bigger issue that has been 
masked? Otherwise, it sounds like you're saying "Ignore the obvious errors, 
because maybe someone will find something non-obvious, and we don't want to 
miss out" - but that's a deeply flawed argument, and I would hope isn't the 
substance of what you're saying.

Note: I still disagree with you about the artificial ontology; all of these 
errors equally speak to the CA's ability to execute on Best Practices, such as 
using available tools that have been evangelized for over a year as something 
that can (and arguably should) be integrated into issuance pipelines. 
Discussions at this point are extremely relevant, as they speak to how well the 
CA is staying abreast of changes, as well as how effectively they're managing 
their subsidiaries - both issues that are key to public trust.

On Thu, Aug 10, 2017 at 2:17 PM, Jeremy Rowley via dev-security-policy 
<dev-security-policy@lists.mozilla.org 
<mailto:dev-security-policy@lists.mozilla.org> > wrote:

I strongly disagree. The discussion around errors like these masks the
bigger issues in the noise.  If there are bigger issues, let's find those.

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley 
<mailto:dev-security-policy-bounces%2Bjeremy.rowley> =digicert.com@lists.mozilla

.org] On Behalf Of David E. Ross via dev-security-policy
Sent: Wednesday, August 9, 2017 4:35 PM
To: mozilla-dev-security-pol...@lists.mozilla.org 
<mailto:mozilla-dev-security-pol...@lists.mozilla.org> 
Subject: Re: Certificates with metadata-only subject fields

On 8/9/2017 2:54 PM, Jonathan Rudenberg wrote:
>
>> On Aug 9, 2017, at 17:50, Peter Bowen <pzbo...@gmail.com 
>> <mailto:pzbo...@gmail.com> > wrote:
>>
>> The point of certlint was to help identify issues.  While I
>> appreciate it getting broad usage, I don't think pushing for
>> revocation of every certificate that trips any of the Error level checks
is productive.
>
> I agree, and I don't really have a position on the revocation of
certificates with errors that do not appear to have any security impact like
these.
>
> Jonathan
>
>

I strongly disagree.  Errors like this make me question whether the
certification authority is sufficiently competent to be trusted.  Small
errors can indicate an increased likelihood of serious errors.

--
David E. Ross
<http://www.rossde.com/>

President Trump demands loyalty to himself from Republican members of
Congress.  I always thought that members of Congress -- House and Senate --
were required to be loyal to the people of the United States.  In any case,
they all swore an oath of office to be loyal to the Constitution.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org 
<mailto: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 
<mailto:dev-security-policy@lists.mozilla.org> 
https://lists.mozilla.org/listinfo/dev-security-policy

smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Certificates with metadata-only subject fields

2017-08-10 Thread Jeremy Rowley via dev-security-policy

I strongly disagree. The discussion around errors like these masks the
bigger issues in the noise.  If there are bigger issues, let's find those. 

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of David E. Ross via dev-security-policy
Sent: Wednesday, August 9, 2017 4:35 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Certificates with metadata-only subject fields

On 8/9/2017 2:54 PM, Jonathan Rudenberg wrote:
> 
>> On Aug 9, 2017, at 17:50, Peter Bowen  wrote:
>>
>> The point of certlint was to help identify issues.  While I 
>> appreciate it getting broad usage, I don't think pushing for 
>> revocation of every certificate that trips any of the Error level checks
is productive.
> 
> I agree, and I don't really have a position on the revocation of
certificates with errors that do not appear to have any security impact like
these.
> 
> Jonathan
> 
> 

I strongly disagree.  Errors like this make me question whether the
certification authority is sufficiently competent to be trusted.  Small
errors can indicate an increased likelihood of serious errors.

--
David E. Ross

President Trump demands loyalty to himself from Republican members of
Congress.  I always thought that members of Congress -- House and Senate --
were required to be loyal to the people of the United States.  In any case,
they all swore an oath of office to be loyal to the Constitution.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Misissued certificates

2017-08-10 Thread Jeremy Rowley via dev-security-policy

This is interesting.  We had one Sub CA who mis-issued some pre-certs but
then never issued an actual certificate tied to the pre-certificate.  There
was a previous Mozilla discussion (link coming) where mis-issuance of a
pre-certificate was akin to mis-issuance of the certificate itself.  The
pre-certificates were later revoked at our request.  If no actual
certificate issued, the pre-cert falls out of scope of the BRs right? Since
it can't be used for actual server transactions thanks to the poison
extensions? Obviously they still fall within the Mozilla policy as they
contain serverAuth in the EKU.  However, should they be reported as issues
and should they be revoked in accordance with the BR?

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Nick Lamb via dev-security-policy
Sent: Thursday, August 10, 2017 10:44 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Misissued certificates

On Thursday, 10 August 2017 16:55:22 UTC+1, iden...@gmail.com  wrote:
> certificates contain the issue.  Three (3) of these are real 
> certificates; however, one has expired. We have revoked the other two 
> certificates. The remaining two (2) are pre-certificates.

To clear this up for anybody who didn't go look: They're specifically
pre-certificates _for_ the other two certificates, so there is nothing
further here that could be revoked.

And as Ryan writes, what we'd want to see here in m.d.s.policy isn't
revocations (though those are required by the BRs anyway so we do expect
them) but an investigation of what went wrong and a summary of what was done
to ensure we won't be back here reading about the same problems at the same
CAs.

Like an Accident Investigator my focus is not on "punishing the guilty" but
on the Prevention of Future Harm. We can't undo the fact that a certificate
was mis-issued, but we can try to reduce the number of future mis-issuances
by learning from past mistakes and putting in place technologies, policies
and practices that avoid mis-issuance in the future.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificates with less than 64 bits of entropy

2017-08-11 Thread Jeremy Rowley via dev-security-policy

They are no longer issuing from the digicert cross. The issue is within their 
PKI but  there should be no additional certificates chained to DigiCert roots

On Aug 11, 2017, at 8:33 AM, Ben Wilson 
<ben.wil...@digicert.com<mailto:ben.wil...@digicert.com>> wrote:

Apparently they haven’t yet, but we’ll assume that they will.
Does the community expect a remediation plan for their code and then a 
revocation-and-replacement plan?

Ben Wilson, JD, CISA, CISSP
VP Compliance
+1 801 701 9678


From: Alex Gaynor [mailto:agay...@mozilla.com]
Sent: Friday, August 11, 2017 8:31 AM
To: Ben Wilson <ben.wil...@digicert.com<mailto:ben.wil...@digicert.com>>
Cc: Jeremy Rowley 
<jeremy.row...@digicert.com<mailto:jeremy.row...@digicert.com>>; Jonathan 
Rudenberg <jonat...@titanous.com<mailto:jonat...@titanous.com>>; 
mozilla-dev-security-pol...@lists.mozilla.org<mailto:mozilla-dev-security-pol...@lists.mozilla.org>
Subject: Re: Certificates with less than 64 bits of entropy

Have they fixed whatever issue there is with their PKI infrastructure that 
leads to this issue? From skimming, I see this pool contains certs issued as 
recently as one month ago.

Alex

On Fri, Aug 11, 2017 at 10:26 AM, Ben Wilson via dev-security-policy 
<dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>>
 wrote:
With regard to Siemens, given the large number of certificates and the 
disruption that massive revocations will have on their infrastructure, what 
does this community expect them to do?

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+ben<mailto:dev-security-policy-bounces%2Bben>=digicert@lists.mozilla.org<mailto:digicert....@lists.mozilla.org>]
 On Behalf Of Jeremy Rowley via dev-security-policy
Sent: Thursday, August 10, 2017 12:01 PM
To: Jonathan Rudenberg <jonat...@titanous.com<mailto:jonat...@titanous.com>>; 
mozilla-dev-security-pol...@lists.mozilla.org<mailto:mozilla-dev-security-pol...@lists.mozilla.org>
Subject: RE: Certificates with less than 64 bits of entropy

Hi Jonathan,

InfoCert's sub CA was revoked on August 1, 2017. We'll reach out to Siemens. 
They moved to Quovadis a while ago and are no longer issuing from that Sub CA.

Jeremy

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+jeremy.rowley<mailto:dev-security-policy-bounces%2Bjeremy.rowley>=digicert@lists.mozilla.org<mailto:digicert@lists.mozilla.org>]
 On Behalf Of Jonathan Rudenberg via dev-security-policy
Sent: Thursday, August 10, 2017 9:26 AM
To: 
mozilla-dev-security-pol...@lists.mozilla.org<mailto:mozilla-dev-security-pol...@lists.mozilla.org>
Subject: Re: Certificates with less than 64 bits of entropy


> On Aug 10, 2017, at 11:20, Jonathan Rudenberg via dev-security-policy 
> <dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>>
>  wrote:
>
> QuoVadis (560)
>Siemens Issuing CA Internet Server 2016 (560)
>
> D-TRUST (224)
>D-TRUST SSL Class 3 CA 1 2009 (178)
>D-TRUST SSL Class 3 CA 1 EV 2009 (45)
>D-TRUST Root Class 3 CA 2 EV 2009 (1)
>
> DigiCert (85)
>Siemens Issuing CA Class Internet Server 2013 (82)
>InfoCert Web Certification Authority (3)
>
> Izenpe S.A. (62)
>EAEko Herri Administrazioen CA - CA AAPP Vascas (2) (62)
>
> Government of The Netherlands, PKIoverheid (Logius) (55)
>Digidentity Services CA - G2 (55)
>
> Government of Turkey, Kamu Sertifikasyon Merkezi (Kamu SM) (38)
>Cihaz Sertifikası Hizmet Sağlayıcı - Sürüm 4 (38)

It looks like my summary missed one QuoVadis intermediate:

Bayerische SSL-CA-2016-01 (3)

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org<mailto: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<mailto: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: Certificates with reserved IP addresses

2017-08-12 Thread Jeremy Rowley via dev-security-policy

The CTJ one was issued in 2013 and is a five year cert (which was also 
prohibited under the BRs at that time_.  It should have been revoked much 
earlier, of course.

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org]
 On Behalf Of Jonathan Rudenberg via dev-security-policy
Sent: Saturday, August 12, 2017 7:53 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Certificates with reserved IP addresses

Baseline Requirements section 7.1.4.2.1 prohibits ipAddress SANs from 
containing IANA reserved IP addresses and any certificates containing them 
should have been revoked by 2016-10-01.

There are seven unexpired unrevoked certificates that are known to CT and 
trusted by NSS containing reserved IP addresses.

The full list can be found at: https://misissued.com/batch/7/

DigiCert
TI Trust Technologies Global CA (5)
Cybertrust Japan Public CA G2 (1)

PROCERT
PSCProcert (1)

It’s also worth noting that three of the "TI Trust Technologies” certificates 
contain dnsNames with internal names, which are prohibited under the same BR 
section.

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

smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Symantec Update on SubCA Proposal

2017-08-13 Thread Jeremy Rowley via dev-security-policy

Hi wizard,

Although DigiCert will acquire the assets related to Symantec’s CA business, 
DigiCert is not required to use those assets in its business operations.  We 
are organizing the operations of DigiCert to meet the requirements established 
in the Managed CA proposal. This includes having all validation and issuance 
performed through DigiCert’s existing PKI and using DigiCert processes 
accompanied by DigiCert leadership.  

Our interpretation of the Google and Mozilla requirements is similar to yours – 
that the goal is to migrate from Symantec’s existing PKI to a third party while 
implementing systematic and operational controls over the issuing and 
validation processes.  Post close, we plan to continue towards these objectives 
using the path adopted by the browsers in the Managed CA process. This path 
includes regular audits during the transition, a migration away from Symantec’s 
issuing and validation systems, and implementation of operational controls to 
prevent mis-issuance.  Our plan is to transition completely away from the 
Symantec issuance platform and validation processes by December 1 and work 
towards the distrust dates set by Mozilla for the end of 2018.  

The Managed CA requirements seemed designed to (1) give Symantec time to 
reengineer processes and systems and (2) work towards rebuilding trust in the 
Symantec’s operations.  The acquisition eliminates the need to reengineer the 
process and makes the question of restoring trust moot.  With only DigiCert 
performing the validation and operating the CA, the risks identified to be 
fixed by the Managed CA proposal are remediated as of closing.

Of course, we’re always open to feedback and additional ideas on how to build 
community trust.  Feel free to message us or submit follow-up questions and 
ideas about how we can answer the community’s concerns. 

Thanks!

Jeremy

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org]
 On Behalf Of wizard--- via dev-security-policy
Sent: Friday, August 11, 2017 9:12 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Symantec Update on SubCA Proposal

Steve,

Thank you for responding relatively promptly (at least as compared to previous 
Symantec responses) to Devon's questions.

However, these responses seem to imply that a side effect of the sale *is* to 
skirt the remediation requirements imposed by Google and Mozilla. 

In particular, the agreed upon plan requires issuance (and information 
verification) by a managed SubCA that does *not* involve Symantec processes, 
equipment, personnel, etc., until trust in those equipment, people, and 
processes is established.

if Digicert were *not* acquiring any of the equipment/personnel/processes from 
Symantec, only the customers, this would seem to meet the spirit and letter of 
the Symantec remediation plan. 

However, the publicly announced details of the acquisition [Devon ref. 2] 
explicitly state that equipment and personnel will be transferred from Symantec 
to Digicert. Combined with the answers below, this means that as soon as the 
deal closes and this transfer occurs, there is no barrier to the 
formerly-Symantec-but-now-Digicert equipment and personnel from immediately 
assisting in the issuance of new certificates (presumably under the Digicert 
roots). This seems to go against the spirit (and possibly letter) of the 
remediation plan, which was designed to prevent the bad practices within the 
existing Symantec CA organization from being involved in further issuances 
until a level of trust could be demonstrated. 

Perhaps you or Digicert could clarify why you believe the above to not be the 
case.

Thank you.

On Friday, August 11, 2017 at 8:32:33 PM UTC-4, Steve Medin wrote:
> > -Original Message-
> > From: dev-security-policy [mailto:dev-security-policy-
> > bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of
> > Devon O'Brien via dev-security-policy
> > Sent: Wednesday, August 09, 2017 12:24 PM
> > To: mozilla-dev-security-pol...@lists.mozilla.org
> > Subject: [EXT] Re: Symantec Update on SubCA Proposal
> >
> > Hello m.d.s.p.,
> >
> > I'd just like to give the community a heads up that Chrome’s plan 
> > remains to put up a blog post echoing our recent announcement on 
> > blink-dev [1], but in the meantime, we are reviewing the facts 
> > related to Symantec’s sale of their PKI business to DigiCert [2].
> >
> > Recently, it has come to our attention that Symantec may have 
> > selected DigiCert from the RFP process to become a Managed CA 
> > Partner. As defined in Google’s first Managed CA proposal [3], then 
> > supported by Symantec’s commitment to “[cover] all aspects of the 
> > SubCA proposal” [4], and finally reiterated in Google’s final 
> > proposal [1], the requirement has always been that the Managed 
> > Partner Infrastructure be operated by an independent and 
> > non-affiliated CA while

RE: Certificates with invalidly long serial numbers

2017-08-10 Thread Jeremy Rowley via dev-security-policy

I disagree - 24 hours is enough to reissue the certificate, but  24 hours 
usually isn't enough to contact the subscriber, regardless of cert type. 

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org]
 On Behalf Of Ryan Sleevi via dev-security-policy
Sent: Thursday, August 10, 2017 4:13 PM
To: Jakob Bohm 
Cc: mozilla-dev-security-policy 
Subject: Re: Certificates with invalidly long serial numbers

Could you explain how it benefits Mozilla users to optimize for OV or EV, given 
that it does not provide any additional security value?

It seems far better for the security of users, and the ecosystem, to have such 
certificates revoked in 24 hours. If the subscriber's selection of certificate 
type (e.g. OV or EV) makes it difficult to replace, then that's a market choice 
they've made, given that it offers no objective security value over DV, and it 
being possible to replace that certificate with a DV certificate in a timely 
fashion.

24 hours is enough for most subscribers to get a reissued certificate. I don't 
think we should speculate about what cost it is (that's between them and the 
CA) or their selection of validation type (of which, for objective security 
value, only the domain name matters).

On Thu, Aug 10, 2017 at 5:39 PM, Jakob Bohm via dev-security-policy < 
dev-security-policy@lists.mozilla.org> wrote:

> But that would require the issuer of the replacement cert (which might 
> not be a fast-issue DV cert) to complete validation in something like 
> 36 hours, which is much shorter than the normal time taken to do 
> proper OV and/or EV validation.
>
> I have previously suggested 14 days for live certificates that don't 
> cause actual security issues.  This would be enough for most 
> subscribers to either get a reissued certificate (for free) from the 
> original CA or set up an account with a competing CA and get at least a basic 
> OV cert.
>
> On 10/08/2017 03:02, Jeremy Rowley wrote:
>
>> No objection to 72 hours v. 1 business day.  I agree it should be 
>> short and
>> 72 hours seems perfectly reasonable .
>>
>> -Original Message-
>> From: dev-security-policy
>> [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.
>> com@lists.mozilla
>> .org] On Behalf Of Paul Kehrer via dev-security-policy
>> Sent: Wednesday, August 9, 2017 4:57 PM
>> To: mozilla-dev-security-pol...@lists.mozilla.org
>> Subject: Re: Certificates with invalidly long serial numbers
>>
>> On Wednesday, August 9, 2017 at 9:20:02 AM UTC-5, Jeremy Rowley wrote:
>>
>>> All CAS are required to maintain the capability to process and 
>>> receive
>>>
>> revocation requests 24x7 under the baseline requirements. The 
>> headache is not with the CA. Rather, it's notifying the customer that 
>> their certificate will be revoked before the start of the next 
>> business day. Having a one to two business day rule  instead of 24 
>> hours for non compromise issues gives the end entity time to receive 
>> the notification and replace their certificate with a compliant 
>> version.
>>
>> I'm sure many customers would absolutely prefer that and on the 
>> surface it does sound like a good solution. However, I think it's 
>> another example of the general difference of opinion between people 
>> on this list around whether we should be holding CAs to the highest 
>> standards or not. These mis-issued certificates are typically not a 
>> security concern, but they speak to either ignorance on the part of 
>> CA operators or a pattern of lackadaisical controls within the 
>> issuance systems. Neither of these is acceptable behavior at this 
>> juncture. Conformance with the BRs has been mandatory for over 5 
>> years now.
>> Customers need to be made aware of the failures of their chosen 
>> providers and the responsibilities incumbent upon them as 
>> subscribers, and if their own certificate installation/replacement 
>> processes are sufficiently archaic as to make it difficult to replace 
>> a certificate in an automated fashion then they should rectify that 
>> immediately.
>>
>> That said, to continue the thought experiment, what does "1-2 
>> business days"
>> really mean?Does the CA get 1-2 business days followed by 1-2 for the 
>> customer? What if there's a holiday in the CA's country of operations 
>> followed by a holiday in the customer's home country? How quickly 
>> does this window extend to 2+ weeks? If you were to go down this path 
>> I'd strongly prefer it to be a hard deadline (e.g. 72 hours) and not 
>> anything related to business days.
>>
>>
>
> Enjoy
>
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com 
> Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10 This 
> public discussion message is non-binding and may contain errors.
> WiseMo - Remote Service Management for PCs, Phones and Embedded 
>

RE: Certificate with invalid dnsName issued from Baltimore intermediate

2017-07-18 Thread Jeremy Rowley via dev-security-policy

Some of these certs are really old.  Is there a reason people were using double 
dot names? Are they all mistakes in the certificate request or is there some 
logic behind them?

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org]
 On Behalf Of Tom via dev-security-policy
Sent: Tuesday, July 18, 2017 12:17 PM
To: Hanno Böck ; mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Certificate with invalid dnsName issued from Baltimore intermediate


The "www..*" search is also intersting, I think:
https://crt.sh/?dNSName=www..%25

crt.sh IDLogged At  ⇧   Not Before  IdentityIssuer Name
397448732016-10-02  2012-12-29  www..coinfling.com  
386479982016-10-01  2011-03-24  www..altmangroup.com
375324392016-10-01  2014-05-02  www..edm.me 
352341082016-09-26  2013-12-09  www..erhgroup.com.tw
337105522016-09-22  2009-08-04 www..webmail.collegeofidaho.edu
332788532016-09-20  2013-03-26  www..labpro2000.com 
329180042016-09-19  2013-04-30  www..getswapapp.com 
228356352016-06-22  2016-06-20  www..tapspace.org   
623 2015-10-07  2015-09-23  www..imypaths.com   
8584525 2015-07-24  2015-07-22  www..myacademicprogram.in   
8431374 2015-07-13  2015-07-06  www..marza.com.br   
8216255 2015-06-28  2015-06-25  www..mysummitortho.com  
4327936 2014-06-14  2014-06-12  www..mysummitortho.com  
4303228 2014-06-10  2008-12-03  www..wildlifelicense.com
3956875 2014-04-25  2014-04-23  www..mysummitortho.com  
2728659 2013-09-28  2013-09-25  www..marza.com.br   
637932  2013-03-26  2012-10-21  www..guidedstudies.com  
85797   2013-03-26  2012-07-01  www..mysummitortho.com  


Le 18/07/2017 à 17:57, Hanno Böck a écrit :
> More dotdot-certificates:
> 
> https://crt.sh/?id=34528113
> for autodiscover.amphenolcanada..com
> Expired 2012
> issued by Geotrust (aka symantec)
> 
> https://crt.sh/?id=3478078
> for PDC-LIB-WEB1.RBI1.rbi..in
> Expired 2016
> issued by Institute for Development and Research in Banking Technology
> 
> https://crt.sh/?id=4112846
> pkictslvws.dmdc.osd..mil
> expired 2016
> issued by U.S. Government
> 
> So all expired, but certainly at least the ones from 2016 are 
> worrying, indicating that the issuing CAs are failing at domain validation.
> 
> (Due to limitations in the search methodology - scraping crt.sh search 
> results and looping through tlds - I only searched for ..tld. It would 
> certainly be valuable to search further.)
> 

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


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Miss-issuance: URI in dNSName SAN

2017-07-25 Thread Jeremy Rowley via dev-security-policy

Each CA is required (under the BRs) to provide public information on how to
submit certificate problem reports, including mis-issued certificates. The
only way to properly notify the CA is through that mechanism as those are
monitored 24 hours. CAs participating on the list usually have a couple of
reps who monitor and participate, but not 24x7. I do agree there should be
penalties for missing the 24 hour requirement to give the BRs a bit more
teeth, but those penalties should be based on the proper notice process
being followed. 

I would also love to see a more standardized notice mechanism that is
universal to all CAs. Right now, notifying CAs is a pain as some have
different webforms, some use email, and some don't readily tell you how to
contact them about certificate problems.  

Jeremy

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Alex Gaynor via dev-security-policy
Sent: Tuesday, July 25, 2017 10:58 AM
To: Alex Gaynor 
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Miss-issuance: URI in dNSName SAN

Following up on this (and really several other threads). The BRs require
mis-issued certs to be revoked with 24 hours of the CA becoming aware. CAs
are required to track m.d.s.p. per the Mozilla Root Policy, so really
notifying this list _ought_ to qualify as notifying the CAs.

In any event, here are some certificates, by CA, that have been mis-issued
and linked on this list many days ago at this point:

PSCProcert - https://crt.sh/?id=124094761 - dNSName is a URI PSCProcert -
https://crt.sh/?id=175466182 - dNSName is for a .local domain Camerfirma
AAPP II - 2014 - https://crt.sh/?id=42531587 - dNSName is a URI AC
CAMERFIRMA AAPP - https://crt.sh/?id=5129200 - dNSName is a URI StartCom
Class 2 Primary Intermediate Server CA -
https://crt.sh/?id=10714112 - incorrect wildcard "*g10.net-lab.net"
StartCom Class 3 OV Server CA - https://crt.sh/?id=17295812 - incorrect
wildcard "*dev02.calendar42.com"
StartCom Class 1 DV Server CA - https://crt.sh/?id=78248795 - invalid
dNSName "-1ccenter.777chao.com"
TI Trust Technologies Global CA - https://crt.sh/?id=48682944 - invalid
wildcard "*nuvolaitaliana.it"
UniCredit Subordinate External - https://crt.sh/?id=44997156 - invalid
wildcard "*.*.rnd.unicredit.it"
Swisscom Smaragd CA 2 - https://crt.sh/?id=5982951 - invalid wildcard "*.*.
int.swisscom.ch"
Swisscom Smaragd CA 2 - https://crt.sh/?id=175444569 - dNSName is for a
.local domain Verizon Public SureServer CA G14-SHA2 -
https://crt.sh/?id=33626750 - dNSName is for a .test domain Verizon Public
SureServer CA G14-SHA2 - https://crt.sh/?id=12344381 - dNSName is for a
.local domain CLASS 2 KEYNECTIS CA - https://crt.sh/?id=42475510 - dNSName
is for a .corp domain EC-SectorPublic - https://crt.sh/?id=98706307 -
dNSName is for a .local domain

Should there be some penalty for the failure of CAs to revoke within the
time period required by the BRs?

Alex

On Sat, Jul 22, 2017 at 10:11 AM, alex.gaynor--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> It has now been several days, does Camerafirma intend to revoke these 
> certificates, as required by the BRs (within 24 hours of being notified)?
> ___
> 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

smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Certificate with invalid dnsName

2017-07-19 Thread Jeremy Rowley via dev-security-policy

Thank you, Charles and Tom, for bringing this to the forefront.  We have
contacted the cross-signed partner and asked for an explanation. We've also
demanded revocation within 24 hours and a full scan to determine whether any
other certificates exist.  

Jeremy 

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Charles Reiss via dev-security-policy
Sent: Wednesday, July 19, 2017 7:02 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Certificate with invalid dnsName

On 07/19/2017 06:03 PM, Tom wrote:
> Following that discovery, I've search for odd (invalid?) DNS names.
> Here is the list of certificated I've found, it may overlap some 
> discovery already reported.
> If I'm correct, theses certificate are not revoked, not expired, and 
> probably trusted by Mozilla (crt.sh issuer are marked trusted by 
> Mozilla, but not all).
> 
[snip]

Some additional problematic certs:

chains to Swisscom:
https://crt.sh/?id=175444569  wxadm.swissucc.local

chains to CATCert, notBefore in 2017:
https://crt.sh/?id=98706307   maritim4.mmaritim.local

chains to PROCERT, notBefore in 2017:
https://crt.sh/?id=175466182  fospuca.local

chains to Baltimore Cybertrust Root (DigiCert):
https://crt.sh/?id=12344381   lorweb.local

chains to Baltimore Cybertrust Root (DigiCert), notBefore in 2017:
https://crt.sh/?id=175469208  skbfep01.justica.local
https://crt.sh/?id=175469209  energy.ctd  and  pt

chains to QuoVadis, notBefore in 2017:
https://crt.sh/?id=175466199  devsrv.pe.siemens.info-com  (swapped -/.)

chains to DocuSign, notBefore in 2017:
https://crt.sh/?id=99149574   "www.immonotaireargus.com " (trailing space)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificate with invalid dnsName issued from Baltimore intermediate

2017-07-19 Thread Jeremy Rowley via dev-security-policy

You should also filter out expired certs as they aren't usable.

> On Jul 19, 2017, at 8:30 AM, Alex Gaynor via dev-security-policy 
>  wrote:
> 
> I think there might be a bug in your SQL, one of the offending certs is
> issued by "C=US, O=U.S. Government, OU=Department of Homeland Security,
> OU=Certification Authorities, OU=DHS CA4", who are revoked using OneCRL.
> 
> Alex
> 
> On Wed, Jul 19, 2017 at 10:08 AM, Rob Stradling via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
>> On 18/07/17 16:57, Hanno Böck via dev-security-policy wrote:
>> 
>> 
>>> (Due to limitations in the search methodology - scraping crt.sh
>>> search results and looping through tlds - I only searched for ..tld. It
>>> would certainly be valuable to search further.)
>>> 
>> 
>> Here's a report of all "double dot" certs known to crt.sh that are useable
>> for server authentication and chain to a root trusted by Mozilla:
>> 
>> https://docs.google.com/spreadsheets/d/18rvkdAd9A_N9_i2jIVhN
>> QVWODGhRtIT1iYoVms7Wb2w/edit?usp=sharing
>> 
>> 
>> P.S.
>> For anyone interested, here's the SQL I executed on the crt.sh DB to
>> produce this report:
>> 
>> SELECT c.ID, x509_notBefore(c.CERTIFICATE), x509_notAfter(c.CERTIFICATE),
>> array_to_string(array_agg(DISTINCT ci.NAME_VALUE), CHR(10)), ca.NAME
>>  FROM certificate_identity ci, ca, certificate c
>>  WHERE ci.NAME_VALUE LIKE '%..%'
>>AND ci.NAME_TYPE IN ('dNSName', 'commonName')
>>AND ci.ISSUER_CA_ID = ca.ID
>>AND ci.CERTIFICATE_ID = c.ID
>>AND EXISTS (
>>  SELECT 1
>>FROM ca_trust_purpose ctp
>>WHERE ci.ISSUER_CA_ID = ctp.CA_ID
>>  AND ctp.TRUST_PURPOSE_ID = 1  -- Server Authentication
>>  AND ctp.TRUST_CONTEXT_ID = 5  -- Mozilla
>>)
>>AND x509_isEKUPermitted(c.CERTIFICATE, '1.3.6.1.5.5.7.3.1')
>>  GROUP BY c.ID, x509_notBefore(c.CERTIFICATE),
>> x509_notAfter(c.CERTIFICATE), ci.NAME_VALUE, ca.NAME
>>  ORDER BY ca.NAME, x509_notAfter(c.CERTIFICATE) DESC;
>> 
>> --
>> Rob Stradling
>> Senior Research & Development Scientist
>> COMODO - Creating Trust Online
>> 
>> 
>> ___
>> 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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: DigiCert policy violation - non-disclosure of https://crt.sh/?id=160110886

2017-07-03 Thread Jeremy Rowley via dev-security-policy

Link please to a formal definition? As your email alleges a policy violation by 
one a cross-signed CAs, we take the investigation and response very seriously. 
I'd like to know the basis for the definition before formulating an official 
report and potentially penalizing the Sub CA for non-compliance.

-Original Message-
From: Rob Stradling [mailto:rob.stradl...@comodo.com] 
Sent: Monday, July 3, 2017 2:14 PM
To: Jeremy Rowley <jeremy.row...@digicert.com>; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: DigiCert policy violation - non-disclosure of 
https://crt.sh/?id=160110886

On 03/07/17 16:10, Jeremy Rowley via dev-security-policy wrote:
> I am surprised you decided to fork the thread from here 
> https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/sNDN6q26_uM
>  where this was already being discussed. Seems unnecessary.

Hi Jeremy.  That thread discusses a collection of intermediate certs that Tavis 
Ormandy found (when "crawling the pkcs7 blobs in public pdf
files") that were not at the time known to any CT logs.  Most of those 
intermediates did not need to be disclosed to Mozilla.

https://crt.sh/?id=160110886 was not in Tavis's collection and has not AFAICT 
been previously discussed on this list.

> I don't agree this is a policy violation, and I doubt any CA not involved in 
> the previously mentioned thread would even register that Mozilla may be 
> requiring disclosure of self-signed CAs.

See this post (from another recent thread) in which Ryan Sleevi explained why 
it makes sense to require disclosure of self-signed CA certs (for which the 
subject public key also exists in one or more trusted cross-certificates):
https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg07049.html

> The only disclosure requirement this root may fall under is the weird 
> "transitive" trust phrase in the policy. Note, this phrase is not defined in 
> 5280 or the Mozilla policy. Can you please link me to the definition in an 
> RFC? If there isn't one, until Mozilla clarifies what this means, the 
> definition of transitive trust is vague, meaning any third interpretation is 
> as good as the one you propose.

I think the meaning of "transitive" trust is actually quite simple.

A leaf cert (L) or intermediate cert (IC1) "transitively chains" to a root (R) 
if it is issued by an intermediate CA whose cert (IC2) chains to R.  The trust 
for L / IC1 is "transitive" because a relying party will only be able to verify 
that trust under certain circumstances - i.e., the RP needs to have been made 
aware of, and received a copy of, the IC2 cert.

If IC1 is issued directly by R, trust is "direct".  The RP is able to verify 
that trust under all circumstances, because R is built into the application / 
shipped with the trust store that the RP is using.

> Regardless, we will log the cert in the database pending resolution of the 
> dispute on what this means in the Mozilla policy to avoid the debate over 
> this particular root.
> 
> Jeremy
> 
> -Original Message-
> From: dev-security-policy 
> [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.m
> ozilla.org] On Behalf Of Rob Stradling via dev-security-policy
> Sent: Monday, July 3, 2017 5:32 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org 
> <dev-security-policy@lists.mozilla.org>
> Subject: DigiCert policy violation - non-disclosure of 
> https://crt.sh/?id=160110886
> 
> https://crt.sh/mozilla-disclosures#undisclosed has listed
> https://crt.sh/?id=160110886 for over 1 week.
> 
> This is a violation of section 5.3.2 of the Mozilla Root Store Policy
> v2.5 [1], which says (emphasis mine):
> "All certificates that are capable of being used to issue new certificates, 
> that are not technically constrained, and that directly or transitively chain 
> to a certificate included in Mozilla’s root program MUST be audited in 
> accordance with Mozilla’s Root Store Policy and MUST be publicly disclosed in 
> the CCADB by the CA that has their certificate included in Mozilla’s root 
> program. The CA with a certificate included in Mozilla’s root program MUST 
> disclose this information *within a week* of certificate creation, and before 
> any such subordinate CA is allowed to issue certificates."
> 
> It's a self-signed root certificate, but nonetheless there exists a signature 
> chain up to an included root and so disclosure is required.
> 
> 
> [1]
> https://www.mozilla.org/en-US/about/governance/policies/security-group
> /certs/policy/
> 
> 
> 
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
> 

--
Rob St

RE: DigiCert policy violation - non-disclosure of https://crt.sh/?id=160110886

2017-07-03 Thread Jeremy Rowley via dev-security-policy

Thanks Nick.  I'm missing something on this, so I appreciate the help so
far. I replied to each section.

Perhaps you have confused transitivity with commutativity or one of the
other simple properties. Transitivity is the property whereby if F(A,B) and
F(B,C) then F(A,C), for example the "greater than" binary relation is
transitive.
[JR] No confusion on what the arithmetic property, but I am having trouble
seeing how the transitive
trust applies to a self-signed and self-issued root with a publicly trusted
root.  Can you explain this more? 

The previously undisclosed certificate chains to a certificate which chains
to another certificate and so on until you reach one that is included in the
programme.  The Mozilla policy isn't trying to do anything very fancy here,
it's just spelling out how chains actually work, which is why it was a
concern that you seem so surprised this policy applies.
[JR] Well yeah - but this one is self-signed and self-issued, so how does it
chain? 

It seems _especially_ strange to object for this certificate that you had
never imagined it was necessary to disclose it, while perhaps half a dozen
similar certificates in the same family were previously disclosed. I would
suggest that rather than demonstrating DigiCert had no idea it was supposed
to disclose them, it instead indicates that DigiCert's processes for
actually ensuring this gets done are inadequate and so some random
proportion of sub-CAs may go undisclosed entirely by accident. That's not
good news.

[JR] No. We have a process for disclosing. We didn't issue the cert...
directly. This was issued by the Belgium government, who is obligated to
follow the policy themselves for all cross-signed certs.  However, this
isn't a cross-signed cert since it's self-signed.  We've never encountered
transitive trust as we don't reuse keys in our certs.  This is a unique
situation for us as it's a program that's long been deprecated that we
haven't been able to force migration from. 


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


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: DigiCert policy violation - non-disclosure of https://crt.sh/?id=160110886

2017-07-03 Thread Jeremy Rowley via dev-security-policy

"Previously accepted without comment" is hardly accurate. There's lots of
comments on the Mozilla policy (including Ben's comment on this very term).
And it's hardly fair to deride my lack of understanding on what transitive
trust entails in the digital certificate space considering it's outside of
the usual trust paths, not defined in the standard RFCs, and not the same as
the mathematical expression.  Instead, you're substituting one signed object
with another.  I'd figure two-way cross-signed objects would be more akin to
transitive trust than this scenario. After all, they are substitute trust
anchors instead of here where one isn't intended for trust in Mozilla.  It'd
be more helpful to provide additional educational resources rather than
snide comments.  I'd rather understand how it works than argue about what it
means. 

Yes - we pass all policy without comment on to the Sub CA.  

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Nick Lamb via dev-security-policy
Sent: Monday, July 3, 2017 3:22 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: DigiCert policy violation - non-disclosure of
https://crt.sh/?id=160110886

On Monday, 3 July 2017 22:00:00 UTC+1, Jeremy Rowley  wrote:
> Link please to a formal definition? As your email alleges a policy
violation by one a cross-signed CAs, we take the investigation and response
very seriously. I'd like to know the basis for the definition before
formulating an official report and potentially penalizing the Sub CA for
non-compliance.

You're asking for a "formal definition" of the word transitively. A word
which was in a policy you have previously accepted without comment, but NOW
you assert you aren't sure what it means. Transitivity is a normal concept
of mathematics and logic, its meaning here seems pretty transparent to me,
it's something we introduce (albeit not with trying to process cyclic
graphs) to secondary school children as part of their normal background in
arithmetic.

Was this policy, which you apparently didn't understand, passed without
comment to the affected Sub CA? Or did you figure that despite not
understanding what it meant you'd be able to somehow implement it?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: DigiCert policy violation - non-disclosure of https://crt.sh/?id=160110886

2017-07-04 Thread Jeremy Rowley via dev-security-policy

Thanks Rob.  Appreciate the links. 

-Original Message-
From: Rob Stradling [mailto:rob.stradl...@comodo.com] 
Sent: Tuesday, July 4, 2017 3:50 AM
To: Jeremy Rowley <jeremy.row...@digicert.com>; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: DigiCert policy violation - non-disclosure of 
https://crt.sh/?id=160110886

Hi Jeremy.  I'm not aware of any formal definition in any RFC of the phrase 
"transitively chains".

My recollection (and Hanno's [1]) is that this terminology dates back to the 
2010 write-up of the EFF SSL Observatory [2], in which the word "transvalid" 
was coined.


[1]
https://blog.hboeck.de/archives/847-Incomplete-Certificate-Chains-and-Transvalid-Certificates.html

[2]
https://events.ccc.de/congress/2010/Fahrplan/attachments/1777_is-the-SSLiverse-a-safe-place.pdf
Slide 29

On 03/07/17 21:59, Jeremy Rowley wrote:
> Link please to a formal definition? As your email alleges a policy violation 
> by one a cross-signed CAs, we take the investigation and response very 
> seriously. I'd like to know the basis for the definition before formulating 
> an official report and potentially penalizing the Sub CA for non-compliance.
> 
> -Original Message-
> From: Rob Stradling [mailto:rob.stradl...@comodo.com]
> Sent: Monday, July 3, 2017 2:14 PM
> To: Jeremy Rowley <jeremy.row...@digicert.com>; 
> mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: DigiCert policy violation - non-disclosure of 
> https://crt.sh/?id=160110886
> 
> On 03/07/17 16:10, Jeremy Rowley via dev-security-policy wrote:
>> I am surprised you decided to fork the thread from here 
>> https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/sNDN6q26_uM
>>  where this was already being discussed. Seems unnecessary.
> 
> Hi Jeremy.  That thread discusses a collection of intermediate certs 
> that Tavis Ormandy found (when "crawling the pkcs7 blobs in public pdf
> files") that were not at the time known to any CT logs.  Most of those 
> intermediates did not need to be disclosed to Mozilla.
> 
> https://crt.sh/?id=160110886 was not in Tavis's collection and has not AFAICT 
> been previously discussed on this list.
> 
>> I don't agree this is a policy violation, and I doubt any CA not involved in 
>> the previously mentioned thread would even register that Mozilla may be 
>> requiring disclosure of self-signed CAs.
> 
> See this post (from another recent thread) in which Ryan Sleevi explained why 
> it makes sense to require disclosure of self-signed CA certs (for which the 
> subject public key also exists in one or more trusted cross-certificates):
> https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg
> 07049.html
> 
>> The only disclosure requirement this root may fall under is the weird 
>> "transitive" trust phrase in the policy. Note, this phrase is not defined in 
>> 5280 or the Mozilla policy. Can you please link me to the definition in an 
>> RFC? If there isn't one, until Mozilla clarifies what this means, the 
>> definition of transitive trust is vague, meaning any third interpretation is 
>> as good as the one you propose.
> 
> I think the meaning of "transitive" trust is actually quite simple.
> 
> A leaf cert (L) or intermediate cert (IC1) "transitively chains" to a root 
> (R) if it is issued by an intermediate CA whose cert (IC2) chains to R.  The 
> trust for L / IC1 is "transitive" because a relying party will only be able 
> to verify that trust under certain circumstances - i.e., the RP needs to have 
> been made aware of, and received a copy of, the IC2 cert.
> 
> If IC1 is issued directly by R, trust is "direct".  The RP is able to verify 
> that trust under all circumstances, because R is built into the application / 
> shipped with the trust store that the RP is using.
> 
>> Regardless, we will log the cert in the database pending resolution of the 
>> dispute on what this means in the Mozilla policy to avoid the debate over 
>> this particular root.
>>
>> Jeremy
>>
>> -Original Message-
>> From: dev-security-policy
>> [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.
>> m ozilla.org] On Behalf Of Rob Stradling via dev-security-policy
>> Sent: Monday, July 3, 2017 5:32 AM
>> To: mozilla-dev-security-pol...@lists.mozilla.org
>> <dev-security-policy@lists.mozilla.org>
>> Subject: DigiCert policy violation - non-disclosure of
>> https://crt.sh/?id=160110886
>>
>> https://crt.sh/mozilla-disclosures#undisclosed has listed
>> https://crt.sh/?id=160110886 for over 1 week.
>>
>> This is a violation of section 5.

RE: DigiCert policy violation - non-disclosure of https://crt.sh/?id=160110886

2017-07-04 Thread Jeremy Rowley via dev-security-policy

I'm an idiot. The discussion wasn't meant to be a red herring.  Just a
momentary lapse in intelligence...

It really looks like this from a validation perspective, right? EE ->
Self-signed -> Issuing CA (as it has the same key) -> Digicert Root

Yeah - I agree it should have been disclosed. Apologies for the confusion. 

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Nick Lamb via dev-security-policy
Sent: Tuesday, July 4, 2017 2:05 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: DigiCert policy violation - non-disclosure of
https://crt.sh/?id=160110886

On Tuesday, 4 July 2017 02:37:36 UTC+1, Jeremy Rowley  wrote:
> [JR] Well yeah - but this one is self-signed and self-issued, so how 
> does it chain?

This seems to be a source of confusion for a lot of people, several people
have posted queries about it to Stack Overflow or its sister Q systems
over the years too. It chains because the Issuer is also the Subject of a
(different) trusted, certificate. To decide whether a certificate chains we
don't need to look at its Subject at all, even if the Subject is itself.

The self-signed, self-issued certificate is a loop in the PKI graph. But
just because it's a loop very much does NOT mean that it isn't connected to
the rest of the graph, nor does it mean that client software trying to make
a chain should give up and decide it's a root. In fact some systems (I
believe including in the Web PKI) already rely on being able to get pst the
loop if it's presented as an intermediate.

I'm glad that transitivity was a red herring and in fact your understanding
of what is to be disclosed lines up with everybody else's except for this
blind spot about self-signed certificates.

The Belgian government seems to have understood that this certificate was to
be treated like any other trusted certificate, it was for example listed in
their audit documents, the only oversight was that it wasn't disclosed to
Mozilla via the common database. As I said, I believe this is a process
shortcoming, and I grasp that you don't feel this is directly DigiCert's
responsibility, but of course the Belgian government is not a root programme
member, so DigiCert ends up answering for what they do here on m.d.s.policy.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: DigiCert policy violation - non-disclosure of https://crt.sh/?id=160110886

2017-07-03 Thread Jeremy Rowley via dev-security-policy

I am surprised you decided to fork the thread from here 
https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/sNDN6q26_uM 
where this was already being discussed. Seems unnecessary. 

I don't agree this is a policy violation, and I doubt any CA not involved in 
the previously mentioned thread would even register that Mozilla may be 
requiring disclosure of self-signed CAs.  The only disclosure requirement this 
root may fall under is the weird "transitive" trust phrase in the policy. Note, 
this phrase is not defined in 5280 or the Mozilla policy. Can you please link 
me to the definition in an RFC? If there isn't one, until Mozilla clarifies 
what this means, the definition of transitive trust is vague, meaning any third 
interpretation is as good as the one you propose.  

Regardless, we will log the cert in the database pending resolution of the 
dispute on what this means in the Mozilla policy to avoid the debate over this 
particular root. 

Jeremy

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org]
 On Behalf Of Rob Stradling via dev-security-policy
Sent: Monday, July 3, 2017 5:32 AM
To: mozilla-dev-security-pol...@lists.mozilla.org 

Subject: DigiCert policy violation - non-disclosure of 
https://crt.sh/?id=160110886

https://crt.sh/mozilla-disclosures#undisclosed has listed
https://crt.sh/?id=160110886 for over 1 week.

This is a violation of section 5.3.2 of the Mozilla Root Store Policy
v2.5 [1], which says (emphasis mine):
"All certificates that are capable of being used to issue new certificates, 
that are not technically constrained, and that directly or transitively chain 
to a certificate included in Mozilla’s root program MUST be audited in 
accordance with Mozilla’s Root Store Policy and MUST be publicly disclosed in 
the CCADB by the CA that has their certificate included in Mozilla’s root 
program. The CA with a certificate included in Mozilla’s root program MUST 
disclose this information *within a week* of certificate creation, and before 
any such subordinate CA is allowed to issue certificates."

It's a self-signed root certificate, but nonetheless there exists a signature 
chain up to an included root and so disclosure is required.


[1] 
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: SRVNames in name constraints

2017-07-03 Thread Jeremy Rowley via dev-security-policy

Isn't this ballot ready to go?  If we start the review period now, it'll be
passed by the time the Mozilla policy is updated.

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Peter Bowen via dev-security-policy
Sent: Monday, July 3, 2017 10:30 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: SRVNames in name constraints

In reviewing the Mozilla CA policy, I noticed one bug that is probably my
fault.  It says:

"name constraints which do not allow Subject Alternative Names (SANs) of any
of the following types: dNSName, iPAddress, SRVName, rfc822Name"

SRVName is not yet allowed by the CA/Browser Forum Baseline Requirements
(BRs), so I highly doubt any CA has issued a cross-certificate containing
constraints on SRVName-type names.  Until the Forum allows such issuance, I
think this requirement should be changed to remove SRVName from the list.
If the Forum does allow such in the future, adding this back can be
revisited at such time.

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

smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: CA Validation quality is failing

2017-04-26 Thread Jeremy Rowley via dev-security-policy

Status Update: 

We are still scanning our database to discover all certificates containing 
incorrect data. So far, the count is at 1510.  The issues fall into two 
categories: 1) a failure to properly convey that BRs prohibit inclusion of meta 
data (BR 7.1.4.2.2.j) and 2) auto-population of data in the order that 
validation forgot to clear before issuing the certificate. 

On the training issue, the validation team inserted characters like "-", "." or 
other similar information in approximately 1000 certificates. This information 
asserted that the field was not applicable. The remaining 500 included 
auto-population data. The auto-population took three formats (such as a number 
representing the country code) depending on the customer's location and access 
to our certificate management platform. Interestingly, the validation database 
contains the correct documentation. However, we failed to properly update the 
certificate information to match the validated data.

Since Mike reported the issue, we've patched our system to prevent meta-data 
and made substantial improvements to the validation process. These improvements 
help identify mis-matches between validation information and certificate data.

We also started the revocation process for the 500 certificates containing 
meta-data. However, we wanted to ask about the 1000 certificates containing 
data indicating the field was not applicable. We recognize these were not 
properly issued, but I am curious whether revocation is required by Mozilla in 
this case. Should we start revoking those certificates as well despite the 
certificate information clearly not indicating a state/province? My thought is 
yes because of BR 4.9.1.1:

9. The CA is made aware that the Certificate was not issued in accordance with 
these Requirements or the
CA’s Certificate Policy or Certification Practice Statement;

I don't think #10 applies because the information is accurate - the field is 
not applicable:
10. The CA determines that any of the information appearing in the Certificate 
is inaccurate or misleading;

Thoughts? 

Jeremy


-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org]
 On Behalf Of Jeremy Rowley via dev-security-policy
Sent: Thursday, April 20, 2017 6:11 PM
To: mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org>
Subject: RE: CA Validation quality is failing

Thanks Mike for bringing this up. We’ve looked into it and have an initial 
report to share.

After receiving the email on the Mozilla list, we investigated the identified 
certificates and discovered a couple of very related issues in our process that 
led to certificates with bad info:
1. As Jakob pointed out, part of the issue was that our intake form required a 
state if US was selected. As country is the last requested field, the state 
only became optional after the customer completed the rest of the form. This 
led to a lot of customers submitting bad data.  
2. We have an old tool that generates information based on a customer’s 
location. This tool helps customers create CSRs and complete certificate 
requests. The tool inserts bad data into some fields if the field is left blank 
by the customer. The result was customers using this tool outside of the US had 
numbers included in the state field.  
3.  There was a gap in our validation process. This is the more important issue 
as the validation process should have caught the bad data inserted by the other 
two issues. Although we are obtaining validation documents from the appropriate 
government entity, the data submitted via the tool or intake form was not 
properly being updated with retrieved validated information. The end result was 
that the bad CSR data was submitted for signing instead of the data listed on 
the government document. This was a personnel problem, not a failure in our 
system as the validation staff was not appropriately updating the required 
signing fields.

So far, we have identified approximately 600 certificates that have the wrong 
state, zip, or locality. This is just a measurement of the problem scope and 
not the exact number as we are still reviewing are certificate database using a 
mapping API to determine whether the address exists. We expect the search to 
have a lot of false positives initially but provide a maximum scope of the 
problem. In parallel, we are contacting each customer with a non-compliant 
certificate, replacing the certificate, and revoking the certificate.  All 
mis-matched certificates are being uploaded to the Google and DigiCert CT logs. 

To fix our process, we are planning the following:
a.  We are immediately deprecating our geolocation tool and updating our intake 
form to help reduce the amount of bad data. 
b. We are updating our validation process to flag the differences in validation 
data and customer-provided data. 
c. We are prov

RE: Symantec Conclusions and Next Steps

2017-04-27 Thread Jeremy Rowley via dev-security-policy

Your post made me realize that we never publicly posted the status of these
last few CAs. Sorry about that.  Here's the plan:

1. ABB - ABB was supposed to be technically constrained (and is restricted
to certain names). However, the technical constraints were added incorrectly
and didn't exclude IPv6.  We're working with them to update the intermediate
with a properly constrained sub CA.

2. Bechtel - The Bechtel intermediates are scheduled for revocation the last
day of April.

3. Nets Norway - This intermediate lacked an EKU but was constrained to
certain domain names under Nets Norway's control. Nets Norway is no longer
using the intermediate but would like to leave the intermediate active until
the certs expire. I'm not sure what to do on this one. Any thoughts? 

4. Belgium Roots - The Belgium roots have audits now. We are waiting on the
audit report publication to change the status. The reports were provided to
the browsers but aren't available publicly yet. The Belgium CAs only issue
client certificates. 

Jeremy

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Rob Stradling via dev-security-policy
Sent: Thursday, April 27, 2017 4:38 AM
To: mozilla-dev-security-policy

Subject: Re: Symantec Conclusions and Next Steps

On 26/04/17 21:21, Rob Stradling via dev-security-policy wrote:

> (Note: A few of the non-Symantec entries currently listed by 
> https://crt.sh/mozilla-disclosures#undisclosed are false positives, I 
> think.  It looks like Kathleen has marked some roots as "Removed" on 
> CCADB ahead of the corresponding certdata.txt update on mozilla-central).

Ah, I take that back.  The March certdata.txt update did hit mozilla-central
on 11th April, but I missed an alert.  I've just pushed that update to
crt.sh.

https://crt.sh/mozilla-disclosures#undisclosed is currently free of false
positives.  It shows that DigiCert, StartCom and Symantec are currently
out-of-compliance with Mozilla's disclosure requirement.

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

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

smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Symantec Conclusions and Next Steps

2017-04-27 Thread Jeremy Rowley via dev-security-policy

Thanks Alex. Greatly appreciated.

From: Alex Gaynor [mailto:agay...@mozilla.com]
Sent: Thursday, April 27, 2017 2:05 PM
To: Jeremy Rowley <jeremy.row...@digicert.com>
Cc: Rob Stradling <rob.stradl...@comodo.com>; mozilla-dev-security-policy 
<mozilla-dev-security-pol...@lists.mozilla.org>
Subject: Re: Symantec Conclusions and Next Steps

On Thu, Apr 27, 2017 at 3:52 PM, Jeremy Rowley via dev-security-policy 
<dev-security-policy@lists.mozilla.org 
<mailto:dev-security-policy@lists.mozilla.org> > wrote:

Your post made me realize that we never publicly posted the status of these
last few CAs. Sorry about that.  Here's the plan:

1. ABB - ABB was supposed to be technically constrained (and is restricted
to certain names). However, the technical constraints were added incorrectly
and didn't exclude IPv6.  We're working with them to update the intermediate
with a properly constrained sub CA.

2. Bechtel - The Bechtel intermediates are scheduled for revocation the last
day of April.

3. Nets Norway - This intermediate lacked an EKU but was constrained to
certain domain names under Nets Norway's control. Nets Norway is no longer
using the intermediate but would like to leave the intermediate active until
the certs expire. I'm not sure what to do on this one. Any thoughts?

To save everyone else 3 minutes of search crt.sh, the oldest cert that I saw 
under this intermediate was November 2019.

Alex

4. Belgium Roots - The Belgium roots have audits now. We are waiting on the
audit report publication to change the status. The reports were provided to
the browsers but aren't available publicly yet. The Belgium CAs only issue
client certificates.

Jeremy

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley 
<mailto:dev-security-policy-bounces%2Bjeremy.rowley> 
=digicert.com@lists.mozilla
.org] On Behalf Of Rob Stradling via dev-security-policy
Sent: Thursday, April 27, 2017 4:38 AM
To: mozilla-dev-security-policy
<mozilla-dev-security-pol...@lists.mozilla.org 
<mailto:mozilla-dev-security-pol...@lists.mozilla.org> >
Subject: Re: Symantec Conclusions and Next Steps

On 26/04/17 21:21, Rob Stradling via dev-security-policy wrote:

> (Note: A few of the non-Symantec entries currently listed by
> https://crt.sh/mozilla-disclosures#undisclosed are false positives, I
> think.  It looks like Kathleen has marked some roots as "Removed" on
> CCADB ahead of the corresponding certdata.txt update on mozilla-central).

Ah, I take that back.  The March certdata.txt update did hit mozilla-central
on 11th April, but I missed an alert.  I've just pushed that update to
crt.sh.

https://crt.sh/mozilla-disclosures#undisclosed is currently free of false
positives.  It shows that DigiCert, StartCom and Symantec are currently
out-of-compliance with Mozilla's disclosure requirement.

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org 
<mailto: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 
<mailto:dev-security-policy@lists.mozilla.org>
https://lists.mozilla.org/listinfo/dev-security-policy

smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Certificates with invalidly long serial numbers

2017-08-08 Thread Jeremy Rowley via dev-security-policy

24 hours is super short when it's a Saturday morning at 4 am and it’s a 
European government entity. I agree that is what the policy says now, but, for 
lower risk items, the policy should change, preferably to at least one business 
day. 

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org]
 On Behalf Of Alex Gaynor via dev-security-policy
Sent: Tuesday, August 8, 2017 12:46 PM
To: Jakob Bohm 
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Certificates with invalidly long serial numbers

It's from the BRs 4.9.1.1:

 The CA SHALL revoke a Certificate within 24 hours if one or more of the 
following occurs:

It's also not a penalty on the CA, it's a remediation step for them to 
undertake.

Alex

On Tue, Aug 8, 2017 at 2:43 PM, Jakob Bohm via dev-security-policy < 
dev-security-policy@lists.mozilla.org> wrote:

> Some people seemed to require 24-hour revocation of these, which I 
> also find possibly excessive.
>
> On 08/08/2017 20:28, Alex Gaynor wrote:
>
>> I think you're largely objecting to a strawman, no one is proposing 
>> revoking trust in any of these threads.
>>
>> The only CAs that have ever had _any_ penalty applied to them have 
>> been for grotesque abuse of the trust vested in them.
>>
>> Alex
>>
>> On Tue, Aug 8, 2017 at 2:25 PM, Jakob Bohm via dev-security-policy < 
>> dev-security-policy@lists.mozilla.org> wrote:
>>
>> On 08/08/2017 18:43, Ryan Sleevi wrote:
>>>
>>> On Tuesday, August 8, 2017 at 11:05:06 PM UTC+9, Jakob Bohm wrote:

 I was not advocating "letting everyone decide".  I was advocating 
 that
> Mozilla show some restraint, intelligence and common sense in 
> wielding the new weapons that certlint and crt.sh have given us.
>
> This shouldn't be race as to who wields the weapon first, 
> forgiving CAs only if they happen to report faster than some other 
> newsgroup participant.
>
> This is similar to if a store boss gets a new surveillance camera 
> in the shop and sees that some employees are taking extra breaks 
> when there are few customers in the store.  It would be 
> unreasonable for such a store boss to discipline this with similar 
> zeal as seeing some employees genuinely steeling cash out of the 
> register or selling stolen items out of the back door.  Instead 
> the fact that they work less when there is less work to do should 
> inspire reevaluation of any old rule that they are not allowed to 
> have a watercooler chat during work hours.
>
> Now such a reevaluation might result in requiring them to use such 
> occasions to clean the floors or do some other chores (Mozilla equiv:
> Deciding that the rule is important for good reason and needs to 
> be followed in the future) or it could result in relaxing the rule 
> as long as they stand ready the moment a customer arrives (Mozilla equiv:
> Relaxing the requirement, initially just for Mozilla, later 
> perhaps as a BR change).
>
> Dogmatically insisting on enforcing rules that were previously not 
> enforced due to lack of detection, just because "rules are rules" 
> or other such arguments seems overzealous.
>
>
> Such tools have been available for over a year. CAs have been 
> aware of
 this, the ability to run it over their own corpus and self-detect 
 and self-report. These tools, notably, were created by one of the 
 newest CA applicants - Amazon - based on a methodical study of what 
 is required of a CA.

 Your attempts to characterize it as overzealous ignore this 
 entirely. At this point, it's gross negligence, and attempts to 
 argue otherwise merely suggest a lack of understanding or concern 
 for standards compliance and interoperability.

 Mozilla has already communicated to CAs these tools exist and their 
 relevance to CAs.

 Perhaps we can move on from misguided apologetics and instead focus 
 on how to make things better. Suggestions we ignore these, at this 
 point, are neither productive nor relevant. Attempts to suggest 
 tortured metaphors are like attempting to suggest rich people 
 deserve to be robbed, or poor people just need to work harder - 
 arguments that are both hollow and borderline offensive in their 
 reductionism. A pattern of easily preventable misissuance has been 
 happening,CAs have been repeatedly told to self-detect, and 
 clearly, some CAs, like presumably some businesses, aren't taking 
 security seriously. That needs to stop.

 I am questioning the fairness of applying these tools, which did 
 not
>>> exist when the rules were written, to enforce every rule with the 
>>> same high weight.  I am not apologizing for bad behavior, I am 
>>> saying if everybody gets scrutinized this hard, we will

RE: High traffic on this list, and Mozilla root program involvement

2017-08-08 Thread Jeremy Rowley via dev-security-policy

Do you want that added as a new bug for all the issues listed?  

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Gervase Markham via dev-security-policy
Sent: Tuesday, August 8, 2017 10:02 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: High traffic on this list, and Mozilla root program involvement

Hi everyone,

Wow, traffic on this group has exploded :-) Thank you to everyone who has
been bringing incidents to our attention.

Clearly, many of these items need official responses and action from
representatives of the Mozilla root program. I have been on holiday quite a
lot recently, and that includes this week, and any time I have had has been
fighting fires relating to my other responsibilities and requirements placed
on me. But please rest assured, all this has not been forgotten.

In the mean time, I would hope CAs would be picking up incidents relating to
themselves, doing investigations and publishing best-practice-style incident
reports here once those investigations were concluded. I probably need to
write a wiki page on this, but in brief best practice involves much more
than "we revoked the certificates concerned", it needs to say "this is how
this happened", and "this is what we've done/are doing to make sure it won't
happen again".

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

smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CA Problem Reporting Mechanisms

2017-08-08 Thread Jeremy Rowley via dev-security-policy

+1. CAs should be required to support certificate problem reports sent through 
a specified email address. It simplifies the process a lot if CAs use at least 
one common mechanism.

> On Aug 8, 2017, at 12:22 PM, Jonathan Rudenberg via dev-security-policy 
>  wrote:
> 
> 
>> On Aug 8, 2017, at 10:36, David E. Ross via dev-security-policy 
>>  wrote:
>> 
>> On 8/7/2017 8:09 PM, Jonathan Rudenberg wrote:
>>> 
 On May 17, 2017, at 07:24, Gervase Markham via dev-security-policy 
  wrote:
 
 On 16/05/17 02:26, userwithuid wrote:
> After skimming the responses and checking a few CAs, I'm starting to
> wonder: Wouldn't it be easier to just add another mandatory field to
> the CCADB (e..g. "revocation contact"), requiring $URL or $EMAIL via
> policy and just use that to provide a public list?
 
 Well, such contacts are normally per CA rather than per root. I guess we
 could add it on the CA's entry.
>>> 
>>> I’ve been reporting a fair amount of misissuance this week, and the 
>>> responses to the Problem Reporting question in the April CA communication 
>>> leave a lot to be desired. Several CAs do not have any contact details at 
>>> all, and others require filling forms with captchas.
>>> 
>>> I think it’d be very useful if CAs were required maintain a problem 
>>> reporting email address and keep it current in the CCADB, this requirement 
>>> could go in the Mozilla Root Store policy or the CCADB policy. If they want 
>>> to also maintain other modes of contact, they can but no matter what an 
>>> email address should be required.
>>> 
>>> Jonathan
>>> 
>> 
>> I think that a public point of contact for a certification authority was
>> a requirement under Mozilla's policy.  I cannot find such a requirement
>> now unless the Baseline Requirements, which are included by reference in
>> Mozilla's policy, require it.
> 
> Yes, section 4.9.3 of the Baseline Requirements says:
> 
>> The CA SHALL provide Subscribers, Relying Parties, Application Software 
>> Suppliers, and other third parties with clear instructions for reporting 
>> suspected Private Key Compromise, Certificate misuse, or other types of 
>> fraud, compromise, misuse, inappropriate conduct, or any other matter 
>> related to Certificates. The CA SHALL publicly disclose the instructions 
>> through a readily accessible online means.
> 
> However, it does not specify that email is required. I’m proposing that 
> Mozilla require that one of the methods for reporting be email and that the 
> email address be recorded in the CCADB.
> 
> Jonathan
> ___
> 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: High traffic on this list, and Mozilla root program involvement

2017-08-09 Thread Jeremy Rowley via dev-security-policy

I was thinking you should just have the Cas add them all for you.  Makes it
easier on you and demonstrates they are tracking and remediating these
issues.  If I were going to create a bug for these in Mozilla would you
prefer to see one bug per issue on one bug per CA. For example, should there
be a bug for all DigiCert issues or should there be one that describes too
long of serial number and another that says the field contains meta-data? 

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Gervase Markham via dev-security-policy
Sent: Wednesday, August 9, 2017 9:34 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: High traffic on this list, and Mozilla root program involvement

On 09/08/17 00:12, Jeremy Rowley wrote:
> Do you want that added as a new bug for all the issues listed?

I'm not sure I follow. Do I want what added?

I will be filing any additional appropriate bugs when I get around to
triaging all the messages in this forum.

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


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Certificates with metadata-only subject fields

2017-08-09 Thread Jeremy Rowley via dev-security-policy

And this is exactly why we need separate tiers of revocation. Here, there is 
zero risk to the end user.  I do think it should be fixed and remediated, but 
revoking all these certs within 24 hours seems unnecessarily harsh.  I think 
there was a post about this a while ago, but I haven't been able to find it.  
If someone remembers where it was, I'd appreciate it.

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org]
 On Behalf Of Jonathan Rudenberg via dev-security-policy
Sent: Wednesday, August 9, 2017 10:08 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Certificates with metadata-only subject fields

Baseline Requirements section 7.1.4.2.2(j) says:

> All other optional attributes, when present within the subject field, MUST 
> contain information that has been verified by the CA. Optional attributes 
> MUST NOT contain metadata such as ‘.’, ‘‐‘, and ‘ ‘ (i.e. space) characters, 
> and/or any other indication that the value is absent, incomplete, or not 
> applicable.

There are 522 unexpired unrevoked certificates known to CT issued after 
2015-11-01 that are trusted by NSS for server authentication and have at least 
one subject field that only contains ASCII punctuation characters.

The full list can be found here: https://misissued.com/batch/5/

Since there are so many, I have included a list of the CCADB owner, 
intermediate commonName, and count of certificates for the 311 certificates in 
this batch that were issued in the last 365 days so that the relevant CAs can 
add the appropriate technical controls and policy to comply with this 
requirement in the future. Please let me know if there is any additional 
information that would be useful.

Jonathan

—

DigiCert (131)
Cybertrust Japan Public CA G3 (64)
DigiCert SHA2 Extended Validation Server CA (36)
DigiCert SHA2 High Assurance Server CA (12)
TERENA SSL CA 3 (7)
DigiCert SHA2 Secure Server CA (6)
Cybertrust Japan EV CA G2 (6)

GlobalSign (62)
GlobalSign Organization Validation CA - SHA256 - G2 (46)
GlobalSign Extended Validation CA - SHA256 - G2 (8)
GlobalSign Extended Validation CA - SHA256 - G3 (8)

Symantec / VeriSign (35)
Symantec Class 3 Secure Server CA - G4 (32)
Symantec Class 3 EV SSL CA - G3 (2)
Wells Fargo Certificate Authority WS1 (1)

Symantec / GeoTrust (34)
GeoTrust SSL CA - G3 (25)
GeoTrust SHA256 SSL CA (5)
RapidSSL SHA256 CA (2)
GeoTrust Extended Validation SHA256 SSL CA (2)

Comodo (19)
COMODO RSA Organization Validation Secure Server CA (11)
COMODO RSA Extended Validation Secure Server CA (8)

Symantec / Thawte (17)
thawte SSL CA - G2 (12)
thawte SHA256 SSL CA (3)
thawte EV SSL CA - G3 (2)

T-Systems International GmbH (Deutsche Telekom) (6)
Zertifizierungsstelle FH Duesseldorf - G02 (3)
TeleSec ServerPass Class 2 CA (2)
Helmholtz-Zentrum fuer Infektionsforschung (1)

QuoVadis (3)
QuoVadis EV SSL ICA G1 (2)
QuoVadis Global SSL ICA G2 (1)

SECOM Trust Systems Co. Ltd. (2)
NII Open Domain CA - G4 (2)

SwissSign AG (1)
SwissSign Server Gold CA 2014 - G22 (1)

Entrust (1)
Entrust Certification Authority - L1K (1) 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Certificates with invalidly long serial numbers

2017-08-09 Thread Jeremy Rowley via dev-security-policy

No objection to 72 hours v. 1 business day.  I agree it should be short and
72 hours seems perfectly reasonable . 

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Paul Kehrer via dev-security-policy
Sent: Wednesday, August 9, 2017 4:57 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Certificates with invalidly long serial numbers

On Wednesday, August 9, 2017 at 9:20:02 AM UTC-5, Jeremy Rowley wrote:
> All CAS are required to maintain the capability to process and receive
revocation requests 24x7 under the baseline requirements. The headache is
not with the CA. Rather, it's notifying the customer that their certificate
will be revoked before the start of the next business day. Having a one to
two business day rule  instead of 24 hours for non compromise issues gives
the end entity time to receive the notification and replace their
certificate with a compliant version.

I'm sure many customers would absolutely prefer that and on the surface it
does sound like a good solution. However, I think it's another example of
the general difference of opinion between people on this list around whether
we should be holding CAs to the highest standards or not. These mis-issued
certificates are typically not a security concern, but they speak to either
ignorance on the part of CA operators or a pattern of lackadaisical controls
within the issuance systems. Neither of these is acceptable behavior at this
juncture. Conformance with the BRs has been mandatory for over 5 years now.
Customers need to be made aware of the failures of their chosen providers
and the responsibilities incumbent upon them as subscribers, and if their
own certificate installation/replacement processes are sufficiently archaic
as to make it difficult to replace a certificate in an automated fashion
then they should rectify that immediately.

That said, to continue the thought experiment, what does "1-2 business days"
really mean?Does the CA get 1-2 business days followed by 1-2 for the
customer? What if there's a holiday in the CA's country of operations
followed by a holiday in the customer's home country? How quickly does this
window extend to 2+ weeks? If you were to go down this path I'd strongly
prefer it to be a hard deadline (e.g. 72 hours) and not anything related to
business days.

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

smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificates with invalidly long serial numbers

2017-08-09 Thread Jeremy Rowley via dev-security-policy

Totally agree Alex. The tiers I'm proposing are 1) subscriber requests 
revocation, cert was issued to the wrong entity, or the key was compromised and 
2) everything else

On Aug 9, 2017, at 8:22 AM, Alex Gaynor 
<agay...@mozilla.com<mailto:agay...@mozilla.com>> wrote:

I'm not really sure I agree that there should be multiple tiers of revocation, 
but just to go along with the thought experiment..

If there were, "key compromise" is definitely not the only case I'd want on the 
more aggressive schedule, I'd also want to include cases where there was a 
failure in DV and the rightful owner of a domain wanted the cert revoked.

Alex

On Wed, Aug 9, 2017 at 10:19 AM, Jeremy Rowley via dev-security-policy 
<dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>>
 wrote:
All CAS are required to maintain the capability to process and receive 
revocation requests 24x7 under the baseline requirements. The headache is not 
with the CA. Rather, it's notifying the customer that their certificate will be 
revoked before the start of the next business day. Having a one to two business 
day rule  instead of 24 hours for non compromise issues gives the end entity 
time to receive the notification and replace their certificate with a compliant 
version.

> On Aug 9, 2017, at 1:10 AM, Paul Kehrer via dev-security-policy 
> <dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>>
>  wrote:
>
>> On Tuesday, August 8, 2017 at 7:03:19 PM UTC-5, Jeremy Rowley wrote:
>> 24 hours is super short when it's a Saturday morning at 4 am and it’s a 
>> European government entity. I agree that is what the policy says now, but, 
>> for lower risk items, the policy should change, preferably to at least one 
>> business day.
>>
>
> It is short, but any CA possessing global trust should already have 
> procedures in place for handling revocation in a prompt manner. It seems odd 
> that it would be onerous for them to revoke a non-compliant certificate. The 
> only difference is a need to confirm to the CA's satisfaction that the given 
> certificate is in violation of the BRs, which I would expect any competent CA 
> to be eminently capable of doing.
>
> -Paul
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org<mailto: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<mailto: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: Certificates with invalidly long serial numbers

2017-08-09 Thread Jeremy Rowley via dev-security-policy

All CAS are required to maintain the capability to process and receive 
revocation requests 24x7 under the baseline requirements. The headache is not 
with the CA. Rather, it's notifying the customer that their certificate will be 
revoked before the start of the next business day. Having a one to two business 
day rule  instead of 24 hours for non compromise issues gives the end entity 
time to receive the notification and replace their certificate with a compliant 
version.

> On Aug 9, 2017, at 1:10 AM, Paul Kehrer via dev-security-policy 
>  wrote:
> 
>> On Tuesday, August 8, 2017 at 7:03:19 PM UTC-5, Jeremy Rowley wrote:
>> 24 hours is super short when it's a Saturday morning at 4 am and it’s a 
>> European government entity. I agree that is what the policy says now, but, 
>> for lower risk items, the policy should change, preferably to at least one 
>> business day. 
>> 
> 
> It is short, but any CA possessing global trust should already have 
> procedures in place for handling revocation in a prompt manner. It seems odd 
> that it would be onerous for them to revoke a non-compliant certificate. The 
> only difference is a need to confirm to the CA's satisfaction that the given 
> certificate is in violation of the BRs, which I would expect any competent CA 
> to be eminently capable of doing.
> 
> -Paul
> ___
> 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: DigiCert-Symantec Announcement

2017-08-20 Thread Jeremy Rowley via dev-security-policy

Hi everyone, 

 

We’re still progressing towards close and transition.  One of the items we are 
heavily evaluating is the root structure and cross-signings post close.  
Although the plan is still being finalized, I wanted to provide a community 
update on the current proposal.

 

Right now, Mozilla post stated that they plan to deprecate Symantec roots for 
TLS by the end of 2018.  We continue to work on a plan to transition all 
customers using the roots for TLS to another root, likely the DigiCert High 
Assurance root.  We will not cross-sign any Symantec roots, however we will 
continue using those roots for code signing and client/email certs post close 
(non-TLS use cases).  We also plan on using Symantec roots to cross-sign some 
of the DigiCert roots to provide ubiquity in non-Mozilla systems and processes. 
 However, this sign will only provide one-way trust, with the ultimate chain in 
Mozilla being EE-> Issuing CA -> DigiCert root in all cases.

 

DigiCert currently has four operational roots in the Mozilla trust store: 
Baltimore, Global, Assured ID, and High Assurance. The other roots are some 
permutation of these four roots that were established for future use 
cases/rollover (ECC vs. RSA).  We already separate operations by Sub CA, with 
TLS, email, and code signing using different issuing CAs. As mentioned in my 
previous post, we plan on using multiple Sub CAs chained to the DigiCert roots 
to further control the population trusted by each Sub CA but have not decided 
on exact numbers. OV and EV will be limited  by Alexa distribution and/or 
number of customers.  DV isn’t readily identifiable by customer and will use a 
common sub CA.

 

Root separation proves a difficult, yet achievable, task as there are only four 
operational roots: Baltimore, High Assurance, Global, and Assured ID. Global 
and High Assurance issue mostly OV/EV certs but do include code signing and 
client certificates. High Assurance is our EV root and used for both EV code 
signing certificates and TLS certs.   Baltimore is our cross-signed root and 
used primarily by older Verizon customers. Assured ID is used mostly for code 
signing and client.  However, Assured ID is also our FBCA root, meaning 
government-issued TLS certificates chain to it.  Of course, all TLS certs are 
issued in accordance with the BRs regardless of root.  

 

Looking at the current customer base, our current plan is to issue EV (code and 
TLS) from High Assurance, OV (code and TLS) from Global. Assured ID will 
continue as our client certificate and government root. We plan to continue 
using Symantec roots for code signing and client.  We’re still looking into 
this though. We’d love to separate out the roots more than this, but that’s not 
likely possible given the current root architecture. If there is a 
non-cross-signed Symantec root that the browsers are not planning to remove, 
we’d like to continue using the root to issue high volume DV and device 
certificates.  If this is not possible and Mozilla is still planning on 
distrusting all Symantec roots, we’ll likely migrate DV certs to a Sub CA 
chained to the Baltimore root.

 

Of course, this is only an initial proposal.  We’ll revise as things progress 
and based on the community feedback.  We appreciate your thoughts.

 

Jeremy

 

 

From: Peter Kurrasch [mailto:fhw...@gmail.com] 
Sent: Thursday, August 3, 2017 11:21 PM
To: Jeremy Rowley ; mozilla-dev-security-policy 

Subject: Re: DigiCert-Symantec Announcement

 

I agree with the high-level concepts, although I would probably like to add 
something about "being good stewards of technologies that play a critical role 
in the global economy." (Feel free to use your own words!)

 

Regarding the current Mozilla/Google plans, I don't necessarily have a problem 
with them but I do think we should give ourselves permission to make 
adjustments (if needed) because the circumstances have changed since those 
plans were developed. Consider:

 

* Because the acquisition is now in the picture, legal issues might impede 
progress in certain areas. The most notable example is the fact that DigiCert 
will have limited authority over Symantec until the deal actually closes. For 
example, what will happen in the period between Dec 1 and the closing (assuming 
it's after the first)?

 

* Once the deal does close, personnel and management issues could present 
various challenges in meeting certain deadlines. For example, if subject matter 
experts decide to leave Symantec prior to the closing, how might that hinder 
DigiCert?

 

* A lot of churn is about to be introduced in the global PKI. Times of chaos 
create moments of opportunity for those who wish to do bad things. Should 
something happen, corrections may be necessary which can impact delivery dates, 
and so on.





Let me be clear that these are just hypothetical situations and rhetorical 
questions.

Re: O=U.S. Government for non-USG entity (IdenTrust)

2017-08-18 Thread Jeremy Rowley via dev-security-policy

I don't (as these are the exact type of cert I've been trying to kill for
years), but Identrust did based on their response. Looking at it from their
POV, the language could probably be clarified to state thar any cert with no
equipment, sever Auth, or anyEKU is considered a BR cert regardless of other
content.

On Aug 18, 2017, at 8:26 AM, Ryan Sleevi
vb<r...@sleevi.com<mailto:r...@sleevi.com>> wrote:

Do you believe
https://github.com/mozilla/pkipolicy/blob/master/rootstore/policy.md#11-scope
is ambiguous in this context? That is what is referenced in the text.

It sounds as if you're suggesting they're in scope, via 1.1, but that they're
out of scope, because the policy does not state that (id-kp-anyEKU ||
id-kp-serverAuth) are SSL certificates and (id-kp-anyEKU ||
id-kp-emailProtection) are email certificates, even though this would logically
flow (from RFC 5280 https://tools.ietf.org/html/rfc5280#section-4.2.1.12)
stating that anyEKU places no restrictions on the subject key as to its
purpose. Is that correct?

On Fri, Aug 18, 2017 at 9:53 AM, Jeremy Rowley via dev-security-policy
<dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>>
wrote:
Right, but can you call these SSL certs without an FQDN?

* Insofar as the Baseline Requirements attempt to define their own scope,
the scope of this policy (section 1.1) overrides that. Mozilla thus requires CA
operations relating to issuance of all SSL certificates in the scope of this
policy to conform to the Baseline Requirements.

Is SSL certificate defined?

On Aug 18, 2017, at 7:33 AM, Gervase Markham
<g...@mozilla.org<mailto:g...@mozilla.org><mailto:g...@mozilla.org<mailto:g...@mozilla.org>>>
wrote:

On 17/08/17 20:31, Jeremy Rowley wrote:
Without an FQDN, I doubt they are in scope for the baseline requirements.

Not according to the BRs themselves. However, the Mozilla Policy 2.5
specifically says:

"Insofar as the Baseline Requirements attempt to define their own scope,
the scope of this policy (section 1.1) overrides that. Mozilla thus
requires CA operations relating to issuance of all SSL certificates in
the scope of this policy to conform to the Baseline Requirements."

Now, whether we are right to include anyEKU in scope, given that it
pulls in certs such as those in question, is still something I am unsure
about :-) But the current policy says what it says.

They are in scope for the Mozilla policy. The BRs require the cert to
be intended for web tls. These are not.

But the Mozilla Policy re-scopes the BRs to remove the ambiguous
language about "intent".

The Mozilla policy covers client certs as well as tls.

Er, no it doesn't (except insofar as we make anyEKU in scope)? Our
policy covers server certs and email certs.

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org<mailto: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: O=U.S. Government for non-USG entity (IdenTrust)

2017-08-18 Thread Jeremy Rowley via dev-security-policy

Right, but can you call these SSL certs without an FQDN?


  *   Insofar as the Baseline Requirements attempt to define their own scope, 
the scope of this policy (section 1.1) overrides that. Mozilla thus requires CA 
operations relating to issuance of all SSL certificates in the scope of this 
policy to conform to the Baseline Requirements.

Is SSL certificate defined?

On Aug 18, 2017, at 7:33 AM, Gervase Markham 
> wrote:

On 17/08/17 20:31, Jeremy Rowley wrote:
Without an FQDN, I doubt they are in scope for the baseline requirements.

Not according to the BRs themselves. However, the Mozilla Policy 2.5
specifically says:

"Insofar as the Baseline Requirements attempt to define their own scope,
the scope of this policy (section 1.1) overrides that. Mozilla thus
requires CA operations relating to issuance of all SSL certificates in
the scope of this policy to conform to the Baseline Requirements."

Now, whether we are right to include anyEKU in scope, given that it
pulls in certs such as those in question, is still something I am unsure
about :-) But the current policy says what it says.

They are in scope for the Mozilla policy. The BRs require the cert to
be intended for web tls. These are not.

But the Mozilla Policy re-scopes the BRs to remove the ambiguous
language about "intent".

The Mozilla policy covers client certs as well as tls.

Er, no it doesn't (except insofar as we make anyEKU in scope)? Our
policy covers server certs and email certs.

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

RE: CA Validation quality is failing

2017-05-02 Thread Jeremy Rowley via dev-security-policy

Thanks!

The revocation timeline changes are coming today/tomorrow morning.

-Original Message-
From: Gervase Markham [mailto:g...@mozilla.org]
Sent: Tuesday, May 2, 2017 4:55 AM
To: r...@sleevi.com; Jeremy Rowley ; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: CA Validation quality is failing

On 02/05/17 00:01, Ryan Sleevi wrote:
> Thank you for
> 1) Disclosing the details to a sufficient level of detail immediately
> 2) Providing regular updates and continued investigation
> 3) Confirming the acceptability of the plan before implementing it,
> and with sufficient detail to understand the implications

I echo Ryan's comments here. I'm happy with your remediation plan, and think 
there's enough wiggle room in the BRs and Mozilla policy that revocation of 
the certs with "N/A" etc. is avoidable.

I still think we need to address that 24-hour revocation requirement to be a 
bit more nuanced, but that's a separate discussion :-)

Gerv



smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: CA Validation quality is failing

2017-05-02 Thread Jeremy Rowley via dev-security-policy

Okay – we’ll add them all to CT over the next couple of days.

From: Ryan Sleevi [mailto:r...@sleevi.com] 
Sent: Tuesday, May 2, 2017 9:08 AM
To: Jeremy Rowley <jeremy.row...@digicert.com>
Cc: r...@sleevi.com; Gervase Markham <g...@mozilla.org>; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: CA Validation quality is failing

(Still wearing Google Hat in this context) 

I think sharing a list (in CT) of the certs is good and can help verify the 
assertions made here :)

But overall, I think this sounds right and the risk is minimal to our users, so 
not revoking still sounds good :)

On Mon, May 1, 2017 at 11:53 PM, Jeremy Rowley <jeremy.row...@digicert.com 
<mailto:jeremy.row...@digicert.com> > wrote:

Certainly happy to share more info. The search was for all EV and OV certs. Of 
the 4000 certificates detected, 101 certificates are EV. Of these EV 
certificates, 17 would be included in the proposed revocation. The rest have 
the “N/A” issue. This is just the locality/state/zip. The jurisdiction of 
incorporation processes separately and doesn’t have the same auto-populate tool.

More info:

78 certs had non-US states populated with US states (thanks to the 
auto-populator)

791 entities are affected by the entire range of certificates

257 entities are affected if we revoke the 1033 certs

82 entities are affected if we revoke just the 150 certs

What else would you like to know?

Jeremy

From: Ryan Sleevi [mailto:r...@sleevi.com <mailto:r...@sleevi.com> ] 
Sent: Monday, May 1, 2017 5:01 PM
To: Jeremy Rowley <jeremy.row...@digicert.com 
<mailto:jeremy.row...@digicert.com> >
Cc: Gervase Markham <g...@mozilla.org <mailto:g...@mozilla.org> >; 
mozilla-dev-security-pol...@lists.mozilla.org 
<mailto:mozilla-dev-security-pol...@lists.mozilla.org> 
Subject: Re: CA Validation quality is failing

On Mon, May 1, 2017 at 3:41 PM, Jeremy Rowley via dev-security-policy 
<dev-security-policy@lists.mozilla.org 
<mailto:dev-security-policy@lists.mozilla.org> > wrote:

There isn't anything in our CPS directly. However, we state that we follow the 
baseline requirements in the CPS. The baseline requirements give a profile for 
the state field. We weren't sure this was strictly followed.

We finished our validation review over the weekend.   There are about 3000 
older certs with information indicating a field was not applicable (such as a 
"-", "N/A", etc). On top of this, we issued about 1000 certificates with 
mismatched validation information. The mismatched information can be divided 
into about 850 certificates with numbers in the state field. These numbers 
indicate a location code that was provided by the auto-populator.  The 
remaining 150 are certificates with "Select", a state, or a postal code 
improperly included in the certificate.  The root issue was a combination of 
the auto-populator inserting incorrect data into the cert request and our 
validation staff not properly updating the certificate information after 
completing the validation process.

Based on these results, we propose the following remediation plan:
1. We already removed the auto-populator from our CSR and certificate order 
generators.
2. We already blocked this information on the CA side from included in signed 
SSL/TLS objects.
3. We will revoke the 150 certificates with mismatched information.
4. We plan to let the remaining 3850 expire normally but will correct the 
certificate for all future orders (including rekeys).

Is this an acceptable plan? We are proposing not revoking the 3850 certificates 
because the information isn't misleading, the information is accurate, and 
there isn't a risk posed to Mozilla's users by inclusion of the numeric 
location code or not applicable indicator. Any thoughts?

(With a Google hat on)

Jeremy,

I think with the information you've shared so far, that sounds like a 
reasonable plan from Google's perspective for the 3000 certificates. I think 
there's at least a little concern about the EV nature for the 850 side, but 
just trying to understand more here what the implications would be. Is this 
exclusively the state, or does it also extend to the jurisdiction* fields? Or 
is this only for EV?

Would you be able to share a spreadsheet or details for those, in the spirit of 
transparency? I think if you can share those details, it's reasonable to avoid 
revoking, and anything specific that might represent a security/compat risk to 
an Application Software Supplier (i.e. 4.9.1.1(15) ), we can look into 
separately.

Thank you for

1) Disclosing the details to a sufficient level of detail immediately

2) Providing regular updates and continued investigation

3) Confirming the acceptability of the plan before implementing it, and with 
sufficient detail to understand the implications

These are several of the factors we weighed when co

RE: CA Validation quality is failing

2017-05-09 Thread Jeremy Rowley via dev-security-policy

Okay - all certs were added to the CT log.  We're now working through 
revocation.

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org]
 On Behalf Of Jeremy Rowley via dev-security-policy
Sent: Tuesday, May 2, 2017 12:09 PM
To: r...@sleevi.com
Cc: mozilla-dev-security-pol...@lists.mozilla.org; Gervase Markham 
<g...@mozilla.org>
Subject: RE: CA Validation quality is failing

Okay – we’ll add them all to CT over the next couple of days.

From: Ryan Sleevi [mailto:r...@sleevi.com] 
Sent: Tuesday, May 2, 2017 9:08 AM
To: Jeremy Rowley <jeremy.row...@digicert.com>
Cc: r...@sleevi.com; Gervase Markham <g...@mozilla.org>; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: CA Validation quality is failing

(Still wearing Google Hat in this context) 

I think sharing a list (in CT) of the certs is good and can help verify the 
assertions made here :)

But overall, I think this sounds right and the risk is minimal to our users, so 
not revoking still sounds good :)

On Mon, May 1, 2017 at 11:53 PM, Jeremy Rowley <jeremy.row...@digicert.com 
<mailto:jeremy.row...@digicert.com> > wrote:

Certainly happy to share more info. The search was for all EV and OV certs. Of 
the 4000 certificates detected, 101 certificates are EV. Of these EV 
certificates, 17 would be included in the proposed revocation. The rest have 
the “N/A” issue. This is just the locality/state/zip. The jurisdiction of 
incorporation processes separately and doesn’t have the same auto-populate tool.

More info:

78 certs had non-US states populated with US states (thanks to the 
auto-populator)

791 entities are affected by the entire range of certificates

257 entities are affected if we revoke the 1033 certs

82 entities are affected if we revoke just the 150 certs

What else would you like to know?

Jeremy

From: Ryan Sleevi [mailto:r...@sleevi.com <mailto:r...@sleevi.com> ] 
Sent: Monday, May 1, 2017 5:01 PM
To: Jeremy Rowley <jeremy.row...@digicert.com 
<mailto:jeremy.row...@digicert.com> >
Cc: Gervase Markham <g...@mozilla.org <mailto:g...@mozilla.org> >; 
mozilla-dev-security-pol...@lists.mozilla.org 
<mailto:mozilla-dev-security-pol...@lists.mozilla.org> 
Subject: Re: CA Validation quality is failing

On Mon, May 1, 2017 at 3:41 PM, Jeremy Rowley via dev-security-policy 
<dev-security-policy@lists.mozilla.org 
<mailto:dev-security-policy@lists.mozilla.org> > wrote:

There isn't anything in our CPS directly. However, we state that we follow the 
baseline requirements in the CPS. The baseline requirements give a profile for 
the state field. We weren't sure this was strictly followed.

We finished our validation review over the weekend.   There are about 3000 
older certs with information indicating a field was not applicable (such as a 
"-", "N/A", etc). On top of this, we issued about 1000 certificates with 
mismatched validation information. The mismatched information can be divided 
into about 850 certificates with numbers in the state field. These numbers 
indicate a location code that was provided by the auto-populator.  The 
remaining 150 are certificates with "Select", a state, or a postal code 
improperly included in the certificate.  The root issue was a combination of 
the auto-populator inserting incorrect data into the cert request and our 
validation staff not properly updating the certificate information after 
completing the validation process.

Based on these results, we propose the following remediation plan:
1. We already removed the auto-populator from our CSR and certificate order 
generators.
2. We already blocked this information on the CA side from included in signed 
SSL/TLS objects.
3. We will revoke the 150 certificates with mismatched information.
4. We plan to let the remaining 3850 expire normally but will correct the 
certificate for all future orders (including rekeys).

Is this an acceptable plan? We are proposing not revoking the 3850 certificates 
because the information isn't misleading, the information is accurate, and 
there isn't a risk posed to Mozilla's users by inclusion of the numeric 
location code or not applicable indicator. Any thoughts?

(With a Google hat on)

Jeremy,

I think with the information you've shared so far, that sounds like a 
reasonable plan from Google's perspective for the 3000 certificates. I think 
there's at least a little concern about the EV nature for the 850 side, but 
just trying to understand more here what the implications would be. Is this 
exclusively the state, or does it also extend to the jurisdiction* fields? Or 
is this only for EV?

Would you be able to share a spreadsheet or details for those, in the spirit of 
transparency? I think if you can share those details, it's reasonable to avoid 
revoking, and anything speci

Re: When are public applications embedding certificates pointing to 127.0.0.1 OK?

2017-06-21 Thread Jeremy Rowley via dev-security-policy

And a common practice. Old Microsoft documentation used to recommend it.

> On Jun 21, 2017, at 12:22 PM, Santhan Raj via dev-security-policy 
>  wrote:
> 
> On Wednesday, June 21, 2017 at 12:02:51 PM UTC-7, Jonathan Rudenberg wrote:
>>> On Jun 21, 2017, at 14:41, urijah--- via dev-security-policy 
>>>  wrote:
>>> 
>>> Apparently, in at least one case, the certificate was issued directly(!) to 
>>> localhost by Symantec.
>>> 
>>> https://news.ycombinator.com/item?id=14598262
>>> 
>>> subject=/C=US/ST=Florida/L=Melbourne/O=AuthenTec/OU=Terms of use at 
>>> www.verisign.com/rpa (c)05/CN=localhost
>>> issuer=/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at 
>>> https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 Secure Server CA - G3
>>> reply
>>> 
>>> Is this a known incident?
>> 
>> Here is the (since expired) certificate: 
>> https://crt.sh/?q=07C4AD287B850CAA3DD89656937DB1217067407AA8504A10382A8AD3838D153F
> 
> As bad as it may sound, issuing certs for internal server name from a public 
> chain was allowed until Oct 2015 (as per BR).
> ___
> 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: StartCom issuing bogus certificates

2017-05-31 Thread Jeremy Rowley via dev-security-policy

Agreed - the license to use the domain granted by IANA is only for inclusion
in documents (https://www.iana.org/domains/reserved). There isn't a license
to use the domain for testing or any other purposes. 

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Kurt Roeckx via dev-security-policy
Sent: Wednesday, May 31, 2017 11:55 AM
To: Yuhong Bao 
Cc: mozilla-dev-security-pol...@lists.mozilla.org; Matthew Hardeman

Subject: Re: StartCom issuing bogus certificates

On Wed, May 31, 2017 at 05:09:57PM +, Yuhong Bao via dev-security-policy
wrote:
> The point is that "misissuance" of example.com is harmless as they are
reserved by IANA.

But example.com is a real domain that that even has an https website. The
certificate is issued by digicert, and the subject says it's to ICANN. If
the certificate is not requested by IANA or ICANN nobody should issue a
certificate for it.

Kurt

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

smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: New undisclosed intermediates

2017-06-08 Thread Jeremy Rowley via dev-security-policy

If you added them automatically to OneCRL, how would you create new
intermediates? Would it be anything over X days old and undisclosed is
automatically added? If so, +1 from us.  I'm pretty sure the two CAs listed
from the Baltimore root don't believe these are publicly trusted
intermediates. 

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Gervase Markham via dev-security-policy
Sent: Thursday, June 8, 2017 3:17 AM
To: Jonathan Rudenberg ;
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: New undisclosed intermediates

On 08/06/17 00:42, Jonathan Rudenberg wrote:
> Yet another batch of undisclosed intermediates has shown up in CT:

Like, seriously?

Every CA in our program indicated that they would disclose all their
intermediates by June 30th, 2016:

https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesO
nlyReport?CommunicationId=a05o00iHdtx=Q4

I don't really want to switch to an intermediate whitelist because that
requires coding.

My patience is expiring. What CA can't keep track of the intermediates it
issues? How hard is that, really?

What downsides would there be, other than the obvious "some sites might
break", to us just adding any such intermediate certs directly to OneCRL?

Gerv

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


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: CA Validation quality is failing

2017-05-01 Thread Jeremy Rowley via dev-security-policy

There isn't anything in our CPS directly. However, we state that we follow the 
baseline requirements in the CPS. The baseline requirements give a profile for 
the state field. We weren't sure this was strictly followed. 

We finished our validation review over the weekend.   There are about 3000 
older certs with information indicating a field was not applicable (such as a 
"-", "N/A", etc). On top of this, we issued about 1000 certificates with 
mismatched validation information. The mismatched information can be divided 
into about 850 certificates with numbers in the state field. These numbers 
indicate a location code that was provided by the auto-populator.  The 
remaining 150 are certificates with "Select", a state, or a postal code 
improperly included in the certificate.  The root issue was a combination of 
the auto-populator inserting incorrect data into the cert request and our 
validation staff not properly updating the certificate information after 
completing the validation process. 

Based on these results, we propose the following remediation plan:
1. We already removed the auto-populator from our CSR and certificate order 
generators. 
2. We already blocked this information on the CA side from included in signed 
SSL/TLS objects.
3. We will revoke the 150 certificates with mismatched information. 
4. We plan to let the remaining 3850 expire normally but will correct the 
certificate for all future orders (including rekeys).

Is this an acceptable plan? We are proposing not revoking the 3850 certificates 
because the information isn't misleading, the information is accurate, and 
there isn't a risk posed to Mozilla's users by inclusion of the numeric 
location code or not applicable indicator. Any thoughts?

Jeremy

-Original Message-
From: Gervase Markham [mailto:g...@mozilla.org] 
Sent: Thursday, April 27, 2017 2:41 AM
To: Jeremy Rowley ; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: CA Validation quality is failing

On 27/04/17 00:16, Jeremy Rowley wrote:
> We also started the revocation process for the 500 certificates 
> containing meta-data. However, we wanted to ask about the 1000 
> certificates containing data indicating the field was not applicable.
> We recognize these were not properly issued, but I am curious whether 
> revocation is required by Mozilla in this case. Should we start 
> revoking those certificates as well despite the certificate 
> information clearly not indicating a state/province? My thought is yes 
> because of BR 4.9.1.1:
> 
> 9. The CA is made aware that the Certificate was not issued in 
> accordance with these Requirements or the CA’s Certificate Policy or 
> Certification Practice Statement;

What line in your CP or CPS is violated by these certs?

> I don't think #10 applies because the information is accurate - the 
> field is not applicable: 10. The CA determines that any of the 
> information appearing in the Certificate is inaccurate or misleading;

I agree that a "." or "-" instead of a field being empty is not inaccurate or 
misleading. However, #10 also says "the CA determines", so it's your view, not 
mine, which is most relevant :-)

Gerv

smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: CA Validation quality is failing

2017-05-01 Thread Jeremy Rowley via dev-security-policy

Certainly happy to share more info. The search was for all EV and OV certs. Of 
the 4000 certificates detected, 101 certificates are EV. Of these EV 
certificates, 17 would be included in the proposed revocation. The rest have 
the “N/A” issue. This is just the locality/state/zip. The jurisdiction of 
incorporation processes separately and doesn’t have the same auto-populate tool.

 

More info:

78 certs had non-US states populated with US states (thanks to the 
auto-populator)

791 entities are affected by the entire range of certificates

257 entities are affected if we revoke the 1033 certs

82 entities are affected if we revoke just the 150 certs

 

What else would you like to know?

 

Jeremy

 

From: Ryan Sleevi [mailto:r...@sleevi.com] 
Sent: Monday, May 1, 2017 5:01 PM
To: Jeremy Rowley <jeremy.row...@digicert.com>
Cc: Gervase Markham <g...@mozilla.org>; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: CA Validation quality is failing

 

 

 

On Mon, May 1, 2017 at 3:41 PM, Jeremy Rowley via dev-security-policy 
<dev-security-policy@lists.mozilla.org 
<mailto:dev-security-policy@lists.mozilla.org> > wrote:

There isn't anything in our CPS directly. However, we state that we follow the 
baseline requirements in the CPS. The baseline requirements give a profile for 
the state field. We weren't sure this was strictly followed.

We finished our validation review over the weekend.   There are about 3000 
older certs with information indicating a field was not applicable (such as a 
"-", "N/A", etc). On top of this, we issued about 1000 certificates with 
mismatched validation information. The mismatched information can be divided 
into about 850 certificates with numbers in the state field. These numbers 
indicate a location code that was provided by the auto-populator.  The 
remaining 150 are certificates with "Select", a state, or a postal code 
improperly included in the certificate.  The root issue was a combination of 
the auto-populator inserting incorrect data into the cert request and our 
validation staff not properly updating the certificate information after 
completing the validation process.

Based on these results, we propose the following remediation plan:
1. We already removed the auto-populator from our CSR and certificate order 
generators.
2. We already blocked this information on the CA side from included in signed 
SSL/TLS objects.
3. We will revoke the 150 certificates with mismatched information.
4. We plan to let the remaining 3850 expire normally but will correct the 
certificate for all future orders (including rekeys).

Is this an acceptable plan? We are proposing not revoking the 3850 certificates 
because the information isn't misleading, the information is accurate, and 
there isn't a risk posed to Mozilla's users by inclusion of the numeric 
location code or not applicable indicator. Any thoughts?

 

(With a Google hat on)

 

Jeremy,

 

I think with the information you've shared so far, that sounds like a 
reasonable plan from Google's perspective for the 3000 certificates. I think 
there's at least a little concern about the EV nature for the 850 side, but 
just trying to understand more here what the implications would be. Is this 
exclusively the state, or does it also extend to the jurisdiction* fields? Or 
is this only for EV?

 

Would you be able to share a spreadsheet or details for those, in the spirit of 
transparency? I think if you can share those details, it's reasonable to avoid 
revoking, and anything specific that might represent a security/compat risk to 
an Application Software Supplier (i.e. 4.9.1.1(15) ), we can look into 
separately.

 

Thank you for

1) Disclosing the details to a sufficient level of detail immediately

2) Providing regular updates and continued investigation

3) Confirming the acceptability of the plan before implementing it, and with 
sufficient detail to understand the implications

 

These are several of the factors we weighed when considering the 
implications/risk of not revoking.

 



smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: DigiCert-Symantec Announcement

2017-09-15 Thread Jeremy Rowley via dev-security-policy

Hey Ryan – Thanks a ton for this post.  I’m working on a reply and should have 
something next week, but I wanted to acknowledge that we saw the post and are 
working on providing the information requested. 

 

Jeremy

 

From: Ryan Sleevi [mailto:r...@sleevi.com] 
Sent: Thursday, September 14, 2017 1:28 PM
To: Jeremy Rowley <jeremy.row...@digicert.com>
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: DigiCert-Symantec Announcement

 

 

 

On Wed, Aug 2, 2017 at 5:12 PM, Jeremy Rowley via dev-security-policy 
<dev-security-policy@lists.mozilla.org 
<mailto:dev-security-policy@lists.mozilla.org> > wrote:

Hi everyone,



Today, DigiCert and Symantec announced that DigiCert is acquiring the
Symantec CA assets, including the infrastructure, personnel, roots, and
platforms.  At the same time, DigiCert signed a Sub CA agreement wherein we
will validate and issue all Symantec certs as of Dec 1, 2017.  We are
committed to meeting the Mozilla and Google plans in transitioning away from
the Symantec infrastructure. The deal is expected to close near the end of
the year, after which we will be solely responsible for operation of the CA.
>From there, we will migrate customers and systems as necessary to
consolidate platforms and operations while continuing to run all issuance
and validation through DigiCert.  We will post updates and plans to the
community as things change and progress.



I wanted to post to the Mozilla dev list to:

1.  Inform the public,
2.  Get community feedback about the transition and concerns, and
3.  Get an update from the browsers on what this means for the plan,
noting that we fully commit to the stated deadlines. We're hoping that any
changes



Two things I can say we plan on doing (following closing) to address
concerns are:

a.  We plan to segregate certs by type on each root. Going forward, we
will issue all SSL certs from a root while client and email come from
different roots. We also plan on limiting the number of organizations on
each issuing CA.  We hope this will help address the "too big to fail" issue
seen with Symantec.  By segregating end entities into roots and sub CAs, the
browsers can add affected Sub CAs to their CRL lists quickly and without
impacting the entire ecosystem.  This plan is very much in flux, and we'd
love to hear additional recommendations.
b.  Another thing we are doing is adding a validation OID to all of our
certificates that identifies which of the BR methods were used to issue the
cert. This way the entire community can readily identify which method was
used when issuing a cert and take action if a method is deemed weak or
insufficient.  We think this is a huge improvement over the existing
landscape, and I'm very excited to see that OID rolled out.



Thanks a ton for any thoughts you offer.



Jeremy

 

eremy,

 

Thanks for sharing details about your rough plans. There’s a lot at play here, 
particularly when trying to fully visualize DigiCert’s existing and proposed 
hierarchy, so I’m wondering if it might be easier to explore what the ‘ideal 
PKI’ may look like, and then try to work backwards to figure out how this 
acquisition can help that.

 

At the core, we can imagine there is a root CA for each major long-term 
cryptographic configuration - which, in today’s world, generally means 
RSA/2048, RSA/4096, ECC/256, and ECC/384. In tomorrow’s world, this may also 
accommodate additional curves Ed25519 and Ed448, such as via 
https://tools.ietf.org/id/draft-ietf-curdle-pkix . In total, this means the 
ideal PKI only needs four to six root certificates.

 

Within each root, you can build out the appropriate segmentation. For 
performance reasons, it’s likely preferable to have a ‘wide’ PKI (many sub-CAs 
off the root, each constrained in capability and used for a limited amount of 
time) versus a ‘deep’ PKI (hierarchically reducing the capabilities at each 
level in the trust graph- for example, “All TLS” -> “All DV” -> “All first 
party DV” -> “All first party DV in Q12017”), even if a deep PKI can provide 
better compartmentalization for some use cases.

 

It isn’t clear that compartmentalizing on root provides any obvious benefits to 
users, especially as it’s the same infrastructure and audits, but it does seem 
that it increases the management overhead (for root stores), the configuration 
challenges (for site operators), not to mention the management (and, 
occasionally, network & memory) challenges for users to support all of those 
roots.

 

It would be ideal to see DigiCert streamline its PKI to better align with that 
vision, and to understand what challenges might prevent that. For example, is 
there a path to transition all new DigiCert issuance to a single root? If it 
can’t be done for all certs, can it be done for TLS? Understanding if there are 
challenges to that goal can provide invaluable insight into how the Managed CA 
transition can look.

DigiCert mis-issuance report: rekeyed certificates

2017-09-19 Thread Jeremy Rowley via dev-security-policy

Hi all, 

 

On Friday, Sep 15, we discovered that 1090 certificates were rekeyed using
expired domain validation documents. In each case, the original
certificate's domain was properly verified at time of issuance using an
approved method.  Organization verification properly completed for each
rekey prior to issuance.  This means, to get a rekeyed certificate with
expired validation data the following had to be true:

A.  Unexpired organization validation information,
B.  A previously issued, unexpired, and unrevoked certificate for the
same domain as the rekeyed certificate,  
C.  Valid domain documentation for the original certificate at time of
issuance, and
D.  All necessary access and permissions on the account issuing the
original certificate.

 

In parallel to the on-going investigation, we are reverifying the affected
domains using one of the approved domain methods.  So far, we have
reverified 1021 of the 1090 affected certificates, leaving 69 domains
outstanding.  We are working with the domain owners to re-establish domain
approval, but plan to revoke any certs that cannot be revalidated by end of
this week.  

1.  How your CA first became aware of the problem (e.g. via a problem
report submitted to your Problem Reporting Mechanism, via a discussion in
mozilla.dev.security.policy, or via a Bugzilla bug), and the date. 

[DC] We first became aware that there was a potential issue on Sep 14th
during part of a routine internal review.  We noticed some of the domain
control validation documents were older than permitted under both the
Baseline Requirements and EV Guidelines. On Sep 14th, we confirmed that
rekeys in a validation system did not follow the proper path for
verification of the timestamp associated with domain documents, instead
using the timestamp of the domain documents on the original certificate.  We
patched our system early Sep 15th, preventing the system from further
re-using expired domain documentation to rekey a certificate.  Over the
weekend, we worked on this report while revalidating domains associated with
the misissued rekeys.

2.  A timeline of the actions your CA took in response. 

[DC]  The same day the staff reported the potential issue, we began
investigating the root cause. On Sep 15th, we confirmed that older
validation code improperly reused domain validation when rekeying a
certificate. We thought we patched this after the CAB Forum's previous
discussion on what constitutes a new certificate. If you recall those
discussions, DigiCert mistakenly believed rekeyed certificates were
considered the same certificate, not requiring domain reverification.  The
original system believed duplicate certificates and rekeyed certificates
were identical to the original cert (despite a new serial number) and relied
on a previously completed validation outside of the permitted reuse period.
Ultimately, we decided to amend our issuance process because of the CAB
Forum discussions but failed to properly communicate this requirement
internally. Although most workflows were patched to follow our "new
issuance" process, one workflow path was not.  Validation documents properly
expired in the system, preventing issuance of "new" certificate orders using
expired documentation. All organization documents expired in the system
according to the proper guidelines, blocking both new issuance and issuance
of rekeyed certificates.

3.  Confirmation that your CA has stopped issuing TLS/SSL certificates
with the problem. 

[DC] Confirmed.  The system was patched on Sep 15th to require valid domain
validation prior to rekey.  This was within 24 hours of receiving an
internal message about the issue and within two hours of confirming the
issue's existence. 

4.  A summary of the problematic certificates. For each problem: number
of certs, and the date the first and last certs with that problem were
issued. 

[DC] 1090 certificate rekeys are known. Impacted certificates will be
provided in the bug list and will also be available through CT (we're still
working on this part).  

5.  The complete certificate data for the problematic certificates. The
recommended way to provide this is to ensure each certificate is logged to
CT and then list the fingerprints or crt.sh IDs, either in the report or as
an attached spreadsheet, with one list per distinct problem. 

[DC] Provided as an excel file on the bug list (once compiled).

6.  Explanation about how and why the mistakes were made or bugs
introduced, and how they avoided detection until now. 

[DC] The issue was intentionally introduced during DigiCert's earlier days
because of a mis-understanding by the original DigiCert team about whether
rekeys constituted new issuance rather than duplication of a previous
certificate.  We thought we fixed the issue back when the CAB Forum
discussed this topic, but apparently missed a work flow path. One mitigating
factor is that all rekeys were initiated at the request of a

RE: DigiCert-Symantec Announcement

2017-09-20 Thread Jeremy Rowley via dev-security-policy

.  GeoTrust Global CA
2.  GeoTrust Global CA 2
3.  Verisign Class 3 Public Primary Certificate Authority – G5
4.  Thawte Primary Root CA

 

The exact roots cross-signing the DigiCert root is very much in flux. Until 
close, we aren’t reaching out to current Symantec customers for, I think, 
obvious reasons.  However, we do plan on communicating with these customers 
immediately post close to determine which roots are pinned in applications and 
what roots are required for custom applications. We are trying to limit the 
number of primary roots to six (three ECC, three RSA) plus one transition root 
to keep the chains and use manageable.  

 

The Global G2 root will become the transition root to DigiCert for customers 
who can’t move fully to an operational DigiCert roots prior to September 2018. 
Any customers that require a specific root can use the transition root for as 
long as they want, realizing that path validation may be an issue as Symantec 
roots are removed by platform operators. Although we cannot currently move to a 
single root because of the lack of EV support and trust in non-Mozilla 
platforms, we can move to the existing three roots in an orderly fashion. 

 

If the agreement closes prior to Dec 1, the Managed CA will never exist. 
Instead, all issuance will occur through one of the three primary DigiCert 
roots mentioned above with the exception of customers required to use a 
Symantec root for certain platforms or pinning. The cross-signed Global root 
will be only transitory, meaning we’d hope customers would migrate to the 
DigiCert roots once the systems requiring a specific Symantec roots are 
deprecated or as path validation errors arise.

 

Jeremy

 

 

From: Ryan Sleevi [mailto:r...@sleevi.com] 
Sent: Thursday, September 14, 2017 1:28 PM
To: Jeremy Rowley <jeremy.row...@digicert.com>
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: DigiCert-Symantec Announcement

 

 

 

On Wed, Aug 2, 2017 at 5:12 PM, Jeremy Rowley via dev-security-policy 
<dev-security-policy@lists.mozilla.org 
<mailto:dev-security-policy@lists.mozilla.org> > wrote:

Hi everyone,



Today, DigiCert and Symantec announced that DigiCert is acquiring the
Symantec CA assets, including the infrastructure, personnel, roots, and
platforms.  At the same time, DigiCert signed a Sub CA agreement wherein we
will validate and issue all Symantec certs as of Dec 1, 2017.  We are
committed to meeting the Mozilla and Google plans in transitioning away from
the Symantec infrastructure. The deal is expected to close near the end of
the year, after which we will be solely responsible for operation of the CA.
>From there, we will migrate customers and systems as necessary to
consolidate platforms and operations while continuing to run all issuance
and validation through DigiCert.  We will post updates and plans to the
community as things change and progress.



I wanted to post to the Mozilla dev list to:

1.  Inform the public,
2.  Get community feedback about the transition and concerns, and
3.  Get an update from the browsers on what this means for the plan,
noting that we fully commit to the stated deadlines. We're hoping that any
changes



Two things I can say we plan on doing (following closing) to address
concerns are:

a.  We plan to segregate certs by type on each root. Going forward, we
will issue all SSL certs from a root while client and email come from
different roots. We also plan on limiting the number of organizations on
each issuing CA.  We hope this will help address the "too big to fail" issue
seen with Symantec.  By segregating end entities into roots and sub CAs, the
browsers can add affected Sub CAs to their CRL lists quickly and without
impacting the entire ecosystem.  This plan is very much in flux, and we'd
love to hear additional recommendations.
b.  Another thing we are doing is adding a validation OID to all of our
certificates that identifies which of the BR methods were used to issue the
cert. This way the entire community can readily identify which method was
used when issuing a cert and take action if a method is deemed weak or
insufficient.  We think this is a huge improvement over the existing
landscape, and I'm very excited to see that OID rolled out.



Thanks a ton for any thoughts you offer.



Jeremy

 

eremy,

 

Thanks for sharing details about your rough plans. There’s a lot at play here, 
particularly when trying to fully visualize DigiCert’s existing and proposed 
hierarchy, so I’m wondering if it might be easier to explore what the ‘ideal 
PKI’ may look like, and then try to work backwards to figure out how this 
acquisition can help that.

 

At the core, we can imagine there is a root CA for each major long-term 
cryptographic configuration - which, in today’s world, generally means 
RSA/2048, RSA/4096, ECC/256, and ECC/384. In tomorrow’s world, this may also 
accommodate additional curves Ed2551

RE: DigiCert-Symantec Announcement

2017-09-20 Thread Jeremy Rowley via dev-security-policy

The original Mozilla plan was to distrust around Sep 2018.  We're still 
planning for that date, but would appreciate it if trust was permitted around a 
single intermediate (say the DigiCert Global Trust G2 root?).  If we need to 
use a separate root with no other certs as the transition, we could create one. 
 I know my team would prefer it as the Global Trust G2 root is our primary SHA2 
root.

-Original Message-
From: Peter Bowen [mailto:pzbo...@gmail.com] 
Sent: Wednesday, September 20, 2017 10:21 AM
To: Jeremy Rowley <jeremy.row...@digicert.com>
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: DigiCert-Symantec Announcement

On Tue, Sep 19, 2017 at 8:39 PM, Jeremy Rowley via dev-security-policy 
<dev-security-policy@lists.mozilla.org> wrote:
>
> The current end-state plan for root cross-signing is provided at 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1401384. The diagrams there show 
> all of the existing sub CAs along with the new Sub CAs and root signings 
> planned for post-close. Some of these don’t have names so they are lumped in 
> a general “Intermediate” box.
>
> The Global G2 root will become the transition root to DigiCert for customers 
> who can’t move fully to an operational DigiCert roots prior to September 
> 2018. Any customers that require a specific root can use the transition root 
> for as long as they want, realizing that path validation may be an issue as 
> Symantec roots are removed by platform operators. Although we cannot 
> currently move to a single root because of the lack of EV support and trust 
> in non-Mozilla platforms, we can move to the existing three roots in an 
> orderly fashion.
>
> If the agreement closes prior to Dec 1, the Managed CA will never exist. 
> Instead, all issuance will occur through one of the three primary DigiCert 
> roots mentioned above with the exception of customers required to use a 
> Symantec root for certain platforms or pinning. The cross-signed Global root 
> will be only transitory, meaning we’d hope customers would migrate to the 
> DigiCert roots once the systems requiring a specific Symantec roots are 
> deprecated or as path validation errors arise.

Jeremy,

Am I correct that a key input into this plan was the Mozilla plan to fully 
remove the Symantec roots from the trust store before then end of 2018?  Google 
seemed to suggest they would keep trusting them for a longer period with a 
restriction on which subordinate CAs are trusted.

Thanks,
Peter


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CAs not compliant with CAA CP/CPS requirement

2017-09-08 Thread Jeremy Rowley via dev-security-policy

Hey Andrew, we are checking CAA records at time of issuance. The CPS update 
should publish today.

> On Sep 8, 2017, at 1:25 PM, Andrew Ayer via dev-security-policy 
>  wrote:
> 
> The BRs state:
> 
> "Effective as of 8 September 2017, section 4.2 of a CA's Certificate
> Policy and/or Certification Practice Statement (section 4.1 for CAs
> still conforming to RFC 2527) SHALL state the CA's policy or practice
> on processing CAA Records for Fully Qualified Domain Names; that policy
> shall be consistent with these Requirements. It shall clearly specify
> the set of Issuer Domain Names that the CA recognises in CAA 'issue' or
> 'issuewild' records as permitting it to issue. The CA SHALL log all
> actions taken, if any, consistent with its processing practice."
> 
> Since it is now 8 September 2017, I decided to spot check the CP/CPSes
> of some CAs.
> 
> At time of writing, the latest published CP/CPSes of the following CAs
> are not compliant with the above provision of the BRs:
> 
> Amazon (https://www.amazontrust.com/repository/) - Does not check CAA
> 
> Comodo (https://www.comodo.com/about/comodo-agreements.php) - Does not
> specify issuer domain names
> 
> DigiCert (https://www.digicert.com/legal-repository/) - Does not
> specify issuer domain names, and processing is not compliant with BRs
> ("If a CAA record exists that does not list DigiCert as an authorized
> CA, DigiCert verifies that the applicant has authorized issuance,
> despite the CAA record.")
> 
> Google Trust Services (https://pki.goog/) - Does not check CAA
> 
> Identrust (https://secure.identrust.com/certificates/policy/ts/) -
> Does not check CAA
> 
> Izenpe
> (http://www.izenpe.eus/s15-content/en/contenidos/informacion/descarga_certificados/es_url/index.shtml)
> - Does not specify issuer domain names
> 
> PROCERT (https://www.procert.net.ve/eng/ca.html) - No mention of CAA
> 
> Symantec / GeoTrust (https://www.geotrust.com/resources/repository/legal/)
> - Does not specify issuer domain names
> 
> Trustis (https://www.trustis.com/pki/trustis-ssl/standard/index.htm) -
> No mention of CAA
> 
> Visa (http://www.visa.com/pki/) - Does not check CAA
> 
> 
> These CAs have compliant CP/CPSes:
> 
> Entrust
> 
> GlobalSign
> 
> GoDaddy
> 
> Let's Encrypt
> 
> QuoVadis
> 
> Trustwave
> 
> 
> It would be nice to hear confirmation from the non-compliant CAs that they
> really are checking CAA as required, and if so, why they overlooked the
> requirement to update their CP/CPS.
> 
> Regards,
> Andrew
> ___
> 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: CAs not compliant with CAA CP/CPS requirement

2017-09-08 Thread Jeremy Rowley via dev-security-policy

Hi Andrew, 

I'm not certain how to update the previous Mozilla response with respect to
CAA, but we added the following as authorized CAA records:
Digicert.com
*.digicert
Digicert.net.jp
Cybertrust.net.jp

I wasn't sure if adding a wildcard to the CAA record is kosher, but I didn't
seem anything prohibiting use of wildcard characters in CAA records.  We saw
quite a few records similar to CAA.digiert.com during the testing and added
this to the list.

Jeremy


Jeremy

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Andrew Ayer via dev-security-policy
Sent: Friday, September 8, 2017 1:25 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: CAs not compliant with CAA CP/CPS requirement

The BRs state:

"Effective as of 8 September 2017, section 4.2 of a CA's Certificate Policy
and/or Certification Practice Statement (section 4.1 for CAs still
conforming to RFC 2527) SHALL state the CA's policy or practice on
processing CAA Records for Fully Qualified Domain Names; that policy shall
be consistent with these Requirements. It shall clearly specify the set of
Issuer Domain Names that the CA recognises in CAA 'issue' or 'issuewild'
records as permitting it to issue. The CA SHALL log all actions taken, if
any, consistent with its processing practice."

Since it is now 8 September 2017, I decided to spot check the CP/CPSes of
some CAs.

At time of writing, the latest published CP/CPSes of the following CAs are
not compliant with the above provision of the BRs:

Amazon (https://www.amazontrust.com/repository/) - Does not check CAA

Comodo (https://www.comodo.com/about/comodo-agreements.php) - Does not
specify issuer domain names

DigiCert (https://www.digicert.com/legal-repository/) - Does not specify
issuer domain names, and processing is not compliant with BRs ("If a CAA
record exists that does not list DigiCert as an authorized CA, DigiCert
verifies that the applicant has authorized issuance, despite the CAA
record.")

Google Trust Services (https://pki.goog/) - Does not check CAA

Identrust (https://secure.identrust.com/certificates/policy/ts/) - Does not
check CAA

Izenpe
(http://www.izenpe.eus/s15-content/en/contenidos/informacion/descarga_certif
icados/es_url/index.shtml)
- Does not specify issuer domain names

PROCERT (https://www.procert.net.ve/eng/ca.html) - No mention of CAA

Symantec / GeoTrust (https://www.geotrust.com/resources/repository/legal/)
- Does not specify issuer domain names

Trustis (https://www.trustis.com/pki/trustis-ssl/standard/index.htm) - No
mention of CAA

Visa (http://www.visa.com/pki/) - Does not check CAA


These CAs have compliant CP/CPSes:

Entrust

GlobalSign

GoDaddy

Let's Encrypt

QuoVadis

Trustwave


It would be nice to hear confirmation from the non-compliant CAs that they
really are checking CAA as required, and if so, why they overlooked the
requirement to update their CP/CPS.

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


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CAs not compliant with CAA CP/CPS requirement

2017-09-11 Thread Jeremy Rowley via dev-security-policy

Let me pull the data and share it with you. For some reason we saw a few sub 
domains right before the 8th. We added *.digicerts.com at the last minute until 
we had time to figure out why. I suspect it's being caused by documentation or 
a partner telling the customers the wrong thing. Once we track down the source, 
we can drop the wildcard.

> On Sep 11, 2017, at 5:09 AM, Gervase Markham  wrote:
> 
> Hi Ben and Jeremy,
> 
>> On 09/09/17 01:25, Ben Wilson wrote:
>> Those are typos.  See section 4.2.1 of our CPS posted here:
>> https://www.digicert.com/wp-content/uploads/2017/09/DigiCert_CPS_v412.pdf 
> 
> This reads:
> 
> "The Certification Authority CAA identifying domains for CAs within
> DigiCert’s operational control are “digicert.com”, “digicert.ne.jp”,
> "cybertrust.ne.jp”, and any domain containing those identifying domains
> as suffixes (e.g. *.digicert.com)."
> 
> This latter part, while not perhaps being against the letter of the RFC,
> is somewhat unhelpful for people who want to write software working with
> CAA, because they now can't just load it with a per-CA list of valid
> domain names, but have to post-process and stem the value in this case.
> Are you certain you need that provision?
> 
> Gerv
> 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CAs not compliant with CAA CP/CPS requirement

2017-09-09 Thread Jeremy Rowley via dev-security-policy

I would have checked Sept 9th as Sept 8th at midnight would be the last 
possible moment when the CPS could be updated and still be compliant.

> On Sep 9, 2017, at 3:33 PM, Andrew Ayer via dev-security-policy 
>  wrote:
> 
> On Fri, 8 Sep 2017 15:22:52 -0700 (PDT)
> Andy Warner via dev-security-policy
>  wrote:
> 
>> Google Trust Services published updated CP & CPS versions earlier
>> today covering CAA checking. I'd suggest checking all CAs again
>> tomorrow. Given the range of timezones CA operational staffs operate
>> across, some may not have had a chance to publish their updates yet.
> 
> At the time I checked, it was already September 8 in all timezones.
> 
>> In terms of the 'rush' I suspect many CAs have had language prepared
>> to publish well in advance, but were holding off given the number of
>> discussions in various forums about how to interpret some sections of
>> the RFC and BRs. Many of those discussions continued until the last
>> moment, so holding off to ensure published details aligned with
>> community consensus was a reasonable approach.
> 
> Could you point to a discussion that would suggest that not checking CAA
> at all (which is what many CAs' CP/CPSes said, including Google Trust
> Services') was a reasonable interpretation of the BRs?
> 
> The published details need to align with what the CA is doing.  In some
> cases there may be ongoing discussions about how to interpret
> requirements (though I believe in the case of CAA they had all
> concluded well before the deadline), but that shouldn't stop a CA from
> publishing how _they_ have interpreted the requirements, so that
> relying parties know what the CA is doing.
> 
> Regards,
> Andrew
> 
> ___
> 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: CAA Certificate Problem Report

2017-09-11 Thread Jeremy Rowley via dev-security-policy

Not saying we implemented DNSSEC checking correctly, but I don't think the 
requirements are as clear as you present them.

The BRs state that:
" 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."

That's the entire corpus of information related to DNSSEC in the BRs. Under 4 
and 5, we successfully returned a DNS record. The lookup didn’t fail so the 
sentence "the domain's zone does not have a DNSSEC validation chain to the 
ICANN root" doesn't apply.  There is no need to check the DNSSEC validation 
chain in this case.

For 3 and 6:
RFC 4033:
1) Is not referenced in the BRs
2) Does not define domain's zone
3) Does not reference a "validation chain" (but does define authentication 
chain as you noted) 
4) Does not mention an ICANN root
5) Is only a footnote in RFC 6844

Although most of these are straight forward without being defined, the 
culmination of semi-loose specifications makes for one very loose specification 
at the CAB Forum level, especially where programs like drill apparently did 
DNSSEC checking wrong. 

Of course, we would like to properly check DNSSEC (or at least check it more 
properly) so I'm interested to hear your opinion on whether this works as a fix:
1) Checking the entire DNSSEC chain was incredibly slow, causing the certs to 
take 10 sec plus to issue.  We figured checking RRSIG removed this delay by 
simply checking whether DNSSEC exists. If DNSSEC exists and we failed to return 
a DNS record, we'll just block the cert. 
2) Instead of checking the DNSSEC chain, could we simply check the DNSKEY RR at 
the parent? If the DNS RRSet exists at the parent, we will simply refuse the 
cert issuance.  This way we avoid the super long issuance times while still 
respecting DNSSEC requirements.

Thanks a ton for the discussion on this.
Jeremy

-Original Message-
From: Andrew Ayer [mailto:a...@andrewayer.name] 
Sent: Saturday, September 9, 2017 1:01 PM
To: Jonathan Rudenberg 
Cc: Jonathan Rudenberg via dev-security-policy 
; Peter Bowen ; 
mozilla-dev-security-pol...@lists.mozilla.org; Jeremy Rowley 

Subject: Re: CAA Certificate Problem Report

On Sat, 9 Sep 2017 06:57:39 -0400
Jonathan Rudenberg via dev-security-policy 
 wrote:

> 
> > On Sep 9, 2017, at 06:19, Peter Bowen via dev-security-policy 
> >  wrote:
> > 
> > In all three of these cases, the "domain's zone does not have a 
> > DNSSEC validation chain to the ICANN root" -- I requested SOA, 
> > DNSKEY, NS, and CAA records types for each zone and in no case did I 
> > get a response that had a valid DNSSEC chain to the ICANN root.
> 
> This comes down to what exactly “does not have a valid DNSSEC chain”
> means.

As I explained in my reply to Peter, it's not "valid DNSSEC chain", but rather 
a "validation chain", which is defined by RFC4033, albeit under the synonymous 
term "authentication chain".

> I had assumed that given the reference to DNSSEC in the BRs that the 
> relevant DNSSEC RFCs were incorporated by reference via RFC 6844 and 
> that DNSSEC validation is required. However, this is not entirely the 
> case, using DNSSEC for CAA lookups is only RECOMMENDED in section 4.1 
> and explicitly “not required.” Which means this is all pretty 
> pointless. The existence or non-existence of DNSSEC records doesn’t 
> matter if there is no requirement to use them.

The BRs could arguably be interpreted to not require DNSSEC validation during 
lookups, although as I explained in my reply to Jeremy I do not find this to be 
a very compelling interpretation.

However, it is not at all ambiguous that a request must be denied if the lookup 
fails for non-DNSSEC reasons, if there is DNSSEC validation chain to the ICANN 
root.  Given the reference to RFC4033 from RFC6844 in the definition of DNSSEC, 
CAs should be able to figure out what this means. Therefore, the blackhole and 
refused certs are unquestionably misissuances, if not also missing and expired.

Regards,
Andrew

smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

CAA Certificate Problem Report

2017-09-09 Thread Jeremy Rowley via dev-security-policy

Hi everyone, 

 

We received a certificate problem report at 11 pm on Sep 8, 2017 from Andrew
Ayer alleging the mis-issuance of 6 certificates because of a failure to
properly verify CAA records.

 

I'm sharing the report here because there are questions about CAA record
checking that we feel are better shared with the broader community.  We're
looking for clarification on whether these are a) mis-issuances based on a
misunderstanding of the requirement, b) an issue with the test suite used to
verify CAA compliance, or c) gaps in the RFC/BRs. The report:

 

[DigiCert] issued the following certificates in violation of the Baseline
Requirements' CAA checking requirement:

 

1.
https://crt.sh/?sha256=26F4FFABCF94AA16A85C7F02D9F4604E74A41ACE51DA1C55B732E
1618798D04A

2.
https://crt.sh/?sha256=2619EAA800BA627CC3C1971DF0BB8006B2831B500935E94379952
4E81CA3EDAB

3.
https://crt.sh/?sha256=D0DA8826B05D5A079E4356D4FED6300A94B0E2B9E6E40FCB6AAEA
C1F2163AF2E

4.
https://crt.sh/?sha256=300D20D0E63112AD77D09BBA8F02E9B075E265DF21E0FE6F18C38
CD11179D43B

5.
https://crt.sh/?sha256=CC08B270A8BF66D431E9AC073C7014373F6CE582F1CF5C08CF73C
340F91327FB

6.
https://crt.sh/?sha256=A3AA9FDC0ED72C29C969E76A929F517EB093A574ED2C248CBAFC7
85767403FC6

 

Certificate 1 contains a single DNS identifier for
big.basic.caatestsuite.com  .  This DNS
name has a CAA resource record set that is too large to fit within a single
DNS UDP packet, but small enough to fit within a DNS TCP packet.  The only
CAA record containing an issue property is:

big.basic.caatestsuite.com  . IN
CAA 0 issue "caatestsuite.com  "

Therefore, only caatestsuite.com   is allowed to
issue for this identifier.

 

[JR] We only check CAA records with UDP to keep performance good on certs
with hundreds of SANs. I couldn't find a requirement that mandates use of
TCP to check CAA records.  Should TCP be required? 

 

Certificate 2 contains a single DNS identifier for
cname-deny-sub.basic.caatestsuite.com
 .  The following DNS records
are

relevant:

cname-deny-sub.basic.caatestsuite.com
 . IN CNAME
sub.deny.basic.caatestsuite.com  .

deny.basic.caatestsuite.com  . IN CAA 0
issue "caatestsuite.com  "

There is no CAA record at sub.deny.basic.caatestsuite.com
 .  According to RFC 6844, the only
CA allowed to issue for cname-deny-sub.basic.caatestsuite.com
 

is caatestsuite.com  .

 

[DC] I don't read the RFC this way. I know both the CAB Forum and IETF hotly
debated CNAME's interplay with CAA  a couple of times, but I thought we were
awaiting on adoption of the Errata to determine the proper resolution.   My
interpretation of the RFC remains that the CA verifies  X.Y.Z, then the
alias of X.Y.Z, then Y.Z,  then alias of Y.Z, etc.  If A.B.C. is the alias
of X.Y.Z, you'd only verify the CAA record at A.B.C., not A.B.C. followed by
B.C. followed by C. This is perhaps clarified in the  RFC errata, but that
is not official yet and not part of the BR requirement.  I don't think
there's sufficient clarity around the correct CAA-CNAME process to implement
a code change.

 

Certificate 3 contains a single DNS identifier for
refused.caatestsuite-dnssec.com  .
Attempts to query the CAA record for this DNS name result in a REFUSED DNS
response.  Since there is a DNSSEC validation chain from this zone to the
ICANN root, CAs are not permitted to treat the lookup failure as permission
to issue.

 

[DC] This will always issue. A refusal is treated as a failure.  Under the
BRs a failure is permission to issue if we retry and DNSSec is not present.
However, although DNSSec is present on the test suite's side, we can't see
it.  Therefore, we get refused (a lookup failure), retry (resulting in
another lookup failure), followed by a DNSSec check (which fails because
retrieving the RSSIG record is refused).  There's no path under which this
won't issue because we can't see whether DNSSec is present.

 

Certificate 4 contains a single DNS identifier for
missing.caatestsuite-dnssec.com  .
This DNS name has no CAA records, but the zone is missing RRSIG records.
Since there is a DNSSEC validation chain from this zone to the ICANN root,
the DNS lookup should fail and this failure cannot be treated by the CA as
permission to issue.

 

[DC]  I believe this is properly issued.  We retrieved the DNS record (no
failure) and found no CAA record present.  The relevant portion of the BRs
state: "CAs are permitted to treat a record lookup failure as permission to
issue if: . the failure is outside the

RE: CAA Certificate Problem Report

2017-09-11 Thread Jeremy Rowley via dev-security-policy

Well, we are checking CAA and DNSSEC per our implementation. Looks great on our 
side and against our tests.  Some individuals disagree though.

From: Ryan Sleevi [mailto:r...@sleevi.com] 
Sent: Monday, September 11, 2017 3:42 PM
To: Jeremy Rowley <jeremy.row...@digicert.com>; Jonathan Rudenberg 
<jonat...@titanous.com>
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: CAA Certificate Problem Report

That seems like very poor logic and justification.

Given that CAA and DNSSEC has been discussed in the CA/Browser Forum for 
literally years now, perhaps it's worth asking why CAs are only now discovering 
issues. That is, is the only reason we're discovering issues because CAs waited 
for the last possible moment? If so, why.

Because they didn't write test suites? If not, why not? If so, what were they?

I think arguments that suggest that failing to do the right thing makes it OK 
to do the wrong thing are the worst arguments to make :)

On Mon, Sep 11, 2017 at 2:28 PM Jeremy Rowley via dev-security-policy 
<dev-security-policy@lists.mozilla.org 
<mailto:dev-security-policy@lists.mozilla.org> > wrote:

I would support that.  I can't recall why it's in there.

-Original Message-
From: Jonathan Rudenberg [mailto:jonat...@titanous.com 
<mailto:jonat...@titanous.com> ]
Sent: Monday, September 11, 2017 3:19 PM
To: Jeremy Rowley <jeremy.row...@digicert.com 
<mailto:jeremy.row...@digicert.com> >
Cc: mozilla-dev-security-pol...@lists.mozilla.org 
<mailto:mozilla-dev-security-pol...@lists.mozilla.org> 
Subject: Re: CAA Certificate Problem Report

> On Sep 11, 2017, at 17:03, Jeremy Rowley via dev-security-policy 
> <dev-security-policy@lists.mozilla.org 
> <mailto:dev-security-policy@lists.mozilla.org> > wrote:
>
> For a little more context, the idea is that we can speed up the CAA check for 
> all customers while working with those who have DNSSEC to make sure they 
> aren't killing performance.  If there's a way to group them easily into 
> buckets (timeout + quick does DNSSEC exist check), working on improving the 
> experience for that particular set of customers is easier. That bucket can 
> then be improved later.

Given the disaster that DNSSEC+CAA has been over the past few days for multiple 
CAs and the fact that it’s optional in the CAA RFC, what do you think about 
proposing a ballot to remove the DNSSEC requirement from the BRs entirely?

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

smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: CAA Certificate Problem Report

2017-09-11 Thread Jeremy Rowley via dev-security-policy

For a little more context, the idea is that we can speed up the CAA check for 
all customers while working with those who have DNSSEC to make sure they aren't 
killing performance.  If there's a way to group them easily into buckets 
(timeout + quick does DNSSEC exist check), working on improving the experience 
for that particular set of customers is easier. That bucket can then be 
improved later.

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org]
 On Behalf Of Jeremy Rowley via dev-security-policy
Sent: Monday, September 11, 2017 2:56 PM
To: Nick Lamb <tialara...@gmail.com>; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: RE: CAA Certificate Problem Report

I think that's the opposite of what I'm saying.  CAs don't need to do DNSSEC 
provided 1) they don't want to issue certs where DNSSEC is implemented and 2) 
the CAA record check times out, and 3) there is a way to check if DNSSEC is 
present without doing the entire chain validation. #3 is what I'm not sure of.  

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org]
 On Behalf Of Nick Lamb via dev-security-policy
Sent: Monday, September 11, 2017 2:52 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: CAA Certificate Problem Report

On Monday, 11 September 2017 18:33:24 UTC+1, Jeremy Rowley  wrote:
> That's the entire corpus of information related to DNSSEC in the BRs. Under 4 
> and 5, we successfully returned a DNS record. The lookup didn’t fail so the 
> sentence "the domain's zone does not have a DNSSEC validation chain to the 
> ICANN root" doesn't apply.  There is no need to check the DNSSEC validation 
> chain in this case.

Mmm. So your belief is that you're not actually required to do DNSSEC here at 
all? If Honest Achmed is asked to issue for example.com, he can do a plain (non 
DNSSEC) lookup, receive a spoofed "0 answers" for CAA on example.com, and issue 
on that basis, never needing to investigate whether example.com has DNSSEC 
enabled (it does), let alone whether the CAA response was properly signed ?

I guess if that's the common interpretation of this document at least it'd be 
good to understand which CAs are vulnerable in this way. Of course, even if you 
know this it's pointless to exclude them using CAA, they'll accept a spoofed 
answer...
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: CAA Certificate Problem Report

2017-09-11 Thread Jeremy Rowley via dev-security-policy

I would support that.  I can't recall why it's in there.

-Original Message-
From: Jonathan Rudenberg [mailto:jonat...@titanous.com] 
Sent: Monday, September 11, 2017 3:19 PM
To: Jeremy Rowley <jeremy.row...@digicert.com>
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: CAA Certificate Problem Report


> On Sep 11, 2017, at 17:03, Jeremy Rowley via dev-security-policy 
> <dev-security-policy@lists.mozilla.org> wrote:
> 
> For a little more context, the idea is that we can speed up the CAA check for 
> all customers while working with those who have DNSSEC to make sure they 
> aren't killing performance.  If there's a way to group them easily into 
> buckets (timeout + quick does DNSSEC exist check), working on improving the 
> experience for that particular set of customers is easier. That bucket can 
> then be improved later.

Given the disaster that DNSSEC+CAA has been over the past few days for multiple 
CAs and the fact that it’s optional in the CAA RFC, what do you think about 
proposing a ballot to remove the DNSSEC requirement from the BRs entirely?

Jonathan


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: CAA Certificate Problem Report

2017-09-11 Thread Jeremy Rowley via dev-security-policy

I think that's the opposite of what I'm saying.  CAs don't need to do DNSSEC 
provided 1) they don't want to issue certs where DNSSEC is implemented and 2) 
the CAA record check times out, and 3) there is a way to check if DNSSEC is 
present without doing the entire chain validation. #3 is what I'm not sure of.  

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org]
 On Behalf Of Nick Lamb via dev-security-policy
Sent: Monday, September 11, 2017 2:52 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: CAA Certificate Problem Report

On Monday, 11 September 2017 18:33:24 UTC+1, Jeremy Rowley  wrote:
> That's the entire corpus of information related to DNSSEC in the BRs. Under 4 
> and 5, we successfully returned a DNS record. The lookup didn’t fail so the 
> sentence "the domain's zone does not have a DNSSEC validation chain to the 
> ICANN root" doesn't apply.  There is no need to check the DNSSEC validation 
> chain in this case.

Mmm. So your belief is that you're not actually required to do DNSSEC here at 
all? If Honest Achmed is asked to issue for example.com, he can do a plain (non 
DNSSEC) lookup, receive a spoofed "0 answers" for CAA on example.com, and issue 
on that basis, never needing to investigate whether example.com has DNSSEC 
enabled (it does), let alone whether the CAA response was properly signed ?

I guess if that's the common interpretation of this document at least it'd be 
good to understand which CAs are vulnerable in this way. Of course, even if you 
know this it's pointless to exclude them using CAA, they'll accept a spoofed 
answer...
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: DigiCert-Symantec Announcement

2017-10-01 Thread Jeremy Rowley via dev-security-policy

Is this a correct summary? 

 

There’s four categories of customers that require trust in existing Symantec 
roots being address:

1.  Those that can migrate to a new trusted root because they use the certs 
in a standard TLS-configuration
2.  Those that require a certain Symantec root for various applications but 
can use a DigiCert root for standard browser-based TLS
3.  Those that require a non-trusted intermediate because they have pinned 
a Symantec root in the application and using a trusted DigiCert root, even if 
cross-signed would cause the application to fail.
4.  Those that pinned a specific intermediate’s keys, resulting in a 
failure unless the issuing CA had the same keys as used by Symantec. 

 

Category 1 customers are straight-forward.  They will be migrated to a DigiCert 
root.

 

Category 2 customers are potentially straight forward but could have validation 
issues.  If we cross-sign the DigiCert global root with the required Symantec 
root, then the customer can migrate but might experience issues when the root 
is actually removed.  However, this could cause issues for the 84 certificates 
already using the DigiCert root.

 

Category 3 customers are potentially straight forward but will lose trust in 
Sep 2018 unless the new root is embedded prior to that date. If we create a new 
root, sign it with the Symantec roots, and embed the new roots as necessary, we 
avoid the problems with a previously trusted root.  Wouldn’t this have the same 
validation issues as Category 2? 

 

Category 4 is under discussion.  Sounds like Google would prefer not to see a 
reuse of keys. Pinning times are sufficiently short that customers could 
migrate to the new infrastructure prior to total distrust of the roots under 
certain circumstances. If the cert was issued prior to June 2016, and the key 
expires after March 2018, anyone using the pin could be locked out until the 
pin expires. If pins last up to a year, customers issuing a cert after June 
2016 should have time to migrate prior to root removal. One issue is that these 
customers won’t be able to get a new cert that functions off the old 
intermediate post Dec 1, 2017, effectively meaning key compromises cannot be 
addressed.

 

=

Jeremy

 

 

From: Ryan Sleevi [mailto:r...@sleevi.com] 
Sent: Monday, September 25, 2017 8:18 PM
To: Peter Bowen 
Cc: Ryan Sleevi ; 
mozilla-dev-security-pol...@lists.mozilla.org; Jeremy Rowley 

Subject: Re: DigiCert-Symantec Announcement

 

 

 

On Sun, Sep 24, 2017 at 12:40 PM, Peter Bowen  > wrote:

I agree that 3b potentially has a higher risk than 3z, but it has a
higher reward.  3b allows pins to continue to work even if the trust
store removes 3.  It comes down to the level of protection of the root
key.  If it is secure, then this provides continued compatibility
while removing the original root.  The 3z option means that all pins
to the existing root break.

This isn't really a risk for browser-based applications, after all the
browser can implement a "known bad pins" list and not enforce pinning
if all the pins are on that list or can choose to not enforce pins if
older than a certain date.  However in a situation where the
application is distinct from the browser, this does not work.  I
realize this isn't Mozilla (or Chrome's) problem, but it is important
to consider in the broader Internet PKI view.

Thanks,
Peter

 

Peter,

 

Thanks for confirming that this isn’t a concern for browser-based applications. 
While not to suggest they are the only participant that matters in the Web PKI, 
I think it would be fair to say that many of the concessions and workarounds 
have been heretofore focused on the browser-based case.

 

That said, I’m not sure it’s as dire as you suspect. As noted in the previous 
message, an adoption of 3z wouldn’t break applications pinned to 3 unless and 
until a root store took steps to remove. We’ve seen some platforms, such as 
macOS and iOS, take steps for manual whitelisting of pre-existing certs. We’ve 
seen other platforms, such as Windows, take steps based on timestamping or date 
issued. Most importantly, however, the only public discussions regarding 
removal have suggested a timeframe of late-2018. Applications that pinned 
certificates, without the ability to update in a year, are arguably outside of 
the scope of ‘reasonable’ use cases - the ecosystem itself has shown itself to 
change on at least that frequency.

 

As such, hopefully it’s persuasive that the reward for 3b compared to 3z is not 
actually significant, especially for browsers, and the risk is arguably much 
greater. Repeating the pattern of 2z & 3z, for every root with active issuance, 
provides the greatest way to reduce risk for applications that have pinned and 
need additional migration time. Note that the plan would still suggest that all 
users should be moved

Re: O=U.S. Government for non-USG entity (IdenTrust)

2017-08-17 Thread Jeremy Rowley via dev-security-policy

Without an FQDN, I doubt they are in scope for the baseline requirements. They 
are in scope for the Mozilla policy. The BRs require the cert to be intended 
for web tls. These are not. The Mozilla policy covers client certs as well as 
tls.

> On Aug 17, 2017, at 12:27 PM, identrust--- via dev-security-policy 
>  wrote:
> 
> On Wednesday, August 16, 2017 at 1:45:12 PM UTC-4, Jonathan Rudenberg wrote:
>>> On Aug 16, 2017, at 12:52, Jonathan Rudenberg via dev-security-policy 
>>>  wrote:
>>> 
>>> I looked through the CT logs and found 15 more unexpired unrevoked 
>>> certificates that are trusted by NSS and appear to have the same inaccurate 
>>> organizationName of “U.S. Government” for a non-USG entity.
>>> 
>>> The list is here: https://misissued.com/batch/10/
>>> 
>>> Can you explain why your review missed these? Are there any more in 
>>> addition to these 15 and previous 5?
>>> 
>>> Jonathan
>> 
>> After looking into this more, I’ve found that the majority of certificates 
>> issued by the "IdenTrust ACES CA 2” and "IdenTrust ACES CA 1” intermediates 
>> are not BR-compliant.
>> 
>> The issues fall into three categories:
>> 
>> 1) Certificates with HTTPS OCSP URLs
>> 2) Certificates with otherName SANs
>> 3) Certificates that appear to be intended as client certificates, but have 
>> the anyExtendedKeyUsage EKU, putting them in scope for the Mozilla Root 
>> Policy.
>> 
>> I’ve found 33 certificates that have one or more of these issues that are 
>> unexpired and unrevoked.
>> 
>> Here is the full list: https://misissued.com/batch/11/ (note that it is a 
>> superset of the batch I posted earlier today)
>> 
>> Jonathan
> and also in reference to number 1 but regarding non US Government issue 
> certificates, here is the reply in the expected format:
> Issue: Non US Government Certificates issued with o=US Government (IdenTrust) 
>
> 1.How your CA first became aware of the problems listed below (e.g. via a 
> Problem Report, via the discussion in mozilla.dev.security.policy, or via 
> this Bugzilla Bug), and the date.
> IdenTrust: Problem Reported to IdenTrust  via the Mozilla Dev Security Policy 
> Forum on August 8, 2017
> 2.Prompt confirmation that your CA has stopped issuing TLS/SSL 
> certificates with the problems listed below.
> IdenTrust: on August 9, IdenTrust acknowledged the issue and offered a formal 
> reply before the end of the business day. A formal reply was supplied to the 
> forum the following day August 10, 2017:
> 3.Complete list of certificates that your CA finds with each of the 
> listed issues during the remediation process. The recommended way to handle 
> this is to ensure each certificate is logged to CT and then attach a CSV 
> file/spreadsheet of the fingerprints or crt.sh IDs, with one list per 
> distinct problem.
> IdenTrust: On August 16, 2017 we have identified a total of 164 ACES 
> certificates reflecting o=US Government for non-US government entities. 
> 4.Summary of the problematic certificates. For each problem listed below:
> number of certs, date first and last certs with that problem were issued.
> IdenTrust: The date range of the ACES certificates with issue is from 
> 08/21/2015 to 05/12/2017
> 5.Explanation about how and why the mistakes were made, and not caught 
> and fixed earlier. 
> IdenTrust: When IdenTrust initially established the ACES SSL certificate 
> profile (around 2002), it was intended to apply only to US government 
> entities.  At that time, the Organization was defined as a static value of 
> “U.S. Government” in our profiles.  Subsequently around 2007, when 
> non-agencies were identified to require ACES SSL certificates under the ACES 
> policy, IdenTrust interpreted the policy at that time that this static value 
> continued to be acceptable as these entities must identify themselves as 
> organizations that act as relying parties affiliated with a government 
> program, accepting client certificates issued under the ACES program, and are 
> in some capacity associated with the U.S. Government programs.  Once we were 
> notified of the problem, we consulted internally and with GSA (owner of the 
> ACES policy) and have determined that this interpretation needs to be updated 
> to align  with BR requirements.  As such we updated our processes and 
> profiles to include the Organization as the non-agencies when the FQDN owner 
> is not directly U.S. Government agency. 
> 6.List of steps your CA is taking to resolve the situation and ensure 
> such issuance will not be repeated in the future, accompanied with a timeline 
> of when your CA expects to accomplish these things.
> IdenTrust:
> 1.Effective August 7, 2017 the ACES SSL profile and process has been 
> updated to use the applicant Organization name in the Subject DN organization 
> field include only HTTP OCSP URLs. 
> 2.Other IdenTrust SSL Sub-CA’s have been

RE: Anomalous Certificate Issuances based on historic CAA records

2017-11-29 Thread Jeremy Rowley via dev-security-policy

Yes, CAA transparency should exist. Right now CAA is only a point-in-time check 
by the CA with no way to verify what the CA saw or what was processed. This was 
one of the limitations raised during the discussions about adoption. Without 
some transparency, the reliance is on the CA to ensure the CAA record checking 
is properly done and not useful to subscribers. Despite the lack of 
transparency, CAA checking is still useful as it can help a CA prevent 
unauthorized issuance, even if the prevention/CAA record check results aren’t 
publicly available. CAA is a useful tool for CAs but could be a more useful 
tools for researchers if there was a good way to make the record check results 
more publicly available.  

Jeremy

From: Ben Laurie [mailto:b...@google.com] 
Sent: Wednesday, November 29, 2017 3:01 PM
To: Jeremy Rowley <jeremy.row...@digicert.com>
Cc: douglas.beat...@gmail.com; mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Anomalous Certificate Issuances based on historic CAA records

This whole conversation makes me wonder if CAA Transparency should be a thing.

On 29 November 2017 at 20:44, Jeremy Rowley via dev-security-policy 
<dev-security-policy@lists.mozilla.org 
<mailto:dev-security-policy@lists.mozilla.org> > wrote:

The Thawte records aren't showing any CAA record preventing wildcards either.

Here's the Thawte CAA record logs for the domain:

2017-09-13 05:25:09.117 [pool-3058695-thread-1] [] INFO  
c.s.s.r.service.CAAV2CheckService - Lookup domain: trnava-vuc.sk 
<http://trnava-vuc.sk>  type: 257 result: 4 lookupTimeout: 500
2017-09-13 05:25:09.117 [pool-3058693-thread-1] [] INFO  
c.s.s.r.service.CAAV2CheckService - Looking for alias for: trnava-vuc.sk 
<http://trnava-vuc.sk> 
2017-09-13 05:25:09.117 [pool-3058696-thread-1] [] INFO  
c.s.s.r.service.CAAV2CheckService - Lookup domain: trnava-vuc.sk 
<http://trnava-vuc.sk>  type: 5 result: 4 lookupTimeout: 750
2017-09-13 05:25:09.117 [pool-3058692-thread-1] [] INFO  
c.s.s.r.service.CAAV2CheckService - CAAResponse: CAAMatchCode : [32] : CAAInput 
: [trnava-vuc.sk <http://trnava-vuc.sk> ] : CAAMatchMessage : [CAA record not 
found] : CAADNSRecords : [ ]
2017-09-13 05:25:09.118 [pool-3058691-thread-1] [] INFO  
c.s.s.r.service.CAAV2CheckService - Time taken in seconds for CAA check of 
trnava-vuc.sk <http://trnava-vuc.sk>  is: 1
2017-09-13 05:25:09.118 [pool-3058693-thread-1] [] INFO  
c.s.s.r.service.CAAV2CheckService - CAAResponse: CAAMatchCode : [32] : CAAInput 
: [*.trnava-vuc.sk <http://trnava-vuc.sk> ] : CAAMatchMessage : [CAA record not 
found] : CAADNSRecords : [ ]
2017-09-13 05:25:09.118 [pool-3058691-thread-2] [] INFO  
c.s.s.r.service.CAAV2CheckService - Time taken in seconds for CAA check of 
*.trnava-vuc.sk <http://trnava-vuc.sk>  is: 2

Jeremy
-Original Message-
From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley 
<mailto:dev-security-policy-bounces%2Bjeremy.rowley> 
=digicert@lists.mozilla.org <mailto:digicert@lists.mozilla.org> ] On 
Behalf Of douglas.beattie--- via dev-security-policy
Sent: Wednesday, November 29, 2017 4:27 AM
To: mozilla-dev-security-pol...@lists.mozilla.org 
<mailto:mozilla-dev-security-pol...@lists.mozilla.org> 
Subject: Re: Anomalous Certificate Issuances based on historic CAA records

Hi Quirin,

I'm curious about how you recorded the historical information from DNS, can you 
explain how this was requested and logged?

We logged the data used for issuance of the GlobalSign certificate at the time 
of issuance and it's different from what you recorded.

We logged that there was no “issuewild” entry and that "digicert.com 
<http://digicert.com> ", "globalsign.com <http://globalsign.com> ", 
"letsencrypt.org <http://letsencrypt.org> " and "rapidssl.com 
<http://rapidssl.com> " are all defined as “issue” at time of issuance.

Doug

On Friday, November 24, 2017 at 7:23:25 AM UTC-5, Gervase Markham wrote:
> Hi Quirin,
>
> Thank you for your work on this topic. I would be grateful if you
> could file Bugzilla bugs in the Misissuance component as follows,
> giving your evidence of misissuance:
>
> On 22/11/17 23:50, Quirin Scheitle wrote:
> > 1) Mix of wildcard and non-wildcard DNS names in SAN
> > Batch: 
> > https://clicktime.symantec.com/a/1/4dVQ4kGvYsWRmDR0QMfBBhhwpXEgvnl0A7TEgxMQx-Y=?d=rkGEi9PYD9VAuJcuuNl_82EIceTRmNUV-CSz6VnLprGkKWC5qO_pTFqzTqItIrlHULu_74YdlLpwafEHJsWyJlsnxXxdlqbrgtuvS2sVM1lDR58zsfgSszsL1BsUK0qlPgkKq9Jm-IsHuRYomXUaQ3iu5fLmzKVagdoX0LhTmygTygjdgc-zyO2ThD4noAPAfEow_4QSRxJzWUxIFdyghvj1lzF-xWhxb__1OvcJCp9aGkIYWZYDZ73ecMsovTuRD8H39wXh4pqzMlwLWvkpNPyQRRp7mHoxoa00SNpoC18PP-_01YOSM5ijfGx8vefcuDDcKt1DWhMNKto4Ezgv5Q2w_-J4j4EUpa9FliuJA2nOqD_Y2or0a_6EcFLl2sGoNa120tlyjhfxSMd6SBF4WxXgrWRvI2vQ324f-Zjgp9maEE02aJVanB-D5Fa2kjOEax5n8dtFGFmTHF6mGdm3Ciwy38yneQ5QEbjN

RE: Anomalous Certificate Issuances based on historic CAA records

2017-11-30 Thread Jeremy Rowley via dev-security-policy

I think we can be more transparent about CAA records without requiring CT. I 
don’t have a solution, but more transparency about processing CAA records 
couldn’t hurt.

From: Ryan Sleevi [mailto:r...@sleevi.com] 
Sent: Thursday, November 30, 2017 3:12 PM
To: Tim Hollebeek 
Cc: Wayne Thayer ; r...@sleevi.com; 
douglas.beat...@gmail.com; mozilla-dev-security-pol...@lists.mozilla.org; Paul 
Wouters ; Ben Laurie ; Jeremy Rowley 

Subject: Re: Anomalous Certificate Issuances based on historic CAA records

Right, and to my point:

Each transparency mechanism has to be specific to the problem it's trying to 
solve. CT is not a magic cureall for transparency - it's specific to, well, 
certificates, and more generally, TLS web certificates.

For things like S/MIME, you have "Key Transparency" (based on COINKS)

For things like binaries, you have "Binary Transparency"

For things like DNSSEC authority records, you could have "DNSSEC transparency"

It would be a mistake to think CT is some cureall, just like it would be a 
mistake to think "blockchain" suddenly solves all problems. The design of the 
technology, and its assumptions about the ecosystem, are relevant.

The general problem of any *Transparency system is you need a way to 
authenticate the data that is logged to some extent, and you need a way to 
independently verify or evaluate that data. Certificates provide both 
signatures and trust chains, so you get both. The constraints around privacy of 
S/MIME certificates (which are unique to them) lend themselves to a different 
technical solution, like Key Transparency.

As it relates to DNS, DNS sans-DNSSEC has no way to authenticate the data. So 
either your authentication is to introduce TTPs that can log the data (whether 
it's the Log or some multi-perspective contractually trusted third-party) or 
you need to find a way to sign the data (which DNSSEC is). Yet all that does is 
create a merkle hash tree - the system for ensuring and validating consistency 
and accuracy of that is also going to depend on the specific case.

I agree that the fact that a certificate must be disclosed to a log, and that 
logs are independent of CAs, make it very easy and appealing to suggest that 
logs should serve as the counterbalance to CAs. That's neither the design nor 
the goal - logs are meant to be neutral record-keepers with no trust afforded 
to them - with monitors/auditors/clients keeping them honest, and anyone (not 
just CAs) being able to ask them to record the facts.

There's obviously a gray area right now because of spec violations being things 
you want to log, but you also don't want to normalize - and CT Policy Days 
discussions around that continue to be interesting. But as it relates to CAA 
Transparency, it's both confusing the purpose of CAA (a machine readable 
expression of intent) and CT (no TTPs)

On Thu, Nov 30, 2017 at 4:16 PM, Tim Hollebeek  > wrote:

Wayne, your last point is closest to my thinking, and I whole-heartedly agree 
there may be better solutions.  My suggestion was that if CAA transparency is a 
desired thing, and it is clear that at least a few people think it is worth 
considering, it’s probably better to do it with existing transparency 
mechanisms instead of making up new ones.

There’s a lot of CAA debugging going on in private right now, and there isn’t 
necessarily an a priori reason why it has to be private.

-Tim

From: Wayne Thayer [mailto:wtha...@mozilla.com  ] 
Sent: Thursday, November 30, 2017 2:07 PM
To: Tim Hollebeek  >
Cc: r...@sleevi.com  ; douglas.beat...@gmail.com 
 ; 
mozilla-dev-security-pol...@lists.mozilla.org 
 ; Paul Wouters 
 >; Ben Laurie  >; Jeremy Rowley  >
Subject: Re: Anomalous Certificate Issuances based on historic CAA records

What problem(s) are you trying to solve?

- Subscribers already (or soon will) have CT logs and monitors available to 
detect mis-issued certs. They don't need CAA Transparency.

- This thread started as a discussion over possible mis-issuance that was 
determined to be false positives. As has been stated, without DNSSEC there is 
no such thing as a coherent view of DNS and Ryan described a legitimate example 
where a domain owner may consciously update CAA records briefly to permit 
issuance. It's unclear to me how CAA Transparency could solve this problem and 
thus provide a mechanism to confirm mis-issuance, if that is the goal.

- The goal of reducing the

RE: Anomalous Certificate Issuances based on historic CAA records

2017-11-29 Thread Jeremy Rowley via dev-security-policy

The Thawte records aren't showing any CAA record preventing wildcards either. 

Here's the Thawte CAA record logs for the domain:

2017-09-13 05:25:09.117 [pool-3058695-thread-1] [] INFO  
c.s.s.r.service.CAAV2CheckService - Lookup domain: trnava-vuc.sk type: 257 
result: 4 lookupTimeout: 500
2017-09-13 05:25:09.117 [pool-3058693-thread-1] [] INFO  
c.s.s.r.service.CAAV2CheckService - Looking for alias for: trnava-vuc.sk
2017-09-13 05:25:09.117 [pool-3058696-thread-1] [] INFO  
c.s.s.r.service.CAAV2CheckService - Lookup domain: trnava-vuc.sk type: 5 
result: 4 lookupTimeout: 750
2017-09-13 05:25:09.117 [pool-3058692-thread-1] [] INFO  
c.s.s.r.service.CAAV2CheckService - CAAResponse: CAAMatchCode : [32] : CAAInput 
: [trnava-vuc.sk] : CAAMatchMessage : [CAA record not found] : CAADNSRecords : 
[ ]
2017-09-13 05:25:09.118 [pool-3058691-thread-1] [] INFO  
c.s.s.r.service.CAAV2CheckService - Time taken in seconds for CAA check of 
trnava-vuc.sk is: 1
2017-09-13 05:25:09.118 [pool-3058693-thread-1] [] INFO  
c.s.s.r.service.CAAV2CheckService - CAAResponse: CAAMatchCode : [32] : CAAInput 
: [*.trnava-vuc.sk] : CAAMatchMessage : [CAA record not found] : CAADNSRecords 
: [ ]
2017-09-13 05:25:09.118 [pool-3058691-thread-2] [] INFO  
c.s.s.r.service.CAAV2CheckService - Time taken in seconds for CAA check of 
*.trnava-vuc.sk is: 2

Jeremy
-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org]
 On Behalf Of douglas.beattie--- via dev-security-policy
Sent: Wednesday, November 29, 2017 4:27 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Anomalous Certificate Issuances based on historic CAA records

Hi Quirin,

I'm curious about how you recorded the historical information from DNS, can you 
explain how this was requested and logged?

We logged the data used for issuance of the GlobalSign certificate at the time 
of issuance and it's different from what you recorded.

We logged that there was no “issuewild” entry and that "digicert.com", 
"globalsign.com", "letsencrypt.org" and "rapidssl.com" are all defined as 
“issue” at time of issuance.

Doug

On Friday, November 24, 2017 at 7:23:25 AM UTC-5, Gervase Markham wrote:
> Hi Quirin,
> 
> Thank you for your work on this topic. I would be grateful if you 
> could file Bugzilla bugs in the Misissuance component as follows, 
> giving your evidence of misissuance:
> 
> On 22/11/17 23:50, Quirin Scheitle wrote:
> > 1) Mix of wildcard and non-wildcard DNS names in SAN
> > Batch: 
> > https://clicktime.symantec.com/a/1/4dVQ4kGvYsWRmDR0QMfBBhhwpXEgvnl0A7TEgxMQx-Y=?d=rkGEi9PYD9VAuJcuuNl_82EIceTRmNUV-CSz6VnLprGkKWC5qO_pTFqzTqItIrlHULu_74YdlLpwafEHJsWyJlsnxXxdlqbrgtuvS2sVM1lDR58zsfgSszsL1BsUK0qlPgkKq9Jm-IsHuRYomXUaQ3iu5fLmzKVagdoX0LhTmygTygjdgc-zyO2ThD4noAPAfEow_4QSRxJzWUxIFdyghvj1lzF-xWhxb__1OvcJCp9aGkIYWZYDZ73ecMsovTuRD8H39wXh4pqzMlwLWvkpNPyQRRp7mHoxoa00SNpoC18PP-_01YOSM5ijfGx8vefcuDDcKt1DWhMNKto4Ezgv5Q2w_-J4j4EUpa9FliuJA2nOqD_Y2or0a_6EcFLl2sGoNa120tlyjhfxSMd6SBF4WxXgrWRvI2vQ324f-Zjgp9maEE02aJVanB-D5Fa2kjOEax5n8dtFGFmTHF6mGdm3Ciwy38yneQ5QEbjN038nIZxAwx1l9SBe=https%3A%2F%2Fmisissued.com%2Fbatch%2F32%2F
> > Description: best confer 
> > https://clicktime.symantec.com/a/1/bRWz8YI8GaFJN5p0wMSlE_HKuFXeSpidx
> > EosAdBNIhw=?d=rkGEi9PYD9VAuJcuuNl_82EIceTRmNUV-CSz6VnLprGkKWC5qO_pTF
> > qzTqItIrlHULu_74YdlLpwafEHJsWyJlsnxXxdlqbrgtuvS2sVM1lDR58zsfgSszsL1B
> > sUK0qlPgkKq9Jm-IsHuRYomXUaQ3iu5fLmzKVagdoX0LhTmygTygjdgc-zyO2ThD4noA
> > PAfEow_4QSRxJzWUxIFdyghvj1lzF-xWhxb__1OvcJCp9aGkIYWZYDZ73ecMsovTuRD8
> > H39wXh4pqzMlwLWvkpNPyQRRp7mHoxoa00SNpoC18PP-_01YOSM5ijfGx8vefcuDDcKt
> > 1DWhMNKto4Ezgv5Q2w_-J4j4EUpa9FliuJA2nOqD_Y2or0a_6EcFLl2sGoNa120tlyjh
> > fxSMd6SBF4WxXgrWRvI2vQ324f-Zjgp9maEE02aJVanB-D5Fa2kjOEax5n8dtFGFmTHF
> > 6mGdm3Ciwy38yneQ5QEbjN038nIZxAwx1l9SBe=https%3A%2F%2Fgroups.google
> > .com%2Fd%2Fmsg%2Fmozilla.dev.security.policy%2FO9HZPMvHMY8%2FHtXR8S-
> > 1AAAJ
> 
> One bug per CA, please.
> 
> > 4) Apparent non-evaluation of CAA records
> > Batch: 
> > https://clicktime.symantec.com/a/1/ZSn0R3LPoUJA--jAELl6kXSjRsrKYmYOKsgQn5Gve1U=?d=rkGEi9PYD9VAuJcuuNl_82EIceTRmNUV-CSz6VnLprGkKWC5qO_pTFqzTqItIrlHULu_74YdlLpwafEHJsWyJlsnxXxdlqbrgtuvS2sVM1lDR58zsfgSszsL1BsUK0qlPgkKq9Jm-IsHuRYomXUaQ3iu5fLmzKVagdoX0LhTmygTygjdgc-zyO2ThD4noAPAfEow_4QSRxJzWUxIFdyghvj1lzF-xWhxb__1OvcJCp9aGkIYWZYDZ73ecMsovTuRD8H39wXh4pqzMlwLWvkpNPyQRRp7mHoxoa00SNpoC18PP-_01YOSM5ijfGx8vefcuDDcKt1DWhMNKto4Ezgv5Q2w_-J4j4EUpa9FliuJA2nOqD_Y2or0a_6EcFLl2sGoNa120tlyjhfxSMd6SBF4WxXgrWRvI2vQ324f-Zjgp9maEE02aJVanB-D5Fa2kjOEax5n8dtFGFmTHF6mGdm3Ciwy38yneQ5QEbjN038nIZxAwx1l9SBe=https%3A%2F%2Fmisissued.com%2Fbatch%2F33%2F
> > Description: These cases appear as pretty straight-forward that they 
> > should not have been issued, but
> > there might be good explanations
> 
> One bug for the two Comodo certs, one for the Camerfirma cert.
> 
> Thank you,
> 
> Gerv

___

DigiCert/Symantec updates

2017-11-15 Thread Jeremy Rowley via dev-security-policy

Hey everyone, 

 

I wanted to give the community and update on how the DigiCert-Symantec
transition is going and make everyone aware of a few issues I recently
created on Bugzilla.  

 

First, the good news.  DigiCert has started validating and issuing
certificates through the Symantec platform for a limited number of
customers.  The initial tests are positive, and I think we're on track to
meet the Dec 1 requirements.  Thanksgiving next week is going to be a sad
holiday, but we're very excited to see everything go live.  Right now, we
are doing DV, OV, and EV validation, although only issuing DV certs (as a
test of the integration).  You can see the hierarchy and migration plans
here: https://bugzilla.mozilla.org/show_bug.cgi?id=1401384. I'm happy to
answer any questions about it as well.

 

The bad news is there are some compliance issues. 

 

1.  EV JOI issues. I filed this a while ago but never posted about it.
This bug (https://bugzilla.mozilla.org/show_bug.cgi?id=1413761) caused
duplicate certificates to issue with incorrect JOI information. Basically,
when someone duplicated with a different key (RSA vs. ECC), incorrect JOI
information would be placed in the certificate.  The certs were revoked and
everything was dumped into CT.
2.  CAA Woes. Like most CAs, Symantec had improper CAA record checking
where DNSSEC was not properly checked if the record timed out.
(https://bugzilla.mozilla.org/show_bug.cgi?id=1409735). A patch was applied
to prevent this. As of Dec 1, all CAA record checking will be done by
DigiCert's systems instead of the systems we acquired from Symantec.
3.  Undisclosed CAs.  The details are a little iffy on this one so far,
but I think there are a couple hundred undisclosed issuing CAs within
Symantec's infrastructure.  These CAs are not issuing TLS certs from what I
can see, but they aren't disclosed in CCDAB
(https://bugzilla.mozilla.org/show_bug.cgi?id=1417771). I'll be posting
updates there as we figure out what we're looking at.  I think there was
confusion about whether these required disclosure as they don't issue certs
and are within the Symantec HSMs. I think disclosure and audit reports are
required so we'll be updating the latest audit report to show them.

 

And my least favorite because its DigiCert pre-close:

4.  Insufficient Entropy.  This one makes me sad because of how dumb it
is (https://bugzilla.mozilla.org/show_bug.cgi?id=141).  DigiCert's older
validation system validated domain control using random values in emails
sent to the WHOIS contact. These random values did not contain 112 bits of
entropy.  They contained 112 bits, but some of the characters were fixed.
The actual entropy was about 77.  Only the one system was impacted.  The
root cause was a developer not realizing 112 bits != 112 bits of entropy.
All other systems were verified as operationally correct.  This impacts a
large number of certs (like tens of thousands) so we're not 100% sure on how
to best remediate, especially since significant entropy still existed in the
random value. 

 

Let me know what questions/comments you have. Looking forward to the
discussion!

Jeremy

 



smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Incident Report : GoDaddy certificates with ROCA Fingerprint

2017-11-01 Thread Jeremy Rowley via dev-security-policy

Hey Alex - we intend to publish a report for the former Symantec certs.  For 
now, here's what I know:

1) The scope was 15 TLS certs. We became aware of the certs through your 
posting.  
2) We are revoking all 15 certs. I'm still waiting for their serial numbers. We 
kicked off the 24 hour period today so they should all be revoked tomorrow.

That's about all I know right now.
Jeremy

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org]
 On Behalf Of Alex Gaynor via dev-security-policy
Sent: Friday, October 27, 2017 9:08 AM
To: Daymion Reynolds 
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Incident Report : GoDaddy certificates with ROCA Fingerprint

Thank you for writing this up.

Do any of the other CAs with trusted server certificates intend to publish 
similar reports? (Based on CT logs that'd be Comodo, Symantec, and GlobalSign).

Alex

On Tue, Oct 24, 2017 at 12:28 PM, Daymion Reynolds via dev-security-policy < 
dev-security-policy@lists.mozilla.org> wrote:

> Godaddy LLC first became aware of possible ROCA vulnerability exposure 
> on Monday October 16th 2017 at 9:30am. The following are the steps we 
> took for detection, revocation, and the permanent fix of certificate 
> provisioning:
>
> •   Monday October 16th 2017 AZ, first became aware of the ROCA
> vulnerability.  We downloaded and modified the open source detection 
> tool to audit 100% of the non-revoked and non-expired certs we had issued.
> •   Early am Wednesday October 18th AZ we had our complete list of 7
> certs with the ROCA defect. We verified the results and proceeded to 
> start the revocation process. While cert revocation was in progress we 
> started researching the long-term detection and prevention of the weak 
> CSR vulnerability.
> •   Early am Wednesday October 18th Rob Stradling released a list of
> certs with the vulnerability. 2/7 we revoked were on the list.
> https://clicktime.symantec.com/a/1/1SkDS7vkKe6aFPef3aMSvQFIofogSXtMjIDOMPSrNdU=?d=y7maDzQwn0t2gfiNBTRLLoxLptvalFLxhxxGV50FFf2HN_GpCO0GEQ5_rJD53axlha3VgyPx5e47idtKKh9Q430x5oQoja_2JjwYYimO70LL-IABmm8rLDDwsSe6D-SQ4vUvLFK8QmovkdoVYa5s4bx_lJw2M8RHGF6MxFEinJ-dFtEuoLiaF_FuBO7KEhoOnoqj2At2y3L-V1_T2U3QXqMynZvbpNH7wBgbuTN89gmguJAKE4Wff-cB1Q590BZYVEFmTUCwDBXXB-aCCKdMZU-CPbiC27t9PqIsHpBTeMTdqeYJIPkES4fzuq6TW8no6Bh0q9461T37F4JqNHK-9ybFxA8-HEacA0WU6u25efXCjiK0bzUgwVRxB9vTYtCoXtet39vQB7YyQRj0Rgyh8TU7keVb3WjzVERe0Pp3r7l3JmD6_4RyNRVIUiI8Kjf9WRn-N0rHOgbvv9p_hin3dr7wSFSS85zlq4g65z0_L1idMgpHVkqfaf33dUSsaghwqNn5=https%3A%2F%2Fmisissued.com%2Fbatch%2F28%2F
> •   Thursday October 19th by 2:02am AZ, we completed the 7 cert
> revocations. Revocations included customer outreach to advise the 
> customer of the vulnerability.
> •   Thursday October 19th AZ, two CSRs were submitted for commonNames “
> scada2.emsglobal.net” & “scada.emsglobal.net” and were issued. Each 
> request had used the vulnerable keys for CSR generation.  We revoked 
> the certs again on Thursday October 19th AZ. During this period, we 
> reached out to the customer to educate them regarding the 
> vulnerability and informing them they needed to generate a new keypair from 
> an unimpacted device.
> Customer was unreachable. Friday October 20thAZ,  another cert was 
> issued for commonName “scada.emsglobal.net” using a CSR generated with 
> a weak key. We then took measures to prevent future certs from being 
> issued to the same common name and revoked the cert on October 20th 2017 AZ.
> commonName   crt.sh-link
> scada.emsglobal.net  
> https://clicktime.symantec.com/a/1/4ypxaC37c0Q-AJ7bui52CmnZ0rpGYzh75RU
> ZYnpk23A=?d=y7maDzQwn0t2gfiNBTRLLoxLptvalFLxhxxGV50FFf2HN_GpCO0GEQ5_rJ
> D53axlha3VgyPx5e47idtKKh9Q430x5oQoja_2JjwYYimO70LL-IABmm8rLDDwsSe6D-SQ
> 4vUvLFK8QmovkdoVYa5s4bx_lJw2M8RHGF6MxFEinJ-dFtEuoLiaF_FuBO7KEhoOnoqj2A
> t2y3L-V1_T2U3QXqMynZvbpNH7wBgbuTN89gmguJAKE4Wff-cB1Q590BZYVEFmTUCwDBXX
> B-aCCKdMZU-CPbiC27t9PqIsHpBTeMTdqeYJIPkES4fzuq6TW8no6Bh0q9461T37F4JqNH
> K-9ybFxA8-HEacA0WU6u25efXCjiK0bzUgwVRxB9vTYtCoXtet39vQB7YyQRj0Rgyh8TU7
> keVb3WjzVERe0Pp3r7l3JmD6_4RyNRVIUiI8Kjf9WRn-N0rHOgbvv9p_hin3dr7wSFSS85
> zlq4g65z0_L1idMgpHVkqfaf33dUSsaghwqNn5=https%3A%2F%2Fcrt.sh%2F%3Fid%
> 3D3084867
>
> scada.emsglobal.net  
> https://clicktime.symantec.com/a/1/OB-olazZASanecDv3efdwDvRV66LosOv7dP
> Crn-2tbc=?d=y7maDzQwn0t2gfiNBTRLLoxLptvalFLxhxxGV50FFf2HN_GpCO0GEQ5_rJ
> D53axlha3VgyPx5e47idtKKh9Q430x5oQoja_2JjwYYimO70LL-IABmm8rLDDwsSe6D-SQ
> 4vUvLFK8QmovkdoVYa5s4bx_lJw2M8RHGF6MxFEinJ-dFtEuoLiaF_FuBO7KEhoOnoqj2A
> t2y3L-V1_T2U3QXqMynZvbpNH7wBgbuTN89gmguJAKE4Wff-cB1Q590BZYVEFmTUCwDBXX
> B-aCCKdMZU-CPbiC27t9PqIsHpBTeMTdqeYJIPkES4fzuq6TW8no6Bh0q9461T37F4JqNH
> K-9ybFxA8-HEacA0WU6u25efXCjiK0bzUgwVRxB9vTYtCoXtet39vQB7YyQRj0Rgyh8TU7
> keVb3WjzVERe0Pp3r7l3JmD6_4RyNRVIUiI8Kjf9WRn-N0rHOgbvv9p_hin3dr7wSFSS85
> zlq4g65z0_L1idMgpHVkqfaf33dUSsaghwqNn5=https%3A%2F%2Fcrt.sh%2F%3Fid%
>

1 2 3 >

1 - 100 of 293 matches

Mail list logo