Wildcard cert, no intermediate
I've encountered a wildcard end-entity certificate on a live server that chains directly to the root cert. There is no intermediate certificate and the root is in the Mozilla trust store. I assume this is a frowned upon practice that will be stopped as the BRs are adopted and such certs expire naturally. There is no reason for such certs to be reissued indefinitely, is there? Beyond this one case I'm wondering if there are any survey data or anecdotes about how common a practice this is (was?). Thanks. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Wildcard cert, no intermediate
On Wed, Aug 20, 2014 at 1:55 PM, fhw...@gmail.com wrote: I've encountered a wildcard end-entity certificate on a live server that chains directly to the root cert. There is no intermediate certificate and the root is in the Mozilla trust store. I assume this is a frowned upon practice that will be stopped as the BRs are adopted and such certs expire naturally. There is no reason for such certs to be reissued indefinitely, is there? Beyond this one case I'm wondering if there are any survey data or anecdotes about how common a practice this is (was?). It is allowed by the BRs if (as per section 12): a. The Root CA uses a 1024-bit RSA signing key that was created prior to the Effective Date; b. The Applicant’s application was deployed prior to the Effective Date; c. The Applicant’s application is in active use by the Applicant or the CA uses a documented process to establish that the Certificate’s use is required by a substantial number of Relying Parties; d. The CA follows a documented process to determine that the Applicant’s application poses no known security risks to Relying Parties; and e. The CA documents that the Applicant’s application cannot be patched or replaced without substantial economic outlay. and the Root CA Certificate has a validity period beginning on or before 31 Dec 2010 (Appendix A) ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Wildcard cert, no intermediate
The cert is allowable as long as the root is 1024, not the end entity. The end entity must be 2048 under the current Mozilla requirements. Jeremy -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org] On Behalf Of fhw...@gmail.com Sent: Wednesday, August 20, 2014 4:19 PM To: Peter Bowen Cc: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Wildcard cert, no intermediate Hmmm... I'll just assume that all the prior to Effective Date conditions are satisfied but both the end and root certs are 2048-bit. I can't speak to how actively or widely used the cert is nor how costly it would be to replace other than to say I've seen it on a half dozen different hosts. Regarding no known security risks, however, that point is a farce. The mere existence of the cert puts everyone at risk. If I can get my hands on the private key (Heartbleed, compromised admin/root account) I can start setting up bogus sites anywhere (the cloud). Add in a splash of DNS poison and hack some easy, popular targets (compromised admin accounts, SQL injection, MITM) and I'm golden! My malware distribution factory is ready for action and it will take a lot of effort to stop me. Of course first you would have to catch me. So is this cert still allowable since it's 2048-bit? Is there any requirement that might force its discontinued use upon (or prior to) its expiration date next year? Original Message From: Peter Bowen Sent: Wednesday, August 20, 2014 4:03 PM It is allowed by the BRs if (as per section 12): a. The Root CA uses a 1024-bit RSA signing key that was created prior to the Effective Date; b. The Applicant’s application was deployed prior to the Effective Date; c. The Applicant’s application is in active use by the Applicant or the CA uses a documented process to establish that the Certificate’s use is required by a substantial number of Relying Parties; d. The CA follows a documented process to determine that the Applicant’s application poses no known security risks to Relying Parties; and e. The CA documents that the Applicant’s application cannot be patched or replaced without substantial economic outlay. and the Root CA Certificate has a validity period beginning on or before 31 Dec 2010 (Appendix A) ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Wildcard cert, no intermediate
On Wed, August 20, 2014 3:18 pm, fhw...@gmail.com wrote: Hmmm... I'll just assume that all the prior to Effective Date conditions are satisfied but both the end and root certs are 2048-bit. I can't speak to how actively or widely used the cert is nor how costly it would be to replace other than to say I've seen it on a half dozen different hosts. Regarding no known security risks, however, that point is a farce. The mere existence of the cert puts everyone at risk. If I can get my hands on the private key (Heartbleed, compromised admin/root account) I can start setting up bogus sites anywhere (the cloud). Add in a splash of DNS poison and hack some easy, popular targets (compromised admin accounts, SQL injection, MITM) and I'm golden! My malware distribution factory is ready for action and it will take a lot of effort to stop me. Of course first you would have to catch me. This doesn't add any useful data to the debate, nor is it accurate. Your original complaint is about a certificate with no intermediate. This is permitted (pre-BR), and not (post-BR). Your examples of doom that would be caused by this cert apply to all wildcard certs. If you wish to complain about wildcard certs, you're certainly entitled to, but it's entirely orthogonal. So is this cert still allowable since it's 2048-bit? Is there any requirement that might force its discontinued use upon (or prior to) its expiration date next year? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Audits of CA conformance to the BRs
On 8/19/14, 5:37 PM, Kathleen Wilson wrote: All, I started a new wiki page to document Mozilla's expectations regarding CA compliance with the BRs, and auditing according to the BRs. https://wiki.mozilla.org/CA:BaselineRequirements It is a very rough draft, but I would appreciate feedback on it. Thanks, Kathleen Regarding Whole-Population BR Audit of Intermediate Certs, since the BRs are for SSL certs, this should probably only apply to intermediate certs that are capable of issuing SSL certs. Regarding auditing for things in RFC 5280... There are things in RFC 5280 (such as duplicate serial numbers) that aren't stated in the BRs. So, does the CAB Forum need to add important requirements from RFC 5280 to the BRs, so they get added to the BR audit criteria? Why I ask... It is my understanding that when an auditor performs a BR audit, she will follow a BR audit criteria such as the WebTrust BR audit criteria or the ETSI TS 102 042 PTC-BR criteria. For the requirements that are explicitly defined in the BR audit criteria, the auditor will examine the technical settings and sampled certificates to check for those things. For things that are not explicitly defined in BR audit criteria, the auditor may use some less strict audit procedures such as asking CA personnel or reviewing the CP/CPS to check for those things. Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
The case for point in time readiness audits (PITRAs)
Sorry for this late response, but Peter Bowen's post below in subpart 2) is exactly correct - FF needs to accept PITRAs from new CA roots, or else you will never have any new CA roots. No customer will accept certs from a CA's new roots unless they are already in the major browsers (possibly cross-signed as well - at a price - by an established CA's older roots to get greater ubiquity). But no auditor will provide a performance audit until the CA has been in operation producing real certs (some meaningful number of certs) for some months... If Mozilla refuses to accept new roots without a performance audit, then the roots will never be accepted (because you can't get the customers without the roots being in Mozilla, and you can't get the performance audit without customers... etc.). As I recall, it took my former company AffirmTrust (now part of Trend Micro) about 20-22 months of waiting in Mozilla's queue AFTER we submitted all our root application information INCLUDING not one but (as I recall) two PITRA audits a year apart before we actually were accepted in Firefox. Of course, we could not launch any meaningful customer efforts until our roots were accepted. Once in FF, we did cross-sign and get customers, and soon after that we obtained regular and EV WebTrust performance audits for an initial audit period of less than a year and submitted to all the browsers. In fact, the readiness audits we obtained were almost more difficult than the subsequent performance audits, as the auditors demanded to see a lot of materials and demonstrations to prove how we would issue certs - technical, operational, security, etc. After that, the performance audits followed the template we already established with the auditors on how we would operate - so a PITRA is actually a good warm up for the auditor to become familiar with your (planned) systems and operations for the first performance audit. Another post suggested when flaws are found in certs that maybe the CA should be forced to change auditors; someone responded that would likely be very expensive (true). A better plan may be to require the current auditor to come up with an immediate plan for correction and compliance, and then present a mid-term partial audit following that plan... Probably more meaningful and effective. In any case, if you drop PITRAs, you may never see another new root application. Kirk R. Hall Operations Director, Trust Services Trend Micro Message: 3 Date: Wed, 13 Aug 2014 12:41:48 -0700 From: Peter Bowen pzbo...@gmail.com To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Audits of CA conformance to the BRs Message-ID: CAK6vND97+_eUemva6Wz8sUjvO-QzV76xemypnX=bs1bxkdr...@mail.gmail.com Content-Type: text/plain; charset=UTF-8 On Wed, Aug 13, 2014 at 11:16 AM, Kathleen Wilson kwil...@mozilla.commailto:kwil...@mozilla.com wrote: 2) BR point-in-time audits may not be sufficient. https://wiki.mozilla.org/CA:CertificatePolicyV2.1#Time_Frames_for_incl uded_CAs_to_comply_with_the_new_policy Any Certificate Authority being considered for root inclusion after February 15, 2013 must comply with Version 2.1 or later of Mozilla's CA Certificate Policy. This includes having a Baseline Requirements audit performed if the websites trust bit is to be enabled. *Note that the CA's first Baseline Requirements audit may be a Point in Time audit.* We could change that to say that the first BR audit may be performed over a minimum of 3 months, and include testing of issuance and infrastructure. i.e. If it is the CA's first BR audit (because they were not in the program and did not know about the BRs) then the audit should cover 3 months, and the certificates/CRLs/OCSP-responses issued during that time must be evaluated against the BRs. Would this help? i.e. Is it needed in addition to proposal #1? It seems there two reasons that CAs might get a point in time readiness assessment (PITRA) rather than a period of time audit: 1) They didn't know about the BRs. In this case, it would seem possible that only having a PITRA is due to previously not following the BRs or at least not having auditable processes defined that required them to follow the BRs. 2) They don't yet issue certificates. If an organization is creating a brand new CA, there is no history of operation to be audited, so the only thing an auditor can perform is a PITRA. It is very possible that the CA will not start issuing certificates until they are accepted into the Mozilla program. I think AffirmTrust's application a couple of years ago demonstrated this scenario. It seems reasonable to continue to accept the PITRA for CAs that are not yet issuing certificates. This should be different than handling a CA that has issued certificate which do not follow the BR. Thanks, Peter table class=TM_EMAIL_NOTICEtrtdpre TREND MICRO EMAIL NOTICE The information
Re: Audits of CA conformance to the BRs
On Wed, August 20, 2014 5:17 pm, Kathleen Wilson wrote: On 8/19/14, 5:37 PM, Kathleen Wilson wrote: All, I started a new wiki page to document Mozilla's expectations regarding CA compliance with the BRs, and auditing according to the BRs. https://wiki.mozilla.org/CA:BaselineRequirements It is a very rough draft, but I would appreciate feedback on it. Thanks, Kathleen Regarding Whole-Population BR Audit of Intermediate Certs, since the BRs are for SSL certs, this should probably only apply to intermediate certs that are capable of issuing SSL certs. Agreed, which will require a definition of capability. This was discussed during the Mountain View F2F in the Forum though, and roughly aligns with Anything browsers recognize as SSL capable (something Mozilla's policy already explores) Regarding auditing for things in RFC 5280... There are things in RFC 5280 (such as duplicate serial numbers) that aren't stated in the BRs. So, does the CAB Forum need to add important requirements from RFC 5280 to the BRs, so they get added to the BR audit criteria? They are. From BR 1.1.9 From Section 4, Terminology Valid Certificate: A Certificate that passes the validation procedure specified in RFC 5280 From Appendix B - Certificate Extensions (Normative) All other fields and extensions MUST be set in accordance with RFC 5280. Note fields includes non-extension fields. Why I ask... It is my understanding that when an auditor performs a BR audit, she will follow a BR audit criteria such as the WebTrust BR audit criteria or the ETSI TS 102 042 PTC-BR criteria. For the requirements that are explicitly defined in the BR audit criteria, the auditor will examine the technical settings and sampled certificates to check for those things. For things that are not explicitly defined in BR audit criteria, the auditor may use some less strict audit procedures such as asking CA personnel or reviewing the CP/CPS to check for those things. Kathleen RFC 5280 is clear as a profile of what constitutes a 'valid' PKIX X.509 certificate. Fields that fail to adhere to the technical requirements do not conform to the BRs. For example, RFC 5280 Section 4.1.2.2. (Serial Number) The serial number MUST be a positive integer assigned by the CA to each certificate. It MUST be unique for each certificate issued by a given CA (i.e., the issuer name and serial number identify a unique certificate). CAs MUST force the serialNumber to be a non-negative integer. This basic requirement has been in RFC 5280 since 2008, RFC 3280 since 2002. The uniqueness requirement is present in RFC 2459 since 1999. (however, the positive integer requirement was not, at least not within 4.1.2.2) Given that the BRs normatively incorporate RFC 5280, auditors MUST be checking compliance in order to evaluate whether or not a given certificate conforms to the BRs. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
