Re: Symantec Update on SubCA Proposal

[Rick Andrews via dev-security-policy]

On Wednesday, July 26, 2017 at 10:20:08 AM UTC-7, Alex Gaynor wrote:
> On Tue, Jul 25, 2017 at 4:28 PM, Rick Andrews via dev-security-policy
> wrote:
> 
> > Symantec has proposed timing changes that are consistent with the scope of
> > distrust of the original SubCA proposal as proposed by Google and endorsed
> > by Mozilla, which requires premature replacement of over 234,000
> > certificates based on our proposed May 1, 2018 distrust date for
> > certificates issued before June 1, 2016, and optimizes for replacement
> > certificates to be issued off the new Managed CA(s) infrastructure
> > (avoiding the requirement for double early replacement for the same
> > original validity period). We believe our proposal minimizes disruption to
> > websites and web end-users while meeting the spirit of Google’s and
> > Mozilla’s prior commentary on their intent regarding the SubCA proposal,
> > which is to limit the issuance of Symantec certificates under Symantec’s
> > existing infrastructure and governance.
> >
> 
> Hi Rick,
> 
> Given the importance of this 234,000 number, I was curious to explore.
> Using the list of certificates Peter Bowen previously put together (
> https://groups.google.com/a/chromium.org/d/msg/blink-dev/eUAKwjihhBs/aQqYZX6oBgAJ),
> I ran a small script to filter out ones that expire before May 2018, or
> were issued after June 2016. Using this methodlogy, I got a count of 166k,
> a deviation of ~70k from your number. My 166k includes any certificates
> that have been replaced since Peter put together the list in April, so in
> that sense it likely reflects an over estimate of the number of certs
> needing to be replaced.
> 
> Can you say a little more on how you came to this number?
> 
> Cheers,
> Alex

Our reference to over 234,000 certificates is based on our internal records of 
all active, unrevoked certificates that we issued prior to June 1, 2016 that 
expire after May 1, 2018. The dataset you reference relies on CT logs, which 
includes all active EV certificates Symantec has issued before June 1, 2016, 
but does not include all active, unrevoked OV and DV certificates Symantec has 
issued before June 1, 2016.
___
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

[Rick Andrews via dev-security-policy]

On Monday, July 24, 2017 at 2:50:22 AM UTC-7, Gervase Markham wrote:
> Hi Rick,
> 
> Some more thoughts on your post. I continue to invite community
> commentary on the issues we are discussing.
> 
> On 21/07/17 07:00, Rick Andrews wrote:
> > In our June 1 post, we stated that we would update the community after the 
> > end of the month. 
> 
> Indeed. I was more referring to the suggestions made in the meeting with
> Mozilla about when the public statement would be forthcoming. But no matter.
> 
> > Correct. However, as we indicated in our update, with a change of
> > this magnitude we believe that there will likely be material
> > compatibility and interoperability issues that will only come to
> > light once server operators begin the transition to the Managed CA
> > issued certificates. Recognizing this, we recommend that we establish
> > a clear process to evaluate exception requests that includes
> > consultations with the browsers to handle such corner cases.
> Operators who have initial difficulty with the transition can, of
> course, stay on their certificates issued from the old infrastructure.
> (It's worth noting that if all of those customers had recently renewed
> their certificates, as my proposal suggests, then there would not be a
> problem with their existing-infra certs expiring while they were
> attempting to make the transition.)

In practice, this is much more difficult. For larger organizations, PKI 
administration is often a dedicated function where administrators may have 
limited visibility into the applications using specific certificates. This 
makes communication along the lines of "well, for these types of applications, 
your existing certificates are fine, but in these others they need a change" 
much more subject to error and will likely lead to disruption and downtime.  

> How would you see such an exception process working, and how would it be
> implemented technically?

The details of this process would probably be best served in a separate thread. 
Essentially, such a process would involve a quick assessment by the community 
on the context and merits of the request by the customer, the impact of denying 
such a request, and a model to actually operationalize such a request (such as 
potentially white-listing some certificates for a period of time). In the ideal 
case, these requests that can only be resolved through an exception will not be 
common, but we believe that we should prepare for such contingencies given the 
scope of certificates covered, as we have learned with other transitions, such 
as the SHA1 transition. A placeholder of this type would allow us to reach 
closure on the operational aspects of the proposal. We can then later begin 
discussions regarding what such a process would look like. 

> > While this is true under the terms of the SubCA proposal, we do not
> > believe this is consistent with the spirit of Google’s and Mozilla’s
> > prior commentary on their intent regarding the SubCA proposal, which
> > is to limit the issuance of Symantec certificates under Symantec’s
> > existing infrastructure and governance.
> I'm not sure how you reach that conclusion. We want to end new issuance
> in December, you want it to continue until next May. How are our dates
> more inconsistent than yours with a desire to limit the issuance of
> Symantec certificates under the existing infrastructure and governance?
> We want to limit it earlier.

We may be more aligned on this point than your response suggests. We are in 
agreement with you that we will cease issuing certificates under the existing 
infrastructure and governance on December 1, 2017. At that point you could stop 
accepting the issuance of new certificates off the existing infrastructure and 
PKI. (See our last reply to this thread where we confirmed this point, but 
asked for an exception process.) Our point here is that if you also make 
December 1, 2017 the "distrust date" for all certificates issued off of 
Symantec’s current PKI before June 1, 2016 then, in effect, you will be forcing 
all customers to "double down" on the existing Symantec PKI and infrastructure 
because they would need to be issued early replacement certificates off of the 
current PKI. Alternatively, if the distrust date of all certificates issued 
before June 1, 2016 were to be moved to May 1, 2018 (as opposed to December 1, 
2017 as you currently propose) it would allow these replacement certificates to 
chain to the new PKI because they would be issued by the Managed CA(s) off of 
the new SubCA(s). This, we believe, was one of the intents of the original 
proposal which was to move users to the new infrastructure and PKI as quickly 
as possible. A December 1, 2017 distrust date (for certificates issued before 
June 1, 2016) would

Re: [EXT] Symantec Update on SubCA Proposal

[Rick Andrews via dev-security-policy]

On Friday, July 21, 2017 at 12:39:54 PM UTC-7, Peter Bowen wrote:
> Steve,
> 
> I think this level of public detail is very helpful when it comes to
> understanding the proposal.
> 
> On Thu, Jul 20, 2017 at 8:00 AM, Steve Medin via dev-security-policy
> wrote:
> > 1)  December 1, 2017 is the earliest credible date that any RFP 
> > respondent can provide the Managed CA solution proposed by Google, assuming 
> > a start date of August 1, 2017. Only one RFP respondent initially proposed 
> > a schedule targeting August 8, 2017 (assuming a start date of June 12, 
> > 2017). We did not deem this proposal to be credible, however, based on the 
> > lack of specificity around our RFP evaluation criteria, as compared to all 
> > other RFP responses which provided detailed responses to all aspects of the 
> > RFP, and we have received no subsequent information from this bidder to 
> > increase our confidence.
> 
> You note that this assumes a start date of June 12.   A later email
> from Rick Andrews says "Our proposed dates assume we are able to
> finalize negotiation of contracts with the selected Managed CA
> partner(s), [...] by no later than July 31, 2017."
> 
> Presumably the June 12 date is long gone.  However if one assumes the
> delta of 57 days from start to delivery stands, this would put
> delivery at September 26, 2017.  This is two months sooner than the
> December 1 date.  This seems like a pretty big difference.  Given you
> are asking to delay the timeline based on other RFP respondents being
> unable to hit earlier dates, it seems prudent to ask whether the you
> attempted to investigate the proposal from the bidder who proposed
> August 8.

Please see our response to Alex Gaynor.
 
> Given that one of the requirements stated by Google is that the SubCA
> operator had to have roots that have been in the Google trust store
> for several years, it seems unusual that any eligible respondent would
> not be "credible" out of the gate.
> 
> Did you ask them to provide more information and details to help
> determine if it was a "credible" offer?

There is a difference between a prospective SubCA being capable of performing 
the activities of a Managed CA under the SubCA proposal and having a realistic 
plan to do so. We concluded the RFP response from the sole respondent who 
proposed a 2-month timeline was not credible because it failed to meet a 
minimum bar of providing us with sufficient information to evaluate the 
bidder’s ability to satisfy RFP requirements or meaningfully compare / contrast 
the bidder’s response with all other RFP respondents.  There were other 
attributes relating to this bidder’s proposal beyond its lack of content in 
addressing RFP evaluation criteria that reinforced our conclusion that the bid 
was not credible.

> > 2)  We are using several selection criteria for evaluating RFP 
> > responses, including the depth of plan to address key technical integration 
> > and operational requirements, the timeframe to execute, the ability to 
> > handle the scope, volume, language, and customer support requirements both 
> > for ongoing issuance and for one-time replacement of certificates issued 
> > prior to June 1, 2016, compliance program and posture, and the ability to 
> > meet uptime, interface performance, and other SLAs. Certain RFP respondents 
> > have distinguished themselves based on the quality and depth of their 
> > integration planning assumptions, requirements and activities, which have 
> > directly influenced the dates we have proposed for the SubCA proposal.
> >
> > 3)  The RFP was first released on May 26, 2017. The first round of 
> > bidder responses was first received on June 12, 2017.
> 
> In the 
> https://groups.google.com/a/chromium.org/d/msg/blink-dev/eUAKwjihhBs/ovLalSBRBQAJ
> message, it was implied that Symantec was aware of the SubCA plan and
> dates since at least May 12.  Given the plan to sign an agreement by
> July 31, the August 8 date seems rather impossible. Did Symantec push
> back on the August 8 date at that point?

Yes, Symantec pushed back on the August 8 date in its earliest discussions with 
both Google and Mozilla after the SubCA proposal was made. We pushed back on 
the dates again publicly on June 1st.  We have now done the work of executing a 
robust RFP process that included multiple parties and involved multiple working 
sessions to arrive at dates that are both aggressive and achievable for the 
size and scale of our CA operations. 

> In the original email that started this subthread, you said, "Some of
> the prospective Managed CAs have proposed supporting only a portion of
> our volume (some by customer segment, others by geographic 

Re: [EXT] Symantec Update on SubCA Proposal

[Rick Andrews via dev-security-policy]

On Friday, July 21, 2017 at 12:07:02 PM UTC-7, Alex Gaynor wrote:
> On Thu, Jul 20, 2017 at 11:00 AM, Steve Medin wrote:
> 
> > 1)  *December 1, 2017 is the earliest credible date that any RFP
> > respondent can provide the Managed CA solution proposed by Google, assuming
> > a start date of August 1, 2017. Only one RFP respondent initially proposed
> > a schedule targeting August 8, 2017 (assuming a start date of June 12,
> > 2017). We did not deem this proposal to be credible, however, based on the
> > lack of specificity around our RFP evaluation criteria, as compared to all
> > other RFP responses which provided detailed responses to all aspects of the
> > RFP, and we have received no subsequent information from this bidder to
> > increase our confidence.*
> >
> >
> Hi Steve,
> 
> Given that this represents nearly a 4 month difference in timelines, can
> you give us any more insight here as why you see such a large delta?
> 
> Alex

We have evaluated the rigor of the proposals with regard to integration between 
Symantec and the Managed CA(s) for all certificate lifecycle functions for 
retail, partner, and Enterprise RA models, supporting enrollment, all methods 
of domain verification, organization and extended validation vetting, 
re-authentication, replacement, renewal, cancelation, modification, revocation, 
CAA checking, CT logging, and CRL and OCSP response provisioning; the models 
for cross-team engagement and release planning; identification of any gaps and 
the plans to address; and the plans for end-to-end testing. The most aggressive 
of the RFP responses was the sole outlier in terms of timing (2 months to 
implementation) and offered the least amount of information in response to the 
RFP. There were other attributes relating to this bidder’s proposal beyond its 
lack of content in addressing RFP evaluation criteria that reinforced our 
conclusion that the bid was not realistic.  The difference between the most 
aggressive timing proposal when compared with the other RFP respondent plans 
was only about two months. All other RFP responses independently offered 
project plan timelines that spanned approximately 4-6 months. Symantec’s 
internal planning concluded that a 4 month timeline was aggressive but 
achievable.
___
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

[Rick Andrews via dev-security-policy]

On Thursday, July 20, 2017 at 12:31:56 PM UTC-7, Gervase Markham wrote:
> Hi Steve,
> 
> Thanks for posting this. I appreciate the level of detail provided,
> which is useful in giving us a basis for discussion. It's a little
> regrettable, though, that it was published a couple of weeks after we
> were led to expect it...

In our June 1 post, we stated that we would update the community after the end 
of the month. Considering the community’s request for detail in our response, 
we wanted our update to reflect our latest discussions with RFP respondents, 
which took place during the first two weeks of July.  These discussions have 
directly informed our proposed dates as described in our post.  We also felt it 
was important to collect feedback from both Google and Mozilla (which we have 
done) on our draft timing proposal before submitting it to the community for 
consideration given that Google and Mozilla authored / endorsed the SubCA 
proposal.

> One note before we start: Symantec's business dealings regarding its CA
> business are not of concern to Mozilla other than relating to the
> "change of ownership or control" provisions in Mozilla policy (policy
> 2.5 section 8). However, if dates are proposed or agreed for
> implementation of the consensus plan, we would not expect those dates to
> be renegotiated because of a change of ownership or control.
> 
> Am I right in saying that, in order to hit these dates you are
> proposing, you would strongly desire to get consensus on them by August 1st?

Symantec would like to reach consensus on the totality of the SubCA proposal, 
including final dates, as soon as possible.  This is in the best interest of 
all.  Our proposed dates assume we are able to finalize negotiation of 
contracts with the selected Managed CA partner(s), which incorporate final 
agreed-upon dates by the community, by no later than July 31, 2017.

> On 18/07/17 19:22, Steve Medin wrote:
> > New Certificate Issuance: We believe the dates for transition of validation 
> > and issuance to the Managed CA that are both aggressive and achievable are 
> > as follows:
> > 
> > - Implement the Managed CA by December 1, 2017 (changed from August 8, 
> > 2017);
> > 
> > - Managed CA performs domain validation for all new certificates by 
> > December 1, 2017 (changed from November 1, 2017); and
> > 
> > - Managed CA performs full validation for all certificates by February 1, 
> > 2018. Prior to this date, reuse of Symantec authenticated organization 
> > information would be allowable for certificates of <13 months in validity.
> 
> To summarise for those reading along: this represents a change of a
> little less than 4 months for the first date, 1 month for the second
> date, and the third date is as originally proposed.

This is correct. We have worked with our RFP respondents to put together an 
aggressive but achievable plan that delivers on the spirit of the original 
proposal.

> Steve: to be clear, this means that browsers could implement a block on
> certificates from Symantec's existing PKI as follows: after December
> 1st, 2017, they could dis-trust all certificates with a notBefore
> greater than December 1st 2017?

Correct. However, as we indicated in our update, with a change of this 
magnitude we believe that there will likely be material compatibility and 
interoperability issues that will only come to light once server operators 
begin the transition to the Managed CA issued certificates. Recognizing this, 
we recommend that we establish a clear process to evaluate exception requests 
that includes consultations with the browsers to handle such corner cases.

> Given the explanations Symantec has given as to why these dates are
> reasonable, and the effort required to stand up the new PKI, I am minded
> to accept them, particularly as they have managed to hit the third
> originally-proposed date on the nose. However, I am still open to
> community input.
> 
> > Replacement of Unexpired Certificates Issued Before June 1, 2016: There are 
> > two major milestones that must be achieved after implementation of the 
> > Managed CA in order to replace unexpired certificates issued before June 1, 
> > 2016 that do not naturally expire before the distrust date(s) in the SubCA 
> > proposal. Those include the full revalidation of certificate information 
> > and then the customer replacement of those certificates. 
> 
> That is not necessarily so. The customers could replace their
> certificates using new, CT-logged certificates from Symantec's old
> infrastructure. This doesn't require any revalidation or any change in
> the certificate chain, so should have excellent compatibility
> properties, and it's something that could begin today.

While this is true under the terms of the SubCA proposal, we do not believe 
this is consistent with the spirit of Google’s and Mozilla’s prior commentary 
on their intent regarding the SubCA proposal, which is to limit the issuance of 
Symantec certif

Re: Symantec: Draft Proposal

[Rick Andrews via dev-security-policy]

I'm posting this on behalf of Symantec:

We would like to update the community about our ongoing dialogue with Google.  
 
Following our May 4th post, senior executives at Google and Symantec 
established a new dialogue with the intention to arrive at a new proposal for 
the community that addresses the substantial customer impact that would result 
from prior proposals. We urge Symantec customers and the browser community to 
pause on decisions related to this matter until final proposals are posted and 
accepted. The intent of both Google and Symantec is to arrive at a proposal 
that improves security while minimizing business disruption across the 
community.
 
We want to reassure the community that we are taking these matters and the 
impact on the community very seriously.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Compliance with 7.1.4.2.1 (internal names revocation)

[Rick Andrews]

We conducted a search of our databases in September 2016, in which we examined 
every CN and SAN in every certificate still valid at the time. Each CN and SAN 
was examined to see if it contained no dot or an invalid DNS suffix; if so, the 
certificate was classified as an internal server cert and revoked. For all 
remaining CNs and SANs, those were checked against our internal list of TLDs 
built from information provided by ICANN and IANA. That list had a status value 
associated with each TLD, and our mistake was in excluding TLDs with certain 
status values.

Our scans conducted this week discovered three additional certificates that had 
not been revoked as of October 2016. These, and the certificate discovered by 
Nick, have now been revoked. Here are the links to those certificates:

https://crt.sh/?sha256=A642406A2BDF92DF8C9FB9322A81736506DDED79A20A7CD33CBEFD2AD2581167
https://crt.sh/?sha256=12B3CCC45D66B9CB2206DEF1C5A24B062CCC938694C92A0806D1D34845C0FC19
https://crt.sh/?sha256=E90AFAE4998D2B8103058ADF35810D87CCE5E98A0E1D691D2A558A6A4E115BAC

Thanks again to Nick for discovering this and pointing it out.

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

Re: Compliance with 7.1.4.2.1 (internal names revocation)

[Rick Andrews]

Thanks for finding this, Nick. We're in the process of revoking the cert you 
found, and searching for any others. We'll get back to you when we're done.

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

Re: Open BR Compliance Bugs

[Rick Andrews]

Kathleen, https://bugzilla.mozilla.org/show_bug.cgi?id=1269332 is not a BR 
violation. Kurt suggested we remove explicitText, but it's just a suggestion.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: New SHA-1 certificates issued in 2016

[Rick Andrews]

On Friday, November 4, 2016 at 4:49:28 AM UTC-7, Gervase Markham wrote:
> On 03/11/16 18:09, Andrew Ayer wrote:
> > This is just as bad as signing an actual cert with SHA-1.
> 
> Add:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1315225 (Symantec)
> 
> Gerv

I updated the bug to say that this was disclosed back in March and discussed on 
https://groups.google.com/forum/#!searchin/mozilla.dev.security.policy/64$3Aa9$3A32$3A73$3Aa4$3A19$3Ad1$3A64/mozilla.dev.security.policy/siHOXppxE9k/0PLPVcktBAAJ
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: TSYS Application for SHA-1 Issuance - Counter-cryptanalysis

[Rick Andrews]

On Tuesday, July 19, 2016 at 1:05:13 PM UTC-7, Andrew Whalley wrote:
> Greetings,
> 
> I have run the tool provided by dr.ir. Marc Stevens [1] on the
> tbsCertificates provided by Symantec [2]
> 
> And see no evidence of collisions:
> 
> $ ./sha1dcsum_partialcoll *.tbs
> 6ead26663275c388662dfdbc23ff0a76cdcf74dc  ssl1.tsysacquiring.net.1.tbs
> 3365793f36c197047b2f595c0f85c67b807c765f  ssl1.tsysacquiring.net.2.tbs
> 3c47155a5d9880a6893925e1c4479f914b3b9ffe  ssl1.vitalps.net.1.tbs
> d130d1a8c51bce7323ba984b2f6298d0750405f4  ssl1.vitalps.net.2.tbs
> c9eb52c30bfaaaba5a1e060723e3c9e4b25f7b1e  ssl2.vitalps.net.1.tbs
> 3698794f1cabc3036380cc2adbc2805393098c45  ssl2.vitalps.net.2.tbs
> e7233e69a89b6b7568f790482b73f635d2464a95  ssl3.vitalps.net.1.tbs
> 9c7bbae0fc9b08c5304908bd956c5b4b37c4e1c7  ssl3.vitalps.net.2.tbs
> 
> I'd be interested to know if anybody else replicates this.
> 
> Marc - I believe that the tool as posted doesn't give assurance to the full
> 80 bit security level.  If that's true do you have an estimate of the
> security level it does provide?
> 
> Many thanks,
> 
> Andrew
> 
> [1] see https://marc-stevens.nl/research/ &
> https://svn.marc-stevens.nl/collisiondetection/
> [2] https://cabforum.org/pipermail/public/2016-July/007999.html

Marc, it's been pointed out in the CABF list [1] that the analysis you did on 
the second set of seven was on the original certificates, on which we based new 
TBSCertificates. Your analysis wasn't done on the new TBSCertificates. The new 
TBSCertificates differ from the original certificates only in serial number and 
date fields.

[1] https://cabforum.org/pipermail/public/2016-July/008147.html
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Intermediate certificate disclosure deadline in 2 weeks

[Rick Andrews]

On Friday, July 8, 2016 at 4:21:27 PM UTC-7, Rick Andrews wrote:
> GSA which governs FPKI recently approved Symantec’s proposal for one-way 
> cross-certification with the FBCA and to remove the cross-certificate from 
> the Symantec CA to the FBCA. The cross certificate is expiring on June 31, 
> 2016 and Symantec does not intend to renew the certificate going forward.

Correction - it's expiring on July 31, 2016.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Intermediate certificate disclosure deadline in 2 weeks

[Rick Andrews]

GSA which governs FPKI recently approved Symantec’s proposal for one-way 
cross-certification with the FBCA and to remove the cross-certificate from the 
Symantec CA to the FBCA. The cross certificate is expiring on June 31, 2016 and 
Symantec does not intend to renew the certificate going forward.

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

Re: Request to enable EV for VeriSign Class 3 G4 ECC root

[Rick Andrews]

On Friday, April 22, 2016 at 6:41:46 AM UTC-7, Richard Barnes wrote:
> That is not the criterion, Rick.  The criterion is "capable of being used
> to issue new certificates":
> 
> """
> All certificates that are capable of being used to issue new certificates,
> and which directly or transitively chain to a certificate included in
> Mozilla's CA Certificate Program, MUST be operated in accordance with 
> Mozilla's
> CA Certificate Policy
> 
> and MUST either be *technically constrained* or be *publicly disclosed and
> audited.*
> """
> 
> So until that CA is constrained, disclosed+audited, or revoked, the G4 root
> is out of compliance with Mozilla's policy.  If you have any more of these
> around, please make sure include them in your upcoming disclosures.
> 
> --Richard
> 
> 
> 
> > We are planning to revoke the Symantec AATL ECC Intermediate CA and
> > provide it along with the "Revoked" list of ICAs to Mozilla in the coming
> > month.
> > ___
> > dev-security-policy mailing list
> >

It was an oversight. We'll disclose it in SalesForce today.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Request to enable EV for VeriSign Class 3 G4 ECC root

[Rick Andrews]

On Wednesday, April 20, 2016 at 12:47:58 PM UTC-7, Charles Reiss wrote:
> On 04/13/16 23:12, Kathleen Wilson wrote:
> > Request to enable EV for VeriSign Class 3 G4 ECC root
> > 
> > This request by Symantec is to enable EV treatment for the "VeriSign
> > Class 3 Public Primary Certification Authority - G4" root certificate
> > that was included via bug #409235, and has all three trust bits
> > enabled.  Symantec is a major commercial CA with worldwide operations
> > and customer base.
> > 
> > The request is documented in the following bug: 
> > https://bugzilla.mozilla.org/show_bug.cgi?id=833974
> > 
> > And in the pending certificates list: 
> > https://wiki.mozilla.org/CA:PendingCAs
> > 
> > Summary of Information Gathered and Verified: 
> > https://bugzilla.mozilla.org/attachment.cgi?id=8734043
> > 
> > Noteworthy points:
> > 
> > * The primary documents are the CP and CPS, which are provided in
> > English.
> > 
> > Document Repository: 
> > https://www.symantec.com/about/profile/policies/repository.jsp 
> > CP:
> > https://www.symantec.com/content/en/us/about/media/repository/stn-cp.pdf
> > CPS:
> https://www.symantec.com/content/en/us/about/media/repository/stn-cps.pdf
> > 
> > * CA Hierarchy: This root signs internally-operated SubCAs which
> > issue OV and EV SSL certificates, as well as Code Signing
> > certificates. S/MIME certs may also be issued in this CA hierarchy.
> 
> "Symantec AATL ECC Intermediate CA" is an unconstrained subCA
> (https://crt.sh/?caid=13519) of this
> root, albeit one with a certificate policy OID that should prohibit it
> from receiving EV treatment:
> - Why was this subCA not included in the disclosure attached to
> https://bugzilla.mozilla.org/show_bug.cgi?id=1019864 ?
> - Where and since when was this subCA disclosed in compliance with
> Mozilla's policies?
> - What CP/CPSes apply to this subCA?
> - Presumably this subCA is not meant to be used for TLS server
> certificates, so why is it not technically constrained from doing so?

Symantec AATL ECC Intermediate CA was never intended for issuing SSL/TLS 
certificates. It has never been used and will not be used in the future for 
SSL/TLS. As such, it hasn't been disclosed to date. We are planning to revoke 
the Symantec AATL ECC Intermediate CA and provide it along with the "Revoked" 
list of ICAs to Mozilla in the coming month.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Request to enable EV for VeriSign Class 3 G4 ECC root

[Rick Andrews]

On Thursday, April 21, 2016 at 9:15:43 AM UTC-7, Rick Andrews wrote:
> On Thursday, April 21, 2016 at 3:35:55 AM UTC-7, Ryan Sleevi wrote:
> > On Wednesday, April 20, 2016 at 5:53:28 PM UTC-7, Matt Palmer wrote:
> > > It seems fairly dysfunctional if a single member of the CA/B Forum can
> > > prevent a ballot from going ahead.
> > 
> > To be clear: That is not the same as what I said. No single member can 
> > prevent a ballot going forward - but it can be enough to discourage someone 
> > from proposing/progressing on a ballot due to not feeling strongly enough.
> > 
> > You can see an original proposal raised on 
> > https://cabforum.org/pipermail/public/2016-March/006933.html (which I 
> > referred to earlier). There was interested in proposing a ballot, but that 
> > interest waned with Symantec's objections.
> 
> I wouldn't say I had objections; I merely pointed out that the BRs, as 
> written, prohibit a type of wildcard that Microsoft officially allows in TLS 
> certificates (https://support.microsoft.com/en-us/kb/258858), specifically, 
> w*.example.com and ww*.example.com Ideally, CAs and/or Microsoft would have 
> noticed that long ago and brought it up to be resolved before it was encoded 
> in the BRs. So I admit that we were negligent in not raising the issue 
> sooner, but I won't take full blame for it, because other CAs also issued 
> such certificates and Microsoft could have disclosed the conflict. Microsoft 
> has now expressed their opinion that they need to allow them 
> (https://cabforum.org/pipermail/public/2016-April/007335.html).

Apologies; I mixed up two discussions. Microsoft hasn't yet expressed their 
opinion in favor of this. Please ignore that last link.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Request to enable EV for VeriSign Class 3 G4 ECC root

[Rick Andrews]

On Thursday, April 21, 2016 at 3:35:55 AM UTC-7, Ryan Sleevi wrote:
> On Wednesday, April 20, 2016 at 5:53:28 PM UTC-7, Matt Palmer wrote:
> > It seems fairly dysfunctional if a single member of the CA/B Forum can
> > prevent a ballot from going ahead.
> 
> To be clear: That is not the same as what I said. No single member can 
> prevent a ballot going forward - but it can be enough to discourage someone 
> from proposing/progressing on a ballot due to not feeling strongly enough.
> 
> You can see an original proposal raised on 
> https://cabforum.org/pipermail/public/2016-March/006933.html (which I 
> referred to earlier). There was interested in proposing a ballot, but that 
> interest waned with Symantec's objections.

I wouldn't say I had objections; I merely pointed out that the BRs, as written, 
prohibit a type of wildcard that Microsoft officially allows in TLS 
certificates (https://support.microsoft.com/en-us/kb/258858), specifically, 
w*.example.com and ww*.example.com Ideally, CAs and/or Microsoft would have 
noticed that long ago and brought it up to be resolved before it was encoded in 
the BRs. So I admit that we were negligent in not raising the issue sooner, but 
I won't take full blame for it, because other CAs also issued such certificates 
and Microsoft could have disclosed the conflict. Microsoft has now expressed 
their opinion that they need to allow them 
(https://cabforum.org/pipermail/public/2016-April/007335.html).

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

Re: March 2016 CA Communication

[Rick Andrews]

On Wednesday, April 13, 2016 at 8:33:33 AM UTC-7, Kathleen Wilson wrote:
> On Tuesday, April 12, 2016 at 12:29:16 PM UTC-7, Rick Andrews wrote:
> > On Tuesday, April 12, 2016 at 11:00:11 AM UTC-7, Kathleen Wilson wrote:
> > > It was pointed out to me that it was not clear that the dates I am asking 
> > > for in ACTION #1a and ACTION #1b are regarding issuance of end-entity 
> > > SHA-1 SSL certs. So, I added "(end-entity)" to both, as follows.
> > > 
> > > "ACTION #1a: ... Please enter the last date that a SHA-1 based TLS/SSL 
> > > (end-entity) certificate was issued that chained up to your root 
> > > certificates included in Mozilla's program. ..."
> > > 
> > > "ACTION #1b: Enter the date when all of the SHA-1 based TLS/SSL 
> > > (end-entity) certificates that chain up to your root certificates 
> > > included in Mozilla's CA Certificate Program will either expire or be 
> > > revoked. ..."
> > > 
> > > Hopefully that makes it a bit more clear.
> > > 
> > > Kathleen
> > 
> > Kathleen, since there's only one box, we'll give you one date for all roots?
> 
> 
> 
> Yes, but please clarify as appropriate in the "ACTION #1c TEXT INPUT". For 
> instance, I suspect that Symantec may want to specify different dates for 
> most of their roots.
> 
> Also, please note that I've added a clarification about the dates throughout 
> the survey: "(use format MM/DD/)"
> 
> Thanks,
> Kathleen

Sorry, I'm more confused. You'd like us to use "ACTION #1c TEXT INPUT" to 
provide clarification on "ACTION #1b"?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: March 2016 CA Communication

[Rick Andrews]

On Tuesday, April 12, 2016 at 11:00:11 AM UTC-7, Kathleen Wilson wrote:
> It was pointed out to me that it was not clear that the dates I am asking for 
> in ACTION #1a and ACTION #1b are regarding issuance of end-entity SHA-1 SSL 
> certs. So, I added "(end-entity)" to both, as follows.
> 
> "ACTION #1a: ... Please enter the last date that a SHA-1 based TLS/SSL 
> (end-entity) certificate was issued that chained up to your root certificates 
> included in Mozilla's program. ..."
> 
> "ACTION #1b: Enter the date when all of the SHA-1 based TLS/SSL (end-entity) 
> certificates that chain up to your root certificates included in Mozilla's CA 
> Certificate Program will either expire or be revoked. ..."
> 
> Hopefully that makes it a bit more clear.
> 
> Kathleen

Kathleen, since there's only one box, we'll give you one date for all roots?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: OCSP Responders Are An Attack Vector For SHA-1 Collisions

[Rick Andrews]

> I would note that we could also combine these responses.  For example, we
> might require that CAs retire SHA-1 for OCSP with a long-ish horizon, but
> require them to use constrained OCSP certs basically ASAP.
> 
> Of course, if we could just turn off SHA-1 for OCSP, that would be
> fantastic.  Do any CAs on the list know of blockers on making this switch
> basically now?  E.g., are there client stacks that support SHA-2 for
> verification, but not for OCSP?  (Firefox is obviously fine for both.)
> 
> --Richard

I know of one blocker: Microsoft. Their TechNet article at aka.ms/sha1 says 
that CAs are allowed to use SHA-1 and SHA-2 for OCSP signing certs and OCSP 
responses, to allow continued support for XP SP1 and 2, and Server 2003. Using 
SHA-2 only for OCSP signing certs and OCSP responses will break those platforms.

The TechNet article is about Authenticode code signing and timestamping, but I 
think most CAs use the same roots (but different intermediates) to issue TLS 
and Code Signing certs. The current discussion in the CABF public list about 
what's in scope and what's not in scope is relevant here. If the BRs are scoped 
to include everything signed under certain roots, that may pull in code signing 
certs, timestamping certs, and CRLs and OCSP responses for code signing certs.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: More SHA-1 certs

[Rick Andrews]

On Monday, February 1, 2016 at 10:34:18 AM UTC-8, Rick Andrews wrote:
> On Sunday, January 31, 2016 at 9:47:53 AM UTC-8, Peter Bowen wrote:
> > These are all in the last week
> > 
> > Sub-CA under SHECA (which has applied to be in the Mozilla program)
> > https://crt.sh/?id=12367776&opt=cablint
> > 
> > Sub-CA under DigiCert
> > https://crt.sh/?id=12460684&opt=cablint
> > 
> > Sub-CA under Symantec
> > https://crt.sh/?id=12456194&opt=cablint
> > https://crt.sh/?id=12434313&opt=cablint
> 
> The Sub-CA under Symantec is managed by one of our customers. We've reached 
> out to them and we're investigating. More detail to follow.

We verified that the customer who managed that SubCA has revoked both 
certificates.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: More SHA-1 certs

[Rick Andrews]

On Sunday, January 31, 2016 at 9:47:53 AM UTC-8, Peter Bowen wrote:
> These are all in the last week
> 
> Sub-CA under SHECA (which has applied to be in the Mozilla program)
> https://crt.sh/?id=12367776&opt=cablint
> 
> Sub-CA under DigiCert
> https://crt.sh/?id=12460684&opt=cablint
> 
> Sub-CA under Symantec
> https://crt.sh/?id=12456194&opt=cablint
> https://crt.sh/?id=12434313&opt=cablint

The Sub-CA under Symantec is managed by one of our customers. We've reached out 
to them and we're investigating. More detail to follow.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: [FORGED] Name issues in public certificates

[Rick Andrews]

On Wednesday, November 18, 2015 at 5:43:57 PM UTC-8, Brian Smith wrote:
> Peter Bowen wrote:
> 
> > 2) For commonName attributes in subject DNs, clarify that they can only
> > contain:
> >
> - IPv4 address in dotted-decimal notation (specified as IPv4address
> > from section 3.2.2 of RFC 3986)
> > - IPv6 address in coloned-hexadecimal notation (specified as
> > IPv6address from section 3.2.2 of RFC 3986)
> > - Fully Qualified Domain Name or Wildcard Domain Name in the
> > "preferred name syntax" (specified by Section 3.5 of RFC1034 and as
> > modified by Section 2.1 of RFC1123)
> > - Fully Qualified Domain Name or Wildcard Domain Name in containing
> > u-labels (as specified in RFC 5890)
> 
> 
> > 3) Forbid commonName attributes in subject DNs from containing a Fully
> > Qualified Domain Name or Wildcard Domain Name that contains both one
> > or more u-labels and one or more a-labels (as specified in RFC 5890).
> >
> 
> I don't think these rules are necessary, because CAs are already required
> to encode all this information in the SAN, and if there is a SAN with a
> dNSName and/or iPAddress the browser is required to ignore the subject CNs.
> That is, if the certificate a SAN with a dNSName and/or iPAddress entry,
> then it doesn't really matter how the CN is encoded as long as it isn't
> misleading.
> 
> 
> > If the Forum decides to allow an exception to RFC 5280 to permit IP
> > address strings in dNSName general names, then require the same format
> > as allowed for common names.
> >
> 
> That should not be done. As I mentioned in my other reply in this thread,
> Ryan Sleevi already described a workaround that seems to work very well:
> Encode the IP addresses in the SubjectAltName as iPAddress entries, and
> then also encode them as (normalized) ASCII dotted/colon-separated text in
> the subject CN, using more than one subject CN if there is more than one IP
> address.
> 
> By the way, I believe that mozilla::pkix will reject all the invalid names
> that you found, except it accepts "_" in dNSNames. If you found some names
> that mozilla::pkix accepts that you think are invalid, I would love to hear
> about that.
> 
> Cheers,
> Brian
> -- 
> https://briansmith.org/

Multiple common names were flagged as an attack vector in Kaminsky's PKI Layer 
Cake paper at 
https://securewww.esat.kuleuven.be/cosic/publications/article-1432.pdf. 
Specifically, the paper said that Firefox respected only the last CN in the DN. 
We need to be sure that all browsers (mobile too) respect all CNs. And this 
solution may be risky too because CN is being deprecated.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Update to phasing out SHA-1 Certs

[Rick Andrews]

> - We are re-evaluating when we should start rejecting all SHA-1 SSL 
> certificates (regardless of when they were issued).  As we said before, 
> the current plan is to make this change on January 1, 2017.  However, in 
> light of recent attacks on SHA-1, we are also considering the 
> feasibility of having a cut-off date as early as July 1, 2016.

I think that pulling in this date will create chaos for some large enterprises 
who are already scrambling to phase out SHA-1 by the end of 2016. They had been 
counting on using all of 2016 to complete their migration. It wouldn't just be 
an inconvenience - it would make an already-difficult situation nearly 
impossible.

And I'll point out that Microsoft is considering the same thing but with a 
different date - June 1, 2016. Would you at least consider collaborating with 
other browser vendors to agree on the same date?


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

Re: Symantec Test Cert Misissuance Incident

[Rick Andrews]

We have just posted an update to our test certificate incident report at 
https://www-secure.symantec.com/connect/sites/default/files/Test_Certificates_Incident_Final_Report_20151029.pdf.
 With regard to the questions on the certificates identified in this 
discussion, we have reviewed these and we see no anomalies with regard to 
logging:   
 
[3] https://crt.sh/?id=9314698
 > pre-cert logged as part of our internal testing
 
[4] https://crt.sh/?q=evgabrieltest%2Ebbtest%2Ecom&iCAID=1454
 > cert logged as part of our internal testing
 
[5] https://crt.sh/?id=5934504
 > this was a properly issued certificate
 
[6] https://crt.sh/?id=9324337
 > pre-cert logged as part of internal testing
 
[7] https://crt.sh/?id=10162388
 > this was a properly issued certificate
 
[8] https://crt.sh/?id=10162533
 > this was a properly issued certificate
 
[9] https://crt.sh/?id=10162537
 > this was a properly issued certificate

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

Re: Symantec Test Cert Misissuance Incident

[Rick Andrews]

We are working hard on providing an update and responding to open questions.  
We will provide further information as soon as its available.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec Test Cert Misissuance Incident

[Rick Andrews]

Rob, Gerv - Thanks for your input. We are collating all feedback and are 
planning to publish another update soon.


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

Re: Symantec Test Cert Misissuance Incident

[Rick Andrews]

On Tuesday, October 13, 2015 at 5:16:10 PM UTC-7, Charles Reiss wrote:
> On 10/13/15 18:46, Kathleen Wilson wrote:
> > In September of this year, the CA Symantec revealed[0] that they had 
> > mis-issued
> > a number of certificates for domains that they did not own or control, for
> > testing purposes. After an "exhaustive review", they issued a Final 
> > Report[1]
> > which documented 23 such certificates.
> > 
> > Yesterday, Symantec updated their final report[2] to indicate that the 
> > problem
> > was more extensive than they had at first believed. They said, in part:
> > 
> > "While our current investigation is ongoing, so far we have found 164 
> > additional
> > instances where test certificates were inappropriately issued. All of these 
> > test
> > certificates have been revoked. These test certificates were spread over 76
> > domain owners whom we are in the process of contacting."
> > 
> > In addition, they have identified 3073 test certificates which were issued 
> > for
> > domains which were (at the time) unregistered, since the practice was banned
> > (which happened at different times for EV certs and other certs). They have
> > provided two lists[3][4], one of the 164 certs and another of the 3073.
> 
> This list of test certs for owned domains contains an entry for
> a cert with serial number 0xc222a issued by RapidSSL CA, valid from 05/18/2013
> 22:27:16 GMT to 06/20/2015 13:57:13 GMT (last entry of the owned domains PDF).
> This appears to be this certificate https://crt.sh/?id=1990400 which has:
> 
> X509v3 Subject Alternative Name:
> DNS:*.icns.com.au
> DNS:icns.com.au
> 
> As of this writing, there appears to be a functional server at that
> www.icns.com.au which presents that (expired and revoked) cert and to which
> openssl s_client can successfully connect.
> 
> Is this entry an error?
> 
> In Symantec's initial incident report, they indicated 'the private keys
> associated with the test certificates were all destroyed as part of the 
> testing
> tool that was used to enroll for the test certificates'. Are they still making
> this claim for the test certificates found subsequently?
> 
> - Charles
> 
> 
> > 
> > They are continuing to search, and will update the Final Report again when 
> > their
> > investigations are complete.
> > 
> > The 164 certificates will be added to Mozilla's OneCRL system[5]. (We do not
> > think the risk from the 3073 is significant enough to warrant this step.)
> > 
> > This message has been posted to begin a discussion in the Mozilla community 
> > as
> > to what additional action, if any, Mozilla should take in response to these 
> > events.
> > 
> > Kathleen, Gerv and Richard
> > 
> > [0]http://www.symantec.com/connect/blogs/tough-day-leaders
> > [1]https://www-secure.symantec.com/connect/sites/default/files/Test_Certificates_Incident_Final_Report.pdf
> > 
> > [2]https://www-secure.symantec.com/connect/sites/default/files/Test_Certificates_Incident_Final_Report_10_12_2015.pdf
> > 
> > [3]https://www-secure.symantec.com/connect/sites/default/files/TestCertificateIncidentReportOwnedDomains.pdf
> > 
> > [4]https://www-secure.symantec.com/connect/sites/default/files/TestCertificateIncidentReportUnregistered.pdf
> > 
> > [5]https://bugzilla.mozilla.org/show_bug.cgi?id=1214321

Thanks for your post.  
 
Symantec does not own the icns.com.au domain, but we had authorization by the 
domain owner to use the domain for testing. This icns.com.au test certificate 
was properly authenticated, and was installed and used externally by the domain 
owner.
 
We included this certificate on our list of certificates associated with 
domains that we do not own, which is accurate. However, because we had 
authorization from the domain owner to issue the certificate, this certificate 
did not need to be on this list but was included for completeness.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy Update Proposal: Remove Code Signing Trust Bit

[Rick Andrews]

Kathleen, I'll admit that I'm discouraged from contributing. Can you tell us 
what if anything is being done to keep the discourse at a more respectable 
level?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Automated the Included CA List

[Rick Andrews]

On Tuesday, August 4, 2015 at 2:05:47 PM UTC-7, Kathleen Wilson wrote:
> On 8/4/15 1:26 PM, Peter Bowen wrote:
> > On Tue, Aug 4, 2015 at 1:17 PM, Kathleen Wilson wrote:
> >> The Included CAs list is now being automatically generated directly from
> >> Salesforce:
> >>
> >> https://mozillacaprogram.secure.force.com/CA/IncludedCACertificateReport
> >>
> >> If everyone is OK with this new report, I will change
> >> https://wiki.mozilla.org/CA:IncludedCAs to point to this new report, and
> >> will remove the Google spreadsheet that is currently included in the page.
> >> (and I will no longer update the Google spreadsheet)
> >
> > Is there a way to download the Salesforce data in CSV, xlsx, ods, or
> > some other non-HTML format.
> >
> > Thanks,
> > Peter
> >
> 
> We have it on our to-do list: Create a way to download a CSV version of 
> the new auto-generated Included CAs report.
> We were planning to tackle that in September. Do you need it earlier?
> 
> Also, I should mention that there is a new column in the report: 
> Geographic Focus.
> I've been filling that data in as I update CA records in Salesforce 
> (when I remember). CAs, please send me email if there is particular data 
> in this report that should be updated.
> 
> Kathleen

In the meantime, it's possible to select all the cells and copy and paste them 
into Excel.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CA scope transparency (was Re: Name-constraining government CAs, or not)

[Rick Andrews]

I don't understand. The domain owner/admin is not a third party. 

-Rick

> On Jun 10, 2015, at 4:01 AM, Hubert Kario  wrote:
> 
>> On Tuesday 09 June 2015 11:57:40 Rick Andrews wrote:
>>> On Tuesday, June 9, 2015 at 3:05:30 AM UTC-7, Hubert Kario wrote:
>>> True, OTOH, if a third party says that there was a misissuance, that means
>>> there was one.
>> 
>> I disagree. Only the domain owner knows for sure what is a misissuance, and
>> what isn't. It seems likely that I might turn over all known certs for my
>> domain to the third party, but they might find another one, and I might say
>> "oh, yeah, I forgot about that one". So a third party can only report to
>> the domain owner, but cannot know if the cert is legitimate.
> 
> the implied situation was that the tool is run by the domain owner/admin
> 
> -- 
> Regards,
> Hubert Kario
> Quality Engineer, QE BaseOS Security team
> Web: www.cz.redhat.com
> Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CA scope transparency (was Re: Name-constraining government CAs, or not)

[Rick Andrews]

On Tuesday, June 9, 2015 at 12:23:57 PM UTC-7, Kurt Roeckx wrote:
> On Tue, Jun 09, 2015 at 12:00:23PM -0700, Rick Andrews wrote:
> > On Tuesday, June 9, 2015 at 7:45:05 AM UTC-7, Kurt Roeckx wrote:
> > > On 2015-06-09 15:26, Peter Kurrasch wrote:
> > > > 3) How frequently might such tools run? Or to put it differently, how 
> > > > much time do I probably have between when I issue a gmail cert and when 
> > > > someone figures it out (and of course how much longer before my 
> > > > illegitimate cert is no longer valid)? I need only 24 hours to do all 
> > > > the damage I want, but in a pinch I'll make do with 8.
> > > 
> > > CT allows to store precertificate.  That is, the CA says it intents to 
> > > issue a certificate.  Should we mandate the use of precertificates and a 
> > > minimum time between the precertificate and the real certificate?
> > > 
> > > 
> > > Kurt
> > 
> > Absolutely not. If a CA is unable to get the required minimum number of 
> > SCTs, it will likely not issue the cert (sure, it may retry, but it's 
> > possible that retries fail too). Logging must be seen as intent, but not a 
> > guarantee of issuance.
> 
> I'm not sure I understand what you're saying.
> 
> First, I don't understand your thing about a minimum number of
> STCs.  I wasn't talking about a minimum amount of SCTs between
> them.  The signed certificate timestamp (SCT) has, as the name
> implies, a timestamp.  I'm saying that we could require a minimum
> time between the timestamp from the precertificate and the
> certificate.
> 
> I also didn't say anything about guaranteeing issuance.   The
> whole point is that we could detect that a wrong one could be
> issued and that we can avoid the issuance.
> 
> 
> Kurt

I should have been more clear. I'm talking about Google's current requirement 
for CAs to adhere to RFC6962 for all EV certs. Google's policy specifies 
minimum numbers of SCTs based on the validity period of the cert. So CAs 
currently have to gather 3 SCTs for a 27-month EV cert.

If CAs issue an EV cert with fewer than the minimum number of SCTs mandated by 
Google, Chrome will not display the EV treatment for that cert. So CAs are 
incentivized to add the required minimum number of SCTs to each EV cert, and 
not issue any EV cert with fewer than the minimum number of SCTs if the 
customer expects to see the EV treatment for their site.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CA scope transparency (was Re: Name-constraining government CAs, or not)

[Rick Andrews]

On Tuesday, June 9, 2015 at 7:45:05 AM UTC-7, Kurt Roeckx wrote:
> On 2015-06-09 15:26, Peter Kurrasch wrote:
> > 3) How frequently might such tools run? Or to put it differently, how much 
> > time do I probably have between when I issue a gmail cert and when someone 
> > figures it out (and of course how much longer before my illegitimate cert 
> > is no longer valid)? I need only 24 hours to do all the damage I want, but 
> > in a pinch I'll make do with 8.
> 
> CT allows to store precertificate.  That is, the CA says it intents to 
> issue a certificate.  Should we mandate the use of precertificates and a 
> minimum time between the precertificate and the real certificate?
> 
> 
> Kurt

Absolutely not. If a CA is unable to get the required minimum number of SCTs, 
it will likely not issue the cert (sure, it may retry, but it's possible that 
retries fail too). Logging must be seen as intent, but not a guarantee of 
issuance.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CA scope transparency (was Re: Name-constraining government CAs, or not)

[Rick Andrews]

On Tuesday, June 9, 2015 at 3:05:30 AM UTC-7, Hubert Kario wrote:
> True, OTOH, if a third party says that there was a misissuance, that means 
> there was one.

I disagree. Only the domain owner knows for sure what is a misissuance, and 
what isn't. It seems likely that I might turn over all known certs for my 
domain to the third party, but they might find another one, and I might say 
"oh, yeah, I forgot about that one". So a third party can only report to the 
domain owner, but cannot know if the cert is legitimate.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Security Blog about SHA-1

[Rick Andrews]

Kathleen, why is mozilla.org still using a SHA-1 cert? 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Question about disclosing subCA certs

[Rick Andrews]

On Thursday, May 22, 2014 11:22:17 AM UTC-7, Kathleen Wilson wrote:
> On 5/21/14, 5:02 PM, Kathleen Wilson wrote:
> 
> > On 5/21/14, 2:54 PM, Ryan Sleevi wrote:
> 
> >> On Wed, May 21, 2014 12:12 pm, Kathleen Wilson wrote:
> 
> >>>   On 5/20/14, 9:53 AM, Rick Andrews wrote:
> 
> >>>> Ryan, they're not, but the root is not trusted for SSL (via meta-data).
> 
> >>>> AFAIK, Firefox won't trust any SSL cert chaining to it. Will Chrome?
> 
> >>>>
> 
> >>>> -Rick
> 
> >>>>
> 
> >>>> ---
> 
> >>>> Rick,
> 
> >>>>
> 
> >>>> Are these subordinate CAs technically constrained, according to the
> 
> >>>> terms of Mozilla's CA Certificate Policy? It sounds like they aren't.
> 
> >>>>
> 
> >>>> That means that they are technically capable of issuing SSL
> 
> >>>> certificates, and that such certificates MAY be accepted as valid SSL
> 
> >>>> certificates within Mozilla products. If so, it does seem that they
> 
> >>>> should be disclosed.
> 
> >>>>
> 
> >>>
> 
> >>>
> 
> >>>   Rick, what did you mean by "but the root is not trusted for SSL (via
> 
> >>>   meta-data)"?
> 
> >>>
> 
> >>>   If a root does not have the websites trust bit enabled, then I
> 
> >>> think it
> 
> >>>   would be OK to grant an exception to items #9 and #10 of the policy.
> 
> >>>
> 
> >>>   For instance, there are several VeriSign roots that are included in
> 
> >>>   Mozilla's CA program that are only enabled for Email and/or Code
> 
> >>> Signing.
> 
> >>>
> 
> >>>   I really don't want to be tracking all of the subCAs for those roots.
> 
> >>>
> 
> >>>   Does anyone have issues about granting an exception to items #9 and
> 
> >>> #10
> 
> >>>   of the policy for roots that don't have the websites (SSL) trust
> 
> >>> bit set?
> 
> >>>
> 
> >>>   Kathleen
> 
> >>>
> 
> >>>   ___
> 
> 
> >>>
> 
> >>
> 
> >> +1
> 
> >>
> 
> >> If a certificate transitively chains to an anchor that is not trusted for
> 
> >> SSL, that certainly seems to meet the spirit of technically constrained -
> 
> >> as it's not capable of issuing SSL/TLS certificates that will be
> 
> >> recognized by Firefox and related products.
> 
> >>
> 
> >> The only caveat would be that enabling the trust bits (if ever requested)
> 
> >> would seem like it should trigger the disclosure.
> 
> >>
> 
> >
> 
> >
> 
> > How about if I add the following to
> 
> > https://wiki.mozilla.org/CA:CertificatePolicyV2.1#Frequently_Asked_Questions
> 
> >
> 
> 
> 
> 
> 
> Based on the discussion so far, here's a new draft.
> 
> 
> 
> https://wiki.mozilla.org/CA:CertificatePolicyV2.1#Frequently_Asked_Questions 
> 
> 
> 
> -- 
> 
> 4. If an included trust anchor does not have the websites (SSL/TLS) 
> 
> trust bit enabled, can it be exempt from items #9 and #10 of Mozilla's 
> 
> CA Certificate Inclusion Policy?
> 
>- A subordinate CA certificate that transitively chains to a trust 
> 
> anchor that *only* has the email trust bit enabled may be considered 
> 
> technically constrained as per #9 of Mozilla�s CA Certificate Inclusion 
> 
> Policy even when it does not have the EKU extension.
> 
>- A subordinate CA certificate that transitively chains to an 
> 
> included trust anchor that has the Code Signing and/or websites 
> 
> (SSL/TLS) trust bit(s) enabled must either include the EKU extension and 
> 
> constraints as per section #9 of Mozilla�s CA Certificate Inclusion 
> 
> Policy, or must be audited and publicly disclosed as per section #10 of 
> 
> Mozilla�s CA Certificate Inclusion Policy.
> 
> --
> 
> 
> 
> 
> 
> Thanks,
> 
> Kathleen

Kathleen, why does the second bullet point lump together Code Signing and 
WebSites bits? We have a root that doesn't have WebSites, but has Code Signing 
and Email trust bits set.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Question about disclosing subCA certs

[Rick Andrews]

Ryan, they're not, but the root is not trusted for SSL (via meta-data). AFAIK, 
Firefox won't trust any SSL cert chaining to it. Will Chrome?

-Rick

---
Rick,

Are these subordinate CAs technically constrained, according to the terms of 
Mozilla's CA Certificate Policy? It sounds like they aren't.

That means that they are technically capable of issuing SSL certificates, and 
that such certificates MAY be accepted as valid SSL certificates within Mozilla 
products. If so, it does seem that they should be disclosed.

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

Re: Question about disclosing subCA certs

[Rick Andrews]

On Tuesday, May 20, 2014 11:33:17 AM UTC-7, Kathleen Wilson wrote:
> On 5/20/14, 11:08 AM, Kathleen Wilson wrote:
> 
> > On 5/19/14, 9:40 AM, Rick Andrews wrote:
> 
> >  > Kathleen, that means we'll be disclosing a number of intermediates
> 
> >  > used to sign certificates that are not used for SSL, Code Signing or
> 
> >  > Mail (the three trust bits that Firefox lets me view/edit). For
> 
> >  > example, we issue a lot of client auth certs from our public roots.
> 
> >  >
> 
> >  > Based on your previous comments, I assume you expect those to be
> 
> >  > disclosed too, even though Mozilla products likely will never
> 
> >  > encounter them, or work with them if encountered. Please confirm.
> 
> >
> 
> >
> 
> > I'm only interested in the intermediate certs that can be used to issue
> 
> > certs for SSL, Code Signing, or Mail (the three trust bits that are set
> 
> > in NSS).
> 
> >
> 
> > Kathleen
> 
> >
> 
> 
> 
> 
> 
> To be clear, I agree with what Ryan said:
> 
> "Are these subordinate CAs technically constrained, according to the 
> 
> terms of Mozilla's CA Certificate Policy? It sounds like they aren't.
> 
> That means that they are technically capable of issuing SSL 
> 
> certificates, and that such certificates MAY be accepted as valid SSL 
> 
> certificates within Mozilla products. If so, it does seem that they 
> 
> should be disclosed."
> 
> 
> 
> 
> 
> My preference is that you use the EKU as described in section 9 of 
> 
> Mozilla's CA Certificate Inclusion policy, so that you wouldn't need to 
> 
> disclose them. So, for client auth, the intermediate cert would have an 
> 
> EKU extension that does not include id-kp-serverAuth. Then it wouldn't 
> 
> need to be disclosed.
> 
> 
> 
> 
> 
> Kathleen

Kathleen, sorry, it's still not clear. Two posts back, you said you're 
"interested in the intermediate certs that can be used to issue certs for SSL, 
Code Signing, or Mail". In your last post, it seems you're only interested in 
intermediates that can issue SSL certs. Please clarify.

And if the intermediate does not have an EKU (and therefore could be used to 
issue SSL certs even if we didn't intend it to) but chains to a root that does 
not have the SSL meta-data bit set, must it be disclosed?

Finally, if I read Section 9 of the Inclusion Policy right, having an EKU of 
id-kp-serverAuth is not enough; the intermediate must also include name 
constraints to avoid needing to be disclosed, right?

I'm not trying to be difficult, but we may have to disclose a *lot* of 
intermediates depending on your clarification.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Question about disclosing subCA certs

[Rick Andrews]

Kathleen, that means we'll be disclosing a number of intermediates used to sign 
certificates that are not used for SSL, Code Signing or Mail (the three trust 
bits that Firefox lets me view/edit). For example, we issue a lot of client 
auth certs from our public roots.

Based on your previous comments, I assume you expect those to be disclosed too, 
even though Mozilla products likely will never encounter them, or work with 
them if encountered. Please confirm.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: No CRL UI as of Firefox 24

[Rick Andrews]

Since support for CRLs has been removed from Firefox, why does Mozilla's root 
policy 
(http://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/maintenance/)
 require CAs to maintain and publish CRLs?

Is it because Mozilla intends to build CRLs sets in the future?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Request to blacklist a pb certificate not complying to BR

[Rick Andrews]

Kai, I can give you a little history to explain our actions.

Although it's clear today that there's (at least) two classes of users for SSL 
certificates, browsers and non-browsers (devices like POS terminals, TVs, 
etc.), that's not always been the case. For years, we (and I'm sure other CAs) 
have issued certs to both classes from the same roots and intermediates.

If we had known that in 2012, one class (browsers) would begin enforcing strict 
rules on certificate issuance, we probably would have created separate roots 
and intermediates for the other class(es) to keep them separate. But we didn't 
do that.

Now we find ourselves in a situation where customers have embedded our roots in 
their non-browser devices. These devices don't auto-update like browsers, so 
they cannot now move to new roots; in some cases, they can't even move to new 
intermediates; in many cases they can't handle 2048-bit keys or SHA-2). They 
come to us and ask for a renewal of their cert, and it usually needs to be the 
same as what they had been using. 

We tell them we can't give them what they want, because of Baseline 
Requirements. Many of them ask why browser vendors have the ability to tell 
them what kind of cert they can or can't have. It's always a difficult 
conversation.

So our position has been that the requests from these non-browser customers are 
legitimate; the situation evolved and was not planned to be this way. We work 
with each customer to try to find a solution that works for them and is 
BR-compliant. But if all else fails, we try to find a solution that works for 
them and does not harm the browser-user community. That's what happened in this 
case.
As one of the founding members of the CA/Browser Forum, we take the Baseline 
Requirements very seriously and we certainly don't ignore them.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Exceptions to 1024-bit cert revocation requirement

[Rick Andrews]

Kathleen, I think that even if you agree to extend the deadline, it's a moot 
point unless Microsoft and other browsers follow suit. Unless there are web 
site owners that only support Firefox.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla not compliant with RFC 5280

[Rick Andrews]

Brian, Kathleen,

The idea of removing Firefox's ability to fetch an OCSP response from a CA 
seems to me to be a significant policy shift. But it's being discussed here in 
this thread (with an unrelated Subject line) which many may miss. Why not add 
it to https://wiki.mozilla.org/CA:ImprovingRevocation so that everyone's aware 
of what you're considering?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: De we need EV OIDs in the Included Certs spreadsheet?

[Rick Andrews]

I noticed that Wikipedia lists EV OIDs 
(http://en.wikipedia.org/wiki/Extended_validation).

If any are missing, it's easy to update that page.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: When should CAs notify Mozilla of intermediate cert revocations?

[Rick Andrews]

I'd like to explore how "Notification shall be made in an authenticated and 
trusted manner". Kathleen's wiki page says to send email to 
secur...@mozilla.org or file a bug. How would Mozilla determine that the 
request was legitimate?

I suspect that Mozilla already maintains a short list of contacts for each CA. 
Only they (or some selected subset of them) should be able to report a 
revocation. Mozilla should have some other means of authenticating them. Maybe 
you have a cell phone number for each, which you will call to validate the 
request.

>From the CA's perspective, I'd like this process to work the same for Apple,  
>Microsoft and any other trusted root operator. I urge Mozilla to work with 
>these other companies to come up with a unified standard.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Netcraft blog, violations of CABF Baseline Requirements, any consequences?

[Rick Andrews]

Brian, you seem to be saying that revocation checking adds value only when 
there's an attacker involved. If that's your point, I disagree. There are cases 
in which a CA revokes a certificate because the site has misrepresented itself, 
and revocation serves as a warning to the client.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Netcraft blog, violations of CABF Baseline Requirements, any consequences?

[Rick Andrews]

> Yes, surely only someone insidious and evil and who hates Freedom would
> 
> ever support such an security-hostile idea as a 1-4KB OCSP response,
> 
> rather than a 50MB CRL. It's likely that the Legion of Cryptographic Doom
> 
> have compromised OCSP, likely using the World Bank to infiltrate the IETF
> 
> with members of the Secret Illuminati (which even the regular Illuminati
> 
> don't know about), and only CRLs can save us from the impending saucer
> 
> people who will break our crypto and control our minds with houseplants.

Please keep it civil, Ryan. I'm afraid you've stooped to the same level as the 
person you were criticizing.
 
> 
> Please keep it civil, Michael, and please provide technical discussions,
> 
> rather than emotional pleas or accusations.
> 
> 
> 
> OCSP and CRLs both represent ways to obtain revocation information. Thus,
> 
> for EV, it's should "always" be possible to obtain fresh information.
> 
> 
> 
> CRLs and OCSP offer no security advantage unless enabled for 'hard fail',
> 
> which cannot be enabled by default, and which few users (if any) have ever
> 
> enabled. The security gains absent hard fail are illusions (... not
> 
> tricks), and so Firefox, which was not implemented hard-fail by default
> 
> and will not implement hard fail by default, it's a perfectly practical
> 
> decision.

I agree with Jeremy that there are security benefits to revocation checking, 
even without hard-fail, and that they are not illusions. If a CA can serve an 
OCSP response to a browser before the browser gives up, the user may be alerted 
to a revoked certificate and may then choose to avoid the web site. A number of 
CAs have been actively working to improve the performance of their CA 
infrastructures, and have made significant improvements.

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

Seeking detail on certificate chain handling

[Rick Andrews]

Is there any detailed explanation (perhaps similar to this page: 
https://developer.mozilla.org/en-US/docs/Introduction_to_Public-Key_Cryptography)
 that describes how NSS chooses among multiple valid chains for SSL certs (for 
example, when an SSL server returns a cross certificate that could be used to 
chain up to a second root)? Thanks.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy