Re: Drafting Q1 2016 CA Communication
On 03/15/16 22:43, kwil...@mozilla.com wrote: > On Monday, March 14, 2016 at 5:28:32 PM UTC-7, Charles Reiss wrote: >>> ACTION #1a: As previously communicated, CAs should no longer be >>> issuing SHA-1 certificates chaining up to root certificates >>> included in Mozilla's CA Certificate Program. Check your systems >>> and those of your subordinate CAs to ensure that SHA-1 >>> certificates chaining up to your included root certificates are >>> no longer being issued. Please enter the last date that a SHA-1 >>> certificate was issued that chained up to your root >>> certificate(s) included in Mozilla's program. (Required) >> >> Mozilla should make clear how this question should be answered >> with respect to issuance of: a) SHA-1 subCAs which are constrained >> by EKU to not issue TLS server or email certs (e.g. for code >> signing); b) SHA-1 end-entity certificates which are constrained by >> EKU to not be for TLS servers or email certs but whose issuing >> subCA is not so constrained; c) SHA-1 end-entity certificates which >> are not constrained by EKU but lack a common name or SAN which can >> be used a server name or email address; and d) SHA-1 end-entity >> certificates whose parent CA is constrained by EKU to not be for >> TLS server or email certs; >> >> The question as written would seem to me to apply to all of these >> (since "SHA-1 certificates chaining up to your included root >> certificates" is not qualified), but it seems, from inclusion >> request discussion, that CAs tend to think that "out of scope" >> certificates need not be mentioned. >> > > Does the following text clear it up? > > ACTION #1a: As previously communicated, CAs should no longer be > issuing SHA-1 certificates chaining up to root certificates included > in Mozilla's CA Certificate Program. This includes TLS/SSL and S/MIME > certificates, as well as any intermediate certificates that they > chain up to. Check your systems and those of your subordinate CAs to > ensure that SHA-1 based TLS/SSL and S/MIME certificates chaining up > to your included root certificates are no longer being issued. Please > enter the last date that a SHA-1 based TLS/SSL certificate was issued > that chained up to your root certificates included in Mozilla's > program. (Required) For reasons discussed in thread on BR scope here (that restrictions from certificate contents won't be effective against a chosen-prefix collision attack), I was hoping that Mozilla would ask whether CAs would continue issuing any SHA-1 certificates, regardless of suitability for TLS or S/MIME (except those that chain through technically constrained subCAs issued before 2016). But perhaps that needs to be done in context of more expansive improvements to Mozilla's policies. >> [snip] >>> ACTION #6: All certificates that directly or transitively chain >>> to your root certificate(s) included in Mozilla's CA Certificate >>> Program must comply with Mozilla's CA Certificate Policy. This >>> includes test certificates. >>> >>> Review your policies, procedures, and auditing about issuance of >>> test certificates, what domain names may be used in test >>> certificates, and the domain verification procedures that must be >>> followed for test certificates. >>> >>> [TBD] What else should we say here? -- What sort of responses to >>> we want from CAs? -- Rules about testing and test certs (per >>> Symantec incident) -- What sorts of things do we want to make >>> sure CAs do and don't do regarding testing? (Required) >> >> Maybe a reminder that test certificates Mozilla expects test >> certificates to follow the domain validation procedures in the >> CA's CP/CPS (that Mozilla presumably reviewed) and not just be >> issued in compliance with the BRs per se? > > > How about the following? This seems to address that. My suspicion is that CAs generally think their test certificates comply with Mozilla's policy in terms of certificate contents, so maybe that is not the right thing to emphasize? My guess is that the real problems are ad-hoc and/or unpublished policies for how compliance is to be achieved. I think this is clearly prohibited by Mozilla's policies (which, e.g., require CAs notify Mozilla when "its policies and business practices change in regards to verification procedures for issuing certificates"). > ACTION #6: All certificates that directly or transitively chain to > your root certificates included in Mozilla's CA Certificate Program > must comply with Mozilla's CA Certificate Policy. This includes test > certificates. > > Review your policies, procedures, and auditing about issuance of test > certificates, what domain names may be used in test certificates, and > the domain verification procedures that must be followed for test > certificates. (Required) > > [checkbox] I confirm that I understand that all TLS/SSL certificates > chaining up root certificates included in Mozilla's CA Certificate > Program, without exception, must conform to Mozilla's CA C
Re: Drafting Q1 2016 CA Communication
On 3/15/16 5:16 AM, Gervase Markham wrote: >> This survey requests a set of actions on your behalf, as a >> participant in Mozilla's CA Certificate Program by [DATE TBD]. > > In general, I think that dates should be set the same distance in the > future as previous CA communications. It seems that most CAs have not > had a problem complying with the previous timelines we have set. In the > past, we've given them 3 weeks to respond - that seems plenty. > > Some of the items have individual response deadlines, and there is a > master response deadline here at the top. If we have both, we need to be > clear on how they relate. > Updated. I've used April 22, 2016, as the date by which CAs must respond to the communication, assuming I get it sent by the end of March. > >> To respond to this survey, please login to the CA Community in >> Salesforce, click on the 'CA Communications (Page)' tab, and select >> the 'March 2016 CA Communication' survey. Please enter your initial >> response by [DATE TBD]. After that, you may update your responses >> until the survey Expiration Date of [TBD], by following these same >> steps. > > I don't think it's necessary to have different initial response and > final response dates. We should just have a response date, noting that > CAs can update their answers. > OK. Expiration date info removed. >> ACTION #1a: As previously communicated, CAs should no longer be >> issuing SHA-1 certificates chaining up to root certificates included >> in Mozilla's CA Certificate Program. Check your systems and those of >> your subordinate CAs to ensure that SHA-1 certificates chaining up to >> your included root certificates are no longer being issued. Please >> enter the last date that a SHA-1 certificate was issued that chained >> up to your root certificate(s) included in Mozilla's program. >> (Required) > > This is one overall date, not one date per root, right? Correct, one overall date. It now says: "... Please enter the last date that a SHA-1 based TLS/SSL certificate was issued that chained up to your root certificates included in Mozilla's program." OK? > >> ACTION #1b: Enter the date when all of the SHA-1 certificates that >> chain up to your root certificate(s) included in Mozilla's CA >> Certificate Program will either expire or be revoked. As previously >> communicated we plan to show the "Untrusted Connection" error >> whenever a SHA-1 certificate is encountered in Firefox after January >> 1, 2017. (Required) > > Again, this is one overall date, not one per root? Correct. It now says: "ACTION #1b: Enter the date when all of the SHA-1 based TLS/SSL certificates that chain up to your root certificates included in Mozilla's CA Certificate Program will either expire or be revoked. As previously communicated we plan to show the "Untrusted Connection" error whenever a SHA-1 certificate is encountered in Firefox after January 1, 2017. (Required)" OK? > >> ACTION #1c: Enter the date by which safeguards will be put into place >> that will prevent the future issuance of SHA-1 certificates that >> chain up to your root certificate(s) included in Mozilla's CA >> Certificate Program. If you have already completed this, then please >> enter the approximate date when those safeguards were completed. >> (Required) > > Are we requiring such safeguards? If not, then there needs to be a "not > implemented" option. If so, then we need to be clearer about explaining > where we promulgated that requirement. I am not aware of requirements about putting safeguards in place. How about if I delete action 1c, and add the following sentence to action 1b? "We recommend that you put safeguards into place that will prevent the future issuance of SHA-1 based TLS/SSL and S/MIME certificates and SHA-1 based intermediate certificates that chain up to your root certificates included in Mozilla's CA Certificate Program." > >> ACTION #5: Review the root certificates that you currently have >> included in Mozilla's CA Certificate Program, and let us know which >> of your root certificates may be removed, and when. > > I would say "whether any of them can now be removed or could be removed > in the next year and, if so, when." > Updated. Now it says: "ACTION #5: Review the root certificates that you currently have included in Mozilla's CA Certificate Program, and let us know whether any of them can now be removed or could be removed in the next year and, if so, when. For instance, if you have old root certificates that are being replaced by newer root certificates, indicate when you expect to finish migrating your customers to the new root certificates. Provide the Issuer Field and SHA-256 Fingerprint of each root certificate that may be removed, and the date when the root certificate may be removed. (Required)" >> Review your policies, procedures, and auditing about issuance of test >> certificates, what domain names may be used in test certificates, and >> the domain verification
Re: Drafting Q1 2016 CA Communication
On Monday, March 14, 2016 at 5:28:32 PM UTC-7, Charles Reiss wrote: > > ACTION #1a: As previously communicated, CAs should no longer be > > issuing SHA-1 certificates chaining up to root certificates included > > in Mozilla's CA Certificate Program. Check your systems and those of > > your subordinate CAs to ensure that SHA-1 certificates chaining up to > > your included root certificates are no longer being issued. Please > > enter the last date that a SHA-1 certificate was issued that chained > > up to your root certificate(s) included in Mozilla's program. > > (Required) > > Mozilla should make clear how this question should be answered with > respect to issuance of: > a) SHA-1 subCAs which are constrained by EKU to not issue TLS server or > email certs (e.g. for code signing); > b) SHA-1 end-entity certificates which are constrained by EKU to not be > for TLS servers or email certs but whose issuing subCA is not so > constrained; > c) SHA-1 end-entity certificates which are not constrained by EKU but > lack a common name or SAN which can be used a server name or email > address; and > d) SHA-1 end-entity certificates whose parent CA is constrained by EKU > to not be for TLS server or email certs; > > The question as written would seem to me to apply to all of these (since > "SHA-1 certificates chaining up to your included root certificates" is > not qualified), but it seems, from inclusion request discussion, that > CAs tend to think that "out of scope" certificates need not be mentioned. > Does the following text clear it up? ACTION #1a: As previously communicated, CAs should no longer be issuing SHA-1 certificates chaining up to root certificates included in Mozilla's CA Certificate Program. This includes TLS/SSL and S/MIME certificates, as well as any intermediate certificates that they chain up to. Check your systems and those of your subordinate CAs to ensure that SHA-1 based TLS/SSL and S/MIME certificates chaining up to your included root certificates are no longer being issued. Please enter the last date that a SHA-1 based TLS/SSL certificate was issued that chained up to your root certificates included in Mozilla's program. (Required) > [snip] > > ACTION #6: All certificates that directly or transitively chain to > > your root certificate(s) included in Mozilla's CA Certificate Program > > must comply with Mozilla's CA Certificate Policy. This includes test > > certificates. > > > > Review your policies, procedures, and auditing about issuance of test > > certificates, what domain names may be used in test certificates, and > > the domain verification procedures that must be followed for test > > certificates. > > > > [TBD] What else should we say here? -- What sort of responses to we > > want from CAs? -- Rules about testing and test certs (per Symantec > > incident) -- What sorts of things do we want to make sure CAs do and > > don't do regarding testing? (Required) > > Maybe a reminder that test certificates Mozilla expects test > certificates to follow the domain validation procedures in the CA's > CP/CPS (that Mozilla presumably reviewed) and not just be issued in > compliance with the BRs per se? How about the following? ACTION #6: All certificates that directly or transitively chain to your root certificates included in Mozilla's CA Certificate Program must comply with Mozilla's CA Certificate Policy. This includes test certificates. Review your policies, procedures, and auditing about issuance of test certificates, what domain names may be used in test certificates, and the domain verification procedures that must be followed for test certificates. (Required) [checkbox] I confirm that I understand that all TLS/SSL certificates chaining up root certificates included in Mozilla's CA Certificate Program, without exception, must conform to Mozilla's CA Certificate Policy and the domain validation procedures documented in our CP/CPS. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Drafting Q1 2016 CA Communication
On Monday, March 14, 2016 at 10:11:20 PM UTC-7, Eric Mill wrote: > > However, just for extra emphasis, it might be useful to work the phrase > "cross-signature" or similar into the paragraph, to make sure that CAs are > reminded to consider these when evaluating your action request. > > One way of doing this might be adding to the end of the first paragraph: > "This can include cross-signatures that create a chain to issuing > certificates owned by third parties, whether or not those issuing > certificates are already part of the Mozilla CA Certificate Program." > I added a sentence to the end of the first paragraph, as suggested: ~~ ACTION #2: Version 2.1 of Mozilla's CA Certificate Policy added the requirement that CAs must provide public-facing documentation about certificate verification requirements and annual public attestation of conformance to the stated certificate verification requirements for all certificates that are capable of being used to issue new certificates, and which directly or transitively chain to their certificate(s) included in Mozilla's CA Certificate Program that are not technically constrained as described in section 9 of Mozilla's CA Certificate Inclusion Policy. This includes cross-signed certificates that create a chain to issuing certificates owned by third parties, whether or not those issuing certificates are already part of Mozilla's CA Certificate Program. Respond with the date by which you plan to complete entry into Mozilla's CA Community in Salesforce of the PEM data, CP/CPS, and audit statements for all certificates that are capable of being used to issue new certificates, and which directly or transitively chain to your certificate(s) included in Mozilla's CA Certificate Program that are not technically constrained as described in section 9 of Mozilla's CA Certificate Inclusion Policy. This includes every intermediate certificate (chaining up to your root certificates in Mozilla's program with the Websites trust bit enabled) that is not Technically Constrained via Extended Key Usage and Name Constraint settings. The date that you enter must be on or before [DATE TBD]. (Required) ~~ Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
