Re: DRAFT January 2018 CA Communication

[Wayne Thayer via dev-security-policy]

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 vulnerable methods are used in the
>> wild,
>> > they have the same level of brokenness as TLS-SNI-01/02 and it’s not
>> clear
>> > how evaluating for vulnerabilities would fix anything.
>>
>>
>> This is a matter of timing. When possible, we should give the CA/Browser
>> Forum time to act before Mozilla does so unilaterally. Also, changing our
>> own policy is a process that would need to happen before we send this
>> communication. I have already suggested the Mozilla policy change [1].
>>
>
> Why is this?
>
> Mozilla unilaterally acted with the 10 Blessed Methods in order to
> mitigate security risks, after the Forum kept postponing.
>

Yes, *after the Forum kept postponing*.

Google and Microsoft (and later Mozilla) unilaterally acted with the
> deprecation of SHA-1.
>

My recollection is that Microsoft acted after first raising the issue with
the Forum and getting nowhere. So I believe that both of your examples
support my statement.

>
> The CA/Browser Forum consensus process does not produce results aligned
> with the Mozilla Foundation Manifesto, per-se, as it reflects a consensus
> process where 2/3 of CAs have agreed to do something. This naturally
> creates a situation of regulatory capture unaligned with the interests of
> or security of Mozilla users.
>
> There's two parts to the question at play here:
> 1) Does Mozilla believe the ballot is likely to pass the Forum, given a
> number of CA's stated opposition?
>

I can't answer that, but it does appear logical that the ballot is less
likely to succeed with a March deadline.


> 2) Does Mozilla believe August is an appropriate time to cease the
> practice, given the risks?
>

I don't know if there is consensus on this, but it is now clear to me that
at least some members of our community believe that August is not
appropriate.

  - Similarly, is Mozilla comfortable with accepting certificates using
> methods with disclosed vulnerabilities between now and that time, and that
> CAs sufficiently understand said vulnerabilities and have devised (but
> seemingly not yet disclosed) appropriate mitigations or controls?
>
>
Based on the feedback we've seen on this list, I'm going to say no, this is
a risk we're not comfortable with.


> 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.
>
>
> Are you talking the public list, or some other list, such as the
> Validation WG list? As a co-endorser of the Ballot, in its current form of
> August, it was presented that unless we agreed to endorse at August, it was
> not worth putting forward. One reason privately put forward as to why
> August was because "other user agents" would vote against it unless it was
> August. Is Mozilla such a User Agent?
>
> I expressed my concerns about a Mar 1 deadline on a Validation WG call and
then reiterated them on the Public list: https://cabforum.org/
pipermail/public/2018-January/012713.html I don't think that message
suggests Mozilla would vote against an earlier deadline, and I can't say if
Mozilla would or not. Conversely, your endorsement of the ballot certainly
made me think that Google supported the August deadline.


> I'm not yet aware of conversation that speaks to the volume of its usage
> (those questions have gone unanswered) or to the challenges in migrating to
> an alternative method (such as .2 or .3), which are still remarkably
> flexible and, indeed, mitigations for the risk of .1 inevitably come back
> to being .2 or .3 methods.
>
>
>> I would summarize the argument as (1) a number of
>> smaller CAs rely solely on 3.2.2.4.1 and (2) those that have commented
>> agreed that 6 months was enough time to migrate away from it.
>>
>
> I've not seen any CA publicly state that 6 months was sufficient time. Was
> this on the Validation list?
>

Yes - https://cabforum.org/pipermail/validation/2018-January/000703.html
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DRAFT January 2018 CA Communication

[Ryan Sleevi via dev-security-policy]

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 level of brokenness as TLS-SNI-01/02 and it’s not
> clear
> > how evaluating for vulnerabilities would fix anything.
>
>
> This is a matter of timing. When possible, we should give the CA/Browser
> Forum time to act before Mozilla does so unilaterally. Also, changing our
> own policy is a process that would need to happen before we send this
> communication. I have already suggested the Mozilla policy change [1].
>

Why is this?

Mozilla unilaterally acted with the 10 Blessed Methods in order to mitigate
security risks, after the Forum kept postponing.
Google and Microsoft (and later Mozilla) unilaterally acted with the
deprecation of SHA-1.

The CA/Browser Forum consensus process does not produce results aligned
with the Mozilla Foundation Manifesto, per-se, as it reflects a consensus
process where 2/3 of CAs have agreed to do something. This naturally
creates a situation of regulatory capture unaligned with the interests of
or security of Mozilla users.

There's two parts to the question at play here:
1) Does Mozilla believe the ballot is likely to pass the Forum, given a
number of CA's stated opposition?
2) Does Mozilla believe August is an appropriate time to cease the
practice, given the risks?
  - Similarly, is Mozilla comfortable with accepting certificates using
methods with disclosed vulnerabilities between now and that time, and that
CAs sufficiently understand said vulnerabilities and have devised (but
seemingly not yet disclosed) appropriate mitigations or controls?


> 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.


Are you talking the public list, or some other list, such as the Validation
WG list? As a co-endorser of the Ballot, in its current form of August, it
was presented that unless we agreed to endorse at August, it was not worth
putting forward. One reason privately put forward as to why August was
because "other user agents" would vote against it unless it was August. Is
Mozilla such a User Agent?

I'm not yet aware of conversation that speaks to the volume of its usage
(those questions have gone unanswered) or to the challenges in migrating to
an alternative method (such as .2 or .3), which are still remarkably
flexible and, indeed, mitigations for the risk of .1 inevitably come back
to being .2 or .3 methods.


> I would summarize the argument as (1) a number of
> smaller CAs rely solely on 3.2.2.4.1 and (2) those that have commented
> agreed that 6 months was enough time to migrate away from it.
>

I've not seen any CA publicly state that 6 months was sufficient time. Was
this on the Validation list?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Summary of Responses to the November CA Communication

[Ryan Sleevi via dev-security-policy]

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 some period of time is appealing to me, but I think we need
> to take a step back and discuss whether or not this is really a good idea.
> Would Mozilla be better off in the long run having lesser sanctions readily
> at our disposal?
>
> First off, I question if we would really use lesser sanctions more often.
> I think we would still want to coordinate their implementation with other
> user agents, and that is a tedious process.
>

While probably not your intent, that does mean that any program
requirements Mozilla imposes - for example, disclosing the BR validation
method used - that aren't also adopted by other Root Programs - would be
somewhat toothless. Why would another user agent take an action against a
root that failed to disclose the methods used, if they didn't require that?
And if taking action requires that degree of coordination, to what end?


> Second, what might be the unintended consequences? For example, would CAs
> shift their focus from maintaining trust to avoiding sanctions?
>

So, when the only option is distrust, and when it's seen as a heavy option
(rather than what I think it should be - a regular occurrence until things
improve), then the only thing a CA has to worry about is not being so bad
that you get distrusted. We know you shouldn't be PROCERT bad [1] , but you
can seemingly be Visa bad [2] - their first audit wasn't until September
2016, despite Mozilla clearly communicating expectations in May 2014 [3],
and they still weren't compliant by the time of discussion.

So it doesn't _seem_ like CAs are focused on maintaining trust, per-se -
more like maintaining the status quo, and only making changes when
required, where "required" means threat of removal, which is a high-bar
that apparently Visa did not rise to (sadly, surprisingly). Further, the
argument seems to have been accepted that once you're in, it should be
harder to remove than what would normally be a complete disqualification
for a new entrant. Sanctions, on the other hand, help balance that - by
actually and effectively communicating that requirements are requirements,
and leveraging the host of options available to a Root Store appropriate to
their role as gatekeepers of trust.

A UA/Root Store is ultimately balancing the risk of 'past certificates'
with the risk of 'new certificates' - and making it easier to more rapidly
mitigate the risk of 'new certificates' (such as distrust periods and
requiring new roots, limiting the types of issuance accepted, etc) are
effective means of minimizing the risk to 'past certificates'.
Alternatively, abilities to more effectively mitigate 'past certificates' -
such as whitelists (despite the size hit) - can also help express that
requirements _are_ requirements.

The challenge is the changes must be meaningful, and not just things to
dance around. Preventing new certs and requiring new roots are an effective
way of actually minimizing that legacy-compat risk, while providing real
protection

[1]
https://groups.google.com/d/msg/mozilla.dev.security.policy/Ymrpsm7s5_I/Gki--pwHBgAJ
[2]
https://groups.google.com/d/msg/mozilla.dev.security.policy/NNV3zvX43vE/rae9kNkWAgAJ
[3] https://wiki.mozilla.org/CA/Communications#May_2014
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DRAFT January 2018 CA Communication

[Jonathan Rudenberg via dev-security-policy]

> 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 of
> smaller CAs rely solely on 3.2.2.4.1 and (2) those that have commented
> agreed that 6 months was enough time to migrate away from it.

While these CAs might want six months, it’s not clear that a good argument has 
been made for this. Let’s Encrypt stopped validating using the TLS-SNI-01 
method under two hours after learning that there was a *potential* security 
vulnerability in the validation method. Why should we expect any less from 
other CAs? We should err on the side of protecting users, not CAs using 
insecure validation methods that don’t even stand up to a small amount of 
adversarial scrutiny.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DRAFT January 2018 CA Communication

[Wayne Thayer via dev-security-policy]

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 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 have
> > resulted in a proposed ballot to prohibit the use of these methods after
> > 1-August 2018. [4] If your CA uses either of these methods, please
> evaluate
> > your implementation for vulnerabilities and be prepared to discontinue
> > their use prior to the deadline if ballot 218 succeeds.
>
> 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 level of brokenness as TLS-SNI-01/02 and it’s not clear
> how evaluating for vulnerabilities would fix anything.


This is a matter of timing. When possible, we should give the CA/Browser
Forum time to act before Mozilla does so unilaterally. Also, changing our
own policy is a process that would need to happen before we send this
communication. I have already suggested the Mozilla policy change [1].

August is a long time from now, and even that date would be conditional on
> the ballot.
>

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 of
smaller CAs rely solely on 3.2.2.4.1 and (2) those that have commented
agreed that 6 months was enough time to migrate away from it.

>
> I strongly believe that requiring CAs to disclose their use of these
> methods immediately, and setting a date not more than a couple months from
> now where these methods and previous validations using them must not be
> used would be the correct choice to protect Mozilla’s users.
>
> Jonathan


[1] https://github.com/mozilla/pkipolicy/issues/116
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Summary of Responses to the November CA Communication

[Wayne Thayer via dev-security-policy]

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 take a step back and discuss whether or not this is really a good idea.
Would Mozilla be better off in the long run having lesser sanctions readily
at our disposal?

First off, I question if we would really use lesser sanctions more often. I
think we would still want to coordinate their implementation with other
user agents, and that is a tedious process.

Second, what might be the unintended consequences? For example, would CAs
shift their focus from maintaining trust to avoiding sanctions?

- Wayne

On Wed, Jan 24, 2018 at 9:24 AM, Ryan Sleevi  wrote:

> 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 some code change necessary to ensure both a sane/predictable default
> (in the event of persistent DoS to an update server) and a configurable
> flag for that which matters.
>
> On Wed, Jan 24, 2018 at 9:24 AM, James Burton  wrote:
>
>> 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
>>
>>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Summary of Responses to the November CA Communication

[Wayne Thayer via dev-security-policy]

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 parties (CAs that are not competent are allowed
> to continue to be incompetent) or for competent CAs (Mozilla's
> requests/requirements are not actual requirements, but merely suggestions)
>
> I have to agree with this sentiment. However, in this particular case I
suspect many CAs were unaware of the compliance date (as was I).
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DRAFT January 2018 CA Communication

[Jonathan Rudenberg via dev-security-policy]

> 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 have
> resulted in a proposed ballot to prohibit the use of these methods after
> 1-August 2018. [4] If your CA uses either of these methods, please evaluate
> your implementation for vulnerabilities and be prepared to discontinue
> their use prior to the deadline if ballot 218 succeeds.

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 level of brokenness as TLS-SNI-01/02 and it’s not clear how evaluating 
for vulnerabilities would fix anything. August is a long time from now, and 
even that date would be conditional on the ballot.

I strongly believe that requiring CAs to disclose their use of these methods 
immediately, and setting a date not more than a couple months from now where 
these methods and previous validations using them must not be used would be the 
correct choice to protect Mozilla’s users.

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

RE: DRAFT January 2018 CA Communication

[Tim Hollebeek via dev-security-policy]

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
issue and should be mentioned as well.

-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

DRAFT January 2018 CA Communication

[Wayne Thayer via dev-security-policy]

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 constructive feedback on this message -
I'd like to get it sent out this week.

Thanks,

Wayne

===

Dear Certification Authority,

Because 2018 has already generated some important news for Certification
Authorities, we are sending this message to ensure that every CA in the
Mozilla program is aware of the following current events and impending
deadlines:

1. On 9-January, the CA “Let’s Encrypt” disclosed a vulnerability in the
ACME domain validation method known as TLS-SNI-01, which is an
implementation of the more general method described in BR 3.2.2.4.10. [1] A
subsequent vulnerability was disclosed on 11-January affecting the
validation method described in BR 3.2.2.4.9. [2] Mozilla expects all CAs to
be monitoring discussion in the mozilla.dev.security.policy forum and for
any CA that employs either of these methods to disclose that fact on the
list. From now on, Mozilla expects that CAs will not use these methods
unless they have implemented and disclosed a mitigation for the
vulnerabilities that have been discovered.

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 have
resulted in a proposed ballot to prohibit the use of these methods after
1-August 2018. [4] If your CA uses either of these methods, please evaluate
your implementation for vulnerabilities and be prepared to discontinue
their use prior to the deadline if ballot 218 succeeds.

3. Sections 5.3.1 and 5.3.2 of Mozilla Root Store Policy version 2.5 [5]
require CAs to publicly disclose (via CCADB [6]) all subordinate CA
certificates including those used to issue email S/MIME certificates by
15-January unless they are technically constrained to a whitelist of
domains. We have since changed the compliance deadline to 15-April 2018.
Certificate monitors have detected over 200 certificates that currently do
not comply with this new policy. [7] Please ensure that your CA is in
compliance before 15-April 2018.

4. In our November 2017 CA Communication [8], Mozilla asked all CAs with
roots enabled for websites (SSL) to complete a BR self-assessment [9] by
31-January and send it to Kathleen. If you have not yet done so, please
complete this work. If you requested an extension, your deadline is
15-April 2018.

5. If you are one of the CAs that indicated in your response to the
November 2017 CA Communication that you need more time to update your CPS
to comply with version 2.5 of the Mozilla Root Store Policy, please
complete the updates no later than 15-April 2018. Mozilla feels that four
months is more than long enough to make a CPS change.

6. On 17-March 2017, in ballot 193, the CA/Browser Forum set a deadline of
1-March 2018 after which newly-issued SSL certificates must not have a
validity period greater than 825 days, and the re-use of validation
information must be limited to 825 days. As with all other baseline
requirements, Mozilla expects all CAs in the program to comply.

Participation in Mozilla's CA Certificate Program is at our sole
discretion, and we will take whatever steps are necessary to keep our users
safe. Nevertheless, we believe that the best approach to safeguard that
security is to work with CAs as partners, to foster open and frank
communication, and to be diligent in looking for ways to improve. Thank you
for your cooperation in this pursuit.

Regards,
Wayne Thayer
Mozilla CA Program Manager

[1]
https://groups.google.com/d/msg/mozilla.dev.security.policy/RHsIInIjJA0/LKrNi35aAQAJ
[2]
https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/PiOiGCyuxCU
[3] https://cabforum.org/pipermail/public/2017-December/012630.html
[4] https://cabforum.org/pipermail/public/2018-January/012819.html
[5]
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/
[6] http://ccadb.org/cas/intermediates
[7]
https://groups.google.com/d/msg/mozilla.dev.security.policy/sKhPTsIYNqs/Q-_ZKmDVAQAJ
[8]
https://wiki.mozilla.org/CA/Communications#November_2017_CA_Communication
[9] https://wiki.mozilla.org/CA/BR_Self-Assessment
___
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 ; Rob Stradling
> >> ; Jonathan Rudenberg
> >> ; 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 ; Jonathan Rudenberg
> >>> ; 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&u=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&u=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]

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 ; Rob Stradling
; Jonathan Rudenberg
; 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 ; Jonathan Rudenberg
; 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://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

[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 ; 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 ; Rob Stradling
> ; Jonathan Rudenberg
> ; 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 ; Jonathan Rudenberg
> > ; 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 ; Jonathan Rudenberg
> ; 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: Summary of Responses to the November CA Communication

[Wayne Thayer via dev-security-policy]

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 the compliance date to the
policy and related communications.

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

Re: Summary of Responses to the November CA Communication

[Gervase Markham via dev-security-policy]

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 immediately and we expect you to comply with it
> as soon as possible". Given this abuse, I'd prefer to put a date on each
> new version of the policy by which CAs are expected to comply with it. This
> date would be 2-3 months after the policy was announced, but would also
> allow specific carve-outs for changes that take longer.

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.

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]

> > 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: Summary of Responses to the November CA Communication

[Wayne Thayer via dev-security-policy]

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 soon as possible". Given this abuse, I'd prefer to put a date on each
new version of the policy by which CAs are expected to comply with it. This
date would be 2-3 months after the policy was announced, but would also
allow specific carve-outs for changes that take longer.

- Wayne

On Wed, Jan 24, 2018 at 3:01 AM, Gervase Markham  wrote:

> 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
> consider it reasonable to take more than N months to make an update to a
> CPS, with N being a number like 3 or 2.
>
> Now, a particular change my require code changes as well, and the CPS
> may only be updated when those are made, and that might take longer -
> that's fine. But if the requirement is e.g. "add some extra contact
> information", that's not fine. CAs should not be in the habit of having
> processes where their CPSes are only updated yearly.
>
> Gerv
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Summary of Responses to the November CA Communication

[Ryan Sleevi via dev-security-policy]

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
some code change necessary to ensure both a sane/predictable default (in
the event of persistent DoS to an update server) and a configurable flag
for that which matters.

On Wed, Jan 24, 2018 at 9:24 AM, James Burton  wrote:

> 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-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> 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 good news, no new concerns related to the suspected
>> > .tg Registry compromise were reported (Action #8)
>> > * The deadline for submitting the survey was 15-December, but Amazon,
>> > DSV-Gruppe, and Web.com required repeated prodding in January before
>> they
>> > responded. It may be that mid-December is not the best time of the year
>> for
>> > a survey deadline, but the response we received fell short of our
>> > expectations.
>> > * In action #1, CAs were asked to confirm that they comply with version
>> 2.5
>> > of the Mozilla root store policy. This policy took effect last June [2],
>> > but a number of CAs stated that they needed more time to bring their CPS
>> > into compliance. Most CAs said they would comply by 1-March, but some
>> > requested much more time. Microsec Ltd. stated that “The next version of
>> > our public documents will contain the exact reference to these BR
>> sections
>> > which will be issued by 2018-09-30.” I expect CAs to update their CPS
>> much
>> > 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.
>> >
>>
>> 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 parties (CAs that are not competent are allowed
>> to continue to be incompetent) or for competent CAs (Mozilla's
>> requests/requirements are not actual requirements, but merely suggestions)
>>
>> I am specifically concerned about the CP/CPS updates and the impact they
>> have to global trust. Am I mistaken in evaluating
>> https://github.com/mozilla/pkipolicy/compare/2.4.1...2.5 that the
>> substance
>> of those changes are:
>> 1) Documenting which of the 10 Blessed Methods a CA does not use
>> 2) Updating the version number and adding a dated change log
>>
>> 2 should be inconsequential, but 1 has a very real effect - unless/until
>> the CA updates their CP/CPS to explicitly state what methods they are
>> using
>> (implicitly disavowing the 'any other method'), then a CA can receive a
>> fully compliant audit, despite actively issuing certificates using 'any
>> other method', in contravention of Mozilla Policy.
>>
>> That seems concerning, and the effect is that delaying such updates to
>> 15-April-2018 would mean the community is being asked to accept, based on
>> the honor system, a CA's word that they're not issuing certificates using
>> arbitrary methods.
>>
>> Is my concern misplaced? This seems fairly critical to security, and given
>> the number of CA incidents over the past year, I have very little faith
>> that CAs are in compliance, and that some form of 'human error or
>> oversight' didn't cause them to 'forget' they were using Any-Other-Method.
>>
>> Does Mozilla plan to sanction non-compliant CAs, either now or in the
>> future? Certainly, it seems the removal of any EV status would be
>> appropriate for any CA still needing time to update their CP/CPS, as the
>> level of assurance provided by these CAs regarding their validation
>> methods
>> surely does not rise to the high levels of assurance EV is presumed to
>> convey. But more importantly, should new certificates be distrusted until
>> such a time as the CA can demonstrate compliance? I cannot help but think
>> that is the only way to ensure timely compliance - any CA found to need
>> more time to adjust to policy changes will have trust in their
>> certificates
>> immediately disabled, and for some fixed period (which may grow if the
>> incidents are repeated). 6 months seems an appropriate start.
>> _

Re: ComSign Root Renewal Request

[Ryan Sleevi via dev-security-policy]

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 whether or not DTPs can perform domain validation
(which is no longer permitted under the BRs). ComSign does employ DTPs as
RAs for other forms of information, such as organization information, and
does make it clear it supports Enterprise RAs (which are permitted under
the BRs, provided the domain namespace is scoped to something the CA
validated). Section 3.2.2.4 touches on this by stating it'll be performed
by their own staff, so I think this is just highlighting an ambiguous
inconsistency.

Section 3.2.2.4
- ComSign makes use of the (problematic) 3.2.2.4.1 method. This method is
presently permitted under the BRs, but worth highlighting as a concern,
given the attacks demonstrated in the CA/Browser Forum as to the
reliability of this method.
- ComSign makes use of the (problematic) 3.2.2.4.5 method. This method is
presently permitted under the BRs, but worth highlighting as a concern,
given the attacks demonstrated in the CA/Browser Forum as to the
reliability of this method.
- ComSign makes use of the (problematic) 3.2.2.4.9 method. This method is
presently permitted under the BRs, but worth highlighting as a concern,
given the attacks demonstrated in the CA/Browser Forum as to the
reliability of this method. ComSign has not yet disclosed to this list how
they use it, and whether their use of this method is affected by the same
vulnerabilities that affected GlobalSign and Let's Encrypt.

Section 3.2.2.8
- ComSign does not document ComSign's CAA identifier here or in Section
2.2. It is, however, documented in 4.2.1.1 (iv).

Section 3.4
- ComSign does not seem to permit revocation requests in the event of
misissuance, at least within this section. This means the domain holder of
a misissued certificate seemingly cannot request ComSign revoke that
certificate, nor can they request ComSign revoke pre-existing certificates
potentially obtained by prior domain holders. This seems supported by the
process in Section 4.9.2

Particularly Concerning:
This CP/CPS is the same set that ComSign uses for all of its issuance
practices. During the course of Chrome development and improving our
compliance checks to RFC5280 (which we require by policy and by virtue of
the BRs), we discovered that ComSign had issued "tens of thousands" of
misencoded client certificates [1]. The result was due to using RSA Keon
Certificate Authority [2]. These details were provided by someone
representing themselves as the CEO of ComSign [3].

As best we can tell, RSA was calling the product "Keon Certificate
Authority" at least as recent as 2007, based on CVE-2006-4991 [4], although
based on RSA's current information [5], it appears to have been rebranded
around that time to "RSA Certificate Manager" (no longer being called Keon
CA). The version known as "Keon CA" at least had vulnerabilities that
allowed for the overwriting of CA's audit logs

It's unclear if this means that ComSign is using CA software written in
2007, or whether they're using a more recent version. Based on the
documentation in [5], it does seem RSA Certificate Manager is reached End
of Product Support sometime in 2017, although it seems at least some
updates [6] were provided.

I think this demonstrates a violation of ComSign's commitment to RFC5280,
and to its CP/CPS regarding the use of names (c.f. Section 3.1.1), but also
raises deeper concerns about their commitment to quality in issuance, and
to past practices - particularly those outside of the audited window. Given
that ComSign has stated they plan to find new CA software [7], perhaps it
may be advisable to reject this request (and the key associated), and wait
until such a time as a new CA, with a new key, and an unblemished and
unquestioned audit sequence, can be established.

[1] https://bugs.chromium.org/p/chromium/issues/detail?id=770323#c3
[2] https://bugs.chromium.org/p/chromium/issues/detail?id=770323#c4
[3] https://bugs.chromium.org/p/chromium/issues/detail?id=770323#c29
[4] https://nvd.nist.gov/vuln/detail/CVE-2006-4991
[5] https://community.rsa.com/docs/DOC-73367
[6] https://community.rsa.com/docs/DOC-81493
[7] https://bugs.chromium.org/p/chromium/issues/detail?id=770323#c5

On Tue, Jan 16, 2018 at 4:05 PM, Wayne Thayer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> To recap, we've established that this root was first BR audited on
> 26-April 2015 and has received clean period-of-time audits over the next
> two years. ComSign has disclosed 36 certificates issued by this root prior
> to the BR point-in-time audit, of which one remains unexpired. This does
> not meet the requirements of BR section 8.1 both because the point-in-time
> readiness assessment was not completed prior to issuin

Izenpe.com rootCA expiration

[García Jimeno , Oscar via dev-security-policy]

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://bugzilla.mozilla.org/show_bug.cgi?id=1432807
Link to the certificate -> 
http://www.izenpe.eus/contenidos/informacion/cas_izenpe/es_cas/adjuntos/CA_Raiz_2003.crt

Regards


.eus gara !
horregatik orain nire helbide elektronikoa da:
por eso mi dirección de correo electrónico ahora es:  
o-gar...@izenpe.eus

Oscar García
CISSP, CISM

[Descripción: firma_email_Izenpe_eus]



ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. 
Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki 
idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. 
KONTUZ!
ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la 
que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error 
le agradeceriamos que no hiciera uso de la informacion y que se pusiese en 
contacto con el remitente.



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

Re: Summary of Responses to the November CA Communication

[James Burton via dev-security-policy]

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-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> 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 good news, no new concerns related to the suspected
> > .tg Registry compromise were reported (Action #8)
> > * The deadline for submitting the survey was 15-December, but Amazon,
> > DSV-Gruppe, and Web.com required repeated prodding in January before they
> > responded. It may be that mid-December is not the best time of the year
> for
> > a survey deadline, but the response we received fell short of our
> > expectations.
> > * In action #1, CAs were asked to confirm that they comply with version
> 2.5
> > of the Mozilla root store policy. This policy took effect last June [2],
> > but a number of CAs stated that they needed more time to bring their CPS
> > into compliance. Most CAs said they would comply by 1-March, but some
> > requested much more time. Microsec Ltd. stated that “The next version of
> > our public documents will contain the exact reference to these BR
> sections
> > which will be issued by 2018-09-30.” I expect CAs to update their CPS
> much
> > 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.
> >
>
> 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 parties (CAs that are not competent are allowed
> to continue to be incompetent) or for competent CAs (Mozilla's
> requests/requirements are not actual requirements, but merely suggestions)
>
> I am specifically concerned about the CP/CPS updates and the impact they
> have to global trust. Am I mistaken in evaluating
> https://github.com/mozilla/pkipolicy/compare/2.4.1...2.5 that the
> substance
> of those changes are:
> 1) Documenting which of the 10 Blessed Methods a CA does not use
> 2) Updating the version number and adding a dated change log
>
> 2 should be inconsequential, but 1 has a very real effect - unless/until
> the CA updates their CP/CPS to explicitly state what methods they are using
> (implicitly disavowing the 'any other method'), then a CA can receive a
> fully compliant audit, despite actively issuing certificates using 'any
> other method', in contravention of Mozilla Policy.
>
> That seems concerning, and the effect is that delaying such updates to
> 15-April-2018 would mean the community is being asked to accept, based on
> the honor system, a CA's word that they're not issuing certificates using
> arbitrary methods.
>
> Is my concern misplaced? This seems fairly critical to security, and given
> the number of CA incidents over the past year, I have very little faith
> that CAs are in compliance, and that some form of 'human error or
> oversight' didn't cause them to 'forget' they were using Any-Other-Method.
>
> Does Mozilla plan to sanction non-compliant CAs, either now or in the
> future? Certainly, it seems the removal of any EV status would be
> appropriate for any CA still needing time to update their CP/CPS, as the
> level of assurance provided by these CAs regarding their validation methods
> surely does not rise to the high levels of assurance EV is presumed to
> convey. But more importantly, should new certificates be distrusted until
> such a time as the CA can demonstrate compliance? I cannot help but think
> that is the only way to ensure timely compliance - any CA found to need
> more time to adjust to policy changes will have trust in their certificates
> immediately disabled, and for some fixed period (which may grow if the
> incidents are repeated). 6 months seems an appropriate start.
> ___
> 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: Summary of Responses to the November CA Communication

[Ryan Sleevi via dev-security-policy]

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 good news, no new concerns related to the suspected
> .tg Registry compromise were reported (Action #8)
> * The deadline for submitting the survey was 15-December, but Amazon,
> DSV-Gruppe, and Web.com required repeated prodding in January before they
> responded. It may be that mid-December is not the best time of the year for
> a survey deadline, but the response we received fell short of our
> expectations.
> * In action #1, CAs were asked to confirm that they comply with version 2.5
> of the Mozilla root store policy. This policy took effect last June [2],
> but a number of CAs stated that they needed more time to bring their CPS
> into compliance. Most CAs said they would comply by 1-March, but some
> requested much more time. Microsec Ltd. stated that “The next version of
> our public documents will contain the exact reference to these BR sections
> which will be issued by 2018-09-30.” I expect CAs to update their CPS much
> 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.
>

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 parties (CAs that are not competent are allowed
to continue to be incompetent) or for competent CAs (Mozilla's
requests/requirements are not actual requirements, but merely suggestions)

I am specifically concerned about the CP/CPS updates and the impact they
have to global trust. Am I mistaken in evaluating
https://github.com/mozilla/pkipolicy/compare/2.4.1...2.5 that the substance
of those changes are:
1) Documenting which of the 10 Blessed Methods a CA does not use
2) Updating the version number and adding a dated change log

2 should be inconsequential, but 1 has a very real effect - unless/until
the CA updates their CP/CPS to explicitly state what methods they are using
(implicitly disavowing the 'any other method'), then a CA can receive a
fully compliant audit, despite actively issuing certificates using 'any
other method', in contravention of Mozilla Policy.

That seems concerning, and the effect is that delaying such updates to
15-April-2018 would mean the community is being asked to accept, based on
the honor system, a CA's word that they're not issuing certificates using
arbitrary methods.

Is my concern misplaced? This seems fairly critical to security, and given
the number of CA incidents over the past year, I have very little faith
that CAs are in compliance, and that some form of 'human error or
oversight' didn't cause them to 'forget' they were using Any-Other-Method.

Does Mozilla plan to sanction non-compliant CAs, either now or in the
future? Certainly, it seems the removal of any EV status would be
appropriate for any CA still needing time to update their CP/CPS, as the
level of assurance provided by these CAs regarding their validation methods
surely does not rise to the high levels of assurance EV is presumed to
convey. But more importantly, should new certificates be distrusted until
such a time as the CA can demonstrate compliance? I cannot help but think
that is the only way to ensure timely compliance - any CA found to need
more time to adjust to policy changes will have trust in their certificates
immediately disabled, and for some fixed period (which may grow if the
incidents are repeated). 6 months seems an appropriate start.
___
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 ; 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 ; 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 ; 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 ; 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: Summary of Responses to the November CA Communication

[Gervase Markham via dev-security-policy]

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
consider it reasonable to take more than N months to make an update to a
CPS, with N being a number like 3 or 2.

Now, a particular change my require code changes as well, and the CPS
may only be updated when those are made, and that might take longer -
that's fine. But if the requirement is e.g. "add some extra contact
information", that's not fine. CAs should not be in the habit of having
processes where their CPSes are only updated yearly.

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