[cabfpub] Ballot 108: Clarifying the scope of the baseline requirements

Ryan Sleevi sleevi at google.com
Thu Aug 1 17:48:13 UTC 2013


On Thu, Aug 1, 2013 at 2:04 AM, Rijt, R.A. van de (Robert) - Logius
<robert.vande.rijt at logius.nl> wrote:
> Although I understand the need for tightening the definition and I can
> follow the reasoning below to a certain point I feel that, instead of
> tightening it, the new definition seems to have broadened the scope. The
> vast majority of certificates issued under the Logius PKIoverheid root are
> not intended for the identification of SSL servers. However, roughly 90% of
> these certificates will now fall under this new definition. In the present
> version, the scope made clear that the BR only addressed certificates meant
> for servers.

Robert,

For what it's worth, the goal here would be to ensure that
certificates that are *technically capable* of being used for server
certificates are seen as in-scope, regardless of whether or not they
are *intended* to be used as such.

Intent is all well and good, and I'd like to think that CAs both
inside and outside the CA/B Forum are operating in good faith in that
regard, but if a root program member/publicly trusted CA is issuing
certificates that can be used for servers, then whether or not the
'intent' is there, it represents a concern and possible threat to the
overall system.

The definition provided matches the implementation of a wide-variety
of existing client libraries - including those of a number of root
store members in this group - and thus represents the reality of risk
that such certs may pose. I think the goal should be to either have
the CA change practices such that certificates that they do not intend
to be used as server certificates are technically prevented from being
used as such (eg: EKU restrictions) or - if this ballot proceeds and
is voted in - working with program members and auditors to establish
that such roots/intermediates/leafs are out of scope of the BRs
through some other means (eg: having the root store override the
acceptable EKUs).

I'm not really fond of the latter solution at all, given the wide
variety of client libraries that exist out there that may be
attempting to use existing root stores (eg: Mozilla's), and thus would
be at risk if they did not implement the same non-standard measures,
but at the end of the day, that's the responsibility of those client
libraries, not the root or the root program.

Cheers,
Ryan

>
>
>
> What about personal certificates on a SSCD that have no EKU or have an
> anyExtendedKeyUsage as a safetynet? Would these certificates suddenly by
> seen as SSL certificates although they are obviously not intended for
> servers? What about certificates issued to autonomous devices such as
> onboard computers in taxicabs or domestic gas meters, to name but two? Would
> these be considered SSL certificates if they have no EKU or the clientauth
> EKU in combination with anyExtendedKeyUsage?
>
>
>
> Regards,
>
> Robert
>
>
>
>
>
>
>
>
>
> Van: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] Namens
> Ryan Sleevi
> Verzonden: maandag 29 juli 2013 22:57
> Aan: Kelvin Yiu
> CC: CABFPub
> Onderwerp: Re: [cabfpub] Ballot 108: Clarifying the scope of the baseline
> requirements
>
>
>
> They're still respected (for better or worse) by Apple, NSS, and Android.
>
> Even if that changed tomorrow, the fact that a significant portion of the
> deployed user base for those products may not upgrade immediately suggests
> it would be wise to keep them in scope - especially given that even few
> products implement Microsoft's EKU chaining behaviour for intermediates.
>
> On Jul 29, 2013 1:52 PM, "Kelvin Yiu" <kelviny at exchange.microsoft.com>
> wrote:
>
> I prefer to drop any mention of the MS or Netscape SGC OIDs. These OIDs have
> been obsolete for over a decade and have ceased to have any meaning on MS
> platforms since Windows 2000.
>
> Kelvin
>
> -----Original Message-----
> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
> Behalf Of Ryan Sleevi
> Sent: Friday, July 26, 2013 12:35 PM
> To: jeremy rowley
> Cc: CABFPub
> Subject: Re: [cabfpub] Ballot 108: Clarifying the scope of the baseline
> requirements
>
> Jeremy,
>
> If I might suggest a slight modification to the wording, which still leaves
> things a little ambiguous. "All root and intermediate certificates included
> in a browser's trust store" - AIUI, none of the browsers are really
> accepting intermediates to the trust store at this point.
>
> This was a sticky point when working on Mozilla's wording on this policy to.
> Luckily, the terminology for "Root CA" and "Subordinate CA"
> may be sufficient here to help clarify.
>
> "All root certificates included in a browser's trust store, all subordinate
> CA certificates signed by one of these root certificates, and all end-entity
> certificates that either lack any Extended Key Usage extension or contain an
> Extended Key Usage extension that contains one of the following:
> - Server Authentication (1.3.6.1.5.5.7.3.1)
> - anyExtendedKeyUsage (2.5.29.37.0)
> - Netscape Server Gated Cryptography (2.16.840.1.113730.4.1)
> - Microsoft Server Gated Cryptography (1.3.6.1.4.1.311.10.3.3) are expressly
> covered by these requirements."
>
> Note that Appendix B, 3.F lists other values as SHOULD NOT. However, that
> presumably only applies when a certificate is 'in scope' of the BRs, hence
> the restatement of potential EKUs that are relevant.
>
>
>
> On Fri, Jul 26, 2013 at 12:22 PM, Jeremy Rowley <jeremy.rowley at digicert.com>
> wrote:
>> Hi everyone,
>>
>>
>>
>> As mentioned on the phone call last week, CAs have claimed exemption
>> from the BRs because the definition of a publicly-trusted SSL certificate
>> is not
>> clear.   I would like to clarify the scope of the BRs to avoid confusion
>> on
>> what particular certificate contents are necessary to require
>> compliance.  I am looking for on endorser (Stephen Davidson has already
>> endorsed).
>>
>>
>>
>> The third paragraph of Section 1 of the baseline requirements is:
>>
>> "This version of the Requirements only addresses Certificates intended
>> to be used for authenticating servers  accessible through the
>> Internet. Similar requirements for code signing, S/MIME,
>> time-stamping, VoIP, IM, Web services, etc. may be covered in future
>> versions."
>>
>>
>>
>> I'd like to replace the above text with the following:
>>
>> "This version of the Baseline Requirements addresses all root,
>> intermediate, and end entity certificates that can be used in
>> publicly-trusted SSL handshakes.  All root and intermediate
>> certificates included in a browser's trust store and all end entity
>> certificates containing an extended key usage extension of Server
>> Authentication (1.3.6.1.5.5.7.3.1) are expressly covered by these
>> requirements. Similar requirements for code signing, S/MIME,
>> time-stamping, VoIP, IM, Web services, etc. may be covered in future
>> versions."
>>
>>
>>
>> I look forward to your comments.
>>
>>
>>
>> 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
>
>
> ________________________________
>
> Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u
> niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden,
> wordt u verzocht dat aan de afzender te melden en het bericht te
> verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van
> welke aard ook, die verband houdt met risico's verbonden aan het
> elektronisch verzenden van berichten.
> This message may contain information that is not intended for you. If you
> are not the addressee or if this message was sent to you by mistake, you are
> requested to inform the sender and delete the message. The State accepts no
> liability for damage of any kind resulting from the risks inherent in the
> electronic transmission of messages. .
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>



More information about the Public mailing list