[Cscwg-public] Updated RFC 3647 mapping document
Dimitris Zacharopoulos (HARICA)
dzacharo at harica.gr
Wed Nov 17 08:07:10 UTC 2021
On 16/11/2021 4:22 μ.μ., Corey Bonnell wrote:
>
> 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.
>
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.
> > 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.
>
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?
> > 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.
>
Looks good to me.
> > 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.
>
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.
I made some comments directly on the pull request.
> > 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.
>
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.
> > 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 😊.
>
I don't fully agree with that interpretation because this means that a
CA that *currently *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.
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.
> 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.
>
Thanks, I missed that in my previous review. I suggested some changes in
the pull request to make these requirements hopefully more clear.
Dimitris.
>
> 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
>
> https://lists.cabforum.org/mailman/listinfo/cscwg-public
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20211117/456f38df/attachment-0001.html>
More information about the Cscwg-public
mailing list