Re: New Blog Post on 398-Day Certificate Lifetimes

[Ben Wilson via dev-security-policy]

Dear Steven,
CA certificates can have a validity longer than 398 days. The policy
applies to the validity period of TLS server certificates. At the CA level,
it will be enforced as a compliance issue in the root store when we accept
or remove a root CA in the "publicly trusted" root store. It will also be
enforced at the server-certificate level, through the incident-reporting
process and treated as a mis-issuance. See
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#24-incidents.
However, if a user installs its own CA certificate, then that CA can issue
server certificates with validity longer than 398 days. The code will check
the TLS server certificate to see if it chains to a publicly trusted root
and whether it was issued on or after 1-Sept-2020. If so, then if it does
not have a lifetime of less than 398 days, the TLS connection will be
blocked and there will be a warning message. See
https://bugzilla.mozilla.org/show_bug.cgi?id=908125
Does that answer your question?
Thanks,
Ben

On Tue, Aug 25, 2020 at 10:42 AM None Of via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Tuesday, July 14, 2020 at 2:13:30 PM UTC-4, Ben Wilson wrote:
> > Hi Christian,
> > I think your concern is about how our code will enforce this. Because
> our
> > policy only applies to roots that are built in, our intent is to have
> our
> > code apply this restriction only to certificates that chain up to
> built-in
> > roots.
> > Thanks,
> > Ben
> > On Mon, Jul 13, 2020 at 10:37 PM Christian Felsing via
> dev-security-policy <
> > dev-secur...@lists.mozilla.org> wrote:
> >
> > > Am 09.07.2020 um 17:46 schrieb Ben Wilson via dev-security-policy:
> > > >
> > >
> https://blog.mozilla.org/security/2020/07/09/reducing-tls-certificate-lifespans-to-398-days/
> > >
> > > Hi,
> > >
> > > blog post should clarify if this is valid for certificates issued by
> > > preinstalled root CAs only or also for CAs installed by user.
> > >
> > >
> > > regards
> > > Christian
> > > ___
> > > dev-security-policy mailing list
> > > dev-secur...@lists.mozilla.org
> > > https://lists.mozilla.org/listinfo/dev-security-policy
> > >
> Hello Ben,
>
> I also would like clarification as to whether this change is an
> "administrative change" for Mozilla accepting CAs in the included root
> store, or whether it will be a technical change in how Firefox validates CA
> certificate validity.
>
> If users install a CA cert that has a validity longer than 398 days after
> 1 Sept 2020, will this cause warning messages to appear?
> ___
> 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: New Blog Post on 398-Day Certificate Lifetimes

[None Of via dev-security-policy]

On Tuesday, July 14, 2020 at 2:13:30 PM UTC-4, Ben Wilson wrote:
> Hi Christian, 
> I think your concern is about how our code will enforce this. Because our 
> policy only applies to roots that are built in, our intent is to have our 
> code apply this restriction only to certificates that chain up to built-in 
> roots. 
> Thanks, 
> Ben
> On Mon, Jul 13, 2020 at 10:37 PM Christian Felsing via dev-security-policy < 
> dev-secur...@lists.mozilla.org> wrote: 
> 
> > Am 09.07.2020 um 17:46 schrieb Ben Wilson via dev-security-policy: 
> > > 
> > https://blog.mozilla.org/security/2020/07/09/reducing-tls-certificate-lifespans-to-398-days/
> >  
> > 
> > Hi, 
> > 
> > blog post should clarify if this is valid for certificates issued by 
> > preinstalled root CAs only or also for CAs installed by user. 
> > 
> > 
> > regards 
> > Christian
> > ___ 
> > dev-security-policy mailing list 
> > dev-secur...@lists.mozilla.org 
> > https://lists.mozilla.org/listinfo/dev-security-policy 
> >
Hello Ben,

I also would like clarification as to whether this change is an "administrative 
change" for Mozilla accepting CAs in the included root store, or whether it 
will be a technical change in how Firefox validates CA certificate validity.  

If users install a CA cert that has a validity longer than 398 days after 1 
Sept 2020, will this cause warning messages to appear?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Concerns with Let's Encrpyt repeated issuing for known fraudulent sites

[nathali...--- via dev-security-policy]

Apologies for triggering such a controversial discussion. Just to be clear, my 
original post was not directed at discrediting any practice of a CA, but rather 
to trigger discussion about what is/should be/will be the best option to solve 
the issue.

> >> Why not just do the right thing? 
> > The domain you send your emails from is, as far as I can tell, at 
> > least as much in breach of Germany's "Telemediengesetz" ("Tele media 
> > law") as a CA is of identity theft.
> That would raise a very involved question of international jurisdiction 
> that was not raised by the original question of a U.S. CA under the law 
> of a U.S. state. 
> > ...Why even think about whether the CA is legally bound by a German
> > court-order when it could ***just do the right thing***?
> Please tell us, counseller, what "the right thing" is? I think there's a 
> big difference between 
> 
> (1) a CA refusing to take action following a report that one of its 
> certs is being used to perpetrate fraud (my hypo); and 
> 
> (2) a CA taking no pre-emptive action regarding a supposed technical 
> violation of a labelling requirement for which no specific section of 
> law has been cited, and which "violation" makes no real difference to 
> how anyone interacts with the "violating" site or in the services (if 
> any) that it provides to people who visit it (your hypo). 

For post-issuing, this may be a solution in my opinion for damage containment. 
But, and that is what bothers me more, it is a reactive measure. Shouldn't we 
think and aim at  a preventive measure by solving the root cause?
Trust into such a phishing site is given by the DV certificate issued. The 
basis for issuing is that the ownership of the domain is confirmed. So, any 
user on the Internet is suggested to trust that the domain really has been 
verified as being the domain it is. And here, I guess the discrepancy happens. 
Domain validation means only it is controlled by whoever registered it. No 
statement on validation of any other attributes is given, although it is 
suggested that if it has "credit-suisse" in the name, it should belong to this 
financial institution. So, the root cuase in my opinion is that the validation 
method suggests more than it is. So as a solution we either make that clear to 
the user (what she/he gets trustwise with this certificate; certainly not easy 
to do) or we think about improving the validation so that the user gets 
validation for whats she/he expects to get which probably means that only OV or 
EV or QWAC will be needed, or we work on how we revoke such certificates in a
 n efficient manner (probably by an according change in the BRGs).

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

Plans for new ECDSA root and new intermediates from Let's Encrypt

[Jacob Hoffman-Andrews via dev-security-policy]

Let’s Encrypt is planning to issue a new root and new intermediates soon.
The new root will be an ECDSA one, to augment our existing RSA root. The
new intermediates will be part of our regular replacement of intermediates.
Our RSA root will cross-sign the ECDSA root.

We’re sharing our detailed issuance plans, including certificate profiles
and the tools we will use to generate the certificates. This is in the
spirit of transparency and also to get feedback from the community about
our plans.

Originally posted at
https://community.letsencrypt.org/t/detailed-2020-hierarchy/131019:

I’ve put together a detailed demonstration at
https://github.com/letsencrypt/2020-hierarchy-demo. I’ve attached sample
output from a run here, along with OpenSSL textual output. If you see any
flaws, please let us know!


Notable things:

   -

   We’re continuing to use X1 / X2 to identify roots.
   -

   We’re using O=Let’s Encrypt, CN=E1, E2, R3, and R4 to identify
   intermediates, where E/R indicates the key type, and we chose
   non-overlapping numbers across key types to make the names even easier to
   visually distinguish.
   -

   We’re using P-384 for our ECDSA hierarchy. We will continue to issue
   both P-256 and P-384 end-entity (leaf) certificates.
   -

   Per Ballot SC31 , we are
   not including OCSP URLs in our intermediates. This makes them smaller (for
   faster handshakes) and also simplifies our operations. The ballot has
   passed. We plan to perform the ceremony after the ballot’s review period
   has also passed and it takes effect.
   -

   We’re adopting a new domain for URLs in certificates: lencr.org. This
   saves some bytes.
   -

   For intermediates, we are just including CPS OIDs, not CPS URLs. Our
   end-entity certificates contain our CPS URL, so including it in the
   intermediates uses bytes unnecessarily.


The below is sample output from our demonstration:

root-x2.cert.pem.txt:

```text

Certificate:

Data:

Version: 3 (0x2)

Serial Number:

0d:e3:b6:d6:c3:12:af:10:9c:8b:74:de:8b:3a:97:a0

Signature Algorithm: ecdsa-with-SHA384

Issuer: C = US, O = Let's Encrypt, CN = (FAKE) Let's Encrypt Root X2

Validity

Not Before: Sep  4 00:00:00 2020 GMT

Not After : Sep 17 16:00:00 2040 GMT

Subject: C = US, O = Let's Encrypt, CN = (FAKE) Let's Encrypt Root
X2

Subject Public Key Info:

Public Key Algorithm: id-ecPublicKey

Public-Key: (384 bit)

pub:

04:aa:a9:a7:6e:c0:cd:01:16:af:60:ba:35:ea:d9:

02:8e:fb:ec:b8:c9:9f:a6:5c:50:f4:fc:25:99:af:

76:4c:22:50:8d:62:86:1d:51:58:b9:2d:39:dc:1a:

ca:76:1d:44:83:6c:93:94:01:b1:e3:9c:27:d6:e8:

61:ac:ab:bc:7f:4e:7f:d9:8a:43:d5:57:dd:72:87:

70:1c:25:c7:41:78:ad:ce:58:86:79:61:ff:ee:a3:

2b:9c:c3:5f:9d:b7:36

ASN1 OID: secp384r1

NIST CURVE: P-384

X509v3 extensions:

X509v3 Key Usage: critical

Certificate Sign, CRL Sign

X509v3 Basic Constraints: critical

CA:TRUE

X509v3 Subject Key Identifier:

5B:BC:E1:46:F2:7B:A4:61:96:FA:28:A8:23:10:F5:BD:C2:CA:8F:E0

Signature Algorithm: ecdsa-with-SHA384

 30:65:02:31:00:d2:6c:91:04:a7:d6:21:73:d0:52:f1:68:eb:

 4b:34:98:9a:43:57:9d:fe:d2:61:fc:c0:c1:ec:5f:58:f6:c9:

 b9:ea:84:3e:1f:3a:20:e4:85:dd:72:36:00:53:1e:30:88:02:

 30:02:25:a3:c4:ac:6e:97:70:6f:b3:cd:4f:59:95:55:b9:e7:

 52:f1:4d:a6:a0:a3:07:77:40:d4:dc:05:7b:26:9e:b9:be:05:

 b9:0f:c0:5f:9e:cc:3a:1c:de:e7:8b:2b:93

```

x2-signed-by-x1.txt

```text

Certificate:

Data:

Version: 3 (0x2)

Serial Number:

07:d7:a2:bb:0c:dc:93:25:d0:be:e2:26:39:de:7b:d0

Signature Algorithm: sha256WithRSAEncryption

Issuer: C = US, O = Internet Security Research Group, CN = (FAKE)
ISRG Root X1

Validity

Not Before: Sep  4 00:00:00 2020 GMT

Not After : Sep 15 16:00:00 2025 GMT

Subject: C = US, O = Let's Encrypt, CN = (FAKE) Let's Encrypt Root
X2

Subject Public Key Info:

Public Key Algorithm: id-ecPublicKey

Public-Key: (384 bit)

pub:

04:77:df:ec:6c:fe:22:06:aa:2e:8f:54:ce:1d:30:

60:01:85:ca:92:d6:d6:3d:21:0f:e5:18:1b:d5:35:

a4:72:ad:2d:07:56:cc:fe:0c:f5:39:2b:da:1a:83:

bf:a2:1a:9d:96:a2:74:2d:01:84:32:30:35:e0:a1:

e4:8a:fe:7f:16:58:83:13:e2:49:f2:01:84:60:98:

ef:07:4f:3c:f6:0c:86:21:22:33:aa:4e:6d:45:01:

da:8b:98:fb:c8:db:a5

ASN1 OID: secp384r1

NIST CURVE: 

Re: CCADB Updates August 20-24: Policy Document Objects

[Kathleen Wilson via dev-security-policy]

The CCADB has been updated to enable many-to-many mapping between policy 
documents and root certificates.


If you run into any problems using the CCADB, please send an email to 
supp...@ccadb.org. We are already working to fix the 
AllCertificateRecordsCSVFormat report, which is currently messing up 
crt.sh/mozilla-disclosures.


Summary of the changes:

1) Root Certificate pages have a new 'Policy Documents' section. The old 
information is also still visible in the 'DEPRECATED: Policies and 
Practices Information' section.


2) Case pages:
- There's a new 'Policy Documents' section. The old information is also 
still visible in the 'DEPRECATED: Policies and Practices Information' 
section.

- Added button: 'Update Policy Documents'
- Updated Progress Bar and instructions at the top of the page
- Updated https://www.ccadb.org/cas/updates#instructions

3) Moved 'Document Repository' and 'Document Repository Description' 
fields from root certificate pages to CA Owner pages. For those of you 
with multiple document repository URLs, please send me email to let me 
know if you would like change the list in your CA Owner record.


Thanks,
Kathleen


On 8/13/20 4:35 PM, Kathleen Wilson wrote:

All,

Currently CCADB only allows for one CP URL and one CPS URL per root 
certificate, so we are updating the CCADB to enable many-to-many mapping 
between policy documents and root certificates. One or more policy 
documents may be provided and associated with one or more root 
certificates and policy OIDs. Screenshots showing the changes are here:


https://docs.google.com/document/d/1bhlCSLhdAfLa1J-ek7N3jupLRE630XOjqeNaMQ9lSsU/edit?usp=sharing 



We intend to migrate the changes to production August 20 to 24. You 
should be able to use the CCADB during this update, which will impact: 
CA Owner, Root Certificate, Audit Case, Root Inclusion Case.


There will be a one-time migration from existing fields to new Policy 
Document objects.


If you run into problems with the CCADB from August 20 to August 24, 
please try again later. If you run into problems with the CCADB after 
August 24, please send an email to supp...@ccadb.org.


Thanks,
Kathleen


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