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 

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=cablint
> > 
> > Sub-CA under DigiCert
> > https://crt.sh/?id=12460684=cablint
> > 
> > Sub-CA under Symantec
> > https://crt.sh/?id=12456194=cablint
> > https://crt.sh/?id=12434313=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=cablint
> 
> Sub-CA under DigiCert
> https://crt.sh/?id=12460684=cablint
> 
> Sub-CA under Symantec
> https://crt.sh/?id=12456194=cablint
> https://crt.sh/?id=12434313=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 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: 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 hka...@redhat.com 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 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: 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 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: 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]

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: 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: 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: 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