[Smcwg-public] [External Sender] Re: Re: [EXTERNAL]-Re: Fields for S/MIME CSRs
Adriano Santoni
adriano.santoni at staff.aruba.it
Tue Oct 3 06:51:27 UTC 2023
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 <http://www.globalsign.co.uk/>|www.globalsign.eu
> <http://www.globalsign.eu/>
>
> *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
>
>
> 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=
> <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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/smcwg-public/attachments/20231003/d9df6dcf/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4620 bytes
Desc: Firma crittografica S/MIME
URL: <http://lists.cabforum.org/pipermail/smcwg-public/attachments/20231003/d9df6dcf/attachment-0001.p7s>
More information about the Smcwg-public
mailing list