Your opinion on misissuance under name constrained ICAs

[Buschart, Rufus]

Dear MDSP community!

I would like to ask for your opinion in regards to the following scenario:

Let there be an Issuing CA that is name constrained (acc. BRGs 7.1.5) to the issuance of certificates only for example.com. Now this Issuing CA issues an end-entity certificate for example2.com. This certificate would be un-trusted, but would this be considered a misissuance? And would it make a difference if the Issuing CA has successfully performed a domain validation according to the BRGs before issuing the end-entity certificate?

I couldn't find any rules for this in the BRGs nor a discussion on this within the archive of this mailing list.


With best regards

Rufus Buschart
Siemens AG

[Rob Stradling]

Hi Rufus.  I think it's not a misissuance, as long as domain control validation was performed correctly.

RFC5280 section 4.2.1.10 says:

  "The name constraints extension, which MUST be used only in a CA

   certificate, indicates a name space within which all subject names in

   subsequent certificates in a certification path MUST be located."

In my view this rule pertains to client behaviour only, not to certificate contents, since there's nothing to prohibit the issuance of a second intermediate that has the same Name and Key and that either lacks Name Constraints or has Name Constraints that permit both example.com and example2.com.  In other words, multiple certification paths might (and often do) exist.

---

From: dev-secur...@mozilla.org <dev-secur...@mozilla.org> on behalf of Buschart, Rufus <rufus.b...@siemens.com>
Sent: 21 July 2021 16:01
To: dev-secur...@mozilla.org <dev-secur...@mozilla.org>
Subject: Your opinion on misissuance under name constrained ICAs

 

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.

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fa%2Fmozilla.org%2Fd%2Fmsgid%2Fdev-security-policy%2FAM8PR10MB430551044C73C395B64451499EE39%2540AM8PR10MB4305.EURPRD10.PROD.OUTLOOK.COM&amp;data=04%7C01%7Crob%40sectigo.com%7C94cb17951c9545ec03e708d94c585f64%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637624764868902702%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=rEopDOrQ4TLV55waO2SRgWnBC3G9wG9pl1DtTGM88Z4%3D&amp;reserved=0.

[Ryan Hurst]

Rufus,

This is a tricky one, off the top of my head I can't think of any language in root program requirements or the BRs that clearly makes it a miss-issuance but I believe in principle it would be.

I say this because name constraints are intended to be a technical control of a policy, not a replacement for policy. For example, I would assume in the situation described the practices that governed the creation of the name constrained certificate authority had language that limited the issuer contractually as well. Those policy controls would have failed in this case.

This is important I think because not all name constraint implementations are created equal; see the Netflix test suite on name constraints for an overview of how some UAs fail to properly enforce name constraints https://netflixtechblog.com/bettertls-c9915cd255c0.

This gets more complicated in cases where there are multiple paths to the same ICA with different constraints (contractual or otherwise) but in the plain vanilla variant, it seems like this would be a miss isuance.

Ryan Hurst

(Personal)

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/AM8PR10MB430551044C73C395B64451499EE39%40AM8PR10MB4305.EURPRD10.PROD.OUTLOOK.COM.

[Tim Hollebeek]

I agree with Rob Stradling on this one.  The potential existence of multiple certification paths means that such a certificate can make sense in some situations.

 

-Tim

 

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CALVZKwZbcnfkJJGG2CXKaoxWNg46zstk5mL%2Bq9HYKjk2VTdxsA%40mail.gmail.com.

[Ryan Sleevi]

Weighing in for a Root Program (Chrome, i.e. wearing a Chrome Hat)

As Rob and Tim have captured: if (and only if) the BRs were followed in the process of validating the domain, then even though clients will reject that certificate, it is not misissuance.

Put differently: A (TLS capable) Technically Constrained Sub-CA is expected to fully follow the BRs and root program requirements, just like a non-technically constrained sub-CA. The only difference is in the audit schemes and disclosure of those audits.

That said, that's not a guarantee it's never misissuance; as Ryan (Hurst) captured, it's possible, for example, that the (non-constrained) CA was relying on this TCSC as an Enterprise RA. The BRs require an Enterprise RA to only issue certificates within the Enterprise RA's verified Domain Namespace. Technically Constrained Sub-CAs do not serve as a substitute for that requirement, meaning the Issuing CA was still expected to be performing domain validation themselves, and ensuring that the domains are within the Enterprise RAs' verified Domain Namespace.

I'm not sure if that clears things up or muddies it more, but I think we've all captured that "It depends; it's not inherently, but it could be, misissuance".

That said, this also touches on one area of complexity within the BRs and RFC 5280 interactions: the assumptions here assume there may be an alternative path that can successfully validate the certificate (e.g. the existence of an unconstrained intermediate with the same subject and public key). That may be purely hypothetical, though: it may be there's only the singular path, and the certificate that was just issued does not validate through any possible certificate path. Is it misissuance if a CA issues a certificate where there are no viable certificate paths according to RFC 5280? That is a fair and legitimate question for concern, but it's unclear if that's the scenario here.

[Rob Stradling]

> Is it misissuance if a CA issues a certificate where there are no viable certificate paths according to RFC 5280?

If so, is it still misissuance if a viable path later comes into existence (due to issuance of another, less-constrained subordinate CA certificate that has the same Subject and Key)?  Or does it become "no longer considered misissuance"?  (Or does this thought experiment suggest that it wasn't actually misissuance in the first place?)

---

From: dev-secur...@mozilla.org <dev-secur...@mozilla.org> on behalf of Ryan Sleevi <ry...@sleevi.com>
Sent: 21 July 2021 22:15
To: Tim Hollebeek <tim.ho...@digicert.com>
Cc: Ryan Hurst <ryan....@gmail.com>; Buschart, Rufus <rufus.b...@siemens.com>; dev-secur...@mozilla.org <dev-secur...@mozilla.org>

Subject: Re: Your opinion on misissuance under name constrained ICAs

 

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.

--

You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAErg%3DHEaH4eCZARYRpunCdroDr0G8zGei%3DHjuDezP0OUxpCk8w%40mail.gmail.com.

[Ryan Sleevi]

On Wed, Jul 21, 2021 at 6:55 PM Rob Stradling <r...@sectigo.com> wrote:

> Is it misissuance if a CA issues a certificate where there are no viable certificate paths according to RFC 5280?

If so, is it still misissuance if a viable path later comes into existence (due to issuance of another, less-constrained subordinate CA certificate that has the same Subject and Key)?  Or does it become "no longer considered misissuance"?  (Or does this thought experiment suggest that it wasn't actually misissuance in the first place?)

Is it misissuance if something is disallowed by the BRs, but then later allowed? (hint: yes)

I mean, we just misissuance by the expectations and requirements at time of issuance, right?

[Cynthia Revström]

Hi,

I would have to agree with Rob here, mainly as this validation *should* be done by the consuming software/tls client.

Sure it might not always be implemented correctly but that is the TLS client's issue and given that this would still require a valid domain control validation, I see very limited risk.

I am not too familiar with what definition is being used for a viable path here but if "Acme Corp Issuing CA" had a TCSC certificate from a root but then had a non-constrained cert from a root that might be audited etc but not in any of the major root programs, could they issue outside of their constrained names?

My initial thoughts are that there seems to be a lot of complexity for what seems like a mostly theoretical problem that has limited risk and in a perfect world shouldn't be a problem at all because the TLS client would handle it.

-Cynthia

--

You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAErg%3DHH2t5hDs50Cb5zmG_wg%2BQA%2Bgj9LZ4ky96Zk0cYHZwsbTw%40mail.gmail.com.

[Ryan Sleevi]

On Wed, Jul 21, 2021 at 8:31 PM Cynthia Revström <m...@cynthia.re> wrote:

I would have to agree with Rob here, mainly as this validation *should* be done by the consuming software/tls client.

Client behavior has never excused CA behavior though. The point here is with respect to _all_ CAs being expected to perform the same validation, which Rob was also highlighting here.

I am not too familiar with what definition is being used for a viable path here but if "Acme Corp Issuing CA" had a TCSC certificate from a root but then had a non-constrained cert from a root that might be audited etc but not in any of the major root programs, could they issue outside of their constrained names?

I think you’re conflating two different things. This isn’t about an unconstrained, untrusted path - it’s about the fact that an unconstrained, trusted path may exist now, or in the future, and that certificate becomes valid. If that certificate was not properly validated, that’s misissuance (at time of issuance), TCSC or not.

My initial thoughts are that there seems to be a lot of complexity for what seems like a mostly theoretical problem that has limited risk and in a perfect world shouldn't be a problem at all because the TLS client would handle it.

This is functionally the same argument as when CAs assert misencoded certificates have no risks, because OpenSSL didn’t accept it. There are multiple risks here you’re (likely unintentionally) ignoring: the risk of the CA delegating domain validation to the TCSC (forbidden by BRs), the risk of the CA improperly implementing enterprise RA controls (a BR violation), and the risk of domain validation itself failing. The hypothetical here doesn’t have enough information, and so our answers need the depth to highlight that it’s not cut and dry like you mentioned.

The remaining question posed by the hypothetical invalid path is functionally similar to the question of “Is a certificate misissued if it has a SAN of google.com, a TLS EKU, no domain validation performed, but also has an unrecognized critical EKU.” If we use the same logic mentioned here, the argument is “well, no, it can’t be misissued, because of the extra extension that clients won’t understand and RFC 5280 says they should reject the cert.” But that doesn’t seem a very good answer, especially for the risks posed.

The situation for a TCSC is even messier, precisely because even if we say “ignore it now,” at any point later, a doppelgänger can be issued (and, as an intermediate cert, has no guarantee of being logged), which would cause that cert to become valid later. That’s why we have to evaluate the situation at issuance time, and assume the worst, because the worst may have already happened and we just don’t know it yet.

[Ryan Sleevi]

I was reminded of a similar past discussion offlist, with https://bugzilla.mozilla.org/show_bug.cgi?id=1699796

In this scenario, a CA issued certificates that did not, according to RFC 5280, have a valid_policy_tree output, and the very positive steps the CA took in response to this, in terms of disclosure, revocation, and remediation.

[Rob Stradling]

> Is it misissuance if something is disallowed by the BRs, but then later allowed? (hint: yes)

I agree.  Yes.

(For clarity: My thought experiment was trying to further explore whether or not Rufus's scenario is actually disallowed by the BRs).

> I mean, we just [judge?] misissuance by the expectations and requirements at time of issuance, right?

Yes, and I think there's a natural follow-on question that I'd appreciate folks' thoughts on...

Having judged a cert to have been misissued, should(*) it necessary follow that that cert MUST be revoked?

I'm thinking in particular of misissuances where an external event could cause the misissued certificate to no longer be "wrong".  For example, if a viable trust path later came into existence in Rufus's example, what purpose would be served by requiring the (potentially) misissued cert to then be revoked?

We had a similar discussion internally at Sectigo earlier this month during preparations to revoke a bunch of certs (that are listed in https://bugzilla.mozilla.org/show_bug.cgi?id=1718771) for which we discovered that, at time of issuance, we hadn't performed DCV recently enough for all of the domains in each cert.  BR 4.9.1.1 requires revocation within 24 hours if "The CA obtains evidence that the validation of domain authorization or control for any Fully‐Qualified Domain Name or IP address in the Certificate should not be relied upon".  We wondered: if we could perform fresh DCV checks for the affected domains before those 24 hours elapse, then "should not be relied upon" will no longer be the case - what purpose would then be served by revoking these certs?

(*) I'm aware that currently, per BR 4.9.1.1(7), all BR-misissued certs SHOULD be revoked within 24 hours and MUST be revoked within 5 days (and, just to be clear, in the case of bug 1718771 we did revoke everything within 24 hours).  I'm just curious to hear folks' opinions on whether or not BR 4.9.1.1(7) is always a reasonable requirement.

---

From: Ryan Sleevi <ry...@sleevi.com>
Sent: 22 July 2021 01:20
To: Rob Stradling <r...@sectigo.com>
Cc: Buschart, Rufus <rufus.b...@siemens.com>; Ryan Hurst <ryan....@gmail.com>; Tim Hollebeek <tim.ho...@digicert.com>; dev-secur...@mozilla.org <dev-secur...@mozilla.org>; ry...@sleevi.com <ry...@sleevi.com>

Subject: Re: Your opinion on misissuance under name constrained ICAs

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.

[Pedro Fuentes]

In my humble opinion there's no much room to discuss here... Any issuance that is done breaching a policy is a mis-issuance, and nothing done later can make it a non-mis-issuance.

In particular, the case described is unmistakably a mis-issuance, as the "promise" made when creating the CA was broken at the moment of issuing the certificate, whatever is done afterwards.

BR/P

[Ryan Sleevi]

✔️💯

[Tim Hollebeek]

Sticking to the simple case where there are no alternative certification paths, I would say that it would be reasonable to improve the policy here to disallow such useless certificates in the future.  It’s not clear they serve any useful function, and the world would probably be a better place if CAs couldn’t issue them.

 

Someone should probably file a CABF github issue, too.  It’s worth discussing there.

 

-Tim

 

From: Ryan Sleevi <ry...@sleevi.com>
Sent: Wednesday, July 21, 2021 5:16 PM
To: Tim Hollebeek <tim.ho...@digicert.com>

Cc: Ryan Hurst <ryan....@gmail.com>; Buschart, Rufus <rufus.b...@siemens.com>; dev-secur...@mozilla.org
Subject: Re: Your opinion on misissuance under name constrained ICAs

 

Weighing in for a Root Program (Chrome, i.e. wearing a Chrome Hat)

[Ryan Sleevi]

It sounds like you’re saying something different: that you don’t believe it’s prohibited today (“improve the policy to disallow”).

Given that you don’t feel it’s clear today, perhaps you’d be able to file the issue and suggest language you feel would be clear? I think that is always the challenge when folks say something isn’t clear; by having them phrase the expected requirement in their own words, it can often help reveal where the disconnects are, and allow drafters to improve going forward.

[Matt Palmer]

On Fri, Jul 23, 2021 at 09:58:11AM +0000, Rob Stradling wrote:
> Having judged a cert to have been misissued, should(*) it necessary follow
> that that cert MUST be revoked?
>
> I'm thinking in particular of misissuances where an external event could
> cause the misissued certificate to no longer be "wrong". For example, if
> a viable trust path later came into existence in Rufus's example, what
> purpose would be served by requiring the (potentially) misissued cert to
> then be revoked?
>
> We had a similar discussion internally at Sectigo earlier this month
> during preparations to revoke a bunch of certs (that are listed in
> https://bugzilla.mozilla.org/show_bug.cgi?id=1718771) for which we
> discovered that, at time of issuance, we hadn't performed DCV recently
> enough for all of the domains in each cert. BR 4.9.1.1 requires
> revocation within 24 hours if "The CA obtains evidence that the validation
> of domain authorization or control for any Fully‐Qualified Domain Name or
> IP address in the Certificate should not be relied upon". We wondered: if
> we could perform fresh DCV checks for the affected domains before those 24
> hours elapse, then "should not be relied upon" will no longer be the case
> - what purpose would then be served by revoking these certs?

Absent a time machine, I don't see how you could perform a BR-compliant DCV
that would ensure that the domain was under the control of the subscriber
when the certificate was issued, hence that would trip the revocation
requirement, because the information in the certificate could not be relied
upon at some point during the certificate's validity period.

- Matt

[Phillip Hallam-Baker]

This is (one of) the things we have Certificate Transparency for. It is the time machine you seek.

I can imagine scenarios in which we might have separate intermediates with different policies. Especially if corporate acquisitions or dispositions are involved. One day example.com and example.net are under the same management, the next, they are not.

There is a similar issue with validating CAA entries. It is the entry at the time the certificate is issued that counts.

If this is an issue that is of concern, a CA is going to need to log intermediaries in their CT logs so they can establish that there was a valid path for issuance.

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/20210726043030.GD27405%40hezmatt.org.

[Corey Bonnell]

> If this is an issue that is of concern, a CA is going to need to log intermediaries in their CT logs so they can establish that there was a valid path for issuance.

 

Mozilla does not have a formal CT policy, but it does have CCADB. It would be reasonable to require disclosure of TCSC certificates within one week of issuance and before any end-entity certificates have been issued (i.e., the same disclosure requirements as non-technically constrained CA certificates). Requiring such disclosure would provide visibility into the ecosystem using existing mechanisms.

 

Thanks,

Corey

 

From: dev-secur...@mozilla.org <dev-secur...@mozilla.org> On Behalf Of Phillip Hallam-Baker
Sent: Monday, July 26, 2021 1:57 AM
To: Matt Palmer <mpa...@hezmatt.org>
Cc: dev-secur...@mozilla.org
Subject: Re: Your opinion on misissuance under name constrained ICAs

 

This is (one of) the things we have Certificate Transparency for. It is the time machine you seek.

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAMm%2BLwjyMdgDnh4zeFGzV2JGmC%2BoToKmrBpcDV5fcYXgrpqhPw%40mail.gmail.com.

[Phillip Hallam-Baker]

As technologies go, 'blockchain' is one of the most overhyped in history. This is one of the few applications where it actually has some relevance. Seems strange not to use it.

And yes, it is a 30 year old technology that the field only rediscovered after the patent ran out.

[Buschart, Rufus]

Hello Dimitris!

Thank you for your reply and your willingness to disclose about your experiences. I would like to understand:

1) Do you operate all the different ICAs in a central environment or is every of these ICAs operated by the said university? (for the following questions, I assume you operate them centrally).
2) To set up all those ICAs, do you use some automation? Or is everything created manually?
3) What is you experience how often do you have to modify those ICAs due to changes in the name constraints? Do you do this also outside of the regular interval for rekeying / renewale?
4) Do you involve your auditor in each of these events?
5) For each of the ICAs you must generate OCSP signer keys / certificates. Do you backup those keys and have to access the HSMs therefore physically?
6) Are there any special considerations to be done in the yearly audit?

The background to my questions is, that I would like to understand how good the processes of a CA can scale if the CA is not only maintaining a few number of TLS CAs but > 50.

With best regards,
Rufus Buschart

Siemens AG
Information Technology
Infrastructure

> -----Original Message-----
> From: dev-secur...@mozilla.org <dev-secur...@mozilla.org> On Behalf Of Dimitris Zacharopoulos
> Sent: Samstag, 24. Juli 2021 10:16
> To: Buschart, Rufus (IT IN COR TSQ-1) <rufus.b...@siemens.com>; dev-secur...@mozilla.org
> Subject: Re: Your opinion on misissuance under name constrained ICAs)
>
>
>
> On 24/7/2021 1:54 π.μ., Buschart, Rufus wrote:
> > 1) I would love to hear from HARICA about their experiences with their approach of having a lot of name-constrained ICAs, since this
> is very different to what everybody else seems to be doing.
>
> Hi Rufus,
>
> What exactly are you hoping to hear? "experiences" is pretty wide :-)
>
> Please note that our replies might be delayed as several people are on vacation.
>
>
> Best regards,
> Dimitris.

>
> --
> You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
> To view this discussion on the web visit

> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fa%2Fmozilla.org%2Fd%2Fmsgid%2Fde
> v-security-policy%2F1a302f08-81c6-3e30-c87c-
> 70d0fd8ef556%2540it.auth.gr&amp;data=04%7C01%7Crufus.buschart%40siemens.com%7C943298beabbf40f040cf08d94e7b3d23%7C3
> 8ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637627113474858162%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL
> CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=kg103A1h0RMe%2Bntun2NrIM09sZjNeMUqrJIjZdaIyHw%3D
> &amp;reserved=0.

[Rob Stradling]

Hi Matt.  

> Absent a time machine, I don't see how you could perform a BR-compliant DCV that would ensure that the domain was under the control of the subscriber when the certificate was issued,

I can't do that, and I wasn't suggesting that I could.

> hence that would trip the revocation requirement, because the information in the certificate could not be relied upon at some point during the certificate's validity period.

Yes, I understand that it would trip the revocation requirement in the current BRs.

The point of this sub-thread is to consider whether or not that BR revocation requirement is always reasonable and helpful.  Specifically, what's in the past is in the past; and unlike S/MIME certificates and Code Signing certificates, TLS certificates are not intended to be used to validate historical signatures.  So, if a DCV anomaly is discovered and swiftly "fixed" midway through TLS certificate X's lifetime, how exactly would or could relying parties be harmed by the subsequent non-revocation of certificate X?

Revoking certificate X could certainly cause pain(*) for the Subscriber, who probably isn't going to find "just because the BRs say so" a particularly satisfying explanation of why their certificate had to be revoked.  Why(**) do the BRs say so?  Who is protected or helped by the revocation of certificate X, and how?

(*) Yes, full PKI automation everywhere would be great, but we're not there yet.

(**) Do any of the following capture a/the reason(s) why the BRs require certificate X to be revoked?

  - "Somebody might invent a time machine one day"
  - "The CA screwed up, so the CA must be punished by being forced to revoke the certificate"

  - "Requiring revocation for every misissuance keeps things simple; let's not add complexity"

  - "The BR authors did not consider the possibility that the effects of some classes of misissuance could be mitigated part-way through a certificate's lifetime"

---

From: dev-secur...@mozilla.org <dev-secur...@mozilla.org> on behalf of Matt Palmer <mpa...@hezmatt.org>
Sent: 26 July 2021 05:30
To: dev-secur...@mozilla.org <dev-secur...@mozilla.org>

Subject: Re: Your opinion on misissuance under name constrained ICAs

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.

On Fri, Jul 23, 2021 at 09:58:11AM +0000, Rob Stradling wrote:
> Having judged a cert to have been misissued, should(*) it necessary follow
> that that cert MUST be revoked?
>
> I'm thinking in particular of misissuances where an external event could
> cause the misissued certificate to no longer be "wrong".  For example, if
> a viable trust path later came into existence in Rufus's example, what
> purpose would be served by requiring the (potentially) misissued cert to
> then be revoked?
>
> We had a similar discussion internally at Sectigo earlier this month
> during preparations to revoke a bunch of certs (that are listed in

> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.mozilla.org%2Fshow_bug.cgi%3Fid%3D1718771&amp;data=04%7C01%7Crob%40sectigo.com%7C3188b6cb08b24166f67408d94fee21e7%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637628706467271133%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=GrTXtWLeSi%2B1r6oVmVPszIh3%2BIE1zG3a1E%2F4ovApzeg%3D&amp;reserved=0) for which we

> discovered that, at time of issuance, we hadn't performed DCV recently
> enough for all of the domains in each cert.  BR 4.9.1.1 requires
> revocation within 24 hours if "The CA obtains evidence that the validation
> of domain authorization or control for any Fully‐Qualified Domain Name or
> IP address in the Certificate should not be relied upon".  We wondered: if
> we could perform fresh DCV checks for the affected domains before those 24
> hours elapse, then "should not be relied upon" will no longer be the case
> - what purpose would then be served by revoking these certs?

Absent a time machine, I don't see how you could perform a BR-compliant DCV
that would ensure that the domain was under the control of the subscriber
when the certificate was issued, hence that would trip the revocation
requirement, because the information in the certificate could not be relied
upon at some point during the certificate's validity period.

- Matt

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.

To view this discussion on the web visit https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fa%2Fmozilla.org%2Fd%2Fmsgid%2Fdev-security-policy%2F20210726043030.GD27405%2540hezmatt.org&amp;data=04%7C01%7Crob%40sectigo.com%7C3188b6cb08b24166f67408d94fee21e7%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637628706467271133%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=uXoVkSrUoVqqSIBSzHH81vJH5%2BowqxHkjsb5%2FgZgjBE%3D&amp;reserved=0.

[Buschart, Rufus]

Hello!

From: Ryan Sleevi <ry...@sleevi.com>
>> On Fri, Jul 23, 2021 at 6:54 PM Buschart, Rufus <mailto:rufus.b...@siemens.com> wrote:
>> This analysis leads me to the following points:
>> 1) I would love to hear from HARICA about their experiences with their approach of having a lot of name-constrained ICAs,
>> since this is very different to what everybody else seems to be doing.
>>

> What do you mean, different?

Since HARICA is the owner of 73% of all ICAs with name constraints in crt.sh it seems to be obvious, that they are doing something fundamentally different than the rest of the community. I'm not saying that they do something wrong and I don't want to judge it, but I would like to learn from their experiences.
 
>> 2) For S/MIME there is a demand for name constrained Enterprise CAs. I would assume, that this demand will increase when
>> the market for S/MIME certificates increases (which I expect to come with ACME for S/MIME being available now). --> This
>> topic should be further discussed in the S/MIME WG
>> 3) For TLS I wonder if there is a market for name-constrained ICAs at all. And if there is no market, it would be worth discussing
>> if it would reduce complexity and error-proneness for the overall TLS ecosystem when name-constrained TLS ICAs are banned in
>> general.
> I've read your mail a few times, and I'm not sure I understand exactly what you're trying to figure out, or what you're proposing?

Thank you for the feedback that the intention of my email isn't clear. Writing emails late at night is not always the best idea. I hope this one is more understandable.

> For example, you discuss forbidding name-constrained TLS ICAs, but I'm not fully sure I understand why? Is it simply because they're
> just as subjected to the BRs as other CAs, excluding the audit? Or is it something else? 

First I would like to start a discussion if the Mozilla PKI community sees Name Constraint ICAs as a security benefit for the overall ecosystem. If yes, then the community should, in my opinion, think about possible steps to make them a more common thing and therewith increase the overall security. If no, then the community should think if the possibility of the existence of Name Constraint ICAs does harm to the ecosystem.

> That is, I'm not sure I understand your "problem statement" or "goal". We could, for example, compare how many CAs are effectively
> doing "white-label" sub-CAs - where a different O value for the sub-CA, even though its audit is the same as parent, and whose
> sub-CA solely exists for marketing purposes.

This is an interesting research task in crt.sh. I'll see if I'm able to create a query to generate some statistics on this. I have to say, this will take some time.

> If our goal is to improve agility of the ecosystem, forbidding those (as well?) seems
> valuable. Why does a CA need 200 intermediates, if they're all just as capable, and all operationally part of the same infrastructure
> (thus, don't reduce risk).

Maybe the other way around would be interesting to think about as well. Would a 'white-label' ICA be an ideal candidate for Name Constraints? Take for example this ICA: https://crt.sh/?Identity=%25&iCAID=180349 It is hosted on-prem at a commercial CA and we could easily have a name constrained on .siemens.com in this ICA. Having such a name constraint would reduce the possibility of abuse of this CA and therefore increase (even if only marginally) the security of the ecosystem. But currently having name constraints in it is bringing no benefit to neither the CA nor the company paying for this CA, so there are none in it.

[Dimitris Zacharopoulos]

On 26/7/2021 6:44 μ.μ., Buschart, Rufus wrote:

Hello Dimitris!

Thank you for your reply and your willingness to disclose about your experiences. I would like to understand:

1) Do you operate all the different ICAs in a central environment or is every of these ICAs operated by the said university? (for the following questions, I assume you operate them centrally).

All ICAs are centrally managed. Originally there was a plan to allow Universities to operate technically constrained subCAs that would only need to be internally audited per the BRs. We were very much concerned about the auditing process and the scope of the audit because the BRs were a bit unclear. When we investigated this issue with various colleagues working in other CAs, various auditors, security consultants, browser representatives, there were many different interpretations. Some said that we would only need to audit the issued certificates (3%). Our understanding was that we would probably have to audit the entirety of the BRs, but do that internally.

We decided not to allow transfer of key material or CA key generation associated with TCSCs to Universities or other Research Institutions because the internal audit burden (assuming the scope was the entirety of the BRs+NetSec) and the risks associated with operating everything in accordance with the BRs+NetSec were significantly higher compared with the little gain of having independent infrastructures operating outside HARICA's central management.

2) To set up all those ICAs, do you use some automation? Or is everything created manually?

We automate as much as possible, but there are steps that require human interaction or a human to make decisions and therefore can't be entirely automated.

3) What is you experience how often do you have to modify those ICAs due to changes in the name constraints? Do you do this also outside of the regular interval for rekeying / renewale?

It's not frequent but it does happen for time to time. Yes.

4) Do you involve your auditor in each of these events?

Our auditors are always involved when a CA Certificate is issued (in any form, meaning it covers re-issuance, renewal, re-key), revoked or a CA key is destroyed.

5) For each of the ICAs you must generate OCSP signer keys / certificates. Do you backup those keys and have to access the HSMs therefore physically?

We backup OCSP keys, but we are also planning to move to pre-signed OCSP responses from the CAs, where possible.

I can't really see the relevance with the TCSC topic though, this is the case for unconstrained subCAs as well.

6) Are there any special considerations to be done in the yearly audit?

No. I explained the reasons why we didn't decide to allow for externally technically constrained subCAs so our audits are like any audit of unconstrained subCAs.

It is quite possible that you have identified HARICA as the CA with most technically constrained subCAs because we decided to disclose our TCSC Certificate in CCADB although the current Mozilla Policy does not require it. It's very likely that other CAs have TCSCs that have not been disclosed and could have a different approach from HARICA.

In such a case, I would also be very much interested to understand the audit scope for TCSCs and get some clarity from the Root Store managers about the expectations, since the BRs are not entirely clear on the audit scope for TCSCs.


Best regards,
Dimitris.

The background to my questions is, that I would like to understand how good the processes of a CA can scale if the CA is not only maintaining a few number of TLS CAs but > 50.

With best regards,
Rufus Buschart

Siemens AG
Information Technology
Infrastructure

-----Original Message-----
From: dev-secur...@mozilla.org <dev-secur...@mozilla.org> On Behalf Of Dimitris Zacharopoulos
Sent: Samstag, 24. Juli 2021 10:16
To: Buschart, Rufus (IT IN COR TSQ-1) <rufus.b...@siemens.com>; dev-secur...@mozilla.org
Subject: Re: Your opinion on misissuance under name constrained ICAs)



On 24/7/2021 1:54 π.μ., Buschart, Rufus wrote:

1) I would love to hear from HARICA about their experiences with their approach of having a lot of name-constrained ICAs, since this

is very different to what everybody else seems to be doing.

Hi Rufus,

What exactly are you hoping to hear? "experiences" is pretty wide

[Ryan Sleevi]

On Tue, Jul 27, 2021 at 12:12 PM Dimitris Zacharopoulos <ji...@it.auth.gr> wrote:

6) Are there any special considerations to be done in the yearly audit?

No. I explained the reasons why we didn't decide to allow for externally technically constrained subCAs so our audits are like any audit of unconstrained subCAs.

It is quite possible that you have identified HARICA as the CA with most technically constrained subCAs because we decided to disclose our TCSC Certificate in CCADB although the current Mozilla Policy does not require it. It's very likely that other CAs have TCSCs that have not been disclosed and could have a different approach from HARICA.

In such a case, I would also be very much interested to understand the audit scope for TCSCs and get some clarity from the Root Store managers about the expectations, since the BRs are not entirely clear on the audit scope for TCSCs.

I think there are two things to separate out here:

• The compliance obligations of the TCSC
• The audit obligations imposed on the issuer of the TCSC

TCSCs are subjected to the full compliance obligations of the BRs, with the following exceptions:

• CAA checking grandfathering in 3.2.2.8 (related to the historic question of delegation of domain validation and the use of off-prem-of-CA subCAs)
• OCSP responder grandfathering in 4.9.10 (probably can be removed at this point, existed for the off-prem-of-CA subCAs)
• The exemption to sections 8.2, 8.3, 8.4, 8.5, and 8.6 by Section 8.1

TCSCs are subjected to the following BR audit requirements:

• Section 8.1 requires compliance with Section 8.7
• Section 8.7 requires "SHALL monitor adherence to the CA's Certificate Policy and the Subordinate CA's Certification Practice Statement". This requires the full scope of CP/CPS, which by reference will include the full scope of the BRs. This is a form of supervision, but it's understandably questionable whether to call it an audit (e.g. there is no requirement to use the controls from the schemes in Section 8.4)
• Section 8.7 additionally requires the quarterly, 1 cert/3% certs sampling to ensure "all applicable CP are met"

Put differently: There is a continuous obligation to supervise practices, and a quarterly obligation to supervise the actual issued certificates against the CP.

In addition, from a Mozilla Root Store Policy, there is a similar compliance/audit split:

Compliance to Mozilla Policy

• Section 1.1 makes it unambiguous that these certificates are in-scope
• Section 2.3 is made explicitly clear as applying, by virtue of Section 5.3.1 (this is a reiteration, not a limitation)

TCSCs are subject to the following Mozilla audit requirements:

• Section 5.3.2 explicitly exempts them from the Mozilla audit requirements.
• Section 8 explicitly exempts TCSCs, although it does not exempt unconstrained intermediates that chain to/through TCSCs (there is past discussion on the list). This exemption further exempts from audit requirements, such as those in Section 8.3 regarding transfers.

To Rufus' goal/question on the parallel thread, this means that TCSCs have the potential to create more risk, even if they may not presently be doing so in practice:

• CAA checking may not be performed. As such, a TCSC may be seen as a way to reintroduce BygoneSSL-style attacks, by using the TCSC for a domain no longer in the holders control.
• TCSCs themselves bypass domain validation lifetime limits, by virtue of no profile restricting the validity period of the TCSC to the domain validation period Subscriber certificates are subjected to. There is ostensibly no requirement for regular revalidation, although 4.9.1.2 of the BRs does require revocation if the CA obtains evidence the TCSC is no longer authorized. This, in effect, creates an incentive for CAs do "not look" at domain validation.
• OCSP services are presumed to be less reliable, and in practice, historically were less reliable.
• Although the obligations for compliance exist, the interpretation of those requirements is left to a non-independent party (the issuing CA) without any form of requirement as to how to assess compliance with the CA's CP or CPS. For example, auditing certificates may reveal mismatches on the certificate profile, but would not reveal a compromise of the TCSC's private key. While this harm may be mitigated to being "similar to" a compromise of a TLS server's private key (which CAs both cannot and are not expected to audit, simply respond to reports of this), the aforementioned certificate lifetime issues exacerbates the risk to clients with unreliable checking of intermediates.
• The aforementioned unreliability of revocation information (both in terms of OCSP services and key compromise events) are exacerbated by the fact that sub-CAs have different revocation publication timeline requirements, in a way that allows attackers to potentially use a compromised key much longer than they would be able to with a Subscriber certificate. That is, the 10 day window for OCSP/CRLs, versus the 1 year window for intermediates. While there is a prompt revocation requirement, the ability to provide past "known-good" responses (whether via multi-staple, TLS 1.3, or through MITM'ing the HTTP connection to the repository) effectively mean the window for compromise is significantly longer.
• The inability to distinguish such certificates as on-prem vs off-prem, by virtue of the Section 8 exemption in Mozilla policy not requiring disclosure of such changes, combined with the Section 5.3.2 requirement not requiring disclosure at all.

So, to Rufus' original question about whether nameConstraints are net-positive or net-harmful: They remain net-harmful over managed CA scenarios (where the TCSC is operated on-prem by the issuing CA), but they were a net-positive over the legacy on-prem CAs that TCSCs were introduced to phase out. In 2021, there's not a compelling benefit, to end users / relying parties, to issuing such certificates.

[Ben Wilson]

On Tue, Jul 27, 2021 at 10:12 AM Dimitris Zacharopoulos <ji...@it.auth.gr> wrote:

It is quite possible that you have identified HARICA as the CA with most technically constrained subCAs because we decided to disclose our TCSC Certificate in CCADB although the current Mozilla Policy does not require it. It's very likely that other CAs have TCSCs that have not been disclosed and could have a different approach from HARICA.

Maybe Section 5.3 of the Mozilla Root Store Policy should be amended to require disclosure in the CCADB of TCSC Certificates, especially now that other root stores rely on the CCADB?

Ben

[Buschart, Rufus]

> From: Ben Wilson <bwi...@mozilla.com>
> Sent: Dienstag, 27. Juli 2021 19:10

Until this email I wasn't even aware that there is such an exception for TCSC. Yes, I would support this
Proposal and I would propose to enforce this disclosure for all sub CAs chaining to a Mozilla trusted root,
regardless of the EKU / KU.

[Dimitris Zacharopoulos]

Thank you very much for the insight and detailed analysis. It is extremely helpful for making people understand the challenges, expectations and nuances for allowing an externally-operated Technically Constrained subCA.

I'm sure external auditors will be in a better position to understand what controls the parent CA must have in place to effectively audit a TCSC even if they don't audit the TCSC themselves.

Obviously CAs may need to revisit their internal auditing programs to ensure that all requirements of the BRs (with the exceptions you highlighted) are met and how this is supported in their annual external audit.

Dimitris.

[Rufus Buschart]

I created a PR on Github to enforce the disclosure of TCSC to CCADB:  Disclose also TCSC to CCADB by RufusJWB · Pull Request #229 · mozilla/pkipolicy (github.com) . You might want to consider this for the next release for the root store policy.

/Rufus

[Buschart, Rufus]

Dear MDSP community!

I would like to try to summarize the answers on my original question. If you think I misunderstood an answer, please feel free to correct.

We had replies considering my example not a misissuance, as long as the domain validation was performed correctly:

Rob: https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/XsVpyOGlagE/m/FprHuJeHAwAJ
Tim: https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/XsVpyOGlagE/m/A7ItybSJAwAJ
Ryan S: https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/XsVpyOGlagE/m/MIUVYrGZAwAJ
Cynthia (I'm not 100% sure I understood your statement correct): https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/XsVpyOGlagE/m/d4cbD1ukAwAJ

But we also had replies seeing it as a misissuance:

Ryan H: https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/XsVpyOGlagE/m/WkgjfmWIAwAJ
Pedro: https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/XsVpyOGlagE/m/7eqJO37NAgAJ

So I think it is obvious, the situation is not clear. How do we go forward? Would it make more sense to propose a clarifying language on this topic for the next Mozilla Root Store Policies update or does someone wants to take this into the CA/B forum? Personally, I would prefer to discuss this in the context of the Mozilla Root Store Policy and later move it to the CA/B forum as I'm not able to participate in the discussions of the Server Cert WG of the CA/B forum.

/Rufus

> -----Original Message-----
> From: dev-secur...@mozilla.org <dev-secur...@mozilla.org> On

> Behalf Of Buschart, Rufus
> Sent: Wednesday, 21 July 2021 17:01
> To: dev-secur...@mozilla.org
> Subject: Your opinion on misissuance under name constrained ICAs
>
> Dear MDSP community!
>
> I would like to ask for your opinion in regards to the following scenario:
>
> Let there be an Issuing CA that is name constrained (acc. BRGs 7.1.5) to the
> issuance of certificates only for example.com. Now this Issuing CA issues an
> end-entity certificate for example2.com. This certificate would be un-
> trusted, but would this be considered a misissuance? And would it make a
> difference if the Issuing CA has successfully performed a domain validation
> according to the BRGs before issuing the end-entity certificate?
>
> I couldn't find any rules for this in the BRGs nor a discussion on this within the
> archive of this mailing list.
>
>
> With best regards
>
> Rufus Buschart
> Siemens AG
>

> --
> You received this message because you are subscribed to the Google Groups
> "dev-secur...@mozilla.org" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to dev-security-po...@mozilla.org.
> To view this discussion on the web visit
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgrou
> ps.google.com%2Fa%2Fmozilla.org%2Fd%2Fmsgid%2Fdev-security-

> policy%2FAM8PR10MB430551044C73C395B64451499EE39%2540AM8PR10MB
> 4305.EURPRD10.PROD.OUTLOOK.COM&amp;data=04%7C01%7Crufus.buscha
> rt%40siemens.com%7C8cfdc07eef1a47a1f7b108d94c585f26%7C38ae3bcd957
> 94fd4addab42e1495d55a%7C1%7C0%7C637624764698315053%7CUnknown%
> 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haW
> wiLCJXVCI6Mn0%3D%7C1000&amp;sdata=lkkAOmOpsTgfkg3KcIyPgpm4M8c
> yzLM76Qh%2BbYk4PZU%3D&amp;reserved=0.

[Ryan Sleevi]

On Wed, Aug 4, 2021 at 5:46 AM Buschart, Rufus <rufus.b...@siemens.com> wrote:

Ryan S: https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/XsVpyOGlagE/m/MIUVYrGZAwAJ

I realize in posing the “thought experiment” it may not have been clear where I personally stand: I would prefer CAs consistently treat it as misissuance, even if they feel it is ambiguous or disagree, and believe _this specific example_ should be considered misissuance, even if domain validation was properly performed.

[Buschart, Rufus]

Thank you for clarification! But you would support the overall insight: currently it is not clear from the BRGs or the Mozilla Root Store Policy if this is a misissuance or not and we should clarify it?

 

/Rufus

 

From: dev-secur...@mozilla.org <dev-secur...@mozilla.org> On Behalf Of Ryan Sleevi

Sent: Wednesday, 4 August 2021 17:18
To: Buschart, Rufus (IT IN COR TSQ-1) <rufus.b...@siemens.com>

--

You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAErg%3DHF_sUOTeea1Pb9T3VHBuAox%2B6iBijaC180wnMCNwYAUYA%40mail.gmail.com.

[Ryan Sleevi]

On Wed, Aug 4, 2021 at 11:37 AM Buschart, Rufus <rufus.b...@siemens.com> wrote:

Thank you for clarification! But you would support the overall insight: currently it is not clear from the BRGs or the Mozilla Root Store Policy if this is a misissuance or not and we should clarify it?

Yes, this is something that has come up in the CA/Browser Forum before, although I don't have the links readily handy. Broadly, the discussion about what a CA can use their private key for also directly relates to the question about "what is an acceptable certificate to sign". Your question here, regarding an NC-violating EE certificate, is a subset of the broader problem of a "certificate which does not validate". I provided an example of a different manifestation of this problem, which was admirably handled, but it still remains broad.

The work of Certificate Profiles in the Validation Subcommitee, in part, is my attempt to formally tackle this. While I would love to be more ambitious in the initial scope, it's clear that CA members are not quite there yet, hence the multi-phase approach. My hope and goal is to ensure that the BRs are unambiguous regarding the expectations for compliance with RFC 5280, which, although this is already an _existing_ requirement, is not fully understood through its practical implications.

I don't believe this is something easily tackled with policy, if only because I believe the root cause is one that begins at a technical level with data being signed, and flows from there, which is why I've been focusing my time in this space.