[Cscwg-public] Updated RFC 3647 mapping document

Tue Nov 16 14:22:35 UTC 2021

Hi Dimitris,

Thanks for another round of careful review. A few more of these and the document will be over the finish line 😊. Comments inline.

>             In 10.1.2, you have a red highlighted text and a comment. However, this has already been moved to the new section 3.2.2.2 so it should be green and the comment should be updated.

Thanks, this is corrected in the attached update.

> In 11.8, perhaps this text fits better to the new section 4.2.2 which describes procedures related to the approval/rejection of a certificate application but I don't have any strong feelings about it. If there is no preference by other members, we can leave it as-is.

My interpretation of the “Due Diligence” check is that it is a validation step that ensures validation was carried out properly and is not additional, separate verification that the Applicant is suspect, etc. Given this, I think 4.2.1 is the best location for the text, but I also don’t object strongly to moving it to 4.2.2.

> In 14.2.1, there is a strange "exception" for delegated RAs. I agree that the current pointer to "Section 14.2.2 of this document" makes no sense but my feeling is that the current language was trying to allow an "exception" to external audits for delegated RAs, and enforce internal audits? Is that other people's reading as well?

I agree the current language is very hard to follow, but I don’t believe the current language provides a clear exception for external audits for DTPs. For example, section 17.6 requires such external audits for DTPs. I think this is one area where the CSBRs are unclear/contradictory in terms of audit obligations for DTPs and we should discuss further. Attempting to rectify in this ballot might be out of scope though.

> In 14.2.2 and 14.2.3 you tried to move some requirements to the new section 9.8. I am not very fond of the "MAY NOT" language that we currently use in section 18. Would it be ok to separate the non-EV and EV requirements as far as liability is concerned making sure the requirement remains the same but more clearly written?

I updated the PR to hopefully make this clearer. Let me know if you have further suggestions for improvement here.

> In Appendix B (2) F, I believe the explicit "MUST NOT" and "SHOULD NOT" language should be copied over to the new 7.1.2.2g.

I have a comment in the mapping doc explaining the rationale for the proposed language: “This is a long winded way to say every other EKU is prohibited unless the platform vendor gives the CA permission to include other EKUs.”. Do you disagree with that interpretation? Nonetheless, I removed the duplicative MUST NOTs for timestamping EKU in code signing certs and vice versa.

> In Appendix B (2), about the RFC 5280 applicability for setting all other fields and extensions, I'm fine with bringing BR 7.1.2.4 into the CSBRs. However, I'd like to remind members that there were some past discussions in the SCWG about the restriction of including new extensions for testing new protocols or other standards, making this kind of a controversial issue.

I believe the normative requirements in TLS BR 7.1.2.4 already exist for the CSBRs because the CSBRs are silent here and we defer to the TLS BRs wherever the CSBRs do not specify anything.

> In Appendix B (3) F, we should try to keep as much of the existing language as possible, and migrate it to 7.1.2.3 f. We should create a listing of applicable mandatory/optional requirements for codeSigning and TimeStamping KeyPurposeIDs to make it clearer. In a subsequent ballot, we could make these sections clearer by changing the requirements, and even include additional RFC 3161 requirements for setting the EKU extension as "critical" for Time-stamping Certificates.

I think this is related to the above point about EKUs. I attempted to clean up the language by merely specifying the logical conclusion of all other values being MUST NOT unless you ask the platform vendor. Of course, if I reached the wrong conclusion, let me know 😊. As for EKU extension criticality for end-entity TSA certificates, the current CSBRs already specify the extension MUST be critical and I carried that over in the new document.

We can discuss these points (or any other items) further on this week’s call.

Thanks,

Corey

From: Cscwg-public <cscwg-public-bounces at cabforum.org> On Behalf Of Dimitris Zacharopoulos (HARICA) via Cscwg-public
Sent: Monday, November 15, 2021 7:06 AM
To: Corey Bonnell via Cscwg-public <cscwg-public at cabforum.org>
Subject: Re: [Cscwg-public] Updated RFC 3647 mapping document

On 10/11/2021 11:55 μ.μ., Corey Bonnell via Cscwg-public wrote:

Hello,

As discussed last week, I have updated the RFC 3647/Pandoc Github PR (https://github.com/cabforum/code-signing/pull/6) with the text from CSC-11 (I’ll update for CSC-12 once it clears IPR). Attached is the mapping document that shows where all the text in the current CSBR v2.6 now lives in the RFC 3647 draft. Hopefully, this mapping document facilitates next week’s discussion on next steps for the RFC 3647 draft.

Let me know if there’s any questions or comments.

Hi Corey,

I took another pass through the mapping document. 

*	In 10.1.2, you have a red highlighted text and a comment. However, this has already been moved to the new section 3.2.2.2 so it should be green and the comment should be updated.
*	In 11.8, perhaps this text fits better to the new section 4.2.2 which describes procedures related to the approval/rejection of a certificate application but I don't have any strong feelings about it. If there is no preference by other members, we can leave it as-is.
*	In 14.2.1, there is a strange "exception" for delegated RAs. I agree that the current pointer to "Section 14.2.2 of this document" makes no sense but my feeling is that the current language was trying to allow an "exception" to external audits for delegated RAs, and enforce internal audits? Is that other people's reading as well?
*	In 14.2.2 and 14.2.3 you tried to move some requirements to the new section 9.8. I am not very fond of the "MAY NOT" language that we currently use in section 18. Would it be ok to separate the non-EV and EV requirements as far as liability is concerned making sure the requirement remains the same but more clearly written?
*	In Appendix B (2) F, I believe the explicit "MUST NOT" and "SHOULD NOT" language should be copied over to the new 7.1.2.2g.
*	In Appendix B (2), about the RFC 5280 applicability for setting all other fields and extensions, I'm fine with bringing BR 7.1.2.4 into the CSBRs. However, I'd like to remind members that there were some past discussions in the SCWG about the restriction of including new extensions for testing new protocols or other standards, making this kind of a controversial issue.
*	In Appendix B (3) F, we should try to keep as much of the existing language as possible, and migrate it to 7.1.2.3 f. We should create a listing of applicable mandatory/optional requirements for codeSigning and TimeStamping KeyPurposeIDs to make it clearer. In a subsequent ballot, we could make these sections clearer by changing the requirements, and even include additional RFC 3161 requirements for setting the EKU extension as "critical" for Time-stamping Certificates.

Let me know if you have any questions that I could clarify. I'm also happy to work with you on addressing these issues as soon as possible.

Thanks,
Dimitris.

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/20211116/c36f477b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CSBR v2.6 RFC 3647 mapping.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 155108 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20211116/c36f477b/attachment-0001.docx>
-------------- 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/20211116/c36f477b/attachment-0001.p7s>