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

Wed Sep 8 12:56:57 UTC 2021

Hi Dimitris,

Thank you as always for your careful review. Comments inline.

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

I originally thought this was redundant since we normatively reference specific sections of the EVGs for validation steps and those sections call out the Role requirements. However, I can see your point that this may not be clear, so I restored the language in 3.2.2.2.

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

I moved the OCSP requirements to 4.9.10.

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

That is a good point. My original thinking was that the TLS BRs are generally the most reasonable way of encoding these values, so I thought it would be harmless to incorporate the language directly. However, this would impose a new requirement. I can revert this change and instead only mention the acceptable set of algorithms without prescribing the encoding (similar to what we do in Appendix A currently). Does anyone object to this course of action?

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

I agree that we should decide whether we will allow normative requirements changes. I selfishly proposed killing of DSA so I didn’t have to generate the hex encodings of the corresponding AlgorithmIdentifiers, but I agree this would introduce a new requirement. If we remove the encoding requirements for the AlgorithmIdentifiers (as mentioned above) anyway, this will make it easier to maintain the allowance for DSA.

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

You’re right, it is a KeyPurposeId. Fixed 7.1.2.3 (f).

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

I think this is a Github-only issue; the links within the generated PDFs should all work correctly.

Thanks,

Corey

From: Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr> 
Sent: Monday, September 6, 2021 5:23 AM
To: Corey Bonnell <Corey.Bonnell at digicert.com>; cscwg-public at cabforum.org
Subject: Re: [Cscwg-public] CSBR v2.5 to RFC 3647 mapping

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:

1.	Green indicates the text is unchanged
2.	Yellow indicates the text is still present, but has been modified for consistency or to fix section references that have changed
3.	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.

Thanks,

Corey

_______________________________________________
Cscwg-public mailing list
Cscwg-public at cabforum.org <mailto: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/20210908/a8ded536/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4990 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20210908/a8ded536/attachment-0001.p7s>