Re: [Servercert-wg] Voting Period Begins - Ballot SC-073: Compromised and Weak Keys

[Yoshihiko Matsuo via Servercert-wg]

JPRS votes YES to Ballot SC-073

Yoshihiko Matsuo

On 2024/04/26 9:00, Wayne Thayer via Servercert-wg wrote:

Purpose of Ballot SC-073

This ballot proposes updates to the Baseline Requirements for the Issuance and 
Management of Publicly-Trusted TLS Server Certificates related to weak and 
compromised private keys. These changes lie primarily in Section 6.1.1.3 
:

  *

6.1.1.3(4) clarifies that, for the purpose of this requirement, CAs shall 
be made aware of compromised keys using their existing notification 
mechanism(s).

  *

6.1.1.3(5) improves guidance for CAs around the detection of weak keys. 
Should this ballot pass, these changes become effective on November 15, 2024.

Notes:

  *

This ballot builds on the extensive work done by SSL.com in creating ballot 
SC-59v2 Weak Key Guidance. SSL.com’s contributions are appreciated.

  *

Thanks to Rob Stradling of Sectigo for the generation and publication of 
the set of Debian weak keys referenced in this ballot.

  *

The Debian weak keys requirements have been discussed extensively, including in the 
following threads: 
https://lists.cabforum.org/pipermail/servercert-wg/2024-March/004291.html 
and 
https://lists.cabforum.org/pipermail/servercert-wg/2024-April/004422.html 


  *

This ballot does not appear to conflict with any other ballots that are 
currently under discussion.


The following motion has been proposed by Wayne Thayer of Fastly, and endorsed 
by Brittany Randall of GoDaddy and Bruce Morton of Entrust.

— Motion Begins —

This ballot modifies the “Baseline Requirements for the Issuance and Management 
of Publicly-Trusted Certificates” (“Baseline Requirements”), based on Version 
2.0.3.

MODIFY the Baseline Requirements for the Issuance and Management of 
Publicly-Trusted TLS Server Certificates as specified in the following Redline:

Here is a link to the immutable GitHub redline: 
https://github.com/cabforum/servercert/compare/a65402cff89affe1fc0a1f0e49807c7e42e1608a...bee10c8e4a56815bffd59fab12cbd4044baa7cc0
 


— Motion Ends —

This ballot proposes a Final Maintenance Guideline. The procedure for approval 
of this ballot is as follows:

Discussion (7+ days)

  *

Start time: 2024-04-18 00:00:00 UTC

  *

End time: 2024-04-26 00:00:00 UTC

Vote for approval (7 days)

  *

Start time: 2024-04-26 00:00:00 UTC

  * End time: 2024-05-03 00:00:00 UTC


___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

Re: [Servercert-wg] [External Sender] Question regarding the id-ad-caIssuers accessMethod URI

[Clint Wilson via Servercert-wg]

I did a quick check, but was only able to find one recently issued leaf 
certificate that contained an https CA Issuers URI. There seems to be about 26 
CA certificates that do as well, but all were issued before 2019 except for 2. 
Of the 1 leaf and 2 CA certificates that are more recent, they’re all from CAs 
that have very limited root inclusion in the ecosystem and do not participate 
in the CA/BF afaict.

Not sure how relevant all that is, but just to share what I’d found. I’m sure 
others could do a more thorough job, but I don’t see clear signs that this is a 
widespread issue at least (phew! :)

Cheers,
-Clint

> On Apr 30, 2024, at 11:40 PM, Dimitris Zacharopoulos (HARICA) 
>  wrote:
> 
> Thanks Clint,
> 
> It would help doing some research in CENSYS to see if this is a real problem 
> or not. I will try to get some additional resources internally to help me 
> with this. In any case, this discussion might inspire some of the linting 
> software developers to write a lint expecting only http:// URLs in that field.
> 
> 
> Best regards,
> Dimitris.
> 
> On 1/5/2024 12:52 π.μ., Clint Wilson wrote:
>> Hi Dimitris,
>> 
>> My understanding is that the intent was indeed to restrict these to HTTP 
>> specifically. That is, the phrase “the only URLS present MUST be HTTP URLs” 
>> is intended to preclude the use of HTTPS, and not just to indicate that any 
>> scheme which relies on the Hypertext Transfer Protocol can be used.
>> 
>> Presumably when 5280 was drafted, the authors were aware of the updates 2817 
>> made to 2616, but chose not to reference those updates. Even if not, I 
>> concur with Ryan and my recollection is also that the discussion during 
>> SC-62’s formation did include this topic with the consensus (at that time) 
>> being that some fields would be restricted to using only HTTP URIs.
>> 
>> To your original questions:
>> Do Members agree with that interpretation? 
>> 
>> Yes
>> 
>> 
>> If this is the correct interpretation, would it be considered a 
>> violation of the BRs if a CA or end-entity certificate contains https:// 
>> URL in the id-ad-caIssuers accessMethod ? 
>> 
>> Yes, at least for certificates issued after SC-62 went into effect (maybe 
>> also for those prior, I just haven’t looked).
>> 
>> 
>> I'm afraid that this might not be as clear in the BRs as it should be, 
>> so if people agree with the above, we should probably update section 
>> 7.1.2.7.7 
>> 
>>  (and possibly other parts) to explicitly state that the allowed scheme 
>> is "http" and not "https", just like we do for the CRLDP in section 
>> 7.1.2.11.2 
>> 
>>  . 
>> 
>> I’m not convinced a clarification is worthwhile here. To be clear, I’m not 
>> opposed, I’m just not sure it’s something CAs are actively getting or likely 
>> to get wrong — if some are, then I would instead support such a 
>> clarification.
>> 
>> Cheers!
>> -Clint
>> 
>>> On Apr 25, 2024, at 5:41 AM, Dimitris Zacharopoulos (HARICA) via 
>>> Servercert-wg  
>>>  wrote:
>>> 
>>> Hi Ryan,
>>> 
>>> The question is not between HTTP vs FTP vs LDAP but specifically for "HTTP 
>>> URL" that could have two schemes "http" and "https".
>>> 
>>> RFC 2616 (June 1999) included only "http" and was updated in May 2000 by 
>>> RFC 2817  to include TLS 
>>> Within HTTP/1.1 ("https").
>>> 
>>> I hope this clarifies the issue.
>>> 
>>> 
>>> Dimitris.
>>> 
>>> On 25/4/2024 3:29 μ.μ., Ryan Dickson via Servercert-wg wrote:
 It's my understanding that the intent of the updates made in SC-62 were to 
 prohibit any non-HTTP URI. This was discussed in:
 
 1) at least one historical GitHub discussion 
  (referenced in ballot 
 preamble 
 ):
 
 "authorityInformationAccess: This is a new requirement.
 BRs 7.1.2.2 (c) notes that it SHOULD contain the HTTP URL of the Issuing 
 CA's certificate and MAY contain the HTTP URL of the Issuing CA's OCSP 
 responder.
 Some questions were raised about whether this means other URLs, other 
 schemes, or multiple URLs can be included. Similar to 
 crlDistributionPoints, the ordering of URLs implies processing semantics 
 on clients, and only particular URL schemes are supported. Namely, if one 
 of the two supported access methods are present (CA issuer or OCSP), then 
 the only URLs present MUST be HTTP URLs, and MUST be listed in order of 
 priority.
 This prohibits the use of other access methods, as they are not used in 
 the Web PKI."
 
 and 2) Corey's Validation 

Re: [Servercert-wg] Voting Period Begins - Ballot SC-073: Compromised and Weak Keys

[Andrea Holland via Servercert-wg]

VikingCloud votes yes on SC-073.

Regards,
Andrea Holland


From: Servercert-wg  On Behalf Of Wayne 
Thayer via Servercert-wg
Sent: Thursday, April 25, 2024 8:00 PM
To: CA/B Forum Server Certificate WG Public Discussion List 

Subject: [Servercert-wg] Voting Period Begins - Ballot SC-073: Compromised and 
Weak Keys


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.


Purpose of Ballot SC-073

This ballot proposes updates to the Baseline Requirements for the Issuance and 
Management of Publicly-Trusted TLS Server Certificates related to weak and 
compromised private keys. These changes lie primarily in Section 
6.1.1.3:

  *   6.1.1.3(4) clarifies that, for the purpose of this requirement, CAs shall 
be made aware of compromised keys using their existing notification 
mechanism(s).
  *   6.1.1.3(5) improves guidance for CAs around the detection of weak keys. 
Should this ballot pass, these changes become effective on November 15, 2024.

Notes:

  *   This ballot builds on the extensive work done by SSL.com in creating 
ballot SC-59v2 Weak Key Guidance. SSL.com’s contributions are appreciated.
  *   Thanks to Rob Stradling of Sectigo for the generation and publication of 
the set of Debian weak keys referenced in this ballot.
  *   The Debian weak keys requirements have been discussed extensively, 
including in the following threads: 
https://lists.cabforum.org/pipermail/servercert-wg/2024-March/004291.html and 
https://lists.cabforum.org/pipermail/servercert-wg/2024-April/004422.html
  *   This ballot does not appear to conflict with any other ballots that are 
currently under discussion.



The following motion has been proposed by Wayne Thayer of Fastly, and endorsed 
by Brittany Randall of GoDaddy and Bruce Morton of Entrust.

— Motion Begins —

This ballot modifies the “Baseline Requirements for the Issuance and Management 
of Publicly-Trusted Certificates” (“Baseline Requirements”), based on Version 
2.0.3.

MODIFY the Baseline Requirements for the Issuance and Management of 
Publicly-Trusted TLS Server Certificates as specified in the following Redline:

Here is a link to the immutable GitHub redline: 
https://github.com/cabforum/servercert/compare/a65402cff89affe1fc0a1f0e49807c7e42e1608a...bee10c8e4a56815bffd59fab12cbd4044baa7cc0

— Motion Ends —

This ballot proposes a Final Maintenance Guideline. The procedure for approval 
of this ballot is as follows:

Discussion (7+ days)

  *   Start time: 2024-04-18 00:00:00 UTC
  *   End time: 2024-04-26 00:00:00 UTC

Vote for approval (7 days)

  *   Start time: 2024-04-26 00:00:00 UTC
  *   End time: 2024-05-03 00:00:00 UTC





Company Registration Details
VikingCloud is the registered business name of Sysxnet Limited. Sysxnet Limited 
is registered in Ireland under company registration number 147176 and its 
registered office is at 1st Floor, Block 71a, The Plaza, Park West Business 
Park, Dublin 12, Ireland.

Email Disclaimer
The information contained in this communication is intended solely for the use 
of the individual or entity to whom it is addressed and others authorized to 
receive it. It may contain confidential or legally privileged information. If 
you are not the intended recipient you are hereby notified that any disclosure, 
copying, distribution or taking any action in reliance on the contents of this 
information is strictly prohibited and may be unlawful. If you have received 
this communication in error, please notify us immediately by responding to this 
email and then delete it from your system. Sysxnet Limited is neither liable 
for the proper and complete transmission of the information contained in this 
communication nor for any delay in its receipt..
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

Re: [Servercert-wg] Voting Period Begins - Ballot SC-073: Compromised and Weak Keys

[So, Nicol via Servercert-wg]

CommScope votes “yes” to Ballot SC-073.

From: Servercert-wg  On Behalf Of Wayne 
Thayer via Servercert-wg
Sent: Thursday, April 25, 2024 8:00 PM
To: CA/B Forum Server Certificate WG Public Discussion List 

Subject: [Servercert-wg] Voting Period Begins - Ballot SC-073: Compromised and 
Weak Keys

Purpose of Ballot SC-073 This ballot proposes updates to the Baseline 
Requirements for the Issuance and Management of Publicly-Trusted TLS Server 
Certificates related to weak and compromised private k
Caution: External 
(servercert-wg@cabforum.org)
Misleading Reply-To   
Details
  Report This 
Email
  FAQ  Protection by 
INKY


Purpose of Ballot SC-073

This ballot proposes updates to the Baseline Requirements for the Issuance and 
Management of Publicly-Trusted TLS Server Certificates related to weak and 
compromised private keys. These changes lie primarily in Section 
6.1.1.3:

  *   6.1.1.3(4) clarifies that, for the purpose of this requirement, CAs shall 
be made aware of compromised keys using their existing notification 
mechanism(s).
  *   6.1.1.3(5) improves guidance for CAs around the detection of weak keys. 
Should this ballot pass, these changes become effective on November 15, 2024.

Notes:

  *   This ballot builds on the extensive work done by SSL.com 
in creating ballot SC-59v2 Weak Key Guidance. SSL.com’s contributions are 
appreciated.
  *   Thanks to Rob Stradling of Sectigo for the generation and publication of 
the set of Debian weak keys referenced in this ballot.
  *   The Debian weak keys requirements have been discussed extensively, 
including in the following threads: 
https://lists.cabforum.org/pipermail/servercert-wg/2024-March/004291.html and 
https://lists.cabforum.org/pipermail/servercert-wg/2024-April/004422.html
  *   This ballot does not appear to conflict with any other ballots that are 
currently under discussion.



The following motion has been proposed by Wayne Thayer of Fastly, and endorsed 
by Brittany Randall of GoDaddy and Bruce Morton of Entrust.

— Motion Begins —

This ballot modifies the “Baseline Requirements for the Issuance and Management 
of Publicly-Trusted Certificates” (“Baseline Requirements”), based on Version 
2.0.3.

MODIFY the Baseline Requirements for the Issuance and Management of 
Publicly-Trusted TLS Server Certificates as specified in the following Redline:

Here is a link to the immutable GitHub redline: 
https://github.com/cabforum/servercert/compare/a65402cff89affe1fc0a1f0e49807c7e42e1608a...bee10c8e4a56815bffd59fab12cbd4044baa7cc0

— Motion Ends —

This ballot proposes a Final Maintenance Guideline. The procedure for approval 
of this ballot is as follows:

Discussion (7+ days)

  *   Start time: 2024-04-18 00:00:00 UTC
  *   End time: 2024-04-26 00:00:00 UTC

Vote for approval (7 days)

  *   Start time: 2024-04-26 00:00:00 UTC
  *   End time: 2024-05-03 00:00:00 UTC
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

Re: [Servercert-wg] [External Sender] Question regarding the id-ad-caIssuers accessMethod URI

[Corey Bonnell via Servercert-wg]

Hi Clint,

> My understanding is that the intent was indeed to restrict these to HTTP 
> specifically.

 

That matches my understanding as well.

 

> I’m not convinced a clarification is worthwhile here. To be clear, I’m not 
> opposed, I’m just not sure it’s something CAs are actively getting or likely 
> to get wrong — if some are, then I would instead support such a clarification.

 

The S/MIME BRs use the term “scheme” to explicitly specify when only plaintext 
HTTP (and not HTTPS) URIs are allowed. If the consensus is that a change in the 
TLS BRs is warranted, then I think using this term would better clarify the 
requirements regarding the mandated use of plaintext HTTP.

 

Thanks,

Corey

 

From: Servercert-wg  On Behalf Of Clint 
Wilson via Servercert-wg
Sent: Tuesday, April 30, 2024 5:53 PM
To: Dimitris Zacharopoulos (HARICA) ; ServerCert CA/BF 

Subject: Re: [Servercert-wg] [External Sender] Question regarding the 
id-ad-caIssuers accessMethod URI

 

Hi Dimitris,

 

My understanding is that the intent was indeed to restrict these to HTTP 
specifically. That is, the phrase “the only URLS present MUST be HTTP URLs” is 
intended to preclude the use of HTTPS, and not just to indicate that any scheme 
which relies on the Hypertext Transfer Protocol can be used.

 

Presumably when 5280 was drafted, the authors were aware of the updates 2817 
made to 2616, but chose not to reference those updates. Even if not, I concur 
with Ryan and my recollection is also that the discussion during SC-62’s 
formation did include this topic with the consensus (at that time) being that 
some fields would be restricted to using only HTTP URIs.

 

To your original questions:

Do Members agree with that interpretation? 

 

Yes






If this is the correct interpretation, would it be considered a violation of 
the BRs if a CA or end-entity certificate contains https:// URL in the 
id-ad-caIssuers accessMethod ? 

 

Yes, at least for certificates issued after SC-62 went into effect (maybe also 
for those prior, I just haven’t looked).






I'm afraid that this might not be as clear in the BRs as it should be, so if 
people agree with the above, we should probably update section 7.1.2.7.7 

  (and possibly other parts) to explicitly state that the allowed scheme is 
"http" and not "https", just like we do for the CRLDP in section 7.1.2.11.2 

  . 

 

I’m not convinced a clarification is worthwhile here. To be clear, I’m not 
opposed, I’m just not sure it’s something CAs are actively getting or likely to 
get wrong — if some are, then I would instead support such a clarification.

 

Cheers!

-Clint





On Apr 25, 2024, at 5:41 AM, Dimitris Zacharopoulos (HARICA) via Servercert-wg 
mailto:servercert-wg@cabforum.org> > wrote:

 

Hi Ryan,

The question is not between HTTP vs FTP vs LDAP but specifically for "HTTP URL" 
that could have two schemes "http" and "https".

RFC 2616 (June 1999) included only "http" and was updated in May 2000 by RFC 
2817 

  to include TLS Within HTTP/1.1 ("https").

I hope this clarifies the issue.


Dimitris.

On 25/4/2024 3:29 μ.μ., Ryan Dickson via Servercert-wg wrote:

It's my understanding that the intent of the updates made in SC-62 were to 
prohibit any non-HTTP URI. This was discussed in:

 

1) at least one historical GitHub discussion 

  (referenced in ballot preamble 

 ):

 

*   "authorityInformationAccess: This is a new requirement.

*   BRs 7.1.2.2 (c) notes that it SHOULD contain the HTTP URL of the 
Issuing CA's certificate and MAY contain the HTTP URL of the Issuing CA's OCSP 
responder.
*

Re: [Servercert-wg] [External Sender] Question regarding the id-ad-caIssuers accessMethod URI

[Dimitris Zacharopoulos (HARICA) via Servercert-wg]

Thanks Clint,

It would help doing some research in CENSYS to see if this is a real 
problem or not. I will try to get some additional resources internally 
to help me with this. In any case, this discussion might inspire some of 
the linting software developers to write a lint expecting only *http://* 
URLs in that field.



Best regards,
Dimitris.

On 1/5/2024 12:52 π.μ., Clint Wilson wrote:

Hi Dimitris,

My understanding is that the intent was indeed to restrict these to 
HTTP specifically. That is, the phrase “the only URLS present MUST be 
HTTP URLs” is intended to preclude the use of HTTPS, and not just to 
indicate that any scheme which relies on the Hypertext Transfer 
Protocol can be used.


Presumably when 5280 was drafted, the authors were aware of the 
updates 2817 made to 2616, but chose not to reference those updates. 
Even if not, I concur with Ryan and my recollection is also that the 
discussion during SC-62’s formation did include this topic with the 
consensus (at that time) being that some fields would be restricted to 
using only HTTP URIs.


To your original questions:



Do Members agree with that interpretation?




Yes



If this is the correct interpretation, would it be considered a
violation of the BRs if a CA or end-entity certificate contains
https:// URL in the id-ad-caIssuers accessMethod ?




Yes, at least for certificates issued after SC-62 went into effect 
(maybe also for those prior, I just haven’t looked).




I'm afraid that this might not be as clear in the BRs as it
should be, so if people agree with the above, we should
probably update section 7.1.2.7.7


 (and
possibly other parts) to explicitly state that the allowed
scheme is "http" and not "https", just like we do for the CRLDP
in section 7.1.2.11.2


 .





I’m not convinced a clarification is worthwhile here. To be clear, I’m 
not opposed, I’m just not sure it’s something CAs are actively getting 
or likely to get wrong — if some are, then I would instead support 
such a clarification.


Cheers!
-Clint

On Apr 25, 2024, at 5:41 AM, Dimitris Zacharopoulos (HARICA) via 
Servercert-wg  wrote:


Hi Ryan,

The question is not between HTTP vs FTP vs LDAP but specifically for 
"HTTP URL" that could have two schemes "http" and "https".


RFC 2616 (June 1999) included only "http" and was updated in May 2000 
by RFC 2817  to 
include TLS Within HTTP/1.1 ("https").


I hope this clarifies the issue.


Dimitris.

On 25/4/2024 3:29 μ.μ., Ryan Dickson via Servercert-wg wrote:
It's my understanding that the intent of the updates made in SC-62 
were to prohibit any non-HTTP URI. This was discussed in:


1) at least one historical GitHub discussion 
 (referenced in 
ballot preamble 
):


  * /"authorityInformationAccess: This is a new requirement./
  o /BRs 7.1.2.2 (c) notes that it SHOULD contain the HTTP URL
of the Issuing CA's certificate and MAY contain the HTTP URL
of the Issuing CA's OCSP responder./
  o /Some questions were raised about whether this means other
URLs, other schemes, or multiple URLs can be included.
Similar to crlDistributionPoints, the ordering of URLs
implies processing semantics on clients, and only particular
URL schemes are supported. Namely, if one of the two
supported access methods are present (CA issuer or OCSP),
*then the only URLs present MUST be HTTP URLs*, and MUST be
listed in order of priority./
  o /This prohibits the use of other access methods, as they are
not used in the Web PKI."/

/
/
and 2) Corey's Validation Subcommittee presentation at F2F 56 
 (slide 
14 
, 
/"Non-HTTP (i.e., LDAP and FTP) OCSP and CA Issuers URIs are 
prohibited").//

/
/
/
D-Trust volunteered to propose an update to the BRs to address the 
issue in this 
 Bugzilla 
Bug (Actions Table).


Thanks,
Ryan

On Thu, Apr 25, 2024 at 3:44 AM Adriano Santoni via Servercert-wg 
 wrote:


Hi,

IMO, including an HTTPS URI in the *id-ad-caIssuers*
accessMethod is at least a bad practice and very unwise (if done
on purpose), as it may give rise to unbounded loops, as it is
clearly explained in RFC5280:



CAs SHOULD NOT include URIs that specify https, ldaps, or similar
schemes in extensions.  CAs that include an https URI in one of