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

[Wendy Brown - QT3LB-C via Servercert-wg]

OK - then I have a question for all those voting on SC74 (as an Associate
member rep, I do not have a vote)
How do you interpret the proposed new language:
include at least every section and subsection defined in section 6 of RFC
3647

Does this mean:
a) that the section and subsection headers have to exactly match the text
in RFC 3647 including its use of capitalization, or
b) just that the words must be the same or
c) you just have to have the same numbering and the title can be slightly
different as long as it covers the intended content?

Sorry to not have asked this during the discussion period, until I saw the
output of the linter Aaron prepared, it didn't occur to me that anyone
would have interpreted it as the capitalization had to match.

thanks,

Wendy


Wendy Brown

Supporting GSA

FPKIMA Technical Liaison

Protiviti Government Services
703-965-2990 (cell)


On Thu, May 9, 2024 at 10:33 AM Aaron Gable  wrote:

> I think that is a question to be taken up with the authors of SC-74, and
> with the root programs. In the interest of caution, I think this linting
> tool should err on the side of strictness. It is open source, however, so
> you are of course free to modify it for your own preferences.
>
> Aaron
>
>
> On Thu, May 9, 2024, 04:57 Wendy Brown - QT3LB-C 
> wrote:
>
>> Aaron -
>> Can I suggest that maybe the comparison should be done in a case blind
>> fashion?
>> For example, requiring the headers for the subsections of 1.3 to have the
>> second word lower case when it is common practice to refer to Certification
>> Authorities as CAs and Registration Authorities as RAs, etc. just makes the
>> document inconsistent. I understand the goal is to try to make comparisons
>> easier, but requiring all Public Trusted CAs have these style
>> inconsistencies in their own documentation seems like a step too far.
>>
>> thanks,
>>
>> Wendy
>>
>>
>> Wendy Brown
>>
>> Supporting GSA
>>
>> FPKIMA Technical Liaison
>>
>> Protiviti Government Services
>> 703-965-2990 (cell)
>>
>>
>> On Wed, May 8, 2024 at 6:06 PM Aaron Gable via Servercert-wg <
>> servercert-wg@cabforum.org> wrote:
>>
>>> Of course! Done: https://github.com/cabforum/servercert/issues/513
>>>
>>> On Wed, May 8, 2024 at 8:37 AM Dimitris Zacharopoulos (HARICA) <
>>> dzach...@harica.gr> wrote:
>>>
 Thanks Aaron,

 Would it be ok for you to create a GitHub issue
  to identify the
 specific sections that deviate in content? We might tackle that in a
 cleanup ballot. I don't think the capitalization is so much of a concern
 but if others think it is, please speak up :)


 Dimitris.

 On 8/5/2024 1:19 π.μ., Aaron Gable wrote:

 Two notes on this ballot, findings from our process for handling
 upcoming requirements:

 1) Let's Encrypt has created and open-sourced a tool
  for
 linting a CPS to confirm compliance with RFC 3647 Section 6 and Ballot
 SC-074. If you maintain your CPS document in markdown, it should be very
 simple to use or adapt to your particular situation.

 2) The Baseline Requirements themselves do not quite comply with RFC
 3647 Section 6, with several 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 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 3647."*
>
> The intent of this language was to ensure that all CAs' CP and/or CPS
> documents contain a similar structure, making it easier to review and
> compare against the BRs. However, there was some ambiguity as to the 
> actual
> structure that CAs should follow. After several discussions in the SCWG
> Public Mailing List
> 
> and F2F meetings, it was agreed that more clarity should be added to the
> existing requirement, pointing to the outline described in section 6 of 
> RFC
> 3647.
> The following motion has been proposed by Dimitris Zacharopoulos
> (HARICA) and endorsed by Aaron Poulsen (Amazon) and Tim Hollebeek
> (Digicert).
>
> You can view the github pull request representing this ballot here
> .
> Motion Begins
>
> MODIFY the "Baseline Requirements for the Issuance and Management of
> Publicly-Trusted TLS Server Certificates" based on Version 2.0.4 as
> specif

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

[Wendy Brown - QT3LB-C via Servercert-wg]

Aaron -
Can I suggest that maybe the comparison should be done in a case blind
fashion?
For example, requiring the headers for the subsections of 1.3 to have the
second word lower case when it is common practice to refer to Certification
Authorities as CAs and Registration Authorities as RAs, etc. just makes the
document inconsistent. I understand the goal is to try to make comparisons
easier, but requiring all Public Trusted CAs have these style
inconsistencies in their own documentation seems like a step too far.

thanks,

Wendy


Wendy Brown

Supporting GSA

FPKIMA Technical Liaison

Protiviti Government Services
703-965-2990 (cell)


On Wed, May 8, 2024 at 6:06 PM Aaron Gable via Servercert-wg <
servercert-wg@cabforum.org> wrote:

> Of course! Done: https://github.com/cabforum/servercert/issues/513
>
> On Wed, May 8, 2024 at 8:37 AM Dimitris Zacharopoulos (HARICA) <
> dzach...@harica.gr> wrote:
>
>> Thanks Aaron,
>>
>> Would it be ok for you to create a GitHub issue
>>  to identify the specific
>> sections that deviate in content? We might tackle that in a cleanup ballot.
>> I don't think the capitalization is so much of a concern but if others
>> think it is, please speak up :)
>>
>>
>> Dimitris.
>>
>> On 8/5/2024 1:19 π.μ., Aaron Gable wrote:
>>
>> Two notes on this ballot, findings from our process for handling upcoming
>> requirements:
>>
>> 1) Let's Encrypt has created and open-sourced a tool
>>  for
>> linting a CPS to confirm compliance with RFC 3647 Section 6 and Ballot
>> SC-074. If you maintain your CPS document in markdown, it should be very
>> simple to use or adapt to your particular situation.
>>
>> 2) The Baseline Requirements themselves do not quite comply with RFC 3647
>> Section 6, with several 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 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 3647."*
>>>
>>> The intent of this language was to ensure that all CAs' CP and/or CPS
>>> documents contain a similar structure, making it easier to review and
>>> compare against the BRs. However, there was some ambiguity as to the actual
>>> structure that CAs should follow. After several discussions in the SCWG
>>> Public Mailing List
>>> 
>>> and F2F meetings, it was agreed that more clarity should be added to the
>>> existing requirement, pointing to the outline described in section 6 of RFC
>>> 3647.
>>> The following motion has been proposed by Dimitris Zacharopoulos
>>> (HARICA) and endorsed by Aaron Poulsen (Amazon) and Tim Hollebeek
>>> (Digicert).
>>>
>>> You can view the github pull request representing this ballot here
>>> .
>>> Motion Begins
>>>
>>> MODIFY the "Baseline Requirements for the Issuance and Management of
>>> Publicly-Trusted TLS Server Certificates" based on Version 2.0.4 as
>>> specified in the following redline:
>>>
>>>-
>>>
>>> https://github.com/cabforum/servercert/compare/c4a34fe2292022e0a04ba66b5a85df75907ac2a2...f6a90e2a652fbb7a2d62a976b70f4af3adce8dae
>>>
>>> Motion Ends
>>>
>>> This ballot proposes a Final Maintenance Guideline. The procedure for
>>> approval of this ballot is as follows:
>>> Discussion (at least 7 days)
>>>
>>>- Start time: 2024-04-25 16:30:00 UTC
>>>- End time: on or after 2024-05-02 16:30:00 UTC
>>>
>>> Vote for approval (7 days)
>>>
>>>- Start time: TBD
>>>- End time: TBD
>>>
>>>
>>> ___
>>> Servercert-wg mailing list
>>> Servercert-wg@cabforum.org
>>> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>>>
>>
>> ___
> Servercert-wg mailing list
> Servercert-wg@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>
___
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

[Wendy Brown - QT3LB-C via Servercert-wg]

Infrastructure certificates are certs that are required for the
operation of the CA - they may be things like a certificate used to sign
the CA's system audit logs so there is an integrity check of these logs, or
certificates issued to trusted roles for MFA to the CA.
If the BRs (which are supposed to BASELINE Requirements - not totally
prescriptive, suddenly remove that specific line in the BRs that allow
these type of certificates to be signed by the offline root CA then you are
basically prescribing that the offline root now needs connection to another
PKI in order to be able to validate any certificates used for these
purposes, or less securely it now needs to just accept any such
certificates as being valid without being able to check the current status.

Wendy


Wendy Brown

Supporting GSA

FPKIMA Technical Liaison

Protiviti Government Services
703-965-2990 (cell)


On Fri, Aug 18, 2023 at 12:48 PM Clint Wilson  wrote:

> Hi all,
>
> Is anyone able to identify the product in question such that we can review
> its documentation and behavior in greater detail and collectively determine
> whether (and if so, how) the certificates it’s issuing should fit into or
> be accounted for by the BRs?
> The profiles ballot — version 2.0 of the BRs — has been momentous in
> moving us towards clearer, more comprehensive definitions of what exists
> with any relation to the Web PKI’s TLS hierarchies, but as this ballot
> represents, there were some oversights that yet require addressing. It’s
> a tad difficult for me, personally, to view the continued allowance of
> these infrastructure certificates as justified without having a
> *substantially *clearer understanding of exactly what they are and how
> they relate to the trusted TLS Root CA Certificates (and their keypairs)
> subject to the BRs.
>
> I’m hopeful we can have greater clarity and transparency around
> infrastructure certificates which need to chain to publicly trusted Root
> CAs. Until then, I remain supportive of the current ballot removing them
> from the BRs.
>
> Thank you,
> -Clint
>
> On Aug 2, 2023, at 11:57 AM, Wendy Brown - QT3LB-C 
> wrote:
>
> Clint,
> I'll have to defer to others in terms of available documentation on the
> product.
> But the certs & keys created are definitely the result of explicit CA
> personnel actions - the first action being the establishment of a new
> self-signed Root CA.  Personnel authentication certificates also must be
> issued through explicit commands.
> These aren't things that just happen after the CA has been up and running
> , it doesn't make a decision on its own to issue new certificates.
> It is a CA that has been widely used on very secure PKIs.  And being
> self-sufficient like that is a good implementation for an offline Root CA
> so as to minimize the number of supplemental systems that might be required
> to support it.
>
> thanks,
>
> Wendy
>
>
> Wendy Brown
>
> Supporting GSA
>
> FPKIMA Technical Liaison
>
> Protiviti Government Services
> 703-965-2990 (cell)
>
>
> On Wed, Aug 2, 2023 at 2:07 PM Clint Wilson  wrote:
>
>> Hi Wendy,
>>
>> Thanks for this additional information and context. Is there publicly
>> available documentation for the product and this functionality? I think
>> that might be the most efficient way to answer some of the questions
>> arising around this. If not, I have a few follow-on questions. In what ways
>> and to what extent can the profiles be adjusted prior to issuance? Is the
>> TLS certificate issued directly by a Root, or a subordinate CA? Is the OCSP
>> signing certificate generated even if no OCSP responders are configured or
>> expected to be used? What are the default profiles used for each of the
>> certificates, if not adjusted prior to issuance?
>>
>> I’d like to understand better how these events occur — and why within the
>> context of the product — but currently it seems the described product is
>> not well-suited to operations within the Web (or any Public) PKI. While
>> it’s promising that the profiles are configurable, it remains quite
>> concerning that a CA/HSM would issue certificates automatically, without
>> the initiation and explicit input of CA personnel being prerequisite.
>>
>> Cheers,
>> -Clint
>>
>>
>> On Aug 2, 2023, at 10:52 AM, Wendy Brown - QT3LB-C via Servercert-wg <
>> servercert-wg@cabforum.org> wrote:
>>
>> Corey -
>> For at least 1 CA product that I am aware of, issuance of these
>> certificates is automatic, and we don't believe that issuance can be
>> disabled, or that a separate private PKI can be used to issue these
>> certificates inst

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

[Wendy Brown - QT3LB-C via Servercert-wg]

Clint,
I'll have to defer to others in terms of available documentation on the
product.
But the certs & keys created are definitely the result of explicit CA
personnel actions - the first action being the establishment of a new
self-signed Root CA.  Personnel authentication certificates also must be
issued through explicit commands.
These aren't things that just happen after the CA has been up and running ,
it doesn't make a decision on its own to issue new certificates.
It is a CA that has been widely used on very secure PKIs.  And being
self-sufficient like that is a good implementation for an offline Root CA
so as to minimize the number of supplemental systems that might be required
to support it.

thanks,

Wendy


Wendy Brown

Supporting GSA

FPKIMA Technical Liaison

Protiviti Government Services
703-965-2990 (cell)


On Wed, Aug 2, 2023 at 2:07 PM Clint Wilson  wrote:

> Hi Wendy,
>
> Thanks for this additional information and context. Is there publicly
> available documentation for the product and this functionality? I think
> that might be the most efficient way to answer some of the questions
> arising around this. If not, I have a few follow-on questions. In what ways
> and to what extent can the profiles be adjusted prior to issuance? Is the
> TLS certificate issued directly by a Root, or a subordinate CA? Is the OCSP
> signing certificate generated even if no OCSP responders are configured or
> expected to be used? What are the default profiles used for each of the
> certificates, if not adjusted prior to issuance?
>
> I’d like to understand better how these events occur — and why within the
> context of the product — but currently it seems the described product is
> not well-suited to operations within the Web (or any Public) PKI. While
> it’s promising that the profiles are configurable, it remains quite
> concerning that a CA/HSM would issue certificates automatically, without
> the initiation and explicit input of CA personnel being prerequisite.
>
> Cheers,
> -Clint
>
>
> On Aug 2, 2023, at 10:52 AM, Wendy Brown - QT3LB-C via Servercert-wg <
> servercert-wg@cabforum.org> wrote:
>
> Corey -
> For at least 1 CA product that I am aware of, issuance of these
> certificates is automatic, and we don't believe that issuance can be
> disabled, or that a separate private PKI can be used to issue these
> certificates instead.  In the event a separate, private PKI is used for CA
> infrastructure, it would be important that the private PKI at a minimum
> meets the same security and monitoring requirements of the CA for which it
> issues infrastructure certificates.  In a situation where a CA requires
> these certificates, it would be more secure to have optional Baseline
> profiles than stand up a separate private PKI to avoid the certificates.
>
> While the issuance is automatic, the profiles can be adjusted prior to
> issuance.  The profiles required would be for a Trusted Role authentication
> certificate (unless the two factor authentication requirement is waived and
> password authentication is used instead), audit log signing certificate,
> OCSP signing certificate, TLS certificate (for the local web interface of
> the CA), and a subsystem certificate so the certificate manager subsystem
> can communicate with the CA subsystem for issuance/revocation/Trusted Role
> authentication, etc.
>
> In addition, for an offline Root CA - requiring the use of a separate
> internal PKI might also require network capability each time the Root is
> activated so the Root CA can validate the current status of those
> externally issued certificates.
>
> thanks,
>
> Wendy
>
>
> Wendy Brown
>
> Supporting GSA
>
> FPKIMA Technical Liaison
>
> Protiviti Government Services
> 703-965-2990 (cell)
>
>
> On Tue, Aug 1, 2023 at 2:27 PM Corey Bonnell 
> wrote:
>
>> 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

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

[Wendy Brown - QT3LB-C via Servercert-wg]

Tim -
These are not TLS certificates so they cannot easily adhere to the TLS
serverAuth profile. They do not contain the serverAuth EKU
They are currently allowed in the BRs under
6.1.7
#3  Certificates for infrastructure purposes (administrative role
certificates, internal CA operational device certificates)

Which this "cleanup ballet" is proposing to remove.

thanks

Wendy


Wendy Brown

Supporting GSA

FPKIMA Technical Liaison

Protiviti Government Services
703-965-2990 (cell)


On Wed, Aug 2, 2023 at 2:00 PM Tim Hollebeek 
wrote:

> Do these automatically issued certificates have the serverAuth EKU, and is
> it necessary for them to chain to a publicly-trusted root?  If not, they’re
> out of scope for the server certificate baseline requirements.  If so, why
> can they not be in full compliance with the standard TLS profiles?  Which
> fields / requirements are causing problems?
>
>
>
> -Tim
>
>
>
> *From:* Servercert-wg  *On Behalf Of 
> *Wendy
> Brown - QT3LB-C via Servercert-wg
> *Sent:* Wednesday, August 2, 2023 1:52 PM
> *To:* Corey Bonnell 
> *Cc:* CA/B Forum Server Certificate WG Public Discussion List <
> servercert-wg@cabforum.org>
> *Subject:* Re: [Servercert-wg] Draft ballot SC-XX: Profiles cleanup ballot
>
>
>
> Corey -
>
> For at least 1 CA product that I am aware of, issuance of these
> certificates is automatic, and we don't believe that issuance can be
> disabled, or that a separate private PKI can be used to issue these
> certificates instead.  In the event a separate, private PKI is used for CA
> infrastructure, it would be important that the private PKI at a minimum
> meets the same security and monitoring requirements of the CA for which it
> issues infrastructure certificates.  In a situation where a CA requires
> these certificates, it would be more secure to have optional Baseline
> profiles than stand up a separate private PKI to avoid the certificates.
>
> While the issuance is automatic, the profiles can be adjusted prior to
> issuance.  The profiles required would be for a Trusted Role authentication
> certificate (unless the two factor authentication requirement is waived and
> password authentication is used instead), audit log signing certificate,
> OCSP signing certificate, TLS certificate (for the local web interface of
> the CA), and a subsystem certificate so the certificate manager subsystem
> can communicate with the CA subsystem for issuance/revocation/Trusted Role
> authentication, etc.
>
>
>
> In addition, for an offline Root CA - requiring the use of a separate
> internal PKI might also require network capability each time the Root is
> activated so the Root CA can validate the current status of those
> externally issued certificates.
>
>
>
> thanks,
>
> Wendy
>
>
>
> Wendy Brown
>
> Supporting GSA
>
> FPKIMA Technical Liaison
>
> Protiviti Government Services
>
> 703-965-2990 (cell)
>
>
>
>
>
> On Tue, Aug 1, 2023 at 2:27 PM Corey Bonnell 
> wrote:
>
> 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 <
> servercert-wg@cabforum.org>
> *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
>

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

[Wendy Brown - QT3LB-C via Servercert-wg]

Corey -
For at least 1 CA product that I am aware of, issuance of these
certificates is automatic, and we don't believe that issuance can be
disabled, or that a separate private PKI can be used to issue these
certificates instead.  In the event a separate, private PKI is used for CA
infrastructure, it would be important that the private PKI at a minimum
meets the same security and monitoring requirements of the CA for which it
issues infrastructure certificates.  In a situation where a CA requires
these certificates, it would be more secure to have optional Baseline
profiles than stand up a separate private PKI to avoid the certificates.

While the issuance is automatic, the profiles can be adjusted prior to
issuance.  The profiles required would be for a Trusted Role authentication
certificate (unless the two factor authentication requirement is waived and
password authentication is used instead), audit log signing certificate,
OCSP signing certificate, TLS certificate (for the local web interface of
the CA), and a subsystem certificate so the certificate manager subsystem
can communicate with the CA subsystem for issuance/revocation/Trusted Role
authentication, etc.

In addition, for an offline Root CA - requiring the use of a separate
internal PKI might also require network capability each time the Root is
activated so the Root CA can validate the current status of those
externally issued certificates.

thanks,

Wendy


Wendy Brown

Supporting GSA

FPKIMA Technical Liaison

Protiviti Government Services
703-965-2990 (cell)


On Tue, Aug 1, 2023 at 2:27 PM Corey Bonnell 
wrote:

> 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 <
> servercert-wg@cabforum.org>
> *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 
> 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 
> *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 

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

[Wendy Brown - QT3LB-C via Servercert-wg]

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 
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 
> *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 <
> 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
> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>
>
___
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

[Wendy Brown - QT3LB-C via Servercert-wg]

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 <
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
> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg