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

Janssen, M.A. (Mark) - Logius mark.janssen at logius.nl
Thu Aug 8 00:07:08 MST 2013


Hi All,

We have done some quick research into personal certificates, both qualified and non-qualified, that have been issued in the EU. Millions of these certificates have been issued, with a validity of at least 5 years. For non-qualified, public key certificates (in line with EN 319 411-3) the validity period could be even longer. A lot if not most of these certificates lack an EKU which seems to be the de facto standard approach.

I have no idea how the CPs and certificate profiles look from governments / CAs outside the EU that are publicly trusted and issue personal certificates. Again, there must be millions of these certificates around without an EKU or anyExtendedKeyUsage.

It looks to me this is not only a technical issue but certainly also a political one. In the CABforum we used to set rules for ourselves. Now we are setting rules for the rest of the PKI world that are ignorant of the BR. We are likely to be talking about tens of millions of certificates worldwide with unknown validity periods that would suddenly be in scope of the BR.

We underline the need for a clear definition, but it seems to us the evolved scope definition is not the way to go. The following reasoning could possibly help us out. The BR state that certificates MUST contain an EKU server or client authentication. So, if a certificate does not contain these EKUs, it is not compliant with the BR. According to the RFC 5280, certificate using applications, in this case browsers, are entitled to state that they explicitly need the EKU server authentication to be present for setting up an SSL connection. If an end-entity certificate does contain the EKU server authentication and is publicly trusted, it will have to be compliant with all requirements of the Baseline. Therefore, I would like to suggest an alternative definition for SSL certs in the BR:

"This version of the Baseline Requirements addresses the hierarchy of all end entity certificates that contain an extended key usage extension of Server Authentication (1.3.6.1.5.5.7.3.1) and are issued under a root CA that is publicly trusted by browsers.
Similar requirements for code signing, S/MIME, time-stamping, VoIP, IM, Web services, etc. may be covered in future versions."

This comes very close to Jeremy Rowley's original proposal:

"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."

Browsers should explicitly state in their root programs that only end entity certificates containing an extended key usage extension of Server Authentication (1.3.6.1.5.5.7.3.1) will be allowed to set up an SSL connection.
Theoretically, we would have a legacy period of about 2 years in which we have to decide whether we want to hard fail or soft fail on certificates without the EKU server authentication present. We have to decide what we do within these two legacy years and / or after these two years.

Thanks.

Best Regards,

Mark Janssen
Policy Authority PKIoverheid
........................................................................
Logius
The ministry of the Interior and Kingdom Relations (BZK)
Wilhelmina van Pruisenweg 52 | 2595 AN | The Hague
P.O. Box 96810 | 2509 JE | The Hague
........................................................................
T +31(0) 6 21162365
F +31(0) 70 8887 882
mark.janssen at logius.nl
http://www.logius.nl/
........................................................................
Service e-government
........................................................................
Please consider the environment - do you really need to print this mail?



-----Oorspronkelijk bericht-----
Van: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] Namens Moudrick M. Dadashov
Verzonden: zaterdag 3 augustus 2013 2:48
Aan: Ryan Sleevi
CC: CABFPub
Onderwerp: Re: [cabfpub] Ballot 108: Clarifying the scope of the baseline requirements

Thanks, Ryan, your arguments sound quite reasonable.

But, like my other European colleagues have pointed out, the problem is not how important the proposal is, the  real problem is in finding proper place for BRs within the ETSI framework where policy requirements have been defined in terms of reference certificate policy groups from which CAs can produce policies targeted at particular services.

The BRs, at least in their declared scope,  are similar to the EU standard "Policy requirements for CAs issuing public key certificates (ETSI EN 319 411-3 V1.1.1), which is derived from the requirements specified in TS 102 042 "Policy requirements for CAs issuing public key certificates" (excluding the requirements related  to SSL certificates, previously also covered by single standard - TS 102 042).

So, the question becomes not rhetoric if you start thinking about auditing. I think we should move in the direction of harmonization where the terminology we use and policy requirements can be relatively easily mapped to each other. I'm quite doubtful if we can achieve this just by "fine tuning" applicable scope of BRs.

We definitely need more time to see the consequences.

Thanks,
M.D.




On 8/2/2013 3:46 AM, Ryan Sleevi wrote:
> Moudrick,
>
> The importance of clarifying that the intermediates are in scope is
> that such intermediates are capable of issuing any kind of certificate
> (including server certificates), so it's important to consider them in
> scope.
>
> The comment about permitting EKUs in intermediate certificates - and
> their value - has been discussed in the context of Ballot 105. The
> short answer is that several client libraries *further* restrict the
> acceptable EKUs based on the transitive EKUs of the certificate chain
> it appears in.
>
> That is, if a subordinate CA certificate *has* an EKU extension, and
> it lacks the aforementioned EKUs, then any certificates issued by that
> CA will *not* be accepted for server auth - regardless of what EKUs
> the leaf says. That is, treating EKUs in intermediates as "eku
> constraints", for lack of a better term.
>
> While this may be seen as controversial to "PKIX purists", it's been
> deployed for over a decade, and offers a reasonable path for scoping
> subordinate CAs. Note that RFC 5280 does not *prevent* this extension
> from appearing in the intermediates, so such behaviour SHOULD be
> acceptable to other software that does not implement this check (eg:
> non-browser users of root stores)
>
> Hopefully that clears things up.
>
> Cheers,
> Ryan
>
> On Thu, Aug 1, 2013 at 3:56 PM, Moudrick M. Dadashov <md at ssc.lt> wrote:
>> Jeremy, my comment was about Key Usage not EKU, sorry for the confuse..
>>
>> If the proposed change requires EKU for non EE certificates, then
>> there is one more issue:
>>
>> RFC 5280:
>> 4.2.1.12. Extended Key Usage
>>
>>     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.  In general, this
>>     extension will appear only in end entity certificates.
>>
>>
>> Thanks,
>> M.D.
>>
>>
>> On 8/1/2013 11:52 PM, Jeremy Rowley wrote:
>>
>> 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
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> 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. .


More information about the Public mailing list