RE: CCADB Proposal: Add field called Full CRL Issued By This CA

[Corey Bonnell via dev-security-policy]

Thanks for the additional context, Ben. Given the comment that you linked to, 
it appears that there’s a possibility that Mozilla will support sharded CRLs 
and that there may be logic included in the CRLLite crawler to timeout and 
remove the issuing CA from the crawler configuration if CRL-fetching times out.

 

I have a few follow-up questions and concerns:

1.  As we know from the list of Problem Reporting Mechanisms produced from 
CCADB, the information provided by CAs is on a “best-effort” basis that carries 
no obligation by the CA to timely respond to requests if the Mechanism is not 
listed in section 1.5.2 of their CPS. What policy changes will be formulated to 
obligate the CA to provide accurate URL pointers in CCADB where CRL-based 
revocation information can be found for end-entity certificates that have no 
CRLDP extension?
2.  What are the expectations regarding availability for such revocation 
information? Do the availability requirements in BR 4.10.2 stand for these CRLs 
even if such CRL pointers are not encoded in end-entity certificates?
3.  Is the JSON-based sharding specification acceptable by the other Root 
Programs, or will CAs be required to produce complete CRLs for consumption by 
other Root Programs?
4.  Given that CRLLite is not used in Thunderbird, it appears that the 
scope of disclosure is only for those CAs that are capable of TLS certificate 
issuance. Is this a correct assumption?

 

Thanks,

Corey 

 

From: Ben Wilson  
Sent: Thursday, November 19, 2020 6:14 PM
To: Ryan Hurst ; Corey Bonnell 

Cc: Mozilla 
Subject: Re: CCADB Proposal: Add field called Full CRL Issued By This CA

 

FWIW - Here is a recent post on this issue from JC Jones - 
https://github.com/mozilla/crlite/issues/43#issuecomment-726493990  
 

 

On Thu, Nov 19, 2020 at 4:00 PM Ryan Hurst via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org> > wrote:

On Wednesday, November 18, 2020 at 8:26:50 PM UTC-8, Ryan Sleevi wrote:
> On Wed, Nov 18, 2020 at 7:57 PM Ryan Hurst via dev-security-policy < 
> dev-secur...@lists.mozilla.org  > 
> wrote: 
> 
> > Kathleen, 
> > 
> > This introduces an interesting question, how might Mozilla want to see 
> > partial CRLs be discoverable? Of course, they are pointed to by the 
> > associated CRLdp but is there a need for a manifest of these CRL shards 
> > that can be picked up by CCADB? 
> >
> What's the use case for sharding a CRL when there's no CDP in the issued 
> certificates and the primary downloader is root stores?

I think there may be some confusion. In my response to Kathleen's mail I stated 
" Of course, they are pointed to by the associated CRLdp", as such I am not 
suggesting there is a value to sharded/partitioned CRLs if not referenced by 
the CRLdp.

The origin of my question is that as I remember the requirements, CAs do not 
have to produce a full and complete CRL. Specifically today, I believe they are 
allowed to produce partitioned CRLs, this is good because in some cases a full 
and complete CRL can be gigabytes in size. I assume the reason for adding the 
URL to a full, and I imagine complete, CRL is that Mozilla would like to use 
this information in its CRLLite feature.

If so, and a CA partitions CRLs and does not produce a full and complete CRL 
how should the CA ensure Mozilla has the entire set of information it wants?

Ryan
___
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: FNMT: Public Discussion of Root Inclusion Request

[Santiago Brox via dev-security-policy]

El jueves, 19 de noviembre de 2020 a las 0:47:03 UTC+1, Matthias van de Meent 
escribió:
> On Wed, 18 Nov 2020, 01:06 Ben Wilson via dev-security-policy, 
>  wrote: 
> > 
> > All, 
> > 
> > This is to announce the beginning of the public discussion phase of the 
> > Mozilla root CA inclusion process for Fábrica Nacional de Moneda y Timbre 
> > (FNMT)’s request to include the AC RAIZ FNMT-RCM SERVIDORES SEGUROS in the 
> > root store. See 
> > https://wiki.mozilla.org/CA/Application_Process#Process_Overview, (Steps 4 
> > through 9). 
> > 
> > Mozilla is considering approving FNMT’s request to add the root as a trust 
> > anchor with the websites trust bit and EV enabled as documented in Bugzilla 
> > bug 
> > #1559342 . 
> > 
> > This email begins the 3-week comment period, after which, if no concerns 
> > are raised, we will close the discussion and the request may proceed to the 
> > approval phase (Step 10). 
> >
> > [...]
> > 
> > *CP/CPS:* 
> > 
> > https://www.sede.fnmt.gob.es/documents/10445900/10536309/dpc_ss_english.pdf 
> > 
> > Current CPS is version 1.5, published 1-October-2020. 
> > 
> > Repository location: 
> > https://www.sede.fnmt.gob.es/normativa/declaracion-de-practicas-de-certificacion
> >  
> >
> I'm having trouble finding the end entity certificate profiles in this 
> CPS. According to the CPS s7.1.2, they are supposed to be available at 
> http://www.cert.fnmt.es/dpcs/, but that redirects me to a repository 
> [0] of which the only english-language document [1] does not contain 
> any end entity certificate profiles, but only the root and ICA 
> profiles in attachments. Similarly, I cannot find the CPS you linked 
> in their repository. 
> 
> I noticed that the CPS defers a great amount of sections (section 5, 
> 6.2, 6.4, 8.2 - 8.7 and large parts of section 9) to the DGPC, which 
> probably is [1] but that is never explicitly confirmed in the CPS - 
> there is no explicit link to any repository in section 1.6.1 where the 
> acronym is defined, nor are there any other indications that this DGPC 
> is located in the repository under the link of [0]. This is confusing, 
> and detrimental to the readability of the document. 
> 
> CPS s4.9.2 and s1.5.2 both mention that third parties may send 
> certificate problem reports, and select parties may send revocation 
> requests, which is great; but I cannot find a commitment to 
> communicating a preliminary report within 24 hours to the reporter as 
> stipulated by BR 4.9.5. 
> 
> CPS / DGPC s5.2.2 includes by reference an internal policy, which may 
> or may not comply with the "at least dual control for CA private key 
> backup/storage/recovery" requirement of BR 5.2.2. 
> 
> CPS / DGPC s5.3.1 only guarantee the "experience and knowledge", not 
> the "trustworthiness and identity" of the operators. 
> 
> CPS / DGPC s5.3.3 does not provide information on the specific topics 
> that are SHALL-qualified in BR s5.3.3. This same can be said about 
> s5.3.4 and s5.3.7. 
> 
> CPS / DGPC s5.4.1 does definately not mention logging 
> rejection/acceptance of certificate requests (BR s5.4.1(1)(3)), and 
> probably also doesn't cover some other parts, but the language is very 
> opaque (i.e. unclear). 
> ... looks further 
> ... those specific events are apparently included in 5.5.1 Types of 
> Records Archived (?) 
> 
> CPS / DGPC s5.4.3 does not comply with BR 5.4.3: Audit log retention 
> of 15 years is not enough to cover the CA certificate event record log 
> retention timespan of 2 years past the latest of 1.) the destruction 
> of the CA private key, and 2.) the revocation or expiration of the 
> final CA certificate of that private key. Unless of course you expect 
> to revoke the root and destroy the CA keys within 13 years after 
> creation. 
> 
> CPS / DGPC s6.1.1.1 (CA Key Pair Generation) fails to include the 
> procedure with which CA keys are generated. 
> More specifically, the current implication is that the auditor could 
> not be witness of the CA key generation ceremony, nor have seen any 
> evidence other than the report, and sign this report. This fails to 
> apply BR 6.1.1.1(1) items 2 and 3, and BR 6.1.1.1(2)(2). The procedure 
> included by reference is not accessible [3] and may add requirements, 
> but those requirements need not meet the baseline of the BR. 
> 
> CPS s6.2 points to a section s6.2 in the DGPC, which is blank. 
> Therefore, I'm missing the documentation on that the CA is committed 
> to securing the CA private key material in a BR-compliant manner. 
> 
> CPS / DGPC s6.2.4 does not apply the requirements of BR 6.2 nor 5.2.2 
> to their private key backup procedure. 
> 
> CPS delegates s6.2.5 fully to the DGPC, but that s6.2.5 requires the 
> CPS to at least specify a maximum number of copies of the private key, 
> which is not specified. 
> 
> CPS / DGPC s6.2.6 has the interesting construction "Consequently, the 
> Keys cannot be transferred, although 

Re: Microsec: Misissuance of 2 CISCO VPN server authentication certificates

[Sándor dr . Szőke via dev-security-policy]

See further information in the following Mozilla bug:

https://bugzilla.mozilla.org/show_bug.cgi?id=1676352
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CCADB Proposal: Add field called Full CRL Issued By This CA

[Ryan Hurst via dev-security-policy]

On Thursday, November 19, 2020 at 3:13:58 PM UTC-8, Ben Wilson wrote:
> FWIW - Here is a recent post on this issue from JC Jones - 
> https://github.com/mozilla/crlite/issues/43#issuecomment-726493990
> On Thu, Nov 19, 2020 at 4:00 PM Ryan Hurst via dev-security-policy < 
> dev-secur...@lists.mozilla.org> wrote: 
> 
> > On Wednesday, November 18, 2020 at 8:26:50 PM UTC-8, Ryan Sleevi wrote:
> > > On Wed, Nov 18, 2020 at 7:57 PM Ryan Hurst via dev-security-policy < 
> > > dev-secur...@lists.mozilla.org> wrote: 
> > > 
> > > > Kathleen, 
> > > > 
> > > > This introduces an interesting question, how might Mozilla want to see 
> > > > partial CRLs be discoverable? Of course, they are pointed to by the 
> > > > associated CRLdp but is there a need for a manifest of these CRL 
> > shards 
> > > > that can be picked up by CCADB? 
> > > > 
> > > What's the use case for sharding a CRL when there's no CDP in the issued 
> > > certificates and the primary downloader is root stores? 
> >
> > I think there may be some confusion. In my response to Kathleen's mail I 
> > stated " Of course, they are pointed to by the associated CRLdp", as such I 
> > am not suggesting there is a value to sharded/partitioned CRLs if not 
> > referenced by the CRLdp. 
> > 
> > The origin of my question is that as I remember the requirements, CAs do 
> > not have to produce a full and complete CRL. Specifically today, I believe 
> > they are allowed to produce partitioned CRLs, this is good because in some 
> > cases a full and complete CRL can be gigabytes in size. I assume the reason 
> > for adding the URL to a full, and I imagine complete, CRL is that Mozilla 
> > would like to use this information in its CRLLite feature. 
> > 
> > If so, and a CA partitions CRLs and does not produce a full and complete 
> > CRL how should the CA ensure Mozilla has the entire set of information it 
> > wants? 
> > 
> > Ryan
> > ___ 
> > dev-security-policy mailing list 
> > dev-secur...@lists.mozilla.org 
> > https://lists.mozilla.org/listinfo/dev-security-policy 
> >

I think the JSON array approach works and it addresses the concerns I had, 
specifically:
1. How do we make sure Mozilla has all the revocation data when a 
sharded/partitioned CRL approach is used.
2. How do we not force those CCAs that are doing sharded/partitioned CRLs from 
having to also maintain full CRLs which can be VERY big which has logistic 
challenges to distribute reliably and usably.

Maybe we can say such CAs provide a list to this JSON document in CCADB Full 
CRL field?

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