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

Jeremy Rowley jeremy.rowley at digicert.com
Thu Aug 1 13:52:45 MST 2013


Thanks Moudrick.  

 

None of those documents require a certificate to include the anyEKU or no
EKU.  Is there any software that actually requires the anyEKU or no EKU or
is this just something that has happened over time with CAs?  If there isn't
an actual reason to put this in Qualified certs (other than CAs have
included it in the past) then there isn't a conflict, and we can move
forward with the ballot.  Issuers of qualified certs will just need to start
inserting the correct EKUs.  The problem (and related danger) is real enough
that certs with anyEKU or no EKU should be covered by the BRs.

 

Jeremy

 

From: Moudrick M. Dadashov [mailto:md at ssc.lt] 
Sent: Thursday, August 01, 2013 11:39 AM
To: jeremy.rowley at digicert.com
Cc: 'Ryan Hurst'; 'CABFPub'
Subject: Re: [cabfpub] Ballot 108: Clarifying the scope of the baseline
requirements

 

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] 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 keyAgreement bits 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] 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> 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
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
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

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>
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] 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] 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

 

  _____  


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
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/895e16ac/attachment-0001.html 


More information about the Public mailing list