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

Moudrick M. Dadashov md at ssc.lt
Thu Aug 1 08:25:18 MST 2013


I see potential problem for ETSI Qualified SSL certificates, if key 
usage requirements remain mandatory as it is now with the Qualified el. 
signature certs.

Thanks,
M.D.

On 8/1/2013 5:28 PM, Ryan Hurst wrote:
>
> There is nothing in the RFC that requires applications to treat the 
> presence of the EKU as mandatory:
>
>    Certificate 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.
>
> In fact the processing semantics defined in the RFC result in the 
> behavior you see in all browsers today. That is if extended key usage 
> is present the certificate is good for all usages, that if any key 
> usage is present the certificate is only good for the specified usages.
>
>    If the extension is present, then the certificate MUST only be used
>
>    for one of the purposes indicated.  If multiple purposes are
>
>    indicated the application need not recognize all purposes indicated,
>
>    as long as the intended purpose is present.
>
> While this behavior does require CAs to be mindful of what 
> applications require to understand the implications of their 
> certificate profiles it is both standards compliant and the way things 
> have been since the introduction of this extension.
>
> As for key usage; most libraries (certainly CryptoAPI) don't pay 
> attention to the key usage extension; that is with the exception of 
> keyCertSign. Additionally its perfectly legitimate for an application 
> to ignore the Key Usage field:
>
>    This extension indicates one or more purposes for which the certified
>
>    public key may be used, in addition to or in place of the basic
>
>    purposes indicated in the key usage extension.
>
> And the specification of the EKU of server authentication includes a 
> set of specific KUs that are consistent with the extension:
>
>    id-kp-serverAuth        OBJECT IDENTIFIER ::= { id-kp 1 }
>
>    -- TLS WWW server authentication
>
>    -- Key usage bits that may be consistent: digitalSignature,
>
>    -- keyEncipherment or keyAgreement
>
> Given these facts I do not think it makes sense to include KU as part 
> of the definition of scope.
>
> Ryan
>
> *From:*public-bounces at cabforum.org 
> [mailto:public-bounces at cabforum.org] *On Behalf Of *Rijt, R.A. van de 
> (Robert) - Logius
> *Sent:* Thursday, August 01, 2013 5:09 PM
> *To:* jeremy.rowley at digicert.com; 'Steve Roylance'
> *Cc:* 'CABFPub'
> *Subject:* Re: [cabfpub] Ballot 108: Clarifying the scope of the 
> baseline requirements
>
> Ideally, only certificates that explicitly contain an EKU with 
> serverauth would be considered SSL certs. All other certs should be 
> dismissed. That would be in line with the RFC, but I realize this 
> proposal might even be more impractical.
>
> I would suggest though to add to the current definition that only 
> certificates that contain a KeyUsage with the digitalsignature and 
> keyEncipherment and / or keyAgreementbits set, would be considered SSL 
> certificates.  It just does not make sense to mandate that a personal 
> certificate on a SSCD with KeyUsage non-repudation and no EKU would be 
> considered an SSL certificate. That is not how I have interpreted RFC 
> 5280.
>
> If the proposed definition is accepted all certificates with noEKU or 
> anyEKU bits set will be governed by the BR. That means that all client 
> certificates with those bits set, SSL or otherwise, will be governed 
> by the rules of the BR. This in turn means that a client certificate 
> must contain a FQDN, which it obviously cannot. In my view, adopting 
> the proposed definition would lead to a situation where no client 
> certificates can be issued under the roots present in the root 
> programs, unless the burden of change is placed on those CAs issuing 
> client certificates, forcing them to add keyusage bits to their 
> certificates that are not compulsory through the RFCs. Furthermore, in 
> many cases the anyEKU is relied on by software using client certificates.
>
> Regards,
>
> Robert
>
> *Van:*Jeremy Rowley [mailto:jeremy.rowley at digicert.com]
> *Verzonden:* donderdag 1 augustus 2013 14:06
> *Aan:* 'Steve Roylance'; Rijt, R.A. van de (Robert) - Logius
> *CC:* 'CABFPub'
> *Onderwerp:* RE: [cabfpub] Ballot 108: Clarifying the scope of the 
> baseline requirements
>
> That is likely the way forward.  Mozilla can enable roots for "Web, 
> code, or client" .  I assume the other browsers probably have a 
> similar designation. If the root is disabled for "web" then the cert 
> could not perform SSL and would not be considered enabled in the 
> browser's trust store (for SSL/TLS).  The tweak to the proposed 
> language would be nominal.
>
> *From:*public-bounces at cabforum.org 
> <mailto:public-bounces at cabforum.org> 
> [mailto:public-bounces at cabforum.org] *On Behalf Of *Steve Roylance
> *Sent:* Thursday, August 01, 2013 5:25 AM
> *To:* Rijt, R.A. van de (Robert) - Logius
> *Cc:* CABFPub
> *Subject:* Re: [cabfpub] Ballot 108: Clarifying the scope of the 
> baseline requirements
>
> Hi Robert.
>
> Root program's have the ability to mark specific roots for specific 
> uses therefore  you can still offer public trust but for a specific 
> need. Maybe that's a way forward? As with Name Constraints it makes 
> roots (or Subordinate CAs) less attractive as targets as their value 
> to an attacker is decreased.
>
> Regards Steve
>
>
> Sent from my iPhone
>
>
> On 1 Aug 2013, at 12:04, "Rijt, R.A. van de (Robert) - Logius" 
> <robert.vande.rijt at logius.nl <mailto:robert.vande.rijt at logius.nl>> wrote:
>
>     For qualified certificates under ETSI that need to be publicly
>     trusted, a private root would not be an option. Moreover,
>     developing a private, not-publicly trusted root and rolling out
>     end-entity certificates takes time. I am talking about a year at
>     least.
>
>     I wonder if everyone else is realizing the impact on "non-SSL"
>     certificates. Especially the CA's not participating in the
>     CABforum because they do not issue SSL certs (or thought they did
>     not), but do have a publicly trusted root.
>
>     Robert
>
>     *Van:*Jeremy Rowley [mailto:jeremy.rowley at digicert.com]
>     *Verzonden:* donderdag 1 augustus 2013 12:56
>     *Aan:* Rijt, R.A. van de (Robert) - Logius; 'Ryan Hurst'
>     *CC:* 'CABFPub'
>     *Onderwerp:* RE: [cabfpub] Ballot 108: Clarifying the scope of the
>     baseline requirements
>
>     Which is why you will now have to issue these off a root not
>     trusted by a participating browser. The safetynet is the problem
>     since makes them an SSL cert.  I don't think you can both have a
>     safetynet like this and issue the cert from a trusted root.
>
>     Jeremy
>
>     *From:*Rijt, R.A. van de (Robert) - Logius
>     [mailto:robert.vande.rijt at logius.nl]
>     *Sent:* Thursday, August 01, 2013 4:53 AM
>     *To:* Ryan Hurst; jeremy.rowley at digicert.com
>     <mailto:jeremy.rowley at digicert.com>
>     *Cc:* CABFPub
>     *Subject:* RE: [cabfpub] Ballot 108: Clarifying the scope of the
>     baseline requirements
>
>     Thanks for your reply, Jeremy. I conclude that with this new
>     definition:
>
>     1. We are forcing everyone with public certificates to use the EKU;
>
>     2. We are forcing everyone with public certificates not to use the
>     anyExtendedKeyUsage unless it is a SSL certificate;
>
>     3. thereby forcing everyone to spell out all the applicable EKUs
>     one--by-one. My experience is that a lot of software cannot handle
>     this,so the certificate cannot be used for the function intended.
>     That is why the anyExtendedKeyUsage is often used as a safetynet.
>
>     Robert
>
>     *Van:*Ryan Hurst [mailto:ryan.hurst at globalsign.com]
>     *Verzonden:* donderdag 1 augustus 2013 12:45
>     *Aan:* jeremy.rowley at digicert.com <mailto:jeremy.rowley at digicert.com>
>     *CC:* Rijt, R.A. van de (Robert) - Logius; CABFPub
>     *Onderwerp:* Re: [cabfpub] Ballot 108: Clarifying the scope of the
>     baseline requirements
>
>     I concur with Jeremy's analysis.
>
>     Ryan Hurst
>
>     Chief Technology Officer
>
>     GMO Globalsign
>
>     twitter: @rmhrisk
>
>     email: ryan.hurst at globalsign.com <mailto:ryan.hurst at globalsign.com>
>
>     phone: 206-650-7926
>
>     Sent from my phone, please forgive the brevity.
>
>
>     On Aug 1, 2013, at 1:12 PM, "Jeremy Rowley"
>     <jeremy.rowley at digicert.com <mailto:jeremy.rowley at digicert.com>>
>     wrote:
>
>         HI Rijt,
>
>         I think the certificates you mentioned will (and should)
>         qualify under the BRs if are issued from a root that is
>         included in one of the adopting browser's trust stores.
>
>         Here's my logic:
>
>         1)Certs that don't have an EKU or that include the anyEKU can
>         be used as SSL certs, regardless of their intended purposes
>         and should (arguably) be under the BRs.
>
>         2)However, as you mentioned, many certificates assert the
>         anyEKU, have noEKU, or even contain the server authentication
>         EKU that are never intended to be used on a server.
>
>         3)I believe the certificates referenced typically lack an
>         FQDN. Including these certificates under the BR umbrella is
>         problematic because the certificates can't function in the
>         intended manner and comply with the BRs.  The CN is an
>         identifier for the equipment, which violates Section 9.2.2 of
>         the BRs.
>
>         4)Requiring an FQDN for inclusion in the BRs is not a way
>         forward since that would make the sections on internal server
>         names out of scope of the BRs. In fact, the identifier in
>         these certificates is indistinguishable from and qualifies as
>         an internal name, meaning the certificate presents all of the
>         concerns previously expressed by PayPal.   Continuing to trust
>         these certificates would be the same as not deprecating
>         internal server name certificates
>
>         5)Therefore, these certificates must either be included in the
>         BRs, and include an FQDN, or need to be issued off of a
>         non-publicly trusted root certificate.
>
>         The position you expressed is why I wanted to raise the issue
>         and why I think we need to resolve what the BRs actually cover.
>
>         Jeremy
>
>         *From:*public-bounces at cabforum.org
>         <mailto:public-bounces at cabforum.org>
>         [mailto:public-bounces at cabforum.org] *On Behalf Of *Rijt, R.A.
>         van de (Robert) - Logius
>         *Sent:* Thursday, August 01, 2013 3:05 AM
>         *To:* 'CABFPub'
>         *Subject:* Re: [cabfpub] Ballot 108: Clarifying the scope of
>         the baseline requirements
>
>         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.
>
>         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>
>         [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
>         <mailto: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>
>         [mailto: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
>         <mailto: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 <mailto:Public at cabforum.org>
>         > https://cabforum.org/mailman/listinfo/public
>         >
>         _______________________________________________
>         Public mailing list
>         Public at cabforum.org <mailto: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 <mailto: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. .
>
>     ------------------------------------------------------------------------
>
>
>     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 <mailto: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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20130801/9be3402d/attachment-0001.html 


More information about the Public mailing list