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@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.be...@logius.nl > www.logius.nl > > > > workdays Mo-Tue & Thu-Fri > > ........................................................................ > > > > *Van:* Smcwg-public <smcwg-public-boun...@cabforum.org> *Namens *Adriano > Santoni via Smcwg-public > *Verzonden:* dinsdag 3 oktober 2023 08:52 > *Aan:* smcwg-public@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 > r...@example.com and the CSR I send to the CA to provide my public key and > proof-of-possession contains only the email address “ > definitelynot...@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-boun...@cabforum.org> > <smcwg-public-boun...@cabforum.org> on behalf of Adriano Santoni via > Smcwg-public <smcwg-public@cabforum.org> <smcwg-public@cabforum.org> > *Date: *Monday, 2 October 2023 at 07:57 > *To: *smcwg-public@cabforum.org <smcwg-public@cabforum.org> > <smcwg-public@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-000...@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 <pfuen...@wisekey.com> wrote: > > +1 > > > > > > Le 29 sept. 2023 à 17:52, Clint Wilson via Smcwg-public < > smcwg-public@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@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 > > > > _______________________________________________ > Smcwg-public mailing list > Smcwg-public@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@cabforum.org > > https://lists.cabforum.org/mailman/listinfo/smcwg-public > > > > _______________________________________________ > > Smcwg-public mailing list > > Smcwg-public@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@cabforum.org > https://lists.cabforum.org/mailman/listinfo/smcwg-public >
_______________________________________________ Smcwg-public mailing list Smcwg-public@cabforum.org https://lists.cabforum.org/mailman/listinfo/smcwg-public