RE: Your opinion on misissuance under name constrained ICAs)
94 views
Skip to first unread message
Buschart, Rufus
Jul 23, 2021, 6:54:31 PM7/23/21
to dev-secur...@mozilla.org, dzac...@harica.gr
I created (with the help of Rob - thank you) a SQL statement (https://gist.github.com/RufusJWB/ea955620593f0d865a7cdb2b3ec0a390) to do some statistics on crt.sh about the use of name constrained CA. Please find following my results:
In total there are 92 distinct ICAs with name constraints registered in crt.sh which are not revoked and not expired and are capable of issuing either TLS or S/MIME certificates. I filtered the ICAs for modifications, where one ICA exists in multiple versions. Please be aware, that it seems, that not all S/MIME capable, publicly trusted ICAs are disclosed to crt.sh yet.
Out of these 92 ICAs, 67 ICAs are belonging to HARICA (looping in @dzac...@harica.gr as I assume he has an interest in this topic). For the next steps, I excluded those.
Out of the 24 remaining ICAs, only 5 are capable to issue TLS certificates. And it seems that only two of those 5 are still being actively used.
Out of the 24 remaining ICAs 21 are capable of issuing S/MIME certificates. Here it is, due to the lack of CT for S/MIME, not possible to judge, how actively they are in use. But looking into the names of the organizations holding those ICA it is clear, that all of them are Enterprise CAs for tech-affine companies, banks, or public agencies.
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.
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.
With best regards,
Rufus Buschart
Siemens AG
Information Technology
Infrastructure
In total there are 92 distinct ICAs with name constraints registered in crt.sh which are not revoked and not expired and are capable of issuing either TLS or S/MIME certificates. I filtered the ICAs for modifications, where one ICA exists in multiple versions. Please be aware, that it seems, that not all S/MIME capable, publicly trusted ICAs are disclosed to crt.sh yet.
Out of these 92 ICAs, 67 ICAs are belonging to HARICA (looping in @dzac...@harica.gr as I assume he has an interest in this topic). For the next steps, I excluded those.
Out of the 24 remaining ICAs, only 5 are capable to issue TLS certificates. And it seems that only two of those 5 are still being actively used.
Out of the 24 remaining ICAs 21 are capable of issuing S/MIME certificates. Here it is, due to the lack of CT for S/MIME, not possible to judge, how actively they are in use. But looking into the names of the organizations holding those ICA it is clear, that all of them are Enterprise CAs for tech-affine companies, banks, or public agencies.
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.
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.
With best regards,
Rufus Buschart
Siemens AG
Information Technology
Infrastructure
Dimitris Zacharopoulos
Jul 24, 2021, 4:15:46 AM7/24/21
to Buschart, Rufus, dev-secur...@mozilla.org
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.
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.
Ryan Sleevi
Jul 24, 2021, 12:06:28 PM7/24/21
to Buschart, Rufus, dev-secur...@mozilla.org, dzac...@harica.gr
On Fri, Jul 23, 2021 at 6:54 PM Buschart, Rufus <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?
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?
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?
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. 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).
Reply all
Reply to author
Forward
0 new messages