Re: Clarification about Ballot 193 and validity of a certificate issued on March 1st
On Fri, Apr 20, 2018 at 01:30:49PM +, Tim Shirley via dev-security-policy wrote: > This is why I'm not a fan of such precise enforcements of date-related > compliance. There are a lot of different ways to interpret dates/times, > but none of the readings materially change the net effect of the rule. > That is, all readings change the max validity period to ~825 days (which > itself is subject to debate as to its precise meaning in terms of seconds) > within a day or two of each other. So, enforcing the date as Mar 1 as > opposed to Mar 2 doesn't seem to add a lot of value and leads to confusion > like this. Same thing goes the other way, though -- CAs trying to skate too close to the line to extract maximum "value" out of the old rules also doesn't add a lot of value, and leads to confusion like this. If the CA had decided to not issue certificates over 825 days after, say, Feb 25, there wouldn't have been any confusion either. Exact same reasoning applies to bumping up against the ambiguity of the 825 day limit -- if a CA wants to avoid any possibility of confusion, they can just be conservative in what they send, and not issue certificates over, say, 820 days in length. Live life on the edge, and you're going to fall off now and then. - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.6 Proposal: Require separate intermediates for different usages (e.g. server auth, S/MIME)
On Thu, Apr 19, 2018 at 8:40 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 17/04/2018 20:24, Wayne Thayer wrote: > >> This proposal is to require intermediate certificates to be dedicated to >> specific purposes by EKU. Beginning at some future date, all newly created >> intermediate certificates containing either the id-kp-serverAuth or >> id-kp-emailProtection EKUs would be required to contain only a single EKU. >> >> Arguments for this requirement are that it reduces risk of an incident in >> which one type of certificate affecting another type, and it could allow >> some policies to be restricted to specific types of certificates. >> >> > One case that needs to be considered is specifying a set of closely > related EKUs, which are desirable to include in the same end entity > certificate. A typical combination would be emailProtection and > clientAuth, for the same identity in the EE cert. > > I believe the language I proposed takes care of this: https://github.com/mozilla/pkipolicy/commit/1ccf31557932ede045f3c2d7bcdac533c5176f18 If there are no additional comments, I will consider this issue to be resolved and will include this change in version 2.6 of the policy. - Wayne ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.6 Proposal: Add prohibition on CA key generation to policy
On Tue, Apr 17, 2018 at 6:10 AM, Buschart, Rufus via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > I believe the wording "insecure electronic channels" leaves a lot of space > for interpretation. In corporate PKIs for email encryption it is quite > common to transfer centrally generated email encryption p12-files to mobile > device management systems, email encryption gateways or directly to mobile > devices using a wide variety of 'electronic channels'. From the proposed > wording it doesn't seem to be clear which of those channels are 'insecure' > and which not. Even if not that common, the same applies for email > signature p12-files for e.g. email signature on mail gateways or mobile > devices. Most of the mobile devices out in the field neither support > hardware token, key-pair-generation in the mailer software nor installation > of downloaded p12-files (prohibited by app sandboxing). > > Maybe it would be possible to restrict the new wording to the EKU > kp-ServerAuth first and have a detailed discussion about email-encryption > and user authentication with more interested parties in the next months? > Again, this is not new wording. It's already a requirement: https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Distributing_Generated_Private_Keys_in_PKCS.2312_Files Having said that, could we instead be more specific by replacing "insecure electronic channels" with "unencrypted email"? Limiting the scope of this statement to id-kp-serverAuth is meaningless since we forbid CA key generation for server certificates. - Wayne ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.6 Proposal: Require CAs to support problem reports via email
At this point we have a few choices: 1. Do nothing about requiring email as a problem reporting mechanism. Instead, take on the related issues of disclosure of the reporting mechanism and receipt confirmation in Mozilla policy, via the CAB Forum, or both. 2. Go ahead with the proposal to require email, but allow CAs to require some special, but standardized identifier be placed in the message that they can filter on. For example, CAs could ignore messages sent to their problem reporting address unless the subject contains the phrase "problem report". 3. Develop some new problem reporting mechanism that solves the problems with email and forms. For example, we could require CAs to accept problem reports posted to this list, but build in some additional time in which to "receive" the report by reading list messages. Or we could require CAs to accept problem reports via Bugzilla. We already see problems being reported via these mechanisms and require CAs to monitor both of them, just not on a 24x7 basis. The first option ('do nothing') is currently in the lead, so I would especially like to hear from anyone who wants to argue for a different solution. - Wayne ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Clarification about Ballot 193 and validity of a certificate issued on March 1st
On Friday, April 20, 2018 at 9:31:32 AM UTC-4, Tim Shirley wrote: > First of all, it's important to distinguish between the BR requirement, which > is defined in terms of certificate *issuance* dates, and the value in the > "Not Before" field. I'm guessing the "Not Before" value in this certificate > is not the actual issuance timestamp, since it's unlikely it was issued right > at the stroke of midnight. The CA is probably rounding, but we don't know if > they're rounding up or down. But it would only be mis-issuance if the > issuance occurred outside of the allowed time window. There's nothing I can > see to show when the certificate was actually issued; it first showed up in > CT logs on March 13, so we know it was issued on or before that, but that's > all we know for sure about the issuance time. > > So what is the allowed time window according to the BRs? I'd argue that the > intent was that it be >=. If you read the first bullet's "after" as >, then > you have to also read the second bullet's "prior to" as <. So what rule > applies to certificates issued ON March 1, 2018? Apparently none. Certainly > that wasn't the intent, which is why I interpret the requirement as >=. That > is, the dividing line is the moment in time when we moved from February into > March, such that one rule or the other is always in effect. I agree, it was not the intent, nor is it consistent with the other modifications in 193 ( https://cabforum.org/2017/03/17/ballot-193-825-day-certificate-lifetimes/ ). > But even if you accept my premise there, then you have to ask "in what > timezone?" March 1 00:00:00 2018 GMT in North America is February 28. So I > could see someone making the argument that issuance at that moment in time is > fine if the CA is in North America but it's mis-issuance if the CA is in > Europe, since the requirements don't state that the measurement is UTC. This > is why I'm not a fan of such precise enforcements of date-related compliance. > There are a lot of different ways to interpret dates/times, but none of the > readings materially change the net effect of the rule. That is, all readings > change the max validity period to ~825 days (which itself is subject to > debate as to its precise meaning in terms of seconds) within a day or two of > each other. So, enforcing the date as Mar 1 as opposed to Mar 2 doesn't seem > to add a lot of value and leads to confusion like this. I'm curious how auditors would view this, since I think this says that's all that matters. >From the client side, we continue to take the most restrictive interpretation >that is reasonable, and thus in Chrome, any certificate whose notBefore is >= >2018-03-01 00:00:00 UTC and whose difference (in days measured as 60*60*24 >seconds) is greater than 825 days from the notAfter is rejected. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Clarification about Ballot 193 and validity of a certificate issued on March 1st
On 20/04/18 14:30, Tim Shirley via dev-security-policy wrote: First of all, it's important to distinguish between the BR requirement, which is defined in terms of certificate *issuance* dates, and the value in the "Not Before" field. I'm guessing the "Not Before" value in this certificate is not the actual issuance timestamp, since it's unlikely it was issued right at the stroke of midnight. The CA is probably rounding, but we don't know if they're rounding up or down. But it would only be mis-issuance if the issuance occurred outside of the allowed time window. There's nothing I can see to show when the certificate was actually issued; it first showed up in CT logs on March 13, so we know it was issued on or before that, but that's all we know for sure about the issuance time. So what is the allowed time window according to the BRs? I'd argue that the intent was that it be >=. If you read the first bullet's "after" as >, then you have to also read the second bullet's "prior to" as <. So what rule applies to certificates issued ON March 1, 2018? Apparently none. Certainly that wasn't the intent, which is why I interpret the requirement as >=. Indeed, I'm sure that wasn't the intent. However, if the BRs don't say what the BRs intend to say, then the fault is with the BRs rather than with the CA that adheres to what the BRs actually say. What the BRs actually say is what matters, because that's what auditors will audit against. "after" is not the same thing as "on or after". "on or after" is used elsewhere in the document to me >=, so TBH I think that reading "after" as > is the only correct interpretation. BTW, over in linting-land, we've already had this same discussion... https://github.com/awslabs/certlint/pull/58 https://github.com/zmap/zlint/pull/195 That is, the dividing line is the moment in time when we moved from February into March, such that one rule or the other is always in effect. But even if you accept my premise there, then you have to ask "in what timezone?" March 1 00:00:00 2018 GMT in North America is February 28. So I could see someone making the argument that issuance at that moment in time is fine if the CA is in North America but it's mis-issuance if the CA is in Europe, since the requirements don't state that the measurement is UTC. This is why I'm not a fan of such precise enforcements of date-related compliance. There are a lot of different ways to interpret dates/times, but none of the readings materially change the net effect of the rule. That is, all readings change the max validity period to ~825 days (which itself is subject to debate as to its precise meaning in terms of seconds) within a day or two of each other. So, enforcing the date as Mar 1 as opposed to Mar 2 doesn't seem to add a lot of value and leads to confusion like this. On 4/19/18, 10:10 PM, "dev-security-policy on behalf of Simone Carletti via dev-security-policy" wrote: Hello, I'm investigating an issue on behalf of a customer. Our customer requested a multi-year certificate that was issued on March 1st by Comodo. Here's the certificate: https://crt.sh?id=354042595 Validity Not Before: Mar 1 00:00:00 2018 GMT Not After : May 29 23:59:59 2021 GMT The certificate is currently considered invalid at least by Google Chrome. It's my understanding that Google Chrome uses a >= comparison, which effectively means certificates issued on March 1st are already subject to Ballot 193. However, it looks like the interpretation of Comodo of Ballot 193 here is based on a > comparison, since the certificate was issued with a 3y validity. BR 6.3.2 says: > Subscriber Certificates issued after 1 March 2018 MUST have a Validity Period no greater than 825 days. > Subscriber Certificates issued after 1 July 2016 but prior to 1 March 2018 MUST have a Validity Period no greater than 39 months. I'd appreciate some hints about whether a certificate issued on March 1st should be considered subject to Ballot 193 or not. Best, -- Simone ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://scanmail.trustwave.com/?c=4062&d=p8zZ2rF2lZEEgQKoVUUviom_gMvUa93578dYFlK0UQ&s=5&u=https%3a%2f%2flists%2emozilla%2eorg%2flistinfo%2fdev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy -- Rob Stradling Senior Research & Development Scientist Email: r...@comodoca.com Bradford, UK Office: +441274730505 ComodoCA.com This message and any files associated with it may contain legally privileged, confidential, or proprietary information. If you are not the intended recipient, you
Re: Clarification about Ballot 193 and validity of a certificate issued on March 1st
First of all, it's important to distinguish between the BR requirement, which is defined in terms of certificate *issuance* dates, and the value in the "Not Before" field. I'm guessing the "Not Before" value in this certificate is not the actual issuance timestamp, since it's unlikely it was issued right at the stroke of midnight. The CA is probably rounding, but we don't know if they're rounding up or down. But it would only be mis-issuance if the issuance occurred outside of the allowed time window. There's nothing I can see to show when the certificate was actually issued; it first showed up in CT logs on March 13, so we know it was issued on or before that, but that's all we know for sure about the issuance time. So what is the allowed time window according to the BRs? I'd argue that the intent was that it be >=. If you read the first bullet's "after" as >, then you have to also read the second bullet's "prior to" as <. So what rule applies to certificates issued ON March 1, 2018? Apparently none. Certainly that wasn't the intent, which is why I interpret the requirement as >=. That is, the dividing line is the moment in time when we moved from February into March, such that one rule or the other is always in effect. But even if you accept my premise there, then you have to ask "in what timezone?" March 1 00:00:00 2018 GMT in North America is February 28. So I could see someone making the argument that issuance at that moment in time is fine if the CA is in North America but it's mis-issuance if the CA is in Europe, since the requirements don't state that the measurement is UTC. This is why I'm not a fan of such precise enforcements of date-related compliance. There are a lot of different ways to interpret dates/times, but none of the readings materially change the net effect of the rule. That is, all readings change the max validity period to ~825 days (which itself is subject to debate as to its precise meaning in terms of seconds) within a day or two of each other. So, enforcing the date as Mar 1 as opposed to Mar 2 doesn't seem to add a lot of value and leads to confusion like this. On 4/19/18, 10:10 PM, "dev-security-policy on behalf of Simone Carletti via dev-security-policy" wrote: Hello, I'm investigating an issue on behalf of a customer. Our customer requested a multi-year certificate that was issued on March 1st by Comodo. Here's the certificate: https://crt.sh?id=354042595 Validity Not Before: Mar 1 00:00:00 2018 GMT Not After : May 29 23:59:59 2021 GMT The certificate is currently considered invalid at least by Google Chrome. It's my understanding that Google Chrome uses a >= comparison, which effectively means certificates issued on March 1st are already subject to Ballot 193. However, it looks like the interpretation of Comodo of Ballot 193 here is based on a > comparison, since the certificate was issued with a 3y validity. BR 6.3.2 says: > Subscriber Certificates issued after 1 March 2018 MUST have a Validity Period no greater than 825 days. > Subscriber Certificates issued after 1 July 2016 but prior to 1 March 2018 MUST have a Validity Period no greater than 39 months. I'd appreciate some hints about whether a certificate issued on March 1st should be considered subject to Ballot 193 or not. Best, -- Simone ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://scanmail.trustwave.com/?c=4062&d=p8zZ2rF2lZEEgQKoVUUviom_gMvUa93578dYFlK0UQ&s=5&u=https%3a%2f%2flists%2emozilla%2eorg%2flistinfo%2fdev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy