cabforum / servercert Goto Github PK

I would like to suggest to remove ETSI TS 102 042 as acceptable audit scheme for two reasons:

1. The most important root store is not accepting ETSI TS 102 042 audits any more: mozilla/pkipolicy@49a0711
2. The ETSI TS 102 042 audit scheme is referencing heavily to the pre-1.3.0-version of the BRGs

==> Both reasons together should be a sufficient reason to remove ETSI TS 102 042 from the BRGs.

The Baseline Requirements, Section 4.9.1.1, allow for up to five days for revocation if "methods have been developed that can easily calculate it {the private key} based on the Public Key"

However, the BRs also require revocation in 24 hours if the Private Key has been compromised.

Given that the 24 hour revocation overrides the five day revocation requirement, and given that the determination of a Debian Weak Key is, effectively, a lookup in a list of compromised keys, this section should be adjusted to clearly distinguish from the computationally-feasible-but-not-yet-performed type of weakness (e.g. ROCA) with the known-compromised scenario (e.g. Debian Weak Keys)

We're talking through how issues work.

In Section 7.1.6.1 of the Baseline Requirements, it reads as follows: https://github.com/cabforum/documents/blob/6e0b8e61590164eb2d686ddcf266b189f46fc636/docs/BR.md#L1803-L1807
and
https://github.com/cabforum/documents/blob/6e0b8e61590164eb2d686ddcf266b189f46fc636/docs/BR.md#L1812
and
https://github.com/cabforum/documents/blob/6e0b8e61590164eb2d686ddcf266b189f46fc636/docs/BR.md#L1818

In effect, if a certificate asserts a DV OID, then it MUST NOT contain an organizationName. Similarly, if it asserts an OV OID, then it MUST contain an organizationName.

As stated in Section 7.1.6.1, these requirements apply to Root CAs, Subordinate CAs, and End-Entity certificates. However, this requirement prevents a Subordinate CA certificate from explicitly listing both the DV OID and the OV OID, which it's required to to do if it wishes to issue both DV and OV certificates.

Normally, this would be handled by having the subordinate CA use the anyPolicy OID. However, this is prohibited by Section 7.1.6.3 if the Subordinate CA is cross-certified or independently operated, as it reads:
https://github.com/cabforum/documents/blob/6e0b8e61590164eb2d686ddcf266b189f46fc636/docs/BR.md#L1824-L1827

To resolve this, one approach would be to move the initial sentence of 7.1.6.1 into 7.1.6, and then clarify that the remainder of the OIDs' description are statement about the End Entity certificates and that CAs bearing the OIDs are subject to the overall BRs, but not necessarily with respect to the Subject profiles (which are dealt with in Section 7.1.4)

In "11.12.2. Denied Lists and Other Legal Black Lists" (2)(A)

Broken links:
(ii) BIS Denied Entities List - http://www.bis.doc.gov/Entities/Default.htm
(iii) US Treasury Department List of Specially Designated Nationals and Blocked Persons - http://www.treas.gov/ofac/t11sdn.pdf

New link for (iii):
https://www.treasury.gov/ofac/downloads/sdnlist.pdf

Chapter 6.2.2.4.6 of the BRGs say

The presence of the Request Token or Request Value contained in the content of a file where the Request Token or Random Value MUST NOT appear in the request.

I think this is a typo and should be written as

The presence of the Request Token or Random Value contained in the content of a file where the Request Token or Random Value MUST NOT appear in the request.

since there is no reference Request Value any more in this chapter.

Could anyone confirm this? Thank you :-)

BRGs 6.1.1.1 describe the generation of "CA Key Pairs", written in capital letters, but there is no definition of a CA Key Pair in BRG 1.6.1. This is especially irritating, as it is not totally clear, whether for example an OCSP responder Key Pair would be considered a CA Key Pair or not. I personally would say, it is no CA Key Pair but one could argue differently as it belongs to the CAs core infrastructure. To be totally precise, I would like to propose to add the following definition into the definitions chapter:

CA Key Pair A Key Pair that belongs to a Certificate that serves either as Root, Intermediate or Issuing CA.

In sleevi#23 (comment) , @pfuentes69 asked:

Any chance to consider removing the need to have an independent audit for technically-constrained subordinate CAs?

and further pointing out:

Typically a technically-constrained CA can be internally audited by the CA and is not in direct scope of independent audits. I think it should be considered an exception in this case for the need to have the qualified auditor's report as a particular activity, as in any case the creation of any subordinate will be already reviewed during the period audits and that should be enough.

As presently worded in Section 6.1.1.1, if the TCSC generates the key themselves, they're subjected to requiring a Key Generation report, while if the Root CA generates the key for them, and then later transfers the key to the TCSC, they are not.

The challenge is in making sure that no one misinterprets the section and allows a key generation for a TCSC (without audit), and then allows that to be used for a Subordinate CA by arguing that the key was previously generated, ergo 6.1.1.1 doesn't apply.

This effort may be a sub-section of the overall improvement to Key Lifecycle and about the necessary audit reports (Key Generation, a "Key Storage Report" as discussed in meeting 45, the annual audit report, and a key destruction report), clarifying the lifecycle expectations for Root CAs and Subordinate CAs (including Cross-Certificates and TCSCs)

Note: I believe this is an existing requirement in the text, and this is merely to make it unambiguously so.

When the CA/Browser Forum introduced Ballot 144, in 2015-02, permitting .onion domains, there was no special reservation for .onion by the IESG/IANA. That reservation did not happen until 2015-10, with the adoption of RFC 7686.

The language drafted in Ballot 144, and which largely has been maintained in its current form, requires that CA validate the Applicant's control over the .onion name by virtue of either demonstrating proof of possession of the public key or through connection to the .onion service. However, it makes no requirements about how the .onion name is formed/validated.

This ambiguity was resolved by RFC 7686, which normatively depends on the Tor address and rendezvous specifications, which then define the addressing form for v2 onion addresses (i.e. the base-32 encoding of the first 80 bits of the SPKI hash), and has later been updated to define v3 onion addresses as well.

Ballot SC27v3 unambiguously refers to the v3 specification for address creation, so the only potential ambiguity for CAs is with respect to whether or not those addresses formed and validated, according to Appendix F of the EV Guidelines, need to be well-formed according to the rendezvous specification.

I believe it is, for the following reasons:

• RFC 7686 normatively depends on these specifications for the creation of .onion names
• The EV Guidelines, by requiring a service either be connected to (which fundamentally requires the address be well-formed; Appendix F (2)(a)) or requires the CA validate the public key (which thus requires the CA to construct a .onion name according to that public key to ensure the relationship; Appendix F (2)(b)), functionally requires this

However, it wouldn't hurt in future work to be unambiguous that such addresses must be well-formed

According to the proposer of ballot SC25, the following should be updated in a cleanup ballot

The ballot reads:

"CAs MUST NOT perform validation using this method after 3 months from the IPR review date of Ballot SC25. CAs MAY continue to re-use information and validations for domains validated under this method per the applicable certificate data reuse periods".

The intent was that it would read:

"CAs MUST NOT perform validation using this method after June 3, 2020. CAs MAY continue to re-use information and validations for domains validated under this method per the applicable certificate data reuse periods".

From https://travis-ci.org/jsha/documents/builds/126943562:

$ pip install --user -r requirements.txt
...
Downloading/unpacking CairoSVG>=1.0.20 (from weasyprint->-r requirements.txt (line 1))
  Downloading CairoSVG-2.0.0rc1.linux-x86_64.tar.gz (73Kb): 73Kb downloaded
  Running setup.py egg_info for package CairoSVG
    Traceback (most recent call last):
      File "<string>", line 14, in <module>
    IOError: [Errno 2] No such file or directory: '/home/travis/build/jsha/documents/venv/build/CairoSVG/setup.py'
    Complete output from command python setup.py egg_info:
    Traceback (most recent call last):

This may be a version issue. I'll try pinning Weasyprint to a specific version in requirements.txt.

Reported by @bdaehlie at https://cabforum.org/pipermail/servercert-wg/2020-January/001561.html

Section 3.2.2.5 says:

"Note: IP Addresses verified in accordance with this section 3.2.5..."

I think that section reference was intended to say 3.2.2.5. Is there a cleanup ballot / PR open that we could fix this in?

There seems (to me) to be an inconsistency between §5.2 of Mozilla Root Policy, which very clearly prohibits CAs from generating Subscribers' key pairs for SSL Server certs, and §6.1.2 of the BRs which seemingly allows that. Or am I misinterpreting the latter? I'd like to be clarified in the BRs that subscriber key pair generation by the CA is a "MUST NOT", in line with the precise requirement set forth in Mozilla Root Policy.

Also, it's not clear in the BR if the CA is supposed to verify that the Applicant controls the private key corresponding to the public key to be certified. I have been following the discussion on msdp... In my view, this is a crucial obligation of the CA and should be clarified in the BR.

The "Bundesamt für Sicherheit in der Informationstechnik" (German Federal Office for Information Security) published a technical guidance TR-03116-3 which defines fundamental cryptographic requirements for governmental projects. In chapter 2.1.3 it defines three curves that have to be supported as a minimum for SSL/TLS. One of this three curves is the brainpoolp256r1 curve. This curve is not allowed acc. BRGs chapter 6.1.5.

I would like to propose, that this curve becomes allowed by the BRGs as well.

BR.md seems to be large enough that GitHub's rich diff generator takes close to 5 seconds, which is their internal timeout per discussions with GitHub Support. That means viewing the rich diff sometimes produces a timeout, for example at https://github.com/cabforum/documents/pull/24/files.

It sounds like GitHub won't change the timeout, and the code is not open source so we don't have the option of optimizing it.

I'd like to split up BR.md into multiple files, one per section, and recombine them at build time. That will probably make the rich diff generator finish safely below the timeout.

Any objections? @pzb?

In SC27, support for v3 onion addresses was introduced, allowing both DV and OV certificates to be issued.

Support for v2 onion addresses was intentionally not removed from the EV Guidelines, in order to allow continued usage of existing names.

While Appendix F of the EV Guidelines was updated to permit the issuance of V3 addresses, provided they're validated as described within Appendix C of the Baseline Requirements, the normative requirement within Appendix F to include the Tor Service Descriptor hash was not removed.

As discussed in and during SC27, the Tor Service Descriptor hash is not necessary for V3 certificates.

In the current form, this creates a challenge for CAs, in that if the issued certificate is DV/OV/IV, and the address is V3, the extension is not needed, but if the certificate is EV, the extension is still required to be included. Given that it's not necessary to include this extension for v3 addresses, the requirement should be normalized (as not required) across all profiles.

Currently, the Baseline Requirements require that the Subscriber Agreement includes the following:

8. Acknowledgment and Acceptance: An acknowledgment and acceptance that the CA is
entitled to revoke the certificate immediately if the Applicant were to violate the terms of
the Subscriber Agreement or Terms of Use or if the CA discovers that the Certificate is
being used to enable criminal activities such as phishing attacks, fraud, or the distribution
of malware.

However, this does not require that the Subscriber accepts that the CA is entitled to revoke for any of the reasons stated within their CP/CPS or Section 4.9.1.1 (or, indirectly, through 4.9.1.2). It only places the acceptance based on the Subscriber actions, without recognizing that the CA may have cause to revoke for CA-related actions.

One possible suggestion is:

8. Acknowledgment and Acceptance: An acknowledgment and acceptance that the CA is
entitled to revoke the certificate immediately if the Applicant were to violate the terms of
the Subscriber Agreement or Terms of Use or if the CA is determines revocation is
necessary according to these Baseline Requirements.

While more wordsmithing and discussion is needed, within the CA/Browser Forum, the replaced clause is already addressed within the CA's Baseline Requirements, and any CA-specific modifications are addressed by 4.9.1.1 requiring revocation MUST happen within 5 days if

10. Revocation is required by the CA's Certificate Policy and/or Certification Practice Statement;

3.2.2.4.12 is a duplicate of 3.2.2.4.1 and will remain so until Aug 2018. Since BR expects the CAs to list the validation method used for each cert request, shouldn't this be fixed in the meantime so CAs are not listing them both (or is it acceptable to list either one)?

3.2.2.5.6 / 3.2.2.5.7 reference https://tools.ietf.org/html/draft-ietf-acme-ip-04

This is now published as RFC 8738. The references should be updated, presumably through the introduction of a new method.

You can see the diff between draft-04 and the final RFC at http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://tools.ietf.org/id/draft-ietf-acme-ip-04.txt&url2=https://tools.ietf.org/rfc/rfc8738.txt

This was originally raised on the servercert mailing list

Baseline Requirements 1.6.7, Section 7.1.4.3, sets the permitted fields and validation requirements.

The current BRs in 3.2.2.4 state that
"For purposes of domain validation, the term Applicant includes the Applicant's Parent Company, Subsidiary Company, or Affiliate."

Since the adoption of IV Certificates, this sentence should include Applicants that are Individual Natural Persons. Here is a proposed amendment.

"For purposes of domain validation, the term Applicant includes the Applicant's Parent Company, Subsidiary Company, Affiliate or the Applicant as an individual Natural Person".

BRGs require that the revocation request procedure SHALL be disclosed in the CPS:

Chapter 4.9.3:

The CA SHALL publicly disclose the instructions through a readily accessible online means and in section 1.5.2 of their CPS.

I think it would be reasonable, if a CA could also disclose this information in the CP, when the CP acts as an umbrella for a set of CPSes. In that case every CPS could only hold a 'pointer' to the CP. How do you think about this?

This came up during #142 / #165 about lists of requirements that are presented as paragraphs, creating concerns on conjunctions like and/or and which part they apply to.

An example is in Section 3.2.2.3

It really should be abbreviated as "QGTIS".

The start of chapter "1.3.4. Relying Parties" misses a double quote in the PDF file on https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.7.0.pdf

But it is there in the Markdown rendering at GitHub.

So I believe there is a problem with rendering the PDF file.

Chapter 4.9.1.1. says

1. The Subscriber requests in writing that the CA revoke the Certificate;

I'm not very good in English, but I think there is a s missing at the end of revoke

1. The Subscriber requests in writing that the CA revokes the Certificate;

Instead of referencing 3.3.1 (which is empty), this reference should point to section 4.2.1.

@timfromdigicert this looks like a minor change and could be added on your list of minor cleanups.

EV Guidelines, v1.7.1, includes two compliance dates that have since passed, and which can be cleaned up in the next cleanup ballot.

Section 8.2.2, Disclosure:

https://github.com/cabforum/documents/blame/16a5a9bb78a193266f8d1465de1ee5a1acf5d184/docs/EVG.md#L346

Effective 2018/05/31, CP/CPSes must follow RFC 3647

Section 9.8.2, .8.2 CA/Browser Form Organization Identifier Extension:

https://github.com/cabforum/documents/blame/16a5a9bb78a193266f8d1465de1ee5a1acf5d184/docs/EVG.md#L668

Effective 2020/01/31, this extension MUST be present.

Change "443 (http)" to "443 (https)"

During the 2020-06-25 call, the suggestion was raised of having a bare template, in RFC 3647 format, so that CWGs introducing new Final Guidelines and Final Maintenance Guidelines can quickly start and/or align existing requirements.

Ballot SC17, v7 introduced the requirements for the use of the organizationIdentifier.

However, there are a few issues with the present text, as reflected in version 1.7.1

• Appendix H, for NTR, incorrectly refers to "Section 9.8.1", which defines the Subject Alternative Name. This should be Section 9.8.2, the "CA/B Forum Organization Identifier Field"
• The Relevant Dates table makes reference to the "Subject Organization Identifier Extension". It is the only use of this term. The term used in 9.8.2 is "CA/Browser Forum Organization Identifier field"

Passing this report/suggestion along from a community member.

Relating to the definition of "Critical Vulnerability":

1. This link seems outdated:

http://nvd.nist.gov/home.cfm

Perhaps a better link would be:

https://nvd.nist.gov/vuln-metrics/cvss

This also has the advantage of being an https link.

2. CVSS v3.0 defines critical as 9.0 or above. The NetSec guidelines currently say CVSS 7.0 or higher is critical. Should the NetSec guidelines be changed to define critical as 9.0, in line with the CVSS ratings, or is NetSec intentionally lowering the bar for what's considered critical to 7.0?

The profile for Subscriber Certificates, in 7.1.2.3, currently permits the values id-kp-serverAuth, id-kp-clientAuth, as well as any other policies:

https://github.com/cabforum/documents/blob/d9b360f15d6ce3079c735e69539666e09b0c85e7/docs/BR.md#L1668

@dougbeattie raised a question in the 2020-06-18 Validation WG call as to whether it's required for a certificate to assert id-kp-serverAuth if it is going to assert one of the CA/Browser Forum Reserved Policies, established in Sections 1.2 and Sections 7.1.6.1.

The discussion included analyzing how a certificate issued to a server could contain ONLY id-kp-clientAuth, assert a DV OID, and be used for server-to-server mutual authentication, where server means "hostname" or "service", raising a question whether that was in scope of Section 1.1:

https://github.com/cabforum/documents/blob/d9b360f15d6ce3079c735e69539666e09b0c85e7/docs/BR.md#L30

Or whether such certificates were out of scope, by virtue of TLS still having a notion of client and server, and such server-to-server authentication may not be in scope, either by virtue of the protocol or by virtue of the EKU.

Fundamental questions that came up:

1. If a certificate ONLY asserts id-kp-clientAuth, and is issued from an in-scope subordinate, is that certificate in scope of the BRs?
2. If a certificate ONLY asserts id-kp-clientAuth, and asserts a BR OID, is that certificate in scope of the BRs?
3. Is the scope of the BRs defined by what asserts the CABF OIDs, what EKUs are asserted, or some combination thereof?
4. If it's by EKUs asserted, does the id-kp-clientAuth EKU fit within the scope, as it applies to asserting the CABF OIDs?

Bullet C currently reads:

such that end entity certificates issued from the subordinate CA Certificate will be in compliancy with section 7.1.2.4 and 7.1.2.5.

It should read:

such that end entity certificates issued from the subordinate CA Certificate will be in compliance with section 7.1.2.4 and 7.1.2.5.

This is a small typo/spelling error.

@timfromdigicert identified a useful improvement to the EV Guidelines:

The following text is current in the EV Guidelines, section 9.2.5:
“If the Jurisdiction of Incorporation or Registration does not provide a Registration Number, then the date of Incorporation or Registration SHALL be entered into this field in any one of the common date formats.”
Is there any reason why we shouldn’t standardize on an ISO 8601 date format like YYYY-MM-DD?
Obviously, this would require time to implement for CAs that might be using alternative formats, but I’m not sure what the value is of allowing flexibility in this particular field.

@sleevi agreed this would useful to align on. I echo that agreement as well; we should identify a well-specified date format compatible with the goals here (e.g. it's rare for incorporation dates to be more granular that Day+Month+Year).

Using ISO 8601's Complete Date format as Tim described seems like a good starting point (YYYY-MM-DD (e.g. 2020-01-23).

I already reported this issue to the CAB public mailing list but haven't received a feedback so far, therefor I open this issue.

It appear there is a wrong reference in the BRGs, chapter 8.4 “Topics covered by assessment”. This chapter includes the statement

The audit MUST be conducted by a Qualified Auditor, as specified in Section 8.3.

This should most probably read

... specified in Section 8.2

which describes “Identity/qualifications of assessor”. Section 8.3 is empty.

I would propose, this should be changed in one of the upcoming ballots. I would post this directly to the mailing list, but as not being a member, I’m prohibited from posting.

In Mozilla Bug 1650234, a discussion about the problem reporting method a particular CA used and documented within their CP/CPS met the expectations of browsers and the Baseline Requirements. The CP/CPS provided a contact e-mail within Section 1.5.2, but provided a supplementary Section 1.5.2.1 to be used for reporting specific events, and that was restricted in who can access that portal.

While there's nothing inherently problematic with having a problem reporting mechanism available specifically to Subscribers, the concern is whether or not the CA must also maintain a problem reporting mechanism for "other third parties", as described in Section 4.9.3 of the BRs.

That is, 4.9.3 requires that:

The CA SHALL provide Subscribers, Relying Parties, Application Software Suppliers, and other third parties
with clear instructions for reporting suspected Private Key Compromise, Certificate misuse, or other types of
fraud, compromise, misuse, inappropriate conduct, or any other matter related to Certificates. The CA SHALL
publicly disclose the instructions through a readily accessible online means and in section 1.5.2 of their CPS.

However, there's some ambiguity as to whether the only the instructions need to be available through a readily accessible online means, or whether the CA must also provide a problem reporting mechanism itself through a readily accessible online means.

This modification was introduced in CA/B Forum Ballot SC6, which was parallel to a Mozilla discussion about requiring CAs to support problem reporting via e-mail. While Mozilla ultimately declined to mandate e-mail (as opposed to other technologies), it's believed the intent was to at least support some form of readily accessible online means of problem reporting.

The language here can be clarified, and perhaps shifted in its requirements from 4.9.3 to 1.5.2 to greater emphasize the expectation of content by normatively describing it within that section.

@timfromdigicert, in the BRs section 1.6.1 in the definition of Domain Name Registrar:

"Domain Name Registrar: A person or entity that registers Domain Names under the auspices of or by agreement with: (i) the Internet Corporation for Assigned Names and Numbers (ICANN), (ii) a national Domain Name authority/registry, or (iii) a Network Information Center (including their affiliates, contractors, delegates, successors, or assigns)."

should be

"Domain Name Registrar: A person or entity that registers Domain Names under the auspices of or by agreement with: (i) the Internet Corporation for Assigned Names and Numbers (ICANN), (ii) a national Domain Name authority/registry, or (iii) a Network Information Center (including their affiliates, contractors, delegates, successors, or assignees)."

Section 6.1.1.3 requires CAs to reject keys if they do not comply with 6.1.5 / 6.1.6, or if they are known weak.

However, the known weak language could be strengthened, by using the same language from 4.9.1.1:

The CA is made aware of a demonstrated or proven method that exposes the Subscriber's Private Key to compromise, methods have been developed that can easily calculate it based on the Public Key (such as a Debian weak key, see http://wiki.debian.org/SSLkeys), or if there is clear evidence that the specific method used to generate the Private Key was flawed.

A demonstrated (to that CA) key compromise would be a clear demonstration that exposes the Subscriber’s Private Key to compromise.

I want to make an edit to the Branch 169 - rebased, but it looks like it needs to be re-based again. How do I do that or can someone do that for me? I don't want to get too far out of sync with the Master branch.

@RufusJWB pointed out that the first paragraph of BR section 6.1.1.1 is unclear because it implies that it does not apply to subordinate CA key pairs that are not generated by the Root CA:

For Root CA Key Pairs that are either (i) used as Root CA Key Pairs or (ii) Key Pairs generated for a subordinate CA that is not the operator of the Root CA or an Affiliate of the Root CA, the CA SHALL:

Rufus proposed the following clarification:

For CA Key Pairs that are either (i) used as Key Pairs for Root CAs or (ii) Key Pairs used for subordinate CAs, operated by an operator that is not the operator of the Root CA or an Affiliate of the Root CA, the CA SHALL:

Section 3.2.2.4.10 title should say "TLS Using a Random Value"

Section 3.2.2.4.18:

Change "The file containing the Request Token or Random Number"

to "The file containing the Request Token or Random Value"

The wording for the length of the serial number in chapter 7.1 BRGs seems to be a little bit ambiguous:

CAs SHALL generate non-sequential Certificate serial numbers greater than zero (0) containing at least 64 bits of output from a CSPRNG.

This could allow the construction of a serial number as following (in pseudo code)

serialNumber = CSPRNG.getBitsArray(64).convertTo32BitNumber()

which results in a 4 Byte long serial number that can be argued to be BRG compliant. This would be of course against the spirit of this chapter, but not totally clear against the wording.

To be unambiguous here, I would like to propose the following wording:

CAs SHALL generate non-sequential Certificate serial numbers with a length of at least 8 bytes, greater than zero (0), and containing at least 64 bits of output from a CSPRNG.

As raised by Trev on the servercert-wg list, the wording in section 5.4.1 is ambiguous.

At question is whether "log entries" in the following:
https://github.com/cabforum/documents/blob/6e0b8e61590164eb2d686ddcf266b189f46fc636/docs/BR.md#L1318-L1322

refers to 3.f
https://github.com/cabforum/documents/blob/6e0b8e61590164eb2d686ddcf266b189f46fc636/docs/BR.md#L1316
or whether it refers to the overall section 5.4.1
https://github.com/cabforum/documents/blob/6e0b8e61590164eb2d686ddcf266b189f46fc636/docs/BR.md#L1293

Now that RFC 8737 has been published, 3.2.2.4.10 can be sunset, replaced with a new method based on RFC 8737.

In zmap/zlint#343, there were questions raised about whether the special use in.arpa and in6.arpa domains may make use of wildcards.

BRs section 3.2.2.6 has special provisions for when the wildcard appears to the left of particular domain labels, and it’s ambiguous whether or not that section is triggered, based on how IANA administers that root zone and delegates to the RIRs.

The Baseline Requirements currently refer to RFC 6844 as modified by Errata.

This should be updated to depen on RFC 8659, which can be done without errata.

As noted on the questions@ list, Section 6.1.1.1 of the Baseline Requirements uses an ambiguous construction when talking about CA Key Pair generation.

The term used is "Root CA Key Pair", but this is used interchangably to also discuss requirements that are applicable to Subordinate CAs. This is exacerbated by the intersection with #127

In particular, it raises the question of whether Subordinate CAs are required to have a Qualified Auditor issue a report, if the Subordinate CA themselves generates the Key Pair, as opposed to the Root CA generating and then securely delivering to the Subordinate CA.

The first versions of the Guidelines used a lot of copy-paste from other formats (mostly Microsoft Word). During this process, we currently see lots of double spaces and other "Markdown-unfriendly" paragraphs on GitHub.

We should try to update the existing versions without modifying language, numbering or any text, in order to create versions that are more "Markdown-friendly" and can produce better visual results in various Markdown viewers.

It would be very helpful if you would tag the commits that reflect a specific version of the BRG. For example you could tag this commit with the tag v1.5.1 . This would make life easier preparing the annual BRG audit.