<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<br>
<br>
<div class="moz-cite-prefix">On 16/11/2021 4:22 μ.μ., Corey Bonnell
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:DM6PR14MB2186A1F3F5E81F5B8E6C4A7D92999@DM6PR14MB2186.namprd14.prod.outlook.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: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;}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;}div.WordSection1
{page:WordSection1;}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]-->
<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.</p>
</div>
</blockquote>
<br>
My interpretation is that validation takes place first, then the CA
checks if the Applicant is suspect. After this preparation, the due
diligence and cross-correlation procedure is the last step before
certificate issuance. We can certainly discuss on our next call but
I wonder how others feel about this. <br>
<br>
<blockquote type="cite"
cite="mid:DM6PR14MB2186A1F3F5E81F5B8E6C4A7D92999@DM6PR14MB2186.namprd14.prod.outlook.com">
<div class="WordSection1">
<p class="MsoNormal"><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.</p>
</div>
</blockquote>
<br>
So is removing the existing language that some CAs might be using to
support their decisions :). I agree this is ambiguous and we should
discuss to make clearer perhaps in a subsequent ballot. @Bruce,
should we add this issue to the "backlog" of possible
improvements/clarifications?<br>
<br>
<blockquote type="cite"
cite="mid:DM6PR14MB2186A1F3F5E81F5B8E6C4A7D92999@DM6PR14MB2186.namprd14.prod.outlook.com">
<div class="WordSection1">
<p class="MsoNormal"><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.</p>
</div>
</blockquote>
<br>
Looks good to me.<br>
<br>
<blockquote type="cite"
cite="mid:DM6PR14MB2186A1F3F5E81F5B8E6C4A7D92999@DM6PR14MB2186.namprd14.prod.outlook.com">
<div class="WordSection1">
<p class="MsoNormal"><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.</p>
</div>
</blockquote>
<br>
Some EKUs are explicitly forbidden for Code Signing, leaving no room
for exceptions even if requested by platform vendors. For
Time-stamping SubCAs (Appendix B (4) F), there are even less
explicitly forbidden keyPurposeIDs.<br>
<br>
I made some comments directly on the pull request.<br>
<br>
<blockquote type="cite"
cite="mid:DM6PR14MB2186A1F3F5E81F5B8E6C4A7D92999@DM6PR14MB2186.namprd14.prod.outlook.com">
<div class="WordSection1">
<p class="MsoNormal"><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.</p>
</div>
</blockquote>
<br>
As this is open to many interpretation risks, we have already agreed
to bring all the relevant and applicable TLS BRs sections into the
CSBRs. Perhaps we should queue this up as a subsequent ballot sooner
than later.<br>
<br>
<blockquote type="cite"
cite="mid:DM6PR14MB2186A1F3F5E81F5B8E6C4A7D92999@DM6PR14MB2186.namprd14.prod.outlook.com">
<div class="WordSection1">
<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 (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>.</p>
</div>
</blockquote>
<br>
I don't fully agree with that interpretation because this means that
a CA that <b>currently </b>uses -say- "id-kp-emailProtection"
KeyPurposeID along with the id-kp-codeSigning (because of the
current MAY), in your proposed version it must explicitly request
permission from a platform vendor to allow the
"id-kp-emailProtection". That's why we need to add the existing
acceptable exceptions to the 3647 version. Hope this makes sense.<br>
<br>
The current "platform vendor exception" clause is generally not a
good practice. If a platform vendor is consuming Code-Signing
Certificates, then this vendor should participate in the CSCWG and
request the custom KeyPurposeID to be added to the CSBRs, so that
all CAs know about it. If the vendor can't participate, then a CA
that wants to use such IDs should request them to be added. But
that's for a future update.<br>
<br>
<blockquote type="cite"
cite="mid:DM6PR14MB2186A1F3F5E81F5B8E6C4A7D92999@DM6PR14MB2186.namprd14.prod.outlook.com">
<div class="WordSection1">
<p class="MsoNormal"> 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.</p>
</div>
</blockquote>
<br>
Thanks, I missed that in my previous review. I suggested some
changes in the pull request to make these requirements hopefully
more clear.<br>
<br>
<br>
Dimitris.<br>
<blockquote type="cite"
cite="mid:DM6PR14MB2186A1F3F5E81F5B8E6C4A7D92999@DM6PR14MB2186.namprd14.prod.outlook.com">
<div class="WordSection1">
<p class="MsoNormal"><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
<a class="moz-txt-link-rfc2396E" href="mailto:cscwg-public-bounces@cabforum.org"><cscwg-public-bounces@cabforum.org></a> <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
<a class="moz-txt-link-rfc2396E" href="mailto:cscwg-public@cabforum.org"><cscwg-public@cabforum.org></a><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"
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.<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" moz-do-not-send="true" class="moz-txt-link-freetext">Cscwg-public@cabforum.org</a><o:p></o:p></pre>
<pre><a href="https://lists.cabforum.org/mailman/listinfo/cscwg-public" moz-do-not-send="true" class="moz-txt-link-freetext">https://lists.cabforum.org/mailman/listinfo/cscwg-public</a><o:p></o:p></pre>
</blockquote>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</blockquote>
<br>
</body>
</html>