Re: DRAFT May 2020 CA Communication/Survey
Based on the survey results, we (Ben and I) have recommended the following updates to the Browser Alignment Ballot. (currently in draft form here: https://github.com/sleevi/cabforum-docs/pull/10) 1) For the following changes proposed in the ballot, we have recommended that the effective date be on September 30, 2020. - OCSP requirements (OCSP must be supported, validity interval for OCSP response more explicitly defined, revocationReason required) - CRL updates (reasonCode required) -- The change regarding the OCSP and CRL updates is already in progress here: https://github.com/sleevi/cabforum-docs/commit/1e59ed6bc3f1411b28ecafc3ee41b293903cd755 - Certificate Policies (MUST contain at least one CA/Browser Forum defined-policy OID.) -- This change is already in progress here: https://github.com/sleevi/cabforum-docs/commit/80ea02a31b29d614b843d119a6c022652840c806 - Name Encoding Rules (Byte-for-byte Identical Issuer and Subject Distinguished Names) -- This change is already in progress here: https://github.com/sleevi/cabforum-docs/commit/91125b8fbc1b56abea7783f63b915ba09ca799de 2) Restrict the second part of the Name Encoding Rules (Byte-for-byte Identical Issuer and Subject Distinguished Names) changes to subCAs. -- This change is already in progress here: https://github.com/sleevi/cabforum-docs/commit/91125b8fbc1b56abea7783f63b915ba09ca799de 3) (No Change, just explanation) Mozilla’s approach to adding the certificate validity period reduction to our root store policy would normally have included a public discussion in mozilla.dev.security.policy. In the survey, CAs all indicated that they will be following this new requirement anyways for compatibility reasons. So we are OK with it remaining in this ballot. Any further discussion about the Browser Alignment Ballot should continue in the CA/Browser Forum Server Certificate Working Group or in GitHub. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DRAFT May 2020 CA Communication/Survey
On Mon, Jun 1, 2020 at 7:23 PM Kathleen Wilson via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > ** Sub Item 3.2 -- Limit re-use of domain name and IP address > verification to 398 days > (https://github.com/mozilla/pkipolicy/issues/206) > 19 CAs responded that they either do not re-use domain verification, or > that their re-use of domain verification is already less than 398 days. > 11 CAs indicated that they could implement the changes to their > processes and documentation to limit the re-use of domain name > verification to 398 days or less before 2020 Sep 30, 2020 > 9 CAs shared the sentiment that they would prefer that the re-use of > verification information be regulated by the CA/Browser Forum Baseline > Requirements. > A few CAs indicated that this requirement would cause extra work for > their customers, and requested a detailed security analysis of this > change which they could convey to their customers. > One CA noted: "If there is a change to reuse requirements, it should > only apply to data verified on or after the effective date of the > change. This change should not apply to data verified before the > effective date of the change to avoid creating a verification cliff for > the CAs and Subscribers. Note, if Mozilla requires that a domain name or > IP address is re-verified each time a TLS certificate is issued, then > this will reduce the effectivity of a number of verification > methodologies that can be used and could impact many ecosystems which > rely on TLS." It is interesting the degree to which this CA continues to do a disservice to their customers, and the ecosystem, with replies like this. There are only three validation methods which might (not will) have their effectivity reduced, and that is validation methods that require manual validation using less secure, less reliable methods of validation: namely, validation of DNS via a phone call, rather than DNS itself. The extent of ecosystem wide CA incidents in the past year has only highlighted the importance of strong technical controls for domain validation. Methods that rely on unstructured text (like WHOIS) or that are artificially constrained due to requiring manual steps continue to cause validation issues and impair the ability of CAs to respond effectively to security incidents. Mozilla’s own feedback on CA incidents has highlighted the critical importance of CA’s ability to support validation methods that can be done without requiring an error prone, high latency, non-scalable human approval, instead basing validation on the thing being validated, namely, DNS itself. It’s certainly true that there would be an impact, but it is undeniable when one examines the CA incidents, both in issuance and revocation, so say it be a much-needed positive impact towards ensuring robust and healthy ecosystems. Given how many CAs have already implemented this change, or could do so, I think we should be careful when giving it any substantive weight. I worry the inclusion here might be seen as legitimizing the feedback, rather than highlighting how divorced it is from the ecosystem and their peers. Given how much of the ecosystem has already moved positively in the right direction and taken steps to mitigate any issues and avoid any hypothetical cliffs, as shown by the feedback, I think we should view this specific CA’s feedback as a largely intransigent response focused on maintaining the status quo, rather than how best to serve the needs of relying parties who place trust in them. > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DRAFT May 2020 CA Communication/Survey
Thank you to all of you who responded to the May 2020 CA Communication/Survey. Communication/Survey: https://wiki.mozilla.org/CA/Communications#May_2020_CA_Communication Blog Post: https://blog.mozilla.org/security/2020/05/08/may-2020-ca-communication/ Responses: https://wiki.mozilla.org/CA/Communications#May_2020_Responses Summary of Results: * Item 1 -- Impact of COVID-19 Restrictions Everyone responded with: "We have reviewed https://wiki.mozilla.org/CA/Audit_Statements#Audit_Delay and understand the action to take if we need to report issues to Mozilla." * Item 2 -- Mozilla Root Store Policy version 2.7 Requirements and Deadlines Most CAs responded with: "Our responses to the January 2020 CA Communication have not changed, and we will meet these requirements according to the dates we previously specified." Some CAs indicated the work that they are still doing. I did not notice any alarming responses. * Item 3 -- Reducing Maximum Validity Period for TLS Certificates ** Sub Item 3.1 -- Limit TLS Certificates to 398-day validity (https://github.com/mozilla/pkipolicy/issues/204) Most CAs who are issuing TLS certificates indicated their intent to limit TLS certificate validity period to 398 days or less for certificates issued after September 1, 2020. Some CAs are already issuing TLS certs with shorter validity periods, and others indicated that they would be able to implement shorter validity periods by the date Mozilla specifies in its policy. Many CAs voiced discontent with the way this requirement came about. To quote one CA: "Root programs should not place binding requirements on CAs via email messages without corresponding root policy updates, or at a minimum, a blog or announcement that can be referenced as a an authoritative trusted source." ** Sub Item 3.2 -- Limit re-use of domain name and IP address verification to 398 days (https://github.com/mozilla/pkipolicy/issues/206) 19 CAs responded that they either do not re-use domain verification, or that their re-use of domain verification is already less than 398 days. 11 CAs indicated that they could implement the changes to their processes and documentation to limit the re-use of domain name verification to 398 days or less before 2020 Sep 30, 2020 9 CAs shared the sentiment that they would prefer that the re-use of verification information be regulated by the CA/Browser Forum Baseline Requirements. A few CAs indicated that this requirement would cause extra work for their customers, and requested a detailed security analysis of this change which they could convey to their customers. One CA noted: "If there is a change to reuse requirements, it should only apply to data verified on or after the effective date of the change. This change should not apply to data verified before the effective date of the change to avoid creating a verification cliff for the CAs and Subscribers. Note, if Mozilla requires that a domain name or IP address is re-verified each time a TLS certificate is issued, then this will reduce the effectivity of a number of verification methodologies that can be used and could impact many ecosystems which rely on TLS." * Item 4 -- CA/Browser Forum Ballot for Browser Alignment ** Sub Item 4.1 -- CA/Browser Forum defined-policy OID in Subscriber Cert certificatePolicies (https://github.com/mozilla/pkipolicy/issues/212) With the exception of one CA, every CA that is issuing TLS certs responded that they either already do this, or can do this by September 30, 2020. ** Sub Item 4.2 -- Byte-for-byte Identical Issuer and Subject Distinguished Names (https://github.com/mozilla/pkipolicy/issues/213) Most CAs already do this, but a few CAs indicated that they would need some time for further analysis and making changes which appear do-able for future cert issuance. Note: I would not want this to cause lots of revocations of existing certs, so prefer a future effective date. A couple CAs indicated that the second part of the requirement should be restricted to subCAs. Note: This change is already under consideration per discussion in the CABF. ** Sub Item 4.3 -- Text-searchable PDF Audit Statements (https://github.com/mozilla/pkipolicy/issues/210) All CAs indicated that either they already do this, or that they can do this for their next audits. ** Sub Item 4.4 -- OCSP Requirements (https://github.com/mozilla/pkipolicy/issues/211) All CAs indicated that they either already do this, or can do this by September 2020. (Note that one CA said October 14, 2020) Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DRAFT May 2020 CA Communication/Survey
On 5/7/20 11:33 AM, Kathleen Wilson wrote: > I have drafted a potential CA Communication and survey, and will greatly > appreciate your input on it. > > https://wiki.mozilla.org/CA/Communications#May_2020_CA_Communication > > Direct link to read-only copy of the draft survey: > https://ccadb-public.secure.force.com/mozillacommunications/CACommunicationSurveySample?CACommunicationId=a051J42AUSv I believe that all of the questions/concerns have been resolved, so I will open up the survey now, and prepare to send the email to the CAs about it. Thanks, Kathleen The email has been sent to the Primary POC (cc'd the CA's email alias) for each CA with a root cert currently in Mozilla's root store. Blog post: https://blog.mozilla.org/security/2020/05/08/may-2020-ca-communication/ Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DRAFT May 2020 CA Communication/Survey
> I have drafted a potential CA Communication and survey, and will greatly > appreciate your input on it. > > https://wiki.mozilla.org/CA/Communications#May_2020_CA_Communication > > Direct link to read-only copy of the draft survey: > https://ccadb-public.secure.force.com/mozillacommunications/CACommunicationSurveySample?CACommunicationId=a051J42AUSv I believe that all of the questions/concerns have been resolved, so I will open up the survey now, and prepare to send the email to the CAs about it. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DRAFT May 2020 CA Communication/Survey
On 5/4/20 9:31 AM, Corey Bonnell wrote: Thank you very much for the clarifications. If I'm understanding correctly, it sounds like Mozilla is considering to add sub-items of item 4 on the survey as Mozilla Root Program requirements if the associated CAB Forum ballot does not pass. However, there is concern that many CAs may not be compliant with these requirements, so the purpose of the survey is to gauge potential impact to CAs so that effective dates can be set such that CAs can react appropriately as well as to gather data to better inform Mozilla's position in the CAB Forum. Is that a correct assessment of the purpose of question 4? Correct. I created the issues in Github so these items get considered for Mozilla's policy in one form or other (direct, through BRs, or both). Here is a breakdown of my perspective of the Browser Alignment Ballot (https://github.com/sleevi/cabforum-docs/pull/10) specifically in regards to Mozilla’s Root Store Policy. Audit Reporting - CAs should already be following all but one of the additions, because they are already part of section 3.1.4 of Mozilla’s Root Store Policy[1] and section 5.1 of the CCADB Policy[2]. - I filed https://github.com/mozilla/pkipolicy/issues/210 for the requirement that would be new to Mozilla policy: “CCADB Policy: Require audit statements to be text-searchable PDF” (SUB ITEM 4.3 in the May 2020 CA Communication/Survey.) OCSP - I filed https://github.com/mozilla/pkipolicy/issues/211 to consider updating section 6 of Mozilla’s Root Store Policy: “Require OCSP and Reduce OCSP response max validity from 10 days to 7 days” (SUB ITEM 4.4 in the May 2020 CA Communication/Survey.) - Mozilla may propose in the CABF that the other three items in this section be removed from the ballot (fresh OCSP responses at one-half of validity interval, must contain revocationReason, must not contain a reasonCode singleExtension). CRLs - Mozilla may propose in the CABF that these changes be removed from the ballot (reasonCode requirements for intermediate cert revocations). I don't see a reason for Mozilla to require this or enforce such a rule. Certificate Policies - I filed https://github.com/mozilla/pkipolicy/issues/212 to consider updating Mozilla’s Root Store Policy if this doesn’t get added to the BRs: “Require at least one CABF defined-policy OID in certificatePolicies extension for TLS certs” (SUB ITEM 4.1 in the May 2020 CA Communication/Survey.) Authority Key ID - CAs should already be following this item because it is already part of RFC 5280 and section 5.2 of Mozilla’s Root Store Policy. (RFC 5280: authorityKeyIdentifier MUST be present and MUST contain a keyIdentifier, Mozilla Policy: “CAs MUST NOT issue certificates that have … authority key IDs that include both the key ID and the issuer’s issuer name and serial number”) Extended Key Usage - CAs should already be following this item because it is already part of section 5.3 of Mozilla’s Root Store Policy. Name Encoding Rules - I filed https://github.com/mozilla/pkipolicy/issues/213 to consider updating Mozilla’s Root Store Policy even if this does get added to the BRs: “Require Byte-for-byte Identical Issuer and Subject Distinguished Names” (SUB ITEM 4.2 in the May 2020 CA Communication/Survey.) CP/CPS - CAs should already be following this item because it is already in section 3.3 of Mozilla’s Root Store Policy. Key Algorithms and Sizes - CAs should already be following this item because it is already in section 5 of Mozilla’s Root Store Policy. Signature Algorithms - These clarifications were added to section 5 of Mozilla’s Root Store Policy in version 2.7, with an effective date of January 1, 2020. Certificate Lifetimes - https://github.com/mozilla/pkipolicy/issues/204 (ITEM 3 in the May 2020 CA Communication/Survey.) Clarify Effective Dates - This is a clarification that seems reasonable, and does not require action. Thanks, Kathleen [1] https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy [2] https://www.ccadb.org/policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: DRAFT May 2020 CA Communication/Survey
Hi Kathleen, Thank you very much for the clarifications. If I'm understanding correctly, it sounds like Mozilla is considering to add sub-items of item 4 on the survey as Mozilla Root Program requirements if the associated CAB Forum ballot does not pass. However, there is concern that many CAs may not be compliant with these requirements, so the purpose of the survey is to gauge potential impact to CAs so that effective dates can be set such that CAs can react appropriately as well as to gather data to better inform Mozilla's position in the CAB Forum. Is that a correct assessment of the purpose of question 4? As for creating GitHub issues, while I can't speak for other CAs, our team regularly reads MDSP but also checks the Issues list on Github (albeit less frequently) to stay on top of potential policy changes. So I'd say as long as potential policy changes are discussed (or at the very least, mentioned) on MDSP, we don't need a corresponding Github issue to be aware. Having reviewed the Browser Alignment ballot in more detail, I have several concerns, but in the spirit of progressing the conversation forward in the CAB Forum, I'll raise them there. Thanks, Corey > -Original Message- > From: dev-security-policy > On Behalf Of Kathleen Wilson via dev-security-policy > Sent: Friday, May 1, 2020 1:29 PM > To: mozilla-dev-security-pol...@lists.mozilla.org > Subject: Re: DRAFT May 2020 CA Communication/Survey > > On 5/1/20 9:48 AM, Corey Bonnell wrote: > > Hi Kathleen, > > Thank you for sending out this notification of the draft survey. I have > > briefly > reviewed and would like to ask what is the intent of Item 4 and the > associated sub-items? The Browser Alignment draft ballot is under discussion > in the CAB Forum, so the intent behind the shift of the location of > discourse > to the Mozilla forum is unclear. > > > > Thanks, > > Corey > > > > Hi Corey, > > We do not intend to shift the location of the discourse. > > The intent of Item 4 and the associated sub-items in our survey is to help > Mozilla with the specific questions/concerns that we have about the ballot, > so that we can use input from CAs in our program to recommend changes to > the draft. It is relatively easy to tack our questions about this draft > ballot onto > our CA Communication/survey, and the results will give us the data we are > currently lacking. > > Currently some of my concerns about the draft of the ballot have no data > behind them. While I think it is good to add many of those items in the > ballot > to the BRs, I am concerned about the effective dates of "immediately" or > "Sept 1". I don't want to end up with a bunch of cert revocations caused by > effective dates that should have been changed while the ballot was in draft > form. I also don't want to see the entire ballot fail just because we didn't > have the data to reasonably update the draft of the ballot. > > Note: There are some items in the ballot that we (Mozilla) might request be > removed, but that input will be provided by Mozilla's CABF representatives > (Ben and Wayne) directly into the CABF discussion forum. > > I will greatly appreciate your thoughts on how to better ask the questions > in > item 4 of our survey, to clarify our intent, and be able to get the data > that we > seek. > > Thanks, > Kathleen > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://scanmail.trustwave.com/?c=4062=zdys3gH7zHjY6V2sYd- > 9JR90haa22ypk0rHi9NROwQ=5=https%3a%2f%2flists%2emozilla%2eorg > %2flistinfo%2fdev-security-policy smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DRAFT May 2020 CA Communication/Survey
El domingo, 3 de mayo de 2020, 21:05:05 (UTC+2), Ryan Sleevi escribió: > Pedro, > > Did you mean Section 3, not Section 4? > Yes, my bad... My comment was indeed related to section 3 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DRAFT May 2020 CA Communication/Survey
Pedro, Did you mean Section 3, not Section 4? Section 4 does not talk about certificate lifetimes at all, but covers similar long-standing requirements imposed by other root programs directly. Naturally, the CA Communications doesn't cover the many existing Mozilla requirements that are also part of the ballot, and have never been covered by versions of the BRs, in a manner similar to the change in lifetime, and only seems to focus on the requirements either implicit to Mozilla or explicit in other programs. On Sun, May 3, 2020 at 7:58 AM Pedro Fuentes via dev-security-policy wrote: > > Hello, > this commentary it's quite obvious and probably unnecessary, but I would just > say that the controversy that section 4 of the survey is raising is simply > because many of us have the feeling that this change of certificate lifespan > should have come by means of a ballot and a new version of the BR, and not in > the way it's happening, with imposed deadlines. > Best, > Pedro > > El jueves, 30 de abril de 2020, 0:48:08 (UTC+2), Kathleen Wilson escribió: > > All, > > > > I have drafted a potential CA Communication and survey, and will greatly > > appreciate your input on it. > > > > https://wiki.mozilla.org/CA/Communications#May_2020_CA_Communication > > > > Direct link to read-only copy of the draft survey: > > https://ccadb-public.secure.force.com/mozillacommunications/CACommunicationSurveySample?CACommunicationId=a051J42AUSv > > > > Purpose: > > - Communicate Mozilla's expectations about what CAs should do when > > audits, revocations, or other requirements are impacted by COVID-19 > > restrictions. > > - Remind CAs about deadlines in version 2.7 of Mozilla’s Root Store Policy. > > - Collect CA input on limiting TLS cert lifetimes. > > - Collect CA input on the draft CA/Browser Forum Browser Alignment Ballot. > > > > 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
Re: DRAFT May 2020 CA Communication/Survey
Hello, this commentary it's quite obvious and probably unnecessary, but I would just say that the controversy that section 4 of the survey is raising is simply because many of us have the feeling that this change of certificate lifespan should have come by means of a ballot and a new version of the BR, and not in the way it's happening, with imposed deadlines. Best, Pedro El jueves, 30 de abril de 2020, 0:48:08 (UTC+2), Kathleen Wilson escribió: > All, > > I have drafted a potential CA Communication and survey, and will greatly > appreciate your input on it. > > https://wiki.mozilla.org/CA/Communications#May_2020_CA_Communication > > Direct link to read-only copy of the draft survey: > https://ccadb-public.secure.force.com/mozillacommunications/CACommunicationSurveySample?CACommunicationId=a051J42AUSv > > Purpose: > - Communicate Mozilla's expectations about what CAs should do when > audits, revocations, or other requirements are impacted by COVID-19 > restrictions. > - Remind CAs about deadlines in version 2.7 of Mozilla’s Root Store Policy. > - Collect CA input on limiting TLS cert lifetimes. > - Collect CA input on the draft CA/Browser Forum Browser Alignment Ballot. > > Thanks, > Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DRAFT May 2020 CA Communication/Survey
On Fri, May 01, 2020 at 04:48:28PM +, Corey Bonnell via dev-security-policy wrote: > I have briefly reviewed and would like to ask what is the intent of Item 4 > and the associated sub-items? The Browser Alignment draft ballot is under > discussion in the CAB Forum, so the intent behind the shift of the > location of discourse to the Mozilla forum is unclear. I also had a similar "hmm, that seems odd" reaction to point 4 of the draft CA communication. At first glance, it does seem somewhat redundant to ask CAs to tell Mozilla about their concerns rather than tell the CA/B Forum directly. However, when I reflected on it at some length, I came to the conclusion that it is a good thing for Mozilla to survey the CAs in its root program in this manner, for several reasons: 1. It is my understanding that not all CAs in Mozilla's root store are members of the CA/B Forum. You could wonder why that is, you can even think that those CAs that aren't members of the Forum are being various forms of irresponsible, however the fact remains, and Mozilla reaching out to gather the opinions of all CAs in its root store helps to surface the opinions of those CAs that do not have a voice in the CA/B Forum directly. 2. There are multiple examples of CA members of the CA/B Forum failing to express their objections to a ballot until the voting period, which has on at least one occasion let to the failure of a ballot. As there is no mechanism within the CA/B Forum to "force" members to express their objections to a draft ballot in a timely manner, it seems likely that this will occur again in the future. Mozilla's CA communication and survey, being mandatory for all CAs in Mozilla's trust store to complete, requires those CAs to carefully consider the issues and voice their objections, which reduces the chances of objectionable draft ballots making it to the voting stage only to fail at that hurdle. Thus, despite having initial reservations about Mozilla's action here, I've come to the conclusion that it is a Good Thing(TM) that Mozilla is doing this, and it can only be to the benefit of Mozilla, relying parties, and the Web PKI for Section 4 of the draft May CA Communication to go out to CAs as-is. - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DRAFT May 2020 CA Communication/Survey
On 5/1/20 10:18 AM, Corey Bonnell wrote: I agree that the intent of item 3 is clear, given the previous discussion on the topic [1]. However, there is no corresponding discussion on the Mozilla list (nor any Github issues [2]) for item 4 and the associated sub-items, which is why I asked for clarification on intent. Thanks, Corey Do you think it would be useful for me to file issues in GitHub for each of those requirements in the draft ballot and label them for consideration in v2.7.1 of Mozilla's Root Store Policy? Such issues could be closed without discussion in m.d.s.p if the CABF ballot includes them and passes. I see pros and cons about doing this (filing the Github issues), but am not opposed to it if you think it would help. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DRAFT May 2020 CA Communication/Survey
On 5/1/20 9:48 AM, Corey Bonnell wrote: Hi Kathleen, Thank you for sending out this notification of the draft survey. I have briefly reviewed and would like to ask what is the intent of Item 4 and the associated sub-items? The Browser Alignment draft ballot is under discussion in the CAB Forum, so the intent behind the shift of the location of discourse to the Mozilla forum is unclear. Thanks, Corey Hi Corey, We do not intend to shift the location of the discourse. The intent of Item 4 and the associated sub-items in our survey is to help Mozilla with the specific questions/concerns that we have about the ballot, so that we can use input from CAs in our program to recommend changes to the draft. It is relatively easy to tack our questions about this draft ballot onto our CA Communication/survey, and the results will give us the data we are currently lacking. Currently some of my concerns about the draft of the ballot have no data behind them. While I think it is good to add many of those items in the ballot to the BRs, I am concerned about the effective dates of "immediately" or "Sept 1". I don't want to end up with a bunch of cert revocations caused by effective dates that should have been changed while the ballot was in draft form. I also don't want to see the entire ballot fail just because we didn't have the data to reasonably update the draft of the ballot. Note: There are some items in the ballot that we (Mozilla) might request be removed, but that input will be provided by Mozilla's CABF representatives (Ben and Wayne) directly into the CABF discussion forum. I will greatly appreciate your thoughts on how to better ask the questions in item 4 of our survey, to clarify our intent, and be able to get the data that we seek. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: DRAFT May 2020 CA Communication/Survey
> Not Kathleen here, but it seems to make sense to me, for the same reason > Item 3 makes sense. That is, in Item 3, Apple's deployed a policy, and > there's > a question about if/when Mozilla should do the same. Item 4 seems similar - > 4.1 is a Microsoft requirement, 4.2 is an existing Mozilla implementation > requirement (and RFC 5280 requirement), 4.3 is moving a CCADB SHOULD to > a MUST, and 4.4 is a Microsoft requirement. I agree that the intent of item 3 is clear, given the previous discussion on the topic [1]. However, there is no corresponding discussion on the Mozilla list (nor any Github issues [2]) for item 4 and the associated sub-items, which is why I asked for clarification on intent. Thanks, Corey [1] https://groups.google.com/d/msg/mozilla.dev.security.policy/mz1buYdIy-I/oo9zHBADAQAJ [2] https://github.com/mozilla/pkipolicy/issues smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DRAFT May 2020 CA Communication/Survey
On Fri, May 1, 2020 at 12:48 PM Corey Bonnell via dev-security-policy wrote: > > Hi Kathleen, > Thank you for sending out this notification of the draft survey. I have > briefly reviewed and would like to ask what is the intent of Item 4 and the > associated sub-items? The Browser Alignment draft ballot is under discussion > in the CAB Forum, so the intent behind the shift of the location of discourse > to the Mozilla forum is unclear. Not Kathleen here, but it seems to make sense to me, for the same reason Item 3 makes sense. That is, in Item 3, Apple's deployed a policy, and there's a question about if/when Mozilla should do the same. Item 4 seems similar - 4.1 is a Microsoft requirement, 4.2 is an existing Mozilla implementation requirement (and RFC 5280 requirement), 4.3 is moving a CCADB SHOULD to a MUST, and 4.4 is a Microsoft requirement. Discussion in the CA/Browser Forum is very useful, although to date, no CA has raised any concerns or discussion despite the multiple attempts to get feedback, so it's also useful to have a CA communication that can encourage feedback, both as Mozilla looks at possibly adding them to policy (similar to the longstanding requirements in Microsoft's policy) as well as the CA/B Forum looks at adding them to the BRs. How would/should Mozilla gather feedback about potential changes to its Policies, directly or indirectly (e.g. the BRs), if not a CA communication? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: DRAFT May 2020 CA Communication/Survey
Hi Kathleen, Thank you for sending out this notification of the draft survey. I have briefly reviewed and would like to ask what is the intent of Item 4 and the associated sub-items? The Browser Alignment draft ballot is under discussion in the CAB Forum, so the intent behind the shift of the location of discourse to the Mozilla forum is unclear. Thanks, Corey > -Original Message- > From: dev-security-policy > On Behalf Of Kathleen Wilson via dev-security-policy > Sent: Wednesday, April 29, 2020 6:48 PM > To: mozilla-dev-security-pol...@lists.mozilla.org > Subject: DRAFT May 2020 CA Communication/Survey > > All, > > I have drafted a potential CA Communication and survey, and will greatly > appreciate your input on it. > > https://scanmail.trustwave.com/?c=4062=poSq3knT0jDipj1ZCEWVbMkhC > nQ3VJAVJJ3kKSAxrA=5=https%3a%2f%2fwiki%2emozilla%2eorg%2fCA > %2fCommunications%23May%5f2020%5fCA%5fCommunication > > Direct link to read-only copy of the draft survey: > https://scanmail.trustwave.com/?c=4062=poSq3knT0jDipj1ZCEWVbMkhC > nQ3VJAVJMvteHcxrw=5=https%3a%2f%2fccadb- > public%2esecure%2eforce%2ecom%2fmozillacommunications%2fCACommu > nicationSurveySample%3fCACommunicationId%3da051J42AUSv > > Purpose: > - Communicate Mozilla's expectations about what CAs should do when > audits, revocations, or other requirements are impacted by COVID-19 > restrictions. > - Remind CAs about deadlines in version 2.7 of Mozilla’s Root Store Policy. > - Collect CA input on limiting TLS cert lifetimes. > - Collect CA input on the draft CA/Browser Forum Browser Alignment Ballot. > > Thanks, > Kathleen > > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://scanmail.trustwave.com/?c=4062=poSq3knT0jDipj1ZCEWVbMkhC > nQ3VJAVJJ22fyY7pg=5=https%3a%2f%2flists%2emozilla%2eorg%2flistin > fo%2fdev-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
