Re: Japan GPKI Root Renewal Request

[apca2.2013--- via dev-security-policy]

"I would like to again point out that simply waiting for misissued certificates 
to expire is not an acceptable response."

This is a misunderstanding.
We are preparing to revoke certificates immediately, rather than waiting for 
certificates issued prior to 2017 to expire.
However, even if we revoke those certificates, if your judgment is not affected 
and our request is rejected, there is no point in doing it.
Please let us know if our request will be accepted by revoking all the 
certificates we issued prior to 2017.

Thank you
APCA


2018年2月28日水曜日 7時51分23秒 UTC+9 Wayne Thayer:
> To conclude this discussion, Mozilla is denying the Japanese Government
> ApplicationCA2 Root inclusion request.  I'd like to thank everyone for your
> constructive input into the discussion, and I'd like to thank the Japanese
> Government representatives for their patience and work to address issues as
> they have been discovered. I will be resolving the bug as "WONTFIX".
> 
> The Japanese Government PKI may submit a newly generated root and key-pair
> for inclusion, and this submission can be made using the existing bug (
> https://bugzilla.mozilla.org/show_bug.cgi?id=870185).
> 
> On Thu, Feb 22, 2018 at 11:57 PM, apca2.2013--- via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
> > We are a certificate authority controlled by the Government of Japan and
> > issued only for servers operated by the government.
> >
> > For certificates that you point out concerning, they will expire and will
> > be reissued, so we think that the problem will be solved.
> >
> > I would like to again point out that simply waiting for misissued
> certificates to expire is not an acceptable response.
> 
> 
> > We will continue to take BR audits in the future so we will operate as a
> > secure certification authority and we appreciate your continued support.
> >
> > - Wayne

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

Re: Allowing WebExtensions to Override Certificate Trust Decisions

[Jakob Bohm via dev-security-policy]

On 27/02/2018 17:20, Wayne Thayer wrote:

I am seeking input on this proposal:

Work is underway to allow Firefox add-ons to read certificate information
via WebExtensions APIs [1]. It has also been proposed [2] that the
WebExtensions APIs in Firefox be enhanced to allow a 3rd party add-on to
change or ignore the normal results of certificate validation.

This capability existed in the legacy Firefox extension system that was
deprecated last year. It was used to implement stricter security mechanisms
(e.g. CertPatrol) and to experiment with new mechanisms such as Certificate
Transparency and DANE.

When used to override a certificate validation failure, this is a dangerous
capability, and it’s not clear that requiring a user to grant permission to
the add-on is adequate protection. One solution that has been proposed [4]
is to allow an add-on to affect the connection but not the certificate UI.
In other words, when a validation failure is overridden, the page will load
but the nav bar will still display it as a failure.

I would appreciate your constructive feedback on this decision. Should this
capability be added to the Firefox WebExtensions APIs?

- Wayne

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1322748
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1435951
[3] https://mail.mozilla.org/pipermail/dev-addons/2018-February/003629.html
[4] https://mail.mozilla.org/pipermail/dev-addons/2018-February/003641.html



How about allowing the WebExtensions to only request a worse result
(failure/lower trust) and to forcibly mark the origin (extension name)
of such restriction in the internal state and UI?

For example, an extension could mark lack of CT as non-EV (i.e. not
green).  Or it could completely fail certificates found in some CRL
representation.

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: Allowing WebExtensions to Override Certificate Trust Decisions

[Ryan Sleevi via dev-security-policy]

On Tue, Feb 27, 2018 at 6:15 PM, Wayne Thayer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> In the bug I referenced as [2], people said that they specifically need to
> be able to override "negative" certificate validation decisions, so they
> may not see this as a compromise. I think an example would be a site
> serving a self-signed certificate for a DANE add-on to validate.
>

I think some of it may relate to Moz Platform questions, since they go to
the heart of extensions' behaviours.

For example, can extensions allow mixed content when it's been blocked? Can
they disable sandboxing if the user requests? There's a spectrum of
decisions that a browser makes as an intrinsic part of guaranteeing the
security of its users that it does not allow extensions or the like to
override, and may not even allow users themselves to override.

The design of the new extension model is to try to explicitly make sure
each capability granted to extensions is balanced in its security rationale
and functionality, and aligns the collective risks against the individual
rewards. There's a full spectrum here, well beyond PKI bits, so that's why
I suggest it strikes a bit core. It was one of the big benefits of the
process-sandboxing efforts, as extensions no longer had an 'implicit'
backdoor into the browser process.

Would you consider extensions that enabled SHA-1 automatically or disabled
technical enforcement of CAs? Fundamentally, the capability to alter trust
either grants that ability or is no-different-to that ability. What about
an extension called "HTTPS-made-easy" that just disabled all certificate
errors, on the view that the Web should be like it was in the HTTP days,
and solving the technical hurdle? What about vendors that force-install
extensions to Firefox users so they can use a shared key for all of their
installations? All of these things become possible or significantly easier
with an extension that can confer positive trust on something that Firefox
has deemed negative.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Allowing WebExtensions to Override Certificate Trust Decisions

[Peter Saint-Andre via dev-security-policy]

On 2/27/18 4:15 PM, Wayne Thayer wrote:
> On Tue, Feb 27, 2018 at 3:40 PM, Peter Saint-Andre via
> dev-security-policy  > wrote:
> 
> On 2/27/18 3:26 PM, Hanno Böck via dev-security-policy wrote:
> > Hi,
> >
> > On Tue, 27 Feb 2018 09:20:33 -0700
> > Wayne Thayer via dev-security-policy
> >  > wrote:
> >
> >> This capability existed in the legacy Firefox extension system that
> >> was deprecated last year. It was used to implement stricter security
> >> mechanisms (e.g. CertPatrol) and to experiment with new mechanisms
> >> such as Certificate Transparency and DANE.
> >
> > Wouldn't be a good compromise to say: Extensions can downgrade
> > security, but they can't upgrade it?
> 
> 
> In the bug I referenced as [2], people said that they specifically need
> to be able to override "negative" certificate validation decisions, so
> they may not see this as a compromise. I think an example would be a
> site serving a self-signed certificate for a DANE add-on to validate.
> 
> 
> Don't you mean the other way around? Otherwise, we're creating a
> powerful footgun.
> 
> I assume that by "downgrade", Hanno meant "change the UI to indicate a
> bad cert" and by "upgrade" he meant "indicate a valid cert in the UI
> when validation has failed".

OK, we're all in agreement but using opposite terminology. :)

Peter



signature.asc
Description: OpenPGP digital signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Allowing WebExtensions to Override Certificate Trust Decisions

[Wayne Thayer via dev-security-policy]

On Tue, Feb 27, 2018 at 3:40 PM, Peter Saint-Andre via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 2/27/18 3:26 PM, Hanno Böck via dev-security-policy wrote:
> > Hi,
> >
> > On Tue, 27 Feb 2018 09:20:33 -0700
> > Wayne Thayer via dev-security-policy
> >  wrote:
> >
> >> This capability existed in the legacy Firefox extension system that
> >> was deprecated last year. It was used to implement stricter security
> >> mechanisms (e.g. CertPatrol) and to experiment with new mechanisms
> >> such as Certificate Transparency and DANE.
> >
> > Wouldn't be a good compromise to say: Extensions can downgrade
> > security, but they can't upgrade it?
>

In the bug I referenced as [2], people said that they specifically need to
be able to override "negative" certificate validation decisions, so they
may not see this as a compromise. I think an example would be a site
serving a self-signed certificate for a DANE add-on to validate.

>
> Don't you mean the other way around? Otherwise, we're creating a
> powerful footgun.
>
> I assume that by "downgrade", Hanno meant "change the UI to indicate a bad
cert" and by "upgrade" he meant "indicate a valid cert in the UI when
validation has failed".
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Japan GPKI Root Renewal Request

[Wayne Thayer via dev-security-policy]

To conclude this discussion, Mozilla is denying the Japanese Government
ApplicationCA2 Root inclusion request.  I'd like to thank everyone for your
constructive input into the discussion, and I'd like to thank the Japanese
Government representatives for their patience and work to address issues as
they have been discovered. I will be resolving the bug as "WONTFIX".

The Japanese Government PKI may submit a newly generated root and key-pair
for inclusion, and this submission can be made using the existing bug (
https://bugzilla.mozilla.org/show_bug.cgi?id=870185).

On Thu, Feb 22, 2018 at 11:57 PM, apca2.2013--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> We are a certificate authority controlled by the Government of Japan and
> issued only for servers operated by the government.
>
> For certificates that you point out concerning, they will expire and will
> be reissued, so we think that the problem will be solved.
>
> I would like to again point out that simply waiting for misissued
certificates to expire is not an acceptable response.


> We will continue to take BR audits in the future so we will operate as a
> secure certification authority and we appreciate your continued support.
>
> - Wayne
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Allowing WebExtensions to Override Certificate Trust Decisions

[Peter Saint-Andre via dev-security-policy]

On 2/27/18 3:26 PM, Hanno Böck via dev-security-policy wrote:
> Hi,
> 
> On Tue, 27 Feb 2018 09:20:33 -0700
> Wayne Thayer via dev-security-policy
>  wrote:
> 
>> This capability existed in the legacy Firefox extension system that
>> was deprecated last year. It was used to implement stricter security
>> mechanisms (e.g. CertPatrol) and to experiment with new mechanisms
>> such as Certificate Transparency and DANE.
> 
> Wouldn't be a good compromise to say: Extensions can downgrade
> security, but they can't upgrade it?

Don't you mean the other way around? Otherwise, we're creating a
powerful footgun.

Peter




signature.asc
Description: OpenPGP digital signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Allowing WebExtensions to Override Certificate Trust Decisions

[Hanno Böck via dev-security-policy]

Hi,

On Tue, 27 Feb 2018 09:20:33 -0700
Wayne Thayer via dev-security-policy
 wrote:

> This capability existed in the legacy Firefox extension system that
> was deprecated last year. It was used to implement stricter security
> mechanisms (e.g. CertPatrol) and to experiment with new mechanisms
> such as Certificate Transparency and DANE.

Wouldn't be a good compromise to say: Extensions can downgrade
security, but they can't upgrade it?
I.e. if a certificate is valid according to "normal" WebPKI validation
but there's an additional validation mechanism that fails the extension
could say "tread this like an untrusted cert", but it couldn't say
"our positive validation of that cert overrides the normal validation".

Is there any existing use case that would not work with that?

As far as I can see and if I understand it right all of those examples
should be able to work on top of existing validation.

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: TunRootCA2 root inclusion request

[Jonathan Rudenberg via dev-security-policy]

> On Feb 27, 2018, at 16:47, Wayne Thayer via dev-security-policy 
>  wrote:
> 
> On Tue, Feb 27, 2018 at 2:40 PM, Jonathan Rudenberg 
> wrote:
> 
>> 
>>> On Feb 27, 2018, at 16:35, Jonathan Rudenberg via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>> 
>>> 
 On Feb 27, 2018, at 16:17, Wayne Thayer via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
 
 This request has been in public discussion for more than 6 months, so I
 would like to make a decision soon. If you have comments or concerns
>> with
 this request, please post them here by 6-March 2018.
>>> 
>>> Given the misissued certificates in CT under the existing root, I
>> believe this request should be rejected, and a new clean root with audits
>> should be required before moving forward.
>>> 
>> 
> This course of action doesn't seem consistent with our treatment of the
> many included CAs that have experienced these problems.

Given that revocation checking doesn’t work, and CT doesn’t provide a complete 
picture, especially without browser enforcement, accepting this root would have 
the result of exposing Mozilla's users to certificates that are known to be 
misissued.

I realize that some inclusion requests have been accepted in the past despite 
existing misissued certificates, but I don’t think that is sufficient 
justification for continuing to do so. Why shouldn’t we require CAs to cut a 
new root when the data indicates that accepting the existing root will put 
users at risk?

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

Re: TunRootCA2 root inclusion request

[Wayne Thayer via dev-security-policy]

On Tue, Feb 27, 2018 at 2:40 PM, Jonathan Rudenberg 
wrote:

>
> > On Feb 27, 2018, at 16:35, Jonathan Rudenberg via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> >
> >
> >> On Feb 27, 2018, at 16:17, Wayne Thayer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> >>
> >> This request has been in public discussion for more than 6 months, so I
> >> would like to make a decision soon. If you have comments or concerns
> with
> >> this request, please post them here by 6-March 2018.
> >
> > Given the misissued certificates in CT under the existing root, I
> believe this request should be rejected, and a new clean root with audits
> should be required before moving forward.
> >
>
This course of action doesn't seem consistent with our treatment of the
many included CAs that have experienced these problems.


> > The errors in the issued certificates indicate a lack of technical
> controls in addition to improperly implemented certificate profiles. Given
> this, an explanation should also be provided of what changes have been made
> to the issuance environment to ensure these types of mistakes will not
> happen under the new root.
>
> I just took a closer look at the thread, and it appears that some
> misissuance was pointed out in July and most of the controls that were
> suggested as a solution relied on humans. These controls appear to have
> predictably failed, as multiple misissued certificates are from this fall,
> well after the fixes should have been in place.
>
> Olfa's most recent response indicates that additional/technical controls
were added this week. However, I'm not convinced that they are adequate.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: TunRootCA2 root inclusion request

[Jonathan Rudenberg via dev-security-policy]

> On Feb 27, 2018, at 16:35, Jonathan Rudenberg via dev-security-policy 
>  wrote:
> 
> 
>> On Feb 27, 2018, at 16:17, Wayne Thayer via dev-security-policy 
>>  wrote:
>> 
>> This request has been in public discussion for more than 6 months, so I
>> would like to make a decision soon. If you have comments or concerns with
>> this request, please post them here by 6-March 2018.
> 
> Given the misissued certificates in CT under the existing root, I believe 
> this request should be rejected, and a new clean root with audits should be 
> required before moving forward.
> 
> The errors in the issued certificates indicate a lack of technical controls 
> in addition to improperly implemented certificate profiles. Given this, an 
> explanation should also be provided of what changes have been made to the 
> issuance environment to ensure these types of mistakes will not happen under 
> the new root.

I just took a closer look at the thread, and it appears that some misissuance 
was pointed out in July and most of the controls that were suggested as a 
solution relied on humans. These controls appear to have predictably failed, as 
multiple misissued certificates are from this fall, well after the fixes should 
have been in place.

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

Re: TunRootCA2 root inclusion request

[Jonathan Rudenberg via dev-security-policy]

> On Feb 27, 2018, at 16:17, Wayne Thayer via dev-security-policy 
>  wrote:
> 
> This request has been in public discussion for more than 6 months, so I
> would like to make a decision soon. If you have comments or concerns with
> this request, please post them here by 6-March 2018.

Given the misissued certificates in CT under the existing root, I believe this 
request should be rejected, and a new clean root with audits should be required 
before moving forward.

The errors in the issued certificates indicate a lack of technical controls in 
addition to improperly implemented certificate profiles. Given this, an 
explanation should also be provided of what changes have been made to the 
issuance environment to ensure these types of mistakes will not happen under 
the new root.

There are a bunch of warnings, but these jumped out at me as being very serious:

These certificates have a commonName that is not included as a dNSName SAN:

- https://crt.sh/?id=99182607=cablint
- https://crt.sh/?id=242366304=cablint

This certificate has a SAN with a domain ending in .local, which is a reserved 
special-use TLD:

- https://crt.sh/?id=79470561=cablint

It’s important to remember that these are only the certificates that we know 
about via CT. There may be certificates with similar or other issues that are 
not logged.

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

Re: TunRootCA2 root inclusion request

[Wayne Thayer via dev-security-policy]

This request has been in public discussion for more than 6 months, so I
would like to make a decision soon. If you have comments or concerns with
this request, please post them here by 6-March 2018.

On Tue, Feb 27, 2018 at 7:33 AM, Olfa Kaddachi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Dear Wayne,
>
> The TunRootCA2 root CA operates under the following CPS:
> http://www.certification.tn/pub/PC-PDC_AC_RACINE-NG-01-EN.pdf
> ==> The TunRootCA2 operates under a new version of the CP/CPS: :
> http://www.certification.tn/sites/default/files/documents/
> CPCPS-NG-EN-02.pdf
>
> The TunserverCA2 subordinate CA operates under a different CPS:
> http://www.certification.tn/sites/default/files/documents/
> CPCPS-PTC-BR-EN-05.pdf
> ==> The TunServerCA2’s subordinate CA operates under a new version of
> the CP/CPS : http://www.certification.tn/sites/default/files/documents/
> CPCPS-PTC-BR-EN-07.pdf
>
> These updated documents address the concerns I raised below.

>
> ==Good==
> * Misissued certificates reported earlier in this thread have been revoked
> ==> Yes. The RA of the TunServerCA2 has revoked all the misissued
> certificates and issued new ones for its clients.
>
> ==Meh==
> * Numerous warning level lint errors in issued certificates:
> https://crt.sh/?caid=5680=cablint,zlint,x509lint;
> minNotBefore=2017-01-01
> ==> 99182607 : The certificate has been issued on the 28th Feburary
> 2017 and was revoked the 03rd of March 2017.
> ==> 242366304 : The certificate has been issued on 25th October 2017
> and was revoked on the 02nd of November 2017.
> ==>201192937 : This is the certificate of the OCSP server which checks
> the status of the TLS/SSL certificates issued under TunServerCA2.
> * From the US, the server is returning an error or taking more than one
> minute to deliver the CRL at http://crl.certification.tn/TunServerCA2.crl
> (crt.sh is also timing out).
> ==> This problem has been resolved. The reason of this slowness was
> that during the last two weeks, we migrated to our new backup site.
> * The great majority of certificates issued by this CA fall under the .tn
> TLD; however, the Government of Tunisia has not requested that the root be
> constrained to issuance for .tn names.
> ==> Yes the great majority of certificates issued by this CA fall
> under the .tn TLD. However, this CA also issues certificates under others
> TLD like .com, .net and .org.
> * The subordinate CA certificate contains no EKU extension so is not
> constrained to issuing certain types of certificates.
> ==> Yes, the subordinate CA certificate doesn’t contain a EKU
> extension. TunServerCA2 signs SSL certificate, CRL and OCSP certificate.
> This subordinate contains Certificate Sign and CRL Sign key usage.
>
> * Delegated 3rd parties are permitted. The CPS does not clearly state the
> BR requirement that domain validation may not be performed by a delegated
> third party.
> ==> Yes the delegated 3rd parties are permitted. But, the domain
> validation is only performed by the CRA of TunServerCA2 (see section
> 1.3.2.2 of the new version of the CP/CPS).
> * The only method of domain validation specified in the BR Self Assessment
> is the now deprecated 3.2.2.4.5. How and when will the Government of
> Tunisia comply with CA/Browser Forum ballot 218?
> ==> See section 3.2.2 of the new version http://www.certification.tn/
> sites/default/files/documents/CPCPS-PTC-BR-EN-07.pdf.
> * The Government of Tunisia’s answer for wildcard domain validation in
> their BR Self Assessment implies the use of method 3.2.2.4.1, but they
> claim not to use that method in the same document.
> ==> See section 3.2.2 of the new version http://www.certification.tn/
> sites/default/files/documents/CPCPS-PTC-BR-EN-07.pdf.
> * CPS section 4.9.2 does not permit a person who controls a domain name
> contained in a certificate to request revocation unless they are the
> Subscriber or the Subscriber's legal representative.
> ==> Yes we confirm that TunServerCA2 does not permit that the person
> who controls the domain name to request revocation. Only the subscriber and
> the subscriber’s legal representative are allowed to request revocation.
>
> ==Bad==
> * Missing SAN entries: https://crt.sh/?cablint=25;
> iCAID=5680=2017-01-01 This CA continues to misissue
> certificates, so the manual controls described earlier in this thread are
> inadequate.
> ==> To resolve the missing SAN entries, a specific coding has been
> done this week on the RA scripts. The common name specified in the CSR is,
> from now on, automatically included in the SAN entries. In addition to
> that, a check of the issued certificate using the lintcert will be done by
> the operators before delivering the certificate to the RSC.
>

I think you meant "SCR" (i.e. Subscriber) not "RSC". Please be aware that
finding errors after a certificate is issued but before it is delivered to
the SCR/Subscriber is still 

RE: Allowing WebExtensions to Override Certificate Trust Decisions

[Tim Hollebeek via dev-security-policy]

Wow, this is a tough one.  I've wanted to write such an extension myself for
quite some time.  In fact, I probably would write one or more extensions, if 
Mozilla were to allow this, for a variety of use cases.
 
That said, such extensions are extremely dangerous, and users are just going
to accept any warning that might exist about using such an extension.  But I
don't think designing for the ignorant and clueless is wise.  You'll just find
better idiots.

I personally find persuasive the argument that an extension already has the
ability to do equivalently bad things.  The research group I used to work with
many years ago did lots of work with application extensions of all kinds, and
web extensions in particular were obscenely powerful because of the very
rich structure of the Document Object Model.

I'm sure (I hope!) things have been tightened up at least a little bit since 
then,
but I think in the presence of a malicious extension, the question of whether
it can affect the connection UI is rather moot.  Naïve users are going to lose
to a malicious extension every time, no matter what, and I seriously doubt
that even sophisticated users will have much of a chance in such scenarios,
whether the connection UI can be changed by the extension, or not.

It's probably useful to discuss this in conjunction with what controls Mozilla
has available in its ecosystem to combat malicious extensions in general,
as opposed to this particular case, which doesn't seem to be very special.
That more general question might lead to good principles that can be
applied in this specific situation.

Basically, I think it's a question of what the security model/policy for
extensions should be, how to balance the risks vs benefits of various pieces of
exposed functionality.  The tension between powerful, open APIs and
limited, but safer APIs has existed forever, and there isn't one point on
the spectrum that is optimal.

We recently had a case internally where some Office automation was not
possible due to some ad hoc restrictions imposed during the ILOVEYOU
era.  Addressing security risks piecemeal instead of holistically generally
results in a random set of arbitrary restrictions instead of a coherent
security model.  Figure out what the security policy and security model
is, and it will tell you whether allowing extensions to modify the connection
UI is ok.

-Tim

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of Wayne
> Thayer via dev-security-policy
> Sent: Tuesday, February 27, 2018 9:21 AM
> To: mozilla-dev-security-policy 
> 
> Subject: Allowing WebExtensions to Override Certificate Trust Decisions
> 
> I am seeking input on this proposal:
> 
> Work is underway to allow Firefox add-ons to read certificate information via
> WebExtensions APIs [1]. It has also been proposed [2] that the WebExtensions
> APIs in Firefox be enhanced to allow a 3rd party add-on to change or ignore 
> the
> normal results of certificate validation.
> 
> This capability existed in the legacy Firefox extension system that was
> deprecated last year. It was used to implement stricter security mechanisms
> (e.g. CertPatrol) and to experiment with new mechanisms such as Certificate
> Transparency and DANE.
> 
> When used to override a certificate validation failure, this is a dangerous
> capability, and it’s not clear that requiring a user to grant permission to 
> the
> add-on is adequate protection. One solution that has been proposed [4] is to
> allow an add-on to affect the connection but not the certificate UI.
> In other words, when a validation failure is overridden, the page will load 
> but
> the nav bar will still display it as a failure.
> 
> I would appreciate your constructive feedback on this decision. Should this
> capability be added to the Firefox WebExtensions APIs?
> 
> - Wayne
> 
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1322748
> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1435951
> [3] https://mail.mozilla.org/pipermail/dev-addons/2018-
> February/003629.html
> [4] https://mail.mozilla.org/pipermail/dev-addons/2018-
> February/003641.html
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-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: Allowing WebExtensions to Override Certificate Trust Decisions

[Matthew Hardeman via dev-security-policy]

Altering the security UI based on a third party extension seems risky in
either direction.

If a broad pinning scheme was unlikely to cause problems, HPKP would still
be a thing.  Other criteria for stricter than standard validation seem hard
to guarantee over the long haul also.

Even if a whole separate permission can be affirmatively gained from the
user at extension install/update time, the amount of UI engagement and
critical thinking from the user is significant.  Most people would just say
yes, rather than attempt to understand the risk/reward.

You could always do something ridiculous, along the lines of a "Mavis
Beacon Teaches Typing" thing which forces you to literally type in several
sentences as you read them on-screen (at a human pace -- no copy-paste)
acknowledging exactly what it is that you're granting permission to do and
how the user must be smarter than the firefox people.  In fact, the last
thing the user should have to type would be something like "I believe I am
smarter than the Firefox people, and that I can pick and choose who to
trust as well as who to delegate trust decisions to better than the Firefox
people are able.  Grant the permission."

But it seems far easier to just say no.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Allowing WebExtensions to Override Certificate Trust Decisions

[Ryan Sleevi via dev-security-policy]

Chrome has, to date, intentionally rejected the ability of extensions to
modify the connection security attributes in this way.

Mozilla will need to make a call based on its trust of the extensions
ecosystem, the potential for harm, and the various other impacts. For
example, an extension that modified a trust decision favorably may cause a
resource to be cached on an otherwise-invalid connection, and that resource
will persist even if/when the extension is removed. Thus, remediation of a
'malicious' extension may imply eliminating all persistent storage of the
user - depending on what the intended level of remediation is. I don't know
if content-modification scripts are granted that same privilege.

It would similarly be worth thinking about how the user would be presented
to make such an informed decision about granting such an extension access.
Given the profound capabilities implied by certificate verification, and
the risks, Chrome has not yet supported a view that general users would be
able to have sufficient context to make an informed and reasonable decision.

That said, we're very supportive of proposals by EFF to expose
connection-level information (without the ability to impose decision making
capabilities) via the webRequest API, which I understand Mozilla has
implemented something similar?
https://groups.google.com/a/chromium.org/d/msg/security-dev/qdSaEtR2Sss/mxIytQdTCAAJ
includes one such discussion of the various tradeoffs implied.

On Tue, Feb 27, 2018 at 11:23 AM, Alex Gaynor via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> A reasonable compromise that jumps out to me is allowing extensions to make
> an otherwise-secure connection fail, but not allow them to rehabilitate an
> insecure connection. This would allow experimenting with stricter controls
> while avoiding some of the really scary risks.
>
> Alex
>
> On Tue, Feb 27, 2018 at 11:20 AM, Wayne Thayer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > I am seeking input on this proposal:
> >
> > Work is underway to allow Firefox add-ons to read certificate information
> > via WebExtensions APIs [1]. It has also been proposed [2] that the
> > WebExtensions APIs in Firefox be enhanced to allow a 3rd party add-on to
> > change or ignore the normal results of certificate validation.
> >
> > This capability existed in the legacy Firefox extension system that was
> > deprecated last year. It was used to implement stricter security
> mechanisms
> > (e.g. CertPatrol) and to experiment with new mechanisms such as
> Certificate
> > Transparency and DANE.
> >
> > When used to override a certificate validation failure, this is a
> dangerous
> > capability, and it’s not clear that requiring a user to grant permission
> to
> > the add-on is adequate protection. One solution that has been proposed
> [4]
> > is to allow an add-on to affect the connection but not the certificate
> UI.
> > In other words, when a validation failure is overridden, the page will
> load
> > but the nav bar will still display it as a failure.
> >
> > I would appreciate your constructive feedback on this decision. Should
> this
> > capability be added to the Firefox WebExtensions APIs?
> >
> > - Wayne
> >
> > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1322748
> > [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1435951
> > [3] https://mail.mozilla.org/pipermail/dev-addons/2018-
> > February/003629.html
> > [4] https://mail.mozilla.org/pipermail/dev-addons/2018-
> > February/003641.html
> > ___
> > 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: Allowing WebExtensions to Override Certificate Trust Decisions

[jomo via dev-security-policy]

IMHO it should be possible to affect the connection and the UI. This
would allow plug-ins for alternative certificate validation methods,
such as Convergence
(https://en.wikipedia.org/wiki/Convergence_%28SSL%29) / FreeSpeechMe
(https://bit.namecoin.org/freespeechme.html).

While I agree that it is a potentially dangerous capability, a bad
extension can already gain full access to a secure website's content.
Possibly the UI could reflect that an extension has changed the normal
validation result?

- jomo

On 27.2.18 17:20, Wayne Thayer via dev-security-policy wrote:
> I am seeking input on this proposal:
>
> Work is underway to allow Firefox add-ons to read certificate information
> via WebExtensions APIs [1]. It has also been proposed [2] that the
> WebExtensions APIs in Firefox be enhanced to allow a 3rd party add-on to
> change or ignore the normal results of certificate validation.
>
> This capability existed in the legacy Firefox extension system that was
> deprecated last year. It was used to implement stricter security mechanisms
> (e.g. CertPatrol) and to experiment with new mechanisms such as Certificate
> Transparency and DANE.
>
> When used to override a certificate validation failure, this is a dangerous
> capability, and it’s not clear that requiring a user to grant permission to
> the add-on is adequate protection. One solution that has been proposed [4]
> is to allow an add-on to affect the connection but not the certificate UI.
> In other words, when a validation failure is overridden, the page will load
> but the nav bar will still display it as a failure.
>
> I would appreciate your constructive feedback on this decision. Should this
> capability be added to the Firefox WebExtensions APIs?
>
> - Wayne
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1322748
> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1435951
> [3] https://mail.mozilla.org/pipermail/dev-addons/2018-February/003629.html
> [4] https://mail.mozilla.org/pipermail/dev-addons/2018-February/003641.html
> ___
> 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: Allowing WebExtensions to Override Certificate Trust Decisions

[Alex Gaynor via dev-security-policy]

A reasonable compromise that jumps out to me is allowing extensions to make
an otherwise-secure connection fail, but not allow them to rehabilitate an
insecure connection. This would allow experimenting with stricter controls
while avoiding some of the really scary risks.

Alex

On Tue, Feb 27, 2018 at 11:20 AM, Wayne Thayer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> I am seeking input on this proposal:
>
> Work is underway to allow Firefox add-ons to read certificate information
> via WebExtensions APIs [1]. It has also been proposed [2] that the
> WebExtensions APIs in Firefox be enhanced to allow a 3rd party add-on to
> change or ignore the normal results of certificate validation.
>
> This capability existed in the legacy Firefox extension system that was
> deprecated last year. It was used to implement stricter security mechanisms
> (e.g. CertPatrol) and to experiment with new mechanisms such as Certificate
> Transparency and DANE.
>
> When used to override a certificate validation failure, this is a dangerous
> capability, and it’s not clear that requiring a user to grant permission to
> the add-on is adequate protection. One solution that has been proposed [4]
> is to allow an add-on to affect the connection but not the certificate UI.
> In other words, when a validation failure is overridden, the page will load
> but the nav bar will still display it as a failure.
>
> I would appreciate your constructive feedback on this decision. Should this
> capability be added to the Firefox WebExtensions APIs?
>
> - Wayne
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1322748
> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1435951
> [3] https://mail.mozilla.org/pipermail/dev-addons/2018-
> February/003629.html
> [4] https://mail.mozilla.org/pipermail/dev-addons/2018-
> February/003641.html
> ___
> 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

Allowing WebExtensions to Override Certificate Trust Decisions

[Wayne Thayer via dev-security-policy]

I am seeking input on this proposal:

Work is underway to allow Firefox add-ons to read certificate information
via WebExtensions APIs [1]. It has also been proposed [2] that the
WebExtensions APIs in Firefox be enhanced to allow a 3rd party add-on to
change or ignore the normal results of certificate validation.

This capability existed in the legacy Firefox extension system that was
deprecated last year. It was used to implement stricter security mechanisms
(e.g. CertPatrol) and to experiment with new mechanisms such as Certificate
Transparency and DANE.

When used to override a certificate validation failure, this is a dangerous
capability, and it’s not clear that requiring a user to grant permission to
the add-on is adequate protection. One solution that has been proposed [4]
is to allow an add-on to affect the connection but not the certificate UI.
In other words, when a validation failure is overridden, the page will load
but the nav bar will still display it as a failure.

I would appreciate your constructive feedback on this decision. Should this
capability be added to the Firefox WebExtensions APIs?

- Wayne

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1322748
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1435951
[3] https://mail.mozilla.org/pipermail/dev-addons/2018-February/003629.html
[4] https://mail.mozilla.org/pipermail/dev-addons/2018-February/003641.html
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: TunRootCA2 root inclusion request

[Olfa Kaddachi via dev-security-policy]

Dear Wayne,

The TunRootCA2 root CA operates under the following CPS: 
http://www.certification.tn/pub/PC-PDC_AC_RACINE-NG-01-EN.pdf 
==> The TunRootCA2 operates under a new version of the CP/CPS: : 
http://www.certification.tn/sites/default/files/documents/CPCPS-NG-EN-02.pdf 

The TunserverCA2 subordinate CA operates under a different CPS: 
http://www.certification.tn/sites/default/files/documents/CPCPS-PTC-BR-EN-05.pdf
 
==> The TunServerCA2’s subordinate CA operates under a new version of the 
CP/CPS : 
http://www.certification.tn/sites/default/files/documents/CPCPS-PTC-BR-EN-07.pdf


==Good== 
* Misissued certificates reported earlier in this thread have been revoked 
==> Yes. The RA of the TunServerCA2 has revoked all the misissued 
certificates and issued new ones for its clients.

==Meh== 
* Numerous warning level lint errors in issued certificates: 
https://crt.sh/?caid=5680=cablint,zlint,x509lint=2017-01-01 
==> 99182607 : The certificate has been issued on the 28th Feburary 2017 
and was revoked the 03rd of March 2017. 
==> 242366304 : The certificate has been issued on 25th October 2017 and 
was revoked on the 02nd of November 2017.
==>201192937 : This is the certificate of the OCSP server which checks the 
status of the TLS/SSL certificates issued under TunServerCA2. 
* From the US, the server is returning an error or taking more than one minute 
to deliver the CRL at http://crl.certification.tn/TunServerCA2.crl (crt.sh is 
also timing out). 
==> This problem has been resolved. The reason of this slowness was that 
during the last two weeks, we migrated to our new backup site.
* The great majority of certificates issued by this CA fall under the .tn TLD; 
however, the Government of Tunisia has not requested that the root be 
constrained to issuance for .tn names. 
==> Yes the great majority of certificates issued by this CA fall under the 
.tn TLD. However, this CA also issues certificates under others TLD like .com, 
.net and .org.
* The subordinate CA certificate contains no EKU extension so is not 
constrained to issuing certain types of certificates. 
==> Yes, the subordinate CA certificate doesn’t contain a EKU extension. 
TunServerCA2 signs SSL certificate, CRL and OCSP certificate. This subordinate 
contains Certificate Sign and CRL Sign key usage.

* Delegated 3rd parties are permitted. The CPS does not clearly state the BR 
requirement that domain validation may not be performed by a delegated third 
party. 
==> Yes the delegated 3rd parties are permitted. But, the domain validation 
is only performed by the CRA of TunServerCA2 (see section 1.3.2.2 of the new 
version of the CP/CPS).
* The only method of domain validation specified in the BR Self Assessment is 
the now deprecated 3.2.2.4.5. How and when will the Government of Tunisia 
comply with CA/Browser Forum ballot 218? 
==> See section 3.2.2 of the new version 
http://www.certification.tn/sites/default/files/documents/CPCPS-PTC-BR-EN-07.pdf.
* The Government of Tunisia’s answer for wildcard domain validation in their BR 
Self Assessment implies the use of method 3.2.2.4.1, but they claim not to use 
that method in the same document. 
==> See section 3.2.2 of the new version 
http://www.certification.tn/sites/default/files/documents/CPCPS-PTC-BR-EN-07.pdf.
* CPS section 4.9.2 does not permit a person who controls a domain name 
contained in a certificate to request revocation unless they are the Subscriber 
or the Subscriber's legal representative. 
==> Yes we confirm that TunServerCA2 does not permit that the person who 
controls the domain name to request revocation. Only the subscriber and the 
subscriber’s legal representative are allowed to request revocation.

==Bad== 
* Missing SAN entries: 
https://crt.sh/?cablint=25=5680=2017-01-01 This CA continues 
to misissue certificates, so the manual controls described earlier in this 
thread are inadequate. 
==> To resolve the missing SAN entries, a specific coding has been done 
this week on the RA scripts. The common name specified in the CSR is, from now 
on, automatically included in the SAN entries. In addition to that, a check of 
the issued certificate using the lintcert will be done by the operators before 
delivering the certificate to the RSC.
==> * The current subordinate CA CPS is dated October-2016. The current 
root CPS is dated July-2015. Mozilla policy requires annual CPS updates.
==> The revision dates of the subordinate CA CPS are: the 26th of June 
2015, 28th of July 2015, 21st of  October 2015, 21st of January 2016, 12th of 
February 2016, 18th of October 2016, 27th of  November 2017 and 27th of 
February 2018. 
==> The revision dates of the root CPS are : 01st of june 2015, 28th of 
july 2015 and 27th of November 2017.
In the future, both of the TunRootCA2 and TunServerCA2 CPSs  will be reviewed 
at least once a year to meet the requirement of the Mozilla policy.  

* The CPS does not comply