Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

[Ryan Sleevi via dev-security-policy]

On Tue, Jul 7, 2020 at 10:36 PM Matt Palmer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Mon, Jul 06, 2020 at 10:53:50AM -0700, zxzxzx9--- via
> dev-security-policy wrote:
> > Can't the affected CAs decide on their own whether to destroy the
> > intermediate CA private key now, or in case the affected intermediate CA
> > private key is later compromised, revoke the root CA instead?
>
> No, because there's no reason to believe that a CA would follow through on
> their decision, and rapid removal of trust anchors (which is what "revoke
> the root CA" means in practice) has all sorts of unpleasant consequences
> anyway.
>

Er, not quite?

I mean, yes, removing the root is absolutely the final answer, even if
waiting until something "demonstrably" bad happens.

The question is simply whether or not user agents will accept the risk of
needing to remove the root suddenly, and with significant (e.g. active)
attack, or whether they would, as I suggest, take steps to remove the root
beforehand, to mitigate the risk. The cost of issuance plus the cost of
revocation are a fixed cost: it's either pay now or pay later. And it seems
like if one needs to contemplate revoking roots, it's better to do it
sooner, than wait for it to be an inconvenient or inopportune time. This is
why I meant earlier, when I said a solution that tries to wait until the
'last possible minute' is just shifting the cost of misissuance onto
RPs/Browsers, by leaving them to clean up the mess. And a CA that tries to
shift costs onto the ecosystem like that seems like it's not a CA that can
be trusted to, well, be trustworthy.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

[Matt Palmer via dev-security-policy]

On Mon, Jul 06, 2020 at 10:53:50AM -0700, zxzxzx9--- via 
dev-security-policy wrote:
> Can't the affected CAs decide on their own whether to destroy the
> intermediate CA private key now, or in case the affected intermediate CA
> private key is later compromised, revoke the root CA instead?

No, because there's no reason to believe that a CA would follow through on
their decision, and rapid removal of trust anchors (which is what "revoke
the root CA" means in practice) has all sorts of unpleasant consequences
anyway.

- Matt

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

Re: Audit Reminders for Intermediate Certs

[Kathleen Wilson via dev-security-policy]

 Forwarded Message 
Subject: Summary of July 2020 Outdated Audit Statements for Intermediate 
Certs

Date: Tue, 7 Jul 2020 14:00:11 + (GMT)


CA Owner: Government of Taiwan, Government Root Certification Authority 
(GRCA)

   - Certificate Name: 行政院工商憑證管理中心 (MOEACA)
SHA-256 Fingerprint: 
90FFC5150CE0535069E7E5EF961E4047FB0861A140732C8CEDC7E8D58EB59BD1

Standard Audit Period End Date (mm/dd/): 03/31/2019
BR Audit Period End Date (mm/dd/): 03/31/2019

   - Certificate Name: 行政院內政部憑證管理中心 (MOICA)
SHA-256 Fingerprint: 
45111450FB31EF5137E4B7CFF9EE2BEF23E8BBFD165086DFBD93DF2F329B785E

Standard Audit Period End Date (mm/dd/): 03/31/2019
BR Audit Period End Date (mm/dd/): 03/31/2019

   - Certificate Name: 行政院醫事憑證管理中心 (HCA)
SHA-256 Fingerprint: 
A05EE43E556C8C2A38766D0377FB486806D169EA195E69CD873381D8EAB7DFCD

Standard Audit Period End Date (mm/dd/): 03/31/2019


Comments on Government Root Certification Authority - Taiwan:
CKA_NSS_SERVER_DISTRUST_AFTER set to 9/19/2019 in NSS 3.53, Firefox 78.
https://bugzilla.mozilla.org/show_bug.cgi?id=1621159
Email trust bit disabled in NSS 3.54, Firefox 79.
https://bugzilla.mozilla.org/show_bug.cgi?id=1621151


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

Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

[zxzxzx66669--- via dev-security-policy]

On Thursday, July 2, 2020 at 12:06:22 AM UTC+3, Ryan Sleevi wrote:
> Unfortunately, revocation of this certificate is simply not enough to
> protect Mozilla TLS users. This is because this Sub-CA COULD provide OCSP
> for itself that would successfully validate, AND provide OCSP for other
> revoked sub-CAs, even if it was revoked.

If I understand correctly, the logic behind the proposal to destroy 
intermediate CA private key now, is to avoid a situation that in case this 
intermediate CA private key is later compromised the intermediate CA becomes 
non-revocable until it expires.

So the action now is required to mitigate a potential security risk that can 
materialize later.

Can't the affected CAs decide on their own whether to destroy the intermediate 
CA private key now, or in case the affected intermediate CA private key is 
later compromised, revoke the root CA instead?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: 398 Cert Life span 1Sep2020

[Mark Goodwin via dev-security-policy]

Hi,

I can't answer for any of the vendors but I've read around this a bit;
perhaps the following will be of some use:

The Apple announcement states that the change affects "only TLS server
certificates issued from the Root CAs preinstalled with iOS" - therefore, I
think it's safe to assume locally added roots (from Internal CAs) will be
unaffected.

The Chromium change also appears to only apply to certs from known roots (
https://source.chromium.org/chromium/chromium/src/+/master:net/cert/cert_verify_proc.cc;l=682?q=HasTooLongValidity=chromium
) so Chrome, Edge and other Chromium based browsers look to be the same
story.

Kind regards,

Mark



On Mon, 6 Jul 2020 at 15:07, marc.rnlds--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hi All,
>
> How will internal CA's be affected.
>
>
> If I issue or have issued 2 years certificates, how will the browsers
> treat these certificates ?
>
>
> Just after guidance ..
>
> M
> ___
> 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: Change of Root ownership structure

[Arnold Essing via dev-security-policy]

We would like to inform you that our transition from "T-Systems International 
GmbH" to "Deutsche Telekom Security GmbH" has been finalized on July 1, 2020.
This has been discussed in this mailing list in the time period of April 27th 
to May 26th,2020: 
https://groups.google.com/d/msg/mozilla.dev.security.policy/pOu_jWY0SVY/9HnbIjaiAwAJ
Our CP, CPS and other documents have all been updated and published 
accordingly. Our Audit Attestations will be updated soon.
Thanks to Kathleen Wilson for carrying out the necessary changes in the CCADB.
Since July 1st 2020, our Trust Center also received a new homepage 
(www.telesec.de). The English version of that homepage is still under 
construction for which we want apologize.
Due to "Deutsche Telekom Security GmbH" being quite a long term we plan to use 
our short name "Telekom Security" whenever possible.



-Ursprüngliche Nachricht-
Von: dev-security-policy  Im 
Auftrag von Arnold Essing via dev-security-policy
Gesendet: Montag, 27. April 2020 06:45
An: mozilla-dev-security-pol...@lists.mozilla.org
Betreff: Change of Root ownership structure

This message is addressed to the CA/Browser community in relation to the 
request for transfer of root ownership. The root ownership will change from 
"T-Systems International GmbH" to "Deutsche Telekom Security GmbH". Both units 
are 100% subsidiary of the "Deutsche Telekom AG". In accordance with the 
Mozilla Root Store 
Policy
 (section 8.1), we would like to inform you and wish to start a public 
discussion.

The internal ownership structure of the two public roots "T-TeleSec GlobalRoot 
Class 2" and "T-TeleSec GlobalRoot Class 3" from T-Systems International GmbH 
is planned to change on July 1, 2020.  The ownership will remain within the 
company "Deutsche Telekom AG". The CA's operation team, Root decision makers 
and Top Level Management will not change. There will be no material or 
technical location changes. It is planned to transfer via spin-off agreement.

Some information concerning the new company for security, "Deutsche Telekom 
Security GmbH":
   Deutsche Telekom Security GmbH
   Bonner Talweg 100
   53113 Bonn
   The company is based at the Bonn District Court (Amtsgericht Bonn), under 
HRB 15241.
   The spin-off and transfer of the Security subordinate operation as an 
operational business (contracts, employees, property, etc.) from T-Systems 
International GmbH to Deutsche Telekom Security GmbH is planned for July 1, 
2020.
   This will become effective once the secession has been entered in the 
commercial register.

We plan to update and publish our CP/CPS documents for the time the changes 
become effective. At the moment there are no anticipated changes to the CP/CPS 
updates for July 1, 2020 other than the new organization name and address.

We will inform you once the transition has been finalized in accordance with 
the German Reorganization and Transformation Act (UmwG). The projected date is 
July 1, 2020.

Please contact us if you have any questions or if more information is needed.

Best regards,
T-Systems Root Team


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