[Smcwg-public] Fields for S/MIME CSRs

[Clint Wilson]

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> 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
> https://lists.cabforum.org/mailman/listinfo/smcwg-public

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