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@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@cabforum.org > https://lists.cabforum.org/mailman/listinfo/smcwg-public
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Smcwg-public mailing list Smcwg-public@cabforum.org https://lists.cabforum.org/mailman/listinfo/smcwg-public
