[cabfpub] Ballot 108: Clarifying the scope of the baseline requirements
Moudrick M. Dadashov
md at ssc.lt
Thu Aug 1 17:39:14 UTC 2013
Jeremy,
1. ETSI TS 101 862 V1.3.3 (2006-01) Qualified Certificate profile
2. ETSI EN 319 412-5 V1.1.1 (2013-01) Electronic Signatures and
Infrastructures (ESI); Profiles for Trust Service Providers issuing
certificates; Part 5: Extension for Qualified Certificate profile
also have a look:
ETSI TS 119 412-2 V1.1.1 (2012-04) Electronic Signatures and
Infrastructures (ESI); Profiles for Trust Service Providers issuing
certificates; Part 2: Certificate Profile for certificates issued to
natural persons.
Search and download here:
http://pda.etsi.org/pda/queryform.asp
need to register, its free.
Thanks.
M.D.
On 8/1/2013 7:18 PM, Jeremy Rowley wrote:
>
> Do you have a link for the profile? None of the qualified cert
> profile recommendations or requirements I am aware of require the
> anyEKU or omission of the EKU. They all say EKUS MUST be set in
> accordance with 5280.
>
> Jeremy
>
> *From:*public-bounces at cabforum.org
> [mailto:public-bounces at cabforum.org] *On Behalf Of *Moudrick M. Dadashov
> *Sent:* Thursday, August 01, 2013 9:25 AM
> *To:* Ryan Hurst
> *Cc:* 'CABFPub'
> *Subject:* Re: [cabfpub] Ballot 108: Clarifying the scope of the
> baseline requirements
>
> 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>
> [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
> <mailto: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 <mailto:Public at cabforum.org>
>
> https://cabforum.org/mailman/listinfo/public
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20130801/3b35c876/attachment-0003.html>
More information about the Public
mailing list