Re: FNMT: Public Discussion of Root Inclusion Request

[Ben Wilson via dev-security-policy]

 FNMT provided the following clarification regarding its audits:

*Audits:* Annual audits are performed by AENOR Internacional. The most
recent audit was completed by AENOR, for the period ending January 12,
2020, according to ETSI EN 319 411-1 audit criteria (OVCP: Organizational
Validation Certificate Policy).
https://www.aenor.com/Certificacion_Documentos/eiDas/2020%20AENOR%20Anexo%201%20ETSI%20319%20411-2%20PSC-2019-003%20-%20FNMT-v2.pdf

It is mentioned that the audit was performed according to ETSI EN 319
411-1, but the link is the one for our audit ETSI 319 411-2 for QCP-w; EVCP:
Policy for EU qualified website certificate issued to a legal person and
linking the website to that person

Our root is being audited according to both ETSI EN 319 411-2 and ETSI 319
411-1 since we have 2 dedicated subordinate CA: AC Servidores Tipo 1 - for
EVCP and AC Servidores Tipo 2 - for OVCP

https://www.aenor.com/Certificacion_Documentos/eiDas/2020%20AENOR%20Anexo%202%20ETSI%20319%20411-1%20PSC-2019-003%20-%20FNMT-v2.pdf


On Tue, Nov 17, 2020 at 5:06 PM Ben Wilson  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).
>
> *A Summary of Information Gathered and Verified appears here in the CCADB:*
>
>
> https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=0418
>
> *AC RAIZ FNMT-RCM SERVIDORES SEGUROS* is valid from 12/20/2018 to
> 12/20/2043
>
> SHA2 Certificate Hash:
> 554153B13D2CF9DDB753BFBE1A4E0AE08D0AA4187058FE60A2B862B2E4B87BCB
>
> https://crt.sh/?id=1490711558
>
> *Root Certificate Download:*
>
>
> https://www.sede.fnmt.gob.es/documents/10445900/10526749/AC_Raiz_FNMT-RCM-SS.cer
>
>
> *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
>
> *2020 BR Self Assessment* (pdf) is located here:
>
> https://bugzilla.mozilla.org/attachment.cgi?id=9179612
>
> *Audits:*  Annual audits are performed by AENOR Internacional. The most
> recent audit was completed by AENOR, for the period ending January 12,
> 2020, according to ETSI EN 319 411-1 audit criteria (OVCP: Organizational
> Validation Certificate Policy).
> https://www.aenor.com/Certificacion_Documentos/eiDas/2020%20AENOR%20Anexo%201%20ETSI%20319%20411-2%20PSC-2019-003%20-%20FNMT-v2.pdf
>  The audit found “All the minor non-conformities have been scheduled to
> be addressed in the corrective action plan of the Trust Service Provider.
> No critical non-conformities were identified.”  Remediation of the minor
> conformities was discussed in Bug # 1626805
> .
>
> *Incident Reports / Mis-Issuances *
>
> *The following bugs/incidents (closed) have been reported. *
>
> Bug 1495507  (filed
> 10/1/2018) OU field exceeding 64 characters
>
> Bug 1544586  (filed
> 4/15/2019) 2019 audit findings
>
> Bug 1596949  (filed
> 11/15/2019) CP/CPS lack CAA processing details
>
> Bug 1626805  (filed
> 4/1/2020) 2020 audit findings
>
> No misissuances were found under this root, and certificates issued under
> it have passed testing.
>
> Revocation checking at
> https://certificate.revocationcheck.com/testactivetipo1.cert.fnmt.es
> appears to work fine, except there are a few error messages -- "one of the
> certificates in the chain could not be checked", "Valid signature but
> response includes an unnecessary certificate chain" and "Certificate status
> is 'Revoked' expecting 'Unknown'".  Hopefully, these errors can be
> explained or remedied. Otherwise, I have no further questions or concerns
> at this time.
>
> I urge anyone with any additional concerns or questions to raise them on
> this list by replying under the subject heading above.
>
> Pursuant to Step 5 - "A representative of the CA responds to questions and
> concerns posted during the public discussion of the CA's request."
>
> Again, this email begins a three-week public discussion period, which I’m
> scheduling to close on or about 

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

[Nils Amiet via dev-security-policy]

> I realize this is almost entirely critical, and I hope it's taken as
> critical of the proposal, not of the investment or interest in this space.

Not a problem for being critical and we don’t take it personally. We
appreciate the discussion, the time you spend and the opportunity to propose
different approaches to solving this issue.

Our goal is not to defend non-compliant or insecure practices. Quite the
opposite, with our research we hope to find a solution that leads in certain
constellations to a quicker resolution while rewarding projects that follow the
standards. We don’t want to promote our proposal as a better proposal for all
possible constellations, but we believe it can in certain situations be as
secure and more practical as the original proposal on this mailing list.

We have carefully read your email, and believe we’ve identified the following
important points:

1. Potential feasibility issue due to lack of path building support

2. Non-robust CRL implementations may lead to security issues

3. Avoiding financial strain is incompatible with user security.

If we have missed one or misunderstood you, please let us know. We’d like to
address these points below.



#1 Potential feasibility issue due to lack of path building support

If a relying party does not implement proper path building, the EE certificate
may not be validated up to the root certificate. It is true that the new
solution adds some complexity to the certificate hierarchy. More specifically
it would turn a linear hierarchy into a non-linear one. However, we consider
that complexity as still being manageable, especially since there are usually
few levels in the hierarchy in practice. If a CA hierarchy has utilized the
Authority Information Access extension the chance that any PKI library can
build the path seems to be very high.

Even if the path could not be built, this would lead to a fail-secure situation
where the EE certificate is considered invalid and it would not raise a
security issue. That would be different if the EE certificate would erroneously
be considered valid.

Additionally, only the concerned EE certificates are affected. There is no
impact on all the other actors in the ecosystem.

Since lack of proper path building is neither a security issue, nor a
compliance issue, and only the concerned subscribers are affected, it would be
up to the subscriber to decide whether to take the risk that his certificates
are wrongly labeled as invalid by certain relying parties.

In the blog post at medium.com you mentioned in your last answer, you have
analyzed various PKI libraries for their path building capacity. If this
community believes it would clarify the situation, we could run tests with some
of those libraries to see, how they are able to build the path when our
proposal was applied to a simple 4-level PKI hierarchy.



#2 Non-robust CRL implementations may lead to security issues

Relying parties using applications that don’t do a proper revocation check do
have a security risk. This security risk is not introduced by our proposal but
inherent to not implementing core functionality of public key infrastructures.
The new solution rewards relying parties that properly follow the standards.
Indeed, a relying party that has a robust CRL (or OCSP check) implementation
already would not have to bear any additional security risk. They also would
benefit from the point that our solution can be implemented very quickly and so
they would quickly mitigate the security issue. On the other hand, relying
parties with a non-functional revocation mechanism will have to take corrective
measures. And we can consider it a fair balancing of work and risk when the
workload and risk is on the actors with poor current implementations.

It can be noted that the new solution gives some responsibility to the relying
parties. Whereas the original solution gives responsibility to the subscribers
who did nothing wrong about this in the first place. The new solution can be
considered fairer with this regard.



#3 Avoiding financial strain is incompatible with user security

User security is fundamental for the PKI ecosystem. Our proposal increases the
risk exposure level only for those relying parties with a fundamentally
insecure application. Taking into account economic constraints in real life, we
believe that the increase in security should be balanced in terms of cost and
effort. Such a tradeoff may provide sufficient levels of security while
maintaining affordability. This also leads to a quicker time to implement which
limits the exposure and increases security.



One last thing we wanted to get your feedback on, is whether you agree that the
new solution we proposed ensures that if SICA and ICA are considered revoked,
there is no security risk for SICA2.



Thank you for your time and continued discussion.

Nils and team
___
dev-security-policy mailing list

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

[Ryan Sleevi via dev-security-policy]

On Wed, Nov 18, 2020 at 8:19 AM Nils Amiet via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> We have carefully read your email, and believe we’ve identified the
> following
> important points:
>
> 1. Potential feasibility issue due to lack of path building support
>
> 2. Non-robust CRL implementations may lead to security issues
>
> 3. Avoiding financial strain is incompatible with user security.
>

I wasn't trying to suggest that they are fundamentally incompatible (i.e.
user security benefits by imposing financial strain), but rather, the goal
is user security, and avoiding financial strain is a "nice to have", but
not an essential, along that path.


> #1 Potential feasibility issue due to lack of path building support
>
> If a relying party does not implement proper path building, the EE
> certificate
> may not be validated up to the root certificate. It is true that the new
> solution adds some complexity to the certificate hierarchy. More
> specifically
> it would turn a linear hierarchy into a non-linear one. However, we
> consider
> that complexity as still being manageable, especially since there are
> usually
> few levels in the hierarchy in practice. If a CA hierarchy has utilized the
> Authority Information Access extension the chance that any PKI library can
> build the path seems to be very high.
>

I'm not sure which PKI libraries you're using, but as with the presumption
of "robust CRL" implementations, "robust AIA" implementations are
unquestionably the minority. While it's true that Chrome, macOS, and
Windows implement AIA checking, a wide variety of popular browsers
(Firefox), operating systems (Android), and libraries (OpenSSL, cURL,
wolf/yassl, etc etc) do not.

Even if the path could not be built, this would lead to a fail-secure
> situation
> where the EE certificate is considered invalid and it would not raise a
> security issue. That would be different if the EE certificate would
> erroneously
> be considered valid.
>

This perspective too narrowly focuses on the outcome, without considering
the practical deployment expectations. Failing secure is a desirable
property, surely, but there's no question that a desirable property for CAs
is "Does not widely cause outages" and "Does not widely cause our support
costs to grow".

Consider, for example, that despite RFC 5280 having a "fail close" approach
for nameConstraints (by MUST'ing the extension be critical), the CA/B Forum
chose to deviate and make it a MAY. The reason for this MAY was that the
lack of support for nameConstraints on legacy macOS (and OpenSSL) versions
meant that if a CA used nameConstraints, it would fail closed on those
systems, and such a failure made it impractical for the CA to deploy. The
choice to make such an extension non-critical was precisely because
"Everyone who implements the extension is secure, and everyone who doesn't
implement the extension works, but is not secure".

It is unfortunate-but-seemingly-necessary to take this mindset into
consideration: the choice between hard-failure for a number of clients (but
guaranteed security) or the choice between less-than-ideal security, but
practical usability, is often made for the latter, due to the socioeconomic
considerations of CAs.

Now, as it relates to the above point, the path building complexity would
inevitably cause a serious spike in support overhead, because it requires
that in order to avoid issues, every server operator would need to take
action to reconfigure their certificate chains to ensure the "correct"
paths were built to support such non-robust clients (for example, of the
OpenSSL forks, only LibreSSL supports path discovery, and only within the
past several weeks). As a practical matter, that is the same "cost" of
replacing a certificate, but with less determinism of behaviour: instead of
being able to test "am I using the wrong cert or the right one", a server
operator would need to consider the entire certification path, and we know
they'll get that wrong.

This is part of why I'm dismissive of the solution; not because it isn't
technically workable, but because it's practically non-viable when
considering the overall set of ecosystem concerns. These sorts of
considerations all factor in to the decision making and recommendation for
potential remediation for CAs: trying to consider all of the interests, but
also all of the limitations.


> #2 Non-robust CRL implementations may lead to security issues
>
> Relying parties using applications that don’t do a proper revocation check
> do
> have a security risk. This security risk is not introduced by our proposal
> but
> inherent to not implementing core functionality of public key
> infrastructures.
> The new solution rewards relying parties that properly follow the
> standards.
> Indeed, a relying party that has a robust CRL (or OCSP check)
> implementation
> already would not have to bear any additional security risk. They also
> would
> benefit from the point 

Re: FNMT: Public Discussion of Root Inclusion Request

[Matthias van de Meent via dev-security-policy]

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 there is a recovery procedure",
which implies a procedure to extract and transfer keys exists.

CPS / DGPC s6.2.7 fails to commit FNMT to using devices meeting FIPS
140 level 3 or higher (as that is apparently located in DGPC 6.2.1 and
6.2.8 (?))

CPS / DGPC does not mention "factor" or "2fa" according to my search,
even though BR 6.5.2 specifies 'The CA SHALL enforce multi-factor

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

[Ryan Hurst via dev-security-policy]

On Wednesday, November 18, 2020 at 3:07:32 PM UTC-8, Kathleen Wilson wrote:
> All, 
> 
> The following changes have been made in the CCADB: 
> 
> On Intermediate Cert pages: 
> - Renamed section heading ‘Revocation Information’ to ‘Revocation 
> Information for this Certificate’ 
> - Added section called ‘Pertaining to Certificates Issued by this CA’ 
> - Added 'Full CRL Issued By This CA' field to this new section. 
> Note: CAs modify this field directly on intermediate cert pages. 
> 
> On Root Cert pages: 
> - Added section called ‘Pertaining to Certificates Issued by this CA’ 
> - Added 'Full CRL Issued By This CA' field to this new section. 
> Note: Only root store operators may directly update root cert pages, so 
> send email to your root store operator if you would like a URL added to 
> this new field for a root cert. 
> 
> 
> Coming soon: 
> Add 'Full CRL Issued By This CA' column to report: 
> http://ccadb-public.secure.force.com/ccadb/AllCertificateRecordsCSVFormat 
> 
> 
> Thanks, 
> Kathleen


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?

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

Re: Audit Reminder Email Summary

[Kathleen Wilson via dev-security-policy]

 Forwarded Message 
Subject: Summary of November 2020 Audit Reminder Emails
Date: Tue, 17 Nov 2020 20:01:50 + (GMT)

Mozilla: Audit Reminder
CA Owner: Google Trust Services LLC (GTS)
Root Certificates:
   GTS Root R2
   GTS Root R3
   GTS Root R4
   GTS Root R1
   GlobalSign
   GlobalSign
Standard Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=236832

Standard Audit Period End Date: 2019-09-30
BR Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=236833

BR Audit Period End Date: 2019-09-30
CA Comments: null



Mozilla: Audit Reminder
CA Owner: D-TRUST
Root Certificates:
   D-TRUST Root CA 3 2013
   D-TRUST Root Class 3 CA 2 2009
   D-TRUST Root Class 3 CA 2 EV 2009
Standard Audit: 
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/de/AA2019120301_D-TRUST_Root_CA3_V1.0_s.pdf

Standard Audit Period End Date: 2019-10-07
Standard Audit: 
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/de/AA2019120302_D-TRUST_Root_Class_3_CA_2_2009_V1.0_s.pdf

Standard Audit Period End Date: 2019-10-07
Standard Audit: 
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/de/AA2019120303_D-TRUST_Root_Class3_CA2_EV_V1.0_s.pdf

Standard Audit Period End Date: 2019-10-07
BR Audit:
BR Audit Period End Date:
BR Audit: 
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/de/AA2019120302_D-TRUST_Root_Class_3_CA_2_2009_V1.0_s.pdf

BR Audit Period End Date: 2019-10-07
BR Audit: 
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/de/AA2019120303_D-TRUST_Root_Class3_CA2_EV_V1.0_s.pdf

BR Audit Period End Date: 2019-10-07
EV Audit: 
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/de/AA2019120303_D-TRUST_Root_Class3_CA2_EV_V1.0_s.pdf

EV Audit Period End Date: 2019-10-07
CA Comments: null



Mozilla: Overdue Audit Statements
CA Owner: E-Tugra
Root Certificates:
   E-Tugra Certification Authority
Standard Audit: 
https://lsti-certification.fr/images/LSTI_1646_135_AL-V10_E-Tugra.pdf

Standard Audit Period End Date: 2019-07-26
BR Audit: 
https://lsti-certification.fr/images/LSTI_1646_135_AL-V10_E-Tugra.pdf

BR Audit Period End Date: 2019-07-26
EV Audit: 
https://lsti-certification.fr/images/LSTI_1646_135_AL-V10_E-Tugra.pdf

EV Audit Period End Date: 2019-07-26

CA Comments:  https://bugzilla.mozilla.org/show_bug.cgi?id=1659426 -- 
audit delay due to Covid19.




Mozilla: Audit Reminder
CA Owner: SwissSign AG
Root Certificates:
   SwissSign Gold CA - G2
   SwissSign Platinum CA - G2
   SwissSign Silver CA - G2
Standard Audit: 
https://it-tuv.com/wp-content/uploads/2019/12/AA2019121902_Audit_Attestation_TA_CERT__SwissSign_Gold_G2.pdf

Standard Audit Period End Date: 2019-10-02
Standard Audit: 
https://it-tuv.com/wp-content/uploads/2020/01/AA2019121901_Audit_Attestation_TA_CERT__SwissSign_Platinum_G2.pdf

Standard Audit Period End Date: 2019-09-27
Standard Audit: 
https://it-tuv.com/wp-content/uploads/2020/01/AA2019121903_Audit_Attestation_TA_CERT__SwissSign_Silver_G2.pdf

Standard Audit Period End Date: 2019-09-27
BR Audit: 
https://it-tuv.com/wp-content/uploads/2019/12/AA2019121902_Audit_Attestation_TA_CERT__SwissSign_Gold_G2.pdf

BR Audit Period End Date: 2019-10-02
BR Audit:
BR Audit Period End Date:
BR Audit: 
https://it-tuv.com/wp-content/uploads/2020/01/AA2019121903_Audit_Attestation_TA_CERT__SwissSign_Silver_G2.pdf

BR Audit Period End Date: 2019-09-27
EV Audit: 
https://it-tuv.com/wp-content/uploads/2019/12/AA2019121902_Audit_Attestation_TA_CERT__SwissSign_Gold_G2.pdf

EV Audit Period End Date: 2019-10-02
CA Comments: null



Mozilla: Audit Reminder
CA Owner: SecureTrust
Root Certificates:
   Secure Global CA
   SecureTrust CA
   Trustwave Global ECC P256 Certification Authority
   Trustwave Global Certification Authority
   Trustwave Global ECC P384 Certification Authority
   XRamp Global Certification Authority
Standard Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=237400

Standard Audit Period End Date: 2019-09-30
BR Audit: 
https://certs.securetrust.com/CA/2%20-%20SecureTrust%202019%20SSL%20BL%20Report.pdf

BR Audit Period End Date: 2019-09-30
EV Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=237401

EV Audit Period End Date: 2019-09-30
CA Comments: Changed CA Name from Trustwave to SecureTrust on February 
1, 2019.





___
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

[Kathleen Wilson via dev-security-policy]

All,

The following changes have been made in the CCADB:

On Intermediate Cert pages:
- Renamed section heading ‘Revocation Information’ to ‘Revocation 
Information for this Certificate’

- Added section called ‘Pertaining to Certificates Issued by this CA’
- Added 'Full CRL Issued By This CA' field to this new section.
Note: CAs modify this field directly on intermediate cert pages.

On Root Cert pages:
- Added section called ‘Pertaining to Certificates Issued by this CA’
- Added 'Full CRL Issued By This CA' field to this new section.
Note: Only root store operators may directly update root cert pages, so 
send email to your root store operator if you would like a URL added to 
this new field for a root cert.



Coming soon:
Add 'Full CRL Issued By This CA' column to report:
http://ccadb-public.secure.force.com/ccadb/AllCertificateRecordsCSVFormat


Thanks,
Kathleen
___
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

[Jakob Bohm via dev-security-policy]

On 2020-11-18 16:36, Ryan Sleevi wrote:

On Wed, Nov 18, 2020 at 8:19 AM Nils Amiet via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


We have carefully read your email, and believe we’ve identified the
following
important points:

1. Potential feasibility issue due to lack of path building support

2. Non-robust CRL implementations may lead to security issues

3. Avoiding financial strain is incompatible with user security.



I wasn't trying to suggest that they are fundamentally incompatible (i.e.
user security benefits by imposing financial strain), but rather, the goal
is user security, and avoiding financial strain is a "nice to have", but
not an essential, along that path.



#1 Potential feasibility issue due to lack of path building support

If a relying party does not implement proper path building, the EE
certificate
may not be validated up to the root certificate. It is true that the new
solution adds some complexity to the certificate hierarchy. More
specifically
it would turn a linear hierarchy into a non-linear one. However, we
consider
that complexity as still being manageable, especially since there are
usually
few levels in the hierarchy in practice. If a CA hierarchy has utilized the
Authority Information Access extension the chance that any PKI library can
build the path seems to be very high.



I'm not sure which PKI libraries you're using, but as with the presumption
of "robust CRL" implementations, "robust AIA" implementations are
unquestionably the minority. While it's true that Chrome, macOS, and
Windows implement AIA checking, a wide variety of popular browsers
(Firefox), operating systems (Android), and libraries (OpenSSL, cURL,
wolf/yassl, etc etc) do not.

Even if the path could not be built, this would lead to a fail-secure

situation
where the EE certificate is considered invalid and it would not raise a
security issue. That would be different if the EE certificate would
erroneously
be considered valid.



This perspective too narrowly focuses on the outcome, without considering
the practical deployment expectations. Failing secure is a desirable
property, surely, but there's no question that a desirable property for CAs
is "Does not widely cause outages" and "Does not widely cause our support
costs to grow".



The focus seems to be on limiting the ecosystem risks associated with
non-comliant 3rd party SubCAs.  Specifically, in the (already important)
situation where SICA was operated by a 3rd party (not the root CA
operator), their proposal would enforce the change (by replacing and
revoking the root CA controlled ICA), whereas the original procedure
would rely on auditing a previously unaudited 3rd party, such as a name
constrained corporate CA.


Consider, for example, that despite RFC 5280 having a "fail close" approach
for nameConstraints (by MUST'ing the extension be critical), the CA/B Forum
chose to deviate and make it a MAY. The reason for this MAY was that the
lack of support for nameConstraints on legacy macOS (and OpenSSL) versions
meant that if a CA used nameConstraints, it would fail closed on those
systems, and such a failure made it impractical for the CA to deploy. The
choice to make such an extension non-critical was precisely because
"Everyone who implements the extension is secure, and everyone who doesn't
implement the extension works, but is not secure".

It is unfortunate-but-seemingly-necessary to take this mindset into
consideration: the choice between hard-failure for a number of clients (but
guaranteed security) or the choice between less-than-ideal security, but
practical usability, is often made for the latter, due to the socioeconomic
considerations of CAs.

Now, as it relates to the above point, the path building complexity would
inevitably cause a serious spike in support overhead, because it requires
that in order to avoid issues, every server operator would need to take
action to reconfigure their certificate chains to ensure the "correct"
paths were built to support such non-robust clients (for example, of the
OpenSSL forks, only LibreSSL supports path discovery, and only within the
past several weeks). As a practical matter, that is the same "cost" of
replacing a certificate, but with less determinism of behaviour: instead of
being able to test "am I using the wrong cert or the right one", a server
operator would need to consider the entire certification path, and we know
they'll get that wrong.



Their proposal would fall directly into the "am I using the wrong cert
or the right one" category.  EE subscribers would just have to do a
SubCA certifiate replacement, just like they would if a CA-internal
cross-certificate expires and is reissued (as happened in 2019 for
GlobalSign's R1-R3 cross cert, which was totally workable for us
affected subscribers, though insufficient notices were sent out).


This is part of why I'm dismissive of the solution; not because it isn't
technically workable, but because it's 

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

[Ryan Sleevi via dev-security-policy]

On Wed, Nov 18, 2020 at 7:57 PM Ryan Hurst via dev-security-policy <
dev-security-policy@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?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy