[cabfpub] Browser implementation of cert requirements

[Ryan Sleevi]

On Fri, Mar 2, 2018 at 2:05 PM, Peter Bowen via Public <public at cabforum.org>
wrote:

> I’m working on updating cablint to make sure it has checks that match
> browser checks.  These will be INFO level items if they don’t align with
> the BRs, but I think having them is valuable.
>
> I’m hoping that the browsers can confirm a couple of things, so I get it
> right in cablint:
>
> 1) Safari and Chrome both require that the server send CT information for
> the certificate in order to get EV treatment.  There is no date based
> selector for this (this rule has been in effect longer than the maximum
> validity period of an EV cert).
>

To be considered an EV cert, yes. I would distinguish that from any UI
treatment, even if others don't :)

2) Chrome will require that the server send CT information for certificates
> that have notBefore >= 2018-05-01T00:00:00Z in order to not get an
> interstitial
>
> 3) Chrome will present an interstitial for any certificate with notBefore
> >= 2018-03-01T00:00:00Z where the delta between notBefore and NotAfter is
> greater than 71,280,000 seconds (825 days of 24 hours of 60 minutes of 60
> seconds).
>
> Are these correct?
>

Yes. Chrome views the notBefore as a statement of when the certificate was
issued, and expects it to comply with all applicable rules as of that date.

This means that forward-dating certificates, an inherently
misrepresentation of issuance, is a statement that the CA is complying with
all rules at the time of notBefore and that the information is wholly
correct at the time of notBefore (a misrepresentation, because CAs do not
know the future).

Further enforcement of validity period notes:

For validity dates based on months, Chrome extracts the Year, Month, and
Day based on the certificate's Not Before and Not After. The number of
months is calculated by taking the difference in years (expiry - issuance),
multiplying by 12, and adding the difference in months (which may be
negative - for example, an expiration in March in one year, with an
issuance in December the year prior). If the day of the expiration is
greater than the day of issuance, an additional month is added.

If the certificate was issued before 2012-07-01 and is valid for more than
120 months, or valid after 2019-07-01, it will not be trusted. I anticipate
we will soon fully remove support for these certificates in a future
release of Chrome.
If the certificate was issued on-or-after 2012-07-01, and valid for more
than 60 months, it will not be trusted.
If the certificate was issued on-or-after 2015-04-01, and valid for more
than 39 months, it will not be trusted.
If the certificate was issued on-or-after 2018-03-01, and the difference
between the validity end and the issuance date is greater than 71,280,000
seconds, it will not be trusted.


For calculating whether or not a certificate complies with CT policy:
Chrome extracts the Year, Month, and Day based on the certificate's Not
Before and Not After. The number of months is calculated by taking the
difference in years (expiring - issuance), multiplying by 12, and adding
the difference in months (which may be negative). If the day of the
expiration is greater than the day of issuance, an additional month is
added.

The number of SCTs required is then determined based on
https://github.com/chromium/ct-policy/blob/master/ct_policy.md

This means that a certificate issued for exactly 825 days will require 4
SCTs, not 3, as it is valid for 28 months. The longest possible validity
period to comply with 27 months is 366 days + 365 days + 31 days + 31 days
+ 30 days, or 823 days.
There are no plans at this time to change this requirement.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20180302/a16c9d33/attachment-0003.html>