[cabfpub] (Eventually) requiring id-kpServerAuth for all certs in the chain?

[Ryan Sleevi]

On Nov 5, 2014 10:21 AM, "kirk_hall at trendmicro.com" <
kirk_hall at trendmicro.com> wrote:
>
> Again, I’m not necessarily opposing marking intermediates – I am just
wondering if there isn’t an easier way to deal with the problem discussed.
>
>
>
> I asked our team, and they were doubtful about having to reserve
intermediates for SSL only – for example, they might want to use the same
intermediate for S/MIME, etc.
>
>
>
> What if we add a rule that all CAs must list all intermediates “that are
intended for use in SSL” in a specific part of their CPS, and stating that
those intermediates must all be audited?  Wouldn’t that end ambiguity as to
intent?
>

Not if they are technically capable. The goal of both proposals is that
anything technically capable MUST be audited. Intent is irrelevant - and
indeed, the problem.

>
>
> Also – I would assume that the existence of an EE cert used for SSL from
an intermediate is unambiguous intent to use the intermediate for SSL, and
the CA would get in big trouble with browsers.  Is that not true?  Are
there cases where the CA can say “Hey, I thought the cert would be used for
X, and had no idea the customer would also use for SSL”.  Is that happening
today?
>
>

Yes, it has. Which is why the Mozilla policies were reworked to be explicit
about this, and why this better belongs in the BRs, as it matches browsers
_expectations_. Avoiding the BRs will just see browsers doing like Mozilla
and "patching" the issue, which may leas to incompatible language or
expectations.

>
> From: Ryan Sleevi [mailto:sleevi at google.com]
> Sent: Wednesday, November 05, 2014 10:05 AM
>
> To: Kirk Hall (RD-US)
> Cc: Gervase Markham; CABFPub
> Subject: RE: [cabfpub] (Eventually) requiring id-kpServerAuth for all
certs in the chain?
>
>
>
> It only became a violation under Mozilla's policies precisely because of
the BR ambiguity in allowing "intent". Namely, they introduced language
regarding technical capability, with a definition, and require all such
certs conform to Mozilla's policies.
>
> However, even today, under v2.2 of Mozilla's policies, that would allow a
CA to have such intermediates unaudited, since the BRs can allow them to
dismiss the intermediate via intent. It must be disclosed to Mozilla, and
must be audited, but the audit could be to the extent to say "This is out
of scope", which the auditor can then happily certify.
>
> Note that this required specific language from Mozilla to bring in scope
to their requirements what should be quite obvious to CAs. Gerv's proposal
- and the one proposed back in Mountain View and Brian has rechoed here -
both seek ways to incorporating that common sense definition into the BRs,
so that there is no confusion on the expectations of both CAs and auditors.
>
> On Nov 5, 2014 9:53 AM, "kirk_hall at trendmicro.com" <
kirk_hall at trendmicro.com> wrote:
>
> Thanks for the clarification, Ryan.
>
>
>
> Not to argue, but I would point out that if a CA is discovered to be
using an (unconstrained, unmarked) intermediate from a trusted root to
issue SSL certs without subjecting that intermediate and cert to full
WebTrust/ETSI audit coverage – that would be a major violation of the
Chrome and Firefox root program rules.  True, you would only discover that
violation after the fact – but that’s the same as if the CA marked the
intermediate as “usable for SSL” and then failed to subject it and EE certs
to CA’s audit regime.  In both cases, the browsers would find out about the
violation long after the fact.
>
>
>
> Given it’s a violation in both cases, and browsers will find out late in
both cases – what is the advantage in requiring the intermediates to be
marked?
>
>
>
> It seems the browsers have to come up with effective sanctions or other
measures against the non-complying CA in both cases…
>
>
>
> From: Ryan Sleevi [mailto:sleevi at google.com]
> Sent: Wednesday, November 05, 2014 9:38 AM
> To: Kirk Hall (RD-US)
> Cc: Gervase Markham; CABFPub
> Subject: Re: [cabfpub] (Eventually) requiring id-kpServerAuth for all
certs in the chain?
>
>
>
> Under the current audit requirements, a CA can issue an intermediate that
has full power and capability of issuing trusted TLS certs, and then
declare it out of scope of audit, because they don't "intend" for it to
issue TLS certs.
>
> This hand-wave does not require disclosure to auditors, nor to root
programs, and yet still provides the same risk profile as incidents such as
DigiNotar or India CCA.
>
> Gerv is proposing a technical means to express this intent, so that it is
clear to all parties the risk profile involved. Gerv's proposal is "opt-in"
- that is, by a certain timeframe, all CAs must reissue to conform to the
scheme, and anyone not conforming to the scheme is out of scope, and UAs
will be updated to require certs conform.
>
> My proposal is "opt out" - by declaring every certificate transitively
issued by a root to be in scope for the BRs, the burden is placed upon the
CA to use technical means to exclude their "non-TLS" intermediates from
being in scope. This is weaker in some ways (it lacks the hard enforcement
on the client side that Gerv proposes), but as both schemes rely on
auditors, I believe they represent the same effective risk profiles.
>
> On Nov 5, 2014 9:29 AM, "kirk_hall at trendmicro.com" <
kirk_hall at trendmicro.com> wrote:
>
> Gerv, I'm slow on this argument, but I'm trying to figure out why markers
in intermediates are important.
>
> Under the current scheme, it seems the trusted status of the root is
what's important, not the status of intermediates.  CAs must get WebTrust/
ETSI audits covering their operations from those roots to be trusted and
included in the browser root store.  The audits are supposed to cover all
(SSL) operations from that root.  Ultimately, it's a binary yes/no decision
on whether to keep the root in the root store based on audit results, plus
compliance with other root program requirements.  I suppose rogue
intermediates from the roots can also be explicitly untrusted by browsers
if needed.
>
> What are the objectives of the proposals to put markers (EKUs or OIDs) in
intermediates?  Is it not possible to meet those objectives using the
current system of trusted root / audit of all (SSL) operations from that
root?
>
> Just curious.
>
> -----Original Message-----
> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Gervase Markham
> Sent: Monday, November 03, 2014 11:46 AM
> To: CABFPub
> Subject: [cabfpub] (Eventually) requiring id-kpServerAuth for all certs
in the chain?
>
> Hi everyone,
>
> I wonder if the BRs should say that all non-root certs in a chain issued
for SSL server use, which were issued after <date>, should have EKU
id-kpServerAuth in them. Date would be, say, six months from now.
>
> This is primarily aimed at intermediates; EE certs all currently have
this anyway. It would mean that, over time (years) as intermediates got
replaced, we could eventually move to a position where it was entirely
clear what certs were intended for Web PKI SSL use and what certs were not.
>
> Currently, any intermediate in the world issued by a publicly-trusted
root can issue for SSL, even those intermediates which are not intended for
such use. This leads to numerous problems, including the question of
whether such intermediates need to be covered by a BR audit. Once this
change had filtered through, it would be clear - they would not be.
>
> AIUI, EKU "chaining" (i.e. requiring an EKU to be present all the way up
the chain) is not standard, but is implemented in NSS and elsewhere.
>
> I know this is a thing which only pays off in the long term, but I still
think it's worth it. Does this make any sense, or have I missed something
obvious? :-)
>
> Gerv
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
> <table class="TM_EMAIL_NOTICE"><tr><td><pre>
> TREND MICRO EMAIL NOTICE
> The information contained in this email and any attachments is
confidential
> and may be subject to copyright or other intellectual property protection.
> If you are not the intended recipient, you are not authorized to use or
> disclose this information, and we request that you notify us by reply
mail or
> telephone and delete the original message from your mail system.
> </pre></td></tr></table>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>
>
> TREND MICRO EMAIL NOTICE
>
> The information contained in this email and any attachments is
confidential
>
> and may be subject to copyright or other intellectual property
protection.
>
> If you are not the intended recipient, you are not authorized to use or
>
> disclose this information, and we request that you notify us by reply
mail or
>
> telephone and delete the original message from your mail system.
>
>
>
> TREND MICRO EMAIL NOTICE
> The information contained in this email and any attachments is
confidential
> and may be subject to copyright or other intellectual property
protection.
> If you are not the intended recipient, you are not authorized to use or
> disclose this information, and we request that you notify us by reply
mail or
> telephone and delete the original message from your mail system.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20141105/edfd8c1c/attachment-0003.html>