On Sun, Apr 22, 2018 at 5:01 PM, Rob Stradling <[email protected]> wrote:
> On 22/04/18 21:04, Eric Mill via dev-security-policy wrote: > >> On Fri, Apr 20, 2018 at 9:30 AM, Tim Shirley via dev-security-policy < >> [email protected]> wrote: >> >> First of all, it's important to distinguish between the BR r >>> 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 just going to double down on Matt's comment that the problem here >> doesn't seem to be in strictness of enforcement, but rather CAs leaving >> themselves no buffer zone. >> > > The problem here, IMHO, is that the BR requirement was poorly written. > > Whatever business advantage there is of giving >> customers that one last day to get 3-year certs, seems likely not as >> valuable as the certainty of avoiding giving those customers errors when >> the certs are used in major browsers. >> > > The certainty? Hindsight is a wonderful thing. When I wrote Comodo CA's > code to enforce the "after 1 March 2018" rule, this "certainty" did no > occur to me. I simply read the BR requirement and then implemented code to > enforce it. Yeah, I completely get how that would happen. I would just think this is a good learning opportunity to protect against ambiguously written text by giving a day's buffer. Tim's time zone example is another good reason to give that buffer, even if the BR language made it clear whether it was > or >=. A tangentially similar comparison would be that in other systems I've built that structure search results and push notifications around dates, the only safe way to do it is to assign times as 12:00 UTC, even if that doesn't really accurately describe the time something happened, so that no matter what time zone someone is in, they're guaranteed to see it as the same day. It's worth the imprecision to create consistency. > > > -- Eric >> >> >> >>> On 4/19/18, 10:10 PM, "dev-security-policy on behalf of Simone Carletti >>> via dev-security-policy" <dev-security-policy-bounces+tshirley= >>> [email protected] on behalf of dev-security-policy@lists. >>> mozilla.org> 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 >>> >> > -- > Rob Stradling > Senior Research & Development Scientist > Email: [email protected] > -- konklone.com | @konklone <https://twitter.com/konklone> _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
