Re: About upcoming limits on trusted certificates
On 3/12/20 5:52 AM, Doug Beattie wrote: Changing the domain validation re-user period is a substantial change from the Apple proposed max validity period change and will place an additional burden on certificate Applicants to update their domain validation more than twice as frequently. Please elaborate about why re-verifying the domain name ownership is difficult for the CA who is issuing the renewal TLS cert. Or why the TLS certificate Applicant will face undue burden if they have to prove domain name ownership when they renew their TLS cert to replace the cert that was issued a year ago. Or, is your concern about the date? e.g. aligning the change with the date that Apple chose of September 1, 2020 for the one-year validity period? I am not set on any particular date, so long as we are making forward progress. So if the concern is about the date, please suggest alternatives for when it would be reasonable to require CAs to re-verify that the certificate Applicant still owns the domain name to be included in their TLS cert to replace the cert that was issued a year ago. Certificate validity and domain validation re-use periods don’t necessarily need to be tied to the same value, so having certificate validity capped at 398 days and domain re-use set at 825 days isn’t contradictory. BygoneSSL explains why domain ownership validation should be done more frequently: https://insecure.design/ "" This is the demo site for BygoneSSL. It outlines what can happen when a SSL certificate can outlive one of its domains' ownerships into the next. Why is this a problem? Well, aside from the fact that the previous domain owner could Man-in-the-Middle the new domain owner's SSL traffic for that domain, if there are any domains that share alt-names with the domain, they can be revoked, potentially causing a Denial-of-Service if they are still in use. "" Can you also provide, in a blog or a publicly posted article, the reasons for shortening the certificate validity? There are hundreds of comments and suggestions in multiple mail lists, but there is a lack of a documented formal security analysis of the recommended changes that we can point our customers to. If folks think that it would be helpful, I (or someone at Mozilla) could post in Mozilla's Security Blog to list some of the reasons for shortening certificate validity periods and shortening the frequency of re-validating domain name verification. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Request to Include Microsec e-Szigno Root CA 2017 and to EV-enable Microsec e-Szigno Root CA 2009
Responses inline. On Thu, Mar 12, 2020 at 12:46 PM Sándor dr. Szőke via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > * Microsec issued two certificates in 2018 with 3-year validity periods > [1]. > > The certificates were issued for CISCO VPN servers. After receiving the > information about the misissuance the certificates were revoked. > This is an example of what I would call a "Highly disconcerting response". While it's important to note that much of the discussion is captured at https://groups.google.com/d/msg/mozilla.dev.security.policy/Pcc1_luzwNs/nAtn94GdBQAJ (Wayne's [1]), this summation/response of the problem downplays the severity, as well as downplays the confusion about long-standing practices that was discovered during such discussions. Most notably, the suggestion that domain controller and VPN server certificates, despite containing id-kp-serverAuth, were not TLS / not in scope. > * There are roughly 20 policy documents for this hierarchy [2]. It is > > quite challenging to determine which documents apply to which types of > > certificates. The upcoming version of Mozilla policy states that “CAs > > must provide a way to clearly determine which CP and CPS applies to each > > of its root and intermediate certificates.” > > Microsec already offers a tool on its homepage which filters the > corresponding policy documents to a specific type of certificates. The CP > and CPS documents contain the policy OID values which are included in the > issued certificates. The CP OID contains also the version of the CP so it > is evident which version of the CP is relevant. Microsec plans to develop a > tool which will help the user to find the proper CP and CPS documents for a > specific certificate based on the CP OID included in the certificate. > To be clear: In the absence of EKU constraints, the policy OIDs provide limited-to-no technical assurance that a given intermediate will be constrained adequately. As such, for a given intermediate, /all/ of the CP/CPS documents may still be relevant. I can understand and appreciate why, especially in keeping with an ITU-T model of X.509, one would use a separate CP for each OID, and a separate CPS to document how that information within that CP is validated. However, the overarching concern is about trying to understand the scope of the root and intermediate(s), what they are technically capable of issuing, as well as what they do issue. Related to the above, for example, the existence of a CP/CPS for a Cisco VPN service or a Windows Domain Controller, which indicated the certificate contained id-kp-serverAuth, would absolutely be meaningful and relevant to an assessment of that CA. So it's not sufficient to structure based on examining what /has been issued/, but what /could be issued/. The latter leads to a consolidation of CP/CPS documents, as the CA focuses on describing exactly what profile(s) a given intermediate/root can issue, and exactly what practice(s) are used to ensure compliance with policies. That's why you see so many CAs with only one or two CP/CPSes. > > > ==Bad== > > * Microsec recently issued what appears to be two certificate used for > > testing that violate the BRs [3][4]. They are now expired. > > These were only pre-certificates which were sent to the log servers. > These pre-certificates have been issued for internal test purposes only. > The live certificates have never been published in our certificate store > and never been used in publicly available networks. > This is exactly the kind of disconcerting response that leads me to suggest Microsec should not be trusted, because this exact interpretation/explanation by Microsec has been expressly rejected. I can understand that, at the time, Microsec may have reached an erroneous and incorrect conclusion. However, the failure to even acknowledge the clarifications that indicate why this is so problematic, and the failure to provide an incident report that talks about systemic fixes to these issues, suggest that Microsec has learned nothing, has no systemic checks in place, and will continue to make "similar mistakes" that share the same root issue. > > * CCADB currently lists 9 audit letter validation failures for Microsec. > > The CCADB presently contains 0 failure > This would have been a useful opportunity for Microsec to discuss the validation failures, what caused them, and the steps taken. However, this reply, as well as the reply regarding audit qualifications, highlights an approach to compliance that seems to focus on "As long as we're currently compliant, we're trustworthy", without systemically addressing the events that lead to non-compliance or how they're being prevented in the future. Knowing a CA is currently compliant is nowhere near as valuable a signal as knowing a CA has had a pattern of non-compliance, what the systemic causes were, and how they've been remediated. This is why I wrote such a strong message previously,
Re: Proper place for the Private Key Compromise information in CPS
2020. március 12., csütörtök 18:16:54 UTC+1 időpontban Ryan Sleevi a következőt írta: > On Thu, Mar 12, 2020 at 12:46 PM Sándor dr. Szőke via dev-security-policy < > > > So according to the RFC3647 the chapter 1.5.2 shall contain the contact > > person information who is responsible for the management of the CPS, > > but the BR requires, that the chapter 1.5.2 shall contain the information > > regarding the private key compromise. > > > > > > What is your opinion about it? Where to put this information in the CPS? > > Is the chapter 1.5.2 really the correct and expected place for it? > > > > Yes. That is what the BRs say. > > These are not mutually exclusive requirements. You can place the contact > person for the CP/CPS, as well as the contact person for compromises in > that section, and they don't have to be the same person. > > The CP/CPS makes obligations of the CA, and there needs to be a way to > determine how to contact the CA - for example, if the CP/CPS was not > adhered to, if a Subscriber certificate is found to be violating the > CP/CPS, etc. Thanks for the clarification. The RFC 3647 doesn't specify any specific place for this information, so we will move it from the section 4.9.3 to the section 1.5.2 into a subchapter in our CPS. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: GoDaddy: Failure to revoke key-compromised certificate within 24 hours
Matt, Our investigation reopened at March 9, 9:36 AM based on the information you provided in this forum. We were able to research and run appropriate testing which led to evidence of key compromise being determined March 9, 10:24 AM. We continued our diligence in accordance with the Baseline Requirements and revocation completed March 10, 10:24 AM. Joanna Fox ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Proper place for the Private Key Compromise information in CPS
On Thu, Mar 12, 2020 at 12:46 PM Sándor dr. Szőke via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > So according to the RFC3647 the chapter 1.5.2 shall contain the contact > person information who is responsible for the management of the CPS, > but the BR requires, that the chapter 1.5.2 shall contain the information > regarding the private key compromise. > > > What is your opinion about it? Where to put this information in the CPS? > Is the chapter 1.5.2 really the correct and expected place for it? > Yes. That is what the BRs say. These are not mutually exclusive requirements. You can place the contact person for the CP/CPS, as well as the contact person for compromises in that section, and they don't have to be the same person. The CP/CPS makes obligations of the CA, and there needs to be a way to determine how to contact the CA - for example, if the CP/CPS was not adhered to, if a Subscriber certificate is found to be violating the CP/CPS, etc. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: About upcoming limits on trusted certificates
On Thu, Mar 12, 2020 at 10:58 AM Jeremy Rowley wrote: > I think this statement is not accurate: "As a result, CAs don’t pursue > automation, or when they support it, neither promote nor require it." I > know very few CAs who want to spend extra resources on manual validations > and just as few who don't support some level of automation. The manual > methods are generally used because so many companies haven't automated this > process or refuse to. I think it'd be hard pressed to find many CAs that, as part of their sales/outreach, promote automation first. I don't deny that there are many CAs that support automation (indeed, over 99% of issuance is from CAs that support automation in some form), but when the first touch for many organizations, large or small, remains manual validation methods such as "paste a CSR", that's hardly an inaccurate statement. It's equally rare to find a CA that states that manual methods may require costs commiserate with their effort, or in any way indicate to a Subscriber that the lack of automation represents a burden that the Subscriber has some culpability in bearing. I certainly don't know of many CAs who actively refuse to issue certain types of certificates, absent automation. > The automated methods weren't even codified until ballot 169 which was > late 2016. We're at less than 4 years for automation being a real option. > Although I don't have empirical data for other CAs, the LE adoption rate (a > billion certs since indicates a fairly rapid adoption of automated methods > compared to other changes in the industry. > That's not at all true, even remotely. Ballot 169 hardly codified automated methods, and a number of CAs had long offered automated solutions before then. Especially under the pre-existing "Any other method" validation, CAs had plenty of room for automation, and had been using so for some time (this, in turn, influenced Ballot 169) I hate to haggle in the weeds here, since the conversation is really about lifetimes, but I think the record deserves correcting, because it cuts to the heart: which is that automation has long been known, and supported, and the only appreciable difference is not the difficulty, but the recalcitrance to push forward on that. In many ways, this is because CAs are a fungible commodity, and if one CA requires automation for their issuance, a Subscriber can just as easily go to another CA that does not require automation. As a consequence, CAs have strong negative externalities towards security-positive improvements. The balance for those externalities is the imposition of requirements by user agents, acting on behalf of the user, to ensure that user's needs (of site operators and CAs) are reflected, since the entirety of the Web PKI exists for the user's benefit of being assured about the domain/origin. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Request to Include Microsec e-Szigno Root CA 2017 and to EV-enable Microsec e-Szigno Root CA 2009
2020. március 9., hétfő 19:48:56 UTC+1 időpontban Kathleen Wilson a következőt írta: > This request is for inclusion of the Microsec e-Szigno Root CA 2017 > trust anchor and to EV-enable the currently included Microsec e-Szigno > Root CA 2009 trust anchor as documented in the following bug: > https://bugzilla.mozilla.org/show_bug.cgi?id=1445364 > > > Wayne performed the detailed review of the CPs, CPSs, BR Self > Assessment, and related information for inclusion of the Microsec > e-Szigno Root CA 2017 and the EV-enablement of the Microsec e-Szigno > Root CA 2009 roots that are being tracked in this bug and he had the > following comments: > Let me answer Wayne's findings in the original text > ==Meh== > * The subordinate CA certificates for this root were created in 2017 and > 2018. None of those intended for serverAuth are constrained by EKU. > Mozilla began requiring this in 2019. The subordinate CA-s already contain EKU which are intended to issue codesigning certificates and certificates for time stamping units. There is not EKU in the subordinate CA certificates which are intended to issue other types of certificates, like website authentication, digital signature, client authentication, encryption etc. These subordinate CAs were created in 2017. > * Microsec issued two certificates in 2018 with 3-year validity periods [1]. The certificates were issued for CISCO VPN servers. After receiving the information about the misissuance the certificates were revoked. > * There are roughly 20 policy documents for this hierarchy [2]. It is > quite challenging to determine which documents apply to which types of > certificates. The upcoming version of Mozilla policy states that “CAs > must provide a way to clearly determine which CP and CPS applies to each > of its root and intermediate certificates.” Microsec already offers a tool on its homepage which filters the corresponding policy documents to a specific type of certificates. The CP and CPS documents contain the policy OID values which are included in the issued certificates. The CP OID contains also the version of the CP so it is evident which version of the CP is relevant. Microsec plans to develop a tool which will help the user to find the proper CP and CPS documents for a specific certificate based on the CP OID included in the certificate. > * CP section 1.3.2 permits 3rd party RAs, but in their BR > Self-Assessment, Microsec states that “The Trust Service Provider do not > apply third parties for RA activities.” Correct, Microsec presently do not apply any third parties for RA activities as it written in the CPS. > * CPS section 4.9.5 provides a detailed explanation of the revocation > process but fails to mention the required preliminary report to the > Subscriber and the entity who filed the Certificate Problem Report. The working process contains the communication with the Subscriber and the entity who filed the Certificate Problem Report. This information will be included in the next version of the CPS. > * CPS section 4.9.1 contains a section titled “Reasons for Revoking a > Subordinate CA Certificate operated by another CA” but in their BR > Self-assessment, Microsec states that “All Subordinate CA-s under the > Microsec roots are operated by Microsec.” Microsec is open for this type of cooperation, but presently Microsec operates all the subordinate CA-s under the Microsec roots. > > ==Bad== > * I was unable to locate the description of email address validation > practices required by Mozilla policy section 2.2. Microsec published new > CPS version adding section 3.2.7 to resolve this issue. Microsec always validates the email address, typically by sending an email containing an unique URL to the email address which has to be used by the Subscriber. The actual CPS contains more detailed description about the validation method of the email addresses. > * Microsec recently issued what appears to be two certificate used for > testing that violate the BRs [3][4]. They are now expired. These were only pre-certificates which were sent to the log servers. These pre-certificates have been issued for internal test purposes only. The live certificates have never been published in our certificate store and never been used in publicly available networks. > * CCADB currently lists 9 audit letter validation failures for Microsec. The CCADB presently contains 0 failure > * The root contains subject L and organizationIdentifier fields which > are arguably in violation of BR 7.1.4.3 [5]. Some, if not all, of the > subCAs also exhibit this issue. It is a general requirement that CA name shall be detailed enough to allow relatively straightforward identification of the CA. In the EU all of the companies has an official and unique company registration number, and it is a requirement to add this value into the enduser certificates in the organizationIdentifier field. It is
Proper place for the Private Key Compromise information in CPS
The CABF BR section 2.2. PUBLICATION OF INFORMATION contains the following requirement: The Certificate Policy and/or Certification Practice Statement MUST be structured in accordance with RFC 3647 and MUST include all material required by RFC 3647. The CABF BR section 4.9.3. Procedure for Revocation Request contains the following requirement: ... The CA SHALL provide Subscribers, Relying Parties, Application Software Suppliers, and other third parties with clear instructions for reporting suspected Private Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, inappropriate conduct, or any other matter related to Certificates. The CA SHALL publicly disclose the instructions through a readily accessible online means and in section 1.5.2 of their CPS. According to RFC3647 chapter 6 which defines the detailed structure of the CP and CPS documents, the capter 1.5 shall contain the policy administration information as follows: 1.5 Policy administration 1.5.1 Organization administering the document 1.5.2 Contact person 1.5.3 Person determining CPS suitability for the policy 1.5.4 CPS approval procedures So according to the RFC3647 the chapter 1.5.2 shall contain the contact person information who is responsible for the management of the CPS, but the BR requires, that the chapter 1.5.2 shall contain the information regarding the private key compromise. What is your opinion about it? Where to put this information in the CPS? Is the chapter 1.5.2 really the correct and expected place for it? Presently we have this information in the section 4.9.3 in our CPS. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Request to Include Microsec e-Szigno Root CA 2017 and to EV-enable Microsec e-Szigno Root CA 2009
2020. március 9., hétfő 19:48:56 UTC+1 időpontban Kathleen Wilson a következőt írta: > This request is for inclusion of the Microsec e-Szigno Root CA 2017 > trust anchor and to EV-enable the currently included Microsec e-Szigno > Root CA 2009 trust anchor as documented in the following bug: > https://bugzilla.mozilla.org/show_bug.cgi?id=1445364 > > Thank you for opening the 3-week comment period for our inclusion request. At first let us give some background information regarding the findings of the auditor. Microsec is a qualified trust service provider in Hungary and operates under strong control and supervision. The yearly regular conformity assessment audit is made by the German TÜViT, which is one of the most stringent and thorough auditor in Europe. Based on that very deep and careful audit TÜViT issues the audit reports and the attestation letters which contain all of the findings. The findings are classified according to their weight. If the auditor finds any major non-conformity, the audit report is not issued at all. In case of minor non-conformity, the audit report is issued, and the CA may continue its services, but the CA shall report the action made to solve the findings within 3 months. In case of recommendation the weight of the problem is low, and the CA shall solve the issue till the next audit (1 year). TÜViT includes both the minor non-conformities and the recommendations in the attestation letter and the classification of the finding is not indicated in the report. There was no major issue during the Microsec audit, so TÜViT issued the certificates and the attestation letters to Microsec. Most of the findings were classified as recommendation. Microsec has applied remediations to all findings in a timely fashion and all the remediations have been accepted by TÜViT. The other reason while Microsec may have longer finding list than usual is, that Microsec offers several types of services and issues several types of certificates for different purposes (webserver authentication, electronic signature, electronic seal, encryption, authentication etc.) on different trust levels (EU qualified and not qualified). All of the certificates are issued under the same root and there are no EKU to constrain most of the subordinate CAs from the BR audit, this way all the certificate types and CA-s shall be covered by the audit, including certificates which are not in the scope of the BR. The higher number of certificate types and services may result more findings during the audit which can be unusual in a CA who offers only one service. The relatively high number of findings doesn't mean that Microsec is a bad CA, but means that TÜViT is a very thorough auditor. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Auditing of CA facilities in lockdown because of an environmental disaster/pandemic
Situation from ACAB'c ETSI auditors point of view: On one hand it is quite simple: if the auditor cannot perform the audit as foreseen in the certification program no certificate can be issued. In case a surveillance audit cannot be performed, the certification body must withdraw the affected certificate. On the other hand the situation is complex because the reason for not performing the audit is neither the fault of the CA neither the fault of the auditor but due to a force majeure. In this case, the questions to ask comprise: 1. What is the reason for having the audit? 2. What is the reason to perform the audit now? 3. Can the audit be postponed? 4. Would it help to perform the audit in a reduced scope? In the present case the reason for having the audit and having it at a certain time comes from rules defined by the consumer of the audit attestations/certificates, i. e. the browsers. In this case browsers should think about answers to questions 3 and 4 and considering the possibility of adapting the rules for the case of force majeure. This happens in public life, too. According to the law, kids must go to school (at least in Germany). But today, some (but not all) schools are closed because of the virus. So the rules were changed. Hence, it is hard to define a universal rule valid for all CAs (schools). The following focuses on the possibilities in case of travel restrictions. Details might be different for other cases like natural disasters. One possible scenario could be that the Auditors of the accredited CAB are under restriction: Such a case would mainly be addressed by business continuity provisions of the conformity assessment body (CAB), considering e.g. the following questions: - What is the duration until return to normal operation? Can the audit still be performed in time after the restrictions have been lifted? - How is the auditing personnel distributed? With personnel in different locations, maybe not all auditors are affected at the same time. - Can the CAB subcontract non-affected external auditors? - If the CAB does not have sufficient options, can another ACAB’c member CAB jump in? In any case will the accredited CAB take care of the requirement conformant treatment of the travel restricted situation based upon its quality controlled ruleset following ISO/IEC 17065 in conjunction with ETSI EN 319403. The other possible scenario would be that the TSP or a TSP location is under restriction: A general rule is, that the scope of the assessment (including “in terms of facilities”) must be clearly defined (ETSI EN 319 403, 7.4.1.0) and that the complete scope must be audited to perform an ETSI certification. Another general rule is that, depending on some pre-conditions, a sample-based approach could be possible for TSPs using multiple sites. (ETSI EN 319 403, 7.4.3) In some cases, it might be possible to choose a sample that does not include locations under restriction. However, as the CABF requires full audits, this does not apply in this context. If facilities can’t be audited by auditors of the CAB in person, possible alternatives are more or less identical to those stated for Webtrust - “Network-assisted auditing techniques” are possible (ETSI EN 319 403, 7.4.1.2) - CAB may subcontract auditors that do not fall under the restriction, if they fulfil the auditor requirements. The CAB always remains fully responsible for such outsourced activities. (ISO/IEC 17065, 6.2.2 ). If such alternatives were accepted by the CAB to provide reasonable assurance with regard to the requirements to be audited, this would result in a normal audit conclusion and would not be visible on an audit attestation letter. If none of the two alternatives is possible, a general rule is, that everything which can be audited will be audited - there is especially no restriction to do a full Stage 1 document audit. If facilities cannot be audited by auditors of the CAB in person and the alternatives stated above are not possible or the CAB does not regard them to provide reasonable assurance with regard to the requirements to be audited in order to draw a reasonable audit conclusion this shall be documented in the audit report. An audit attestation letter shall be issued stating which parts have not been covered by the audit. How to deal with the situation, after travel restrictions have been lifted? From the viewpoint of an ETSI certification, no ETSI certificate has been issued: - It is possible to re-use the original audit results and perform an additional audit just with regard to the non audited requirements (ISO/IEC 17065, 7.4). Usually, the period during which this is possible is limited by the CAB (ACAB’c: 6 month). Once the original audit becomes too old, a completely new audit would be necessary. From the viewpoint of an Audit Attestation Letter (AAL) under ETSI, either an updated version of the original audit attestation
RE: About upcoming limits on trusted certificates
I think this statement is not accurate: "As a result, CAs don’t pursue automation, or when they support it, neither promote nor require it." I know very few CAs who want to spend extra resources on manual validations and just as few who don't support some level of automation. The manual methods are generally used because so many companies haven't automated this process or refuse to. The companies who contribute to these threads tend to be far more technical than most other companies (or the majority of cert requesters). The assumption that each company has the resources to set up automation ignores this. The opposition to shorter lifecycles and validation periods stems from knowing these work flows and the painful exercise of changing them. The automated methods weren't even codified until ballot 169 which was late 2016. We're at less than 4 years for automation being a real option. Although I don't have empirical data for other CAs, the LE adoption rate (a billion certs since indicates a fairly rapid adoption of automated methods compared to other changes in the industry. Jeremy -Original Message- From: dev-security-policy On Behalf Of Ryan Sleevi via dev-security-policy Sent: Thursday, March 12, 2020 7:30 AM To: Julien Cristau Cc: Mozilla ; Kathleen Wilson Subject: Re: About upcoming limits on trusted certificates The Baseline Requirements allow a number of methods that aren’t easily automated, such as validation via email. As a result, CAs don’t pursue automation, or when they support it, neither promote nor require it. This leads CAs to be opposed to efforts to shorten the reuse time, as they have historically treated it as the same complexity as identity validation, even when it doesn’t need to be. There’s nothing intrinsically preventing it, although the practical effect is it would encourage technically automatable methods, as opposed to manual methods. On Thu, Mar 12, 2020 at 4:45 AM Julien Cristau via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hi Kathleen, all, > > Is there a reason domain validation information needs to be reused for > more than, say, 30 days? For the manual parts of identity validation > I understand you don't want to repeat the process too often, but > domain validation can be entirely automated so it doesn't seem like > long reuse periods are warranted. (It's entirely possible I'm missing > something and there are significant hurdles to overcome for CAs and/or > applicants in confirming domain ownership more than once a year.) > > Thanks, > Julien > > On Wed, Mar 11, 2020 at 11:39 PM Kathleen Wilson via > dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > > All, > > > > First, I would like to say that my preference would have been for > > this type of change (limit SSL cert validity period to 398 days) to > > be agreed to in the CA/Browser Forum and added to the BRs. However, > > the ball is already rolling, and discussion here in m.d.s.p is > > supportive of updating Mozilla's Root Store Policy to incorporate > > the shorter validity period. So... > > > > What do you all think about also limiting the re-use of domain > validation? > > > > BR section 3.2.2.4 currently says: "Completed validations of > > Applicant authority may be valid for the issuance of multiple > > Certificates over time." > > And BR section 4.2.1 currently says: "The CA MAY use the documents > > and data provided in Section 3.2 to verify certificate information, > > or may reuse previous validations themselves, provided that the CA > > obtained the data or document from a source specified under Section > > 3.2 or completed the validation itself no more than 825 days prior > > to issuing the Certificate." > > > > In line with that, section 2.1 of Mozilla's Root Store Policy > > currently > > says: > > "CAs whose certificates are included in Mozilla's root program MUST: ... > > "5. verify that all of the information that is included in SSL > > certificates remains current and correct at time intervals of 825 > > days or less;" > > > > When we update Mozilla's Root Store Policy, should we shorten the > > domain validation frequency to be in line with the shortened > > certificate validity period? i.e. change item 5 in section 2.1 of > > Mozilla's Root Store Policy to: > > "5. limit the validity period and re-use of domain validation for > > SSL certificates to 398 days or less if the certificate is issued on > > or after September 1, 2020;" > > > > I realize that in order to enforce shorter frequency in domain > > validation we will need to get this change into the BRs and into the > > audit criteria. But CAs are expected to follow Mozilla's Root Store > > Policy regardless of enforcement mechanisms, and having this in our > > policy would make Mozilla's intentions clear. > > > > As always, I will greatly appreciate your thoughtful and > > constructive input on this. > > > > Thanks, > >
Re: About upcoming limits on trusted certificates
The Baseline Requirements allow a number of methods that aren’t easily automated, such as validation via email. As a result, CAs don’t pursue automation, or when they support it, neither promote nor require it. This leads CAs to be opposed to efforts to shorten the reuse time, as they have historically treated it as the same complexity as identity validation, even when it doesn’t need to be. There’s nothing intrinsically preventing it, although the practical effect is it would encourage technically automatable methods, as opposed to manual methods. On Thu, Mar 12, 2020 at 4:45 AM Julien Cristau via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hi Kathleen, all, > > Is there a reason domain validation information needs to be reused for more > than, say, 30 days? For the manual parts of identity validation I > understand you don't want to repeat the process too often, but domain > validation can be entirely automated so it doesn't seem like long reuse > periods are warranted. (It's entirely possible I'm missing something and > there are significant hurdles to overcome for CAs and/or applicants in > confirming domain ownership more than once a year.) > > Thanks, > Julien > > On Wed, Mar 11, 2020 at 11:39 PM Kathleen Wilson via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > All, > > > > First, I would like to say that my preference would have been for this > > type of change (limit SSL cert validity period to 398 days) to be agreed > > to in the CA/Browser Forum and added to the BRs. However, the ball is > > already rolling, and discussion here in m.d.s.p is supportive of > > updating Mozilla's Root Store Policy to incorporate the shorter validity > > period. So... > > > > What do you all think about also limiting the re-use of domain > validation? > > > > BR section 3.2.2.4 currently says: "Completed validations of Applicant > > authority may be valid for the issuance of multiple Certificates over > > time." > > And BR section 4.2.1 currently says: "The CA MAY use the documents and > > data provided in Section 3.2 to verify certificate information, or may > > reuse previous validations themselves, provided that the CA obtained the > > data or document from a source specified under Section 3.2 or completed > > the validation itself no more than 825 days prior to issuing the > > Certificate." > > > > In line with that, section 2.1 of Mozilla's Root Store Policy currently > > says: > > "CAs whose certificates are included in Mozilla's root program MUST: ... > > "5. verify that all of the information that is included in SSL > > certificates remains current and correct at time intervals of 825 days > > or less;" > > > > When we update Mozilla's Root Store Policy, should we shorten the domain > > validation frequency to be in line with the shortened certificate > > validity period? i.e. change item 5 in section 2.1 of Mozilla's Root > > Store Policy to: > > "5. limit the validity period and re-use of domain validation for SSL > > certificates to 398 days or less if the certificate is issued on or > > after September 1, 2020;" > > > > I realize that in order to enforce shorter frequency in domain > > validation we will need to get this change into the BRs and into the > > audit criteria. But CAs are expected to follow Mozilla's Root Store > > Policy regardless of enforcement mechanisms, and having this in our > > policy would make Mozilla's intentions clear. > > > > As always, I will greatly appreciate your thoughtful and constructive > > input on this. > > > > Thanks, > > Kathleen > > ___ > > dev-security-policy mailing list > > dev-security-policy@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-security-policy > > > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: About upcoming limits on trusted certificates
Kathleen, Changing the domain validation re-user period is a substantial change from the Apple proposed max validity period change and will place an additional burden on certificate Applicants to update their domain validation more than twice as frequently. This would be a sudden and large departure from the BRs. Certificate validity and domain validation re-use periods don’t necessarily need to be tied to the same value, so having certificate validity capped at 398 days and domain re-use set at 825 days isn’t contradictory. Can you also provide, in a blog or a publicly posted article, the reasons for shortening the certificate validity? There are hundreds of comments and suggestions in multiple mail lists, but there is a lack of a documented formal security analysis of the recommended changes that we can point our customers to. Doug -Original Message- From: dev-security-policy On Behalf Of Kathleen Wilson via dev-security-policy Sent: Wednesday, March 11, 2020 8:29 PM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: About upcoming limits on trusted certificates On 3/11/20 4:37 PM, Paul Walsh wrote: > >> On Mar 11, 2020, at 4:11 PM, Kathleen Wilson via dev-security-policy >> wrote: >> >> On 3/11/20 3:51 PM, Paul Walsh wrote: >>> Can you provide some insight to why you think a shorter frequency in domain >>> validation would be beneficial? > [PW] If the owner’s identity has already been validated and that information > is still valid, why ask them to validate again? By "domain validation" I specifically mean verifying that the certificate requestor owns/controls the domain name(s) to be included in the TLS certificate. > [PW] I believe it’s a good idea to ensure they’re still in control of the > domain. So I guess we are in agreement on this. > My comment is in relation to the cost of validating their identity. My proposal has nothing to do with identity validation. > [PW] Thanks for this info. If this is already part of the CA/B Forum, is it > your intention to potentially do something different/specific for Firefox, > irrespective of what happens in that forum? > My proposal is that if we are going to update Mozilla's policy to require TLS certs to have validity period of 398 days or less, we should also update Mozilla's policy to say that re-use of domain validation is only valid up to 398 days. i.e. the ownership/control of the domain name should be re-validated before the renewal cert is issued. Currently Mozilla's policy and the BRs allow the CA to re-use domain validation results for up to 825 days. (which is inline with the 825 day certificate validity period currently allowed by the BRs) Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: About upcoming limits on trusted certificates
Hi Kathleen, all, Is there a reason domain validation information needs to be reused for more than, say, 30 days? For the manual parts of identity validation I understand you don't want to repeat the process too often, but domain validation can be entirely automated so it doesn't seem like long reuse periods are warranted. (It's entirely possible I'm missing something and there are significant hurdles to overcome for CAs and/or applicants in confirming domain ownership more than once a year.) Thanks, Julien On Wed, Mar 11, 2020 at 11:39 PM Kathleen Wilson via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > All, > > First, I would like to say that my preference would have been for this > type of change (limit SSL cert validity period to 398 days) to be agreed > to in the CA/Browser Forum and added to the BRs. However, the ball is > already rolling, and discussion here in m.d.s.p is supportive of > updating Mozilla's Root Store Policy to incorporate the shorter validity > period. So... > > What do you all think about also limiting the re-use of domain validation? > > BR section 3.2.2.4 currently says: "Completed validations of Applicant > authority may be valid for the issuance of multiple Certificates over > time." > And BR section 4.2.1 currently says: "The CA MAY use the documents and > data provided in Section 3.2 to verify certificate information, or may > reuse previous validations themselves, provided that the CA obtained the > data or document from a source specified under Section 3.2 or completed > the validation itself no more than 825 days prior to issuing the > Certificate." > > In line with that, section 2.1 of Mozilla's Root Store Policy currently > says: > "CAs whose certificates are included in Mozilla's root program MUST: ... > "5. verify that all of the information that is included in SSL > certificates remains current and correct at time intervals of 825 days > or less;" > > When we update Mozilla's Root Store Policy, should we shorten the domain > validation frequency to be in line with the shortened certificate > validity period? i.e. change item 5 in section 2.1 of Mozilla's Root > Store Policy to: > "5. limit the validity period and re-use of domain validation for SSL > certificates to 398 days or less if the certificate is issued on or > after September 1, 2020;" > > I realize that in order to enforce shorter frequency in domain > validation we will need to get this change into the BRs and into the > audit criteria. But CAs are expected to follow Mozilla's Root Store > Policy regardless of enforcement mechanisms, and having this in our > policy would make Mozilla's intentions clear. > > As always, I will greatly appreciate your thoughtful and constructive > input on this. > > Thanks, > Kathleen > ___ > 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
