[cabfpub] FW: [cabfman] BR effective date

Moudrick M. Dadashov md at ssc.lt
Fri Dec 20 16:37:31 UTC 2013

What is confusing here the term QC that has different meanings: 1. A profile defined in RFC 3739. 2. A legal category of: Policy requirements + predefined profile specification (jurisdiction/CA specs) + TSL.

Erwann has already noticed this, no contradiction in my interpretation if you take this into account. Simply speaking, I don't see how reliably you can discover/recognize ETSI QSs without looking at TSL, for a technical QC (RFC) this can be done just by looking at the content of the certificate under consideration.


Jeremy Rowley <jeremy.rowley at digicert.com> wrote:

>Thanks Erwann - I've moved this to the public mailing list. Replies are
>in-line and marked with [JR].	
>>If a certificate happens to have BasicConstraints:CA=true, then it's a CA
>cert, period.
>[JR] No dispute here.
>>If a certificate has a serverAuth EKU, then it's a TLS server cert. With
>compliant content, it's also an EV certificate.
>[JR] serverAuth is the easy case, although someone may disagree since
>community device certs require this EKU.  The hard case is anyEKU or where
>the EKU is omitted.
>>If a certificate follows QC profile, then it's a QC certificate.
>[JR] But QC does not preclude a server cert.
>>If nothing forbids combinations, a certificate could be QC+EV+CA. And of
>course subject to subsequent constraints/rules.
>[JR] The problem is anyEKU or omitted EKUs.  In that case it could be a
>server Cert.  From what I understand, QCs do not contain a domain name in
>the CN (they have the name of the individual).  Therefore, they are not BR
>compliant, despite the face they can be used for server authentication.
>Public mailing list
>Public at cabforum.org

More information about the Public mailing list