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

[Tim Hollebeek via Servercert-wg]

Yes, I’m under no illusions I got it right on the first try, and alternative 
approaches might be better.

 

-Tim

 

From: Clint Wilson  
Sent: Friday, May 10, 2024 2:20 PM
To: Tim Hollebeek ; ServerCert CA/BF 

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

 

Hi Tim,





On May 10, 2024, at 8:52 AM, Tim Hollebeek via Servercert-wg 
mailto:servercert-wg@cabforum.org> > wrote:

 

Whether the comparison should be case sensitive or not is not a question of how 
“strict” the linter should be, but what the requirements are.  Linters MUST NOT 
make their own determinations as to what the requirements are, and SHOULD 
highlight cases like this where ambiguity may be present.  For example, it 
would be sensible to WARN that a value deviates in case from the correct value, 
and that the requirements are unclear whether that’s allowed (assuming SC-74 
had passed in its current form).

 

However, I would question whether it’s actually even unclear at all.  It’s 
impossible to interpret the highlighted language into a, b, or c, because the 
language is completely silent on not just capitalization, but the titles 
themselves.  I interpret the highlighted language as saying you have to include 
at least every section and subsection, but it doesn’t matter what titles you 
give those sections or subsections (since there’s no relevant requirements).  
That’s what the highlighted text says, and questions of whether it has to be 
capitalized the same way miss the fact that it doesn’t even say the same titles 
need to be used.

 

There are also some hilarious errors in 3647 if you look closely.  I think the 
best path forward would be something along the lines of:

 

1.  MUST include at least every section and subsection defined in Appendix 
ZZ, and MUST use the section and subsection titles listed there
2.  The titles SHOULD be formatted, worded, capitalized and spelled the 
same way, and
3.  Errors in formatting or titling sections of a CPS are not grounds for 
revocation of affected certificates. 

 

Overall agreed with what’s stated here, except this part of the proposal. I do 
agree with what I believe your intent to be, but depending on how this is 
worded it seems it could lead to overly broad application (e.g. the error in 
titling “Non-verified subscriber information” results in a title of “Verified 
subscriber information”). Mostly just drawing attention to it as something that 
would need to be crafted somewhat carefully and perhaps would be preferable to 
have the MUST and SHOULD sections worded specifically enough that the intended 
allowance for errors in formatting or titling are encapsulated as clearly not 
part of the MUST requirement and clearly part of the SHOULD requirement. That 
approach would also avoid (I think) needing to consider the interaction of 
something like #3 with 4.9.1.2.(5).

 

Cheers,

-Clint





And then explicitly list the outline we want in Appendix ZZ.  The outline 
should be very close to what 3647 says, to avoid unnecessary churn or deviation 
from IETF standards, but it would give us a chance to fix the obvious errors, 
and perhaps fix some historical baggage.

 

The resulting outline could be submitted back to IETF for publication as an 
update to 3647, which is starting to show its age.

 

-Tim

 

From: Servercert-wg mailto:servercert-wg-boun...@cabforum.org> > On Behalf Of Roman Fischer via 
Servercert-wg
Sent: Friday, May 10, 2024 4:20 AM
To: CA/B Forum Server Certificate WG Public Discussion List 
mailto:servercert-wg@cabforum.org> >
Subject: Re: [Servercert-wg] Ballot SC-74 - Clarify CP/CPS structure according 
to RFC 3647

 

Hi Wendy,

 

I would definitely go for c) because the documents are overall not standardized 
enough to do any kind of automatic parsing where a) or b) would maybe help.

 

Rgds
Roman

 

From: Servercert-wg mailto:servercert-wg-boun...@cabforum.org> > On Behalf Of Wendy Brown - 
QT3LB-C via Servercert-wg
Sent: Donnerstag, 9. Mai 2024 16:58
To: Aaron Gable mailto:aa...@letsencrypt.org> >
Cc: CA/B Forum Server Certificate WG Public Discussion List 
mailto:servercert-wg@cabforum.org> >
Subject: Re: [Servercert-wg] Ballot SC-74 - Clarify CP/CPS structure according 
to RFC 3647

 

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 li

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

[Clint Wilson via Servercert-wg]

Hi Tim,

> On May 10, 2024, at 8:52 AM, Tim Hollebeek via Servercert-wg 
>  wrote:
> 
> Whether the comparison should be case sensitive or not is not a question of 
> how “strict” the linter should be, but what the requirements are.  Linters 
> MUST NOT make their own determinations as to what the requirements are, and 
> SHOULD highlight cases like this where ambiguity may be present.  For 
> example, it would be sensible to WARN that a value deviates in case from the 
> correct value, and that the requirements are unclear whether that’s allowed 
> (assuming SC-74 had passed in its current form).
>  
> However, I would question whether it’s actually even unclear at all.  It’s 
> impossible to interpret the highlighted language into a, b, or c, because the 
> language is completely silent on not just capitalization, but the titles 
> themselves.  I interpret the highlighted language as saying you have to 
> include at least every section and subsection, but it doesn’t matter what 
> titles you give those sections or subsections (since there’s no relevant 
> requirements).  That’s what the highlighted text says, and questions of 
> whether it has to be capitalized the same way miss the fact that it doesn’t 
> even say the same titles need to be used.
>  
> There are also some hilarious errors in 3647 if you look closely.  I think 
> the best path forward would be something along the lines of:
>  
> MUST include at least every section and subsection defined in Appendix ZZ, 
> and MUST use the section and subsection titles listed there
> The titles SHOULD be formatted, worded, capitalized and spelled the same way, 
> and
> Errors in formatting or titling sections of a CPS are not grounds for 
> revocation of affected certificates. 

Overall agreed with what’s stated here, except this part of the proposal. I do 
agree with what I believe your intent to be, but depending on how this is 
worded it seems it could lead to overly broad application (e.g. the error in 
titling “Non-verified subscriber information” results in a title of “Verified 
subscriber information”). Mostly just drawing attention to it as something that 
would need to be crafted somewhat carefully and perhaps would be preferable to 
have the MUST and SHOULD sections worded specifically enough that the intended 
allowance for errors in formatting or titling are encapsulated as clearly not 
part of the MUST requirement and clearly part of the SHOULD requirement. That 
approach would also avoid (I think) needing to consider the interaction of 
something like #3 with 4.9.1.2.(5).

Cheers,
-Clint

> And then explicitly list the outline we want in Appendix ZZ.  The outline 
> should be very close to what 3647 says, to avoid unnecessary churn or 
> deviation from IETF standards, but it would give us a chance to fix the 
> obvious errors, and perhaps fix some historical baggage.
>  
> The resulting outline could be submitted back to IETF for publication as an 
> update to 3647, which is starting to show its age.
>  
> -Tim
>  
> From: Servercert-wg  <mailto:servercert-wg-boun...@cabforum.org>> On Behalf Of Roman Fischer via 
> Servercert-wg
> Sent: Friday, May 10, 2024 4:20 AM
> To: CA/B Forum Server Certificate WG Public Discussion List 
> mailto:servercert-wg@cabforum.org>>
> Subject: Re: [Servercert-wg] Ballot SC-74 - Clarify CP/CPS structure 
> according to RFC 3647
>  
> Hi Wendy,
>  
> I would definitely go for c) because the documents are overall not 
> standardized enough to do any kind of automatic parsing where a) or b) would 
> maybe help.
>  
> Rgds
> Roman
>  
> From: Servercert-wg  <mailto:servercert-wg-boun...@cabforum.org>> On Behalf Of Wendy Brown - 
> QT3LB-C via Servercert-wg
> Sent: Donnerstag, 9. Mai 2024 16:58
> To: Aaron Gable mailto:aa...@letsencrypt.org>>
> Cc: CA/B Forum Server Certificate WG Public Discussion List 
> mailto:servercert-wg@cabforum.org>>
> Subject: Re: [Servercert-wg] Ballot SC-74 - Clarify CP/CPS structure 
> according to RFC 3647
>  
> 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 occu

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

[Dimitris Zacharopoulos (HARICA) via Servercert-wg]

On 10/5/2024 6:52 μ.μ., Tim Hollebeek via Servercert-wg wrote:


Whether the comparison should be case sensitive or not is not a 
question of how “strict” the linter should be, but what the 
requirements are.  Linters MUST NOT make their own determinations as 
to what the requirements are, and SHOULD highlight cases like this 
where ambiguity may be present. For example, it would be sensible to 
WARN that a value deviates in case from the correct value, and that 
the requirements are unclear whether that’s allowed (assuming SC-74 
had passed in its current form).




I agree with this statement because we are constantly trying to make the 
requirements very clear that their adherence can actually be coded in 
linters, even for a text document that is supposed to be read by humans.


However, I would question whether it’s actually even unclear at all. 
It’s impossible to interpret the highlighted language into a, b, or c, 
because the language is completely silent on not just capitalization, 
but the titles themselves.  I interpret the highlighted language as 
saying you have to include at least every section and subsection, but 
it doesn’t matter what titles you give those sections or subsections 
(since there’s no relevant requirements).




Based on the current BRs and EV Guidelines, CP/CPS documents need to be 
structured in accordance with RFC 3647. That must have meant something 
for CAs and auditors, so I don't agree that there are no relevant 
requirements. Some requirements don't need to be fully prescriptive to 
make sense, and a Qualified Auditor would be in a position to check 
whether a CP/CPS follows the outline (even with case insensitive or 
slightly different/clearer wording of the section title), or whether it 
is structured according to the old EV Guidelines which did not follow 
the outline at all.


That’s what the highlighted text says, and questions of whether it has 
to be capitalized the same way miss the fact that it doesn’t even say 
the same titles need to be used.




Please recall that this came from the MRSP 
<https://github.com/mozilla/pkipolicy/blob/master/rootstore/policy.md#33-cps-and-cpses> 
which says "include at least every section and subsection defined in RFC 
3647", which is actually a bit worse than what the ballot said, so I 
think it should also be fixed there :-)


There are also some hilarious errors in 3647 if you look closely.  I 
think the best path forward would be something along the lines of:


 1. MUST include at least every section and subsection defined in
Appendix ZZ, and MUST use the section and subsection titles listed
there
 2. The titles SHOULD be formatted, worded, capitalized and spelled
the same way, and
 3. Errors in formatting or titling sections of a CPS are not grounds
for revocation of affected certificates.

And then explicitly list the outline we want in Appendix ZZ.  The 
outline should be very close to what 3647 says, to avoid unnecessary 
churn or deviation from IETF standards, but it would give us a chance 
to fix the obvious errors, and perhaps fix some historical baggage.


The resulting outline could be submitted back to IETF for publication 
as an update to 3647, which is starting to show its age.




100% onboard with this. It's not a super-urgent matter but I'm confident 
we'll get the language right and contribute back to IETF.


Dimitris.


-Tim

*From:*Servercert-wg  *On Behalf 
Of *Roman Fischer via Servercert-wg

*Sent:* Friday, May 10, 2024 4:20 AM
*To:* CA/B Forum Server Certificate WG Public Discussion List 

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


Hi Wendy,

I would definitely go for c) because the documents are overall not 
standardized enough to do any kind of automatic parsing where a) or b) 
would maybe help.


Rgds
Roman

*From:*Servercert-wg  *On Behalf 
Of *Wendy Brown - QT3LB-C via Servercert-wg

*Sent:* Donnerstag, 9. Mai 2024 16:58
*To:* Aaron Gable 
*Cc:* CA/B Forum Server Certificate WG Public Discussion List 

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


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 T

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

[Tim Hollebeek via Servercert-wg]

Whether the comparison should be case sensitive or not is not a question of how 
“strict” the linter should be, but what the requirements are.  Linters MUST NOT 
make their own determinations as to what the requirements are, and SHOULD 
highlight cases like this where ambiguity may be present.  For example, it 
would be sensible to WARN that a value deviates in case from the correct value, 
and that the requirements are unclear whether that’s allowed (assuming SC-74 
had passed in its current form).

 

However, I would question whether it’s actually even unclear at all.  It’s 
impossible to interpret the highlighted language into a, b, or c, because the 
language is completely silent on not just capitalization, but the titles 
themselves.  I interpret the highlighted language as saying you have to include 
at least every section and subsection, but it doesn’t matter what titles you 
give those sections or subsections (since there’s no relevant requirements).  
That’s what the highlighted text says, and questions of whether it has to be 
capitalized the same way miss the fact that it doesn’t even say the same titles 
need to be used.

 

There are also some hilarious errors in 3647 if you look closely.  I think the 
best path forward would be something along the lines of:

 

1.  MUST include at least every section and subsection defined in Appendix 
ZZ, and MUST use the section and subsection titles listed there
2.  The titles SHOULD be formatted, worded, capitalized and spelled the 
same way, and
3.  Errors in formatting or titling sections of a CPS are not grounds for 
revocation of affected certificates.

 

And then explicitly list the outline we want in Appendix ZZ.  The outline 
should be very close to what 3647 says, to avoid unnecessary churn or deviation 
from IETF standards, but it would give us a chance to fix the obvious errors, 
and perhaps fix some historical baggage.

 

The resulting outline could be submitted back to IETF for publication as an 
update to 3647, which is starting to show its age.

 

-Tim

 

From: Servercert-wg  On Behalf Of Roman 
Fischer via Servercert-wg
Sent: Friday, May 10, 2024 4:20 AM
To: CA/B Forum Server Certificate WG Public Discussion List 

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

 

Hi Wendy,

 

I would definitely go for c) because the documents are overall not standardized 
enough to do any kind of automatic parsing where a) or b) would maybe help.

 

Rgds
Roman

 

From: Servercert-wg mailto:servercert-wg-boun...@cabforum.org> > On Behalf Of Wendy Brown - 
QT3LB-C via Servercert-wg
Sent: Donnerstag, 9. Mai 2024 16:58
To: Aaron Gable mailto:aa...@letsencrypt.org> >
Cc: CA/B Forum Server Certificate WG Public Discussion List 
mailto:servercert-wg@cabforum.org> >
Subject: Re: [Servercert-wg] Ballot SC-74 - Clarify CP/CPS structure according 
to RFC 3647

 

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 mailto:aa...@letsencrypt.org> > 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 mailto:wendy.br...@gsa.gov> > 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)

 

 

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

[Roman Fischer via Servercert-wg]

Hi Wendy,

I would definitely go for c) because the documents are overall not standardized 
enough to do any kind of automatic parsing where a) or b) would maybe help.

Rgds
Roman

From: Servercert-wg  On Behalf Of Wendy 
Brown - QT3LB-C via Servercert-wg
Sent: Donnerstag, 9. Mai 2024 16:58
To: Aaron Gable 
Cc: CA/B Forum Server Certificate WG Public Discussion List 

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

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 
mailto:aa...@letsencrypt.org>> 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 
mailto:wendy.br...@gsa.gov>> 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 
mailto: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) 
mailto:dzach...@harica.gr>> wrote:
Thanks Aaron,

Would it be ok for you to create a GitHub 
issue<https://github.com/cabforum/servercert/issues> 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<https://github.com/letsencrypt/cp-cps/tree/d5b258a/tools/lint> 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 mailto:servercert-wg@cabforum.org>> 
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<https://lists.cabforum.org/pipermail/servercert-wg/2023-November/004070.html>
 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

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
> 

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

[Aaron Gable via Servercert-wg]

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
 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

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] Ballot SC-74 - Clarify CP/CPS structure according to RFC 3647

[Aaron Gable via Servercert-wg]

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

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

[Dimitris Zacharopoulos (HARICA) via Servercert-wg]

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

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

[Aaron Gable via Servercert-wg]

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