Re: [Servercert-wg] SC-065: Convert EVGs into RFC 3647 format pre-ballot

Sat, 02 Dec 2023 02:26:57 -0800

We still have a disagreement so please allow me one more attempt to clarify my position because it seems you didn't check the links included in my previous post. I will copy some of that text here for convenience. 

On 1/12/2023 11:31 μ.μ., Tim Hollebeek wrote:


No.


IETF has both Normative and Informative RFCs.  While it is true that 
compliance with a Normative RFC is voluntary, if you do choose to 
comply, the RFC has requirements stated in RFC 2119 standards language 
that make it clear what the compliance rules are.  Informative RFCs 
like 3647 do not have any normative requirements at all.  They merely 
contain information.



“all sections of the RFC 3647 framework” is fine, this covers the 
sections enumerated in RFC 3647 section 4, which includes the TOP TWO 
levels of an outline in numbered form, e.g. the requirements for 
section 3.2 are described in RFC 3647 section 4.3.2.  There is no RFC 
3647 section 4.3.2.1, which proves my point.  RFC 3647 only has a two 
level outline structure.





I think I might have a hint on our disconnect. RFC 3647 has an 
indicative Table of Contents in Chapter 6 
(https://datatracker.ietf.org/doc/html/rfc3647#section-6) outlining the 
proposed CP/CPS sections and subsections using 3 levels.


Here is the text of the opening paragraph of that section (emphasis added):


    This section contains a recommended outline for a set of provisions,
    intended to serve as a checklist or (with some further development) a
    standard template for use by CP or CPS writers.  Such a common
    outline will facilitate:

    (a) Comparison of two certificate policies during cross-
        certification or other forms of interoperation (for the purpose
        of equivalency mapping).

    (b) Comparison of a CPS with a CP to ensure that the CPS faithfully
        implements the policy.

    (c) Comparison of two CPSs.


*In order to comply with the RFC, the drafters of a compliant CP or 
CPS are strongly advised to adhere to this outline.*   While use of an

    alternate outline is discouraged, it may be accepted if a proper
    justification is provided for the deviation and a mapping table is
    provided to readily discern where each of the items described in this
    outline is provided.



The reason the CA/B Forum BRs were structured according to this outline 
was to assist with comparisons between CP/CPS documents of different 
CAs, making the review of these documents easier.



That's why you see sections like 1.5.4 "CPS approval procedures" in the 
BRs as an empty section with "No Stipulation". There are many such 
sections in the BRs, all coming from section 6 of RFC 3647.


I hope this is clearer now.


BR Section 2.2 needs to be re-written, as there are no materials 
required by RFC 3647 (because RFC 3647 contains no requirements).  It 
needs to say something like “structured in accordance with RFC 3647 
and MUST include all sections of the outline described in section 4” 
or something like that.  What it says right now doesn’t capture the 
intent that you correctly summarized.





During the last couple of years reviewing CP/CPS documents, I saw some 
uniformity at least in Publicly Trusted CAs, and they all seem to follow 
the BRs structure which comes from the outline of section 6 of RFC 3647. 
However, it's not a bad idea to further clarify BR section 2.2 to better 
meet the expectations.



The MSRP language is better, I think I may have made all of these same 
points when it was being drafted, which is why it says “section and 
subsection” (two levels) and uses “structured according to” and not 
“complies with the requirements of”.



But anyway, this is all background that supports what I’ve been saying 
all along: BR 3.2 is a RFC 3647 section.  BR 3.2.1 **is not** a RFC 
3647 required section, nor is it even a section that is even mentioned 
in RFC 3647.  If you don’t believe me, please go to RFC 3647, Section 
4.3.2.1 and read what it says.  OH, WAIT, IT DOESN’T EXIST! 😊





To my point, BR 3.2.1 IS an RFC 3647 required section as it is 
explicitly mentioned in the outline of section 6 of RFC 3647:



3.2.1  Method to prove possession of private key



Details about the contents of that section can be found in the first 
bullet of section 4.3.2 of RFC 3647 
<https://datatracker.ietf.org/doc/html/rfc3647#section-4.3.2>.


Does that make more sense?

Dimitris.


-Tim

*From:* Dimitris Zacharopoulos (HARICA) <[email protected]>
*Sent:* Friday, December 1, 2023 1:04 PM

*To:* Tim Hollebeek <[email protected]>; Inigo Barreira 
<[email protected]>
*Cc:* CA/B Forum Server Certificate WG Public Discussion List 
<[email protected]>
*Subject:* Re: [Servercert-wg] SC-065: Convert EVGs into RFC 3647 
format pre-ballot


Hi Tim,


None of the IETF standards set policy unless they are invited by some 
policy authority :) The BRs set such policy and "import" some 
documents, such as RFC 5280, 3647 and others.


The BRs in section 1.1 state:


    These Requirements do not address all of the issues relevant to
    the issuance and management of Publicly-Trusted Certificates. In
    accordance with RFC 3647 and to facilitate a comparison of other
    certificate policies and CPSs (e.g. for policy mapping), this
    document includes all sections of the RFC 3647 framework. However,
    rather than beginning with a "no stipulation" comment in all empty
    sections, the CA/Browser Forum is leaving such sections initially
    blank until a decision of "no stipulation" is made


In addition, section 2.2 states (emphasis added):


    The Certificate Policy and/or Certification Practice Statement
    MUST be structured in accordance with RFC 3647 and *MUST include
    all material required by RFC 3647*.



If you go back to the discussions when the CA/B Forum decide to align 
with the "RFC 3647 format", we agreed to include each and every 
section of the outline as a minimum set.


MRSP states in section 3.3 (5) (again, emphasis added):


    5. all CPs, CPSes, and combined CP/CPSes MUST be structured
    according to RFC 3647 and MUST:

        - include *at least every section and subsection defined in
    RFC 3647*;
        - only use the words "No Stipulation" to mean that the
    particular document imposes no requirements related to that
    section; and
        - contain no sections that are blank and have no subsections;



So, with all that considered, when we visit section 6 of RFC 3647 
<https://datatracker.ietf.org/doc/html/rfc3647#section-6> ("the 
outline"), the expectation is to include each and every section and 
subsection of the outline (up to three levels).



CAs are free to add MORE sections and subsections as they desire, just 
like the BRs have done, but we can't escape or "hijack" an existing 
RFC 3647 section number. The outline contains a specific section 
labeled as "3.2.1  Method to prove possession of private key". That 
means we cannot re-use the number 3.2.1 for something else.


I hope this sounds reasonable to people.

Dimitris.

On 1/12/2023 6:51 μ.μ., Tim Hollebeek wrote:

    This is unfortunately wrong.  There are lots of misconceptions
    about RFC 3647 “compliance”.

    The first point is that RFC 3647 is an INFORMATIONAL RFC.  You can
    see this right at the top, where it says “Category:
    Informational”.  This means that it contains no requirements and
    it’s impossible to be out of compliance with it.  This is why I
    put quotes around “compliance”. Any requirements around it need to
    come from elsewhere, for example, a root program requirement that
    requires a particular document to be in RFC 3647 format. But
    that’s vague and informal, because 3647 doesn’t have requirements,
    it just has an outline and suggested contents.  It’s not 100%
    precise what “MUST be in RFC 3647 format” means, and we need to
    just acknowledge that (specifying it precisely would be a colossal
    waste of time).

    So what does “RFC 3647 format” mean? RFC 3647’s outline only
    covers the first two levels.  So “Section 3.2: Initial Identity
    Validation” is a RFC 3647 section header, and most reasonable
    interpretations of “RFC 3647 format” would require it to exist
    with that or a substantially similar name and contents.

    Section 3.2.1, on the other hand, is not an RFC 3647 section. 
    It’s common to have a third level of headers that mirror the
    “bullet points” in the suggested content for the section, but
    those are just unordered bullet lists in RFC 3647.  Claiming that
    section 3.2.1 of a document in RFC 3647 must describe private key
    protection goes beyond what RFC 3647 says.  Section 3.2 just
    “contains the following elements”, so private key protection is
    just one of several topics that one might discuss in section 3.2. 
    It could be section 3.2.1, but it could be elsewhere in 3.2, and
    it’s perfectly fine for 3.2.1 to not exist, have different
    content, etc.

    Figuring out where section 11.1 goes is not trivial, but at first
    glance, section 3.2 is not an unreasonable choice, and I can
    understand why Inigo made it.  And there isn’t a compliance reason
    why it can’t be section 3.2.1, if that’s what we want.

    Of course, we could convert the recommended bulleted sections to a
    numbered list of subsections (we often do elsewhere), in which
    case section 3.2.1 could be “Private Key Protection” with contents
    “No Stipulation”.  If we do that, I suggest we follow the rest of
    the bullets as well.

    Either way works.

    -Tim

    *From:* Dimitris Zacharopoulos <[email protected]>
    <mailto:[email protected]>
    *Sent:* Friday, December 1, 2023 10:48 AM
    *To:* Inigo Barreira <[email protected]>
    <mailto:[email protected]>
    *Cc:* Tim Hollebeek <[email protected]>
    <mailto:[email protected]>; CA/B Forum Server Certificate
    WG Public Discussion List <[email protected]>
    <mailto:[email protected]>
    *Subject:* Re: [Servercert-wg] SC-065: Convert EVGs into RFC 3647
    format pre-ballot

    We MUST comply with RFC 3647 which means that we must include
    sections that are listed in the outline of 3647, and if we have
    nothing to say, we leave it empty. We can't "hijack" the numbering
    just because we have no requirements to describe.

    That's my interpretation of the RFC 3647 compliance. Perhaps
    others can chime in and state their opinion.


    Thanks,

    DZ.

    Dec 1, 2023 14:50:23 Inigo Barreira <[email protected]>:

        Thanks Dimitris.

        I think that strictly speaking, in RFC 3647 this section is
        the 4.3.2 Initial Identity Validation and the first bullet is
        about proving the possession of the private key, but there´s
        no specific section other than the general approach that we´ve
        implemented.

        That said, the current EVG does not include anything about the
        possession of the private key because that´s covered in the
        TLS BRs so that section does not exist in the EVGs and
        therefore I didn´t know how to avoid/implement it.

        I decided to continue with the normal numbering for an easy
        checking, so all 11 section is moved into section 3.2 and the
        rest of the sub-numbers do not change (so 11.1 would be 3.2.1,
        11.1.1 would be 3.2.1.1, etc.)

        I understand your point but I think we can´t create a section
        3.2.1 for private key possession because there´s no such a
        text in the EVGs (and don´t think we should add anything new,
        even a NA for that) and don´t know which other sections we can
        create under 3.2 that can break the current equivalence, which
        again was done for an easy comparison.

        So, what would you suggest to “comply” with that? I don´t have
        a clear idea.

        Regards

        *De:*Dimitris Zacharopoulos (HARICA) <[email protected]>
        *Enviado el:* jueves, 30 de noviembre de 2023 13:16
        *Para:* Inigo Barreira <[email protected]>; Tim
        Hollebeek <[email protected]>; CA/B Forum Server
        Certificate WG Public Discussion List <[email protected]>
        *Asunto:* Re: [Servercert-wg] SC-065: Convert EVGs into RFC
        3647 format pre-ballot

        CAUTION: This email originated from outside of the
        organization. Do not click links or open attachments unless
        you recognize the sender and know the content is safe.

        Inigo,

        As I am working to migrate the EV Guidelines into the EV Code
        Signing Baseline Requirements I took a look at the mapping you
        provided for the EV Guidelines and noticed that you are
        proposing migration of EVG section 11.1 into section 3.2.1.
        This particular section is labeled "Method to prove possession
        of private key" in RFC 3647 so I don't think it is
        appropriate. I think it's best to create new subsections under
        3.2.

        Thanks,
        Dimitris.

        On 8/9/2023 7:54 μ.μ., Inigo Barreira wrote:

            Hi all,

            Attached you´ll find the EVG v1.8.0 with comments in all
            sections indicating where those sections, and the content,
            have been moved into the new EVG RFC3647 format. So, with
            this document, plus the redlined version, I hope you can
            have now a clearer view of the changes done.

            Let me know if you need anything else to clarify the new
            version.

            Regards

            *De:*Inigo Barreira <[email protected]>
            <mailto:[email protected]>
            *Enviado el:* martes, 29 de agosto de 2023 17:06
            *Para:* Tim Hollebeek <[email protected]>
            <mailto:[email protected]>; Dimitris
            Zacharopoulos (HARICA) <[email protected]>
            <mailto:[email protected]>; CA/B Forum Server Certificate
            WG Public Discussion List <[email protected]>
            <mailto:[email protected]>
            *Asunto:* RE: [Servercert-wg] SC-065: Convert EVGs into
            RFC 3647 format pre-ballot

            Thanks Dimitris and Tim.

            I did something of that internally but didn´t reflect on
            the document, so will try to reproduce to have it clearer.

            OTOH, and as indicated in the PR, the whole section 11 has
            been placed in section 3.2 keeping the rest of the
            numbering. So, for example:

            EVG EVG3647

            11.1 3.2.1

            11.1.1 3.2.1.1

            11.1.2 3.2.1.2

            11.1.3 3.2.1.3

            11.2 3.2.2

            11.2.1 3.2.2.1

            ….. ….

            11.13 3.2.13

            11.14 3.2.14

            11.14.1 3.2.14.1

            11.14.2 3.2.14.2

            11.14.3 3.2.14.3

            Hope this can clarify the main difficult that I found in
            the document, where to place it and how.

            Regards

            *De:*Tim Hollebeek <[email protected]>
            *Enviado el:* martes, 29 de agosto de 2023 16:59
            *Para:* Dimitris Zacharopoulos (HARICA)
            <[email protected]>; Inigo Barreira
            <[email protected]>; CA/B Forum Server
            Certificate WG Public Discussion List
            <[email protected]>
            *Asunto:* RE: [Servercert-wg] SC-065: Convert EVGs into
            RFC 3647 format pre-ballot

            CAUTION: This email originated from outside of the
            organization. Do not click links or open attachments
            unless you recognize the sender and know the content is safe.

            Yes, exactly.  I would like to see a list that shows that
            EVG-classic section 1.4 is now in EVG-3647 section 4.1. 
            Then I can look at where the new text landed, see how the
            conversion was handled, we can all verify that nothing was
            lost or left out, etc.

            Without that, anyone attempting to review the document is
            forced to recreate the mapping just to figure out where
            everything went and that nothing was missed or put in the
            wrong place.  Redlines are not sufficient when large
            amounts of text are moving around to different places.

            I’m saying this because from my spot-checking, the
            conversion appears to be pretty good, and I’d like to be
            able to do a final verification that it’s mostly correct
            so I can endorse.

            -Tim

            *From:*Dimitris Zacharopoulos (HARICA) <[email protected]
            <mailto:[email protected]>>
            *Sent:* Tuesday, August 29, 2023 7:58 AM
            *To:* Inigo Barreira <[email protected]
            <mailto:[email protected]>>; CA/B Forum Server
            Certificate WG Public Discussion List
            <[email protected]
            <mailto:[email protected]>>; Tim Hollebeek
            <[email protected]
            <mailto:[email protected]>>
            *Subject:* Re: [Servercert-wg] SC-065: Convert EVGs into
            RFC 3647 format pre-ballot

            Hi Inigo,

            You can take some guidance from previous successful
            efforts to convert existing documents into RFC 3647
            format. The latest attempt was in the Code Signing BRs
            conversion in May 2022. Check out the mapping document and
            the comments in the ballot discussion period
            
<https://lists.cabforum.org/pipermail/cscwg-public/2022-May/000795.html>.

            For each existing section/paragraph, it would be nice to
            have a comment describing where that existing language
            will land in the converted document (destination). This
            will allow all existing text to be accounted for.

            During this process, you might encounter duplicate or
            redundant text which needs to be flagged accordingly. You
            might also get into some uncertainty as to which RFC3647
            section is a best fit for existing text that might require
            additional discussion.

            I hope this helps.


            Dimitris.

            On 29/8/2023 12:42 μ.μ., Inigo Barreira via Servercert-wg
            wrote:

                Hi Tim,

                See attached redlined and current versions. I just
                used what Martijn suggested yesterday but let me know
                if this is what you were looking for.

                Regards

                *De:*Tim Hollebeek <[email protected]>
                <mailto:[email protected]>
                *Enviado el:* lunes, 28 de agosto de 2023 19:49
                *Para:* Inigo Barreira <[email protected]>
                <mailto:[email protected]>; CA/B Forum Server
                Certificate WG Public Discussion List
                <[email protected]>
                <mailto:[email protected]>
                *Asunto:* RE: SC-065: Convert EVGs into RFC 3647
                format pre-ballot

                CAUTION: This email originated from outside of the
                organization. Do not click links or open attachments
                unless you recognize the sender and know the content
                is safe.

                Thanks for doing this Inigo … I know re-organizations
                like this are a lot of work and fall very much in the
                category of “important but not fun”. So thanks for
                taking an initial stab at this.

                Is there a mapping that shows where all the original
                text ended up?  I think that’s going to be essential
                for people to be able to review this.  I did some spot
                checking, and your conversion looks pretty good, but I
                wasn’t able to do a more detailed review without a
                mapping.

                -Tim

                *From:*Servercert-wg
                <[email protected]
                <mailto:[email protected]>> *On
                Behalf Of *Inigo Barreira via Servercert-wg
                *Sent:* Monday, August 28, 2023 5:20 AM
                *To:* CA/B Forum Server Certificate WG Public
                Discussion List <[email protected]
                <mailto:[email protected]>>
                *Subject:* [Servercert-wg] SC-065: Convert EVGs into
                RFC 3647 format pre-ballot

                Hello,

                The current Extended Validation Guidelines (EVGs) are
                written in a non-standardized format. For many years
                it has been discussed to convert this document into
                the RFC 3647 format and follow the standardized model
                for this type of documents.

                Given that this has been known for several years, I
                have prepared the following ballot text, which
                converts the EVGs into the RFC 3647 format:

                EVGs based on RFC3647 by barrini · Pull Request #440 ·
                cabforum/servercert (github.com)
                
<https://url.avanan.click/v2/___https:/github.com/cabforum/servercert/pull/440___.YXAzOmRpZ2ljZXJ0OmE6bzoyOGIxNWVhZGVmZDlkZTM0NjQzZTA3YTlmYTA2MzM5YTo2OmExZWM6NGZmMGEzM2U0ZWZjOTU4MTM1NWRkNjU3ZDE5YjU3Y2YxNzg1NWU0ZTVjYzkzY2NjM2M0MWU5MzEyYzJmZTQ0NzpoOkY>

                I am currently seeking two endorsers as well as any
                feedback on the ballot content itself (wording,
                effective dates, etc.).

                Thanks,

                _______________________________________________

                Servercert-wg mailing list

                [email protected]
                <mailto:[email protected]>

                https://lists.cabforum.org/mailman/listinfo/servercert-wg
                <https://lists.cabforum.org/mailman/listinfo/servercert-wg>


_______________________________________________
Servercert-wg mailing list
[email protected]
https://lists.cabforum.org/mailman/listinfo/servercert-wg























					Reply via email to