Re: [Servercert-wg] Discussion Period Begins | SC-079 - Allow more than one Certificate Policy in a Cross-Certified Subordinate CA Certificate

[Corey Bonnell via Servercert-wg]

Sorry, case of the Fridays. The comment is pending because I didn't submit
the review yet (so no one could see it). I went ahead and did that now.

 

From: Servercert-wg  On Behalf Of Corey
Bonnell via Servercert-wg
Sent: Friday, September 20, 2024 11:36 AM
To: Paul van Brouwershaven ; CA/B Forum
Server Certificate WG Public Discussion List 
Subject: Re: [Servercert-wg] Discussion Period Begins | SC-079 - Allow more
than one Certificate Policy in a Cross-Certified Subordinate CA Certificate

 

I commented on the Github PR last week, but the comment is still pending:
the first sentence of 7.1.2.2.6 should be changed to remove "If present", as
cross certificates must always include the certificatePolicies extension.
The "if present" stipulation was originally added to address the Root CA
certificate case, where the omission of the certificatePolicies extension is
encouraged.

 

Thanks,

Corey

 

From: Servercert-wg mailto:servercert-wg-boun...@cabforum.org> > On Behalf Of Paul van
Brouwershaven via Servercert-wg
Sent: Friday, September 20, 2024 4:03 AM
To: CA/B Forum Server Certificate WG Public Discussion List
mailto:servercert-wg@cabforum.org> >
Subject: [Servercert-wg] Discussion Period Begins | SC-079 - Allow more than
one Certificate Policy in a Cross-Certified Subordinate CA Certificate

 

### Purpose of the Ballot

 

This ballot duplicates the content of section 7.1.2.10.5 (CA Certificate
Certificate Policies) into section 7.1.2.2 (Cross-Certified Subordinate CA
Certificate Profile) as section 7.1.2.2.6 (Cross-Certified Subordinate CA
Certificate Certificate Policies), modifying the requirement from "MUST
contain exactly one Reserved Certificate Policy Identifier" to "MUST include
at least one Reserved Certificate Policy Identifier. If any Subscriber
Certificates will chain up directly to the Certificate issued under this
Certificate Profile, this Cross-Certified Subordinate CA Certificate MUST
contain exactly one Reserved Certificate Policy Identifier". This change
allows the inclusion of multiple Reserved Certificate Policy Identifiers in
a Cross-Certified Subordinate CA Certificate, except when any Subscriber
Certificates chain up directly to the Certificate issued under this
Certificate Profile.

 

Additionally, the description of the `policyIdentifier` contents was updated
for clarification in both sections.

 

The following motion has been proposed by Paul van Brouwershaven (Entrust)
and endorsed by Ben Wilson (Mozilla) and Thomas Zermeno (SSL.com).

 

GitHub pull request for this ballot:
https://github.com/cabforum/servercert/pull/544 

 

### Motion begins

 

MODIFY the "Baseline Requirements for the Issuance and Management of
Publicly-Trusted TLS Server Certificates" ("TLS Baseline Requirements")
based on Version 2.0.7 as specified in the following redline:

 

-
https://github.com/cabforum/servercert/compare/ba28d04894d69c8fac62850b9d0de
5061658c7c5...20ac9adc0f9620f5b361c96c1041404432e7fa47 

 

### Motion ends

 

This ballot proposes a Final Maintenance Guideline. The procedure for
approval of this ballot is as follows:

 

Discussion (7+ days)

 

- Start time: 2024-09-20 08:00 UTC

- End time: 2024-09-27 08:00 UTC

 

Vote for approval (7 days)

 

- Start time: TBC

- End time: TBC

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. 



smime.p7s
Description: S/MIME cryptographic signature
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

Re: [Servercert-wg] Discussion Period Begins | SC-079 - Allow more than one Certificate Policy in a Cross-Certified Subordinate CA Certificate

[Corey Bonnell via Servercert-wg]

I commented on the Github PR last week, but the comment is still pending:
the first sentence of 7.1.2.2.6 should be changed to remove "If present", as
cross certificates must always include the certificatePolicies extension.
The "if present" stipulation was originally added to address the Root CA
certificate case, where the omission of the certificatePolicies extension is
encouraged.

 

Thanks,

Corey

 

From: Servercert-wg  On Behalf Of Paul
van Brouwershaven via Servercert-wg
Sent: Friday, September 20, 2024 4:03 AM
To: CA/B Forum Server Certificate WG Public Discussion List

Subject: [Servercert-wg] Discussion Period Begins | SC-079 - Allow more than
one Certificate Policy in a Cross-Certified Subordinate CA Certificate

 

### Purpose of the Ballot

 

This ballot duplicates the content of section 7.1.2.10.5 (CA Certificate
Certificate Policies) into section 7.1.2.2 (Cross-Certified Subordinate CA
Certificate Profile) as section 7.1.2.2.6 (Cross-Certified Subordinate CA
Certificate Certificate Policies), modifying the requirement from "MUST
contain exactly one Reserved Certificate Policy Identifier" to "MUST include
at least one Reserved Certificate Policy Identifier. If any Subscriber
Certificates will chain up directly to the Certificate issued under this
Certificate Profile, this Cross-Certified Subordinate CA Certificate MUST
contain exactly one Reserved Certificate Policy Identifier". This change
allows the inclusion of multiple Reserved Certificate Policy Identifiers in
a Cross-Certified Subordinate CA Certificate, except when any Subscriber
Certificates chain up directly to the Certificate issued under this
Certificate Profile.

 

Additionally, the description of the `policyIdentifier` contents was updated
for clarification in both sections.

 

The following motion has been proposed by Paul van Brouwershaven (Entrust)
and endorsed by Ben Wilson (Mozilla) and Thomas Zermeno (SSL.com).

 

GitHub pull request for this ballot:
https://github.com/cabforum/servercert/pull/544 

 

### Motion begins

 

MODIFY the "Baseline Requirements for the Issuance and Management of
Publicly-Trusted TLS Server Certificates" ("TLS Baseline Requirements")
based on Version 2.0.7 as specified in the following redline:

 

-
https://github.com/cabforum/servercert/compare/ba28d04894d69c8fac62850b9d0de
5061658c7c5...20ac9adc0f9620f5b361c96c1041404432e7fa47 

 

### Motion ends

 

This ballot proposes a Final Maintenance Guideline. The procedure for
approval of this ballot is as follows:

 

Discussion (7+ days)

 

- Start time: 2024-09-20 08:00 UTC

- End time: 2024-09-27 08:00 UTC

 

Vote for approval (7 days)

 

- Start time: TBC

- End time: TBC

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. 



smime.p7s
Description: S/MIME cryptographic signature
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

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

[Corey Bonnell via Servercert-wg]

 

*   Linting software has not always had a great track record of applying 
new lints (based on new requirements) only to certificates issued after a 
certain date. Running a new linting tool over old certificates frequently 
raises warnings or errors which were not actually errors at the time of 
issuance. Zlint has support for this behavior, but it is not used consistently 
across all lints in their corpus. A quick glance at pkilint's source does not 
seem to show any support for this behavior, but I easily could be wrong.

 

In addition to these points, maintaining accuracy of the evolution of 
requirements changes incurs a rather significant increase in software 
complexity. None of the linter projects suffer from an excess of engineering 
resources, so I think that the limited available resources should first be 
spent on ensuring that linters are up to date with the current requirements and 
adding new features. Maintaining fidelity with historical versions of the 
requirements is a “nice-to-have” but not needed, in my opinion. For this 
reason, support for (in)effective dates of requirements was not introduced to 
pkilint until support for SC-72 was added.

 

*   Some CAs have very large certificate corpuses, e.g. Let's Encrypt has 
400 million currently-valid certificates. Some linting tools are very slow, 
e.g. pkilint's `lint_pkix_cert` takes 300ms per run. At that rate, re-linting 
LE's whole corpus would take four years. I'm sure there are speedups to be had, 
but they'd have to be several orders of magnitude to make that feasible.

 

The vast majority of that 300ms is spent spinning up the linter process, so 
there are major performance gains to be had by running the linter as a server 
where the startup cost is incurred only once and not for every certificate. 
This approach is taken by KeyFactor’s “Lint Eastwood” project, Sectigo’s 
pkimetal, and the pkilint REST API. Nonetheless, I agree that recommending 
re-linting the corpus of all valid certificates on every linter release is 
potentially resource intensive and may not yield any useful results due to the 
reasons outlined above about maintaining historical fidelity of requirements 
changes.

 

Thanks,

Corey

 

From: Servercert-wg  On Behalf Of Aaron 
Gable via Servercert-wg
Sent: Friday, May 31, 2024 5:20 PM
To: Dimitris Zacharopoulos (HARICA) ; CA/B Forum Server 
Certificate WG Public Discussion List 
Subject: Re: [Servercert-wg] Ballot SC-75 - Pre-sign linting

 

On Wed, May 29, 2024 at 10:57 PM Dimitris Zacharopoulos (HARICA) via 
Servercert-wg mailto:servercert-wg@cabforum.org> > 
wrote:

While we're in this vein, it would also be useful to add a recommendation for 
CAs to lint all non-expired, non-revoked certificates whenever they install an 
update of their linting software.

*   "The CA SHOULD perform Linting on the corpus of its non-expired, 
non-revoked Subscriber Certificates whenever it updates the Linting software".

What do people think about these proposals?

 

Just chiming in to say that I don't love this proposal, for a few reasons.

 

1. Linting software has not always had a great track record of applying new 
lints (based on new requirements) only to certificates issued after a certain 
date. Running a new linting tool over old certificates frequently raises 
warnings or errors which were not actually errors at the time of issuance. 
Zlint has support for this behavior, but it is not used consistently across all 
lints in their corpus. A quick glance at pkilint's source does not seem to show 
any support for this behavior, but I easily could be wrong.

 

2. Some CAs have very large certificate corpuses, e.g. Let's Encrypt has 400 
million currently-valid certificates. Some linting tools are very slow, e.g. 
pkilint's `lint_pkix_cert` takes 300ms per run. At that rate, re-linting LE's 
whole corpus would take four years. I'm sure there are speedups to be had, but 
they'd have to be several orders of magnitude to make that feasible.

 

3. Any large systems engineer knows that streaming processing and batch 
processing infrastructure are very different, with wholly different software 
and hardware setups to make each efficient. I think it is much more important 
to incentivize stream-linting (i.e. as issuance happens), and that it would be 
counterproductive to require CAs to invest in both at the same time.

 

Thanks,

Aaron



smime.p7s
Description: S/MIME cryptographic signature
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

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

[Corey Bonnell via Servercert-wg]

Hi Clint,

> My understanding is that the intent was indeed to restrict these to HTTP 
> specifically.

 

That matches my understanding as well.

 

> I’m not convinced 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.

 

The S/MIME BRs use the term “scheme” to explicitly specify when only plaintext 
HTTP (and not HTTPS) URIs are allowed. If the consensus is that a change in the 
TLS BRs is warranted, then I think using this term would better clarify the 
requirements regarding the mandated use of plaintext HTTP.

 

Thanks,

Corey

 

From: Servercert-wg  On Behalf Of Clint 
Wilson via Servercert-wg
Sent: Tuesday, April 30, 2024 5:53 PM
To: Dimitris Zacharopoulos (HARICA) ; ServerCert CA/BF 

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

 

Hi Dimitris,

 

My understanding is that the intent was indeed to restrict these to HTTP 
specifically. That is, the phrase “the only URLS present MUST be HTTP URLs” is 
intended to preclude the use of HTTPS, and not just to indicate that any scheme 
which relies on the Hypertext Transfer Protocol can be used.

 

Presumably when 5280 was drafted, the authors were aware of the updates 2817 
made to 2616, but chose not to reference those updates. Even if not, I concur 
with Ryan and my recollection is also that the discussion during SC-62’s 
formation did include this topic with the consensus (at that time) being that 
some fields would be restricted to using only HTTP URIs.

 

To your original questions:

Do Members agree with that interpretation? 

 

Yes






If this is the correct interpretation, would it be considered a violation of 
the BRs if a CA or end-entity certificate contains https:// URL in the 
id-ad-caIssuers accessMethod ? 

 

Yes, at least for certificates issued after SC-62 went into effect (maybe also 
for those prior, I just haven’t looked).






I'm afraid that this might not be as clear in the BRs as it should be, so if 
people agree with the above, we should probably update section 7.1.2.7.7 

  (and possibly other parts) to explicitly state that the allowed scheme is 
"http" and not "https", just like we do for the CRLDP in section 7.1.2.11.2 

  . 

 

I’m not convinced 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 Servercert-wg 
mailto:servercert-wg@cabforum.org> > wrote:

 

Hi Ryan,

The question is not between HTTP vs FTP vs LDAP but specifically for "HTTP URL" 
that could have two schemes "http" and "https".

RFC 2616 (June 1999) included only "http" and was updated in May 2000 by RFC 
2817 

  to include TLS Within HTTP/1.1 ("https").

I hope this clarifies the issue.


Dimitris.

On 25/4/2024 3:29 μ.μ., Ryan Dickson via Servercert-wg wrote:

It's my understanding that the intent of the updates made in SC-62 were to 
prohibit any non-HTTP URI. This was discussed in:

 

1) at least one historical GitHub discussion 

  (referenced in ballot preamble 

 ):

 

*   "authorityInformationAccess: This is a new requirement.

*   BRs 7.1.2.2 (c) notes that it SHOULD contain the HTTP URL of the 
Issuing CA's certificate and MAY contain the HTTP URL of the Issuing CA's OCSP 
responder.
*

Re: [Servercert-wg] IDNA2003 vs IDNA2008 usage

[Corey Bonnell via Servercert-wg]

Hi Martijn,

The same Punycode algorithm as defined in RFC 3492 is used by IDNA2003, 2008, 
and more to convey Unicode code points in domain labels in a way that conforms 
to the LDH syntax. The BRs currently require that any labels that are prefixed 
with “xn—” contain valid Punycode-encoded values (the defined term “P-label” 
was created to denote this type of label). Given that IDNA2008 “A-labels” which 
may contain code points that are not allowed in IDNA2003 (or other deviations 
from IDNA2003) are valid Punycode, such values are allowed by the BRs as valid 
P-labels.

 

This flexibility in allowing differing IDNA standards in domain labels was an 
explicit design decision of SC48v2, as there was much variation between 
browsers and domain registries in terms of conformance to the various IDNA 
standards.

 

Thanks,

Corey

 

From: Servercert-wg  On Behalf Of Martijn 
Katerbarg via Servercert-wg
Sent: Tuesday, March 19, 2024 5:12 AM
To: CA/B Forum Server Certificate WG Public Discussion List 

Subject: [Servercert-wg] IDNA2003 vs IDNA2008 usage

 

All,

 

We’ve recently become aware that some CAs have issued certificates containing 
punycode encoded domain labels compatible with IDNA2008, that are not 
compatible with IDNA2003.

 

Our own interpretation is that IDNA2008 is currently not permitted. While the 
LDH, Non-Reserved LDH and XN label definitions reference RFC 5890, they only 
quote a very specific part of it. Meanwhile the P-Label definition directly 
references RFC3492 for encoding. Likewise RFC5280 which the BRs require 
adherence to, both reference IDNA2003 (RFC3490). (Side-note, I believe RFC9549 
aims to rectify the issue with RFC5280)

 

As a note, ballot SC48v2 updated the language to the current definition.

 

I’m looking for the opinions of this group as to their interpretations, as well 
as opinions if we indeed want to allow IDNA2008 and make this clear within the 
language.

 

Regards,

 

Martijn



smime.p7s
Description: S/MIME cryptographic signature
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

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

[Corey Bonnell via Servercert-wg]

Hi Dimitris,

I’d be happy to endorse and help flesh out the language.

 

Thanks,

Corey

 

From: Servercert-wg  On Behalf 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 

  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,
Dimitris.



smime.p7s
Description: S/MIME cryptographic signature
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

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

[Corey Bonnell via Servercert-wg]

DigiCert votes YES on SC-65v2.

 

While the ballot motion contains a potentially confusing redline link, it
does not affect the actual text changes introduced by the ballot.
Additionally, the reformat proposed by this ballot is valuable in getting us
closer to consistently formatted documents, so it is good to not delay this
work further.

 

Moving forward, it would be useful to develop guidance for ballot authors on
how redline links should be created to ensure that proposed changes are
clearly communicated.

 

Thanks,

Corey

 

From: Servercert-wg  On Behalf Of Inigo
Barreira via Servercert-wg
Sent: Monday, March 4, 2024 10:34 AM
To: CA/B Forum Server Certificate WG Public Discussion List

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

 

Summary: 

The Extended Validation Certificates guidelines (EVGs) were developed and
written in a specific format. Since then, the RFC 3647 has been the basis
(and the de-facto standard) for the CA/Browser Forum to develop other
documents.

This ballot aims to update the EVGs to follow the RFC 3647 format without
changing any content, just moving current sections to those defined in the
RFC 3647. There are no normative requirements changes.

This change also affects the Baseline Requirements for TSL certificates
(BRs) which needs to point to the new sections of the EVGs. Both documents
will be updated according to the latest version published.

This ballot is proposed by Iñigo Barreira (Sectigo) and endorsed by Pedro
Fuentes (OISTE) and Ben Wilson (Mozilla).

--- Motion Begins ---

This ballot modifies the “Baseline Requirements for the Issuance and
Management of Publicly-Trusted TLS Certificates" ("TLS Baseline
Requirements"), based on Version 2.0.2 and the “Guidelines for the Issuance
and Management of Extended Validation Certificates” (EVGs) based on Version
1.8.0. 

MODIFY the TLS EVGs and BRs as specified in the following Redline:

 
 Comparing
90a98dc7c1131eaab01af411968aa7330d315b9b...dedeebfe036fa5a6f0d7ae985ea08317b
a60b8cb · cabforum/servercert (github.com)

--- Motion Ends ---

This ballot proposes a Final Maintenance Guideline for the BRs and EVGs. The
procedure for approval of this ballot is as follows:

Discussion (at least 7 days)

1.  Start time: 2024-02-20 17:00:00 UTC
2.  End time: not before 2024-03-04 15:00:00 UTC

Vote for approval (7 days)

1.  Start time: 2024-03-04 15:30:00 UTC
2.  End time: 2024-03-11 15:30:00 UTC

 



smime.p7s
Description: S/MIME cryptographic signature
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

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

[Corey Bonnell via Servercert-wg]

DigiCert votes YES to SC-69v3.

 

Thanks,

Corey

 

From: Servercert-wg  On Behalf Of Martijn 
Katerbarg via Servercert-wg
Sent: Monday, March 4, 2024 5:59 AM
To: CA/B Forum Server Certificate WG Public Discussion List 

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

 

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 proposed by Martijn Katerbarg (Sectigo) and endorsed by Daniel 
Jeffery (Fastly) and Ben Wilson (Mozilla).

--- Motion Begins ---

This ballot modifies the “Baseline Requirements for the Issuance and Management 
of Publicly-Trusted Certificates" ("Baseline Requirements"), based on Version 
2.0.2.

MODIFY the Baseline Requirements as specified in the following Redline:  

 
https://github.com/cabforum/servercert/compare/41f01640748fa612386f8b1a3031cd1bff3d4f35...d5bd141e14de098ff00c10de7cf500668cbc6843

--- Motion Ends ---

This ballot proposes a Final Maintenance Guideline. The procedure for approval 
of this ballot is as follows:

Discussion (at least 7 days)

1.  Start time: 2024-02-26 07:00:00 UTC
2.  End time: 2024-03-04 11:00:00 UTC

Vote for approval (7 days)

1.  Start time: 2024-03-04 11:00:00 UTC
2.  End time: 2024-03-11 11:00:00 UTC

 

 



smime.p7s
Description: S/MIME cryptographic signature
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

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

[Corey Bonnell via Servercert-wg]

Hi Inigo,

It appears the hyperlink I provided doesn’t immediately highlight the line
(you have to go digging for it). Perhaps explaining it would be easier:

 

EVG version 1.8.0, section 9.8.2 says:

“where the subfields have the same values, meanings, and restrictions
described in Section 9.2.8.

The CA SHALL validate the contents using the requirements in Section 9.2.8.”

 

Section 9.2.8 is “Subject Organization Identifier Field”.

 

This draft has in section 7.1.2.2:

“where the subfields have the same values, meanings, and restrictions
described in [Section
7.1.4.2.1](#71428-subject-organization-identifier-field). The CA SHALL
validate the contents using the requirements in [Section
7.1.4.2.1](#71428-subject-organization-identifier-field).”

 

Section 7.1.4.2.1 is  “Subject Organization Name Field”. This is not
correct, as it needs to be a reference to section 7.1.4.2.8. It looks like
the link (which is informative)  was updated to correctly point to
7.1.4.2.8, but the actual text of the document (which is normative)
specifies the incorrect section number.

 

Thanks,

Corey

 

From: Inigo Barreira  
Sent: Friday, February 16, 2024 12:40 PM
To: Corey Bonnell ; CA/B Forum Server
Certificate WG Public Discussion List 
Subject: RE: [Servercert-wg] [Discussion Period Begins]: SC65: Convert EVGs
into RFC 3647 format

 

Hi Corey,

 

No worries for this late feedback. I´ll try to address it anyway

 

1.  Sorry but I don´t see that under line 1303 (I see CRL frequency) but
in any case, as said I haven´t changed anything, so if it´s something that
needs to be addressed because it´s misleading, we could do it in another
ballot. If the issue is that I changed something inadvertently, please let
me know where it is exactly because I can´t find it. I assume, in any case,
that are you referring to “current” section 9.2.8?
2.  Yes, this ballot will be updated with the latest version derived
from SC68, so will include that change. Currently is under review period and
finishes in 2 weeks. If this SC65 is approved, it will be updated based on
that new version. The issue is that at the time of sending, you can only
work with the current version.
3.  Well, I think I indicated somehow by saying “…without changing any
content, just moving current sections…” but it´s not as formal as your
suggestion. But in any case, there´s no normative requirement changes. No
new text has been added not any other update of the current text.

 

Regards

 

De: Corey Bonnell mailto:corey.bonn...@digicert.com> > 
Enviado el: viernes, 16 de febrero de 2024 15:46
Para: Inigo Barreira mailto:inigo.barre...@sectigo.com> >; CA/B Forum Server Certificate WG
Public Discussion List mailto:servercert-wg@cabforum.org> >
Asunto: RE: [Servercert-wg] [Discussion Period Begins]: SC65: Convert EVGs
into RFC 3647 format

 

Hi Inigo,

I did a cursory review of the draft ballot and have a few comments:

 

1.  Line 1303 indicates that the values of the
CABFOrganizationIdentifier extension MUST be derived from the
OrganizationName attribute as opposed to the OrganizationIdentifier
attribute:
https://github.com/cabforum/servercert/compare/41f01640748fa612386f8b1a3031c
d1bff3d4f35..65b69fe0ab5365a002c3d4b668d3f2ab81079411?diff=split

&w=#diff-f7368cf58de0586cb0ad80e242205ab3272314af71f4115b99187f49521da529R13
03
2.  The changes in Appendix H introduced by SC-68 (to allow EL and XI in
the VAT Registration Scheme) need to be contemplated in accordance with
Bylaws 2.4 (10). Depending on the urgency of this ballot, it might be easier
to wait until SC-68 (presumably) clears IPR and is published before
initiating voting. 
3.  Are there any normative requirements changes introduced in this
ballot? If there are none, it would be useful to indicate that there are no
normative requirements changes in the ballot preamble so that the intent of
the language changes is clear.

 

Thanks,

Corey

 

From: Servercert-wg mailto:servercert-wg-boun...@cabforum.org> > On Behalf Of Inigo Barreira
via Servercert-wg
Sent: Friday, February 9, 2024 8:30 AM
To: CA/B Forum Server Certificate WG Public Discussion List
mailto:servercert-wg@cabforum.org> >
Subject: [Servercert-wg] [Discussion Period Begins]: SC65: Convert EVGs into
RFC 3647 format

 

Summary: 

The Extended Validation Certificates guidelines (EVGs) were developed and
written in a specific format. Since then, the RFC 3647 has been the basis
(and the de-facto standard) for the CA/Browser Forum to develop other
documents.

This ballot aims to update the EVGs to follow the RFC 3647 format without
changing any content, just moving current sections to those defined in the
RFC 3647. This change also affects the Baseline Requirements for TSL
certificates (BRs) which needs to point

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

[Corey Bonnell via Servercert-wg]

Also, apologies for sending this feedback late. I had intended to review and
send earlier this week, but I got bogged down with a few other urgent
matters and didn’t have a chance to review until this AM.

 

From: Servercert-wg  On Behalf Of Corey
Bonnell via Servercert-wg
Sent: Friday, February 16, 2024 9:46 AM
To: Inigo Barreira ; CA/B Forum Server
Certificate WG Public Discussion List 
Subject: Re: [Servercert-wg] [Discussion Period Begins]: SC65: Convert EVGs
into RFC 3647 format

 

Hi Inigo,

I did a cursory review of the draft ballot and have a few comments:

 

1.  Line 1303 indicates that the values of the
CABFOrganizationIdentifier extension MUST be derived from the
OrganizationName attribute as opposed to the OrganizationIdentifier
attribute:
https://github.com/cabforum/servercert/compare/41f01640748fa612386f8b1a3031c
d1bff3d4f35..65b69fe0ab5365a002c3d4b668d3f2ab81079411?diff=split
<https://url.avanan.click/v2/___https:/github.com/cabforum/servercert/compar
e/41f01640748fa612386f8b1a3031cd1bff3d4f35..65b69fe0ab5365a002c3d4b668d3f2ab
81079411?diff=split&w=%23diff-f7368cf58de0586cb0ad80e242205ab3272314af71f411
5b99187f49521da529R1303___.YXAzOmRpZ2ljZXJ0OmE6bzo0YWZhNzQyMWRjOTYwYzY4NjVkN
TA3Zjg3ZTBkMjI2NTo2OjA2NmQ6MjUxMzgzNTM4YzY4NmRhNzQwZWM0NjU2NDllMWRlMTBiYmJhN
2VlMzI1YTVkZjcyYjQ5MjZiODU5N2M1NDE3MTpoOkY>
&w=#diff-f7368cf58de0586cb0ad80e242205ab3272314af71f4115b99187f49521da529R13
03
2.  The changes in Appendix H introduced by SC-68 (to allow EL and XI in
the VAT Registration Scheme) need to be contemplated in accordance with
Bylaws 2.4 (10). Depending on the urgency of this ballot, it might be easier
to wait until SC-68 (presumably) clears IPR and is published before
initiating voting. 
3.  Are there any normative requirements changes introduced in this
ballot? If there are none, it would be useful to indicate that there are no
normative requirements changes in the ballot preamble so that the intent of
the language changes is clear.

 

Thanks,

Corey

 

From: Servercert-wg mailto:servercert-wg-boun...@cabforum.org> > On Behalf Of Inigo Barreira
via Servercert-wg
Sent: Friday, February 9, 2024 8:30 AM
To: CA/B Forum Server Certificate WG Public Discussion List
mailto:servercert-wg@cabforum.org> >
Subject: [Servercert-wg] [Discussion Period Begins]: SC65: Convert EVGs into
RFC 3647 format

 

Summary: 

The Extended Validation Certificates guidelines (EVGs) were developed and
written in a specific format. Since then, the RFC 3647 has been the basis
(and the de-facto standard) for the CA/Browser Forum to develop other
documents.

This ballot aims to update the EVGs to follow the RFC 3647 format without
changing any content, just moving current sections to those defined in the
RFC 3647. This change also affects the Baseline Requirements for TSL
certificates (BRs) which needs to point to the new sections of the EVGs.

This ballot is proposed by Iñigo Barreira (Sectigo) and endorsed by Pedro
Fuentes (OISTE) and Ben Wilson (Mozilla).

--- Motion Begins ---

This ballot modifies the “Baseline Requirements for the Issuance and
Management of Publicly-Trusted TLS Certificates" ("TLS Baseline
Requirements"), based on Version 2.0.2 and the “Guidelines for the Issuance
and Management of Extended Validation Certificates” (EVGs) based on Version
1.8.0. 

MODIFY the TLS EVGs and BRs as specified in the following Redline:

 
<https://url.avanan.click/v2/___https:/github.com/cabforum/servercert/compar
e/90a98dc7c1131eaab01af411968aa7330d315b9b...65b69fe0ab5365a002c3d4b668d3f2a
b81079411___.YXAzOmRpZ2ljZXJ0OmE6bzoyZmIwNGQzNmUyMGY4MzM5OTU3NWYwNDM0NzI3ZDM
wYzo2OmYxNTI6MTY2NDE3Njk1NjhmMDhkNjFiOGZmZDk3OWNiNWQwOTkwZmUwMTk3MjFjYTA3ODA
xMDAyNTExYjI0MTM2OTdiMDpoOkY> Comparing
90a98dc7c1131eaab01af411968aa7330d315b9b...65b69fe0ab5365a002c3d4b668d3f2ab8
1079411 · cabforum/servercert (github.com)

--- Motion Ends ---

This ballot proposes a Final Maintenance Guideline for the BRs and EVGs. The
procedure for approval of this ballot is as follows:

Discussion (at least 7 days)

1.  Start time: 2024-02-09 14:30:00 UTC
2.  End time: not before 2024-02-16 14:30:00 UTC

Vote for approval (7 days)

1.  Start time: TBD
2.  End time: TBD

 



smime.p7s
Description: S/MIME cryptographic signature
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

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

[Corey Bonnell via Servercert-wg]

Hi Inigo,

I did a cursory review of the draft ballot and have a few comments:

 

1.  Line 1303 indicates that the values of the
CABFOrganizationIdentifier extension MUST be derived from the
OrganizationName attribute as opposed to the OrganizationIdentifier
attribute:
https://github.com/cabforum/servercert/compare/41f01640748fa612386f8b1a3031c
d1bff3d4f35..65b69fe0ab5365a002c3d4b668d3f2ab81079411?diff=split

&w=#diff-f7368cf58de0586cb0ad80e242205ab3272314af71f4115b99187f49521da529R13
03
2.  The changes in Appendix H introduced by SC-68 (to allow EL and XI in
the VAT Registration Scheme) need to be contemplated in accordance with
Bylaws 2.4 (10). Depending on the urgency of this ballot, it might be easier
to wait until SC-68 (presumably) clears IPR and is published before
initiating voting. 
3.  Are there any normative requirements changes introduced in this
ballot? If there are none, it would be useful to indicate that there are no
normative requirements changes in the ballot preamble so that the intent of
the language changes is clear.

 

Thanks,

Corey

 

From: Servercert-wg  On Behalf Of Inigo
Barreira via Servercert-wg
Sent: Friday, February 9, 2024 8:30 AM
To: CA/B Forum Server Certificate WG Public Discussion List

Subject: [Servercert-wg] [Discussion Period Begins]: SC65: Convert EVGs into
RFC 3647 format

 

Summary: 

The Extended Validation Certificates guidelines (EVGs) were developed and
written in a specific format. Since then, the RFC 3647 has been the basis
(and the de-facto standard) for the CA/Browser Forum to develop other
documents.

This ballot aims to update the EVGs to follow the RFC 3647 format without
changing any content, just moving current sections to those defined in the
RFC 3647. This change also affects the Baseline Requirements for TSL
certificates (BRs) which needs to point to the new sections of the EVGs.

This ballot is proposed by Iñigo Barreira (Sectigo) and endorsed by Pedro
Fuentes (OISTE) and Ben Wilson (Mozilla).

--- Motion Begins ---

This ballot modifies the “Baseline Requirements for the Issuance and
Management of Publicly-Trusted TLS Certificates" ("TLS Baseline
Requirements"), based on Version 2.0.2 and the “Guidelines for the Issuance
and Management of Extended Validation Certificates” (EVGs) based on Version
1.8.0. 

MODIFY the TLS EVGs and BRs as specified in the following Redline:

 
 Comparing
90a98dc7c1131eaab01af411968aa7330d315b9b...65b69fe0ab5365a002c3d4b668d3f2ab8
1079411 · cabforum/servercert (github.com)

--- Motion Ends ---

This ballot proposes a Final Maintenance Guideline for the BRs and EVGs. The
procedure for approval of this ballot is as follows:

Discussion (at least 7 days)

1.  Start time: 2024-02-09 14:30:00 UTC
2.  End time: not before 2024-02-16 14:30:00 UTC

Vote for approval (7 days)

1.  Start time: TBD
2.  End time: TBD

 



smime.p7s
Description: S/MIME cryptographic signature
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

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

[Corey Bonnell via Servercert-wg]

Hi Dimitris,

I’d be happy to endorse.

 

Thanks,

Corey

 

From: Servercert-wg  On Behalf Of Dimitris 
Zacharopoulos (HARICA) via Servercert-wg
Sent: Monday, January 8, 2024 12:39 PM
To: CA/B Forum Server Certificate WG Public Discussion List 

Subject: [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 ETSI ESI 319 412-1 and 
then the SCWG made several modifications. However, there is an exception for 
Greece specifically for the VAT Registration Scheme that is aligned with 
Article 215 of Council Directive 2006/112/EC 

  that allows Greece to use the country prefix "EL". In practice, Greece uses 
the prefix "EL" to identify itself next to the VAT number of all Legal Entities 
registered/incorporated/established in Greece, and all other European Countries 
use this prefix to identify Greek VAT numbers. You can easily verify this in 
the VIES VAT number validation website 

  where Greece is listed as"EL".

Based on the above, I prepared 
https://github.com/cabforum/servercert/compare/main...dzacharo:servercert:updateVAT
 

  and plan to prepare a ballot to update the EV Guidelines. Mozilla is willing 
to endorse this ballot so I am actually looking for one more endorser.

Please let me know if there are any issues or concerns with this proposal.


Best regards,
Dimitris.



smime.p7s
Description: S/MIME cryptographic signature
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

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

[Corey Bonnell via Servercert-wg]

Hi Inigo,

Comments inline.

 

> the chair of the CWG can perform some changes that do not change anything 
> without requiring a ballot procedure, so I guess there´s nothing to 
> vote/discuss there

 

Perhaps I’m misunderstanding what you’re saying, but changing the 
formatting/content will require a new version of the ballot with associated new 
discussion period and voting period. This should be clear from Bylaws 2.4 (8), 
as modifying arbitrary formatting does not fall within the allowed set of 
post-voting changes that can be performed by the (Vice) Chair.

 

> The change proposed by Ryan is just a simple issue with the format and it´s 
> not changing the content nor anything else.

 

Some members do see the formatting of these documents as significant and will 
vote accordingly. See [1] for a recent example.

 

I agree with Dimitris: if this formatting change is to be included, then the 
ballot redline needs to be updated to incorporate the changes and the 
appropriate commits included in the immutable link. To do otherwise will likely 
result in confusion, as members will be unsure on what they’re voting on.

 

Thanks,

Corey

 

[1] https://lists.cabforum.org/pipermail/cscwg-public/2022-May/000810.html

 

From: Servercert-wg  On Behalf Of Inigo 
Barreira via Servercert-wg
Sent: Thursday, October 19, 2023 7:56 AM
To: Dimitris Zacharopoulos (HARICA) ; CA/B Forum Server 
Certificate WG Public Discussion List 
Subject: Re: [Servercert-wg] Voting period begins: Ballot SC-066: Fall 2023 
Clean-up v2

 

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 8, the chair of the CWG can perform some changes that do not change 
anything without requiring a ballot procedure, so I guess there´s nothing to 
vote/discuss there. The change proposed by Ryan is just a simple issue with the 
format and it´s not changing the content nor anything else.

 

 

De: Dimitris Zacharopoulos (HARICA) mailto:dzach...@harica.gr> > 
Enviado el: jueves, 19 de octubre de 2023 13:26
Para: Inigo Barreira mailto:inigo.barre...@sectigo.com> >; CA/B Forum Server Certificate WG Public 
Discussion List mailto:servercert-wg@cabforum.org> 
>
Asunto: Re: [Servercert-wg] Voting period begins: Ballot SC-066: Fall 2023 
Clean-up v2

 

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.

 

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 included (it´s a format issue 
with no content change).



Inigo,

You started the voting period on a specific ballot that has a specific redline 

 . That means you cannot make any changes without invoking a new 7-days 
discussion period. Unfortunately, since you started the voting period there is 
nothing you can do but either let the ballot fail or withdraw it. Withdrawing a 
ballot is a new addition to the Bylaws in section 2.3 (4)



A proposer may withdraw a ballot containing defective language at any point 
during the voting period 



According to the Bylaws, the voting period ends 7 days after the voting starts, 
so that would be 7 days from TODAY (2023-10-19), which means that the voting 
ends at 2023-10-26. The information at the bottom of the page should have been 
updated.

I'd appreciate a confirmation from at least another person that is familiar 
with the Bylaws about whether my interpretation is accurate or not.


Best regards,
Dimitris.






 

Purpose of Ballot SC-66 v2

 

This ballot proposes updates to the Baseline Requirements for the Issuance and 
Management of Publicly-Trusted Certificates related to the issues and typos 
that have happened due to the different updates of the document. No new 
normative requirements are introduced by the changes in this ballot.

 

Notes: 

1.  The majority of these issues have been documented in GitHub and have 
therefore labeled as cleanup and have been the basis for this update.
2.  Some have been provided by emails to the CABF lists and included in 
this reviewed v

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

[Corey Bonnell via Servercert-wg]

I believe this URL does the trick: 
https://github.com/cabforum/servercert/compare/90a98dc7c1131eaab01af411968aa7330d315b9b...b72da7a87955aed81d14f9fe96ee222098fd4264.

 

As Dimitris mentioned, it’s important that the redline URL uses the specific 
commit hashes to ensure the ballot cannot be modified during or after voting. A 
Pull Request link is not appropriate, as commits can be added to the PR that 
materially change the ballot.

 

Thanks,

Corey

 

From: Servercert-wg  On Behalf Of Dimitris 
Zacharopoulos (HARICA) via Servercert-wg
Sent: Monday, October 9, 2023 1:36 PM
To: Inigo Barreira ; CA/B Forum Server Certificate 
WG Public Discussion List 
Subject: 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 shepherds" idea we talked about in the 
past and create a list of volunteers that can assist in the ballot process for 
things related to GitHub :)


Thanks,
Dimitris.

On 9/10/2023 8:29 μ.μ., Inigo Barreira wrote:

Done

 

De: Dimitris Zacharopoulos (HARICA)   
 
Enviado el: lunes, 9 de octubre de 2023 19:26
Para: Inigo Barreira   
; CA/B Forum Server Certificate WG Public 
Discussion List   

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

 

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.

 

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 and 
Management of Publicly-Trusted Certificates related to the issues and typos 
that have happened due to the different updates of the document. 

 

Notes: 

1.  The majority of these issues have been documented in GitHub and have 
therefore labeled as cleanup and have been the basis for this update.
2.  Some have been provided by emails to the CABF lists and included in 
this reviewed version because were typos.

 

The following motion has been proposed by Iñigo Barreira of Sectigo. And, 
endorsed by Aaron Gable of Let´s Encrypt and Clint Wilson of Apple.

 

— Motion Begins —

 

This ballot modifies the “Baseline Requirements for the Issuance and Management 
of Publicly-Trusted Certificates” (“Baseline Requirements”), based on Version 
2.0.1.

 

MODIFY the Baseline Requirements as specified in the following Pull Request: 

 

 Fall 2023 clean up by barrini · Pull Request #460 · cabforum/servercert 
(github.com)

 

— Motion Ends —

 

 

This ballot proposes a Final Maintenance Guideline. The procedure for approval 
of this ballot is as follows:

 

Discussion (13+ days)

• Start time: 18-09-2023 12:00:00 UTC

• End time: 4-10-2023 12:00:00 UTC

 

Vote for approval (7 days)

• Start time: 09-10-2023 18:00:00 UTC

• End time: 16-10-2023 18:00:00 UTC

 






___
Servercert-wg mailing list
Servercert-wg@cabforum.org  
https://url.avanan.click/v2/___https://lists.cabforum.org/mailman/listinfo/servercert-wg___.YXAzOmRpZ2ljZXJ0OmE6bzpkNDljM2E5ZWFlNTc4Yzk5YWUwNjE1Y2U0OTEzZGNjODo2OmZiZDU6Y2RkZDZkMzRlM2E0MmQ4NjhlMTg3ZjEwOWQ0M2E0M2NlMDY2NGIwMjE1NjRhMmE5ZDMxMjA2NTg0YTMxNzk3Mjp0OkY
 

 

 

 



smime.p7s
Description: S/MIME cryptographic signature
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

[Servercert-wg] DigiCert’s OSS pkilint adds support for CABF Ballot SC-62

[Corey Bonnell via Servercert-wg]

DigiCert releases significant update for its open source linting framework,
pkilint, to support linting certificates against the Ballot SC-62 profiles

Building on the successful release earlier this year of pkilint as
open-source software under the permissive MIT license, DigiCert is pleased
to announce that pkilint 0.9.0 has been released today. This release adds
comprehensive support for linting certificates against the certificate
profiles defined in Ballot SC-62 for the CA/Browser Forum's TLS Baseline
Requirements. In particular, support for linting root certificates,
intermediate certificates, end-entity Subscriber certificates, as well as
OCSP delegated responder certificates is now included.

Pkilint can be easily installed as a Python package that is publicly
available on PyPi (https://pypi.org/project/pkilint/). Installation and
usage instructions are available on the PyPi page for pkilint, or on the
Github repository (https://github.com/digicert/pkilint). 

Ballot SC-62 dramatically increased the clarity surrounding requirements for
the profile of publicly trusted certificates, and we greatly encourage
industry participants to leverage pkilint in their transition strategy to
compliant profiles prior to the Ballot SC-62 effective date.

Bugs or other issues can be reported on the Github repository. Additionally,
we welcome contributions to improve the framework.

Near-term plans for enhancements include support for CRL linting against the
Ballot SC-63 profile. Additionally, work is planned to add an embedded REST
API server for all linters included in the framework so that pkilint can be
more readily integrated into CA issuance pipelines and to boost performance.
Finally, Docker images will be published alongside the Python package for
each release to further ease the upgrade process in CA environments.

If you have any questions or comments, please don't hesitate to reach out.

Thanks,

Corey



smime.p7s
Description: S/MIME cryptographic signature
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

Re: [Servercert-wg] Draft ballot SC-XX: Profiles cleanup ballot

[Corey Bonnell via Servercert-wg]

Hi Wendy,

Do you know if the automatic issuance of such certificates can be disabled, and 
a private PKI be used for infrastructure purposes instead? Based on the 
discussions during the development of the profiles ballot, it was clear that 
private PKI should be used for CA infrastructure. However, prohibiting such use 
on a short timeframe would likely cause migration issues, so such issuance may 
need to continue to be permitted for at least some time.

 

I’m wondering whether it’s feasible to create a “infrastructure certificate" 
profile in the BRs that can allow for the continued issuance of these types of 
certificates while also establishing some guard rails. Do you happen to know 
whether these certificates share a profile that is roughly like one another? I 
personally haven’t used CA software that exhibits this “automatic issuance” 
behavior, so I’ll lean on others who do have experience.

 

Thanks,

Corey

 

From: Wendy Brown - QT3LB-C  
Sent: Friday, July 21, 2023 8:24 AM
To: Corey Bonnell 
Cc: CA/B Forum Server Certificate WG Public Discussion List 

Subject: Re: [Servercert-wg] Draft ballot SC-XX: Profiles cleanup ballot

 

Corey - 

not according to some CA products - these additional certificates are created 
automatically at the time a new CA is established - so if they are not excluded 
those products are no longer eligible for use as Root CAs.  It was my 
understanding that the original language that you are proposing to eliminate 
was put there so these products could continue to be used.




Wendy

 

Wendy Brown

Supporting GSA

FPKIMA Technical Liaison

Protiviti Government Services

703-965-2990 (cell)

 

 

On Fri, Jul 21, 2023 at 8:19 AM Corey Bonnell mailto:corey.bonn...@digicert.com> > wrote:

Hi Wendy,

The intent behind the certificate profiles ballot was that the profile of all 
allowed certificate types issued from a BR-compliant CA were completely 
specified within the BRs. Adding a carve-out to allow the issuance of 
certificates whose profile is not specified and not intended for use outside 
the CA’s infrastructure would seem to go against that goal.

 

Is the use of a private PKI not feasible for these internal infrastructure 
certificates?

 

Thanks,

Corey

 

From: Wendy Brown - QT3LB-C mailto:wendy.br...@gsa.gov> > 
Sent: Wednesday, July 19, 2023 3:54 PM
To: Corey Bonnell mailto:corey.bonn...@digicert.com> >; CA/B Forum Server Certificate WG Public 
Discussion List mailto:servercert-wg@cabforum.org> 
>
Subject: Re: [Servercert-wg] Draft ballot SC-XX: Profiles cleanup ballot

 

I would not like to see #3 exclusion for Root CAs removed

 

Some CA products when a new CA is established, automatically create some 
internal certificates that are necessary for the operation of the CA including 
possibly a key pair used to sign audit logs with a certificate signed by the 
Root CA that can be used to verify the integrity of the logs by verifying the 
signature. In addition to enabling cert-based authentication for trusted roles 
needing to access the CA, including for actions like manually instigating the 
issuance of a subordinate CA certificate or manually issuing a new CRL when 
there has not been a revocation.

 

This change would make it so those products could not be compliant with the 
BRs, even though such certificates would never be seen outside the supporting 
infrastructure.

 

If the rationale is there are no profiles for internal certificates, then I 
suggest a better fix would be to add the word public in the conflicting 
language in 7.1.2, as the internal certificates that have no BR profile should 
never be seen outside the CA's infrastructure. But removing the allowance would 
potentially trigger a non-compliance during an audit.:

“If the CA asserts compliance with these Baseline Requirements, all public 
certificates that it issues MUST comply with one of the following certificate 
profiles, which incorporate, and are derived from RFC

5280.”

 

Thanks,

Wendy

 

Wendy Brown

Supporting GSA

FPKIMA Technical Liaison

Protiviti Government Services

703-965-2990 (cell)

 

 

On Wed, Jul 19, 2023 at 10:16 AM Corey Bonnell via Servercert-wg 
mailto:servercert-wg@cabforum.org> > wrote:

Hello,

While adding support for SC-62 linting for TLS certificates in pkilint, a few 
issues were identified with the current language in section 6 and 7 of the BRs. 
To address these issues, I created a draft ballot on Github. The draft ballot 
text can be viewed here: 
https://github.com/cabforum/servercert/compare/SC63..CBonnell:servercert:sc62-cleanup.

 

Chris Clements of the Chrome team reviewed and offered to endorse, so we’re 
looking for one more endorser to push this ballot forward.

 

Please let me know if you have any feedback on the proposed language or if 
you’d be willing to endorse.

 

Thanks,

Corey

___
Servercert-wg mailing list
Servercert-wg@cabforu

Re: [Servercert-wg] Draft ballot SC-XX: Profiles cleanup ballot

[Corey Bonnell via Servercert-wg]

Hi Wendy,

The intent behind the certificate profiles ballot was that the profile of all 
allowed certificate types issued from a BR-compliant CA were completely 
specified within the BRs. Adding a carve-out to allow the issuance of 
certificates whose profile is not specified and not intended for use outside 
the CA’s infrastructure would seem to go against that goal.

 

Is the use of a private PKI not feasible for these internal infrastructure 
certificates?

 

Thanks,

Corey

 

From: Wendy Brown - QT3LB-C  
Sent: Wednesday, July 19, 2023 3:54 PM
To: Corey Bonnell ; CA/B Forum Server Certificate 
WG Public Discussion List 
Subject: Re: [Servercert-wg] Draft ballot SC-XX: Profiles cleanup ballot

 

I would not like to see #3 exclusion for Root CAs removed

 

Some CA products when a new CA is established, automatically create some 
internal certificates that are necessary for the operation of the CA including 
possibly a key pair used to sign audit logs with a certificate signed by the 
Root CA that can be used to verify the integrity of the logs by verifying the 
signature. In addition to enabling cert-based authentication for trusted roles 
needing to access the CA, including for actions like manually instigating the 
issuance of a subordinate CA certificate or manually issuing a new CRL when 
there has not been a revocation.

 

This change would make it so those products could not be compliant with the 
BRs, even though such certificates would never be seen outside the supporting 
infrastructure.

 

If the rationale is there are no profiles for internal certificates, then I 
suggest a better fix would be to add the word public in the conflicting 
language in 7.1.2, as the internal certificates that have no BR profile should 
never be seen outside the CA's infrastructure. But removing the allowance would 
potentially trigger a non-compliance during an audit.:

“If the CA asserts compliance with these Baseline Requirements, all public 
certificates that it issues MUST comply with one of the following certificate 
profiles, which incorporate, and are derived from RFC

5280.”

 

Thanks,

Wendy

 

Wendy Brown

Supporting GSA

FPKIMA Technical Liaison

Protiviti Government Services

703-965-2990 (cell)

 

 

On Wed, Jul 19, 2023 at 10:16 AM Corey Bonnell via Servercert-wg 
mailto:servercert-wg@cabforum.org> > wrote:

Hello,

While adding support for SC-62 linting for TLS certificates in pkilint, a few 
issues were identified with the current language in section 6 and 7 of the BRs. 
To address these issues, I created a draft ballot on Github. The draft ballot 
text can be viewed here: 
https://github.com/cabforum/servercert/compare/SC63..CBonnell:servercert:sc62-cleanup.

 

Chris Clements of the Chrome team reviewed and offered to endorse, so we’re 
looking for one more endorser to push this ballot forward.

 

Please let me know if you have any feedback on the proposed language or if 
you’d be willing to endorse.

 

Thanks,

Corey

___
Servercert-wg mailing list
Servercert-wg@cabforum.org <mailto:Servercert-wg@cabforum.org> 
https://lists.cabforum.org/mailman/listinfo/servercert-wg



smime.p7s
Description: S/MIME cryptographic signature
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

Re: [Servercert-wg] Draft ballot SC-XX: Profiles cleanup ballot

[Corey Bonnell via Servercert-wg]

Thanks, Inigo. If a list of tables with problematic formatting is created,
I’d be happy to tackle. I’m pretty bad at typesetting, so I’d prefer others
who have a better sense for design to come up with this list.

 

Thanks,

Corey

 

 

 

From: Inigo Barreira  
Sent: Wednesday, July 19, 2023 11:24 AM
To: Inigo Barreira ; CA/B Forum Server
Certificate WG Public Discussion List ; Corey
Bonnell 
Subject: RE: Draft ballot SC-XX: Profiles cleanup ballot

 

This is to fix some table formats, for example, those in sections:
7.1.2.10.2, 7.1.4.2, …

 

De: Servercert-wg mailto:servercert-wg-boun...@cabforum.org> > En nombre de Inigo Barreira
via Servercert-wg
Enviado el: miércoles, 19 de julio de 2023 17:19
Para: Corey Bonnell mailto:corey.bonn...@digicert.com> >; CA/B Forum Server Certificate WG
Public Discussion List mailto:servercert-wg@cabforum.org> >
Asunto: Re: [Servercert-wg] Draft ballot SC-XX: Profiles cleanup ballot

 

CAUTION: This email originated from outside of the organization. Do not
click links or open attachments unless you recognize the sender and know the
content is safe.

 

 
<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.cabf
orum.org%2Fbooks%2Finfrastructure%2Fpage%2Fdocument-markdown-guidelines&data
=05%7C01%7Cinigo.barreira%40sectigo.com%7Cb8c50ea79f7e4679191b08db886b86d7%7
C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638253767650066328%7CUnknown%7CT
WFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
D%7C3000%7C%7C%7C&sdata=mlwTLU2n%2FQJkdYtsPfMxv7kcxz3kBqDOFRgEgjUHMGg%3D&res
erved=0> Document Markdown Guid... | CABF Wiki (cabforum.org)

 

De: Corey Bonnell mailto:corey.bonn...@digicert.com> > 
Enviado el: miércoles, 19 de julio de 2023 17:17
Para: Inigo Barreira mailto:inigo.barre...@sectigo.com> >; CA/B Forum Server Certificate WG
Public Discussion List mailto:servercert-wg@cabforum.org> >
Asunto: RE: Draft ballot SC-XX: Profiles cleanup ballot

 

Hi Inigo,

I haven’t on Infra calls in several months (I have a standing meeting
conflict on Wednesdays, so I’m unable to attend) and I don’t see any GitHub
issue in the servercert repo regarding this issue, so I’m not sure what
problem currently exists regarding table formatting.

 

Do you have any pointer on what we’re looking to fix?

 

Thanks,

Corey

 

From: Inigo Barreira mailto:inigo.barre...@sectigo.com> > 
Sent: Wednesday, July 19, 2023 11:07 AM
To: Corey Bonnell mailto:corey.bonn...@digicert.com> >; CA/B Forum Server Certificate WG
Public Discussion List mailto:servercert-wg@cabforum.org> >
Subject: RE: Draft ballot SC-XX: Profiles cleanup ballot

 

Corey, would it be possible to add to this “profiles cleanup ballot” what
was discussed the other day in the infra SC about the “-“ to format
correctly the tables generated in section 7?

 

De: Servercert-wg < <mailto:servercert-wg-boun...@cabforum.org>
servercert-wg-boun...@cabforum.org> En nombre de Corey Bonnell via
Servercert-wg
Enviado el: miércoles, 19 de julio de 2023 16:17
Para: CA/B Forum Server Certificate WG Public Discussion List <
<mailto:servercert-wg@cabforum.org> servercert-wg@cabforum.org>
Asunto: [Servercert-wg] Draft ballot SC-XX: Profiles cleanup ballot

 

CAUTION: This email originated from outside of the organization. Do not
click links or open attachments unless you recognize the sender and know the
content is safe.

 

Hello,

While adding support for SC-62 linting for TLS certificates in pkilint, a
few issues were identified with the current language in section 6 and 7 of
the BRs. To address these issues, I created a draft ballot on Github. The
draft ballot text can be viewed here:
https://github.com/cabforum/servercert/compare/SC63..CBonnell:servercert:sc6
2-cleanup
<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co
m%2Fcabforum%2Fservercert%2Fcompare%2FSC63..CBonnell%3Aservercert%3Asc62-cle
anup&data=05%7C01%7Cinigo.barreira%40sectigo.com%7Cb8c50ea79f7e4679191b08db8
86b86d7%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638253767650066328%7CUn
known%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX
VCI6Mn0%3D%7C3000%7C%7C%7C&sdata=hlX6jocUlgqJZ7LWjl2vpU78CD5p4yc5h4pBuhWms84
%3D&reserved=0> .

 

Chris Clements of the Chrome team reviewed and offered to endorse, so we’re
looking for one more endorser to push this ballot forward.

 

Please let me know if you have any feedback on the proposed language or if
you’d be willing to endorse.

 

Thanks,

Corey



smime.p7s
Description: S/MIME cryptographic signature
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

Re: [Servercert-wg] Draft ballot SC-XX: Profiles cleanup ballot

[Corey Bonnell via Servercert-wg]

Hi Inigo,

I haven’t on Infra calls in several months (I have a standing meeting
conflict on Wednesdays, so I’m unable to attend) and I don’t see any GitHub
issue in the servercert repo regarding this issue, so I’m not sure what
problem currently exists regarding table formatting.

 

Do you have any pointer on what we’re looking to fix?

 

Thanks,

Corey

 

From: Inigo Barreira  
Sent: Wednesday, July 19, 2023 11:07 AM
To: Corey Bonnell ; CA/B Forum Server
Certificate WG Public Discussion List 
Subject: RE: Draft ballot SC-XX: Profiles cleanup ballot

 

Corey, would it be possible to add to this “profiles cleanup ballot” what
was discussed the other day in the infra SC about the “-“ to format
correctly the tables generated in section 7?

 

De: Servercert-wg < <mailto:servercert-wg-boun...@cabforum.org>
servercert-wg-boun...@cabforum.org> En nombre de Corey Bonnell via
Servercert-wg
Enviado el: miércoles, 19 de julio de 2023 16:17
Para: CA/B Forum Server Certificate WG Public Discussion List <
<mailto:servercert-wg@cabforum.org> servercert-wg@cabforum.org>
Asunto: [Servercert-wg] Draft ballot SC-XX: Profiles cleanup ballot

 

CAUTION: This email originated from outside of the organization. Do not
click links or open attachments unless you recognize the sender and know the
content is safe.

 

Hello,

While adding support for SC-62 linting for TLS certificates in pkilint, a
few issues were identified with the current language in section 6 and 7 of
the BRs. To address these issues, I created a draft ballot on Github. The
draft ballot text can be viewed here:
https://github.com/cabforum/servercert/compare/SC63..CBonnell:servercert:sc6
2-cleanup
<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co
m%2Fcabforum%2Fservercert%2Fcompare%2FSC63..CBonnell%3Aservercert%3Asc62-cle
anup&data=05%7C01%7Cinigo.barreira%40sectigo.com%7C1d763755d99a470daf7908db8
862c446%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638253730006334573%7CUn
known%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX
VCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2Fg6vz%2FftZ0jk8L1wV81JX8r8bQzoKePrrjT1xr3
UNFI%3D&reserved=0> .

 

Chris Clements of the Chrome team reviewed and offered to endorse, so we’re
looking for one more endorser to push this ballot forward.

 

Please let me know if you have any feedback on the proposed language or if
you’d be willing to endorse.

 

Thanks,

Corey



smime.p7s
Description: S/MIME cryptographic signature
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

[Servercert-wg] Draft ballot SC-XX: Profiles cleanup ballot

[Corey Bonnell via Servercert-wg]

Hello,
While adding support for SC-62 linting for TLS certificates in pkilint, a few 
issues were identified with the current language in section 6 and 7 of the BRs. 
To address these issues, I created a draft ballot on Github. The draft ballot 
text can be viewed here: 
https://github.com/cabforum/servercert/compare/SC63..CBonnell:servercert:sc62-cleanup.

Chris Clements of the Chrome team reviewed and offered to endorse, so we're 
looking for one more endorser to push this ballot forward.

Please let me know if you have any feedback on the proposed language or if 
you'd be willing to endorse.

Thanks,
Corey
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg