RE: Clarification request: ECC subCAs under RSA Root

[Corey Bonnell via dev-security-policy]

My understanding is that neither the BRs or any Root Program require that that 
subordinate CA key be weaker or equal in strength to the issuing CA's key.

Additionally, such a requirement would prohibit cross-signs where a "legacy" 
root with a smaller key size would certify a new root CA with a stronger key. 
For that reason, this illustrative control seems problematic.

Thanks,
Corey

-Original Message-
From: dev-security-policy  On 
Behalf Of pfuen...--- via dev-security-policy
Sent: Wednesday, March 10, 2021 4:17 AM
To: Mozilla 
Subject: Clarification request: ECC subCAs under RSA Root

Hello all,

I'd have an open question about the possibility (from a compliance standpoint) 
of having an ECC 256 subordinate under an RSA 2048 Root.

If I look at the WebTrust criteria, I can see this:

4.1.3 CA key generation generates keys that:
a) use a key generation algorithm as disclosed within the CA’s CP and/or CPS;
b) have a key length that is appropriate for the algorithm and for the validity 
period of the CA certificate as disclosed in the CA’s CP and/or CPS. The public 
key length to be certified by a CA is less than or equal to that of the CA’s 
private signing key; and
c) take into account requirements on parent and subordinate CA key sizes and 
have a key size in accordance with the CA’s CP and/or CPS.


My reading of this criteria is that it's not possible to have a subordinate 
with a stronger key than the issuer, but this is unclear when mixing algorithms.

In theory, an ECC 256 subordinate has a stronger crypto than an RSA 2048 Root, 
so if I read the above criteria in terms of crypto strength, I get the 
impression that this is nor allowed. But I don't know if this is an appropriate 
interpretation of the rules.

Can anyone help me to see the light?

Thanks!
Pedro
___
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: Policy 2.7.1: MRSP Issue #218: Clarify CRL requirements for End Entity Certificates

[Corey Bonnell via dev-security-policy]

Hi Ben,
A few follow-up questions and comments:

1) What are the expectations regarding availability for such CRLs? 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?
2) What is the expectation for populating the CRLDP in end-entity S/MIME 
certificates? If no change in policy for S/MIME end-entity certificates is 
desired, then I think the text should be further qualified with "CAs SHOULD 
place the URL for the associated CRL within the crlDistributionPoints extension 
of issued *server* certificates".

Thanks,
Corey

On Thursday, January 7, 2021 at 8:00:46 PM UTC-5, Ben Wilson wrote:
> This is the last issue that I have marked for discussion in relation to 
> version 2.7.1 of the Mozilla Root Store Policy 
> .
>  
> It is identified and discussed in GitHub Issue #218 
>  for the MRSP. 
> 
> I will soon update everyone on the status of the other 13 discussion items 
> already presented, as some of them are in need of revision based on 
> comments received thus far. 
> 
> While subsection (b) of section 7.1.2.3 of the Baseline Requirements makes 
> a cRLDistributionPoint (CDP) in end entity certificates optional, Mozilla 
> still desires that CRL-based revocation information be available because 
> CRLite uses CRLs to construct its revocation filters. (Apple also uses 
> such CRL information in its certificate validation processes and, as I 
> understand, is making a similar request of CAs with respect to the new 
> CCADB field, discussed below.) 
> 
> While all such CRL information is needed, large CRLs are disfavored because 
> of the time they take to download and process. Thus, CAs shard, partition, 
> or "scope" their CRLs into smaller chunks. Section 5 of RFC 5280 explains, 
> "Each CRL has a particular scope. The CRL scope is the set of certificates 
> that could appear on a given CRL. … A complete CRL lists all unexpired 
> certificates, within its scope, that have been revoked for one of the 
> revocation reasons covered by the CRL scope. A *full and complete CRL* 
> lists all unexpired certificates issued by a CA that have been revoked for 
> any reason." (Emphasis added.) 
> 
> There is a new field in the CCADB for CAs to include information needed for 
> browsers or others to construct a "full and complete CRL", i.e. to gather 
> information from CAs that don't include the CRL path to their "full and 
> complete CRL" in end entity certificates they issue. This new CCADB field 
> is called "Full CRL Issued By This CA" and is located under the heading 
> "Pertaining to Certificates Issued by this CA." Rather than condition the 
> requirement that CAs fill in this information in the CCADB only when they 
> don't include a CDP to a full and complete CRL, I propose that this new 
> CCADB field be populated in all situations where the CA is enabled for 
> server certificate issuance. In cases where the CA shards or partitions its 
> CRL, the CA must provide a JSON-based list of CRLs that when combined are 
> the equivalent of the full and complete CRL. 
> 
> Proposed language to add to section 6 of the Mozilla Root Store Policy is 
> as follows: 
> 
> *CAs SHOULD place the URL for the associated CRL within the 
> crlDistributionPoints extension of issued certificates. A CA MAY omit the 
> crlDistributionPoint extension, if permitted by applicable requirements and 
> policies, such as the Baseline Requirements. * 
> 
> *A CA technically capable of issuing server certificates MUST ensure that 
> the CCADB field "Full CRL Issued By This CA" contains either the URL for 
> the full and complete CRL or the URL for the JSON file containing all URLs 
> for CRLs that when combined are the equivalent of the full and complete CRL* 
> . 
> 
> 
> I look forward to your comments and suggestions. 
> 
> Ben
___
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

[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: CCADB Proposal: Add field called Full CRL Issued By This CA

[Corey Bonnell via dev-security-policy]

Hi Kathleen,
Thank you for posting the notification concerning the update to CCADB. I have a 
follow-up question: in the discussion captured in 
https://github.com/mozilla/pkipolicy/issues/218, it appears that there's a 
desire for CAs to produce and publish complete CRLs for end-entity certificates 
that lack CRLDP to a complete CRL. However, I have not seen any concrete 
proposals/draft language for inclusion in 2.7.1 surrounding such a requirement. 
Is the thinking that this CCADB field will first be added and then in a 
subsequent Mozilla policy update, CAs will be required to publish full CRLs 
(perhaps as part of a CA/B Forum ballot) and disclose the location of such CRLs 
in CCADB?

Thanks,
Corey

On Wednesday, November 18, 2020 at 6:07:32 PM UTC-5, 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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7.1: MRSP Issue #153: Cradle-to-Grave Contiguous Audits

[Corey Bonnell via dev-security-policy]

I reviewed the associated GitHub commentary on the following change:

"Full-surveillance period-of-time audits MUST be conducted and updated audit
information provided no less frequently than **annually** until the CA 
certificate is no longer trusted by Mozilla's root store. Successive audits
information provided no less frequently than **annually** from the time of CA 
key pair generation until the CA certificate is no longer trusted by Mozilla's 
root store or until all copies of the CA private key have been completely 
destroyed, as evidenced by a Qualified Auditor's key destruction report, 
whichever occurs sooner."

and I'm having difficulty understanding why there is a new stipulation to allow 
for key destruction reports to release a CA from the obligation of annual 
audits for its CA certificates. Is the intent to specify that if the key 
material and operations for a given CA is transferred to another organization, 
the obligation to have annual audits for the original organization no longer 
stands, or is there some other reason for the addition of this language?

Thanks,
Corey

On Thursday, October 15, 2020 at 5:00:49 PM UTC-4, Ben Wilson wrote:
> This issue #153, listed here: 
> https://github.com/mozilla/pkipolicy/issues/153, is proposed for resolution 
> with version 2.7.1 of the Mozilla Root Store Policy. It is related to Issue 
> 139  (audits required even 
> if not issuing). 
> 
> The first paragraph of section 3.1.3 of the MRSP would read: 
> 
> Full-surveillance period-of-time audits MUST be conducted and updated audit 
> information provided no less frequently than *annually* from the time of CA 
> key pair generation until the CA certificate is no longer trusted by 
> Mozilla's root store or until all copies of the CA private key have been 
> completely destroyed, as evidenced by a Qualified Auditor's key destruction 
> report, whichever occurs sooner. Successive period-of-time audits MUST be 
> contiguous (no gaps). 
> Item 5 in the fifth paragraph of section 7.1 of the MRSP (new root 
> inclusions) would read: 
> 
> 5. an auditor-witnessed root key generation ceremony report and contiguous 
> period-of-time audit reports performed thereafter no less frequently than 
> annually; 
> 
> The proposed language can be examined further in the following commits: 
> 
> https://github.com/BenWilson-Mozilla/pkipolicy/commit/0d72d9be5acca17ada34cf7e380741e27ee84e55
>  
> 
> https://github.com/BenWilson-Mozilla/pkipolicy/commit/888dc139d196b02707d228583ac20564ddb27b35
>  
> 
> Or here: 
> https://github.com/BenWilson-Mozilla/pkipolicy/blob/2.7.1/rootstore/policy.md 
> 
> Thanks in advance for your comments, 
> 
> Ben
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7.1: MRSP Issue #186: Requirement to Disclose Self-signed Certificates

[Corey Bonnell via dev-security-policy]

As an alternate proposal, I suggest replacing the third paragraph of section 
5.3, which currently reads:

"These requirements include all cross-certificates which chain to a certificate 
that is included in Mozilla’s CA Certificate Program."

with:

"A certificate is considered to directly or transitively chain to a certificate 
included in Mozilla’s CA Certificate Program if there is a CA or Intermediate 
certificate in scope (as defined in section 1.1 of this Policy) where both of 
the following is true:
1)  The certificate’s Issuer Distinguished Name matches (according to the 
name-matching algorithm specified in RFC 5280, section 7.1) the Subject 
Distinguished Name of the certificate in scope, and
2)  The certificate is signed with a Private Key whose corresponding Public 
Key is encoded in the SubjectPublicKeyInfo of the certificate in scope."

This proposal better defines the meaning of chaining to certificates included 
in the Mozilla CA program and covers the various scenarios that have caused 
issues historically concerning cross-certificates and self-signed certificates.

Thanks,
Corey

On Wednesday, October 28, 2020 at 8:25:50 PM UTC-4, Ben Wilson wrote:
> Issue #186 in Github  
> deals with the disclosure of CA certificates that directly or transitively 
> chain up to an already-trusted, Mozilla-included root. A common scenario 
> for the situation discussed in Issue #186 is when a CA creates a second (or 
> third or fourth) root certificate with the same key pair as the root that 
> is already in the Mozilla Root Store. This problem exists at the 
> intermediate-CA-certificate level, too, where a self-signed 
> intermediate/subordinate CA certificate is created and not reported. 
> 
> Public disclosure of such certificates is already required by section 5.3 
> of the MRSP, which reads, "All certificates that are capable of being used 
> to issue new certificates, and which directly or transitively chain to a 
> certificate included in Mozilla’s CA Certificate Program, MUST be operated 
> in accordance with this policy and MUST either be technically constrained 
> or be publicly disclosed and audited." 
> 
> There have been several instances where a CA operator has not disclosed a 
> CA certificate under the erroneous belief that because it is self-signed it 
> cannot be trusted in a certificate chain beneath the already-trusted, 
> Mozilla-included CA. This erroneous assumption is further discussed in Issue 
> #186 . 
> 
> The third paragraph of MRSP section 5.3 currently reads, " These 
> requirements include all cross-certificates which chain to a certificate 
> that is included in Mozilla’s CA Certificate Program." 
> 
> I recommend that we change that paragraph to read as follows: 
> 
> "These requirements include all cross-certificates *and self-signed 
> certificates (e.g. "Issuer" DN is equivalent to "Subject" DN and public key 
> is signed by the private key) that* chain to a CA certificate that is 
> included in Mozilla’s CA Certificate Program*, and CAs must disclose such 
> CA certificates in the CCADB*. 
> 
> I welcome your recommendations on how we can make this language even more 
> clear. 
> 
> Thanks, 
> 
> Ben
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mandatory reasonCode analysis

[Corey Bonnell via dev-security-policy]

I did some searching in this area after Microsoft announced the new root 
program requirement back in February [1] and it appears that v1 CRLs are still 
being actively published in the webPKI. Notably, v1 CRLs do not support 
extensions in revoked entries, so there is no way to encode the reasonCode 
extension.

Although RFC 5280, section 5 [2] mandates that conforming CAs MUST produce v2 
CRLs, the CAs issuing v1 CRLs pre-date any browser root requirements that 
mandate adherence to the RFC 5280 profile. Switching to v2 CRLs may present 
interoperability concerns for legacy clients that consume CRLs issued from such 
CAs. Additionally, RFC 5280 specifies that conforming clients must be able to 
consume both v1 and v2 CRLs, so modern clients should be able to consume v1 
CRLs.

Given the requirement as specified originally by Microsoft (and later in the 
BRs), I'd think that only v2 CRLs are acceptable moving forward but the 
potential legacy client interoperability issues may pose challenges with 
transitioning to v2 CRLs. I'm interested to hear if anyone has any thoughts on 
this.

Thanks,
Corey

[1] 
https://cabforum.org/2020/03/20/minutes-for-ca-browser-forum-f2f-meeting-49-bratislava-19-20-february-2020/#Microsoft-Root-Program-Update
[2] https://tools.ietf.org/html/rfc5280#section-5


From: dev-security-policy  on 
behalf of Rob Stradling via dev-security-policy 

Sent: Wednesday, September 30, 2020 11:58:45 AM
To: dev-security-policy@lists.mozilla.org 

Subject: Mandatory reasonCode analysis

Starting today, the BRs require a reasonCode in CRLs and OCSP responses for 
revoked CA certificates.  Since crt.sh already monitors CRLs and keeps track of 
reasonCodes, I thought I would conduct some analysis to determine the level of 
(non)compliance with these new rules.

It's not clear to me if (1) the new BR rules should be applied only to CRLs and 
OCSP responses with thisUpdate timestamps dated today or afterwards, or if (2) 
every CRL and OCSP response currently being served by distribution points and 
responders (regardless of the thisUpdate timestamps) is required to comply.  
(I'd be interested to hear folks' opinions on this).

This gist contains my crt.sh query, the results as .tsv, and a .zip containing 
all of the referenced CRLs:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgist.github.com%2Frobstradling%2F3088dd622df8194d84244d4dd65ffd5fdata=02%7C01%7C%7Cfb1686dae6bf4f0475ea08d86559bf9b%7C84df9e7fe9f640afb435%7C1%7C0%7C637370783420551771sdata=7kogxCZ1c%2F1ksbkNYEfMyP91gyIpJ8ppG%2F%2BOjevVl1Y%3Dreserved=0


--
Rob Stradling
Senior Research & Development Scientist
Email: r...@sectigo.com
Bradford, UK
Office: +441274024707
Sectigo Limited

This message and any files associated with it may contain legally privileged, 
confidential, or proprietary information. If you are not the intended 
recipient, you are not permitted to use, copy, or forward it, in whole or in 
part without the express consent of the sender. Please notify the sender by 
reply email, disregard the foregoing messages, and delete it immediately.


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policydata=02%7C01%7C%7Cfb1686dae6bf4f0475ea08d86559bf9b%7C84df9e7fe9f640afb435%7C1%7C0%7C637370783420551771sdata=fkGX6tVkyTLHNtQkoiEdoF13ypjqCm6%2Ffq7FywIpa%2Fo%3Dreserved=0
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Question about the issuance of OCSP Responder Certificates by technically constrained CAs

[Corey Bonnell via dev-security-policy]

> I don’t understand why you’re making a distinction as to CA certificates,
which are irrelevant with respect to the Delegated Responder profile. That
is, you’re trying to find a way that it’s compliant, but this introduction
of the CA bit as somehow special doesn’t have any basis, as far as I can
tell.

The argument you're asserting is akin to someone saying that a CA certificate 
with serverAuth EKU is mis-issued if the subject Common Name is "Super Duper 
High Assurance Issuing CA", which is not a hostname in preferred DNS syntax. 
After all, the EKU definition for serverAuth in RFC 5280 states that 
certificates expressing that EKU value are used for TLS server authentication, 
and clearly that is a malformed hostname so the certificate can't be used for 
its intended purpose. In essence, the argument you're presenting applies the 
end-entity profile definition to the CA certificate profile for that EKU, which 
doesn't make sense.

> When you throw that out, it seems we’re in agreement here? If it’s
problematic to have the wrong KU for the EKU with
basicConstraints:CA=FALSE, it’s problematic to have the wrong KU for the
EKU with basicConstraints:CA=TRUE. They’re both restrictions on key usage,
and it doesn’t matter that one is a CA key.

End-entity certificates and CA certificates will naturally have different KU 
values to constrain the allowed usages of the key. Again, the argument being 
presented here tries to assert that CA certificates need to fit the profile of 
the end-entity certificate for the corresponding EKU.

>> Let's break this down:
>> - RFC 5280 indicates that the digitalSignature KU is required for clients
>> to verify signatures (e.g., OCSP response signatures) using the public key
>> in the certificate
>> - Mozilla Root Policy allows ocspSigning EKU in subCA certificates
>> alongside other EKUs

> Where? It seems you’re reading this as inferred through omission of a
prohibition in Section 5.3, but you’re using it in the remainder of your
argument to argue why it’s proactively allowed.

Ben's email from last evening [1] clearly stated that Mozilla has allowed 
ocspSigning alongside other EKUs and the concrete example given was a CA 
certificate that expresses the serverAuth and ocspSigning EKUs [2]. Notably, 
this certificate also lacks the digitalSignature KU bit.

>> Ignoring the KU, it appears that it is impossible to create a compliant CA
 certificate, despite it being allowed by Mozilla Policy.

> Yes, it’s impossible to create an Issuing CA that has id-kp-OCSPSigning.
That’s not a “bug” or the “gotcha” moment you seem to suggest: it’s the
intended result! 

If Mozilla Root Policy has historically allowed this as was stated last 
evening, then surely there is some way to do it in a compliant manner.

> But I can’t get the view that says, even in 2020, that a Thing is Not a
Thing, which in this case is a Delegated Responder. Just like I can’t
understand folks who say a Sub-CA is not a Sub-CA if it’s a
Cross-Certificate. 

I think there's a world of difference between these two cases. In the former 
case, there are technical controls for certificates used in a RFC 5280 PKI such 
that a CA certificate that expresses the ocspSigning EKU but no 
digitalSignature KU bit will not have any OCSP responses created by the CA 
trusted by clients. In the latter case, I entirely agree with you: the only 
assurance that a "Cross-Certificate" can't be used to issue end-entity 
certificates is pinky swears and promises and therefore must be treated as a 
Sub-CA, because it technically is a Sub-CA.

Thanks,
Corey

[1] 
https://groups.google.com/d/msg/mozilla.dev.security.policy/EzjIkNGfVEE/2WlxGVylBwAJ
[2] https://crt.sh/?id=2472155
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Question about the issuance of OCSP Responder Certificates by technically constrained CAs

[Corey Bonnell via dev-security-policy]

>> It’s an obligation on the client, because the verb “processed” makes no
sense if the intent were to restrict only CAs.

> They're processed independently. The usage requirement is on the CA.

I don't see how this is relevant. The language clearly states that clients must 
process both the KU and EKU extensions when both are present.

> I'll put it bluntly: Your argument is deeply troubling and I would have
little hesitation arguing for the full and immediate distrust of a CA that
made it, that's how extremely problematic I see it. I appreciate that we're
discussing in the abstract, but I want to emphasize how ardently I reject
this argument when it comes to CAs filing their incident reports, to make
sure they don't point to this thread as if somehow you've made the argument
for them.

For the avoidance of doubt, allow me to state that I'm posting this in an 
entirely personal capacity :)

> The same logic being applied here would say that a Subscriber certificate,
which had a TLS serverAuth EKU, was not actually a "server" certificate if
the KU is wrong. Worse, however, you'd similarly argue that if the KU *is*
wrong, nothing else about the certificate could be considered misissued,
because it's clearly "not a TLS server certificate". After all, 7.1.2.3(e)
of the BRs only has KU as optional, and 1.1 of the BRs only applies to
certificates "intended" for TLS, and your argument would say KU shows
intent.

This argument doesn't address the situation at hand, namely the interaction 
between CA certificates, EKU, and KU. If we were discussing OCSP EKU end-entity 
certificates that lack the digitalSignature KU, then I'd be in full agreement 
with you. But we're not; we're discussing CA certificates, which contain a set 
of KUs that restrict the usages of the CA Key Pair, namely the technical 
inability to sign OCSP responses by lack of the digitalSignature bit.

> At the heart of our disagreement is that you'd like to read something like
4.2.2.2 of RFC 6960, which says "OCSP signing delegation SHALL be
designated by the inclusion of id-kp-OCSPSigning in an extended key usage
certificate extension included in the OCSP response signer's certificate",
and add a clause "if and only if the KU is consistent". And I can
understand why that'd be appealing, and certainly when we talk about client
usage, why that would be desirable. But much like we talk about scoping
issues, the mere act of including the EKU designates it as a Responder
certificate. If the KUs are wrong, and if clients checked KUs, that would
mitigate some of the harm, but doesn't change the fundamental fact that
it's still been designated, by the CA, as an OCSP Responder. It may not be
useful as one, but it still *is* a responder certificate, and 4.9.9 applies. 

Let's break this down:
- RFC 5280 indicates that the digitalSignature KU is required for clients to 
verify signatures (e.g., OCSP response signatures) using the public key in the 
certificate
- Mozilla Root Policy allows ocspSigning EKU in subCA certificates alongside 
other EKUs
- The OCSP nocheck extension directs clients to not perform revocation checking 
for the certificate

So if a given intermediate certificate has an EKU of serverAuth and ocspSigning:
- If the certificate has the OCSP nocheck extension, then the certificate 
likely runs afoul of BR 4.9.7 and 4.9.10 as it is irrevocable
- If the certificate does not have the OCSP nocheck extension, then according 
to your interpretation, it is a misissued OCSP delegated responder and thus 
runs afoul of BR 4.9.9 due to lack of the nocheck extension

Ignoring the KU, it appears that it is impossible to create a compliant CA 
certificate, despite it being allowed by Mozilla Policy.

However, if you consider that the digitalSignature KU is required for clients 
to process OCSP responses per RFC 5280, then a compliant profile that protects 
RFC 5280-adhering clients from errant OCSP responses would be:

- KU without digitalSignature, which is a technical control that prevents OCSP 
responses signed using the CA Key Pair from being trusted by compliant clients. 
- EKUs of serverAuth and ocspSigning
- No nocheck extension, to allow for revocability of the intermediate

I would argue that certificates that adhere to the above profile are not 
mis-issued per the relevant policies and provide the proper technical 
protection (not just stated intent!) to RPs against OCSP responses signed by 
the CA key pair (assuming, of course, the client implements RFC 5280 
correctly). Additionally, such a certificate is revocable.

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

RE: Question about the issuance of OCSP Responder Certificates by technically constrained CAs

[Corey Bonnell via dev-security-policy]

>> If a certificate contains both a key usage extension and an extended

   key usage extension, then both extensions MUST be processed

   independently and the certificate MUST only be used for a purpose

   consistent with both extensions.

 

> You're reading an obligation on the CA, not an obligation on the client.

 

It’s an obligation on the client, because the verb “processed” makes no sense 
if the intent were to restrict only CAs.

 

>> I think it might be useful, if you'd like to talk about client mitigation 
>> strategies, to start a separate thread. I agree, there's definitely useful 
>> opportunities here, but there is no reasonable defense that the CA has not 
>> introduced a meaningful security issue here by violating the BRs.

 

If there’s no digitalSignature KU, then the certificate is not a OCSP responder 
certificate due to the technical inability to sign OCSP responses that would be 
accepted by clients conforming to RFC 5280, section 4.2.1.12. Therefore, 
section 4.9.9 is not applicable for those certificates that not express the 
digitalSignature KU. This is directly relevant to the topic at hand.

 

Thanks,

Corey

 

From: Ryan Sleevi  
Sent: Thursday, July 2, 2020 10:59 AM
To: Corey Bonnell 
Cc: r...@sleevi.com; Neil Dunbar ; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Question about the issuance of OCSP Responder Certificates by 
technically constrained CAs

 

 

 

On Thu, Jul 2, 2020 at 10:47 AM Corey Bonnell mailto:cbonn...@securetrust.com> > wrote:

> No, this isn’t specified/required for Delegated Reaponders (at least, by 
> 6960), and the client implementations I looked at did not check.

 

>From RFC 5280, section 4.2.1.12 
>
> :

If a certificate contains both a key usage extension and an extended

   key usage extension, then both extensions MUST be processed

   independently and the certificate MUST only be used for a purpose

   consistent with both extensions.

…

id-kp-OCSPSigningOBJECT IDENTIFIER ::= { id-kp 9 }

   -- Signing OCSP responses

   -- Key usage bits that may be consistent: digitalSignature

   -- and/or nonrepudiation

 

If clients aren’t checking for digitalSignature keyUsage when verifying OCSP 
responses signed by a delegated responder, that seems like a client 
implementation bug.

 

You're reading an obligation on the CA, not an obligation on the client.

 

I think it might be useful, if you'd like to talk about client mitigation 
strategies, to start a separate thread. I agree, there's definitely useful 
opportunities here, but there is no reasonable defense that the CA has not 
introduced a meaningful security issue here by violating the BRs.

 

> RFC 6960 is clear that the EKU indicates a designated responder, and you 
> can’t “take back” that by suggesting the lack of the KU, as required by 5280, 
> or the lack of nocheck, as required by the BRs, makes it “not a Responder”. 
> It just makes it “not a correctly issued responder”. 

 

I don’t think it’s that clear-cut, as there’s an impedance mismatch between the 
use of EKU in CA certificates to enforce policy and IETF work products. In 
other words, several Root Programs/the BRs have used EKU in CA certificates to 
denote policy scope, whereas the IETF in its various standards have the 
assumption that EKU is generally only expressed in end-entity certificates. I 
think that this interplay needs to be kept in mind when reading RFC 6960 and 
asserting whether or not the sole determiner on whether a CA certificate is an 
OCSP responder certificate is the presence of the ocspSigning EKU.

 

I directly acknowledged that interplay, but it does not justify the violation, 
nor ameliorate the security risk.

 

I wanted to nip this argument in the bud, because I have zero tolerance for it, 
as it is fundamentally the question of intent. This is the same argument 
regarding "We didn't intend for this to be able to issue TLS certs, it just 
could", or the "We didn't intend for this sub-CA to be unconstrained, it just 
was" or "We didn't intend to give a basicConstraints:CA=TRUE certificate to a 
subscriber, it just happened". As consumers of client certs, we sadly like 
insight into the ever complex and tortured minds of those operating CAs, and 
cannot discern intent. We have the certificate in front of us. And the 
certificate in front of us is, unambiguously, a Delegated Responder. And lacks 
the requisite extension.

 

A wholly irresponsible argument would be "We clearly didn't intend for it. 
Look, you can see that: we didn't comply with the certificate profile 
specified! We omitted pkix-nocheck and the KU". I don't think that's the 
argument you're making, or at least, I hope not, because that's a CA asking to 
be judged based on how they feel, rather than what they do and how well they do 
it. And I don't think anyone wants feelings to be 

RE: Question about the issuance of OCSP Responder Certificates by technically constrained CAs

[Corey Bonnell via dev-security-policy]

> No, this isn’t specified/required for Delegated Reaponders (at least, by 
> 6960), and the client implementations I looked at did not check.

 

>From RFC 5280, section 4.2.1.12:

If a certificate contains both a key usage extension and an extended

   key usage extension, then both extensions MUST be processed

   independently and the certificate MUST only be used for a purpose

   consistent with both extensions.

…

id-kp-OCSPSigningOBJECT IDENTIFIER ::= { id-kp 9 }

   -- Signing OCSP responses

   -- Key usage bits that may be consistent: digitalSignature

   -- and/or nonrepudiation

 

If clients aren’t checking for digitalSignature keyUsage when verifying OCSP 
responses signed by a delegated responder, that seems like a client 
implementation bug.

 

> RFC 6960 is clear that the EKU indicates a designated responder, and you 
> can’t “take back” that by suggesting the lack of the KU, as required by 5280, 
> or the lack of nocheck, as required by the BRs, makes it “not a Responder”. 
> It just makes it “not a correctly issued responder”. 

 

I don’t think it’s that clear-cut, as there’s an impedance mismatch between the 
use of EKU in CA certificates to enforce policy and IETF work products. In 
other words, several Root Programs/the BRs have used EKU in CA certificates to 
denote policy scope, whereas the IETF in its various standards have the 
assumption that EKU is generally only expressed in end-entity certificates. I 
think that this interplay needs to be kept in mind when reading RFC 6960 and 
asserting whether or not the sole determiner on whether a CA certificate is an 
OCSP responder certificate is the presence of the ocspSigning EKU.

 

Thanks,

Corey

 

 

From: Ryan Sleevi  
Sent: Thursday, July 2, 2020 9:57 AM
To: Corey Bonnell 
Cc: r...@sleevi.com; Neil Dunbar ; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Question about the issuance of OCSP Responder Certificates by 
technically constrained CAs

 

 

 

On Thu, Jul 2, 2020 at 9:36 AM Corey Bonnell mailto:cbonn...@securetrust.com> > wrote:

(Sorry Ryan and Neil for the double-email, I accidentally omitted the list on 
the first email)

> As others have rightfully pointed out, if the EKU is present, it is a
> delegated responder, full stop.

For the certificate to be used as a delegated responder (as opposed to an 
issuer of OCSP responder certificates), wouldn't they also need a keyUsage 
value of digitalSignature?

 

No, this isn’t specified/required for Delegated Reaponders (at least, by 6960), 
and the client implementations I looked at did not check.

 

I suspect you’re thinking about RFC 5280, Section 4.2.1.3’s normative 
requirement on the issuer of such certificates needing to include the KU? If 
so, that just seems to be arguing yet another way these certificates violate 
the requirements/profile. RFC 6960 is clear that the EKU indicates a designated 
responder, and you can’t “take back” that by suggesting the lack of the KU, as 
required by 5280, or the lack of nocheck, as required by the BRs, makes it “not 
a Responder”. It just makes it “not a correctly issued responder”. 



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: Question about the issuance of OCSP Responder Certificates by technically constrained CAs

[Corey Bonnell via dev-security-policy]

(Sorry Ryan and Neil for the double-email, I accidentally omitted the list on 
the first email)

> As others have rightfully pointed out, if the EKU is present, it is a
> delegated responder, full stop.

For the certificate to be used as a delegated responder (as opposed to an 
issuer of OCSP responder certificates), wouldn't they also need a keyUsage 
value of digitalSignature?

Thanks,
Corey


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: Question about the issuance of OCSP Responder Certificates by technically constrained CAs

[Corey Bonnell via dev-security-policy]

> Policy-wise, apparently it's OK for a certificate to be both a CA 
> certificate and
> a (correctly issued!) delegated OCSP signing certificate, which is I think 
> what
> Ryan's earlier post was talking about.  So if the affected CAs could go back 
> in
> time and add the id-pkix-ocsp-nocheck extension to these certificates then
> those certificates arguably wouldn't have been misissued(*).

Wouldn't adding the nocheck extension make the subCA certificate irrevocable, 
thus in the case of a subCA certificate with serverAuth and ocspSigning EKUs, 
violate the spirit (and maybe the wording?) of sections 4.9.7 and 4.9.10 of 
the BRs, which mandate the availability of revocation services for the subCA 
certificate?

Thanks,
Corey


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: Digicert issued certificate with let's encrypts public key

[Corey Bonnell via dev-security-policy]

While I realize the current topic is concerning TLS, I find it rather 
surprising that Mozilla Policy does not mandate PoP for S/MIME certificate 
issuance. Lack of checking for S/MIME would present more concrete security 
concerns, so perhaps this should be addressed in a future update to the Policy.

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

RE: AIA CA Issuers field

[Corey Bonnell via dev-security-policy]

> * Are there rules that CAs must adhere to in regards to referencing the
>   intermediate in the AIA field? Does it need to be available? Does it
>   need to be there at all?

It's optional (SHOULD-level), as Baseline Requirements 7.1.2.3 (c) [1] states:
It (AIA extension) SHOULD also contain the HTTP URL of the Issuing CA’s 
certificate (accessMethod = 1.3.6.1.5.5.7.48.2).

While nowhere is it explicitly written in the relevant requirements that the 
resource actually has to be available, I'd think it's a reasonable 
expectation/implicit requirement that if the caIssuers field is present, the 
issuing CA cert should be generally available on the global internet at the 
specified URL. Otherwise, it makes no sense for the pointer to be embedded in 
the certificate, as it serves no use for Relying Parties on the internet.

> * It seems common practice and desired by RFCs to have the intermediate
>   referenced in binary DER format and not PEM encoded. But some
>   certificates do reference PEM encoded intermediates. Is this a
>   violation of any rule and should this be reported as an incident?

It MUST be a DER-encoded certificate (PEM isn't allowed) according to RFC 5280 
4.2.2.1:
Where the information is available via HTTP or FTP, accessLocation
MUST be a uniformResourceIdentifier and the URI MUST point to either
a single DER encoded certificate as specified in [RFC2585] or a
 collection of certificates in a BER or DER encoded "certs-only" CMS
message as specified in [RFC2797].

Given that, I'd think it would be violation if PEM-encoded certificates were 
served in the same manner if CAs were serving PEM-encoded CRLs.

> * RfC 5280 says certificates should be served as
>   "application/pkix-cert". Is it a violation of any rule if they are
>   not? (application/x-x509-ca-cert is common, no content type and
>   completely bogus content types linke text/html also happen.)

Since this a SHOULD-level requirement, it's not prohibited to use other 
content-types (although discouraged).

Thanks,
Corey

[1] https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.7.0.pdf



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: DRAFT May 2020 CA Communication/Survey

[Corey Bonnell via dev-security-policy]

Hi Kathleen,
Thank you very much for the clarifications. If I'm understanding correctly, it 
sounds like Mozilla is considering to add sub-items of item 4 on the survey as 
Mozilla Root Program requirements if the associated CAB Forum ballot does not 
pass. However, there is concern that many CAs may not be compliant with these 
requirements, so the purpose of the survey is to gauge potential impact to CAs 
so that effective dates can be set such that CAs can react appropriately as 
well as to gather data to better inform Mozilla's position in the CAB Forum. 
Is that a correct assessment of the purpose of question 4?

As for creating GitHub issues, while I can't speak for other CAs, our team 
regularly reads MDSP but also checks the Issues list on Github (albeit less 
frequently) to stay on top of potential policy changes. So I'd say as long as 
potential policy changes are discussed (or at the very least, mentioned) on 
MDSP, we don't need a corresponding Github issue to be aware.

Having reviewed the Browser Alignment ballot in more detail, I have several 
concerns, but in the spirit of progressing the conversation forward in the CAB 
Forum, I'll raise them there.

Thanks,
Corey

> -Original Message-
> From: dev-security-policy 
> On Behalf Of Kathleen Wilson via dev-security-policy
> Sent: Friday, May 1, 2020 1:29 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: DRAFT May 2020 CA Communication/Survey
>
> On 5/1/20 9:48 AM, Corey Bonnell wrote:
> > Hi Kathleen,
> > Thank you for sending out this notification of the draft survey. I have 
> > briefly
> reviewed and would like to ask what is the intent of Item 4 and the
> associated sub-items? The Browser Alignment draft ballot is under discussion
> in the CAB Forum, so the intent behind the shift of the location of 
> discourse
> to the Mozilla forum is unclear.
> >
> > Thanks,
> > Corey
> >
>
> Hi Corey,
>
> We do not intend to shift the location of the discourse.
>
> The intent of Item 4 and the associated sub-items in our survey is to help
> Mozilla with the specific questions/concerns that we have about the ballot,
> so that we can use input from CAs in our program to recommend changes to
> the draft. It is relatively easy to tack our questions about this draft 
> ballot onto
> our CA Communication/survey, and the results will give us the data we are
> currently lacking.
>
> Currently some of my concerns about the draft of the ballot have no data
> behind them. While I think it is good to add many of those items in the 
> ballot
> to the BRs, I am concerned about the effective dates of "immediately" or
> "Sept 1". I don't want to end up with a bunch of cert revocations caused by
> effective dates that should have been changed while the ballot was in draft
> form. I also don't want to see the entire ballot fail just because we didn't
> have the data to reasonably update the draft of the ballot.
>
> Note: There are some items in the ballot that we (Mozilla) might request be
> removed, but that input will be provided by Mozilla's CABF representatives
> (Ben and Wayne) directly into the CABF discussion forum.
>
> I will greatly appreciate your thoughts on how to better ask the questions 
> in
> item 4 of our survey, to clarify our intent, and be able to get the data 
> that we
> seek.
>
> Thanks,
> Kathleen
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://scanmail.trustwave.com/?c=4062=zdys3gH7zHjY6V2sYd-
> 9JR90haa22ypk0rHi9NROwQ=5=https%3a%2f%2flists%2emozilla%2eorg
> %2flistinfo%2fdev-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: DRAFT May 2020 CA Communication/Survey

[Corey Bonnell via dev-security-policy]

> Not Kathleen here, but it seems to make sense to me, for the same reason
> Item 3 makes sense. That is, in Item 3, Apple's deployed a policy, and 
> there's
> a question about if/when Mozilla should do the same. Item 4 seems similar -
> 4.1 is a Microsoft requirement, 4.2 is an existing Mozilla implementation
> requirement (and RFC 5280 requirement), 4.3 is moving a CCADB SHOULD to
> a MUST, and 4.4 is a Microsoft requirement.

I agree that the intent of item 3 is clear, given the previous discussion on 
the topic [1]. However, there is no corresponding discussion on the Mozilla 
list (nor any Github issues [2]) for item 4 and the associated sub-items, 
which is why I asked for clarification on intent.

Thanks,
Corey

[1] 
https://groups.google.com/d/msg/mozilla.dev.security.policy/mz1buYdIy-I/oo9zHBADAQAJ
[2] https://github.com/mozilla/pkipolicy/issues



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: DRAFT May 2020 CA Communication/Survey

[Corey Bonnell via dev-security-policy]

Hi Kathleen,
Thank you for sending out this notification of the draft survey. I have briefly 
reviewed and would like to ask what is the intent of Item 4 and the associated 
sub-items? The Browser Alignment draft ballot is under discussion in the CAB 
Forum, so the intent behind the shift of the location of discourse to the 
Mozilla forum is unclear.

Thanks,
Corey

> -Original Message-
> From: dev-security-policy 
> On Behalf Of Kathleen Wilson via dev-security-policy
> Sent: Wednesday, April 29, 2020 6:48 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: DRAFT May 2020 CA Communication/Survey
> 
> All,
> 
> I have drafted a potential CA Communication and survey, and will greatly
> appreciate your input on it.
> 
> https://scanmail.trustwave.com/?c=4062=poSq3knT0jDipj1ZCEWVbMkhC
> nQ3VJAVJJ3kKSAxrA=5=https%3a%2f%2fwiki%2emozilla%2eorg%2fCA
> %2fCommunications%23May%5f2020%5fCA%5fCommunication
> 
> Direct link to read-only copy of the draft survey:
> https://scanmail.trustwave.com/?c=4062=poSq3knT0jDipj1ZCEWVbMkhC
> nQ3VJAVJMvteHcxrw=5=https%3a%2f%2fccadb-
> public%2esecure%2eforce%2ecom%2fmozillacommunications%2fCACommu
> nicationSurveySample%3fCACommunicationId%3da051J42AUSv
> 
> Purpose:
> - Communicate Mozilla's expectations about what CAs should do when
> audits, revocations, or other requirements are impacted by COVID-19
> restrictions.
> - Remind CAs about deadlines in version 2.7 of Mozilla’s Root Store Policy.
> - Collect CA input on limiting TLS cert lifetimes.
> - Collect CA input on the draft CA/Browser Forum Browser Alignment Ballot.
> 
> Thanks,
> Kathleen
> 
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://scanmail.trustwave.com/?c=4062=poSq3knT0jDipj1ZCEWVbMkhC
> nQ3VJAVJJ22fyY7pg=5=https%3a%2f%2flists%2emozilla%2eorg%2flistin
> fo%2fdev-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: GTS - OCSP serving issue 2020-04-09

[Corey Bonnell via dev-security-policy]

> As owner of the certificate, I think you actually don't want to do that,
> because things will stop working. If it's revoked you want to get a new
> certificate, and as long as you don't have the new one, you want to use the
> old certificate and staple the good OCSP response.
>

That depends on what you're optimizing for. While your solution definitely 
helps with Availability, it deprioritizes Confidentiality and Integrity. For 
example, if your private key was compromised and your certificate subsequently 
revoked, your service would continue to be accessible (good availability) but 
all communications could be MITMed (bad for Confidentiality and Integrity).

Thanks,
Corey
This transmission may contain information that is privileged, confidential, 
and/or exempt from disclosure under applicable law. If you are not the intended 
recipient, you are hereby notified that any disclosure, copying, distribution, 
or use of the information contained herein (including any reliance thereon) is 
STRICTLY PROHIBITED. If you received this transmission in error, please 
immediately contact the sender and destroy the material in its entirety, 
whether in electronic or hard copy format.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Request to Include Microsec e-Szigno Root CA 2017 and to EV-enable Microsec e-Szigno Root CA 2009

[Corey Bonnell via dev-security-policy]

On Monday, March 9, 2020 at 2:48:56 PM UTC-4, Kathleen Wilson wrote:

> * The root contains subject L and organizationIdentifier fields which 
> are arguably in violation of BR 7.1.4.3 [5]. Some, if not all, of the 
> subCAs also exhibit this issue.

Given that Mozilla explicitly encourages CAs to provide detailed identity 
information in subCA/root certificates on its Forbidden or Problematic 
Practices Wiki page [1], I don't see how including these additional subject 
fields would run afoul of Mozilla Root Policy, especially considering that the 
example given on the Wiki page includes the OU subject RDN.

What is Mozilla's expectation for subject field encoding, considering the 
discussion in the CAB Forum and the aforementioned Wiki page?

Thanks,
Corey

[1] 
https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Generic_Names_for_CAs
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Acceptable forms of evidence for key compromise

[Corey Bonnell via dev-security-policy]

As mentioned by Ryan earlier in this thread, CCADB-disclosed problem-reporting 
mechanisms don’t bind the CA to respond to the Certificate Problem Report per 
section 4.9 of the BRs. This “revoke-cert” API URL disclosure would fall into 
the same category – it might work for most cases, but there’s nothing currently 
mandating that CAs act on revocation requests sent to the “revoke-cert” 
endpoint unless CAs start adding this URL to section 1.5.2 of their CPS.

 

Per the BRs, CAs must already timely respond to Certificate Problem Reports 
sent to their problem-reporting address as disclosed in section 1.5.2 of their 
CPS. Standardization of a revocation request format that uses each CA’s 
existing problem-reporting mechanism gets us the best of both worlds: a common 
way of expressing the revocation request and the discoverability and 
well-defined mandatory response of the official problem-reporting mechanism as 
listed in the CPS.

 

Thanks,

Corey 

 

From: Rob Stradling  
Sent: Monday, March 2, 2020 5:06 PM
To: Corey Bonnell ; Nick Lamb ; 
mozilla-dev-security-policy 
Cc: Matt Palmer 
Subject: Re: Acceptable forms of evidence for key compromise

 

"As an alternative, a standard “revocation request” format could be developed 
that leverages the relative discoverability of each CA’s problem-reporting 
mechanism."

 

Alternatively, how about we add discoverability to my proposal by asking 
Kathleen to add a "revokeCert API URL" field to the CCADB?

 

  _  

From: Corey Bonnell
Sent: Monday, March 02, 2020 21:38
To: Rob Stradling; Nick Lamb; mozilla-dev-security-policy
Cc: Matt Palmer
Subject: RE: Acceptable forms of evidence for key compromise 

 

Using ACME as the revocation reporting mechanism moves the issue from using a 
bespoke proof-of-possession/revocation request protocol to a known address 
(i.e., the problem-reporting address disclosed in each CA’s CPS/CCADB) to an 
issue of using a known proof-of-possession/revocation protocol to a largely 
non-discoverable address (i.e., the “revoke-cert” endpoint of each CA’s ACME 
server).

 

There is no central registry of ACME directory URLs, so still significant work 
would be required to make ACME’s “revoke-cert” endpoint useful across CAs.

 

As an alternative, a standard “revocation request” format could be developed 
that leverages the relative discoverability of each CA’s problem-reporting 
mechanism.

 

Thanks,

Corey

 

From: Rob Stradling mailto:r...@sectigo.com> > 
Sent: Monday, March 2, 2020 4:31 PM
To: Nick Lamb mailto:n...@tlrmx.org> >; 
mozilla-dev-security-policy mailto:mozilla-dev-security-pol...@lists.mozilla.org> >; Corey Bonnell 
mailto:cbonn...@securetrust.com> >
Cc: Matt Palmer mailto:mpal...@hezmatt.org> >
Subject: Re: Acceptable forms of evidence for key compromise

 

"I do think there's value in developing some standard mechanism to request 
revocation/demonstrate possession of the private key."

 

Such as https://tools.ietf.org/html/rfc8555#section-7.6 
<https://scanmail.trustwave.com/?c=4062=r4Pd3pPseGq57uT68fGQpVlD7wldYo9_TwBh2fQ3sg=5=https%3a%2f%2ftools%2eietf%2eorg%2fhtml%2frfc8555%23section-7%2e6>
  ?

 

ISTM that any CA could stand up a standalone "revokeCert" API that only accepts 
proofs signed by the private key associated with the certificate, without that 
CA having to implement the rest of RFC8555.  Would this count as a "standard 
mechanism" (given that it's a portion of a Standards Track RFC)?  If so, why 
don't we simply say that this is the "standard mechanism"?

 

@Matt: I read your tweet 
(https://twitter.com/tobermatt/status/1232779464783695873 
<https://scanmail.trustwave.com/?c=4062=r4Pd3pPseGq57uT68fGQpVlD7wldYo9_T1oz0_Bn4Q=5=https%3a%2f%2ftwitter%2ecom%2ftobermatt%2fstatus%2f1232779464783695873>
 ) as proposing this idea, but ISTM that you've stopped slightly short of 
actually proposing it in this list thread.  

 

@Sleevi: JWS certainly isn't my favourite format, but ISTM that the WebPKI is 
kinda stuck with it now (see RFC8555).

 

  _____  

From: dev-security-policy mailto:dev-security-policy-boun...@lists.mozilla.org> > on behalf of Corey 
Bonnell via dev-security-policy mailto:dev-security-policy@lists.mozilla.org> >
Sent: 02 March 2020 19:48
To: Nick Lamb mailto:n...@tlrmx.org> >; 
mozilla-dev-security-policy mailto:mozilla-dev-security-pol...@lists.mozilla.org> >
Cc: Matt Palmer mailto:mpal...@hezmatt.org> >
Subject: RE: Acceptable forms of evidence for key compromise 

 

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.


There was quite a bit of discussion on the development of a standard
revocation request format on LAMPS WG mailing list two years ago in the wake
of the Trustico mass revocation:
https://mailarchive.ietf.org/arc

RE: Acceptable forms of evidence for key compromise

[Corey Bonnell via dev-security-policy]

Using ACME as the revocation reporting mechanism moves the issue from using a 
bespoke proof-of-possession/revocation request protocol to a known address 
(i.e., the problem-reporting address disclosed in each CA’s CPS/CCADB) to an 
issue of using a known proof-of-possession/revocation protocol to a largely 
non-discoverable address (i.e., the “revoke-cert” endpoint of each CA’s ACME 
server).

 

There is no central registry of ACME directory URLs, so still significant work 
would be required to make ACME’s “revoke-cert” endpoint useful across CAs.

 

As an alternative, a standard “revocation request” format could be developed 
that leverages the relative discoverability of each CA’s problem-reporting 
mechanism.

 

Thanks,

Corey

 

From: Rob Stradling  
Sent: Monday, March 2, 2020 4:31 PM
To: Nick Lamb ; mozilla-dev-security-policy 
; Corey Bonnell 

Cc: Matt Palmer 
Subject: Re: Acceptable forms of evidence for key compromise

 

"I do think there's value in developing some standard mechanism to request 
revocation/demonstrate possession of the private key."

 

Such as https://tools.ietf.org/html/rfc8555#section-7.6 
<https://scanmail.trustwave.com/?c=4062=lfvd3rlkzXccymkP6MZsFT-gOI-ZJlGuK4Mm7tnSoQ=5=https%3a%2f%2ftools%2eietf%2eorg%2fhtml%2frfc8555%23section-7%2e6>
  ?

 

ISTM that any CA could stand up a standalone "revokeCert" API that only accepts 
proofs signed by the private key associated with the certificate, without that 
CA having to implement the rest of RFC8555.  Would this count as a "standard 
mechanism" (given that it's a portion of a Standards Track RFC)?  If so, why 
don't we simply say that this is the "standard mechanism"?

 

@Matt: I read your tweet 
(https://twitter.com/tobermatt/status/1232779464783695873 
<https://scanmail.trustwave.com/?c=4062=lfvd3rlkzXccymkP6MZsFT-gOI-ZJlGuK9l05N2C8g=5=https%3a%2f%2ftwitter%2ecom%2ftobermatt%2fstatus%2f1232779464783695873>
 ) as proposing this idea, but ISTM that you've stopped slightly short of 
actually proposing it in this list thread.  

 

@Sleevi: JWS certainly isn't my favourite format, but ISTM that the WebPKI is 
kinda stuck with it now (see RFC8555).

 

  _  

From: dev-security-policy mailto:dev-security-policy-boun...@lists.mozilla.org> > on behalf of Corey 
Bonnell via dev-security-policy mailto:dev-security-policy@lists.mozilla.org> >
Sent: 02 March 2020 19:48
To: Nick Lamb mailto:n...@tlrmx.org> >; 
mozilla-dev-security-policy mailto:mozilla-dev-security-pol...@lists.mozilla.org> >
Cc: Matt Palmer mailto:mpal...@hezmatt.org> >
Subject: RE: Acceptable forms of evidence for key compromise 

 

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.


There was quite a bit of discussion on the development of a standard
revocation request format on LAMPS WG mailing list two years ago in the wake
of the Trustico mass revocation:
https://mailarchive.ietf.org/arch/msg/spasm/qeVHLeG6-Q_47QKNdyOOxsAT3Zk/ 
<https://scanmail.trustwave.com/?c=4062=lfvd3rlkzXccymkP6MZsFT-gOI-ZJlGuK4xz54WB8A=5=https%3a%2f%2fmailarchive%2eietf%2eorg%2farch%2fmsg%2fspasm%2fqeVHLeG6-Q%5f47QKNdyOOxsAT3Zk%2f>
 .
Nothing was developed in terms of a concrete proposal specifying a revocation
request format/protocol, but the pros/cons of such were hashed out pretty
thoroughly.

I do think there's value in developing some standard mechanism to request
revocation/demonstrate possession of the private key. The use of such a
mechanism would reduce the burden of work for those reporting key compromises,
as the reporter would not need to learn how to demonstrate possession the
private key 15 different ways to 15 different CAs. And CAs would benefit from
such a mechanism, as they wouldn't need to spend support cycles working with
the reporter to arrive at a suitable means to demonstrate possession or have
to learn some exoteric software tooling that the reporter is using to prove
possession.

Thanks,
Corey

-Original Message-
From: dev-security-policy mailto:dev-security-policy-boun...@lists.mozilla.org> > On
Behalf Of Nick Lamb via dev-security-policy
Sent: Monday, March 2, 2020 2:35 PM
To: dev-security-policy@lists.mozilla.org 
<mailto:dev-security-policy@lists.mozilla.org> 
Cc: Matt Palmer mailto:mpal...@hezmatt.org> >
Subject: Re: Acceptable forms of evidence for key compromise

On Mon, 2 Mar 2020 13:48:55 +1100
Matt Palmer via dev-security-policy
mailto:dev-security-policy@lists.mozilla.org> > wrote:

> In my specific case, I've been providing a JWS[1] signed by the
> compromised private key, and CAs are telling me that they can't (or
> won't) work with a JWS, and thus no revocation is going to happen.
> Is this a reasonable response?

I don't hate JWS, but I can see Ryan's point of view on this. Not every
"

RE: Acceptable forms of evidence for key compromise

[Corey Bonnell via dev-security-policy]

There was quite a bit of discussion on the development of a standard 
revocation request format on LAMPS WG mailing list two years ago in the wake 
of the Trustico mass revocation: 
https://mailarchive.ietf.org/arch/msg/spasm/qeVHLeG6-Q_47QKNdyOOxsAT3Zk/. 
Nothing was developed in terms of a concrete proposal specifying a revocation 
request format/protocol, but the pros/cons of such were hashed out pretty 
thoroughly.

I do think there's value in developing some standard mechanism to request 
revocation/demonstrate possession of the private key. The use of such a 
mechanism would reduce the burden of work for those reporting key compromises, 
as the reporter would not need to learn how to demonstrate possession the 
private key 15 different ways to 15 different CAs. And CAs would benefit from 
such a mechanism, as they wouldn't need to spend support cycles working with 
the reporter to arrive at a suitable means to demonstrate possession or have 
to learn some exoteric software tooling that the reporter is using to prove 
possession.

Thanks,
Corey

-Original Message-
From: dev-security-policy  On 
Behalf Of Nick Lamb via dev-security-policy
Sent: Monday, March 2, 2020 2:35 PM
To: dev-security-policy@lists.mozilla.org
Cc: Matt Palmer 
Subject: Re: Acceptable forms of evidence for key compromise

On Mon, 2 Mar 2020 13:48:55 +1100
Matt Palmer via dev-security-policy
 wrote:

> In my specific case, I've been providing a JWS[1] signed by the
> compromised private key, and CAs are telling me that they can't (or
> won't) work with a JWS, and thus no revocation is going to happen.
> Is this a reasonable response?

I don't hate JWS, but I can see Ryan's point of view on this. Not every 
"proof" is easy to definitively assess, and a CA doesn't want to get into the 
game of doing detailed forensics on (perhaps) random unfounded claims.

Maybe it makes sense for Mozilla to provide in its policy (without limiting 
what else might be accepted) an example method of demonstrating Key Compromise 
which it considers definitely sufficient ?

I'd also be comfortable with such an example in the BRs, if people think 
that's the right place to do this.


Nick.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://scanmail.trustwave.com/?c=4062=-d_d3pcpfBniFU3M4wE7RXWpZKF7oGE841cFGIoHqA=5=https%3a%2f%2flists%2emozilla%2eorg%2flistinfo%2fdev-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: DRAFT January 2020 CA Communication

[Corey Bonnell via dev-security-policy]

On Friday, January 3, 2020 at 10:27:26 AM UTC-5, Wayne Thayer wrote:
> I've made some additional improvements to the survey based on feedback from
> Kathleen:
> 
> https://ccadb-public.secure.force.com/mozillacommunications/CACommunicationSurveySample?CACommunicationId=a051J3waNOW
> 
> I'm planning to send this out to CAs on Tuesday.
> 
> On Mon, Dec 23, 2019 at 12:39 PM Wayne Thayer  wrote:
> 
> > On Thu, Dec 19, 2019 at 3:59 PM Jeremy Rowley 
> > wrote:
> >
> >> Should anything be mentioned about the allowed algorithms? That's the
> >> largest change to the policy and  confirming the AlgorithmIdentifiers in
> >> each case may take some time.
> >>
> >>
> > I'd argue that this is a clarification rather than a change, and depending
> > on the CA, confirming compliance with the updates in section 5.1 may not
> > take as long as the CPS updates. I'm not strongly opposed to calling this
> > out but I'd argue that it's hard to miss when reviewing all of the updates
> > as required by question #1.
> >

Perhaps a minor question/nit, but it's better to raise it to remove all doubt: 
for Action Item 3, if there exists revoked (but still unexpired) end-entity 
certificates w/o a EKU but the CA has already switched to universally including 
the EKU in end-entity certificates, should the CA select "All unexpired 
end-entity certificates that we issue or have issued and are within the scope 
of Mozilla’s policy currently comply with this requirement" (which loosely 
interprets the meaning of "unexpired" to encompass "non-revoked" as well), or 
should the CA select one of the other options?

I believe the intent of the discussion in 
https://groups.google.com/d/msg/mozilla.dev.security.policy/5lAI-8lkQbM/1D392GR1BQAJ
 indicates that Mozilla doesn't care about revoked certificates in this case, 
so perhaps the language for option 1 should be clarified to specify "unexpired, 
non-revoked" to better convey the intent.

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

Re: CAs cross-signing roots whose subjects don't comply with the BRs

[Corey Bonnell via dev-security-policy]

On Monday, October 7, 2019 at 10:52:36 AM UTC-4, Ryan Sleevi wrote:
> I'm curious how folks feel about the following practice:
> 
> Imagine a CA, "Foo", that creates a new Root Certificate ("Root 1"). They
> create this Root Certificate after the effective date of the Baseline
> Requirements, but prior to Root Programs consistently requiring compliance
> with the Baseline Requirements (i.e. between 2012 and 2014). This Root
> Certificate does not comply with the BRs' rules on Subject: namely, it
> omits the Country field.
> 
> Later, in 2019, Foo takes their existing Root Certificate ("Root 2"),
> included within Mozilla products, and cross-signs the Subject. This now
> creates a cross-signed certificate, "Root 1 signed-by Root 2", which has a
> Subject field that does not comport with the Baseline Requirements.
> 
> To me, this seems like a clear-cut violation of the Baseline Requirements,
> and "Foo" could have pursued an alternative hierarchy to avoid needing to
> cross-sign. However, I thought it interesting to solicit others' feedback
> on this situation, before opening the CA incident for Foo.

It appears there was a few months’ time in between versions 1.0 and 1.1 of the 
BRs that apparently allowed for omitting the C RDN even if the O was included 
in the Subject. Having spent some time in Censys.io, it appears that this root 
in question was not issued during this period so the root certificate in 
question was mis-issued. However, I think there’s an additional issue that’s 
worth discussing along with the current topic: how to treat cross-signs for 
roots that, when originally issued, were compliant with the BRs and Mozilla 
Policy but now can no longer have their subjectDN embedded in cross-signs due 
to changes in policy.

Given that there is discussion about mandating the use of ISO3166 or other 
databases for location information, the profile of the subjectDN may change 
such that future cross-signs cannot be done without running afoul of policy.

With this issue and Ryan’s scenario in mind, I think there may need to be some 
sort of grandfathering allowed for roots so that cross-signs can be issued 
without running afoul of policy. What I’m less certain on, is to what extent 
this grandfathering clause would allow for non-compliance of the current 
policies, as that is a very slippery slope and hinders progress in creating a 
saner webPKI certificate profile. For the CA that Ryan brings up, I’m less 
inclined to allow for a “grandfathering” as the root certificate in question 
was originally mis-issued. But for a root certificate that was issued in 
compliance with the policy at the time but now no longer has a compliant 
subjectDN, perhaps a carve-out in Mozilla Policy to allow for a cross-sign 
(using the now non-compliant subjectDN) is warranted.

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

Re: Nation State MITM CA's ?

[Corey Bonnell via dev-security-policy]

On Thursday, July 18, 2019 at 3:42:00 PM UTC-4, Matthew Hardeman wrote:
> Regarding indicators, I agree that it should be more apparent.  Perhaps a
> dedicated bar that occupies an entire edge-to-edge horizontal area.
> 
> I would propose that it might have two distinct messages, as well:
> 
> 1.  A message that an explicitly known MiTM certificate exists in the
> certificate chain being relied upon.  This would allow for explicit warning
> about known MiTM infrastructures and would allow tailoring any "more info"
> resource to explicitly call out that it is known that interception is being
> performed.
> 
> 2.  A message that indicates that a non-standard certificate chain is being
> presented, which might mean corporate interception, private websites within
> an organization, etc, etc.
> 
> On Thu, Jul 18, 2019 at 2:11 PM Andrew via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
> > I agree a persistent indicator is a good idea. From what I understand
> > Firefox does already have an indicator hidden in the site information box
> > that appears when you click the lock icon in the address bar (
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1549605 ). This should be
> > more visible in my opinion. Maybe add an asterisk next to the lock icon or
> > something.
> >
> >

I don’t think a persistent visual indicator on the browser chrome is a terribly 
effective solution, for two reasons:

1)  This warning will presumably be displayed all the time when the MITM 
root is installed and browsing from a Kazakh ISP. There’s nothing actionable 
that the user can do except remove the MITM root (and break your Internet 
connection, more or less) or leave the country, so it becomes a nag warning. 
This warning will merely induce warning fatigue for the user, so when another 
attacker attempts to MITM a connection (perhaps to steal financial information) 
or otherwise encounters certificate validation errors, the user will be 
desensitized to these warning messages and click right through the warning 
interstitial.
2)  By the time the persistent visual indicator is displayed, significant 
damage has already been done, as the browser has completed the intercepted 
HTTPS connection and sent their HTTP session state (cookies, etc.) to the 
attacker. This damage is greatly compounded if the user accesses the Internet 
from a non-Kazakh ISP to visit (or login to) websites that the government 
disapproves of. When the user returns to using the Kazakh ISP, their previous 
login sessions that were first established externally will have their session 
state data (session cookies, etc.) sent to the government, so the government 
can engage in session fixation attacks or otherwise leverage this information. 
A persistent visual indicator would not help at all in this scenario.

I was originally thinking that as an alternative to the persistent visual 
indicator, perhaps some blacklist of known MITM CA certificates can be created 
and content specific to each certificate explaining the risks of installing 
each certificate could be displayed in response to the user selecting the CA 
certificate to be added to the trust store. The user could then see the risks 
of installing the certificate and make a better-informed choice on whether to 
proceed with the installation. However, I don’t think this is a very effective 
solution either, as it requires that the user understand this information 
despite it being contrary to what the government is directing them to do, so it 
would merely serve to confuse a lot of users.

I think the optimal solution in terms of user security is to create a blacklist 
of known MITM CA public keys and simply prevent the installation of 
certificates containing these public keys in the trust store. If several 
browsers could coordinate on such an effort, then perhaps that would pressure 
the government to back down on their demand to intercept TLS communications 
because their root is would be incompatible with major browsers.

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

Re: P-521 Certificates

[Corey Bonnell via dev-security-policy]

On Tuesday, January 8, 2019 at 3:12:26 PM UTC-5, Wayne Thayer wrote:
> Thanks Corey, Ryan, and Jonathan.
> 
> In one of the bugs that Ryan created, the CA stated that it's not clear if
> or when Mozilla requires revocation of these P-521 certificates. I believe
> the answer is that we do not require revocation. Our policy (section 6)
> explicitly requires CAs to abide by the BR revocation rules (section
> 4.9.1.1), but these certificates do not meet any of those requirements.
> 
> - Wayne
> 
> On Tue, Jan 8, 2019 at 11:30 AM Jonathan Rudenberg via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
> > On Mon, Jan 7, 2019, at 21:26, Corey Bonnell via dev-security-policy wrote:
> > > (Posting in a personal capacity as I am no longer employed by Trustwave)
> > >
> > > Mozilla Root Store Policy section 5.1
> > > (
> > https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/)
> >
> > > prohibits the use of P-521 keys in root certificates included in the
> > > Mozilla trust store, as well as in any certificates chaining to these
> > > roots. This prohibition was made very clear in the discussion on this
> > > list in 2017 at
> > >
> > https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/7O34-DmZeC8/fsKobHABAwAJ.
> >
> > >
> > > Below is a list of unexpired, unrevoked certificates which contain P-521
> > > public keys (grouped by CA Owner and ordered by notBefore):
> >
> > I've created https://misissued.com/batch/43/ to track these.
> > ___
> > dev-security-policy mailing list
> > dev-security-policy@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-security-policy
> >

I’d like to follow-up on this discussion with a list of another 63 unique, 
valid Sectigo-issued P-521 SPKI certificates that have been issued since I 
reported the first batch back in January. According to Sectigo [1], a patch was 
deployed on January 8th to prevent issuance of certificates with P-521 SPKIs, 
but there must have been a problem with the deployment or a regression was 
introduced, as all these certificates have a notBefore date of several weeks 
after January 8th:

Sectigo
"crt.sh URL(s)", notBefore, notAfter, "subject CN", "issuer CN"
"https://crt.sh/?id=1153301077 (precert); https://crt.sh/?id=1153303683 
(final)", 2019-01-29, 2020-01-29, *.012919020120149.vfidev.com, "COMODO ECC 
Organization Validation Secure Server CA"
"https://crt.sh/?id=1159765604 (precert); https://crt.sh/?id=1159768069 
(final)", 2019-01-30, 2020-01-30, vpn.catest.net, "Gandi Standard SSL CA 2"
"https://crt.sh/?id=1166099013 (precert); https://crt.sh/?id=1166156646 
(final)", 2019-02-03, 2021-02-02, sso.aust.ae, "GlobeSSL DV Certification 
Authority 2"
"https://crt.sh/?id=1172672983 (precert); https://crt.sh/?id=1172675064 
(final)", 2019-02-05, 2020-02-05, *.020519020223240.vfidev.com, "COMODO ECC 
Organization Validation Secure Server CA"
"https://crt.sh/?id=1173393341 (precert); https://crt.sh/?id=1173396153 
(final)", 2019-02-05, 2020-02-05, *.020519060222541.vfidev.com, "COMODO ECC 
Organization Validation Secure Server CA"
"https://crt.sh/?id=1194624767 (precert); https://crt.sh/?id=1194625305 
(final)", 2019-02-11, 2021-02-10, im-ec.angelo.edu, "InCommon ECC Server CA"
"https://crt.sh/?id=1194625403 (precert); https://crt.sh/?id=1194625563 
(final)", 2019-02-11, 2021-02-10, im-ec.angelo.edu, "InCommon ECC Server CA"
"https://crt.sh/?id=1194625375 (precert); https://crt.sh/?id=1194625597 
(final)", 2019-02-11, 2021-02-10, im-ec.angelo.edu, "InCommon ECC Server CA"
"https://crt.sh/?id=1203447331 (precert); https://crt.sh/?id=1203448393 
(final)", 2019-02-14, 2020-02-14, *.021419180252278.vfidev.com, "COMODO ECC 
Organization Validation Secure Server CA"
"https://crt.sh/?id=1203465736 (precert); https://crt.sh/?id=1203465915 
(final)", 2019-02-14, 2020-02-14, *.021419180252278.vfidev.com, "COMODO ECC 
Organization Validation Secure Server CA"
"https://crt.sh/?id=1221647998 (precert); https://crt.sh/?id=1221648175 
(final)", 2019-02-21, 2020-02-21, *.022119020213378.vfidev.com, "COMODO ECC 
Organization Validation Secure Server CA"
"https://crt.sh/?id=1221642108 (precert); https://crt.sh/?id=1221644541 
(final)", 2019-02-21, 2020-02-21, *.022119020213378.vfidev.com, "COMODO ECC 
Organization Validation Secure Server CA"
"https://crt.sh/?id=123290 (precert); https://crt.sh/?id=1232911335 
(final)", 2019-02-26, 2020-02-26, test-september.m

Re: Logotype extensions

[Corey Bonnell via dev-security-policy]

On Friday, June 14, 2019 at 1:31:12 PM UTC-4, kirkhal...@gmail.com wrote:
> CAs already have rules allowing a Parent, Subsidiary, or Affiliate (all 
> defined terms) to obtain certs for domains owned by each other - so 
> Alphabet-Google, for example, can get certs for domains owned by each other.  
> So we would use the same rules to make certain the registered trademark owner 
> is a Parent, Subsidiary, or Affiliate of the EV cert Subject - we would use 
> information from the SEC or other government securities agencies (including 
> public filings), and/or other third party data that we have used for the past 
> 10 years to prove affiliation.  Also, remember, we only do trademark 
> registration validation after we have completed EV validation, so we know who 
> our certificate customer is.  Many companies put their IP assets in an 
> affiliated company for tax reasons - it should not be difficult to prove 
> affiliation.  If we can't prove it, the logo will not go into the EV cert.

Section 11 of the EV Guidelines has specific language for all cases where 
information for Parent/Subsidiary/Affiliate companies can be used for 
validation. Given that validation for trademarks/Logotype extensions is not 
specified anywhere in the BRs or EV Guidelines, there is no such language 
allowing the use of trademark data obtained from PSA companies in certificates.

Additionally, as Ryan alluded to, it is reasonable to interpret the definition 
of Subject Identity Information to also encompass any certificate extensions 
which contain identity information about the Subject. Given this, I believe 
that EV Guidelines section 9.2.9 is applicable as the intent of that section is 
clear: no identity information can be included in an EV certificate unless the 
steps for validation and encoding are thoroughly specified in the EV 
Guidelines. To assert otherwise is to assert that well defined, rigorous 
validation steps are not needed for EV certificates.

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

Re: Logotype extensions

[Corey Bonnell via dev-security-policy]

On Tuesday, June 11, 2019 at 7:49:31 AM UTC-4, Jeremy Rowley wrote:
> We wanted to experiment a bit with logotype extensions and trademarks, but
> we heard from the CAB Forum that whether inclusion is allowed is subject a
> bit to interpretation by the browsers.
> 
>  
> 
> >From the BRs section 7.1.2.4
> 
> "All other fields and extensions MUST be set in accordance with RFC 5280.
> The CA SHALL NOT issue a Certificate that contains a keyUsage flag,
> extendedKeyUsage value, Certificate extension, or other data not specified
> in section 7.1.2.1, 7.1.2.2, or 7.1.2.3 unless the CA is aware of a reason
> for including the data in the Certificate. CAs SHALL NOT issue a Certificate
> with: a. Extensions that do not apply in the context of the public Internet
> (such as an extendedKeyUsage value for a service that is only valid in the
> context of a privately managed network), unless: i. such value falls within
> an OID arc for which the Applicant demonstrates ownership, or ii. the
> Applicant can otherwise demonstrate the right to assert the data in a public
> context; or b. semantics that, if included, will mislead a Relying Party
> about the certificate information verified by the CA (such as including
> extendedKeyUsage value for a smart card, where the CA is not able to verify
> that the corresponding Private Key is confined to such hardware due to
> remote issuance)."
> 
>  
> 
> In this case, the logotype extension would have a trademark included (or
> link to a trademark). I think this allowed as:
> 
> 1.There is a reason for including the data in the Certificate (to
> identify a verified trademark). Although you may disagree about the reason
> for needing this information, there is a not small number of people
> interested in figuring out how to better use identification information. No
> browser would be required to use the information (of course), but it would
> give organizations another way to manage certificates and identity
> information - one that is better (imo) than org information.
> 2.The cert applies in the context of the public Internet.
> Trademarks/identity information is already included in the BRs. 
> 3.The trademark does not falls within an OID arc for which the
> Applicant demonstrates ownership (no OID included).
> 4.The Applicant can otherwise demonstrate the right to assert the data
> in a public context. If we vet ownership of the trademark with the
> appropriate office, there's no conflict there.
> 5.Semantics that, if included, will not mislead a Relying Party about
> the certificate information verified by the CA (such as including
> extendedKeyUsage value for a smart card, where the CA is not able to verify
> that the corresponding Private Key is confined to such hardware due to
> remote issuance). None of these examples are very close to the proposal.
> 
>  
> 
> What I'm looking for is not a discussion on whether this is a good idea, but
> rather  is it currently permitted under the BRs per Mozilla's
> interpretation. I'd like to have the "is this a good idea" discussion, but
> in a separate thread to avoid conflating permitted action compared to ideal
> action.
> 
>  
> 
> Jeremy

Absent policy surrounding the validation and encoding of Logotype data, I 
believe that the use of the Logotype extension to convey identity information 
may be fraught with security and privacy problems. A brief read of RFCs 3709 
and 6170 raises several concerns:

1.  Where are the image and audio assets stored? Will the CA allow for 
Applicants to specify an arbitrary URI for assets, or will the CA host them, or 
will the assets be encoded directly in the certificate using data URIs? The 
first two options have ramifications regarding client tracking, or even 
allowing attackers to suppress the retrieval of logo assets (thus providing for 
a potentially inconsistent UI between clients). This is compounded by the fact 
that the RFCs only allow retrieval via plaintext HTTP and FTP. I’m guessing the 
third option (“data” URI) is a non-starter due to certificate size limitations.
2.  The RFCs do not put a hard requirement on the minimum size of images 
and length of audio files. What’s the minimum acceptable size of images to 
ensure that the trademark is clearly conveyed to Relying Parties? Is a 5-second 
clip from the Subject’s radio jingle sufficiently clear identity information?
3.  Perhaps minor, but RFC 3709 specifies that clients MUST support SHA-1 
for hashing assets. This is undesirable, especially given that attacks against 
SHA-1 are becoming increasingly practical.


Given the concern about suppressing the retrieval of the trademark information 
and the lack of specification to ensure clear, unambiguous images/audio, I 
believe that 7.1.2.4.b is applicable here in that there is the possibility to 
mislead Relying Parties. As such, I believe that before CAs begin embedding the 
Logotype extension in certificates, the relevant RFCs need to be profiled (or 

Unretrievable CPS documents listed in CCADB

[Corey Bonnell via dev-security-policy]

Hello,
Section 4 of Mozilla Root Store Policy states that CAs are bound by the latest 
Common CCADB Policy (http://ccadb.org/policy). Section 5 of the Common CCADB 
Policy specifies the requirements for CAs regarding providing URLs to various 
documents, such as the CP, CPS, and audit reports. In particular, “the URLs to 
such CPs, CPSes and audits, and any metadata about them such as the name of the 
auditor or the date of the audit, need to be updated as new information become 
available.”

The current AllCertificateRecordsReport.csv was downloaded and the CPS URLs for 
all unrevoked intermediate and root certificates were extracted. Each extracted 
CPS URL was then requested via HTTP GET using cURL and the HTTP response status 
code recorded. Below is a list of all CPS URLs which return a HTTP status code 
of 400 or greater:

"Row number", "CA Owner", "Certificate Name", "CPS URL", "HTTP status code"
7, "AC Camerfirma, S.A.", "Chambers of Commerce Root", 
http://docs.camerfirma.com/publico/DocumentosWeb/politicas/CPS_eidas_EN_v_1_2_3.pdf,
 404
191, Atos, "Atos TrustedRoot 2011", 
https://pki.atos.net/Download/AtosTrustedCACPSv1.9.0.pdf, 404
258, "Autoridad de Certificacion Firmaprofesional", "SIGNE Autoridad de 
Certificacion", 
http://www.signe.es/wp-content/uploads/2018/08/DPC_SIGNE_2.1-180731.pdf, 404
262, Buypass, "Buypass Class 2 CA 1", 
http://www.buypass.com/home/support/ca-documentation-legal, 404
466, "Deutscher Sparkassen Verlag GmbH (S-TRUST, DSV-Gruppe)", "S-TRUST 
Authentication and Encryption Root CA 2005:PN", 
http://www.s-trust.de/stn-cps/stn_cps.pdf, 404
468, "Deutscher Sparkassen Verlag GmbH (S-TRUST, DSV-Gruppe)", "TC TrustCenter 
Class 3 CA II", https://www.s-trust.de/stn-cps, 404
594, DigiCert, "ADACOM CA for EU Qualified e-Seals", 
https://pki.adacom.com/repository/en/CPS/files/Certification_Practice_Statement_for_EU_Qualified_certificates_v3.pdf,
 404
634, DigiCert, "Allgeier IT Solutions CA", 
https://www.s-trust.de/ablage_download_dokumente/ablage_pdf/S-TRUST_STN_CPS_V3_87.pdf,
 404
741, DigiCert, "Belgium Root CA2", 
https://stage-pki.belgium.be/resources/PKI-BelgiumRootCA-CPS-v1.2.pdf, 404
1394, DigiCert, "Government AA", 
https://stage-pki.belgium.be/resources/Government-CA-Certification-Practice-Statement-v1.0.pdf,
 404
1546, DigiCert, "Microsoft IT SSL CA 1", 
https://www.microsoft.com/pki/mscorp/cps/Microsoft%20IT%20PKI%20CP-CPS%20for%20SSL%20Ver%201%203%20January%202015.htm,
 404
1551, DigiCert, "Microsoft IT SSL SHA2", 
http://www.microsoft.com/pki/mscorp/cps/Microsoft%20IT%20PKI%20CP-CPS%20for%20SSL%20Ver%201%203%20January%202015.htm,
 404
2494, "Financijska agencija (Fina)", "Fina Root CA", 
http://rdc.fina.hr/QTSA2017/FinaQTSA, 404
2815, "Government of France (ANSSI, DCSSI)", IGC/A, 
http://www.ssi.gouv.fr/site_article15.html, 404
2991, "Government of Tunisia, Agence National de Certification Electronique / 
National Digital Certification Agency (ANCE/NDCA)", "Tunisian Root Certificate 
Authority - TunRootCA2", 
http://www.tuntrust.tn/sites/default/files/documents/PolitiqueSERVEURS-PTC-BR-08.pdf,
 404
3209, "Microsec Ltd.", "e-Szigno Class2 CA 2017", 
https://static.e-szigno.hu/docs/szsz--fok--sea--EN--v2.8.pdf, 404
3211, "Microsec Ltd.", "e-Szigno Class3 CA 2017", 
https://static.e-szigno.hu/docs/szsz--fok--sig--EN--v2.8.pdf, 404
3216, "Microsec Ltd.", "e-Szigno Qualified CA 2017", 
https://static.e-szigno.hu/docs/szsz--min--sig--EN--v2.8.pdf, 404
3217, "Microsec Ltd.", "e-Szigno Qualified Organization CA 2017", 
https://static.e-szigno.hu/docs/szsz--min--sea--EN--v2.8.pdf, 404
3308, "Pos Digicert Sdn. Bhd (Malaysia)", "PosDigicert Class 2 Root CA G2", 
https://www.posdigicert.com.my/public/uploads/files/CPS-Rev-60.pdf, 404
3442, "SECOM Trust Systems CO., LTD.", http://www.valicert.com/, 
https://repository.secomtrust.net/rootrepository/CPSen.pdf, 404
3445, "SECOM Trust Systems CO., LTD.", "Security Communication EV RootCA1", 
https://repository.secomtrust.net/EV-Root1/index.html, 404
4526, "T-Systems International GmbH (Deutsche Telekom)", "Deutsche Telekom AG 
Issuing CA 01", http://corporate-pki.telekom.de/cps/cps.htm, 403
4528, "T-Systems International GmbH (Deutsche Telekom)", "Deutsche Telekom AG 
Issuing CA 01", http://corporate-pki1.telekom.de/cps/cps.htm, 403
5242, "Telia Company (formerly TeliaSonera)", "Sonera Class1 CA", 
http://repository.trust.teliasonera.com/CPS/index3.html, 404
5388, "WoSign CA Limited", "CA WoSign ECC Root", 
http://www.wosign.com/policy/wosign-policy-1-2-12.pdf, 403
5436, Zetes, "ZETES TSP ROOT CA 001", http://repository.tsp.zetes.com/Zetes, 404

Given that these URLs return error HTTP status codes, I do not believe these 
CCADB entries comply with CCADB Policy (and by extension, Mozilla Policy).

As an aside, I noticed that several URLs listed in CCADB are “Legal Repository” 
web page URLs that contain a list of many CP/CPS documents. My recommendation 
is to slightly amend CCADB Policy to require CAs to provide URLs to the 

Re: CAA records on a CNAME

[Corey Bonnell via dev-security-policy]

Perhaps not very elegant, but you can encode an “allow all issuers” CAA RRSet 
by specifying a single iodef CAA record without any issue/issuewild records in 
the RRSet, which will probably be treated as permission to issue for CAs. I say 
“probably” because the RFC wasn’t clear on the proper handling RRSets with no 
issue/issuewild property tags, but this was clarified in the CAB Forum in 
Ballot 219 
(https://cabforum.org/2018/04/10/ballot-219-clarify-handling-of-caa-record-sets-with-no-issue-issuewild-property-tag/)
 to explicitly allow the above behavior (although of course some CAs may be 
more restrictive and disallow issuance in this case).

Thanks,
Corey

From: Corey Bonnell 
Sent: Monday, March 18, 2019 16:42
To: Hector Martin 'marcan'; Jan Schaumann
Cc: dev-security-policy@lists.mozilla.org
Subject: Re: CAA records on a CNAME

Perhaps not very elegant, but you can encode an “allow all issuers” CAA RRSet 
by specifying a single iodef CAA record without any issue/issuewild records in 
the RRSet, which will probably be treated as permission to issue for  CAs. I 
say “probably” because the RFC wasn’t clear on the proper handling RRSets with 
no issue/issuewild property tags, but this was clarified in the CAB Forum in 
Ballot 219 
(https://cabforum.org/2018/04/10/ballot-219-clarify-handling-of-caa-record-sets-with-no-issue-issuewild-property-tag/)
 to explicitly allow the above behavior (although of course some CAs may be 
more restrictive and disallow issuance in this case).

Thanks,
Corey

From: dev-security-policy  on 
behalf of Hector Martin 'marcan' via dev-security-policy 

Sent: Monday, March 18, 2019 14:26
To: Jan Schaumann
Cc: dev-security-policy@lists.mozilla.org
Subject: Re: CAA records on a CNAME

On 16/03/2019 10:25, Jan Schaumann via dev-security-policy wrote:
> someapp.example.com, over which I have control is a CNAME, so I can't
> set a CAA record there.  Let's say the CNAME points to
> ghs.googlehosted.com.
>
> Your suggestion is to contact Google and ask them to please add a CAA
> record to that domain for a CA that a third-party (to them and myself)
> chooses.  My experience has been that Google, Akamai, Cloudflare,
> Amazon, and Microsoft etc. are not amenable to adding such records.

I think part of the problem here is that the CAA specification has no
"allow all" option. Third party hosting providers probably want to allow
their customers to use any CA they wish, so they lack CAA records.
However, there is no way to specify this once you have already
encountered a CAA record, so by the time you follow the CNAME, you're stuck.

The default CAA behavior can *only* be specified by default, by the
absence of records throughout the entire tree. In my optinion this is an
oversight in the CAA specification.

My use case is different, but somewhat related. I host services for an
event under example.com, e.g. .example.com, but I also have a
dynamic user.example.com zone (several, actually) where users
automatically get a dynamic record assigned at
.user.example.com. I use Let's Encrypt for all of the
services. Currently I have a CAA record for example.com, but this also
locks all the dynamic users into using Let's Encrypt, while I want them
to be free to use any CA. I could instead have a CAA record for .example.com, but this is hard to manage and less
secure, as it would allow issuance for all nonexistent names and is
harder to manage. Ideally I would just set a CAA record for "*" on
user.example.com and that would solve the issue, but the current CAA
specification has no mechanism for this.

If CAA had a way to signal an explicit "allow all", then third party
hosting services could signal that on their overall zones in order to
solve this problem with CNAMEs (of course, customers who wish to lock
down their CAA records for such third-party hosted domains would have to
get CAA records added to them, but I think that makes more sense as an
explicit thing rather than breaking CNAMEs by default).

--
Hector Martin "marcan"
Public key: 
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmrcn.st%2Fpubdata=02%7C01%7C%7C8c18001675284d88925f08d6ab6246d5%7C84df9e7fe9f640afb435%7C1%7C0%7C636884835910007451sdata=AvRYycQp7w0zMB2to49mL0MqPdkscrDmw91ePNwKJ5k%3Dreserved=0
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policydata=02%7C01%7C%7C8c18001675284d88925f08d6ab6246d5%7C84df9e7fe9f640afb435%7C1%7C0%7C636884835910017456sdata=OGYmdLZfK8Rktf7N62tUzaJsswMiF64cQF8uGL6eekw%3Dreserved=0
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CAA records on a CNAME

[Corey Bonnell via dev-security-policy]

On Friday, March 15, 2019 at 9:26:02 PM UTC-4, Jan Schaumann wrote:
> Matt Palmer via dev-security-policy  
> wrote:
>  
> > I've read through your posts on this topic several times, and I still don't
> > understand the problem you're trying to solve.  If you point a CNAME at
> > someone else, then you're delegating to them control of that name.  If they
> > set CAA records on the CNAME target (or if they don't), and those CAA 
> > records
> > (or lack thereof) do not represent a functioning configuration, you work
> > with them to change it.
> 
> someapp.example.com, over which I have control is a CNAME, so I can't
> set a CAA record there.  Let's say the CNAME points to
> ghs.googlehosted.com.
> 
> Your suggestion is to contact Google and ask them to please add a CAA
> record to that domain for a CA that a third-party (to them and myself)
> chooses.  My experience has been that Google, Akamai, Cloudflare,
> Amazon, and Microsoft etc. are not amenable to adding such records.
> 
> > I speak on this issue not from a theoretical perspective
> 
> I'm sure there are many scenarios where CNAMEs are not a problem and
> work entirely as intended.  My use cases have not been that.
> 
> -Jan

If I recall correctly, there was some discussion in late 2017 in the IETF LAMPS 
WG (the working group producing the successor to the current CAA RFC 6844) 
about modifying the CAA tree-climbing algorithm to query a prefix/"attribute 
leaf" subdomain to allow domain owners the ability to set a CAA configuration 
on domains which contain a CNAME record. You can see this referenced on slide 9 
of the CAA presentation given at the LAMPS session at IETF 100: 
https://datatracker.ietf.org/meeting/100/materials/slides-100-lamps-rfc-6844-bis-00.pdf.

However, this idea was not pursued any further, as RFC 6844-bis 
(https://tools.ietf.org/html/draft-ietf-lamps-rfc6844bis-05#section-3) contains 
no such provision in its tree-climbing algorithm definition.

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

Re: DarkMatter Concerns

[Corey Bonnell via dev-security-policy]

On Sunday, February 24, 2019 at 8:05:10 PM UTC-5, Scott Rea wrote:
> G’day Corey,
> 
> In respect to the previously issued constrained intermediates – can you 
> clarify where in RFC5280 Section 4.2.1.10 that the prohibition against a 
> leading period is specified for the name constraints?
> I see in the RFC the specific sentence: “When the constraint begins with a 
> period, it MAY be expanded with one or more labels.”  This appears to 
> contradict your assertion that leading period constraints violate 5280…
> 
> During the period that these intermediates were deployed, the browsers and 
> platforms dependent on these performed path processing exactly as expected 
> with this configuration.
> 
> Can you please illuminate the passage in the RFC where you feel a leading 
> period in a permitted subtree e.g. (“.ae”) as was used in the identified 
> intermediate certificates, is a violation??
> 
> Regards,
>  
> 
> -- 
> 
> Scott Rea
> 
> On 2/25/19, 12:50 AM, "dev-security-policy on behalf of Corey Bonnell via 
> dev-security-policy"  of dev-security-policy@lists.mozilla.org> wrote:
> 
> Furthermore, two of the intermediates issued to DarkMatter which chain to 
> QuoVadis/Digicert roots violate RFC 5280, section 4.2.1.10 
> (https://tools.ietf.org/html/rfc5280#section-4.2.1.10). Specifically, the 
> dNSName in the nameConstraints extension's permittedSubtrees field contains a 
> leading period (".ae"), which violates the hostname syntax specified in 
> section 4.2.1.10. Therefore, these two intermediate certificates 
> (https://crt.sh/?id=23432430=cablint, 
> https://crt.sh/?id=19415522=cablint) are also mis-issued under the 
> Baseline Requirements.
> 
> I have sent a Certificate Problem Report to Digicert to notify them of 
> these findings, as these intermediates and DarkMatter-issued certificates 
> chain to roots under their control.
> 
> 
>  
> 
> Scott Rea | Senior Vice President - Trust Services 
> Tel: +971 2 417 1417 | Mob: +971 52 847 5093
> scott@darkmatter.ae
> 
> The information transmitted, including attachments, is intended only for the 
> person(s) or entity to which it is addressed and may contain confidential 
> and/or privileged material. Any review, retransmission, dissemination or 
> other use of, or taking of any action in reliance upon this information by 
> persons or entities other than the intended recipient is prohibited. If you 
> received this in error, please contact the sender and destroy any copies of 
> this information.

Hi Scott,
The verbiage from RFC 5280, section 4.2.1.10 that you quoted is in regard to 
URI GeneralNames, as the paragraph starts with "For URIs...".

The relevant paragraph in section 4.2.1.10 that specifies the required syntax 
of dNSNames in nameConstraints and explains why the two intermediates are 
non-compliant is as follows:

"DNS name restrictions are expressed as host.example.com.  Any DNS
   name that can be constructed by simply adding zero or more labels to
   the left-hand side of the name satisfies the name constraint.  For
   example, www.host.example.com would satisfy the constraint but
   host1.example.com would not."

As you can see, there is no provision for encoding a leading period in 
dNSNames. Several certificate linters detect this particular problem, which you 
can see demonstrated in the two links I provided to the two intermediates' 
crt.sh entries.

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

Re: DarkMatter Concerns

[Corey Bonnell via dev-security-policy]

On Sunday, February 24, 2019 at 7:39:34 PM UTC-5, Scott Rea wrote:
> G’day Corey,
> 
> I did not check your math, but is it possible that you are interpreting the 
> serial number conversion output as an unsigned integer representation? If so, 
> then I can understand your potential concern regarding the findings of your 
> analysis.
> 
> DarkMatter uses an EJBCA platform with the requisite setting for 64-bit 
> random serial numbers and our source of entropy is a FIPS140 certified HSM, 
> so I too was surprised by the findings you reported. However, during our 
> investigation of this potential issue, we have thus far discovered that the 
> platform appears to be compliant with the requisite standard, and the anomaly 
> you are highlighting is potentially due just to the integer representation 
> you are using in your calculations.
> 
> RFC5280 (section 4.1.2.2) defines serialNumber to be a positive INTEGER, and 
> X.690 defines INTEGER to consist of one or more octets and (specifically 
> section 8.3.3) says the octets shall be a two’s complement binary number 
> equal to the integer value. Using the two’s complementary representation 
> means that the output of the octet conversion is a signed integer, and it 
> could be positive or negative – the range of integers from 64-bit numbers 
> being from –(2^63) to [+ (2^63)-1]. But since the RFC requires only positive 
> integers, the 64-bits of output from the CSPRNG function must eventuate only 
> in positive numbers, and negative numbers cannot be used. In two’s complement 
> representation, the leading bit determines whether the number is positive or 
> negative – for positive numbers, the leading bit will always be zero (if it’s 
> a 1, then that represents a negative number which RFC5280 prohibits).
> 
> So our findings are that the platform is indeed using 64-bit output from an 
> appropriate CSPRNG for generating serialNumbers, and that the leading zero is 
> exactly what is required to indicate that it is a positive number in two’s 
> complement representation of the INTEGER, which is the requirement under 
> RFC5280. Therefore our findings indicate that the serial number generation 
> scheme used by DarkMatter in it’s certificate hierarchy does meet the 
> requirements set forth in the Baseline Requirements, section 7.1.
> 
> 
> Regards,
>  
> 
> -- 
> 
> Scott Rea
> 
> On 2/25/19, 12:50 AM, "dev-security-policy on behalf of Corey Bonnell via 
> dev-security-policy"  of dev-security-policy@lists.mozilla.org> wrote:
> 
> On Friday, February 22, 2019 at 4:28:30 PM UTC-5, Corey Bonnell wrote:
> > Hello,
> > Section 7.1 of the Baseline Requirements states that, "Effective 
> September 30, 2016, CAs SHALL generate non-sequential Certificate serial 
> numbers greater than zero (0) containing at least 64 bits of output from a 
> CSPRNG".
> > 
> > An analysis of the 23 known certificates (4 root CA, 6 ICA, 1 Audit CA, 
> and 12 end-entity interoperability/test certificates) in the DarkMatter 
> certificate hierarchy currently listed in the inclusion request indicates 
> that the hierarchy is likely not compliant with this requirement. 
> Specifically, all 23 certificates have an 8-octet (64 bit) serial number, but 
> the most significant bit (big-endian) of their serial numbers is 0. The 
> probability that all 23 known certificates in the hierarchy having exactly 64 
> bits of output from a CSPRNG with a most significant bit value of 0 is 1 in 
> 2^23, or 1 in 8,388,608, which would make this a highly extraordinary event. 
> The far more likely case is that each certificate's serial number does not 
> contain the requisite number of bits (64) output from a CSPRNG.
> > 
> > A detailed breakdown is as follows:
> > 
> > "subject CN", notBefore, "serial number", "highest bit index set 
> (1-based indexing)"
> > 
> > "UAE Global Root CA G3", 2017-05-17, 47:0E:FF:0B:2E:B3:83:40, 63
> > "UAE Global Root CA G4", 2017-05-17, 1E:86:4A:1C:01:B1:46:3F, 61
> > "DarkMatter Audit CA", 2017-05-18, 7B:02:F9:F1:42:64:C1:42, 63
> > "DarkMatter Root CA G3", 2017-05-18, 6A:E6:CC:D1:A8:29:7F:EB, 63
> > "DarkMatter Root CA G4", 2017-05-18, 61:17:4D:F7:2B:EC:5F:84, 63
> > "DigitalX1 High Assurance CA G3", 2018-06-28, 75:50:D6:6F:78:B4:BD:F5, 
> 63
> > "DigitalX1 High Assurance CA G4", 2018-06-28, 6E:E0:2C:70:C9:43:17:16, 
> 63
> > "DM X1 High Assurance CA G3", 2018-06-28, 7D:DE:FE:2D:9F:05:74:DE, 63
> > "DM X1 High Assurance CA G4", 2018-06-28, 40:17:D7:B9:DD:E

Re: DarkMatter Concerns

[Corey Bonnell via dev-security-policy]

On Friday, February 22, 2019 at 4:28:30 PM UTC-5, Corey Bonnell wrote:
> Hello,
> Section 7.1 of the Baseline Requirements states that, "Effective September 
> 30, 2016, CAs SHALL generate non-sequential Certificate serial numbers 
> greater than zero (0) containing at least 64 bits of output from a CSPRNG".
> 
> An analysis of the 23 known certificates (4 root CA, 6 ICA, 1 Audit CA, and 
> 12 end-entity interoperability/test certificates) in the DarkMatter 
> certificate hierarchy currently listed in the inclusion request indicates 
> that the hierarchy is likely not compliant with this requirement. 
> Specifically, all 23 certificates have an 8-octet (64 bit) serial number, but 
> the most significant bit (big-endian) of their serial numbers is 0. The 
> probability that all 23 known certificates in the hierarchy having exactly 64 
> bits of output from a CSPRNG with a most significant bit value of 0 is 1 in 
> 2^23, or 1 in 8,388,608, which would make this a highly extraordinary event. 
> The far more likely case is that each certificate's serial number does not 
> contain the requisite number of bits (64) output from a CSPRNG.
> 
> A detailed breakdown is as follows:
> 
> "subject CN", notBefore, "serial number", "highest bit index set (1-based 
> indexing)"
> 
> "UAE Global Root CA G3", 2017-05-17, 47:0E:FF:0B:2E:B3:83:40, 63
> "UAE Global Root CA G4", 2017-05-17, 1E:86:4A:1C:01:B1:46:3F, 61
> "DarkMatter Audit CA", 2017-05-18, 7B:02:F9:F1:42:64:C1:42, 63
> "DarkMatter Root CA G3", 2017-05-18, 6A:E6:CC:D1:A8:29:7F:EB, 63
> "DarkMatter Root CA G4", 2017-05-18, 61:17:4D:F7:2B:EC:5F:84, 63
> "DigitalX1 High Assurance CA G3", 2018-06-28, 75:50:D6:6F:78:B4:BD:F5, 63
> "DigitalX1 High Assurance CA G4", 2018-06-28, 6E:E0:2C:70:C9:43:17:16, 63
> "DM X1 High Assurance CA G3", 2018-06-28, 7D:DE:FE:2D:9F:05:74:DE, 63
> "DM X1 High Assurance CA G4", 2018-06-28, 40:17:D7:B9:DD:ED:20:55, 63
> exped.ca.darkmatter.ae, 2018-07-05, 12:5E:AF:E7:93:49:9A:95, 61
> expeu.ca.darkmatter.ae, 2018-07-05, 2B:65:3C:DB:5C:7D:F6:56, 62
> exprd.ca.darkmatter.ae, 2018-07-05, 55:E4:A1:AE:7C:A3:64:14, 63
> expru.ca.darkmatter.ae, 2018-07-05, 74:EE:AC:88:24:3D:F9:E4, 63
> reved.ca.darkmatter.ae, 2018-07-05, 1A:E6:DA:22:59:06:AD:C1, 61
> reveu.ca.darkmatter.ae, 2018-07-05, 0D:B3:3E:12:5A:4A:11:DF, 60
> revrd.ca.darkmatter.ae, 2018-07-05, 0D:C6:08:0C:4F:B4:76:63, 60
> revru.ca.darkmatter.ae, 2018-07-05, 6F:5A:8C:4F:54:FC:3A:E2, 63
> valed.ca.darkmatter.ae, 2018-07-05, 1E:40:E3:2D:DF:21:95:59, 61
> valeu.ca.darkmatter.ae, 2018-07-05, 65:84:D9:1D:F5:CE:C5:89, 63
> valrd.ca.darkmatter.ae, 2018-07-05, 3F:53:0E:C5:7D:F5:83:C5, 62
> valru.ca.darkmatter.ae, 2018-07-05, 14:CB:73:81:18:20:C5:25, 61
> "DigitalX1 Assured CA G4", 2018-09-05, 6D:9F:01:8E:40:8E:5F:7F, 63
> "DM X1 Assured CA G4", 2018-09-05, 71:9C:24:E8:9A:D9:44:AB, 63
> 
> Thanks,
> Corey

I would like to bolster my previous assertion that the serial number generation 
scheme used in the DarkMatter certificate hierarchy likely does not meet the 
requirements set forth in the Baseline Requirements, section 7.1.

A further analysis of all DarkMatter-issued certificates which were logged to 
Certificate Transparency logs with a notBefore date of 2016-09-30 or later was 
performed. This certificate corpus of 235 unique certificates (pre-certificate 
and final certificate pairs are considered to be a single “unique certificate” 
to avoid double-counting) is overwhelmingly comprised of end-entity TLS 
certificates, but there are also several infrastructure-related certificates 
(such as OCSP Response Signing certificates, etc.) included. DarkMatter has 
asserted that all publicly trusted TLS certificates that they have issued are 
logged to Certificate Transparency logs, so this set of 235 unique certificates 
includes the entirety of publicly trusted TLS certificates issued by DarkMatter 
since 2016-09-30.

This analysis has revealed that all 235 unique certificates have a serial 
number of 8 octets (64 bits) and a big-endian most significant bit set to 0. 
Given that the probability of all 64 bits being output from a CSPRNG with a 
most significant bit value of 0 for all 235 such certificates is 1 in 2^235, it 
is extremely likely that these certificates do not contain the minimum number 
of bits (64) output from a CSPRNG and are therefore mis-issued under the 
Baseline Requirements.

A comprehensive list of the 235 unique certificates can be found here: 
https://gist.github.com/CBonnell/1f01ccd93667c37800b67e518340c606

Furthermore, two of the intermediates issued to DarkMatter which chain to 
QuoVadis/Digicert roots violate RFC 5280, section 4.2.1.10 
(https://tools.ietf.org/html/rfc5280#section-4.2.1.10). Specifically, the 
dNSName in the nameConstraints extension's permittedSubtrees field contains a 
leading period (".ae"), which violates the hostname syntax specified in section 
4.2.1.10. Therefore, these two intermediate certificates 
(https://crt.sh/?id=23432430=cablint, 

Re: P-384 and ecdsa-with-SHA512: is it allowed?

[Corey Bonnell via dev-security-policy]

On Tuesday, February 12, 2019 at 3:15:09 PM UTC-5, Wayne Thayer wrote:
> Thanks Corey and Jakob, I opened a bug for this:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1527423
> 
> Corey, did you report this via DigiCert's problem reporting mechanism?
> 
> Thanks,
> 
> Wayne
> 
> On Mon, Feb 11, 2019 at 8:01 PM Jakob Bohm via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
> > On 10/02/2019 02:55, Corey Bonnell wrote:
> > > Hello,
> > > Section 5.1 of the Mozilla Root Store Policy (
> > https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/)
> > specifies the allowed set of key and signature algorithms for roots and
> > certificates that chain to roots in the Mozilla Root Store. Specifically,
> > the following hash algorithms and ECDSA hash/curve pairs are allowed:
> > >
> > > • Digest algorithms: SHA-1 (see below), SHA-256, SHA-384, or SHA-512.
> > > • P‐256 with SHA-256
> > > • P‐384 with SHA-384
> > >
> > > Given this, if an End-Entity certificate were signed using a subordinate
> > CA’s P-384 key with ecdsa-with-SHA512 as the signature algorithm (which
> > would be reflected in the End-Entity certificate's signatureAlgorithm
> > field), would this violate Mozilla policy? As I understand it, an ECDSA
> > signing operation with a P-384 key using SHA-512 would be equivalent to
> > using SHA-384 (due to the truncation that occurs), so I am unsure if this
> > would violate the specification above (although the signatureAlgorithm
> > field value would be misleading). I believe the same situation exists if a
> > P-256 key is used for a signing operation with SHA-384.
> > >
> > > Any insight into whether this is allowed or prohibited would be
> > appreciated.
> > >
> >
> >
> > Using the same DSA or ECDSA key with more than one hash algorithm
> > violates the cryptographic design of DSA/ECDSA, because those don't
> > include a hash identifier into the signature calculation.  It's
> > insecure to even accept such signatures, as it would make the
> > signature checking code vulnerable to 2nd pre-image attacks on the
> > hash algorithm not used by the actual signer to generate
> > signatures.  It would also be vulnerable to cross-hash pre-image
> > attacks that are otherwise not considered weaknesses in the hash
> > algorithms.
> >
> > Furthermore the FIPS essentially (if not explicitly) require using
> > a shortened 384-bit variant of SHA-512 as input to P-384 ECDSA,
> > and the only approved such shortened version is, in fact, SHA-384.
> >
> > Using the same P-384 ECDSA key pair with both SHA-384 and
> > SHA-3-384 might be within some readings of the FIPS, but would
> > still be vulnerable to the issue above (imagine a pre-image
> > weakness being found in either hash algorithm, all signatures
> > with such a key would then become suspect).
> >
> >
> > Enjoy
> >
> > Jakob
> > --
> > Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
> > Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
> > This public discussion message is non-binding and may contain errors.
> > WiseMo - Remote Service Management for PCs, Phones and Embedded
> > ___
> > dev-security-policy mailing list
> > dev-security-policy@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-security-policy
> >

I didn't report this issue to Digicert's problem reporting mechanism as I 
believe this is not a mis-issuance under the Baseline Requirements, but rather 
a violation specific to Mozilla Root Store Policy (section 6.1.5 of the 
Baseline Requirements does not mandate any curve/hash pairs).
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: P-384 and ecdsa-with-SHA512: is it allowed?

[Corey Bonnell via dev-security-policy]

On Sunday, February 10, 2019 at 6:33:19 AM UTC-5, Ryan Sleevi wrote:
> On Sat, Feb 9, 2019 at 8:55 PM Corey Bonnell via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
> > Hello,
> > Section 5.1 of the Mozilla Root Store Policy (
> > https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/)
> > specifies the allowed set of key and signature algorithms for roots and
> > certificates that chain to roots in the Mozilla Root Store. Specifically,
> > the following hash algorithms and ECDSA hash/curve pairs are allowed:
> >
> > • Digest algorithms: SHA-1 (see below), SHA-256, SHA-384, or SHA-512.
> > • P‐256 with SHA-256
> > • P‐384 with SHA-384
> 
> 
> >
> > Given this, if an End-Entity certificate were signed using a subordinate
> > CA’s P-384 key with ecdsa-with-SHA512 as the signature algorithm (which
> > would be reflected in the End-Entity certificate's signatureAlgorithm
> > field), would this violate Mozilla policy? As I understand it, an ECDSA
> > signing operation with a P-384 key using SHA-512 would be equivalent to
> > using SHA-384 (due to the truncation that occurs), so I am unsure if this
> > would violate the specification above (although the signatureAlgorithm
> > field value would be misleading). I believe the same situation exists if a
> > P-256 key is used for a signing operation with SHA-384.
> >
> > Any insight into whether this is allowed or prohibited would be
> > appreciated.
> >
> > Thanks,
> > Corey
> 
> 
> I don’t think you can read that policy, as written, and legitimately
> interpret it as allowed. It’s literally not listed.
> 
> 
> > ___
> > dev-security-policy mailing list
> > dev-security-policy@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-security-policy
> >

Thanks, Ryan, for weighing in. I suspected that such certificates would be 
prohibited but wanted confirmation.

The motivation for my inquiry was that I discovered the following set of 
unexpired, unrevoked certificates which are signed with a P-384 sub-CA key 
using the ecdsa-with-SHA512 signature algorithm. Given that this hash/curve 
pair is not allowed, I believe that these certificates run afoul of Mozilla 
Root Store Policy:

DigiCert
crt.sh URL(s),notBefore,notAfter,issuer CN,issuer curve,sigAlg
https://crt.sh/?id=252169572 (final),2017-11-08,2020-11-12,DigiCert ECC Secure 
Server CA,P-384,ecdsa-with-SHA512
https://crt.sh/?id=276033955 (precert); https://crt.sh/?id=498045339 
(final),2017-12-11,2019-12-11,DigiCert ECC Extended Validation Server 
CA,P-384,ecdsa-with-SHA512
https://crt.sh/?id=323384439 (precert),2018-02-05,2019-02-20,DigiCert ECC 
Secure Server CA,P-384,ecdsa-with-SHA512
https://crt.sh/?id=323318776 (precert),2018-02-05,2019-02-20,DigiCert ECC 
Secure Server CA,P-384,ecdsa-with-SHA512
https://crt.sh/?id=354276341 (precert),2018-03-13,2020-03-20,DigiCert ECC 
Secure Server CA,P-384,ecdsa-with-SHA512
https://crt.sh/?id=358905399 (precert),2018-03-18,2019-05-22,DigiCert ECC 
Extended Validation Server CA,P-384,ecdsa-with-SHA512
https://crt.sh/?id=368911544 (precert),2018-03-28,2020-04-01,DigiCert ECC 
Secure Server CA,P-384,ecdsa-with-SHA512
https://crt.sh/?id=399193174 (precert); https://crt.sh/?id=402197763 
(final),2018-04-16,2020-04-22,DigiCert ECC Extended Validation Server 
CA,P-384,ecdsa-with-SHA512
https://crt.sh/?id=399645531 (precert),2018-04-17,2020-04-22,DigiCert ECC 
Extended Validation Server CA,P-384,ecdsa-with-SHA512
https://crt.sh/?id=402216416 (precert),2018-04-18,2020-03-26,DigiCert ECC 
Secure Server CA,P-384,ecdsa-with-SHA512
https://crt.sh/?id=402398690 (precert),2018-04-18,2020-03-26,DigiCert ECC 
Secure Server CA,P-384,ecdsa-with-SHA512
https://crt.sh/?id=402397877 (precert),2018-04-18,2020-03-26,DigiCert ECC 
Secure Server CA,P-384,ecdsa-with-SHA512
https://crt.sh/?id=402398610 (precert),2018-04-18,2020-03-26,DigiCert ECC 
Secure Server CA,P-384,ecdsa-with-SHA512
https://crt.sh/?id=402397769 (precert),2018-04-18,2020-03-26,DigiCert ECC 
Secure Server CA,P-384,ecdsa-with-SHA512
https://crt.sh/?id=402398408 (precert),2018-04-18,2020-03-26,DigiCert ECC 
Secure Server CA,P-384,ecdsa-with-SHA512
https://crt.sh/?id=402396037 (precert),2018-04-18,2020-03-26,DigiCert ECC 
Secure Server CA,P-384,ecdsa-with-SHA512
https://crt.sh/?id=402397885 (precert),2018-04-18,2020-03-26,DigiCert ECC 
Secure Server CA,P-384,ecdsa-with-SHA512
https://crt.sh/?id=402517328 (precert),2018-04-18,2020-03-26,DigiCert ECC 
Secure Server CA,P-384,ecdsa-with-SHA512
https://crt.sh/?id=402217433 (precert),2018-04-18,2020-03-26,DigiCert ECC 
Secure Server CA,P-384,ecdsa-with-SHA512
https://crt.sh/?id=402397974 (precert),2018-04-18,2020-03-26,DigiCert ECC 
Secure Server CA,P-384,ec

P-384 and ecdsa-with-SHA512: is it allowed?

[Corey Bonnell via dev-security-policy]

Hello,
Section 5.1 of the Mozilla Root Store Policy 
(https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/)
 specifies the allowed set of key and signature algorithms for roots and 
certificates that chain to roots in the Mozilla Root Store. Specifically, the 
following hash algorithms and ECDSA hash/curve pairs are allowed:

• Digest algorithms: SHA-1 (see below), SHA-256, SHA-384, or SHA-512.
• P‐256 with SHA-256
• P‐384 with SHA-384

Given this, if an End-Entity certificate were signed using a subordinate CA’s 
P-384 key with ecdsa-with-SHA512 as the signature algorithm (which would be 
reflected in the End-Entity certificate's signatureAlgorithm field), would this 
violate Mozilla policy? As I understand it, an ECDSA signing operation with a 
P-384 key using SHA-512 would be equivalent to using SHA-384 (due to the 
truncation that occurs), so I am unsure if this would violate the specification 
above (although the signatureAlgorithm field value would be misleading). I 
believe the same situation exists if a P-256 key is used for a signing 
operation with SHA-384.

Any insight into whether this is allowed or prohibited would be appreciated.

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