On 2/5/19 4:36 μ.μ., Ryan Sleevi via dev-security-policy wrote:
> On Thu, May 2, 2019 at 9:14 AM Fotis Loukos <[email protected]> wrote:
>
>> The PCA (I am calling it PCA even if it does not follow all the design
>> and architecture of RFC5288 PCAs for simplicity's sake) has the
>> technical ability to issue both TLS and S/MIME end-entity certs but is
>> constrained to issue only SubCAs by policy. The same rule applies to
>> Root CAs for example, which have the technical ability to issue
>> end-entity certificates, but they are restricted by policy (once again,
>> for simplicity's sake let's not get into the different rules and
>> different validations that are stated in RFC5280 for trust anchors
>> because if we want to be technically correct with everything, EKUs on
>> intermediates have no meaning). I do not see any reason that the risk to
>> the ecosystem is increased from this CA. No end-entity certificates are
>> issued, and thus there is no place for misconduct.
>>
>
> I don't think it's fair to say there's no place for misconduct. I think
> this may be a distinction in how we approach technical controls versus
> procedural controls. The number of failures of procedural controls in the
> CA incident dashboard is staggering, and many of them could have been
> addressed via technical controls.
>
> Obviously, as a tech guy, I'm going to be biased to technically verifiable
> controls over "Trust us", especially when the "trust" involves both the CA
> and the Auditor/CAB.
I agree with you that technically verifiable controls are always better
than procedural controls, however we are already relying on procedural
controls for many of the requirements, such as CAA. In addition, this
specific change can be monitored in the WebPKI ecosystem using CT.
>
> I do not see any reason how the ecosystem is *helped* by this model, and I
> think that's the thing. It might be comparable to consider the notion of
> self-issued key rollover. While defined in RFC 5280, and thus 'legal' in a
> sense, it causes unnecessary complexity and risk compared to alternative
> designs and solutions. As much as possible, I think we want to keep the
> PKIs that are trusted on the 'happy' path.
I have already displayed the benefit, but I will elaborate more on this
later.
>
>
>> All intermediates underneath that CA will be restricted by EKU (unless
>> they are PCAs themselves, so the afforementioned analysis applies to
>> them too). This is what the Mozilla Root Store Policy already uses, and
>> I think we both agree that this is safe.
>>
>> So I can't identify how we the risk is increased.
>>
>
> As I just stated above, you're fundamentally relying on a policy-level
> control, which means increasing the reliance on audits, and creating
> significantly greater risk of a policy-control failure, whether due to
> misunderstanding, malice, or incompetence. We can and should work to
> improve the systems so we have greater technical verifiability - whether
> that's through EKU constraints or more ecosystem-wide things such as
> pre-issuance linting and Certificate Transparency-based post-issuance
> linting.
I agree with you, but should we become "slaves" of technical controls
and limit functionality in order to accomodate them?
>
> Hopefully that more clearly spells out the fundamental philosophical
> difference in approaches, and why it's important to highlight what the
> benefits are of the policy based solution, for browsers and end users,
> since they bear the risk. As it stands, it seems CAs are the only ones that
> benefit, as you've presented, but even then, it's not clear that that's
> actually true.
>
>
>>> I just want to highlight that there's a difference between whether or not
>>> you see the risk and whether or not others see the benefit. I think it'd
>> be
>>> helpful if you highlight the benefit. For example, you highlighted
>>> infrastructure certificates - but those aren't applicable (e.g. an OCSP
>>> certificate)
>>
>> There are organizations who would like to issue both TLS and S/MIME
>> publicly trusted certificates for their uses. With the current model,
>> the "least common denominator" CA is the Root CA.
>
>
> Yes. That is the intentional goal.
>
>
>> However, having a
>> single CA for this organization underneath which all certificates are
>> issued by other SubCAs makes it way more easier in management. I don't
>> think that I need to elaborate more on why this is much easier, I
>> consider it pretty evident.
>>
>
> I think you do need to elaborate on this, because it's also non-obvious
> that it reduces the number of the CAs. I tried to show the math for you in
> comparing the difference of designs, but perhaps you want to explicitly
> expand on how you see a possible joint TLS/S/MIME PKI being designed, under
> the 'ideal' world, so that it might be more clearly discussed.
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.
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)?
Does this clarify why having a single "Org CA" would help in deployment
in some enterprise environments?
>
>
>> I totally agree with the latest sentence, but I think that the
>> discussion is not on changing the audit requirements themselves, but
>> changing which requirements apply to which CAs. And as I stated before,
>> all CAs that chain to a TLS end-entity certificate will be audited
>> against the same requirements they are audited today, no matter if they
>> are issuing CAs, CAs with the serverAuth EKU, or PCAs. Having said that,
>> I don't think that there are changes to the trust model that is
>> currently in effect.
>>
>
> It introduces unneeded complexity which has been a point of
> misunderstanding and misapplication in the past. This changes the model
> from being one of technically inspecting the certificates and comparing the
> audits to one of divining policy, as to whether a given certificate is a
> PCA, and potentially ineffable elements (to anyone but the CA or auditor),
> such as whether the PCA has actually *been* a PCA and not issued any
> end-entity certificates.
I think that if we exclude the "no serverAuth and emailProtection" and
keep the "must have EKU" requirement for PCAs, things will get much more
clear. That CA will be clearly able to issue TLS end-entity
certificates, so it will be under the same audit requirements as other
TLS CAs. We can clarify this in the policy too if that addresses your
concerns on possibly misunderstanding what applies to that CA.
>
> That is a significant change in the risk model - something which can be
> technically verified no longer is.
>
> It could be that we're entirely missing eachother's perspectives, and I
> think that clarifying both what you see the existing 'required' PKI is, and
> how the alternative PKI under your proposal would look, may help clarify
> any confusion or misunderstanding. From there, we can then discuss about
> the risk factors - for users, browsers, and CAs - and the possible
> benefits. Does that sound like a reasonable next step?
Of course. Does the small diagram I presented above help?
Regards,
Fotis
> _______________________________________________
> dev-security-policy mailing list
> [email protected]
> https://lists.mozilla.org/listinfo/dev-security-policy
>
--
Fotis Loukos, PhD
Director of Security Architecture
SSL Corp
e: [email protected]
w: https://www.ssl.com
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
