[Cscwg-public] CSBR v2.5 to RFC 3647 mapping
Dimitris Zacharopoulos (HARICA)
dzacharo at harica.gr
Mon Sep 6 09:22:30 UTC 2021
Thanks for the great work Corey!
I reviewed the PR and it seems most of the information has been properly
captured and moved to "reasonable" sections. I am saying "reasonable"
because depending on various interpretations of 3647 we could propose
slightly different locations but what you currently proposed works fine.
I'd like to comment on 10.1.2 (highlighted as red). I believe this
information is required and should be referenced in the NEW 220.127.116.11 to
point to 10.1.2 of the TLS EV Guidelines.
The NEW 4.9.7 section includes information about OCSP which we should
probably try to separate from CRLs, although I like the fact that the
issuance requirements for CRLs and OCSP are in one place. RFC 3647
thinks otherwise :)
Regarding Appendix A and how this is split between the NEW 6.1.5 and
7.1.3, I noticed that you have migrated language from the latest BRs
regarding the encoding of algorithms but also some additional
requirements like "The CA SHALL NOT use a different algorithm, such as
the id-RSASSA-PSS (OID: 1.2.840.113518.104.22.168) algorithm identifier, to
indicate an RSA key". Similarly for the NEW 22.214.171.124.2, I don't think the
current CSBRs have these requirements enforced. Please let me know if I
Regarding the deprecation of DSA, we must decide whether this "RFC 3647
alignment" ballot is expected to apply any normative changes or just to
"convert" into something that more-less has the same
expectations/requirements as the latest version of the CSBRs. Having
reviewed several ballots in the past, it's nice to know the scope of the
ballot and whether it is expected to make normative changes or not. With
that said, it would be fine - I think- to mark any possible normative
changes, like the deprecation of DSA, in the preface of the ballot so
Members know about them.
Regarding KeyPurposeIDs, I believe lifetimeSigning IS a KeyPurposeId
that can be used in the EKU extension
Finally, some internal hyperlinks (anchors) don't seem to work. I'm not
sure if this is something related to the rendering of GitHub or if you
have typos in the hyperlinks.
Appendices A and B are quite challenging to review and definitely need
another pair of eyes to check.
On 31/8/2021 6:02 μ.μ., Corey Bonnell via Cscwg-public wrote:
> To aid in the comparison/review process, I have marked up the current
> CSBRs with highlighting (explained below) and comments that indicate
> the new section where the content is located.
> The highlighting in the mapping document has the following meanings:
> * Green indicates the text is unchanged
> * Yellow indicates the text is still present, but has been modified
> for consistency or to fix section references that have changed
> * Red indicates the text has been dropped entirely. There are only a
> few instances of this, but we should review carefully to ensure
> that it can be safely dropped.
> A PR has been opened for the RFC 3647/Pandoc migration:
> <https://github.com/cabforum/code-signing/pull/6>. I pulled in
> Dimitris’s migration work (thanks Dimitris!) in section 1 into my
> branch to complete the document.
> Please provide your comments on that PR or here on the list and let me
> know if anything isn’t clear or if there’s any questions. If there’s
> lots of feedback we may want to devote some time in upcoming calls to
> review together.
> Cscwg-public mailing list
> Cscwg-public at cabforum.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Cscwg-public