[cabf_validation] Enterprise RA and EV CRL Checking

[Corey Bonnell]

Hi Bruce,

Thanks for raising these points; these are areas that we should consider
improving. Comments inline.

 

> As I assume that the CAs use the Enterprise RA to perform the same
function, can we consolidate the definition and only include the definition
in the BRs?

 

As you note, the EVG definition isn't used anywhere, so it can be safely
removed. Along with that removal, we should consider addressing some issues
with Section 14.2.2. This section speaks to a "Enterprise EV Certificate"
that must be issued to the Enterprise RA that lists the (Base) Domain Names
for which that RA may issue EV Certificates for. There are a few problems
with this section:

1.	The language doesn't explicitly require a demonstration of control
of the Domain Namespace for the included domains in the Enterprise EV
Certificate; a blanket permission to issue for "third and higher domain
levels" is seemingly granted. Prior to the introduction of method 20, I
believe all domain validation methods allowed for the reuse of validation
data to validate subdomains of the Authorization Domain Name (ADN), so this
was not an issue. However, since there are now several validation methods
that prohibit "FQDN != ADN" validation, this appears to be a loophole.
2.	14.2.2 (5) seemingly has a provision to allow signing Enterprise EV
Certificates using Root CA Private Keys, contradicting Section 12's
prohibition on using Root CA Private Keys for signing EV Certificates.

 

> EVG 13 states "CAs MUST ensure that CRLs for an EV Certificate chain can
be downloaded in no more than three (3) seconds over an analog telephone
line under normal network conditions."

*	This requirement was in draft 11 in 2007. I believe that it was
added to support dial up Windows users.
*	Is it possible that we could drop this requirement and only require
BR 4.9?

 

In addition to removing this antiquated language, we should also consider
removing 9.7 (4), which states:

 

"The cRLDistributionPoints extension MUST be present in Subscriber

Certificates if the certificate does not specify OCSP responder locations in
an

authorityInformationAccess extension"

 

SC 31 removed the "OCSP stapling" exception to permit CAs to omit the AIA
OCSP pointer. As a result, EV certificates MUST contain an OCSP AIA pointer
in all cases. Thus, this language serves no purpose and could even be
(mis)interpreted as allowing EV certificates to omit the OCSP AIA pointer if
they contain a CRLDP.

 

Thanks,

Corey

 

From: Validation <validation-bounces at cabforum.org> On Behalf Of Bruce Morton
via Validation
Sent: Wednesday, February 23, 2022 2:39 PM
To: CABforum3 <validation at cabforum.org>
Subject: [cabf_validation] Enterprise RA and EV CRL Checking

 

I have a couple of low priority items which I would just like to table.

 

Enterprise RA and Enterprise EV RA

*	BR Enterprise RA definition - An employee or agent of an
organization unaffiliated with the CA who authorizes issuance of
Certificates to that organization.
*	EVG Enterprise EV RA definition - An RA that is authorized by the CA
to authorize the CA to issue EV Certificates at third and higher domain
levels.
*	Although EVG has added "EV" to the definition, the EVGs never
reference "Enterprise EV RA", but only " Enterprise RA".
*	As I assume that the CAs use the Enterprise RA to perform the same
function, can we consolidate the definition and only include the definition
in the BRs?

 

 

EV CRL Checking:

*	EVG 13 states "CAs MUST ensure that CRLs for an EV Certificate chain
can be downloaded in no more than three (3) seconds over an analog telephone
line under normal network conditions."
*	This requirement was in draft 11 in 2007. I believe that it was
added to support dial up Windows users.
*	Is it possible that we could drop this requirement and only require
BR 4.9?

 

 

 

Thanks, Bruce.

Any email and files/attachments transmitted with it are confidential and are
intended solely for the use of the individual or entity to whom they are
addressed. If this message has been sent to you in error, you must not copy,
distribute or disclose of the information it contains. Please notify Entrust
immediately and delete the message from your system. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20220304/5c1f1c30/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4990 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20220304/5c1f1c30/attachment-0001.p7s>