<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<br>
<br>
<div class="moz-cite-prefix">On 10/11/2021 11:55 μ.μ., Corey Bonnell
via Cscwg-public wrote:<br>
</div>
<blockquote type="cite"
cite="mid:0100017d0bd907e2-08e3ad54-39c8-489e-80ad-13000b84f85d-000000@email.amazonses.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style>@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:"\@Yu Gothic";
panose-1:2 11 4 0 0 0 0 0 0 0;}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;}span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}div.WordSection1
{page:WordSection1;}</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]-->
<div class="WordSection1">
<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"
moz-do-not-send="true" class="moz-txt-link-freetext">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.</p>
</div>
</blockquote>
<br>
Hi Corey,<br>
<br>
I took another pass through the mapping document. <br>
<ul>
<li>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.</li>
<li>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.</li>
<li>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?</li>
<li>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?</li>
<li>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.</li>
<li>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.</li>
<li>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.<br>
</li>
</ul>
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>
<blockquote type="cite"
cite="mid:0100017d0bd907e2-08e3ad54-39c8-489e-80ad-13000b84f85d-000000@email.amazonses.com">
<div class="WordSection1">
<p class="MsoNormal"><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<span
style="font-family:"Arial",sans-serif;color:#686869"><o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Cscwg-public mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Cscwg-public@cabforum.org">Cscwg-public@cabforum.org</a>
<a class="moz-txt-link-freetext" href="https://lists.cabforum.org/mailman/listinfo/cscwg-public">https://lists.cabforum.org/mailman/listinfo/cscwg-public</a>
</pre>
</blockquote>
<br>
</body>
</html>