[cabfpub] Definition of an SSL certificate

Fri Dec 20 13:24:17 MST 2013

Ryan,

I absolutely agree, and this was more or less the conclusion we reached
several months ago.

As I mentioned on our most recent telecon, the BRs SHOULD cover any and all
certificates that are technically capable of being used as SSL/TLS
certificates. Our examination of what that meant to different root stores /
browsers (which, as I understand, has been summarized on the members-only
wiki) basically showed that today, this is a very liberal set.

The other big concern is that the BRs do not just cover end-entity
certificates, but also set forth policies for intermediate certificates as
well. By measuring "BR-applicable" by simply examining the leaf
certificate, we create a hole that may be exploited for security-sensitive
purposes, intentionally or not. It's not merely sufficient to determine
whether a leaf certificate is BR applicable, but also to examine whether an
intermediate certificate is BR-applicable.

This is why I advocate that only Roots whose entire hierarchy is conformant
and audited to the BRs - that is, every leaf and every intermediate issued
from that Root - should be entered into Root Programs. CAs can still have
roots that cross-sign these "BR-only Roots", but it would seem
best/unambiguous for all parties to declare the entire hierarchy from a
given root (potentially cross-signed) and below as being in-scope of the
BRs.

On Fri, Dec 20, 2013 at 12:17 PM, Ryan Hurst <ryan.hurst at globalsign.com>wrote:

> Jeremy,
>
> The proposal seems to be to re-write the definition to represent the
> intent of the issuer (I only expected this to ever be used in this way) vs
> what the technical capability of the certificate that they have issued.
>
> In my opinion the problem with this approach is that whats material is not
> what the intent of the action was but what the result of it is. Basically
> any certificate that is technically capable of being used as a publicly
> trusted SSL certificate IS a publicly trusted SSL certificate even if that
> was not the intent.
>
> If the group decides to go this way I think that browsers should change
> what they require of SSL certificates so that only those that match this
> intent can be technically used.
>
> This of course is quite difficult since the group has refused to mandate
> certificate policies map to the common CABF OIDs for the corresponding
> policies but  not addressing this seems to expose the internet to risk.
>
> Thoughts?
>
> Ryan
>
>
>
> On Thu, Dec 19, 2013 at 8:05 AM, Jeremy Rowley <jeremy.rowley at digicert.com
> > wrote:
>
>> We are looking to clarify the scope of the BRs.  Right now the BR scope
>> is very loose and subjective: “This version of the Requirements only
>> addresses Certificates intended to be used for authenticating servers
>>  accessible through the Internet.”
>>
>>
>>
>> This loose definition excludes internal names (which are not typically
>> accessible through the Internet), a type of certificate the BRs are clearly
>> designed to regulate (see 11.1.4).  In addition, a CA could easily issue a
>> certificate outside of the BRs  that could later be used in a TLS/SSL
>> attack simply because the certificate wasn’t intended to be used for SSL.
>>
>>
>>
>> Issuance of certificates outside the BRs may not be intentional,
>> especially by CAs who aren’t regularly issuing SSL certificates.  These CAs
>> may not be aware that the BRs apply to their certificates and may not
>> realize their client certificates could be used for SSL since
>> “authenticating servers” is not a well-defined term.
>>
>>
>>
>> Clarifying the scope will ensure that every CA is aware of the minimum
>> standards and what they cover.  Originally, the idea was to tie the scope
>> to the values in the EKU.  Unfortunately, there are several obstacles to
>> this approach:
>>
>> 1)      Grid Certificates require serverAuth in the EKU.  It’s unclear
>> whether these certs should be covered.
>>
>> 2)      Per 5280, browsers treat the absence of an EKU and the anyEKU as
>> serverAuth, meaning they are enabled for TLS Server Authentication.
>>
>> 3)      The FBCA requires anyEKU in several certificates.  These are
>> clearly client certificates and are outside the BR scope.
>>
>> 4)      Qualified certificates in the EU have either the anyEKU present
>> or omit the EKU.  They are client certs and clearly not covered by the
>> BRs.  However, they can be used  for server authentication.
>>
>>
>>
>> For qualified certificates, Moudrick provided the following guidance:
>>
>> “Certificates using applications MAY require that the extended key usage
>> extension be present and that a particular purpose be indicated in order
>> for the certificate to be acceptable to that application.
>>
>>
>>
>> If a CA includes extended key usages to satisfy such applications, but
>> does not wish to restrict usages of the key, the CA can include the special
>> KeyPurposeId anyExtendedKeyUsage ***in addition to the particular key
>> purposes required by the applications***.
>>
>>
>>
>> So a QC pretending to be RFC 5280/BR and ETSI (web server QCs) compliant
>> would have to at least have:
>>
>>
>>
>> QC + [anyEKU] + id-kp-serverAuth + {DV/OV/EV}
>>
>>
>>
>> I'm quite confident that the absolute majority of QCs issued so far (that
>> have anyEKU, see Mark Janssen's 08/08/2013 - thank you Stephen) do not
>> contain any DV/OV/EV policy IDs, so why not accept them as BR compliant but
>> not sufficient for TSL/SSL establishment?
>>
>>
>>
>> In order for a QC to have a TSL/SSL capability, BR may require:
>>
>>
>>
>> QC + {{id-kp-serverAuth and/or id-kp-clientAuth} + {DV/OV/EV}}
>> (optionally no anyKEY allowed).
>>
>>
>>
>> A practical interpretation: a WEB server that also does some web site
>> related document/content signing.”
>>
>>
>>
>> There appears to be a significant conflict between the CAB Forum’s work
>> and the standards set by other bodies.  In particular, their use of the
>> anyEKU or omission of an EKU is permitting the realm of client certs to
>> overlap SSL certs.  Approaching each government body to stop this practice
>> is not feasible and will take a very long time to complete
>>
>>
>>
>> Hopefully this summary helps inspire ideas on where we can go from here.
>> I’m looking forward to ideas.
>>
>>
>>
>> Thanks!
>>
>>
>>
>> Jeremy
>>
>>
>>
>>
>>
>> _______________________________________________
>> Public mailing list
>> Public at cabforum.org
>> https://cabforum.org/mailman/listinfo/public
>>
>>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20131220/2d129646/attachment-0001.html 