[Smcwg-public] [External Sender] Re: [EXTERNAL]-Re: Fields for S/MIME CSRs

Robert Lee robert.lee at globalsign.com
Mon Oct 2 08:18:52 UTC 2023


Hi all, 

So, I can see the sense to Clint’s argument that fields in the CSR may be confirmatory but shouldn’t be the only source of the information that gets put into a certificate because it should be coming from the store of vetted information held by the CA. But what if the fields in a provided CSR are explicitly contradictory to what is to be in the requested certificate? 

Providing a CSR with no subject information in it to support the certificate request is one thing, but what if a subscriber provides a CSR containing subject information completely different to that which should be put into the certificate? If I am requesting a certificate for rob at example.com <mailto:rob at example.com> and the CSR I send to the CA to provide my public key and proof-of-possession contains only the email address “definitelynotrob at definitelynotexample.com <mailto:definitelynotrob at definitelynotexample.com>” then there is a reasonable argument to be made that something strange is going on and that my CSR does not support my certificate request because the information it does contain doesn’t match what should be included in my certificate. 

I guess I’d argue for a position of “The CSR doesn’t need to contain everything, but what is in there should at least be correct” which I _think_ mostly aligns with Clint’s position. 

Best Regards, 
Rob 

Dr. Robert Lee MEng PhD 
Senior Software Engineer with Cryptography SME 
www.globalsign.co.uk <_blank>|www.globalsign.eu <_blank> 




From: Smcwg-public <smcwg-public-bounces at cabforum.org> on behalf of Adriano Santoni via Smcwg-public <smcwg-public at cabforum.org>
Date: Monday, 2 October 2023 at 07:57
To: smcwg-public at cabforum.org <smcwg-public at cabforum.org>
Subject: Re: [Smcwg-public] [External Sender] Re: [EXTERNAL]-Re: Fields for S/MIME CSRs 

Not necessarily: the email address can be transmitted to the CA as a separate datum. 
Indeed, I would say that this is preferable because it allows syntax checking on the email address without even starting to look at the CSR, from which in my opinion only the public key should be taken.
Adriano

Il 29/09/2023 21:21, Ben Wilson via Smcwg-public ha scritto:

NOTICE: Pay attention - external email - Sender is 0100018ae263a9a7-3e84e260-b7d7-43c5-85cb-d1425682cb27-000000 at amazonses.com <mailto:0100018ae263a9a7-3e84e260-b7d7-43c5-85cb-d1425682cb27-000000 at amazonses.com> 



Shouldn't at least the email address be included, and verified, of course, by the CA?


On Fri, Sep 29, 2023, 11:35 AM Pedro FUENTES <pfuentes at wisekey.com <mailto:pfuentes at wisekey.com>> wrote:

+1






Le 29 sept. 2023 à 17:52, Clint Wilson via Smcwg-public <smcwg-public at cabforum.org <_blank>> a écrit :

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




_______________________________________________
Smcwg-public mailing list
Smcwg-public at cabforum.org <_blank>
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cabforum.org_mailman_listinfo_smcwg-2Dpublic&d=DwICAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY&m=SdzPRXhti18pWLmVPVZwDOe4My0SBGtWzL3HSt02tHKsXpWQUw9YUb_QzXtxZYtw&s=5yodJ9UuvfVvN_CqY53dyFJyNwYRRJDEfhmuysvXrQA&e= <_blank>






_______________________________________________ Smcwg-public mailing list Smcwg-public at cabforum.org <mailto:Smcwg-public at cabforum.org> https://lists.cabforum.org/mailman/listinfo/smcwg-public <https://lists.cabforum.org/mailman/listinfo/smcwg-public> 


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


More information about the Smcwg-public mailing list