On 24/01/18 00:47, Wayne Thayer wrote:
> more frequently when requirements change. I propose that we require CAs to
> update their CPS to comply with version 2.5 of the Mozilla root store
> policy no later than 15-April 2018.
I think we should have a more general stipulation that Mozilla does not
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
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 authorit
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
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
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 futu
> -Original Message-
> From: Gervase Markham [mailto:g...@mozilla.org]
> Sent: Wednesday, January 24, 2018 7:00 AM
> To: Doug Beattie ; mozilla-dev-security-
> pol...@lists.mozilla.org
> Subject: Re: GlobalSign certificate with far-future notBefore
>
> Hi Doug,
>
> Thanks for the quick
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 ; mozilla-dev-security-
> >
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
> "no
On Tue, Jan 23, 2018 at 7:47 PM, Wayne Thayer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Hi Everyone,
>
> I have reviewed the responses we received from the November 2017 CA
> Communication [1], and I have the following comments to share:
>
> * Beginning with the goo
There is no easy way to temporary sanction non-compliant CAs for lateness
of documents, incidents and etc.
There needs to be a switch developed which allows program members to
disable features such as EV without messing around in code.
James
On Wed, Jan 24, 2018 at 1:56 PM, Ryan Sleevi via dev-s
Hi everyone, we have just reported in Bugzilla a bug to remove the following
root CA, because it expires soon:
CN = Izenpe.com
O = IZENPE S.A. - CIF A-01337260-RMerc.Vitoria-Gasteiz T1055 F62 S8
SHA1= 4A 3F 8D 6B DC 0E 1E CF CD 72 E3 77 DE F2 D7 FF 92 C1 9B C7
Link to bugzilla -> https://bugzil
For these, it may help to make sure the context is available on the thread
- https://bugzilla.mozilla.org/show_bug.cgi?id=675060 is the bug, and the
current CPS at time of writing is 4.1 (
https://s3-us-west-2.amazonaws.com/comsign/CPS/CPS_4.1_eng.pdf )
Section 1.3.2.5:
- It remains unclear whethe
I didn't say it was easy, and I don't disagree that there are ways in which
it can be improved (e.g. to include server side checks). However, there are
some inescapable limitations in such approaches (e.g. users who cannot
contact the Mozilla servers that govern such flags), thus there's always
som
In the past, new policy versions have not had a clearly defined future
effective date. That seems to have led some CAs to interpret the timing for
making changes to be "whenever we get around to it" instead of the intent
of "the policy is effective immediately and we expect you to comply with it
as
> > 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-si
On 24/01/18 16:44, Wayne Thayer wrote:
> In the past, new policy versions have not had a clearly defined future
> effective date. That seems to have led some CAs to interpret the timing for
> making changes to be "whenever we get around to it" instead of the intent
> of "the policy is effective imm
On Wed, Jan 24, 2018 at 9:54 AM, Gervase Markham wrote:
> We do actually do that, it's just not written in the policy itself. See:
> https://wiki.mozilla.org/CA/Root_Store_Policy_Archive
> which gives all the publication dates and compliance dates.
>
> Good. Then all I'm suggesting is that we add
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
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 ; Rob Stradling
> ; Jonathan Rudenberg
> ; mozilla-dev-security-poli
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 ;
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/0
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 transitio
I want to directly notify all CAs in the Mozilla program of the recently
exposed issues with domain validation methods and of some upcoming
deadlines. A draft is available below and at
https://wiki.mozilla.org/CA/Communications#January_2018_CA_Communication
I would appreciate your prompt and const
Wayne,
You might want to highlight that method 1 sub-method 3 would survive even if
ballot 218 passes, as a new method 12 with some changes and improvements
that CAs who use sub-method 3 should pay close attention to.
With regards to TLS-SNI-01, I believe TLS-SNI-02 is also affected by the same
i
> On Jan 24, 2018, at 15:20, Wayne Thayer via dev-security-policy
> wrote:
>
> 2. On 19-December, significant concerns were raised about the reliability
> of the domain validation methods specified in BR 3.2.2.4.1 and 3.2.2.4.5.
> [3] Since then, discussions on the CA/Browser Forum Public list
On Wed, Jan 24, 2018 at 6:56 AM, Ryan Sleevi wrote:
> This seems to be a perennial problem with CAs, and doesn't inspire
> confidence in them or their operations. I am also concerned that an
> extension of this nature does not inspire confidence in the Mozilla Root
> Program, either as relying pa
To the best of my knowledge, the only "standard" sanction we have today is
complete distrust of a root or intermediate, and in practice that rarely
happens. On the surface, the idea of lesser sanctions like removing the EV
indicator for some period of time is appealing to me, but I think we need
to
On Wed, Jan 24, 2018 at 1:50 PM, Jonathan Rudenberg
wrote:
>
> > On Jan 24, 2018, at 15:20, Wayne Thayer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> >
> > 2. On 19-December, significant concerns were raised about the reliability
> > of the domain validation methods
> On Jan 24, 2018, at 17:05, Wayne Thayer via dev-security-policy
> wrote:
>
> We could still choose to set that date in our own policy if the ballot were
> to fail. The reasoning behind that date has been discussed on the
> CA/Browser Forum lists. I would summarize the argument as (1) a number
On Wed, Jan 24, 2018 at 4:41 PM, Wayne Thayer wrote:
> To the best of my knowledge, the only "standard" sanction we have today is
> complete distrust of a root or intermediate, and in practice that rarely
> happens. On the surface, the idea of lesser sanctions like removing the EV
> indicator for
On Wed, Jan 24, 2018 at 5:05 PM, Wayne Thayer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> > Is there a reason to make this deprecation conditional on the ballot?
> > Given what we know about how the vulnerable methods are used in the wild,
> > they have the same leve
On Wed, Jan 24, 2018 at 4:05 PM, Ryan Sleevi wrote:
>
>
> On Wed, Jan 24, 2018 at 5:05 PM, Wayne Thayer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>>
>> > Is there a reason to make this deprecation conditional on the ballot?
>> > Given what we know about how the vul
33 matches
Mail list logo
