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

Thu Oct 5 21:01:45 UTC 2023

So, will all CA systems out there accept and process my S/Mime CSR if I
submit it with just the public key and no Subject DN or SAN? Has that been
tested?

On Thu, Oct 5, 2023, 2:51 PM Berge, Jochem Van den via Smcwg-public <
smcwg-public at cabforum.org> wrote:

> 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
> 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 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” 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|www.globalsign.eu
>
>
>
>
>
> *From: *Smcwg-public <smcwg-public-bounces at cabforum.org>
> <smcwg-public-bounces at cabforum.org> on behalf of Adriano Santoni via
> Smcwg-public <smcwg-public at cabforum.org> <smcwg-public at cabforum.org>
> *Date: *Monday, 2 October 2023 at 07:57
> *To: *smcwg-public at cabforum.org <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
>
>
>
>
>
> 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> wrote:
>
> +1
>
>
>
>
>
> Le 29 sept. 2023 à 17:52, Clint Wilson via Smcwg-public <
> 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> 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
>
>
>
> _______________________________________________
> Smcwg-public mailing list
> 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
>
> https://lists.cabforum.org/mailman/listinfo/smcwg-public
>
>
>
> _______________________________________________
>
> Smcwg-public mailing list
>
> 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.
> _______________________________________________
> 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/20231005/b5bf860c/attachment-0001.html>