Re: [Servercert-wg] Ballot SC-75 - Pre-sign linting

*De:*Servercert-wg *En nombre de *Dimitris Zacharopoulos (HARICA) via Servercert-wg *Enviado el:* lunes, 20 de mayo de 2024 19:57 *Para:* CA/B Forum Server Certificate WG Public Discussion List *Asunto:* [Servercert-wg] Ballot SC-75 - Pre-sign lint

Re: [Servercert-wg] Ballot SC-75 - Pre-sign linting

an On Mon, May 20, 2024 at 2:04 PM Inigo Barreira via Servercert-wg wrote: Hi Dimitris, I don´t know if the “(help to improve)” is adding any additional hidden requirement. IMO, I´d remove that. Regards *De:*Servercert-wg *En nombre de *Dimitris Zacharopoulos (HARIC

[Servercert-wg] Ballot SC-75 - Pre-sign linting

SC-75 Pre-sign linting Summary There have been numerous compliance incidents publicly disclosed by CAs in which they failed to comply with the technical requirements described in standards associated with the issuance and management of publicly-trusted TLS Certificates. However, the

Re: [Servercert-wg] [External Sender] Discussion about single-purpose client authentication leaf certificates issued from a server TLS Issuing CA

On 16/5/2024 10:29 μ.μ., Clint Wilson wrote: AFAIK Apple and Mozilla also don't have a specific "trust bit" for Client Authentication. Only Microsoft does. FWIW, Apple does indeed have a specific trust bit for id-kp-clientAuth EKU and allows for (and ships) dedicated clientAuth Root CAs in

Re: [Servercert-wg] [External Sender] Discussion about single-purpose client authentication leaf certificates issued from a server TLS Issuing CA

On 16/5/2024 10:20 μ.μ., Clint Wilson wrote: On May 16, 2024, at 1:19 AM, Dimitris Zacharopoulos (HARICA) wrote: [...] Regardless of the conclusion to the questions you posed, I’m failing to see why we would want any other outcome than to have subCAs which issue TBR-compliant TLS

Re: [Servercert-wg] [External Sender] Discussion about single-purpose client authentication leaf certificates issued from a server TLS Issuing CA

On 16/5/2024 3:21 μ.μ., Dimitris Zacharopoulos (HARICA) via Servercert-wg wrote: I don’t know if you didn’t mention Chrome for a particular reason, No particular reason. It's just a relatively new Root Program compared to others and I haven't bumped into a public tender that requires

Re: [Servercert-wg] [External Sender] Discussion about single-purpose client authentication leaf certificates issued from a server TLS Issuing CA

On 16/5/2024 12:20 μ.μ., Pedro FUENTES wrote: Hello Dimitris, I’m following closely this as I find very important. About… This is easy to answer. Some use cases need single-purpose client authentication certificates. There are numerous use cases where client authentication certificates are

Re: [Servercert-wg] [External Sender] Discussion about single-purpose client authentication leaf certificates issued from a server TLS Issuing CA

On 15/5/2024 11:07 μ.μ., Clint Wilson wrote: Hi Dimitris, I guess I’m confused about how this is relevant to the scope of the CA/BF as it seems quite orthogonal to the questions you posed initially. Regardless of how clients check certificates, the question is about the issuance of a

Re: [Servercert-wg] [External Sender] Discussion about single-purpose client authentication leaf certificates issued from a server TLS Issuing CA

On 15/5/2024 7:27 μ.μ., Clint Wilson wrote: Apologies if I’m replying to the wrong thread, but I wanted to comment on one point here. On May 14, 2024, at 8:54 AM, Dimitris Zacharopoulos (HARICA) via Servercert-wg wrote: On 14/5/2024 1:27 μ.μ., Adriano Santoni via Servercert-wg wrote

Re: [Servercert-wg] Discussion about single-purpose client authentication leaf certificates issued from a server TLS Issuing CA

to be revoked too… Which IMHO makes no sense at all.  Indeed, it doesn't :) Rgds Roman *From:*Servercert-wg *On Behalf Of *Dimitris Zacharopoulos (HARICA) via Servercert-wg *Sent:* Mittwoch, 15. Mai 2024 07:20 *To:* servercert-wg@cabforum.org *Subject:* Re: [Servercert-wg] Discussion about single

Re: [Servercert-wg] Discussion about single-purpose client authentication leaf certificates issued from a server TLS Issuing CA

bject:* Re: [Servercert-wg] Discussion about single-purpose client authentication leaf certificates issued from a server TLS Issuing CA On Tue, May 14, 2024, 02:33 Dimitris Zacharopoulos (HARICA) via Servercert-wg wrote: Is it ok for such an Issuing CA to create a single-purpose client auth

Re: [Servercert-wg] Discussion about single-purpose client authentication leaf certificates issued from a server TLS Issuing CA

erence and proceed accordingly. Dimitris. * "Clarifying" has been used before as a way of adding new requirements. Aaron On Tue, May 14, 2024 at 8:49 AM Dimitris Zacharopoulos (HARICA) wrote: On 14/5/2024 5:58 μ.μ., Aaron Gable wrote: On Tue, May 14, 2024, 02:33 Dimitris Zach

Re: [Servercert-wg] Discussion about single-purpose client authentication leaf certificates issued from a server TLS Issuing CA

t as long as we reach consensus about the intent related to client authentication -and other non-server-TLS, non-codeSigning, non-timeStamping, non-emailProtection- leaf certificates. Thanks, Dimitris. Regards, Martijn *From: *Servercert-wg on behalf of Dimitris Zacharopoulos (HA

Re: [Servercert-wg] [External Sender] Discussion about single-purpose client authentication leaf certificates issued from a server TLS Issuing CA

, Dimitris Zacharopoulos (HARICA) via Servercert-wg ha scritto: NOTICE: Pay attention - external email - Sender is 0100018f76738e97-739d5cad-6797-4977-b997-150e338d5740-000...@amazonses.com Dear Members, Following-up on an interesting public incident <https://bugzilla.mozilla.org/show_bug.c

Re: [Servercert-wg] Discussion about single-purpose client authentication leaf certificates issued from a server TLS Issuing CA

On 14/5/2024 5:58 μ.μ., Aaron Gable wrote: On Tue, May 14, 2024, 02:33 Dimitris Zacharopoulos (HARICA) via Servercert-wg wrote: Is it ok for such an Issuing CA to create a single-purpose client authentication TLS Certificate, one that is structured according to RFC 5280 (thus

[Servercert-wg] Discussion about single-purpose client authentication leaf certificates issued from a server TLS Issuing CA

Dear Members, Following-up on an interesting public incident , I would like to have a discussion about the scope of the TLS BRs as specified in the SCWG Charter and in the actual TLS BRs, especially when it comes to single-purpose

Re: [Servercert-wg] Ballot SC-74 - Clarify CP/CPS structure according to RFC 3647

others, Aaron On Thu, Apr 25, 2024 at 9:27 AM Dimitris Zacharopoulos (HARICA) via Servercert-wg wrote: SC-74 - Clarify CP/CPS structure according to RFC 3647

Re: [Servercert-wg] [Voting Begins] Ballot SC-74 - Clarify CP/CPS structure according to RFC 3647

HARICA votes "no" to ballot SC-74. Dimitris. On 5/5/2024 12:06 μ.μ., Dimitris Zacharopoulos (HARICA) wrote: HARICA votes "yes" to ballot SC-74. On 5/5/2024 11:24 π.μ., Dimitris Zacharopoulos (HARICA) via Servercert-wg wrote: Voting begins for ballot SC-74. SC

Re: [Servercert-wg] [Voting Begins] Ballot SC-74 - Clarify CP/CPS structure according to RFC 3647

to "no" so that the ballot fails and we can re-introduce it after we resolve these issues. Thank you, Dimitris. On 5/5/2024 11:24 π.μ., Dimitris Zacharopoulos (HARICA) via Servercert-wg wrote: Voting begins for ballot SC-74. SC-74 - Clarify CP/CPS structure according t

Re: [Servercert-wg] Ballot SC-74 - Clarify CP/CPS structure according to RFC 3647

eral section titles that deviate from that outline in either capitalization or actual content. We hope this information is helpful to others, Aaron On Thu, Apr 25, 2024 at 9:27 AM Dimitris Zacharopoulos (HARICA) via Servercert-wg wrote: SC-74 - Clarify CP/CPS structure according

Re: [Servercert-wg] [Voting Begins] Ballot SC-74 - Clarify CP/CPS structure according to RFC 3647

HARICA votes "yes" to ballot SC-74. On 5/5/2024 11:24 π.μ., Dimitris Zacharopoulos (HARICA) via Servercert-wg wrote: Voting begins for ballot SC-74. SC-74 - Clarify CP/CPS structure according to RFC 3647 Summary The TLS Baseline Requirements require in s

[Servercert-wg] [Voting Begins] Ballot SC-74 - Clarify CP/CPS structure according to RFC 3647

Voting begins for ballot SC-74. SC-74 - Clarify CP/CPS structure according to RFC 3647 Summary The TLS Baseline Requirements require in section 2.2 that: /"The Certificate Policy and/or Certification Practice Statement MUST be structured in accordance with RFC 3647 and MUST include all

Re: [Servercert-wg] [External Sender] Question regarding the id-ad-caIssuers accessMethod URI

ed a clarification is worthwhile here. To be clear, I’m not opposed, I’m just not sure it’s something CAs are actively getting or likely to get wrong — if some are, then I would instead support such a clarification. Cheers! -Clint On Apr 25, 2024, at 5:41 AM, Dimitris Zacharopoulos (HARICA) via

Re: [Servercert-wg] Voting Period Begins - Ballot SC-073: Compromised and Weak Keys

HARICA votes "yes" to ballot SC-073. On 26/4/2024 3:00 π.μ., Wayne Thayer via Servercert-wg wrote: Purpose of Ballot SC-073 This ballot proposes updates to the Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates related to weak and compromised

[Servercert-wg] Ballot SC-74 - Clarify CP/CPS structure according to RFC 3647

SC-74 - Clarify CP/CPS structure according to RFC 3647 Summary The TLS Baseline Requirements require in section 2.2 that: /"The Certificate Policy and/or Certification Practice Statement MUST be structured in accordance with RFC 3647 and MUST include all material required by RFC

Re: [Servercert-wg] [External Sender] Question regarding the id-ad-caIssuers accessMethod URI

e noted that PKILINT contains a validator for checking that the URI in the *id-ad-caIssuers* accessMethod starts with "http://;. Adriano Il 25/04/2024 08:10, Dimitris Zacharopoulos (HARICA) via Servercert-wg ha scritto: NOTICE: Pay attention - external email - Sender is

[Servercert-wg] Question regarding the id-ad-caIssuers accessMethod URI

Dear Members, I have a quick question regarding the |id-ad-caIssuers|accessMethod URI. Section 4.2.2.1 of RFC 5280 states that: When the|id-ad-caIssuers|accessMethod is used, at least one instance SHOULD specify an

[Servercert-wg] Pre-ballot SC-74 - Clarify CP/CPS structure according to RFC 3647

Dear Members, Following up to the CP/CPS RFC3647 alignment discussion at the last F2F, I prepared a ballot to address the ambiguity regarding the appropriate sections from RFC 3647 that CAs need to include in their CP and/or CPS documents. An effective date was added because these changes

Re: [Servercert-wg] Discussion Period Begins - Ballot SC-071: Subscriber Agreement and Terms of Use Consolidation

On 19/4/2024 9:54 μ.μ., Aaron Gable wrote: On Fri, Apr 19, 2024 at 11:07 AM Dimitris Zacharopoulos (HARICA) via Servercert-wg wrote: What happens if the SA/ToS document changes? I had the impression that the ACME client would be able to see the new version and ask

Re: [Servercert-wg] Discussion Period Begins - Ballot SC-071: Subscriber Agreement and Terms of Use Consolidation

On 18/4/2024 7:58 μ.μ., Aaron Gable via Servercert-wg wrote: 1. Section 9.6.1 adds language that imposes or makes the following requirements explicit: i. the Subscriber has been provided with the most current version of the Subscriber Agreement; ii. the

Re: [Servercert-wg] Ballot to introduce linting in the TLS BRs

On 19/3/2024 6:31 μ.μ., Ben Wilson wrote: Hi Dimitris, You can add me. Thanks Ben, Ballot SC-73 has been assigned to address this issue. Best regards, Dimitris. Thanks, Ben On Tue, Mar 19, 2024 at 9:01 AM Dimitris Zacharopoulos (HARICA) via Servercert-wg wrote: On 19/3/2024 5

Re: [Servercert-wg] Ballot to introduce linting in the TLS BRs

Of *Dimitris Zacharopoulos (HARICA) via Servercert-wg *Sent:* Sunday, March 17, 2024 8:20 AM *To:* CA/B Forum Server Certificate WG Public Discussion List *Subject:* [Servercert-wg] Ballot to introduce linting in the TLS BRs Hi all, This is still very draft <https://url.avanan.click/v2/___ht

Re: [Servercert-wg] Discussion Period Begins - Ballot SC-067 V1: "Require domain validation and CAA checks to be performed from multiple Network Perspectives”

Hi Chris, On 18/3/2024 5:32 μ.μ., Chris Clements via Servercert-wg wrote: Intellectual Property (IP) Disclosure: - While not a Server Certificate Working Group Member, researchers from Princeton University presented at Face-to-Face 58, provided academic expertise, and highlighted

Re: [Servercert-wg] Discussion Period Begins - Ballot SC-067 V1: "Require domain validation and CAA checks to be performed from multiple Network Perspectives”

Hi Antti, The ballot number seems to be ok. Check out https://wiki.cabforum.org/books/server-certificate-wg/page/scwg-ballots-wuG It looks like Ben and Dustin need to get a new number and add a row to the corresponding table. Thanks, Dimitris. On 19/3/2024 7:19 π.μ., Backman, Antti

[Servercert-wg] Ballot to introduce linting in the TLS BRs

Hi all, This is still very draft based on the latest F2F. I would like to ask for 2 endorsers so we can work on the details of the ballot language in the next few of weeks. Thank you,

Re: [Servercert-wg] Compromised/Weak Keys Ballot Proposal

FWIW, I think in the recent years, it was mostly security researchers that attempted to request certificates with Debian weak keys to test if a CA was properly blocking them. If an Applicant uses an outdated OS that generates weak keys, imagine the actual web server or other software that

Re: [Servercert-wg] [Voting Period Begins]: SC65: Convert EVGs into RFC 3647 format v2

ring that the PR is correct) the ballot can continue and see the result. Regards *De:*Servercert-wg *En nombre de *Dimitris Zacharopoulos (HARICA) via Servercert-wg *Enviado el:* jueves, 7 de marzo de 2024 9:07 *Para:* servercert-wg@cabforum.org *Asunto:* Re: [Servercert-wg] [Voting Period Begins

Re: [Servercert-wg] [Voting Period Begins]: SC65: Convert EVGs into RFC 3647 format v2

Apologies for not reviewing this ballot sooner. I am a bit confused with the redline changes, especially in the BRG. Based on the GitHub link, the comparison of the BRs is against version 2.0.0, not 2.0.2 as described in the summary of this ballot. HARICA is uncertain about the changes

Re: [Servercert-wg] [Voting Period Begins]: SC-69v3 Clarify router and firewall logging requirements

HARICA votes "yes" to ballot SC-69v3. On 4/3/2024 12:59 μ.μ., Martijn Katerbarg via Servercert-wg wrote: *Summary: * This ballot aims to clarify what data needs to be logged as part of the "Firewall and router activities" logging requirement in the Baseline Requirements. This ballot is

Re: [Servercert-wg] [Voting Period Begins] SC-070: Clarify the use of DTPs for Domain Control Validation

HARICA votes "yes" to ballot SC-070. On 13/2/2024 6:57 μ.μ., Aaron Gable via Servercert-wg wrote: This new voting period is to fix a typo in the End timestamp of the voting period for the previous version of this ballot. The contents of the motion itself are identical. My apologies for the

Re: [Servercert-wg] Voting Begins for Ballot SC-68: Allow VATEL and VATXI for organizationIdentifier

Reminder that voting for ballot SC-68 ends tomorrow, 2024-01-30 8:00 UTC. Thank you, Dimitris. On 23/1/2024 11:00 π.μ., Dimitris Zacharopoulos (HARICA) wrote: This email initiates the voting period for ballot SC-68. Please vote. Purpose of the Ballot The EV Guidelines have strict

Re: [Servercert-wg] Voting Begins for Ballot SC-68: Allow VATEL and VATXI for organizationIdentifier

HARICA votes "yes" to ballot SC-68. On 23/1/2024 11:00 π.μ., Dimitris Zacharopoulos (HARICA) via Servercert-wg wrote: This email initiates the voting period for ballot SC-68. Please vote. Purpose of the Ballot The EV Guidelines have strict rules in the organization

[Servercert-wg] Voting Begins for Ballot SC-68: Allow VATEL and VATXI for organizationIdentifier

This email initiates the voting period for ballot SC-68. Please vote. Purpose of the Ballot The EV Guidelines have strict rules in the organizationIdentifier values and require the country code of all currently-allowed Registration Schemes (NTR, VAT, PSD) to follow the ISO 3166-1 for

Re: [Servercert-wg] [EXTERNAL]- Ballot SC-68: Allow VATEL and VATXI for organizationIdentifier

CA/B Forum) cases, the provisions of 9.16.3 of the BRs or 8.1 of EVG must be followed. Dimitris. On 16 Jan 2024, at 09:07, Dimitris Zacharopoulos (HARICA) via Servercert-wg wrote: Purpose of the Ballot The EV Guidelines have strict rules in the organizationIdentifier values a

[Servercert-wg] Ballot SC-68: Allow VATEL and VATXI for organizationIdentifier

Purpose of the Ballot The EV Guidelines have strict rules in the organizationIdentifier values and require the country code of all currently-allowed Registration Schemes (NTR, VAT, PSD) to follow the ISO 3166-1 for the 2-letter country prefix. The organizationIdentifier language

[Servercert-wg] Fwd: [cabfpub] Highlight repeated non-acceptable practices, clarify requirements and discuss about DTPs

Forwarding to the Server Certificate WG list to continue the discussion for the TLS BRs. Thanks Aaron, Dimitris. Forwarded Message Subject: Re: [cabfpub] Highlight repeated non-acceptable practices, clarify requirements and discuss about DTPs Date: Thu, 11 Jan 2024

[Servercert-wg] Allow VATEL for organizationIdentifier values in EV Guidelines

Dear Members, The EV Guidelines have strict rules in the organizationIdentifier values and require the country code of all currently-allowed Registration Schemes (NTR, VAT, PSD) to follow the ISO 3166-1 for the 2-letter country prefix. The organizationIdentifier language mainly came from

Re: [Servercert-wg] Section 7.1.5 as required by RFC 3647 is no longer in the TLS BRs

of the BRs. Hopefully we can add pointers to the right name constraints language. Does that make sense? Dimitris. On Thu, Jan 4, 2024 at 4:54 AM Dimitris Zacharopoulos (HARICA) via Servercert-wg wrote: Dear Members, While taking another pass at reviewing the new certificate

[Servercert-wg] Section 7.1.5 as required by RFC 3647 is no longer in the TLS BRs

Dear Members, While taking another pass at reviewing the new certificate profiles introduced in ballot SC62, I realized that there is some deviation from the RFC 3647 structure that the BRs should maintain to help alignment of CA CP/CPS documents. This is the structure defined by RFC 3647

Re: [Servercert-wg] SC-065: Convert EVGs into RFC 3647 format pre-ballot

On 4/12/2023 9:22 μ.μ., Bruce Morton wrote: I thought an intriguing promise of doing documents in Github and in the same format is that we would see the requirements in the same section, which would allow for better management. Also, the proposal Paul brought forward for the BR of BRs

Re: [Servercert-wg] SC-065: Convert EVGs into RFC 3647 format pre-ballot

FWIW, there are informational RFCs that include SHOULD requirements (I didn't check for other informational RFCs that might contain SHALL requirements). Take a look at RFC 8894 . I agree that there seems to be some ambiguity in the REQUIRED

Re: [Servercert-wg] SC-065: Convert EVGs into RFC 3647 format pre-ballot

We still have a disagreement so please allow me one more attempt to clarify my position because it seems you didn't check the links included in my previous post. I will copy some of that text here for convenience. On 1/12/2023 11:31 μ.μ., Tim Hollebeek wrote: No. IETF has both Normative and

Re: [Servercert-wg] SC-065: Convert EVGs into RFC 3647 format pre-ballot

On 1/12/2023 7:27 μ.μ., Aaron Gable wrote: It's also worth noting that the Baseline Requirements also diverge from RFC 3647 in this way: for example, Section 1.5 of RFC 3647 is concerned with the contact information of the group /administering the CP/CPS/, while Section 1.5(.2) of the BRs is

Re: [Servercert-wg] SC-065: Convert EVGs into RFC 3647 format pre-ballot

Hi Tim, None of the IETF standards set policy unless they are invited by some policy authority :) The BRs set such policy and "import" some documents, such as RFC 5280, 3647 and others. The BRs in section 1.1 state: These Requirements do not address all of the issues relevant to the

Re: [Servercert-wg] SC-065: Convert EVGs into RFC 3647 format pre-ballot

Inigo, As I am working to migrate the EV Guidelines into the EV Code Signing Baseline Requirements I took a look at the mapping you provided for the EV Guidelines and noticed that you are proposing migration of EVG section 11.1 into section 3.2.1. This particular section is labeled "Method

[Servercert-wg] Fwd: Server Certificate Working Group Agenda – 26 October 2023

Forwarding to the SCWG public list for consistency with section 5.2 of the Bylaws. Dimitris. Forwarded Message Subject:Re: Server Certificate Working Group Agenda – 26 October 2023 Date: Mon, 23 Oct 2023 23:05:48 + From: Kiran Tummala To:

Re: [Servercert-wg] Voting period begins: Ballot SC-066: Fall 2023 Clean-up v2

or Document History,/ * /The table with Relevant Dates./ Dimitris. On 19/10/2023 6:05 μ.μ., Dimitris Zacharopoulos (HARICA) via Servercert-wg wrote: On 19/10/2023 4:51 μ.μ., Inigo Barreira wrote: I disagree. That's unfortunate because the language in the Bylaws seems unambiguous. It doesn't

Re: [Servercert-wg] Voting period begins: Ballot SC-066: Fall 2023 Clean-up v2

On 19/10/2023 4:51 μ.μ., Inigo Barreira wrote: I disagree. That's unfortunate because the language in the Bylaws seems unambiguous. It doesn't say that the Chair is allowed to make /any/ minor change but has an explicit set of changes. Even changing a bulleted list into a numbered list

Re: [Servercert-wg] Voting period begins: Ballot SC-066: Fall 2023 Clean-up v2

On 19/10/2023 2:55 μ.μ., Inigo Barreira wrote: Well, my interpretation is that this is not changing the ballot itself, the redline still remains the same (there´s no change in that redline) and only if this ballot passes, at the end, and before publishing, and considered section 2.4, item

Re: [Servercert-wg] Voting period begins: Ballot SC-066: Fall 2023 Clean-up v2

On 19/10/2023 12:43 μ.μ., Inigo Barreira via Servercert-wg wrote: The voting period for this ballot has started. Note that Inconsistent document formatting (Markdown vs PDF) · Issue #462 · cabforum/servercert (github.com) will be also

Re: [Servercert-wg] Ballot SC-066: Fall 2023 Clean-up (voting period)

Unfortunately that is not an immutable link. I searched the internal wiki and found some old instructions for how to do this. You can also check out previous ballots submitted. This is also a good time to revisit the "ballot

Re: [Servercert-wg] Ballot SC-066: Fall 2023 Clean-up (voting period)

Hi Inigo, Please provide an immutable redline link directly pointing to GitHub. Your antivirus software is tampering with the URL. Thanks, Dimitris. On 9/10/2023 7:43 μ.μ., Inigo Barreira via Servercert-wg wrote: This ballot proposes updates to the Baseline Requirements for the Issuance

[Servercert-wg] Final SCWG agenda - Thursday, September 14, 2023 at 11:30 am Eastern Time

Forwarding to the correct public mailing list. Forwarded Message Subject: [cabfpub] [cabfman] [EXTERNAL] Final SCWG agenda - Thursday, September 14, 2023 at 11:30 am Eastern Time Date: Thu, 14 Sep 2023 06:20:25 + From: Dustin Hollenback via Public Reply-To: Dustin

Re: [Servercert-wg] Proposal to update logging requirements

Without agreeing with some parts of the justification around OCSP, I support the proposed changes and I believe they capture a fair meaning of Firewall and router "activities". I assume that the original authors couldn't decide on a minimum list of specific events that should be kept by CAs

Re: [Servercert-wg] SC-065: Convert EVGs into RFC 3647 format pre-ballot

Hi Inigo, You can take some guidance from previous successful efforts to convert existing documents into RFC 3647 format. The latest attempt was in the Code Signing BRs conversion in May 2022. Check out the mapping document and the comments in the ballot discussion period

Re: [Servercert-wg] [secdir] Secdir last call review of draft-gutmann-testkeys-04

Hi Tim, On 18/7/2023 5:59 μ.μ., Tim Hollebeek via Servercert-wg wrote: Part of the problem here is a lack of a shared understanding of what it means to bind a keypair to an identity. It’s perfectly reasonable to argue that a certification authority’s only role is to verify the identity