Re: FNMT Root Inclusion Request
Le mercredi 21 octobre 2015 21:18:26 UTC+2, Kathleen Wilson a écrit : > FNMT has applied to include the "AC RAIZ FNMT-RCM" root certificate and > enable the Websites trust bit. [...] > The request is documented in the following bug: > https://bugzilla.mozilla.org/show_bug.cgi?id=435736 [...] > Document Repository: > https://www.sede.fnmt.gob.es/normativa/declaracion-de-practicas-de-certificacion > CP: > https://www.sede.fnmt.gob.es/documents/11614/67070/dpc_componentes_english.pdf/ > > > CPS: https://www.sede.fnmt.gob.es/documents/11614/137578/dpc_english.pdf/ >From 31/10/2012, the CPS states that end-entity certificates are valid for a >maximum of 3 years. However, https://crt.sh/?id=8983568 shows a TLS server certificate valid for 4 years and delivered in 2015. > * CA Hierarchy > > ** This root has internally-operated subordinate CAs > - "AC Componentes Informáticos" issues certificates for SSL Servers and > code signing. > - "AC Administración Pública" is an updated version of the "APE CA" in > order to meet new requirements from Spanish Government about > certificates of Public Administrations. > - "APE CA" is no longer used. > > * This request is to enable the Websites trust bit. > > ** From dpc_componentes_english.pdf... > > > * EV Policy OID: Not applicable; not requesting EV treatment. > > * Root Cert URL: http://www.cert.fnmt.es/certs/ACRAIZFNMTRCM.crt > > * Test Website: https://www.sede.fnmt.gob.es/certificados The SubjectAlternativeName extension of this certificate contains a directoryName entry, this isn't BR-compliant (see section 7.1.4.2.1 of BR 1.3.1). Why did you include an anyExtendedKeyUsage OID in the EKU extension, in addition to the serverAuth? Do you also add this OID in non TLS server certificates? > * CRL > ldap://ldapape.cert.fnmt.es/CN=CRL164,CN=AC%20Administraci%F3n%20P%FAblica,OU=CERES,O=FNMT-RCM,C=ES?certificateRevocationList > ldap://ldapfnmt.cert.fnmt.es/CN=CRL,OU=AC%20RAIZ%20FNMT-RCM,O=FNMT-RCM,C=ES?authorityRevocationList; There's 228 CRLs for this subCA. All are correctly restricted with a critical IssuingDistributionPoints extension. Good luck for OneCRL/CRLSets maintainers. The LDAP URLs are non compliant, because of not being UTF8 (it's mandatory for LDAP), but I guess this isn't a problem for Mozilla's application. Anyway, any request returns an error because of this UTF8 problem. Change the "%F3" into "%C3%B3" and the "%FA" into "%C3%BA" for the URLs to work. Looking at the CRLs content shows that a lot of certificates don't have the required 20bits minimum entropy (the serial number is sometimes a monotonic sequence). Did this practice stop? For all Sub-CAs? If yes, when? > * OCSP > http://ocspape.cert.fnmt.es/ocspape/OcspResponder > http://ocspap.cert.fnmt.es/ocspap/OcspResponder These OCSP responders give a "good" answer for a nonexistent certificate. > * Audit: FNMT is audited annually by PWC according to the WebTrust CA > and WebTrust BR criteria. I exchanged email with the auditor to confirm > the authenticity of the audit statement at this URL: > https://www.cert.fnmt.es/documents/11601/4379265/auditReport_en.pdf ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Question: BR requirement about structuring CPS according to RFC 3647
On Mon, October 26, 2015 11:55 pm, mycho...@gmail.com wrote: > Korea has e-signature Act, Decree and Ordinance. E-Signature act also > contains several administration rules and one of administration rules is a > âguideline for CPSâ. Root CA/Sub-CAs controlled by government has to > follow the 'guideline for CPS' when build or revise its CPS. > > So, structure of contents in CPS is different from RFC 3647, however, all > contents required by RFC 3647 are contained. > > Minyoun It seems worthwhile to separate this out a little. You have a CA hierarchy, of which some CAs are subject to local law that conflicts with the Baseline Requirements and Mozilla CA policy. These CAs are not essential to your application - that is, there is no business reason or need for your e-signature intermediate to be included or recognized as trusted by Mozilla. Indeed, it would seem that, given the conflict, it would be desirable for your e-signature CA NOT to be trusted (transitively/indirectly), given that there are conflicting requirements. There seem to be two options to resolve this conflict: A) Mozilla accepts your local laws as superceding those of the Baseline Requirements and Mozilla Policy B) You adjust your application to only be for that of your SSL/website CA, rather than your root CA (government operated), which transitively includes your e-signature intermediate (subject to local laws regarding CPS structure) Option A has a number of downsides for Mozilla and the community that relies upon the Mozilla Trust Store. The most obvious is that it sets a framework for local jurisdictions to set requirements counter to Mozilla and that being acceptable. I would say that would significantly undermine trust in general in the Mozilla Root Store and its policies, so that would not be a desirable outcome. However, it also puts the burden of work on the Mozilla user community to review your application. While I'm sure there is genuine good faith belief that your CPS covers all of the necessary requirements of RFC 3647, that's a claim that will need to be independently evaluated by anyone who wishes to review your policy for conformance to the Baseline Requirements and to Mozilla policy. That is traditionally a significant amount of work, so it's somewhat of an unreasonable request for the community. Option B appears not to have been fully explored yet, so I'd like to spell out how that could look. This works by shifting the burden of work from the community (to map your CPS back to 3647) to your CA. Rather than applying for inclusion of your root (which is governed by your countries e-signature law), you should instead apply for inclusion of your SSL intermediate, treating it 'as if' it was a root that was cross-signed but otherwise independent. In doing so, you would also develop a separate CP/CPS for this intermediate. This CP/CPS would be in the form of RFC 3647, and would fully conform to the Baseline Requirements. When your CA is audited, you would have your e-signature root and intermediates audited to your e-signature requirements, and your SSL intermediate audited to your SSL CP/CPS (aka the Baseline Requirements and Mozilla Policy). Further, the onus of transliteration of your policies would shift from the community to you, as you would need to demonstrate to your auditor and the supervisors of the e-signature program that your RFC 3647-compliant policy is consistent with the overarching policies of your government-operated root. Option B is not a new option for CAs; indeed, it's what is practiced whenever a CA operates both public and private CA hierarchies that have different business needs/requirements, and arguably is quite similar to how commercial cross-signatures work, since multiple CPSes are in play, and each subordinate CPS needs to be consistent with the cross-signer's main CPS. It would be helpful to know why Option B would not be viable, or, if it is, why it wouldn't be desirable. It's understandable that we're talking about a spectrum of cost, and who bears that cost - whether the relying parties who participate in the maintenance of the Mozilla Root Store, or whether it's borne by the CA applying for inclusion. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Question: BR requirement about structuring CPS according to RFC 3647
Korea has e-signature Act, Decree and Ordinance. E-Signature act also contains several administration rules and one of administration rules is a ‘guideline for CPS’. Root CA/Sub-CAs controlled by government has to follow the 'guideline for CPS' when build or revise its CPS. So, structure of contents in CPS is different from RFC 3647, however, all contents required by RFC 3647 are contained. Minyoun 2015년 10월 23일 금요일 오전 10시 24분 59초 UTC+9, Moudrick M. Dadashov 님의 말: > eIDAS is becoming the only common Law on e-signatures (for the EU) and > I'm not aware of any regulation on mandatory CP/CPS structures. > > Thanks, > M.D. > > > On 10/22/2015 8:56 PM, Richard Barnes wrote: > > On Thu, Oct 22, 2015 at 1:42 PM, Kathleen Wilson > > wrote: > > > >> All, > >> > >> In section 2.2 of version 1.3 of the CA/Browser Forum's Baseline > >> Requirements, it says: > >> > >> "The disclosures MUST include all the material required by RFC 2527 or RFC > >> 3647, and MUST be structured in accordance with either RFC 2527 or RFC > >> 3647." > >> > >> Some government CAs are bound by local e-signature laws that include a > >> guideline for the structure of the CPS, which is not in line with RFC 3647. > >> > > E-signature seems like a different application from HTTPS. Are they really > > using the same CA for both? (That seems like a bad idea.) Or do these > > e-signature laws somehow also impinge on web certificates? > > > > --Richard > > > > > >> Would it be reasonable to allow an exception to this rule (structure CPS > >> according to RFC 36437)for government (non-commercial) CAs that are bound > >> by local law to use a different structure for their CPS? > >> > >> Would such an exception require that the the CA hierarchy be bound to > >> certain TLDs (e.g. country-specific, .gov)? > >> > >> Kathleen > >> > >> ___ > >> 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: Question: BR requirement about structuring CPS according to RFC 3647
Actually, I have been communicating with Kathleen about this issue. For your comments, two separate CAs (for user certificate and for SSL) are existed. Actually, e-Signature law doesn't mention of SSL directly. However, Root CA is controlled by government directly and government is likely to comply with current e- signature law regardless of certificate types. In this case, current CPS contains all contents comply with RFC 3647. Only structure of contents does not comply with RC 3647. Minyoun 2015년 10월 23일 금요일 오전 2시 56분 18초 UTC+9, Richard Barnes 님의 말: > On Thu, Oct 22, 2015 at 1:42 PM, Kathleen Wilson > wrote: > > > All, > > > > In section 2.2 of version 1.3 of the CA/Browser Forum's Baseline > > Requirements, it says: > > > > "The disclosures MUST include all the material required by RFC 2527 or RFC > > 3647, and MUST be structured in accordance with either RFC 2527 or RFC > > 3647." > > > > Some government CAs are bound by local e-signature laws that include a > > guideline for the structure of the CPS, which is not in line with RFC 3647. > > > > E-signature seems like a different application from HTTPS. Are they really > using the same CA for both? (That seems like a bad idea.) Or do these > e-signature laws somehow also impinge on web certificates? > > --Richard > > > > Would it be reasonable to allow an exception to this rule (structure CPS > > according to RFC 36437)for government (non-commercial) CAs that are bound > > by local law to use a different structure for their CPS? > > > > Would such an exception require that the the CA hierarchy be bound to > > certain TLDs (e.g. country-specific, .gov)? > > > > Kathleen > > > > ___ > > 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: SECOM Request for EV Treatment
Dear Ryan-san and public discussion members, The updated SECOM CP for Ryan-san's comment is attached to https://bugzilla.mozilla.org/show_bug.cgi?id=1096205 CP (English): https://bugzilla.mozilla.org/attachment.cgi?id=8679302 The addition for the section 2.2, 3.2.7 and 4.9.9 addressed with proposed update to the English version of CP. The corresponding section were made comprehensible by red characters. Thank you for your consideration. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: SECOM Request for EV Treatment
Dear Ryan-san and public discussion members, The updated SECOM CP for Ryan-san's comment is attached to https://bugzilla.mozilla.org/show_bug.cgi?id=1096205 CP (English): https://bugzilla.mozilla.org/attachment.cgi?id=8679302 The addition for the section 2.2, 3.2.7 and 4.9.9 addressed with proposed update to the English version of CP. The corresponding section were made comprehensible by red characters. Thank you for your consideration. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Let's Encrypt Root
On 2015-10-27 01:28, Peter Kurrasch wrote: I'd like to ask a question about technical constraints on the Let's Encrypt root but will wait until the appropriate time. You can always ask them questions directly. Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
