Re: [TLS] Working group last call for draft-ietf-tls-subcerts-07

[Ryan Sleevi <[e-mail]>]

On Thu, May 21, 2020 at 10:51 AM Russ Housley <[e-mail]> wrote:

>
>
> On May 21, 2020, at 10:12 AM, Ryan Sleevi <[e-mail]> wrote:
>
>
> On Wed, May 20, 2020 at 6:40 PM Russ Housley <[e-mail]> wrote:
>
>> MINOR
>>
>> Section 1 also says:
>>
>>    Because the above problems do not relate to the CA's inherent
>>    function of validating possession of names, ....
>>
>> The CA is responsible for confirming that the public key in the
>> certificate corresponds to a private key that can be used by the
>> certificate subject.  This is usually done by a proof of possession
>> mechanism.  So, I think that the start of this sentence should be
>> reworded to avoid the impression that the CA only validates the
>> name.
>>
>
> The existing framing is correct. The most widely used Internet PKI, the
> Web PKI, intentionally doesn’t not require a proof of possession mechanism.
> It is not used as an authentication mechanism (i.e. a binding of a key to
> an identity) but an authorization mechanism (i.e. a binding of an
> authorized set of identities to a key).
>
> The “CA only validates the name” is not just an impression, it’s the
> widespread running code. Due to how TLS certificates are used (online
> protocol negotiation, without non-repudiation support), there’s no risk
> opened nor any necessity to do a strong proof of possession binding, even
> in cases of strong identity binding.
>
>
> The CSR is signed with the key to be certified.  That is proof of
> possession.
>

None of these CAs are required to use CSRs or validate signatures. You’re
describing ways a CA could implement POP, but as I said, proof of
possession is not required.

That’s why the current text more accurately reflects the rough consensus of
popular root programs and the running code that trusts those CAs.

It’s certainly true that implementors of DC could reach agreements with CAs
to require POPs, but it’s also not necessary for the protocol (DC or
broadly TLS), which is why it’s not done or required.


>
> QUESTION
>>
>> While I have no objection to the DelegationUsage extension,
>> I wonder is an extended key usage would provide the same
>> confidence in the certificate.
>>
>
> In practice, no. As things currently are, it would unfortunately undermine
> the confidence, although this an entirely fair and reasonable question.
>
> As a recap (and more for those without the same context you have) the way
> 5280 and it’s predecessors were designed, the Certificate Policies
> extension is the primary means of expressing or indicating compliance to a
> particular policy. If a relying party explicitly attempts to validate a
> certificate, for a RP-determined Certificate Policy, then they can know
> whether or not that certificate complied with their expectations for
> issuance and management. This is all defined within 5280, albeit quite
> complex, and involves processing rules for both leaves and intermediates,
> as well as the ability to map between different policies (via
> policyMappings), such that an RP expecting policy A can validate a
> certificate bearing only policy B, provided some trusted party in the
> certification path asserted that B was equal-or-equivalent-to A
>
> Additionally, certificates have the extendedKeyUsage, which is most
> commonly used to restrict the protocol or protocols a given certificate can
> be used for. In RFC 5280 and friends, this restriction only applies to lead
> certificates. However, from the very earliest days of PKIX, the two main
> implementations (Microsoft and Netscape) diverged from this, in unspecified
> ways that ultimately PKIX declined to incorporate, to allow EKUs to be used
> on intermediates to restrict the protocols that certificates can be issued
> for. If a leaf EKU is not a subset of its issuing chain, then that EKU is
> not permitted; much like policy OIDs.
>
> This divergence, which has existed since the very earliest days of TLS,
> resulted in a different approach to managing policy than the idealized goal
> of PKIX. Rather than having every relying party application provide an
> initial policy, such as a policy OID assigned by the root store vendor
> (typically the OS/browser vendor), to indicate compliance with the root
> store’s policy, and using policy mappings for that, implementations simply
> used the EKU as a joint indicator for “uses protocol X and complies with
> the issuance policies for protocol X, as defined by the root store vendor”.
>
> This whole long preamble builds to our present day. In wide practice, and
> even for those root stores/OSes/applications that do not implement EKU
> chaining in the fashion mentioned above, the mere presence of an EKU is the
> indicator for compliance with a set of policies, and altering EKUs, like
> altering policy OIDs, requires issuing new intermediates permitted for that
> EKU.
>
> If DC certificates only bore a DC EKU, they would, in effect, be exempt
> from all of the certificate policies widely practiced for the issuance of
> TLS certificates, which would reduce the confidence in the certificate.
> They would also typically require the CA to issue new intermediate
> certificates prior to being able to issue such certificates that were
> accepted. For applications, the certificate validation libraries apply
> local policy to certificates based on their EKU via technical measures, to
> ensure they match the expected issuance policy, such as checking for
> certificate transparency information or limiting the maximum validity
> period the application will accept.
>
> Recall that the design of DC is also possible via simply nameConstrained
> subCAs, but part of the reason for DC is that it does not require or
> reduces dependencies on external PKIs in order to satisfy local protocol
> needs. The same argument applies here against EKU: to use EKU would place
> ongoing dependencies back on those external PKI, be incompatible with how
> those PKIs are typically administered, and would cause significant
> challenges for applications implementing on common libraries (such as those
> provided by their OS).
>
> It’s far from perfect, but the current state of the art is this approach.
> If something is meant to be “like” TLS, at minimum, it needs to contain the
> TLS EKU, so it is subjected to the TLS policies and usable with TLS
> validation stacks. Extensions, with or without the critical bit set, serve
> as the way to distinguish whether and how it should be usable with TLS and
> the “something like TLS” protocol.
>
> An EKU certainly could be pursued, and it’s by no means an unreasonable
> question, but in order to provide the same confidence as currently
> specified, existing root store policies would need to be rewritten and
> redefined to include that EKU in scope of their “subject to TLS”, as would
> their software and validation libraries similarly be updated to process
> that.
>
>
> I am aware of the "fight" about EKU chaining.  I have a view, but I did
> not really want to drag subcerts into that controversy.
>

Sure, but unfortunately, the design of DC/subcerts is a direct result of
that running code.

Certain root programs are trying to bridge those gaps (Google and
Microsoft, notably), in a way that perhaps 5-10 years from now we might see
a change to how things were imagined 20-25 years ago, but unfortunately,
that’s the reality of software today, and DC is living in those constraints.

I guess I ask the authors to add a paragraph to the rationale section that
> says something about why this extension was used instead of an extended key
> usage.
>

Sure, I think that could be useful, since if only looking at this and 5280,
the gap I mentioned previously is not at all obvious, and why I wanted to
capture some of it on the list, for those not familiar.

>