> 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.
I absolutely agree Eric, and this is the primary reason I'm sharing this issue here. I am playing the role of a CA and Browser user here, speaking on behalf of our customer. Our customer is the party that eventually is affected by this misunderstanding. We placed a request with Comodo to get this certificate order refunded and place a new order (as it stands today it's unusable and I assume we can't reissue it with a 3 years length at this point). I'm confident that we'll sort this out, but I wanted to bring up this issue to encourage less ambiguous wording in the future. -- Simone On Sun, Apr 22, 2018 at 2:10 PM, Eric Mill <e...@konklone.com> wrote: > > > On Sun, Apr 22, 2018 at 5:01 PM, Rob Stradling <r...@comodoca.com> 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 < >>> dev-security-policy@lists.mozilla.org> 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= >>>> trustwave....@lists.mozilla.org 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: r...@comodoca.com >> > > > > -- > konklone.com | @konklone <https://twitter.com/konklone> > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
