[cabfpub] FW: [cabfman] BR effective date
Moudrick M. Dadashov
md at ssc.lt
Fri Dec 20 09:37:31 MST 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.
M.D.
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
>https://cabforum.org/mailman/listinfo/public
More information about the Public
mailing list