[cabfpub] Definition of an SSL certificate
Moudrick M. Dadashov
md at ssc.lt
Fri Jan 3 14:09:17 MST 2014
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.
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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20140103/73778e3e/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3663 bytes
Desc: S/MIME Cryptographic Signature
Url : https://cabforum.org/pipermail/public/attachments/20140103/73778e3e/attachment-0001.bin
More information about the Public
mailing list