[cabfpub] Definition of an SSL certificate

Mon Jan 6 09:54:20 UTC 2014

On 1/3/2014 11:58 PM, Rob Stradling wrote:
> On 03/01/14 21:09, Moudrick M. Dadashov wrote:
>> On 1/3/2014 9:32 PM, Jeremy Rowley wrote:
>>>
>>> Sorry – I got the discussion a bit off-track. The issue is not whether
>>> domain names are vetted, but the fact that the BRs do not clearly
>>> define what certs are covered. There is a significant gray area on
>>> when certificates are exempt from the BRs.
>>>
>>> If requiring the BR/EV OID is not a possibility, I’d define the scope
>>> as any certificate that either (i) specifies a domain name in the CN
>>> field or subjectAltName extension and includes the anyEKU or
>>> serverAuth or omits an EKU or (ii) is intended to enable SSL/TLS, as
>>> evidenced by inclusion of the serverAuth EKU.
>>>
>> Once again, relying on BR/EV OID would be really good solution.
>>
>> Jeremy, to my understanding RFC 5280 accepts anyEKU only in combination
>> with any other EKU but not as the only EKU:
>>
>> “Certificates 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.
>
> But RFC5280 also says:
>   "Applications that require the presence of a
>    particular purpose MAY reject certificates that include the
>    anyExtendedKeyUsage OID but not the particular OID expected for the
>    application.
>
> That's MAY, not MUST.

Rob, that's right, but isn't about application behavior only?
The reference below explains when/why CA may need anyEKU and it says "CA 
can include...".
I may have missed something though..

Thanks,
M.D.
>
>> If a CA includes extended key usages to satisfy such applications, but
>> does not wish to restrict usages of the key, the CA can include the
>> special KeyPurposeId anyExtendedKeyUsage ***in addition to the
>> particular key purposes required by the applications***.
>>
>> So based on this:
>> SSL server: = SAN + serverAuth + [anyEKU+EKU]
>> SSL client:= [SAN] +clientAuth + [anyEKU+EKU]
>>
>> Thanks,
>> M.D.
>>
>>> Although the definition needs word smithing, it captures the
>>> certificates of primary concern (those containing domain names)
>>> without excluding internal server name certs. Thoughts?
>>>
>>> Jeremy
>>>
>>> *From:*Brown, Wendy (10421) [mailto:wendy.brown at protiviti.com]
>>> *Sent:* Friday, January 03, 2014 12:08 PM
>>> *To:* Jeremy Rowley; 'Mads Egil Henriksveen'; 'Moudrick M. Dadashov';
>>> public at cabforum.org
>>> *Subject:* RE: [cabfpub] Definition of an SSL certificate
>>>
>>> The requirement to verify is in the CP – the details of How goes in
>>> the CPS.
>>>
>>> *From:*Jeremy Rowley [mailto:jeremy.rowley at digicert.com]
>>> *Sent:* Friday, January 03, 2014 2:03 PM
>>> *To:* Brown, Wendy (10421); 'Mads Egil Henriksveen'; 'Moudrick M.
>>> Dadashov'; public at cabforum.org <mailto:public at cabforum.org>
>>> *Subject:* RE: [cabfpub] Definition of an SSL certificate
>>>
>>> Thanks Wendy for the clarification.  However, I didn’t see anything
>>> specifying how the CA is supposed to verify the domain.
>>>
>>> *From:*Brown, Wendy (10421) [mailto:wendy.brown at protiviti.com]
>>> *Sent:* Friday, January 03, 2014 11:55 AM
>>> *To:* Jeremy Rowley; 'Mads Egil Henriksveen'; 'Moudrick M. Dadashov';
>>> public at cabforum.org <mailto:public at cabforum.org>
>>> *Subject:* RE: [cabfpub] Definition of an SSL certificate
>>>
>>> The FBCA and Common Policy CPs actually require all information
>>> included in a certificate to be verified – so that would include any
>>> domain names, see 3.2.4.
>>>
>>> Thanks,
>>>
>>> Wendy
>>>
>>> Wendy Brown
>>>
>>> FPKIMA Technical Liaison
>>>
>>> Protiviti Government Services
>>>
>>> 703-299-4705 (office)    703-965-2990 (cell)
>>>
>>> wendy.brown at fpki.gov <mailto:wendy.brown at fpki.gov>
>>>
>>> wendy.brown at protiviti.com <mailto:wendy.brown at protiviti.com>
>>>
>>> *From:*public-bounces at cabforum.org
>>> <mailto:public-bounces at cabforum.org>
>>> [mailto:public-bounces at cabforum.org] *On Behalf Of *Jeremy Rowley
>>> *Sent:* Friday, January 03, 2014 11:19 AM
>>> *To:* 'Mads Egil Henriksveen'; 'Moudrick M. Dadashov';
>>> public at cabforum.org <mailto:public at cabforum.org>
>>> *Subject:* Re: [cabfpub] Definition of an SSL certificate
>>>
>>> Many of the trusted QC issuers (and other community issuers) are not
>>> involved in the CAB Forum.  Although you are aware of the
>>> requirements, I don’t think this knowledge is global. For example, I
>>> don’t think the NIST CP or FBCA CP ever mentions domain validation. A
>>> CA following either CP for client certs wouldn’t necessarily validate
>>> an included domain.
>>>
>>> Jeremy
>>>
>>> *From:*public-bounces at cabforum.org
>>> <mailto:public-bounces at cabforum.org>
>>> [mailto:public-bounces at cabforum.org] *On Behalf Of *Mads Egil 
>>> Henriksveen
>>> *Sent:* Friday, January 03, 2014 4:52 AM
>>> *To:* Moudrick M. Dadashov; Jeremy Rowley; public at cabforum.org
>>> <mailto:public at cabforum.org>
>>> *Subject:* Re: [cabfpub] Definition of an SSL certificate
>>>
>>> Hi Moudrick
>>>
>>> There might not be a real use case for including a domain name in a
>>> QC, but as a trusted CA we take the responsibility for the accuracy of
>>> information in all certs we issue. And that was my point and why I am
>>> not very concerned about the described attack scenario.
>>>
>>> Regards
>>>
>>> Mads
>>>
>>> *From:*public-bounces at cabforum.org
>>> <mailto:public-bounces at cabforum.org>
>>> [mailto:public-bounces at cabforum.org] *On Behalf Of *Moudrick M. 
>>> Dadashov
>>> *Sent:* 3. januar 2014 11:51
>>> *To:* Mads Egil Henriksveen; Jeremy Rowley; public at cabforum.org
>>> <mailto:public at cabforum.org>
>>> *Subject:* Re: [cabfpub] Definition of an SSL certificate
>>>
>>> Mads,
>>>
>>> On 1/3/2014 11:49 AM, Mads Egil Henriksveen wrote:
>>>
>>>     The attack scenario assumes that the QC can be chained to a root
>>>     cert in a trusted CA root store. This means that the CA should
>>>     know the root store requirements and should be aware of the risk
>>>     issuing any cert that could be used as an SSL certificate.
>>>
>>>     Buypass do issue both QC and SSL certificates and with the
>>>     DigiNotar attack back in 2011 we realized that the browsers do
>>>     accept a lot of certificates as SSL certificates. Since then we
>>>     have had strict controls to ensure that no certificate is issued
>>>     with an unverified domain name. I guess most of the trusted QC
>>>     issuers who also issue SSL certificates are aware of this, I would
>>>     not be very concerned about this attack scenario.
>>>
>>> What is the use case when in a QC we'd need a [any/unverified] domain
>>> name? (aren't CAs responsible for the accuracy of information in the
>>> QCs they issue?).
>>>
>>> However, I do support the idea of a technical definition of an SSL
>>> certificate and I like the proposal from Ryan Hurst requiring the
>>> BR/EV OIDs.
>>>
>>> Under ETSI framework compliance assumes two things: compliance with
>>> the corresponding requirements plus certificate profile compliance.
>>> These two categories exist as separate documents (under their own ETSI
>>> IDs).
>>> Ryan's proposal is definitely a  good step forward, I'd vote with my
>>> both hands if we go even further, and like ETSI, have separate BR/EV
>>> profile specifications.
>>>
>>> Thanks,
>>> M.D.
>>>
>>> NOTICE: Protiviti is a global consulting and internal audit firm
>>> composed of experts specializing in risk and advisory services.
>>> Protiviti is not licensed or registered as a public accounting firm
>>> and does not issue opinions on financial statements or offer
>>> attestation services.
>>>
>>> This electronic mail message is intended exclusively for the
>>> individual or entity to which it is addressed. This message, together
>>> with any attachment, may contain confidential and privileged
>>> information. Any views, opinions or conclusions expressed in this
>>> message are those of the individual sender and do not necessarily
>>> reflect the views of Protiviti Inc. or its affiliates. Any
>>> unauthorized review, use, printing, copying, retention, disclosure or
>>> distribution is strictly prohibited. If you have received this message
>>> in error, please immediately advise the sender by reply email message
>>> to the sender and delete all copies of this message. Thank you.
>>>
>>>
>>
>>
>>
>> _______________________________________________
>> Public mailing list
>> Public at cabforum.org
>> https://cabforum.org/mailman/listinfo/public
>>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3663 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.cabforum.org/pipermail/public/attachments/20140106/70ff7565/attachment-0001.p7s>