On 08/05/2019 16:05, Ryan Sleevi wrote:
> On Wed, May 8, 2019 at 6:42 AM Fotis Loukos <fot...@ssl.com> wrote:
>
>> ...
> ...
>
>> The scheme I'm proposing is the following:
>>
>> Org CA (serverAuth, emailProtection, and possibly others such as
>> clientAuth)
>> \- Org SSL CA (serverAuth and possibly clientAuth)
>> \- End-entity cert
>> \- Org Mail CA (emailProtection and possibly others such as clientAuth)
>> \- End-entity cert
>>
>> The organization can deploy the "Org CA" as a trusted CA in its internal
>> systems.
>>
>
> Thanks. This clarifies what you meant, and is demonstrably something we
> should not be encouraging.
>
> As you note from this example, the organization can deploy "Org CA" as a
> trusted CA in its internal systems. There's no reason or benefit to use a
> publicly trusted CA hierarchy for this, since you've established the
> precondition that they can already manage their own enterprise CAs.
>
> This example - what you term PCA - is what others might call a "Managed
> CA", and there's no need to cross-certify this managed CA with the public
> hierarchy, if the situation is as you describe.
>
> Of course, if the organization cannot effectively deploy "Org CA", thus
> incentivizing the use of public trust, then there is also no deployment
> headache for the organization; they're relying on the public trust (of the
> root) to confer it to their various applications.
>
[ Note, I am arguing a neutral position on the specific proposal ]
The common purpose of having an internally secured (managed or on-site)
CA in a public hierarchy is to have end certificates which are
simultaneously:
- Trusted by the worldwide public for external communications (public
servers, e-mails to outside parties, signing contracts etc.).
- Trusted at a higher level by internal systems and people, based on
the certainty that no one outside the company security organization
can issue these certificates).
Examples of typical uses for such certificates:
- An extranet portal web server used by customers (WebPKI trust) and
traveling mobile devices (company trust checked strictly by company
installed apps).
- User certificates used for e-mail and system login. E-mail
signatures and encryption trusted by public (S/MIME PKI) and more
strictly checked by internal functions (company trust). System
login using the same certificate is also limited to company trust.
In both cases, the user/system using the certificate does not
distinguish internal/external use and trust models, the distinction
is by relying parties only.
One examples of a specific danger avoided by having such public+private
trusted end certificates and hierarchies include the somewhat common
"CEO fraud", where an external attacker (with an easily obtained
external e-mail address and certificate) contacts the accounting
department pretending to be a higher ranking company officer.
By having the real officers use company-issued certificates for their
e-mails, accounting would automatically get an onscreen notification
that this is an "OUTSIDE E-MAIL", and refuse the payment.
>
>> Under the current scheme, the "Org SSL CA" and the "Org Mail CA" must be
>> issued either by the Root, or by other CAs that chain up to the Root as
>> the least common denominator. The organization would have to either
>> trust the Root as an internally trusted CA, which would mean that they
>> would also place trust in other certificates issued by the same CA (CA
>> as an organization issuing certificates) to different organizations, or
>> deploy both CAs and duplicate controls, if possible (not all software
>> supports this). Of course, they could deploy just a single CA depending
>> on the usage. This adds more management cost, and may lead to other
>> problems. For example, what if a service needs to authenticate users
>> using certificates from both the "Org SSL CA" and the "Org Mail CA"
>> (perfectly valid since both can issue certs having the clientAuth EKU)?
>>
Now if it is difficult for a publicly trusted company PKI to have
different roots for different uses is not something I would know, as
it obviously depends on the common limitations of current enterprise
CA (not public CA) software packages.
However it could be argued that such companies should already have
a second hierarchy for similar certificates that should not be
publicly visible, leading to the following more useful minimal
hierarchy:
Public root CA - R1
\- Public intermediary CA - G2 (optional) [CT logged]
\- Org publicly trusted root - PCA2 [CT logged]
\- Org public trusted intermediary - PY2019 [CT logged]
\- Org end cert with public trust [CT logged if server EKU]
Org root CA - OC1
+- Cross signature of Org public trusted intermediary - PY2019
\- Org internal only intermediary - IY2019
\- Org internal only end cert without public trust
If this is done, it becomes a question if PCA2 and PY2019 should be
duplicated for e-mail versus server certs, like this:
Public root CA - R1
+- Public intermediary WebPKI CA - G2 (optional) [CT logged]
| \- Org publicly trusted server root - PCA2 (optional) [CT logged]
| \- Org public trusted server intermediary - PY2019S [CT logged]
| \- Org server end cert with public trust [CT logged]
\- Public intermediary e-mail CA (optional) - G3 (optional)
\- Org publicly trusted mail root - PCA3 (optional)
\- Org public trusted mail intermediary - PY2019M
\- Org mail end cert with public trust
Org root CA - OC1
+- Cross signature of Org public trusted server intermediary - PY2019S
+- Cross signature of Org public trusted mail intermediary - PY2019M
\- Org internal only intermediary - IY2019
\- Org internal only end cert without public trust
Distributing the internal cross certificates to internal relying
parties (so they get used in preference to the publicly trusted
intermediaries) would also depend on the abilities of corporate
software packages.
>> Does this clarify why having a single "Org CA" would help in deployment
>> in some enterprise environments?
>>
>
> Yes. Hopefully my response demonstrates why, based on the preconditions,
> there is no necessity for the solution you propose, and if we alter those
> conditions, then alternatives such as currently required are better suited.
>
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
