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"
<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
_______________________________________________
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 are not permitted to use, copy, or forward it,
in whole or in part without the express consent of the sender. Please
notify the sender by reply email, disregard the foregoing messages, and
delete it immediately.
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
