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 <[email protected]> *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
<[email protected]>
*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 <[email protected]> *On Behalf
Of *Wendy Brown - QT3LB-C via Servercert-wg
*Sent:* Donnerstag, 9. Mai 2024 16:58
*To:* Aaron Gable <[email protected]>
*Cc:* CA/B Forum Server Certificate WG Public Discussion List
<[email protected]>
*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 <[email protected]> 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
<[email protected]> 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
<[email protected]> wrote:
Of course! Done:
https://github.com/cabforum/servercert/issues/513
<https://url.avanan.click/v2/___https:/github.com/cabforum/servercert/issues/513___.YXAzOmRpZ2ljZXJ0OmE6bzoyZGZmNDkwNjM2NzZkZTVkYTFkY2ZmM2FjZjk2Yzc0Yzo2OjhhYzY6ZmJmZTNhY2NmMGM2YmMyZjFhMzhmMjcwY2ExNDFkZTc3NGU5M2NkZDI4MzAyYjQwOWViMzNhMmJmZGRkMzAyMjpoOkY>
On Wed, May 8, 2024 at 8:37 AM Dimitris Zacharopoulos
(HARICA) <[email protected]> wrote:
Thanks Aaron,
Would it be ok for you to create a GitHub issue
<https://url.avanan.click/v2/___https:/github.com/cabforum/servercert/issues___.YXAzOmRpZ2ljZXJ0OmE6bzoyZGZmNDkwNjM2NzZkZTVkYTFkY2ZmM2FjZjk2Yzc0Yzo2OmUwNjI6MzFkMjYyMTQ3NzdmNTM5NzExNDRlODRhYmQzZTcyM2RkMWU2MDk2YzExNzY3NDczZjRkM2FiNWYzYWIyZTYxMDpoOkY>
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://url.avanan.click/v2/___https:/github.com/letsencrypt/cp-cps/tree/d5b258a/tools/lint___.YXAzOmRpZ2ljZXJ0OmE6bzoyZGZmNDkwNjM2NzZkZTVkYTFkY2ZmM2FjZjk2Yzc0Yzo2OmNjYjI6MmViY2I4M2Y5MmJlNzU4MWM5YWJhMWRhYjk1YmFiNzc0NTdkOWI1OTA5ZWJiNTkzZGNmMGFjZjk2ZjY3NjhhYTpoOkY>
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
<[email protected]> 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://url.avanan.click/v2/___https:/lists.cabforum.org/pipermail/servercert-wg/2023-November/004070.html___.YXAzOmRpZ2ljZXJ0OmE6bzoyZGZmNDkwNjM2NzZkZTVkYTFkY2ZmM2FjZjk2Yzc0Yzo2OjJmNjc6ZWM5ZWFhNDJkMmU0MGE0OGYxOWU1OWZkM2NkZmNiMTY3YmFjOWJlZDhiYTZiYzE5ZjBlZWM3MzI5YjYzNTM3NTpoOkY>
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
<https://url.avanan.click/v2/___https:/github.com/cabforum/servercert/pull/503___.YXAzOmRpZ2ljZXJ0OmE6bzoyZGZmNDkwNjM2NzZkZTVkYTFkY2ZmM2FjZjk2Yzc0Yzo2OjNhZmM6MGQ5ZWY1YjVmZDBhMmU2MGRmODhlNjZlZDhlOWEzNzkwOGU2NjA3NTllYzg5MjJlYWViMTJmODQ5NzBiMThkNzpoOkY>.
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
<https://url.avanan.click/v2/___https:/github.com/cabforum/servercert/compare/c4a34fe2292022e0a04ba66b5a85df75907ac2a2...f6a90e2a652fbb7a2d62a976b70f4af3adce8dae___.YXAzOmRpZ2ljZXJ0OmE6bzoyZGZmNDkwNjM2NzZkZTVkYTFkY2ZmM2FjZjk2Yzc0Yzo2OmFjNTU6ZGE2MDMwNTE5MDk4OGQyZGQzOTI5ODkxMThhMDNhNzM5NDFhY2ZjYjUwZDE1YWUzNTYzZTE4MjcxZTY4ZDY3ODpoOkY>
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
[email protected]
https://lists.cabforum.org/mailman/listinfo/servercert-wg
<https://url.avanan.click/v2/___https:/lists.cabforum.org/mailman/listinfo/servercert-wg___.YXAzOmRpZ2ljZXJ0OmE6bzoyZGZmNDkwNjM2NzZkZTVkYTFkY2ZmM2FjZjk2Yzc0Yzo2OjA2MTI6NjAyZjc1OTQ4MmVlOTNkODMwYTNlMjQzYjgzYmYzMjY0OTdiMGNmNjFhZWUwNDA4OWViZDE0MWY0NjU1NTA2ZTpoOkY>
_______________________________________________
Servercert-wg mailing list
[email protected]
https://lists.cabforum.org/mailman/listinfo/servercert-wg
<https://url.avanan.click/v2/___https:/lists.cabforum.org/mailman/listinfo/servercert-wg___.YXAzOmRpZ2ljZXJ0OmE6bzoyZGZmNDkwNjM2NzZkZTVkYTFkY2ZmM2FjZjk2Yzc0Yzo2OjA1NjY6NjM4MTE2ZWYwN2IwMDY4MzJhZmFiOTBjMmNjNTEzMjY5NDgzYjQ2ZjRmOTE1OTk3OGRmNWEyNWRkMDEyOTU4ZDpoOkY>
_______________________________________________
Servercert-wg mailing list
[email protected]
https://lists.cabforum.org/mailman/listinfo/servercert-wg
_______________________________________________
Servercert-wg mailing list
[email protected]
https://lists.cabforum.org/mailman/listinfo/servercert-wg
