<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Aptos;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle21
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
mso-ligatures:none;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple style='word-wrap:break-word'><div class=WordSection1><p class=MsoNormal>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.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>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.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>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.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>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.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>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.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>-Tim<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b>From:</b> Servercert-wg <servercert-wg-bounces@cabforum.org> <b>On Behalf Of </b>Bruce Morton via Servercert-wg<br><b>Sent:</b> Friday, February 2, 2024 4:28 PM<br><b>To:</b> Doug Beattie <doug.beattie@globalsign.com>; CA/B Forum Server Certificate WG Public Discussion List <servercert-wg@cabforum.org>; Paul van Brouwershaven <Paul.vanBrouwershaven@entrust.com><br><b>Subject:</b> Re: [Servercert-wg] EV Certificates through automation / Pre-Authorized Certificate Approver (API)<o:p></o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Doug,<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>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.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Bruce.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b>From:</b> Servercert-wg <<a href="mailto:servercert-wg-bounces@cabforum.org">servercert-wg-bounces@cabforum.org</a>> <b>On Behalf Of </b>Doug Beattie via Servercert-wg<br><b>Sent:</b> Friday, February 2, 2024 1:43 PM<br><b>To:</b> Paul van Brouwershaven <<a href="mailto:Paul.vanBrouwershaven@entrust.com">Paul.vanBrouwershaven@entrust.com</a>>; CA/B Forum Server Certificate WG Public Discussion List <<a href="mailto:servercert-wg@cabforum.org">servercert-wg@cabforum.org</a>><br><b>Subject:</b> [EXTERNAL] Re: [Servercert-wg] EV Certificates through automation / Pre-Authorized Certificate Approver (API)<o:p></o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Hi Paul,<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>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 <i>need</i> 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.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Doug<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>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 <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b>From:</b> Paul van Brouwershaven <<a href="mailto:Paul.vanBrouwershaven@entrust.com">Paul.vanBrouwershaven@entrust.com</a>> <br><b>Sent:</b> Friday, February 2, 2024 10:02 AM<br><b>To:</b> Doug Beattie <<a href="mailto:doug.beattie@globalsign.com">doug.beattie@globalsign.com</a>>; CA/B Forum Server Certificate WG Public Discussion List <<a href="mailto:servercert-wg@cabforum.org">servercert-wg@cabforum.org</a>><br><b>Subject:</b> Re: EV Certificates through automation / Pre-Authorized Certificate Approver (API)<o:p></o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal><span style='font-family:"Aptos",sans-serif;color:black'>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.</span><o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><span style='font-family:"Aptos",sans-serif;color:black'>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 <span style='background:white'>Cloud Service Provider</span> (ACME client) and provide the EAB to the Cloud Service Provider, unfortunately this is rarely the case, <a href="https://url.avanan.click/v2/___https:/cabforum.org/wp-content/uploads/F2F-59-CABF-SCWG-ACME-Automation.pdf___.YXAzOmRpZ2ljZXJ0OmE6bzo5ZTgyZTVhNzJiNTQzMDJhOTdjMzQ3ZGZlMGM0NmUyMTo2OmNiY2Q6MWY4YTc2NWNhMzJkOWUwNGUyMmJhYzE2ZjVkZmI4OGUxYzhkYWEwNTU3YzJhOGM1MTlhMmQ4OWQwMzAxNGU1ZjpoOkY" title="https://cabforum.org/wp-content/uploads/F2F-59-CABF-SCWG-ACME-Automation.pdf">as I presented at F2F#59 in Redmond</a>.</span><o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><span style='font-family:"Aptos",sans-serif;color:black'>This is why we have been working on an <a href="https://url.avanan.click/v2/___https:/datatracker.ietf.org/doc/draft-vanbrouwershaven-acme-auto-discovery/___.YXAzOmRpZ2ljZXJ0OmE6bzo5ZTgyZTVhNzJiNTQzMDJhOTdjMzQ3ZGZlMGM0NmUyMTo2OmU0MmU6YTM2ZmZjNDQ1YTg1YjA1ZWE4MDc2NTM5MDczYzU4YjU0ZTZkODU0NDlmN2NhOTczZThkYjY3MzFkNjQwZDVkZTpoOkY" title="https://datatracker.ietf.org/doc/draft-vanbrouwershaven-acme-auto-discovery/">auto discovery mechanism for ACME</a>, 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.</span><o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><span style='font-family:"Aptos",sans-serif;color:black'>A domain and organization can be pre-linked at the CA, after verification of domain control and the organization identity.</span><o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><span style='font-family:"Aptos",sans-serif;color:black'>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. </span><o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><span style='font-family:"Aptos",sans-serif;color:black'>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).</span><o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><span style='font-family:"Aptos",sans-serif;color:black'>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.</span><o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><span style='font-family:"Aptos",sans-serif;color:black'>> Do we need the concept of Certificate Approver? </span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-family:"Aptos",sans-serif;color:black'>The idea that a human approves individual certificates requests doesn't align with the desire for automation. </span><o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><span style='font-family:"Aptos",sans-serif;color:black'>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. </span><o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><span style='font-family:"Aptos",sans-serif;color:black'>With API keys linked to <span style='background:white'>Pre-Authorized certificate approver</span>s, we assume that all requests made with this API key <span style='background:white'>are </span>on behalf of that Pre-Authorized certificate approver, where in reality they are made by a system, which could be a third party. </span><o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><span style='font-family:"Aptos",sans-serif;color:black;background:white'>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.</span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:12.0pt;color:black'><o:p> </o:p></span></p></div><div><p class=MsoNormal><span style='font-size:12.0pt;color:black'><o:p> </o:p></span></p></div><div><p class=MsoNormal><span style='font-size:12.0pt;color:black'><o:p> </o:p></span></p></div><div class=MsoNormal align=center style='text-align:center'><hr size=1 width="98%" align=center></div><p class=MsoNormal><b><span style='font-size:12.0pt;color:black'>From:</span></b><span style='font-size:12.0pt;color:black'> Doug Beattie<br><b>Sent:</b> Friday, February 02, 2024 12:48<br><b>To:</b> Paul van Brouwershaven; CA/B Forum Server Certificate WG Public Discussion List<br><b>Subject:</b> [EXTERNAL] RE: EV Certificates through automation / Pre-Authorized Certificate Approver (API) </span><o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><p><span style='color:black'>Hi Paul,</span><o:p></o:p></p><p><span style='color:black'> </span><o:p></o:p></p><p><span style='color:black'>Thanks for that presentation.</span><o:p></o:p></p><p><span style='color:black'> </span><o:p></o:p></p><p><span style='color:black'>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?</span><o:p></o:p></p><p><span style='color:black'> </span><o:p></o:p></p><p><span style='color:black'>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?</span><o:p></o:p></p><p><span style='color:black'> </span><o:p></o:p></p><p><span style='color:black'>Regards,</span><o:p></o:p></p><p><span style='color:black'> </span><o:p></o:p></p><p><span style='color:black'>Doug</span><o:p></o:p></p><p><span style='color:black'> </span><o:p></o:p></p><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p><b><span style='color:black'>From:</span></b><span style='color:black'> Servercert-wg <<a href="mailto:servercert-wg-bounces@cabforum.org">servercert-wg-bounces@cabforum.org</a>> <b>On Behalf Of </b>Paul van Brouwershaven via Servercert-wg<br><b>Sent:</b> Thursday, February 1, 2024 12:41 PM<br><b>To:</b> CA/B Forum Server Certificate WG Public Discussion List <<a href="mailto:servercert-wg@cabforum.org">servercert-wg@cabforum.org</a>><br><b>Subject:</b> [Servercert-wg] EV Certificates through automation / Pre-Authorized Certificate Approver (API)</span><o:p></o:p></p></div><p><span style='color:black'> </span><o:p></o:p></p><p><span style='font-family:"Aptos",sans-serif;color:black'>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.</span><o:p></o:p></p><p><span style='color:black'> </span><o:p></o:p></p><p><span style='font-family:"Aptos",sans-serif;color:black'>Please find some reference slides attached.</span><o:p></o:p></p><p><span style='color:black'> </span><o:p></o:p></p><p><b><span style='font-family:"Aptos",sans-serif;color:black'>Slide 3:</span></b><span style='font-family:"Aptos",sans-serif;color:black'> <br>How I think API keys with a Pre-Authorized Certificate Approver are implemented today.</span><o:p></o:p></p><p><span style='color:black'> </span><o:p></o:p></p><p><b><span style='font-family:"Aptos",sans-serif;color:black'>Slide 4:</span></b><span style='font-family:"Aptos",sans-serif;color:black'> <br>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?</span><o:p></o:p></p><p><span style='color:black'> </span><o:p></o:p></p><p><b><span style='font-family:"Aptos",sans-serif;color:black'>Slide 5:</span></b><span style='font-family:"Aptos",sans-serif;color:black'> <br>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 <a href="https://url.avanan.click/v2/___https:/datatracker.ietf.org/doc/draft-vanbrouwershaven-acme-auto-discovery/___.YXAzOmRpZ2ljZXJ0OmE6bzo5ZTgyZTVhNzJiNTQzMDJhOTdjMzQ3ZGZlMGM0NmUyMTo2OmJiZjQ6YTU0OTliNWI2NzkwYjczZTUxYmIxNTFkMGY3MmI2Y2QxMTAwZWNiNGZmOGVhM2M0NzZhMTJlMDBiZDk5NjMxODpoOkY" title="https://datatracker.ietf.org/doc/draft-vanbrouwershaven-acme-auto-discovery/">ACME auto discovery</a> for OV and EV certificates as the Certificate Approver explicitly approves the CSP to request certificates on their behalf.</span><o:p></o:p></p><p><span style='color:black'> </span><o:p></o:p></p><p><span style='font-family:"Aptos",sans-serif;color:black'>It would be great to get people’s thoughts on this!</span><o:p></o:p></p><p><span style='color:black'> </span><o:p></o:p></p><p><span style='font-family:"Aptos",sans-serif;color:black'>Paul</span><o:p></o:p></p><p><span style='font-family:"Aptos",sans-serif;color:black'> </span><o:p></o:p></p><p><i><span style='color:black'>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. <u>Please notify Entrust immediately and delete the message from your system.</u></span></i><o:p></o:p></p></div></div></body></html>