<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
        {font-family:Wingdings;
        panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:"Yu Gothic";
        panose-1:2 11 4 0 0 0 0 0 0 0;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Consolas;
        panose-1:2 11 6 9 2 2 4 3 2 4;}
@font-face
        {font-family:"\@Yu Gothic";
        panose-1:2 11 4 0 0 0 0 0 0 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:#0563C1;
        text-decoration:underline;}
pre
        {mso-style-priority:99;
        mso-style-link:"HTML Preformatted Char";
        margin:0in;
        margin-bottom:.0001pt;
        font-size:10.0pt;
        font-family:"Courier New",serif;}
span.HTMLPreformattedChar
        {mso-style-name:"HTML Preformatted Char";
        mso-style-priority:99;
        mso-style-link:"HTML Preformatted";
        font-family:Consolas;}
span.EmailStyle21
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
/* List Definitions */
@list l0
        {mso-list-id:857350940;
        mso-list-template-ids:1678389104;}
@list l0:level1
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:.5in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Symbol;}
@list l0:level2
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:1.0in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Symbol;}
@list l0:level3
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:1.5in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Symbol;}
@list l0:level4
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:2.0in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Symbol;}
@list l0:level5
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:2.5in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Symbol;}
@list l0:level6
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:3.0in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Symbol;}
@list l0:level7
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:3.5in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Symbol;}
@list l0:level8
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:4.0in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Symbol;}
@list l0:level9
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:4.5in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Symbol;}
@list l1
        {mso-list-id:1236671003;
        mso-list-template-ids:-1969177104;}
@list l1:level1
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:.5in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Symbol;}
@list l1:level2
        {mso-level-number-format:bullet;
        mso-level-text:o;
        mso-level-tab-stop:1.0in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:"Courier New",serif;
        mso-bidi-font-family:"Times New Roman";}
@list l1:level3
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:1.5in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Wingdings;}
@list l1:level4
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:2.0in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Wingdings;}
@list l1:level5
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:2.5in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Wingdings;}
@list l1:level6
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:3.0in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Wingdings;}
@list l1:level7
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:3.5in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Wingdings;}
@list l1:level8
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:4.0in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Wingdings;}
@list l1:level9
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:4.5in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Wingdings;}
ol
        {margin-bottom:0in;}
ul
        {margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link="#0563C1" vlink=purple style='word-wrap:break-word'><div class=WordSection1><p class=MsoNormal>Hi Dimitris,<o:p></o:p></p><p class=MsoNormal>Thanks for another round of careful review. A few more of these and the document will be over the finish line <span style='font-family:"Segoe UI Emoji",sans-serif'>😊</span>. Comments inline.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>>             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.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Thanks, this is corrected in the attached update.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>> 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.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>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.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>> 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?<o:p></o:p></p><p class=MsoNormal>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.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>> 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?<o:p></o:p></p><p class=MsoNormal>I updated the PR to hopefully make this clearer. Let me know if you have further suggestions for improvement here.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>> 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.<o:p></o:p></p><p class=MsoNormal>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.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>> 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.<o:p></o:p></p><p class=MsoNormal>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.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>> 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.<o:p></o:p></p><p class=MsoNormal>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 <span style='font-family:"Segoe UI Emoji",sans-serif'>😊</span>. 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.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>We can discuss these points (or any other items) further on this week’s call.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Thanks,<o:p></o:p></p><p class=MsoNormal>Corey<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b>From:</b> Cscwg-public <cscwg-public-bounces@cabforum.org> <b>On Behalf Of </b>Dimitris Zacharopoulos (HARICA) via Cscwg-public<br><b>Sent:</b> Monday, November 15, 2021 7:06 AM<br><b>To:</b> Corey Bonnell via Cscwg-public <cscwg-public@cabforum.org><br><b>Subject:</b> Re: [Cscwg-public] Updated RFC 3647 mapping document<o:p></o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal style='margin-bottom:12.0pt'><o:p> </o:p></p><div><p class=MsoNormal>On 10/11/2021 11:55 μ.μ., Corey Bonnell via Cscwg-public wrote:<o:p></o:p></p></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal>Hello,<o:p></o:p></p><p class=MsoNormal>As discussed last week, I have updated the RFC 3647/Pandoc Github PR (<a href="https://github.com/cabforum/code-signing/pull/6">https://github.com/cabforum/code-signing/pull/6</a>) 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.<o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal>Let me know if there’s any questions or comments.<o:p></o:p></p></blockquote><p class=MsoNormal><br>Hi Corey,<br><br>I took another pass through the mapping document. <o:p></o:p></p><ul type=disc><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo3'>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.<o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo3'>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.<o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo3'>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?<o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo3'>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?<o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo3'>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.<o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo3'>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.<o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo3'>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.<o:p></o:p></li></ul><p class=MsoNormal>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.<br><br><br>Thanks,<br>Dimitris.<br><br><br><br><o:p></o:p></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal>Thanks,<o:p></o:p></p><p class=MsoNormal>Corey<o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal><br><br><o:p></o:p></p><pre>_______________________________________________<o:p></o:p></pre><pre>Cscwg-public mailing list<o:p></o:p></pre><pre><a href="mailto:Cscwg-public@cabforum.org">Cscwg-public@cabforum.org</a><o:p></o:p></pre><pre><a href="https://lists.cabforum.org/mailman/listinfo/cscwg-public">https://lists.cabforum.org/mailman/listinfo/cscwg-public</a><o:p></o:p></pre></blockquote><p class=MsoNormal><o:p> </o:p></p></div></body></html>