Re: GlobalSign certificate with far-future notBefore

[bettyliew3329--- via dev-security-policy]

On Wednesday, 24 January 2018 06:55:55 UTC+8, Jonathan Rudenberg  wrote:
> A certificate issued by GlobalSign showed up in CT today with a notBefore 
> date of March 21, 2018 and a notAfter date of April 23, 2021, a validity 
> period of ~1129 days (more than three years).
> 
> https://crt.sh/?id=311477948=zlint
> 
> CA/B Forum ballot 193 modified the Baseline Requirements to set a maximum 
> validity period of 825 days for certificates issued after March 1, 2018.
> 
> While the BRs do not appear to have any rules about forward-dating 
> certificates, Mozilla’s CA Forbidden or Problematic Practices say:
> 
> > Certificates do not contain an issue timestamp, so it is not possible to be 
> > certain when they were issued. The notBefore date is the start of the 
> > certificate's validity range, and is set by the CA. It should be a 
> > reasonable reflection of the date on which the certificate was issued. 
> > Minor tweaking for technical compatibility reasons is accepted, but 
> > backdating certificates in order to avoid some deadline or code-enforced 
> > restriction is not.
> 
> https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Backdating_the_notBefore_Date
> 
> This incident makes me think that two changes should be made:
> 
> 1) The Root Store Policy should explicitly ban forward and back-dating the 
> notBefore date.
> 2) Firefox should implement a technical check to enforce the validity period 
> so that issuance practices like this do not impact users (see 
> https://bugzilla.mozilla.org/show_bug.cgi?id=908125)
> 
> Jonathan

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: GlobalSign certificate with far-future notBefore

[Gervase Markham via dev-security-policy]

On 24/01/18 18:02, Doug Beattie wrote:
> Can we consider this case closed with the action that the VWG will
> propose a ballot that addresses pre and postdating certificates?

Yes. I don't believe anyone has suggested that Globalsign broke a formal
rule, either in the BRs or Mozilla's requirements. Thank you for
engaging with us on this topic.

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: GlobalSign certificate with far-future notBefore

[Tim Hollebeek via dev-security-policy]

That's a good point, thank you.  I think I would lean towards making this
an end-entity only requirement until we've thought through the details
for other certificates.

We've been burned by this before (requirements for OCSP related certificates
were under-specified during the SHA1->SHA2 transition).

-Tim

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of Jakob
> Bohm via dev-security-policy
> Sent: Wednesday, January 24, 2018 12:11 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: GlobalSign certificate with far-future notBefore
> 
> Please also consider the practice of having an off-line CA (typically a
> root) pre-issue CRLs, OCSP responses, intermediary CAs and OCSP responder
> certificates for the period until the next root-key-usage ceremony.
> 
> This practice will naturally involve forward-dating of all of these items.
> 
> On 24/01/2018 19:03, Tim Hollebeek wrote:
> > With respect to the action item, I'll add it to next week's VWG agenda.
> >
> > -Tim
> >
> >> -Original Message-
> >> From: Doug Beattie [mailto:doug.beat...@globalsign.com]
> >> Sent: Wednesday, January 24, 2018 11:02 AM
> >> To: Tim Hollebeek <tim.holleb...@digicert.com>; Rob Stradling
> >> <rob.stradl...@comodo.com>; Jonathan Rudenberg
> >> <jonat...@titanous.com>; mozilla-dev-security-policy
> >  >> pol...@lists.mozilla.org>
> >> Subject: RE: GlobalSign certificate with far-future notBefore
> >>
> >> Can we consider this case closed with the action that the VWG will
> >> propose
> > a
> >> ballot that addresses pre and postdating certificates?
> >>
> >> Doug
> >>
> >>> -Original Message-
> >>> From: dev-security-policy [mailto:dev-security-policy-
> >>> bounces+doug.beattie=globalsign@lists.mozilla.org] On Behalf Of
> >>> bounces+Tim
> >>> Hollebeek via dev-security-policy
> >>> Sent: Wednesday, January 24, 2018 11:49 AM
> >>> To: Rob Stradling <rob.stradl...@comodo.com>; Jonathan Rudenberg
> >>> <jonat...@titanous.com>; mozilla-dev-security-policy
> >>> 
> >>> Subject: RE: GlobalSign certificate with far-future notBefore
> >>>
> >>>
> >>>>> This incident makes me think that two changes should be made:
> >>>>>
> >>>>> 1) The Root Store Policy should explicitly ban forward and
> >>>>> back-dating
> >>> the
> >>>> notBefore date.
> >>>>
> >>>> I think it would be reasonable and sensible to permit back-dating
> >>>> insofar
> >>> as it is
> >>>> deemed necessary to accommodate client-side clock-skew.
> >>>
> >>> Indeed.  This was discussed at a previous Face to Face meeting, and
> >>> it was generally agreed that a requirement that the notBefore date
> >>> be within +-1 week of issuance would not be unreasonable.
> >>>
> >>> The most common practice is backdating by a few days for the reason
> >>> Rob mentioned.
> >>>
> >>> -Tim
> >
> 
> 
> Enjoy
> 
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S.
> https://clicktime.symantec.com/a/1/w3EBVE2BUeC8MLN64pffPHe_ALFM8rW
> FtYSZz0xKgUQ=?d=0cp29hFCr5Urpdzx-
> Mfh962Yi0YHT8LIyoz29Y64zpxMuZ5acgO3veRerXVznnhS8okM5L2iK7Cfn-
> QM7GjRJRKhm9VLVunmzxGFY3ZEBLSt1WL9J_pv6EL3P9LWZ2hVLFetfoezYOko
> 0x-zSINeQfcGEdm1mIF6ToqUHA6FT-PImc0BUUM0RYQrHLClDEtxX9-
> CxA7_Q5Hi-
> dY_G2jx0s6sq6K5ezLrkKQ3gAzBEza0Zh3b1wW58ngKVU5vpeJvvlR_imWg-
> ZYQ3krbn6QKzJDxbo-
> uRsICLMequfXT4i7CTjcmzrWZ6i4wFJ_YwP7494F9dwa63QJ04UWu1VpygY_FO
> 9yp5t7UHK6F0Gm6dZv-
> Dbs0rvQeyRhJcD76INT9CIRVg0NYqzetnqGr_FXERUBlZySFZ5JHbXWLIq7YkZCEB
> 0bzP5csI62QM1CdL8dKJuEkEICGDDorGrSz8TIvahk%3D=https%3A%2F%2Fw
> ww.wisemo.com
> Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10 This
public
> discussion message is non-binding and may contain errors.
> WiseMo - Remote Service Management for PCs, Phones and Embedded
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://clicktime.symantec.com/a/1/kC_2afz6-
> xbFBgJiUlml8gw9eo6BNgViMVS2LeeuzvE=?d=0cp29hFCr5Urpdzx-
> Mfh962Yi0YHT8LIyoz29Y64zpxMuZ5acgO3veRerXVznnhS8okM5L2iK7Cfn-
> QM7GjRJRKhm9VLVunmzxGFY3ZEBLSt1WL9J_pv6EL3P9LWZ2hVLFetfoezYOko
> 0x-zSINeQfcGEdm1mIF6ToqUHA6FT-PImc0BUUM0RYQrHLClDEtxX9-
> CxA7_Q5Hi-
> dY_G2jx0s6sq6K5ezLrkKQ3gAzBEza0Zh3b1wW58ngKVU5vpeJvvlR_imWg-
> ZYQ3krbn6QKzJDxbo-
> uRsICLMequfXT4i7CTjcmzrWZ6i4wFJ_YwP7494F9dwa63QJ04UWu1VpygY_FO
> 9yp5t7UHK6F0Gm6dZv-
> Dbs0rvQeyRhJcD76INT9CIRVg0NYqzetnqGr_FXERUBlZySFZ5JHbXWLIq7YkZCEB
> 0bzP5csI62QM1CdL8dKJuEkEICGDDorGrSz8TIvahk%3D=https%3A%2F%2Fli
> sts.mozilla.org%2Flistinfo%2Fdev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: GlobalSign certificate with far-future notBefore

[Jakob Bohm via dev-security-policy]

On 24/01/2018 13:54, Ryan Sleevi wrote:

On Wed, Jan 24, 2018 at 7:05 AM Doug Beattie via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:





-Original Message-
From: Gervase Markham [mailto:g...@mozilla.org]
Sent: Wednesday, January 24, 2018 7:00 AM
To: Doug Beattie <doug.beat...@globalsign.com>; mozilla-dev-security-
pol...@lists.mozilla.org
Subject: Re: GlobalSign certificate with far-future notBefore

Hi Doug,

Thanks for the quick response.

On 24/01/18 11:52, Doug Beattie wrote:

In the case below, the customer ordered a 39 month certificate and set
the notBefore date for 2 months into the future.


Momentary 2017/2018 confusion in my brain had me thinking that this was
further into the future than it actually was. But yet still, it is the

other side of a

reduction in certificate lifetime deadline.


We permit customers to set a notBefore date into the future, possibly
for the reason listed below, but there could be other reasons.


So if a customer came to you today and renewed their certificate for
www.example.com with validity from 24th Jan 2017 to 24th Apr 2020
(perfectly fine), and then requested a second 39-month certificate valid

from

24th Apr 2020 to 24th July 2023, would you issue this second one?


No, we would not issue that certificate.  In no case would we issue a
certificate that has a notAfter more than 39 months from today, which is
currently 24 Apr 2021.



That’s purely a business decision, right? I couldn’t see anything in the
BRs prohibiting a CA from doing this, particularly given how validation
data is allowed to be reused, but I’m curious if GlobalSign reached a
different decision.



The BRs make no reference to the "Not Before" date in a certificate,
which is why backdating certificates does not excuse a CA from the
rules.

BR 1.6.1 (definitions) defines "validity period" as follows

Expiry Date: The “Not After” date in a Certificate that defines the end
of a Certificate’s validity period.

Validity Period: The period of time measured from the date when the
Certificate is issued until the Expiry Date

BR 6.3.2 sets the limits on the "validity period"

So the BRs limit the time between the /actual/ date of issuance and the
"Not After" date in the certificate.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: GlobalSign certificate with far-future notBefore

[Tim Hollebeek via dev-security-policy]

With respect to the action item, I'll add it to next week's VWG agenda.

-Tim

> -Original Message-
> From: Doug Beattie [mailto:doug.beat...@globalsign.com]
> Sent: Wednesday, January 24, 2018 11:02 AM
> To: Tim Hollebeek <tim.holleb...@digicert.com>; Rob Stradling
> <rob.stradl...@comodo.com>; Jonathan Rudenberg
> <jonat...@titanous.com>; mozilla-dev-security-policy
 pol...@lists.mozilla.org>
> Subject: RE: GlobalSign certificate with far-future notBefore
> 
> Can we consider this case closed with the action that the VWG will propose
a
> ballot that addresses pre and postdating certificates?
> 
> Doug
> 
> > -Original Message-
> > From: dev-security-policy [mailto:dev-security-policy-
> > bounces+doug.beattie=globalsign@lists.mozilla.org] On Behalf Of
> > bounces+Tim
> > Hollebeek via dev-security-policy
> > Sent: Wednesday, January 24, 2018 11:49 AM
> > To: Rob Stradling <rob.stradl...@comodo.com>; Jonathan Rudenberg
> > <jonat...@titanous.com>; mozilla-dev-security-policy
> > 
> > Subject: RE: GlobalSign certificate with far-future notBefore
> >
> >
> > > > This incident makes me think that two changes should be made:
> > > >
> > > > 1) The Root Store Policy should explicitly ban forward and
> > > > back-dating
> > the
> > > notBefore date.
> > >
> > > I think it would be reasonable and sensible to permit back-dating
> > > insofar
> > as it is
> > > deemed necessary to accommodate client-side clock-skew.
> >
> > Indeed.  This was discussed at a previous Face to Face meeting, and it
> > was generally agreed that a requirement that the notBefore date be
> > within +-1 week of issuance would not be unreasonable.
> >
> > The most common practice is backdating by a few days for the reason
> > Rob mentioned.
> >
> > -Tim



smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: GlobalSign certificate with far-future notBefore

[Doug Beattie via dev-security-policy]

Can we consider this case closed with the action that the VWG will propose a 
ballot that addresses pre and postdating certificates?

Doug

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+doug.beattie=globalsign@lists.mozilla.org] On Behalf Of Tim
> Hollebeek via dev-security-policy
> Sent: Wednesday, January 24, 2018 11:49 AM
> To: Rob Stradling <rob.stradl...@comodo.com>; Jonathan Rudenberg
> <jonat...@titanous.com>; mozilla-dev-security-policy  pol...@lists.mozilla.org>
> Subject: RE: GlobalSign certificate with far-future notBefore
> 
> 
> > > This incident makes me think that two changes should be made:
> > >
> > > 1) The Root Store Policy should explicitly ban forward and
> > > back-dating
> the
> > notBefore date.
> >
> > I think it would be reasonable and sensible to permit back-dating
> > insofar
> as it is
> > deemed necessary to accommodate client-side clock-skew.
> 
> Indeed.  This was discussed at a previous Face to Face meeting, and it was
> generally agreed that a requirement that the notBefore date be within +-1
> week of issuance would not be unreasonable.
> 
> The most common practice is backdating by a few days for the reason Rob
> mentioned.
> 
> -Tim

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: GlobalSign certificate with far-future notBefore

[Tim Hollebeek via dev-security-policy]

> > This incident makes me think that two changes should be made:
> >
> > 1) The Root Store Policy should explicitly ban forward and back-dating
the
> notBefore date.
> 
> I think it would be reasonable and sensible to permit back-dating insofar
as it is
> deemed necessary to accommodate client-side clock-skew.

Indeed.  This was discussed at a previous Face to Face meeting, and it was
generally
agreed that a requirement that the notBefore date be within +-1 week of
issuance
would not be unreasonable.

The most common practice is backdating by a few days for the reason Rob
mentioned.

-Tim



smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: GlobalSign certificate with far-future notBefore

[Ryan Sleevi via dev-security-policy]

On Wed, Jan 24, 2018 at 6:52 AM Doug Beattie via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> We don't allow customers to set the notBefore date into the past.
>
> And regarding the Mozilla checks for
> https://bugzilla.mozilla.org/show_bug.cgi?id=908125, perhaps the
> "notBefore" date used in the check should be the earlier of the certificate
> NotBefore or the date the included SCT was created.


This has a variety of both technical problems (e.g. when logs are
disqualified) and policy problems (using CT as a trusted timestamping
service rather than disclosure) that makes this, as a practical matter,
non-viable.

I don't know how Chrome would handle this certificate, but if it marks it
> as invalid, it would be good to know so we can relay this to customers that
> have set the notBefore date after March 1st.


As of Chrome 66, It will be rejected as an invalid certificate and users
will be forced to click through. I would have included this in Chrome 65 or
earlier, but in general, I try to land enforcement code in a way that it
rolls out approximate to the transition date, in the event of any issues.
The use of the notBefore as a proxy for issuance date has been a behavior
of a Chrome for nearly 5 years now, and was originally behavior contributed
by Opera, which had similar checks even longer.

In general, a certificate with a given notBefore is minimally expected to
comply with all of the policies as of that date. NotBefore backdating
attempts to circumvent that, which is problematic, but notBefore
forward-dating runs the risk that the certificate will be unusable at the
time it is valid, because it does not comply with the policies of its
validity period.


>
> Doug
>
> > -Original Message-
> > From: dev-security-policy [mailto:dev-security-policy-
> > bounces+doug.beattie=globalsign@lists.mozilla.org] On Behalf Of
> Gervase
> > Markham via dev-security-policy
> > Sent: Wednesday, January 24, 2018 5:05 AM
> > To: David E. Ross <nobody@nowhere.invalid>; mozilla-dev-security-
> > pol...@lists.mozilla.org
> > Subject: Re: GlobalSign certificate with far-future notBefore
> >
> > On 24/01/18 04:57, David E. Ross wrote:
> > > I am not sure about prohibiting forward-dating the notBefore date.  I
> > > can picture a situation where an existing site certificate is going to
> > > expire.  The site's administration decides to obtain a new certificate
> > > from a different certification authority.  Because of various
> > > administrative processes, the switch to the new site certificate
> > > cannot be accomplished quickly (e.g., moving the server); so they
> > > establish a notBefore date that is a month in the future.
> >
> > Why would that be _necessary_? What would go wrong if the cert was cut
> > with a notBefore of the current date, apart from the fact that they'd
> need to
> > renew it a month earlier?
> >
> > Gerv
> > ___
> > dev-security-policy mailing list
> > dev-security-policy@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-security-policy
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: GlobalSign certificate with far-future notBefore

[Ryan Sleevi via dev-security-policy]

On Wed, Jan 24, 2018 at 7:05 AM Doug Beattie via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
>
> > -Original Message-
> > From: Gervase Markham [mailto:g...@mozilla.org]
> > Sent: Wednesday, January 24, 2018 7:00 AM
> > To: Doug Beattie <doug.beat...@globalsign.com>; mozilla-dev-security-
> > pol...@lists.mozilla.org
> > Subject: Re: GlobalSign certificate with far-future notBefore
> >
> > Hi Doug,
> >
> > Thanks for the quick response.
> >
> > On 24/01/18 11:52, Doug Beattie wrote:
> > > In the case below, the customer ordered a 39 month certificate and set
> > > the notBefore date for 2 months into the future.
> >
> > Momentary 2017/2018 confusion in my brain had me thinking that this was
> > further into the future than it actually was. But yet still, it is the
> other side of a
> > reduction in certificate lifetime deadline.
> >
> > > We permit customers to set a notBefore date into the future, possibly
> > > for the reason listed below, but there could be other reasons.
> >
> > So if a customer came to you today and renewed their certificate for
> > www.example.com with validity from 24th Jan 2017 to 24th Apr 2020
> > (perfectly fine), and then requested a second 39-month certificate valid
> from
> > 24th Apr 2020 to 24th July 2023, would you issue this second one?
>
> No, we would not issue that certificate.  In no case would we issue a
> certificate that has a notAfter more than 39 months from today, which is
> currently 24 Apr 2021.


That’s purely a business decision, right? I couldn’t see anything in the
BRs prohibiting a CA from doing this, particularly given how validation
data is allowed to be reused, but I’m curious if GlobalSign reached a
different decision.

>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: GlobalSign certificate with far-future notBefore

[Doug Beattie via dev-security-policy]

> -Original Message-
> From: Gervase Markham [mailto:g...@mozilla.org]
> Sent: Wednesday, January 24, 2018 7:00 AM
> To: Doug Beattie <doug.beat...@globalsign.com>; mozilla-dev-security-
> pol...@lists.mozilla.org
> Subject: Re: GlobalSign certificate with far-future notBefore
> 
> Hi Doug,
> 
> Thanks for the quick response.
> 
> On 24/01/18 11:52, Doug Beattie wrote:
> > In the case below, the customer ordered a 39 month certificate and set
> > the notBefore date for 2 months into the future.
> 
> Momentary 2017/2018 confusion in my brain had me thinking that this was
> further into the future than it actually was. But yet still, it is the other 
> side of a
> reduction in certificate lifetime deadline.
> 
> > We permit customers to set a notBefore date into the future, possibly
> > for the reason listed below, but there could be other reasons.
> 
> So if a customer came to you today and renewed their certificate for
> www.example.com with validity from 24th Jan 2017 to 24th Apr 2020
> (perfectly fine), and then requested a second 39-month certificate valid from
> 24th Apr 2020 to 24th July 2023, would you issue this second one?

No, we would not issue that certificate.  In no case would we issue a 
certificate that has a notAfter more than 39 months from today, which is 
currently 24 Apr 2021.


> Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: GlobalSign certificate with far-future notBefore

[Gervase Markham via dev-security-policy]

Hi Doug,

Thanks for the quick response.

On 24/01/18 11:52, Doug Beattie wrote:
> In the case below, the customer ordered a 39 month certificate and
> set the notBefore date for 2 months into the future.

Momentary 2017/2018 confusion in my brain had me thinking that this was
further into the future than it actually was. But yet still, it is the
other side of a reduction in certificate lifetime deadline.

> We permit customers to set a notBefore date into the future, possibly
> for the reason listed below, but there could be other reasons.

So if a customer came to you today and renewed their certificate for
www.example.com with validity from 24th Jan 2017 to 24th Apr 2020
(perfectly fine), and then requested a second 39-month certificate valid
from 24th Apr 2020 to 24th July 2023, would you issue this second one?

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: GlobalSign certificate with far-future notBefore

[Doug Beattie via dev-security-policy]

 I'll try to respond to the few questions on the topic in this one email.

In the case below, the customer ordered a 39 month certificate and set the 
notBefore date for 2 months into the future.  The notAfter is within the 
allowed 39 month validity as measured from time of issuance.  Posting the 
precertificate to CT helps document the actual issuance date as "proof".

We permit customers to set a notBefore date into the future, possibly for the 
reason listed below, but there could be other reasons.  We will never permit 
the notAfter date ever exceed 39 months from the issuance date (and soon this 
will be 825 days).

As Jonathan pointed out, "the certificate issued was valid for 1129 days (more 
than three years)" but the expiration date is less than 39 months from the date 
of the SCT (by a few seconds).
- Date posted to CT logs: 2018-01-23 09:32:50
- NotAfter:  2021-04-23  09:32:47 

Not renewing a month earlier isn't a valid use case since the notAfter never 
violates the BR max validity as measured from issuance time to expiration time.

We don't allow customers to set the notBefore date into the past.

And regarding the Mozilla checks for 
https://bugzilla.mozilla.org/show_bug.cgi?id=908125, perhaps the "notBefore" 
date used in the check should be the earlier of the certificate NotBefore or 
the date the included SCT was created.   

I don't know how Chrome would handle this certificate, but if it marks it as 
invalid, it would be good to know so we can relay this to customers that have 
set the notBefore date after March 1st.

Doug

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+doug.beattie=globalsign@lists.mozilla.org] On Behalf Of Gervase
> Markham via dev-security-policy
> Sent: Wednesday, January 24, 2018 5:05 AM
> To: David E. Ross <nobody@nowhere.invalid>; mozilla-dev-security-
> pol...@lists.mozilla.org
> Subject: Re: GlobalSign certificate with far-future notBefore
> 
> On 24/01/18 04:57, David E. Ross wrote:
> > I am not sure about prohibiting forward-dating the notBefore date.  I
> > can picture a situation where an existing site certificate is going to
> > expire.  The site's administration decides to obtain a new certificate
> > from a different certification authority.  Because of various
> > administrative processes, the switch to the new site certificate
> > cannot be accomplished quickly (e.g., moving the server); so they
> > establish a notBefore date that is a month in the future.
> 
> Why would that be _necessary_? What would go wrong if the cert was cut
> with a notBefore of the current date, apart from the fact that they'd need to
> renew it a month earlier?
> 
> Gerv
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: GlobalSign certificate with far-future notBefore

[Rob Stradling via dev-security-policy]

On 23/01/18 22:55, Jonathan Rudenberg via dev-security-policy wrote:


https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Backdating_the_notBefore_Date

This incident makes me think that two changes should be made:

1) The Root Store Policy should explicitly ban forward and back-dating the 
notBefore date.


I think it would be reasonable and sensible to permit back-dating 
insofar as it is deemed necessary to accommodate client-side clock-skew.



2) Firefox should implement a technical check to enforce the validity period so 
that issuance practices like this do not impact users (see 
https://bugzilla.mozilla.org/show_bug.cgi?id=908125)

Jonathan


--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: GlobalSign certificate with far-future notBefore

[Gervase Markham via dev-security-policy]

On 24/01/18 04:57, David E. Ross wrote:
> I am not sure about prohibiting forward-dating the notBefore date.  I
> can picture a situation where an existing site certificate is going to
> expire.  The site's administration decides to obtain a new certificate
> from a different certification authority.  Because of various
> administrative processes, the switch to the new site certificate cannot
> be accomplished quickly (e.g., moving the server); so they establish a
> notBefore date that is a month in the future.

Why would that be _necessary_? What would go wrong if the cert was cut
with a notBefore of the current date, apart from the fact that they'd
need to renew it a month earlier?

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: GlobalSign certificate with far-future notBefore

[Gervase Markham via dev-security-policy]

Hi Jonathan,

On 23/01/18 22:55, Jonathan Rudenberg wrote:
> A certificate issued by GlobalSign showed up in CT today with a notBefore 
> date of March 21, 2018 and a notAfter date of April 23, 2021, a validity 
> period of ~1129 days (more than three years).

Thank you for pointing this out. This does seem at first look like an
attempted end-run around the 825-day validity period restriction which
comes into effect soon. Perhaps GlobalSign would care to comment here?
If not, I can file a bug and make a formal request.

> 1) The Root Store Policy should explicitly ban forward and back-dating the 
> notBefore date.

I am not opposed to this, but I would want to allow CAs to make
representations about when this is necessary so we can see if any
exceptions do actually need to be made. But a general rule might be a
good idea.

> 2) Firefox should implement a technical check to enforce the validity period 
> so that issuance practices like this do not impact users (see 
> https://bugzilla.mozilla.org/show_bug.cgi?id=908125)

Does Chrome already do this? If so, I might expect this cert, once it
becomes valid, not to work in Chrome...

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: GlobalSign certificate with far-future notBefore

[David E. Ross via dev-security-policy]

On 1/23/2018 2:55 PM, Jonathan Rudenberg wrote:
> A certificate issued by GlobalSign showed up in CT today with a notBefore 
> date of March 21, 2018 and a notAfter date of April 23, 2021, a validity 
> period of ~1129 days (more than three years).
> 
> https://crt.sh/?id=311477948=zlint
> 
> CA/B Forum ballot 193 modified the Baseline Requirements to set a maximum 
> validity period of 825 days for certificates issued after March 1, 2018.
> 
> While the BRs do not appear to have any rules about forward-dating 
> certificates, Mozilla’s CA Forbidden or Problematic Practices say:
> 
>> Certificates do not contain an issue timestamp, so it is not possible to be 
>> certain when they were issued. The notBefore date is the start of the 
>> certificate's validity range, and is set by the CA. It should be a 
>> reasonable reflection of the date on which the certificate was issued. Minor 
>> tweaking for technical compatibility reasons is accepted, but backdating 
>> certificates in order to avoid some deadline or code-enforced restriction is 
>> not.
> 
> https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Backdating_the_notBefore_Date
> 
> This incident makes me think that two changes should be made:
> 
> 1) The Root Store Policy should explicitly ban forward and back-dating the 
> notBefore date.
> 2) Firefox should implement a technical check to enforce the validity period 
> so that issuance practices like this do not impact users (see 
> https://bugzilla.mozilla.org/show_bug.cgi?id=908125)
> 
> Jonathan
> 

I am not sure about prohibiting forward-dating the notBefore date.  I
can picture a situation where an existing site certificate is going to
expire.  The site's administration decides to obtain a new certificate
from a different certification authority.  Because of various
administrative processes, the switch to the new site certificate cannot
be accomplished quickly (e.g., moving the server); so they establish a
notBefore date that is a month in the future.

-- 
David E. Ross


President Trump:  Please stop using Twitter.  We need
to hear your voice and see you talking.  We need to know
when your message is really your own and not your attorney's.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

GlobalSign certificate with far-future notBefore

[Jonathan Rudenberg via dev-security-policy]

A certificate issued by GlobalSign showed up in CT today with a notBefore date 
of March 21, 2018 and a notAfter date of April 23, 2021, a validity period of 
~1129 days (more than three years).

https://crt.sh/?id=311477948=zlint

CA/B Forum ballot 193 modified the Baseline Requirements to set a maximum 
validity period of 825 days for certificates issued after March 1, 2018.

While the BRs do not appear to have any rules about forward-dating 
certificates, Mozilla’s CA Forbidden or Problematic Practices say:

> Certificates do not contain an issue timestamp, so it is not possible to be 
> certain when they were issued. The notBefore date is the start of the 
> certificate's validity range, and is set by the CA. It should be a reasonable 
> reflection of the date on which the certificate was issued. Minor tweaking 
> for technical compatibility reasons is accepted, but backdating certificates 
> in order to avoid some deadline or code-enforced restriction is not.

https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Backdating_the_notBefore_Date

This incident makes me think that two changes should be made:

1) The Root Store Policy should explicitly ban forward and back-dating the 
notBefore date.
2) Firefox should implement a technical check to enforce the validity period so 
that issuance practices like this do not impact users (see 
https://bugzilla.mozilla.org/show_bug.cgi?id=908125)

Jonathan
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy