[Smcwg-public] Fields for S/MIME CSRs

[Tim Hollebeek]

We should definitely add guidance, but it needs to be couched in “if using CSRs …”.

 

I consider CSRs to be mildly obsolete, and generally useful only because they are the format that most key generation tools and CA toolchains are used to dealing with and have robust support for.  Which I agree that clarifying that a CSR is only for transporting a key, and PoP, if necessary.  Though CSRs tend to be bad for PoP anyway, especially if you remove the identity information, because without any context binding the CSR is globally replayable and therefore doesn’t prove anything about who owns that key.

 

But there are many ways to request a certificate that don’t use a CSR at all, and those are often preferable anyway.  We need to make sure we don’t accidentally negatively impacts the ability to use better methods than CSRs.

 

-Tim

 

From: Smcwg-public <smcwg-public-bounces at cabforum.org> On Behalf Of Dimitris Zacharopoulos (HARICA) via Smcwg-public
Sent: Saturday, September 30, 2023 10:13 AM
To: smcwg-public at cabforum.org
Subject: Re: [Smcwg-public] Fields for S/MIME CSRs

 

 

On 30/9/2023 4:39 μ.μ., Stephen Davidson via Smcwg-public wrote:

Hello all:

 

If widely supported, should we consider documenting this in the S/MIME BR?


I had the impression that this is was the common understanding and already a dominating practice (using only the public key out of a CSR). There are many documented CA incidents (https://wiki.mozilla.org/CA/Closed_Incidents <https://url.avanan.click/v2/___https:/wiki.mozilla.org/CA/Closed_Incidents___.YXAzOmRpZ2ljZXJ0OmE6bzpjMGQyZmVkMjUwYjAxNjljNGY1MDgzZThhMjY0ODkyYjo2OjZjNWY6ODE1MWIzZWI5ZjQ5NjIwZTA4NTMxZWQ2MGM3N2JjNjM0YjdmOTA1YTg0ODk5OTM0NWQ2MmU4ZTViNmRmZWY5MzpoOkY> ) that explain that using any information inside a CSR other than the public key, is dangerous and could result even in attribute encoding issues.

I am very supportive of adding this clarification/guidance into the S/MIME BRs and other BRs :)


Thanks,
Dimitris.





 

Best, Stephen

 

 

From: Smcwg-public  <mailto:smcwg-public-bounces at cabforum.org> <smcwg-public-bounces at cabforum.org> On Behalf Of Clint Wilson via Smcwg-public
Sent: Friday, September 29, 2023 12:52 PM
To: Ben Wilson  <mailto:bwilson at mozilla.com> <bwilson at mozilla.com>; SMIME Certificate Working Group  <mailto:smcwg-public at cabforum.org> <smcwg-public at cabforum.org>
Subject: Re: [Smcwg-public] Fields for S/MIME CSRs

 

Hi all,

 

In my opinion, CSRs should really be limited to conveying the public key and a proof of possession of the private key; the fields included therein may act as confirmatory signals for a CA, but shouldn’t be directly relied upon e.g. to generate a tbsCertificate. Rather, the values placed in fields of a tbsCertificate should originate from the CA’s validated data store to ensure that the only paths for data to become part of a signed certificate are through static configurations (e.g. signatureAlgorithm) or known-validated data.

 

There’s plenty of nuance we can discuss as well, but generally speaking I believe it’s bad practice to rely on fields in the CSR.

 

Cheers,

-Clint






On Sep 29, 2023, at 8:27 AM, Ben Wilson via Smcwg-public <smcwg-public at cabforum.org <mailto:smcwg-public at cabforum.org> > wrote:

 

All,

I'm interested in gathering information from Certificate Issuers about the kind of information that they would like to collect/extract from the CSRs they receive from S/MIME certificate applicants. This information could be used to refine a system to generate CSRs that result in certificates compliant with the various profiles defined in the S/MIME BRs. Alternatively, what is the minimum amount of information that CAs might expect to obtain from CSRs? In other words, which fields should a CSR generator integrated with a Certificate Consumer's software support?

Thanks,

Ben

_______________________________________________
Smcwg-public mailing list
Smcwg-public at cabforum.org <mailto:Smcwg-public at cabforum.org> 
https://url.avanan.click/v2/___https://lists.cabforum.org/mailman/listinfo/smcwg-public___.YXAzOmRpZ2ljZXJ0OmE6bzo0ODEzZjE5MTQ3NmQzMzBiY2EzZTg1MTAwNWYzODA0NTo2OjgzYjE6YjY4YzcwZWIwNTgwZmY3MmVlMjljNzM5Yzg0YmE4OWMyYTUwMDJmODE3NWY5ZTBjOWI5NzFiZjllODc2YjMwMjp0OkY <https://url.avanan.click/v2/___https:/lists.cabforum.org/mailman/listinfo/smcwg-public___.YXAzOmRpZ2ljZXJ0OmE6bzo0ODEzZjE5MTQ3NmQzMzBiY2EzZTg1MTAwNWYzODA0NTo2OjgzYjE6YjY4YzcwZWIwNTgwZmY3MmVlMjljNzM5Yzg0YmE4OWMyYTUwMDJmODE3NWY5ZTBjOWI5NzFiZjllODc2YjMwMjp0OkY> 

 





_______________________________________________
Smcwg-public mailing list
Smcwg-public at cabforum.org <mailto:Smcwg-public at cabforum.org> 
https://lists.cabforum.org/mailman/listinfo/smcwg-public <https://url.avanan.click/v2/___https:/lists.cabforum.org/mailman/listinfo/smcwg-public___.YXAzOmRpZ2ljZXJ0OmE6bzpjMGQyZmVkMjUwYjAxNjljNGY1MDgzZThhMjY0ODkyYjo2OmYwNzI6M2E3ODMyNzc5YTZkYTY4MDEyOTdmZmQ0YTdkZDRhZDkxNDU5NWI2N2VlNDE1MDA1ZjYyNjRhZTliMzFmMjNiODpoOkY> 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/smcwg-public/attachments/20231002/5d2d7692/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5231 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/smcwg-public/attachments/20231002/5d2d7692/attachment-0001.p7s>