[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