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

[Ben Wilson]

Hi,
It seems simply, as a method of tracking, that Certificate Issuers might
find it helpful to have an email address in the CSR. Plus, if you're
establishing proof of possession, then doesn't it help to know something
about "who" is asserting possession of the key pair? (I don't think a CSR
with only a signed public key is sufficient.) I'm not disagreeing about how
this should be done securely, end-to-end, and I'm certainly not saying that
Certificate Issuers create certificates based solely on CSRs. I'm just
asking for suggestions from Certificate Issuers about a set of common
fields that might be in the most basic type of CSR that would then lead up
to the issuance of an S/MIME certificate, once all of that information has
been validated.
Thanks,
Ben

On Fri, Sep 29, 2023 at 1:33 PM Pedro FUENTES <pfuentes at wisekey.com> wrote:

> That’s an interesting point, but the same than there’s no need to consider
> the domains coming in the CSR to issue TLS certificates, I personally don’t
> see the practical need here.
>
> For example… We could have an Enterprise RA that can issue certs for any
> email address in a set of preauthorized domains and this would just make
> the content of the CSR quite irrelevant.
>
> In our case, we rely on other security methods (e.g. authentication
> credentials to the certificate management system) to link the certificate
> request attributes, the domain validation method and the public key in the
> CSR. We just think is better to rely on the verified information and not on
> whatever the CSR had.
>
> Le 29 sept. 2023 à 21:21, Ben Wilson <bwilson at mozilla.com> a écrit :
>
> 
> 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
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cabforum.org_mailman_listinfo_smcwg-2Dpublic&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=AFTYu1HAQdkStwzgxyDbKOLyDwTHEezL5yeqoxeZ0fc&m=3Ai2uFDmuPvkjzx8-NXCPUEmAIzjkD-8sGOWakiphpuCLfulDVnTYuieselnddbL&s=DlmLTfjyPj2kGhM6d66NyUTRj15XswMU-gv6MKDY5F8&e=>
>>
>>
>> _______________________________________________
>> 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=
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/smcwg-public/attachments/20230929/c83c01f6/attachment.html>