[Cscwg-public] CSBR v2.5 to RFC 3647 mapping

[Dimitris Zacharopoulos (HARICA)]

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 3.2.2.2 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.113549.1.1.10) algorithm identifier, to 
indicate an RSA key". Similarly for the NEW 7.1.3.2.2, I don't think the 
current CSBRs have these requirements enforced. Please let me know if I 
missed anything.

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 
(https://oidref.com/1.3.6.1.4.1.311.10.3.13).

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.


Thanks,
Dimitris.

On 31/8/2021 6:02 μ.μ., Corey Bonnell via Cscwg-public wrote:
>
> Hello,
>
> 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 
> <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.
>
> Thanks,
>
> Corey
>
>
> _______________________________________________
> Cscwg-public mailing list
> Cscwg-public at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/cscwg-public

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20210906/014cf82e/attachment.html>