[Servercert-wg] EV Certificates through automation / Pre-Authorized Certificate Approver (API)

Fri Feb 2 22:31:10 UTC 2024

Yeah, this is where the GlobalSign ballot is actually an excellent start.  I
enjoyed Eva's overview on a recent validation SC call.  I need to dig deeper
into it and do more analysis of the proposals and what I think of them.
It's an ongoing conversation internally and I hope to have some preliminary
feedback soon.

I was also chatting with Bruce yesterday about getting EV slimmed down to
where it's basically a modular set of identity validation requirements,
instead of a full document with a fair amount of random historical stuff
that has little or nothing to do with how organizational validation is done.

Heck, some of the requirements are basically fossilized remains of wars that
have long since run their course.  The world is different now and has new
and better problems.

Thinking more broadly, I think it may be time for another idea that Bruce
has talked about a lot in the past --- different rules for validation of
renewals vs new certificates.  I completely understand why we moved to a
philosophy of "every issuance is a new certificate" and the need to make
sure all the validations are up to date and re-verified before issuing new
certificates, but throwing everything out and starting from scratch actually
makes it more difficult to detect that someone is impersonating the previous
requestor.  Having some sort of long-lived digital asset to be able to prove
that you were the previous requestor can actually help, and that digital
asset might even be the cert itself.  If a server that has access to the
previous private key and can prove it, wants an identical copy of the same
cert it currently has with just a different validity period, and the
identity validation is still valid and the certificate is still authorized,
it should just be able to get a new certificate.

But this is a complicated area, and the reasons the requirements exist are
not well understood any more.  Over the last decade or so, I've seen lots of
proposals both externally and internally on how to make the process easier
and more customer friendly, but it's actually significantly harder to do
than it looks.  You can't just throw out the painful requirements and hope
that what's left is a coherent security model.

-Tim

From: Servercert-wg <servercert-wg-bounces at cabforum.org> On Behalf Of Bruce
Morton via Servercert-wg
Sent: Friday, February 2, 2024 4:28 PM
To: Doug Beattie <doug.beattie at globalsign.com>; CA/B Forum Server
Certificate WG Public Discussion List <servercert-wg at cabforum.org>; Paul van
Brouwershaven <Paul.vanBrouwershaven at entrust.com>
Subject: Re: [Servercert-wg] EV Certificates through automation /
Pre-Authorized Certificate Approver (API)

Doug,

I do agree that we need to update the EV Guidelines. They were created with
the theme of single, manual certificate requests. There was no consideration
for automation. I do think that we should get update understanding of what
we want out of EV. I agree with "increased verified organizational
information/rules", which would exclude domains and the functions of a
certificate approver and due diligence and operations existence ... It
should also be certificate type neutral, so the EV standard could be applied
to any certificate type.

Bruce.

From: Servercert-wg <servercert-wg-bounces at cabforum.org
<mailto:servercert-wg-bounces at cabforum.org> > On Behalf Of Doug Beattie via
Servercert-wg
Sent: Friday, February 2, 2024 1:43 PM
To: Paul van Brouwershaven <Paul.vanBrouwershaven at entrust.com
<mailto:Paul.vanBrouwershaven at entrust.com> >; CA/B Forum Server Certificate
WG Public Discussion List <servercert-wg at cabforum.org
<mailto:servercert-wg at cabforum.org> >
Subject: [EXTERNAL] Re: [Servercert-wg] EV Certificates through automation /
Pre-Authorized Certificate Approver (API)

Hi Paul,

Yea, that's a lot of good information, but I keep coming back to "what's the
value of the certificate approver, especially within a managed account, for
EV in 2024"?  Do we need to have designated individuals as the only people
that can request EV domains and certificates?  When EVGL was initially
written the differentiators for EV were much larger than today, and with
automation being pushed by customers and root programs, can we re-look at
this and determine if all of the these roles and permissions are still
necessary?  If it were up to me, I'd make EV issuance the same as OV with
the exception of the increased verified organizational information/rules so
we can standardize and streamline TLS EV domain validation and issuance.
We've already aligned the domain validation methods and certificate validity
periods.

Doug

I get that this certificate has additional details in it, but is the ability
to bind domains to this request (or identity in the case of a manages
service) or require that these only be submitted by a specific privileged
person still relevant?  It's not necessary for OV and am wondering if all of
this mapping from a designated certificate approver person to API
credentials and specific roles and permissions is overly complicated 

From: Paul van Brouwershaven <Paul.vanBrouwershaven at entrust.com
<mailto:Paul.vanBrouwershaven at entrust.com> > 
Sent: Friday, February 2, 2024 10:02 AM
To: Doug Beattie <doug.beattie at globalsign.com
<mailto:doug.beattie at globalsign.com> >; CA/B Forum Server Certificate WG
Public Discussion List <servercert-wg at cabforum.org
<mailto:servercert-wg at cabforum.org> >
Subject: Re: EV Certificates through automation / Pre-Authorized Certificate
Approver (API)

An ACME key and API key are both credentials but just in a different from, I
provided the examples with API keys as these are most widely used today.

We do indeed use the External Account Binding (EAB), and this works for a
setup where the user can configure the ACME server at the Cloud Service
Provider (ACME client) and provide the EAB to the Cloud Service Provider,
unfortunately this is rarely the case, as I presented at F2F#59 in Redmond
<https://url.avanan.click/v2/___https:/cabforum.org/wp-content/uploads/F2F-5
9-CABF-SCWG-ACME-Automation.pdf___.YXAzOmRpZ2ljZXJ0OmE6bzo5ZTgyZTVhNzJiNTQzM
DJhOTdjMzQ3ZGZlMGM0NmUyMTo2OmNiY2Q6MWY4YTc2NWNhMzJkOWUwNGUyMmJhYzE2ZjVkZmI4O
GUxYzhkYWEwNTU3YzJhOGM1MTlhMmQ4OWQwMzAxNGU1ZjpoOkY> .

This is why we have been working on an auto discovery mechanism
<https://url.avanan.click/v2/___https:/datatracker.ietf.org/doc/draft-vanbro
uwershaven-acme-auto-discovery/___.YXAzOmRpZ2ljZXJ0OmE6bzo5ZTgyZTVhNzJiNTQzM
DJhOTdjMzQ3ZGZlMGM0NmUyMTo2OmU0MmU6YTM2ZmZjNDQ1YTg1YjA1ZWE4MDc2NTM5MDczYzU4Y
jU0ZTZkODU0NDlmN2NhOTczZThkYjY3MzFkNjQwZDVkZTpoOkY>  for ACME, and this
works fine for domain validated certificates as you do not need an EAB for
that, but we would also like to ensure that identity certificates can be
supported by this proposal.

A domain and organization can be pre-linked at the CA, after verification of
domain control and the organization identity.

With ACME its simple to validate domain control for each request, this could
be precondition when there is no explicit and unique account binding. But
proving domain control does not equal an authorization of a Certificate
Approver as required for the issuance of an EV certificate. 

Like linking an ACME client key via an External Account Binding (EAB) to a
Pre-Authorized Certificate Approver, according to 11.8.4 of the EVG, to
support EV certificates over ACME. We could link the ACME keys of an Cloud
Service Provider at the CA side without EAB if these would be disclosed for
linking (like via a manual or by publishing them to the well-known
directory).

My initial thought is that this would give the same guarantee as when the
user provides an EAB to the Cloud Service Provider which links that to an
ACME client key that is shared between all customers as we are just
reversing the process.

> Do we need the concept of Certificate Approver? 

The idea that a human approves individual certificates requests doesn't
align with the desire for automation. 

The concept of a Pre-Authorized certificate approver (EVG 11.8.4) seems to
be trying to address this issue by allowing multiple future EV Certificate
Requests. 

With API keys linked to Pre-Authorized certificate approvers, we assume that
all requests made with this API key are on behalf of that Pre-Authorized
certificate approver, where in reality they are made by a system, which
could be a third party. 

I think we want to have approval by the organization that certificates which
include the organization in the subject DN can be issued for a given domain
name/FQDN, but this is something that can be pre-approved for each domain
name/FQDN and doesn't have to be specified per certificate request.

  _____  

From: Doug Beattie
Sent: Friday, February 02, 2024 12:48
To: Paul van Brouwershaven; CA/B Forum Server Certificate WG Public
Discussion List
Subject: [EXTERNAL] RE: EV Certificates through automation / Pre-Authorized
Certificate Approver (API) 

Hi Paul,

Thanks for that presentation.

I'm assuming that Entrust uses External Account Binding (EAB) to link the
MAC key and KeyID to the customer account.  Are these the API credentials
you're referring to in the presentation?

Another way to look into automating for EV is asking the question: Do we
need the concept of Certificate Approver?  While there was probably value in
this back when the EVGs were created, is there continued value of this in
2024, especially in light of the need to automate?

Regards,

Doug

From: Servercert-wg <servercert-wg-bounces at cabforum.org
<mailto:servercert-wg-bounces at cabforum.org> > On Behalf Of Paul van
Brouwershaven via Servercert-wg
Sent: Thursday, February 1, 2024 12:41 PM
To: CA/B Forum Server Certificate WG Public Discussion List
<servercert-wg at cabforum.org <mailto:servercert-wg at cabforum.org> >
Subject: [Servercert-wg] EV Certificates through automation / Pre-Authorized
Certificate Approver (API)

As briefly introduced on the Server Certificate WG Teleconference, I would
like to bring up a topic around the use of API keys that are linked to a
Pre-Authorized Certificate Approver.

Please find some reference slides attached.

Slide 3: 
How I think API keys with a Pre-Authorized Certificate Approver are
implemented today.

Slide 4: 
If the API key fulfills the same requirements and is authorized by the
Certificate Approver, does it matter who creates/holds the API key with
authorization of the Certificate Approver?

Slide 5: 
Does this change if the authorization was given based on a reference to an
API key, like located in a well-known directory of the Cloud Service
Provider (CSP)? The idea is that this could enable ACME auto discovery
<https://url.avanan.click/v2/___https:/datatracker.ietf.org/doc/draft-vanbro
uwershaven-acme-auto-discovery/___.YXAzOmRpZ2ljZXJ0OmE6bzo5ZTgyZTVhNzJiNTQzM
DJhOTdjMzQ3ZGZlMGM0NmUyMTo2OmJiZjQ6YTU0OTliNWI2NzkwYjczZTUxYmIxNTFkMGY3MmI2Y
2QxMTAwZWNiNGZmOGVhM2M0NzZhMTJlMDBiZDk5NjMxODpoOkY>  for OV and EV
certificates as the Certificate Approver explicitly approves the CSP to
request certificates on their behalf.

It would be great to get people's thoughts on this!

Paul

Any email and files/attachments transmitted with it 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/servercert-wg/attachments/20240202/e293b9b7/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5231 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20240202/e293b9b7/attachment-0001.p7s>