Thanks, Bruce.
*From:*Servercert-wg <[email protected]> *On Behalf
Of *Inigo Barreira via Servercert-wg
*Sent:* Monday, December 4, 2023 2:15 PM
*To:* Dimitris Zacharopoulos (HARICA) <[email protected]>; Tim
Hollebeek <[email protected]>
*Cc:* CA/B Forum Server Certificate WG Public Discussion List
<[email protected]>
*Subject:* [EXTERNAL] Re: [Servercert-wg] SC-065: Convert EVGs into
RFC 3647 format pre-ballot
Dimitris, I think that we should focus on the EVG not on the CP/CPS.
The CA´s CP/CPS will have that 3. 2. 1 section because it´s in the TLS
BRs but that does not mean that the EVG must have also that section
3. 2. 1 (BTW, the section exist in the
Dimitris,
I think that we should focus on the EVG not on the CP/CPS. The CA´s
CP/CPS will have that 3.2.1 section because it´s in the TLS BRs but
that does not mean that the EVG must have also that section 3.2.1
(BTW, the section exist in the TLS BRs but with no content). At the
end of the day, every CA issuing TLS certs will have to follow the TLS
BRs and EVGs and then accommodate their CP/CPSes according to both
documents.
I understand your point to be stricter in the implementation of that
specific point but for every CA to change/update their current CP/CPS
with the new EVG in the RFC 3647 format, would find it easier to where
to make those changes/adjustments in their own CP/CPS if we can
convert easily the current section 11 into 3.2 and not to start
looking into different numbers to make that change.
Regards
*De:*Dimitris Zacharopoulos (HARICA) <[email protected]>
*Enviado el:* lunes, 4 de diciembre de 2023 20:02
*Para:* Tim Hollebeek <[email protected]>; Inigo Barreira
<[email protected]>
*CC:* 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.
FWIW, there are informational RFCs that include SHOULD requirements (I
didn't check for other informational RFCs that might contain SHALL
requirements). Take a look at RFC 8894
<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8894__;!!FJ-Y8qCqXTj2!cDhQeVwolbnJ6hdDSRwEKs2w1lDqgYkiUHc4ApuZ3kUIV3BDxbQ0XAAIsJDbSWbqRevehayXBz_oc-H9s1zZDBI0YJAc7w$>.
I agree that there seems to be some ambiguity in the REQUIRED CP/CPS
structure but the entire reasoning behind using the "RFC 3647 format"
was to align CP and CPS documents so that comparisons can be made
across different CAs. If one CA reads that they must follow a 2-level
structure based on section 4, and another CA reads that they must
follow the structure of section 6 of the RFC, we're not meeting the
goal for alignment and easy comparisons.
Digicert's CPS seems to follow the structure of section 6 of RFC 3647.
Has anyone spotted a CPS claiming compliance with the TLS BRs that is
not following the section 6 structure of 3647?
If all existing public CAs follow the structure of section 6 of 3647
in their CP/CPS documents, we can just clarify that the expectation is
what Ben mentioned in
https://github.com/BenWilson-Mozilla/pkipolicy/commit/1a94642cb95017cf382e4e93811db16a2342a806
<https://urldefense.com/v3/__https:/github.com/BenWilson-Mozilla/pkipolicy/commit/1a94642cb95017cf382e4e93811db16a2342a806__;!!FJ-Y8qCqXTj2!cDhQeVwolbnJ6hdDSRwEKs2w1lDqgYkiUHc4ApuZ3kUIV3BDxbQ0XAAIsJDbSWbqRevehayXBz_oc-H9s1zZDBIIavReJg$>,
so that we address this ambiguity. We probably don't even need an
effective date if it causes no issue on existing CAs.
My point is that if we leave this open to interpretation, we can't
compare CP/CPS sections across multiple CAs efficiently, and this
defeats the whole purpose of the requirement to structure CP/CPS
documents according to RFC 3647. We might as well abandon the idea of
converting the EV Guidelines into that format.
I believe that the intent has always been to enforce a "stricter"
alignment. But if indeed there are deviations, I'd support some
stricter language to align CP/CPS documents according to section 6 of
RFC 3647 even with a future effective date :)
Dimitris.
On 4/12/2023 7:27 μ.μ., Tim Hollebeek wrote:
Yeah, the fact that the section 6 outline goes deeper than the
actual described format in section 4 is annoying, and you’re
right, it’s probably the source of these disagreements. I always
look at section 4, because it has the actual guidance about what
sort of information should be considered for inclusion.
This is what happens when people try to turn informational
documents into normative requirements. You have to try to
interpret what phrases like “are strongly advised to adhere”,
which isn’t even a RFC 2119 SHOULD. And it can’t even be a
SHOULD, because as an informational RFC, it is prohibited from
having requirements, even SHOULDs! That’s why it’s written that
way. Also, informational RFCs are not examined as closely for
inconsistencies (because there are no requirements!) which is how
divergences like section 4 vs 6 happen. It wasn’t intended to be
used as a compliance document.
I still think what Inigo did is perfectly fine, although there are
lots of other perfectly fine solutions, too. What we need to be
discussing is what’s best for us, not RFC 3647 requires, because
RFC 3647 has infinite leeway. As Aaron and I have been pointing
out, you’ll find lots of divergences at level three, and there’s
even lots of additional content in level two, just because a lot
of newer content doesn’t really have a good fit in RFC 3647.
Now, that said, we might want to be more strict in the future, and
if we choose to do so, we can be. I just don’t want people
overstating what the rules actually are, because a lot of people’s
time has been wasted enforcing RFC 3647 in a way that is far
stricter than was ever intended (one of the reasons I’m so vocal
on this issue is because I got this point of view from one of the
original authors).
-Tim
*From:*Dimitris Zacharopoulos (HARICA) <[email protected]>
<mailto:[email protected]>
*Sent:* Saturday, December 2, 2023 5:26 AM
*To:* Tim Hollebeek <[email protected]>
<mailto:[email protected]>; Inigo Barreira
<[email protected]> <mailto:[email protected]>
*Cc:* 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 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
<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc3647*section-6__;Iw!!FJ-Y8qCqXTj2!cDhQeVwolbnJ6hdDSRwEKs2w1lDqgYkiUHc4ApuZ3kUIV3BDxbQ0XAAIsJDbSWbqRevehayXBz_oc-H9s1zZDBKp_QdGmg$>)
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://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc3647*section-4.3.2__;Iw!!FJ-Y8qCqXTj2!cDhQeVwolbnJ6hdDSRwEKs2w1lDqgYkiUHc4ApuZ3kUIV3BDxbQ0XAAIsJDbSWbqRevehayXBz_oc-H9s1zZDBIL19sP_w$>.
Does that make more sense?
Dimitris.
-Tim
*From:*Dimitris Zacharopoulos (HARICA) <[email protected]>
<mailto:[email protected]>
*Sent:* Friday, December 1, 2023 1:04 PM
*To:* Tim Hollebeek <[email protected]>
<mailto:[email protected]>; Inigo Barreira
<[email protected]> <mailto:[email protected]>
*Cc:* 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
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://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc3647*section-6__;Iw!!FJ-Y8qCqXTj2!cDhQeVwolbnJ6hdDSRwEKs2w1lDqgYkiUHc4ApuZ3kUIV3BDxbQ0XAAIsJDbSWbqRevehayXBz_oc-H9s1zZDBKp_QdGmg$>
("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://urldefense.com/v3/__https:/lists.cabforum.org/pipermail/cscwg-public/2022-May/000795.html__;!!FJ-Y8qCqXTj2!cDhQeVwolbnJ6hdDSRwEKs2w1lDqgYkiUHc4ApuZ3kUIV3BDxbQ0XAAIsJDbSWbqRevehayXBz_oc-H9s1zZDBLzwUxa3A$>.
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://urldefense.com/v3/__https:/url.avanan.click/v2/___https:/github.com/cabforum/servercert/pull/440___.YXAzOmRpZ2ljZXJ0OmE6bzoyOGIxNWVhZGVmZDlkZTM0NjQzZTA3YTlmYTA2MzM5YTo2OmExZWM6NGZmMGEzM2U0ZWZjOTU4MTM1NWRkNjU3ZDE5YjU3Y2YxNzg1NWU0ZTVjYzkzY2NjM2M0MWU5MzEyYzJmZTQ0NzpoOkY__;!!FJ-Y8qCqXTj2!cDhQeVwolbnJ6hdDSRwEKs2w1lDqgYkiUHc4ApuZ3kUIV3BDxbQ0XAAIsJDbSWbqRevehayXBz_oc-H9s1zZDBKpiKVP6w$>
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://urldefense.com/v3/__https:/lists.cabforum.org/mailman/listinfo/servercert-wg__;!!FJ-Y8qCqXTj2!cDhQeVwolbnJ6hdDSRwEKs2w1lDqgYkiUHc4ApuZ3kUIV3BDxbQ0XAAIsJDbSWbqRevehayXBz_oc-H9s1zZDBI3Tfxaxw$>
/Any email and files/attachments transmitted with it are intended
solely for the use of the individual or entity to whom they are
addressed. If this message has been sent to you in error, you must not
copy, distribute or disclose of the information it contains. _Please
notify Entrust immediately and delete the message from your system._/
