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

Thu Oct 5 18:51:33 UTC 2023

Hi Adriano/Rob,

Although I can see were you’re coming from (I’ve seen plenty of examples of garbled subject info in CSRs over time) I doubt the use for such a check. Any kind of authentication or authorization is managed by different means already. If an applicant requests a certificate, is properly authenticated and the data in the TBS certificate is properly validated by the CA according to the SBRGs but the Applicant uses a CSR with garbage subject info, that is not an issue that a CA should fix IMHO. Incorrect subject information in a CSR has zero impact on the end certificate (or it’s trustworthiness).

Having thought about it, the only use cases for subject data in a CSR I can see are either:

  1.  The Applicant has used the wrong CSR for a request by mistake, in which case a CA check on the subject data in the CSR could stop issuance of the certificate and alert the Applicant that a potential mistake was made. But those kind of things can also happen with CSRs with the right subject data (multiple CSRs with identical subjects and different keys, although that is maybe less common for S/MIME and more for TLS)
  2.  Easy identification of CSRs if you have a whole stack of them in the same place/system. That is mostly for the Applicant, the CA should already have a database entry for every application request and/or certificate.

Scenario 1 could be useful for a CA to check mainly with regards to customer service but with regards to the SBRGs it opens up another can of worms if the vetted identity data in the CA application portal uses slightly different data than the CSR. Spelling variations, diacritics etc. can make this difficult and can also make an application for an S/MIME certificate frustrating if the check is too strict, but automated checks tend to be black or white (0/1).

In the end I agree with Clint’s original statement I think. The CSR should only be used to bind the certificate to a public key. Any other authentication data or verification of source are managed elsewhere.

Kind Regards,

Jochem van den Berge
Compliance Officer PKIoverheid

Logius

Digital Government Service
Ministry of the Interior and Kingdom Relations
........................................................................

M (+31) (0)6 – 21 16 26 89
T  (+31) (0)70 - 888 76 91
jochem.vanden.berge at logius.nl<mailto:jochem.vanden.berge at logius.nl>
www.logius.nl<http://www.logius.nl/>

workdays Mo-Tue & Thu-Fri
........................................................................

Van: Smcwg-public <smcwg-public-bounces at cabforum.org> Namens Adriano Santoni via Smcwg-public
Verzonden: dinsdag 3 oktober 2023 08:52
Aan: smcwg-public at cabforum.org
Onderwerp: Re: [Smcwg-public] [External Sender] Re: Re: [EXTERNAL]-Re: Fields for S/MIME CSRs

I agree with Rob.

Adriano

Il 02/10/2023 20:45, Robert Lee via Smcwg-public ha scritto:
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<http://www.globalsign.co.uk/>|www.globalsign.eu<http://www.globalsign.eu/>

From: Smcwg-public <smcwg-public-bounces at cabforum.org><mailto:smcwg-public-bounces at cabforum.org> on behalf of Adriano Santoni via Smcwg-public <smcwg-public at cabforum.org><mailto:smcwg-public at cabforum.org>
Date: Monday, 2 October 2023 at 07:57
To: smcwg-public at cabforum.org<mailto:smcwg-public at cabforum.org> <smcwg-public at cabforum.org><mailto: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<mailto:smcwg-public at cabforum.org>> 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<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://lists.cabforum.org/mailman/listinfo/smcwg-public

_______________________________________________
Smcwg-public mailing list
Smcwg-public at cabforum.org<mailto:Smcwg-public at cabforum.org>
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=

_______________________________________________

Smcwg-public mailing list

Smcwg-public at cabforum.org<mailto:Smcwg-public at cabforum.org>

https://lists.cabforum.org/mailman/listinfo/smcwg-public

_______________________________________________

Smcwg-public mailing list

Smcwg-public at cabforum.org<mailto:Smcwg-public at cabforum.org>

https://lists.cabforum.org/mailman/listinfo/smcwg-public
Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten.
This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/smcwg-public/attachments/20231005/56f87c91/attachment-0001.html>