[Cscwg-public] Updated RFC 3647 mapping document

[Dimitris Zacharopoulos (HARICA)]

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/20211115/95af3db0/attachment.html>