From infra-bot at cabforum.org Sun Oct 1 07:34:44 2023 From: infra-bot at cabforum.org (Infrastructure Bot) Date: Sun, 1 Oct 2023 07:34:44 +0000 Subject: [Smcwg-public] Weekly github digest (S/MIME Certificate Working Group) Message-ID: <0100018aea293771-f60f2689-9726-45ed-87cb-8f6c250499c9-000000@email.amazonses.com> Issues ------ * cabforum/smime (+2/-2/?10) 2 issues created: - Other Intermediate CAs in Extant SMIME CA definition (by srdavidson) https://github.com/cabforum/smime/issues/215 - Backdating (by srdavidson) https://github.com/cabforum/smime/issues/214 8 issues received 10 new comments: - #215 Other Intermediate CAs in Extant SMIME CA definition (2 by srdavidson) https://github.com/cabforum/smime/issues/215 - #213 Pseudonym with Subject name fields (2 by robplee, srdavidson) https://github.com/cabforum/smime/issues/213 - #211 No requirement to include countryName if stateOrProvinceName or localityName are present (1 by srdavidson) https://github.com/cabforum/smime/issues/211 - #209 Audit section updates for ETSI TS 119 411-6 (1 by srdavidson) https://github.com/cabforum/smime/issues/209 - #208 Possible ambiguity in keyUsage table (1 by srdavidson) https://github.com/cabforum/smime/issues/208 - #203 CommonName Personal Name/Pseudonym options don't align with subject givenName/surname/pseudonym restriction (1 by srdavidson) https://github.com/cabforum/smime/issues/203 - #202 3.2.2.2 Validity of Random Value could be too short (1 by srdavidson) https://github.com/cabforum/smime/issues/202 - #7 CAA (1 by srdavidson) https://github.com/cabforum/smime/issues/7 [Future Version] 2 issues closed: - 3.2.2.2 Validity of Random Value could be too short https://github.com/cabforum/smime/issues/202 - Pseudonym with Subject name fields https://github.com/cabforum/smime/issues/213 Repositories tracked by this digest: ----------------------------------- * https://github.com/cabforum/smime -------------- next part -------------- An HTML attachment was scrubbed... URL: From adriano.santoni at staff.aruba.it Mon Oct 2 06:57:16 2023 From: adriano.santoni at staff.aruba.it (Adriano Santoni) Date: Mon, 2 Oct 2023 08:57:16 +0200 Subject: [Smcwg-public] [External Sender] Re: [EXTERNAL]-Re: Fields for S/MIME CSRs In-Reply-To: <0100018ae263a9a7-3e84e260-b7d7-43c5-85cb-d1425682cb27-000000@email.amazonses.com> References: <0100018ae1a3f308-31a12362-2959-4e3a-8dc6-2585a8733af7-000000@email.amazonses.com> <62129517-71AE-4D0E-8136-5A2F9F17FE35@wisekey.com> <0100018ae263a9a7-3e84e260-b7d7-43c5-85cb-d1425682cb27-000000@email.amazonses.com> Message-ID: <1b2585c3-cac8-4391-96c2-db66780921b3@staff.aruba.it> 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 wrote: > > +1 > > >> Le 29 sept. 2023 ? 17:52, Clint Wilson via Smcwg-public >> 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 >>> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4620 bytes Desc: Firma crittografica S/MIME URL: From doug.beattie at globalsign.com Mon Oct 2 10:27:29 2023 From: doug.beattie at globalsign.com (Doug Beattie) Date: Mon, 2 Oct 2023 10:27:29 +0000 Subject: [Smcwg-public] [External Sender] Re: [EXTERNAL]-Re: Fields for S/MIME CSRs In-Reply-To: <0100018aef2d6868-cdc4617f-d706-4392-9310-04a1129ab4e2-000000@email.amazonses.com> References: <0100018ae1a3f308-31a12362-2959-4e3a-8dc6-2585a8733af7-000000@email.amazonses.com> <62129517-71AE-4D0E-8136-5A2F9F17FE35@wisekey.com> <0100018ae263a9a7-3e84e260-b7d7-43c5-85cb-d1425682cb27-000000@email.amazonses.com> <0100018aef2d6868-cdc4617f-d706-4392-9310-04a1129ab4e2-000000@email.amazonses.com> Message-ID: I haven?t been following the status of ACME for S/MIME, but I presume there are some fields in that CSR that would be used to automate certificate issuance. Maybe that is a place to start looking for meaningful fields within a CSR? I know that we typically only pull out the public key from CSRs and all other info is provided outside of it. Doug From: Smcwg-public On Behalf Of Adriano Santoni via Smcwg-public Sent: Monday, October 2, 2023 2:57 AM To: 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 > wrote: +1 Le 29 sept. 2023 ? 17:52, Clint Wilson via Smcwg-public > 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 > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 8404 bytes Desc: not available URL: From tim.hollebeek at digicert.com Mon Oct 2 17:05:17 2023 From: tim.hollebeek at digicert.com (Tim Hollebeek) Date: Mon, 2 Oct 2023 17:05:17 +0000 Subject: [Smcwg-public] Fields for S/MIME CSRs In-Reply-To: <0100018ae66f430f-deeda33a-3c98-49fa-b1e9-9f7d04bcdb75-000000@email.amazonses.com> References: <0100018ae18d9aaf-9e079531-94bb-4819-8ef8-43cd3fa58ca6-000000@email.amazonses.com> <0100018ae1a3f1fe-677b87fe-3636-4461-957e-001033ac8f63-000000@email.amazonses.com> <0100018ae6511d14-ee89c460-93dd-419c-a9e4-7305b198b7c6-000000@email.amazonses.com> <0100018ae66f430f-deeda33a-3c98-49fa-b1e9-9f7d04bcdb75-000000@email.amazonses.com> Message-ID: We should definitely add guidance, but it needs to be couched in ?if using CSRs ??. I consider CSRs to be mildly obsolete, and generally useful only because they are the format that most key generation tools and CA toolchains are used to dealing with and have robust support for. Which I agree that clarifying that a CSR is only for transporting a key, and PoP, if necessary. Though CSRs tend to be bad for PoP anyway, especially if you remove the identity information, because without any context binding the CSR is globally replayable and therefore doesn?t prove anything about who owns that key. But there are many ways to request a certificate that don?t use a CSR at all, and those are often preferable anyway. We need to make sure we don?t accidentally negatively impacts the ability to use better methods than CSRs. -Tim From: Smcwg-public On Behalf Of Dimitris Zacharopoulos (HARICA) via Smcwg-public Sent: Saturday, September 30, 2023 10:13 AM To: smcwg-public at cabforum.org Subject: Re: [Smcwg-public] Fields for S/MIME CSRs On 30/9/2023 4:39 ?.?., Stephen Davidson via Smcwg-public wrote: Hello all: If widely supported, should we consider documenting this in the S/MIME BR? I had the impression that this is was the common understanding and already a dominating practice (using only the public key out of a CSR). There are many documented CA incidents (https://wiki.mozilla.org/CA/Closed_Incidents ) that explain that using any information inside a CSR other than the public key, is dangerous and could result even in attribute encoding issues. I am very supportive of adding this clarification/guidance into the S/MIME BRs and other BRs :) Thanks, Dimitris. Best, Stephen From: Smcwg-public On Behalf Of Clint Wilson via Smcwg-public Sent: Friday, September 29, 2023 12:52 PM To: Ben Wilson ; SMIME Certificate Working Group Subject: Re: [Smcwg-public] Fields for S/MIME CSRs 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 > 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://url.avanan.click/v2/___https://lists.cabforum.org/mailman/listinfo/smcwg-public___.YXAzOmRpZ2ljZXJ0OmE6bzo0ODEzZjE5MTQ3NmQzMzBiY2EzZTg1MTAwNWYzODA0NTo2OjgzYjE6YjY4YzcwZWIwNTgwZmY3MmVlMjljNzM5Yzg0YmE4OWMyYTUwMDJmODE3NWY5ZTBjOWI5NzFiZjllODc2YjMwMjp0OkY _______________________________________________ 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5231 bytes Desc: not available URL: From robert.lee at globalsign.com Mon Oct 2 08:18:52 2023 From: robert.lee at globalsign.com (Robert Lee) Date: Mon, 2 Oct 2023 08:18:52 +0000 Subject: [Smcwg-public] [External Sender] Re: [EXTERNAL]-Re: Fields for S/MIME CSRs In-Reply-To: <0100018aef2d6868-cdc4617f-d706-4392-9310-04a1129ab4e2-000000@email.amazonses.com> References: <0100018ae1a3f308-31a12362-2959-4e3a-8dc6-2585a8733af7-000000@email.amazonses.com> <62129517-71AE-4D0E-8136-5A2F9F17FE35@wisekey.com> <0100018ae263a9a7-3e84e260-b7d7-43c5-85cb-d1425682cb27-000000@email.amazonses.com> <0100018aef2d6868-cdc4617f-d706-4392-9310-04a1129ab4e2-000000@email.amazonses.com> Message-ID: ?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 <_blank>|www.globalsign.eu <_blank> From: Smcwg-public on behalf of Adriano Santoni via Smcwg-public Date: Monday, 2 October 2023 at 07:57 To: 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 > wrote: +1 Le 29 sept. 2023 ? 17:52, Clint Wilson via Smcwg-public > 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 > 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 <_blank> https://lists.cabforum.org/mailman/listinfo/smcwg-public <_blank> _______________________________________________ Smcwg-public mailing list Smcwg-public at cabforum.org <_blank> 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= <_blank> _______________________________________________ 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 9889 bytes Desc: not available URL: From housley at vigilsec.com Mon Oct 2 18:59:20 2023 From: housley at vigilsec.com (Russ Housley) Date: Mon, 2 Oct 2023 14:59:20 -0400 Subject: [Smcwg-public] [External Sender] Re: [EXTERNAL]-Re: Fields for S/MIME CSRs In-Reply-To: <0100018aefede039-b13f102f-b904-47d8-8314-d0bd8b4e1ef6-000000@email.amazonses.com> References: <0100018ae1a3f308-31a12362-2959-4e3a-8dc6-2585a8733af7-000000@email.amazonses.com> <62129517-71AE-4D0E-8136-5A2F9F17FE35@wisekey.com> <0100018ae263a9a7-3e84e260-b7d7-43c5-85cb-d1425682cb27-000000@email.amazonses.com> <0100018aef2d6868-cdc4617f-d706-4392-9310-04a1129ab4e2-000000@email.amazonses.com> <0100018aefede039-b13f102f-b904-47d8-8314-d0bd8b4e1ef6-000000@email.amazonses.com> Message-ID: <3B7CABEA-3A7B-4F7B-B84C-63971BD5DF4A@vigilsec.com> Doug, See RFC 8823. Russ > On Oct 2, 2023, at 6:27 AM, Doug Beattie via Smcwg-public wrote: > > I haven?t been following the status of ACME for S/MIME, but I presume there are some fields in that CSR that would be used to automate certificate issuance. Maybe that is a place to start looking for meaningful fields within a CSR? I know that we typically only pull out the public key from CSRs and all other info is provided outside of it. > > Doug > > From: Smcwg-public > On Behalf Of Adriano Santoni via Smcwg-public > Sent: Monday, October 2, 2023 2:57 AM > To: 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 > wrote: > +1 > > > > Le 29 sept. 2023 ? 17:52, Clint Wilson via Smcwg-public > 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 > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4382 bytes Desc: not available URL: From adriano.santoni at staff.aruba.it Tue Oct 3 06:51:27 2023 From: adriano.santoni at staff.aruba.it (Adriano Santoni) Date: Tue, 3 Oct 2023 08:51:27 +0200 Subject: [Smcwg-public] [External Sender] Re: Re: [EXTERNAL]-Re: Fields for S/MIME CSRs In-Reply-To: <0100018af1b605ab-d917b2b3-82a4-4d53-a7b2-6caee230c02f-000000@email.amazonses.com> References: <0100018ae1a3f308-31a12362-2959-4e3a-8dc6-2585a8733af7-000000@email.amazonses.com> <62129517-71AE-4D0E-8136-5A2F9F17FE35@wisekey.com> <0100018ae263a9a7-3e84e260-b7d7-43c5-85cb-d1425682cb27-000000@email.amazonses.com> <0100018aef2d6868-cdc4617f-d706-4392-9310-04a1129ab4e2-000000@email.amazonses.com> <0100018af1b605ab-d917b2b3-82a4-4d53-a7b2-6caee230c02f-000000@email.amazonses.com> Message-ID: <83db84fb-7552-48dd-b394-5ad72fa9a913@staff.aruba.it> 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 on behalf of > Adriano Santoni via Smcwg-public > *Date: *Monday, 2 October 2023 at 07:57 > *To: *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 > wrote: > > +1 > > > > Le 29 sept. 2023 ? 17:52, Clint Wilson via Smcwg-public > 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 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4620 bytes Desc: Firma crittografica S/MIME URL: From martijn.katerbarg at sectigo.com Wed Oct 4 14:39:31 2023 From: martijn.katerbarg at sectigo.com (Martijn Katerbarg) Date: Wed, 4 Oct 2023 14:39:31 +0000 Subject: [Smcwg-public] Backdating S/MIME revocations In-Reply-To: <0100018ab1e93ffe-7c8cb3ad-939b-4580-9289-6e9033d1ae9f-000000@email.amazonses.com> References: <0100018ab1e93ffe-7c8cb3ad-939b-4580-9289-6e9033d1ae9f-000000@email.amazonses.com> Message-ID: ?On the back of this, and the discussion that was held during the last call, I?ve created a proposed language update to address this. Please find this available for discussion at https://github.com/cabforum/smime/pull/217 Regards, Martijn From: Smcwg-public on behalf of Martijn Katerbarg via Smcwg-public Date: Wednesday, 20 September 2023 at 11:26 To: SMIME Certificate Working Group Subject: [Smcwg-public] Backdating S/MIME revocations CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi all, Within our compliance team, we recently had a discussion around the way we handle revocation dates. Code Signing certificates, CAs are required to keep the time encoded in the InvalidityDate extension and revocationDate field the same. Additionally, if a CA deems that a historic date should be set, for example due to a key compromise having occurred a while ago, CAs are required to backdate the value. For TLS Certificates, CAs should set the revocationDate value for the date and time when revocation occurred, however, CAs are allowed to backdate if deemed appropriate. Both of these documents state that this is a deviation/exception to best practices described in RFC5280. However when we look at the SBRs, we could not find any such language that would clarify if and when backdating is allowed. I?m wondering if there?s been any discussion in the past around this, if this was left out on purpose, or if we missed this? Likewise, I?m wondering how other issuers and consumers look at this, and if we want to add some clarifying language in the SBRs. I?m inclined to say that backdating revocation is something we should be supporting. Regards, Martijn -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 8254 bytes Desc: not available URL: From jochem.vanden.berge at logius.nl Thu Oct 5 18:51:33 2023 From: jochem.vanden.berge at logius.nl (Berge, Jochem Van den) Date: Thu, 5 Oct 2023 18:51:33 +0000 Subject: [Smcwg-public] [External Sender] Re: Re: [EXTERNAL]-Re: Fields for S/MIME CSRs In-Reply-To: <0100018af44e75fb-77ce6104-9e5c-442c-8ea8-b1842cb704d4-000000@email.amazonses.com> References: <0100018ae1a3f308-31a12362-2959-4e3a-8dc6-2585a8733af7-000000@email.amazonses.com> <62129517-71AE-4D0E-8136-5A2F9F17FE35@wisekey.com> <0100018ae263a9a7-3e84e260-b7d7-43c5-85cb-d1425682cb27-000000@email.amazonses.com> <0100018aef2d6868-cdc4617f-d706-4392-9310-04a1129ab4e2-000000@email.amazonses.com> <0100018af1b605ab-d917b2b3-82a4-4d53-a7b2-6caee230c02f-000000@email.amazonses.com> <0100018af44e75fb-77ce6104-9e5c-442c-8ea8-b1842cb704d4-000000@email.amazonses.com> Message-ID: <881a810aacb84d55a306c3f9f3f19e08@logius.nl> 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 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 on behalf of Adriano Santoni via Smcwg-public Date: Monday, 2 October 2023 at 07:57 To: 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 > wrote: +1 Le 29 sept. 2023 ? 17:52, Clint Wilson via Smcwg-public > 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 > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bwilson at mozilla.com Thu Oct 5 21:01:45 2023 From: bwilson at mozilla.com (Ben Wilson) Date: Thu, 5 Oct 2023 17:01:45 -0400 Subject: [Smcwg-public] [External Sender] Re: Re: [EXTERNAL]-Re: Fields for S/MIME CSRs In-Reply-To: <0100018b012e7d58-97723490-311c-4bc1-93fb-42e7ad497ee2-000000@email.amazonses.com> References: <0100018ae1a3f308-31a12362-2959-4e3a-8dc6-2585a8733af7-000000@email.amazonses.com> <62129517-71AE-4D0E-8136-5A2F9F17FE35@wisekey.com> <0100018ae263a9a7-3e84e260-b7d7-43c5-85cb-d1425682cb27-000000@email.amazonses.com> <0100018aef2d6868-cdc4617f-d706-4392-9310-04a1129ab4e2-000000@email.amazonses.com> <0100018af1b605ab-d917b2b3-82a4-4d53-a7b2-6caee230c02f-000000@email.amazonses.com> <0100018af44e75fb-77ce6104-9e5c-442c-8ea8-b1842cb704d4-000000@email.amazonses.com> <0100018b012e7d58-97723490-311c-4bc1-93fb-42e7ad497ee2-000000@email.amazonses.com> Message-ID: 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 *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 > on behalf of Adriano Santoni via > Smcwg-public > *Date: *Monday, 2 October 2023 at 07:57 > *To: *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 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: From adriano.santoni at staff.aruba.it Fri Oct 6 04:46:19 2023 From: adriano.santoni at staff.aruba.it (Adriano Santoni) Date: Fri, 6 Oct 2023 06:46:19 +0200 Subject: [Smcwg-public] [External Sender] RE: Re: Re: [EXTERNAL]-Re: Fields for S/MIME CSRs In-Reply-To: <881a810aacb84d55a306c3f9f3f19e08@logius.nl> References: <0100018ae1a3f308-31a12362-2959-4e3a-8dc6-2585a8733af7-000000@email.amazonses.com> <62129517-71AE-4D0E-8136-5A2F9F17FE35@wisekey.com> <0100018ae263a9a7-3e84e260-b7d7-43c5-85cb-d1425682cb27-000000@email.amazonses.com> <0100018aef2d6868-cdc4617f-d706-4392-9310-04a1129ab4e2-000000@email.amazonses.com> <0100018af1b605ab-d917b2b3-82a4-4d53-a7b2-6caee230c02f-000000@email.amazonses.com> <0100018af44e75fb-77ce6104-9e5c-442c-8ea8-b1842cb704d4-000000@email.amazonses.com> <881a810aacb84d55a306c3f9f3f19e08@logius.nl> Message-ID: That's exactly what I also think (quoting Clint): > It?s bad practice to rely on fields in the CSR. > Adriano Il 05/10/2023 20:51, Berge, Jochem Van den ha scritto: > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4620 bytes Desc: Firma crittografica S/MIME URL: From infra-bot at cabforum.org Sun Oct 8 07:34:37 2023 From: infra-bot at cabforum.org (Infrastructure Bot) Date: Sun, 8 Oct 2023 07:34:37 +0000 Subject: [Smcwg-public] Weekly github digest (S/MIME Certificate Working Group) Message-ID: <0100018b0e35a041-32325b66-58c5-4759-98ef-921347c0f26b-000000@email.amazonses.com> Issues ------ * cabforum/smime (+1/-0/?3) 1 issues created: - Clarity on LEI in organizationIdentifier (by srdavidson) https://github.com/cabforum/smime/issues/216 1 issues received 3 new comments: - #216 Clarity on LEI in organizationIdentifier (3 by barrini, srdavidson) https://github.com/cabforum/smime/issues/216 Pull requests ------------- * cabforum/smime (+1/-0/?3) 1 pull requests submitted: - SMCXX: Backdating revocations (by XolphinMartijn) https://github.com/cabforum/smime/pull/217 1 pull requests received 3 new comments: - #217 SMCXX: Backdating revocations (3 by dougbeattie, pfuentes69, srdavidson) https://github.com/cabforum/smime/pull/217 Repositories tracked by this digest: ----------------------------------- * https://github.com/cabforum/smime -------------- next part -------------- An HTML attachment was scrubbed... URL: From jochem.vanden.berge at logius.nl Mon Oct 9 08:16:20 2023 From: jochem.vanden.berge at logius.nl (Berge, Jochem Van den) Date: Mon, 9 Oct 2023 08:16:20 +0000 Subject: [Smcwg-public] [External Sender] Re: Re: [EXTERNAL]-Re: Fields for S/MIME CSRs In-Reply-To: References: <0100018ae1a3f308-31a12362-2959-4e3a-8dc6-2585a8733af7-000000@email.amazonses.com> <62129517-71AE-4D0E-8136-5A2F9F17FE35@wisekey.com> <0100018ae263a9a7-3e84e260-b7d7-43c5-85cb-d1425682cb27-000000@email.amazonses.com> <0100018aef2d6868-cdc4617f-d706-4392-9310-04a1129ab4e2-000000@email.amazonses.com> <0100018af1b605ab-d917b2b3-82a4-4d53-a7b2-6caee230c02f-000000@email.amazonses.com> <0100018af44e75fb-77ce6104-9e5c-442c-8ea8-b1842cb704d4-000000@email.amazonses.com> <0100018b012e7d58-97723490-311c-4bc1-93fb-42e7ad497ee2-000000@email.amazonses.com> Message-ID: Hi Ben, What I meant with my earlier email was meant more as an ideal scenario. What I?ve personally seen in case of TLS CSRs was that the subject/FQDN data was taken from the CSR and either overwritten by static values (for Org etc) and/or as data input for the certificate application. In the latter case it would always be checked against a pre-approved list or verified on-the-fly (both according to BRG 3.2.2.4). I?ve never seen an application with a CSR without any subject data, even though my statement below that that would be superfluous. Getting back to your original email at the start of this thread: It could be good to indeed enquire this subject. With regards to S/MIME I?m also curious how often CSRs are used for signing certificates. In the context of the European market (qualified certificates etc.) I?m much more used to S/MIME certificates where the keypair is generated by the CA. Might this all be something to include in the survey that Stephen proposed during the F2F? 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: Ben Wilson Verzonden: donderdag 5 oktober 2023 23:02 Aan: Berge, Jochem Van den ; SMIME Certificate Working Group CC: Adriano Santoni Onderwerp: Re: [Smcwg-public] [External Sender] Re: Re: [EXTERNAL]-Re: Fields for S/MIME CSRs 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 > 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 > 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 on behalf of Adriano Santoni via Smcwg-public Date: Monday, 2 October 2023 at 07:57 To: 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 > wrote: +1 Le 29 sept. 2023 ? 17:52, Clint Wilson via Smcwg-public > 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 > 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 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: From Corey.Bonnell at digicert.com Tue Oct 10 12:41:24 2023 From: Corey.Bonnell at digicert.com (Corey Bonnell) Date: Tue, 10 Oct 2023 12:41:24 +0000 Subject: [Smcwg-public] [External Sender] Re: Re: [EXTERNAL]-Re: Fields for S/MIME CSRs In-Reply-To: <0100018b01a5c712-e75b377a-3ca2-4b2e-b0f5-5da4f1f9204e-000000@email.amazonses.com> References: <0100018ae1a3f308-31a12362-2959-4e3a-8dc6-2585a8733af7-000000@email.amazonses.com> <62129517-71AE-4D0E-8136-5A2F9F17FE35@wisekey.com> <0100018ae263a9a7-3e84e260-b7d7-43c5-85cb-d1425682cb27-000000@email.amazonses.com> <0100018aef2d6868-cdc4617f-d706-4392-9310-04a1129ab4e2-000000@email.amazonses.com> <0100018af1b605ab-d917b2b3-82a4-4d53-a7b2-6caee230c02f-000000@email.amazonses.com> <0100018af44e75fb-77ce6104-9e5c-442c-8ea8-b1842cb704d4-000000@email.amazonses.com> <0100018b012e7d58-97723490-311c-4bc1-93fb-42e7ad497ee2-000000@email.amazonses.com> <0100018b01a5c712-e75b377a-3ca2-4b2e-b0f5-5da4f1f9204e-000000@email.amazonses.com> Message-ID: Hi Ben, I?m unsure of how many CAs have implemented ACME for S/MIME (RFC 8823), but section 3, step 8 of that RFC specifies that the CSR MUST contain the requested email addresses in the SAN [1]. The inclusion of the email address in the CSR is useful from the perspective of creating a binding of the CSR to the specific certificate request. Thanks, Corey [1] https://www.rfc-editor.org/rfc/rfc8823.html#name-use-of-acme-for-issuing-end From: Smcwg-public On Behalf Of Ben Wilson via Smcwg-public Sent: Thursday, October 5, 2023 5:02 PM To: Berge, Jochem Van den ; SMIME Certificate Working Group Subject: Re: [Smcwg-public] [External Sender] Re: Re: [EXTERNAL]-Re: Fields for S/MIME CSRs 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 > 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 > 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 on behalf of Adriano Santoni via Smcwg-public Date: Monday, 2 October 2023 at 07:57 To: 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 > wrote: +1 Le 29 sept. 2023 ? 17:52, Clint Wilson via Smcwg-public > 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 > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5231 bytes Desc: not available URL: From Stephen.Davidson at digicert.com Tue Oct 10 14:34:53 2023 From: Stephen.Davidson at digicert.com (Stephen Davidson) Date: Tue, 10 Oct 2023 14:34:53 +0000 Subject: [Smcwg-public] Reminder: no SMCWG call on October 11 Message-ID: Hello all: This is a reminder that during the S/MIME session at the CABF #60 F2F last week it was agreed to cancel the October 11 teleconference. We'll return to the normal schedule on October 25. Regards, Stephen -------------- next part -------------- An HTML attachment was scrubbed... URL: From infra-bot at cabforum.org Sun Oct 15 07:34:46 2023 From: infra-bot at cabforum.org (Infrastructure Bot) Date: Sun, 15 Oct 2023 07:34:46 +0000 Subject: [Smcwg-public] Weekly github digest (S/MIME Certificate Working Group) Message-ID: <0100018b32424681-989982b7-3b1c-49f3-a875-1b46e6520f5d-000000@email.amazonses.com> Issues ------ * cabforum/smime (+0/-0/?2) 1 issues received 2 new comments: - #199 Repeated subject DN attributes (2 by CBonnell, jochemvdberge) https://github.com/cabforum/smime/issues/199 Pull requests ------------- * cabforum/smime (+0/-0/?1) 1 pull requests received 1 new comments: - #217 SMCXX: Backdating revocations (1 by romanf) https://github.com/cabforum/smime/pull/217 Repositories tracked by this digest: ----------------------------------- * https://github.com/cabforum/smime -------------- next part -------------- An HTML attachment was scrubbed... URL: From Corey.Bonnell at digicert.com Mon Oct 16 12:52:01 2023 From: Corey.Bonnell at digicert.com (Corey Bonnell) Date: Mon, 16 Oct 2023 12:52:01 +0000 Subject: [Smcwg-public] "Certification Authority Authorization (CAA) Processing for Email Addresses" published as RFC 9495 Message-ID: Hello, The document "Certification Authority Authorization (CAA) Processing for Email Addresses" was published late last week as RFC 9495. It is available here: https://www.rfc-editor.org/rfc/rfc9495.html. Given that this document is now published as an RFC, I believe we can resume the discussion on CAA for S/MIME certificates (https://github.com/cabforum/smime/issues/7). Thanks, Corey -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5231 bytes Desc: not available URL: From adriano.santoni at staff.aruba.it Mon Oct 16 13:52:05 2023 From: adriano.santoni at staff.aruba.it (Adriano Santoni) Date: Mon, 16 Oct 2023 15:52:05 +0200 Subject: [Smcwg-public] SV certificates devoid of individual attributes In-Reply-To: <0100018b324261c8-759958ef-6e5c-48f1-881a-a9faa732bb01-000000@email.amazonses.com> References: <0100018b324261c8-759958ef-6e5c-48f1-881a-a9faa732bb01-000000@email.amazonses.com> Message-ID: <12d0ca8c-0e1a-4bb1-bb51-8a0f69a3121e@staff.aruba.it> Hello all, I have the impression that the current SMBRs allow to issue Sponsor-Validated certificates which, contrary to the definition of this type of certificate, do not contain any "Individual (Natural Person) attributes" (quoting from the definition of Sponsor-Validated). At least, this seems to hold for the "Legacy Generation profiles". * according to ?3.1.1 and ?7.1.4.2.2, the commonName does not necessarily have to contain a Personal Name (in fact it MAY contain a Mailbox Address) * according to ?7.1.4.2.5, givenName and surname attributes are not required in "Legacy Generation profiles". Furthermore, as already discussed in a previous thread, there is no requirement that a personal email address have a "personal" appearance (e.g. forename.surname at company.com). Therefore, if I understand correctly, a Subject of the following type within a "Legacy" SV (Sponsor-Validated) certificate would be 100% compliant: CN=info at example.com, O=Example HmbH, organizationIdentifier=NTRXX-xxxxx, C=XX If this is true, it would make no difference if the certificate was OV rather than SV: the Subject could be identical in the two cases, and it would be devoid of? "Individual (Natural Person) attibutes". Is the above correct, or am I missing something? Adriano -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4620 bytes Desc: Firma crittografica S/MIME URL: From martijn.katerbarg at sectigo.com Mon Oct 16 14:16:31 2023 From: martijn.katerbarg at sectigo.com (Martijn Katerbarg) Date: Mon, 16 Oct 2023 14:16:31 +0000 Subject: [Smcwg-public] SV certificates devoid of individual attributes In-Reply-To: <0100018b38c230fd-55ffb488-7bd3-40dc-bb81-ae9febdeb5fb-000000@email.amazonses.com> References: <0100018b324261c8-759958ef-6e5c-48f1-881a-a9faa732bb01-000000@email.amazonses.com> <0100018b38c230fd-55ffb488-7bd3-40dc-bb81-ae9febdeb5fb-000000@email.amazonses.com> Message-ID: ?Hi Adriano, Yes, I do believe you?re correct. Taking your example, the only difference would be the Policy OID in the certificate. I?m not sure why anyone would in that case opt for a Sponsor Validated cert over OV, however it does appear to be compliant, yet only for Legacy templates. Regards, Martijn From: Smcwg-public on behalf of Adriano Santoni via Smcwg-public Date: Monday, 16 October 2023 at 15:52 To: smcwg-public at cabforum.org Subject: [Smcwg-public] SV certificates devoid of individual attributes CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hello all, I have the impression that the current SMBRs allow to issue Sponsor-Validated certificates which, contrary to the definition of this type of certificate, do not contain any "Individual (Natural Person) attributes" (quoting from the definition of Sponsor-Validated). At least, this seems to hold for the "Legacy Generation profiles". * according to ?3.1.1 and ?7.1.4.2.2, the commonName does not necessarily have to contain a Personal Name (in fact it MAY contain a Mailbox Address) * according to ?7.1.4.2.5, givenName and surname attributes are not required in "Legacy Generation profiles". Furthermore, as already discussed in a previous thread, there is no requirement that a personal email address have a "personal" appearance (e.g. forename.surname at company.com ). Therefore, if I understand correctly, a Subject of the following type within a "Legacy" SV (Sponsor-Validated) certificate would be 100% compliant: CN=info at example.com , O=Example HmbH, organizationIdentifier=NTRXX-xxxxx, C=XX If this is true, it would make no difference if the certificate was OV rather than SV: the Subject could be identical in the two cases, and it would be devoid of "Individual (Natural Person) attibutes". Is the above correct, or am I missing something? Adriano -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 8254 bytes Desc: not available URL: From adriano.santoni at staff.aruba.it Mon Oct 16 14:28:21 2023 From: adriano.santoni at staff.aruba.it (Adriano Santoni) Date: Mon, 16 Oct 2023 16:28:21 +0200 Subject: [Smcwg-public] [External Sender] Re: SV certificates devoid of individual attributes In-Reply-To: References: <0100018b324261c8-759958ef-6e5c-48f1-881a-a9faa732bb01-000000@email.amazonses.com> <0100018b38c230fd-55ffb488-7bd3-40dc-bb81-ae9febdeb5fb-000000@email.amazonses.com> Message-ID: <5a4ededc-382e-43cd-be96-a4042ac64888@staff.aruba.it> Well, in my opinion that's not a good thing. Adriano Il 16/10/2023 16:16, Martijn Katerbarg ha scritto: > > Hi Adriano, > > > Yes, I do believe you?re correct. Taking your example, the only > difference would be the Policy OID in the certificate. > > I?m not sure why anyone would in that case opt for a Sponsor Validated > cert over OV, however it does appear to be compliant, yet only for > Legacy templates. > > Regards, > > Martijn > > *From: *Smcwg-public on behalf of > Adriano Santoni via Smcwg-public > *Date: *Monday, 16 October 2023 at 15:52 > *To: *smcwg-public at cabforum.org > *Subject: *[Smcwg-public] SV certificates devoid of individual attributes > > CAUTION: This email originated from outside of the organization. Do > not click links or open attachments unless you recognize the sender > and know the content is safe. > > Hello all, > > I have the impression that the current SMBRs allow to issue > Sponsor-Validated certificates which, contrary to the definition of > this type of certificate, do not contain any "Individual (Natural > Person) attributes" (quoting from the definition of > Sponsor-Validated). At least, this seems to hold for the "Legacy > Generation profiles". > > * according to ?3.1.1 and ?7.1.4.2.2, the commonName does not > necessarily have to contain a Personal Name (in fact it MAY > contain a Mailbox Address) > > * according to ?7.1.4.2.5, givenName and surname attributes are not > required in "Legacy Generation profiles". > > Furthermore, as already discussed in a previous thread, there is no > requirement that a personal email address have a "personal" appearance > (e.g. forename.surname at company.com). > > Therefore, if I understand correctly, a Subject of the following type > within a "Legacy" SV (Sponsor-Validated) certificate would be 100% > compliant: > > CN=info at example.com, O=Example HmbH, > organizationIdentifier=NTRXX-xxxxx, C=XX > > If this is true, it would make no difference if the certificate was OV > rather than SV: the Subject could be identical in the two cases, and > it would be devoid of "Individual (Natural Person) attibutes". > > Is the above correct, or am I missing something? > > Adriano > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4620 bytes Desc: Firma crittografica S/MIME URL: From dzacharo at harica.gr Mon Oct 16 15:17:48 2023 From: dzacharo at harica.gr (Dimitris Zacharopoulos) Date: Mon, 16 Oct 2023 18:17:48 +0300 (GMT+03:00) Subject: [Smcwg-public] [External Sender] Re: SV certificates devoid of individual attributes In-Reply-To: <0100018b38e3720f-4c2e834e-186a-4700-916e-63a9126dd9ec-000000@email.amazonses.com> References: <0100018b324261c8-759958ef-6e5c-48f1-881a-a9faa732bb01-000000@email.amazonses.com> <0100018b38c230fd-55ffb488-7bd3-40dc-bb81-ae9febdeb5fb-000000@email.amazonses.com> <0100018b38e3720f-4c2e834e-186a-4700-916e-63a9126dd9ec-000000@email.amazonses.com> Message-ID: <570bb783-f31d-4fad-82fe-83a6704ebada@harica.gr> I agree it's not a good thing. The SV profile was to support certificates that include attributes of individuals validated by the Enterprise RA. If we allow those to be missing, making it effectively an OV Certificate, seems like an unintended result. Best regards, -------------- next part -------------- An HTML attachment was scrubbed... URL: From adriano.santoni at staff.aruba.it Mon Oct 16 16:08:54 2023 From: adriano.santoni at staff.aruba.it (Adriano Santoni) Date: Mon, 16 Oct 2023 18:08:54 +0200 Subject: [Smcwg-public] [External Sender] Re: Re: SV certificates devoid of individual attributes In-Reply-To: <0100018b3910b1a1-5f63e11d-cb86-4599-8385-07abf817d4d1-000000@email.amazonses.com> References: <0100018b324261c8-759958ef-6e5c-48f1-881a-a9faa732bb01-000000@email.amazonses.com> <0100018b38c230fd-55ffb488-7bd3-40dc-bb81-ae9febdeb5fb-000000@email.amazonses.com> <0100018b38e3720f-4c2e834e-186a-4700-916e-63a9126dd9ec-000000@email.amazonses.com> <0100018b3910b1a1-5f63e11d-cb86-4599-8385-07abf817d4d1-000000@email.amazonses.com> Message-ID: I would suggest an amendment in order to correct this unintended result; I'm available to dratf a proposal it if there are any endorsers. Adriano Il 16/10/2023 17:17, Dimitris Zacharopoulos via Smcwg-public ha scritto: > NOTICE: Pay attention - external email - Sender is > 0100018b3910b1a1-5f63e11d-cb86-4599-8385-07abf817d4d1-000000 at amazonses.com > > > > > I agree it's not a good thing. The SV profile was to support > certificates that include attributes of individuals validated by the > Enterprise RA. If we allow those to be missing, making it effectively > an OV Certificate, seems like an unintended result. > > Best regards, > > _______________________________________________ > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4620 bytes Desc: Firma crittografica S/MIME URL: From martijn.katerbarg at sectigo.com Mon Oct 16 16:38:03 2023 From: martijn.katerbarg at sectigo.com (Martijn Katerbarg) Date: Mon, 16 Oct 2023 16:38:03 +0000 Subject: [Smcwg-public] [External Sender] Re: Re: SV certificates devoid of individual attributes In-Reply-To: <0100018b393f74f3-c92dc116-1edb-4c4e-8958-40777f6ae808-000000@email.amazonses.com> References: <0100018b324261c8-759958ef-6e5c-48f1-881a-a9faa732bb01-000000@email.amazonses.com> <0100018b38c230fd-55ffb488-7bd3-40dc-bb81-ae9febdeb5fb-000000@email.amazonses.com> <0100018b38e3720f-4c2e834e-186a-4700-916e-63a9126dd9ec-000000@email.amazonses.com> <0100018b3910b1a1-5f63e11d-cb86-4599-8385-07abf817d4d1-000000@email.amazonses.com> <0100018b393f74f3-c92dc116-1edb-4c4e-8958-40777f6ae808-000000@email.amazonses.com> Message-ID: ?Happy to work with you on that. I do wonder what the cause and original intent behind this was. I wonder if they key lies in the Note added to section 7.1.4.2.5: ?Legacy Generation profiles MAY omit the subject:givenName, subject:surname, and subject:pseudonym attributes and include only the subject:commonName as described in Section 7.1.4.2.2(a) .? Could it be that the original intent here was that subject:givenName, subject:surname and subject:pseudonym are allowed to be left out, only if subject:commonName was included and had either the pseudonym or givenName+surname in it? I could see that as a possible legacy use case, with the intend to deprecate. I?m not sure if any CA needs that use case at current though. Regards, Martijn From: Smcwg-public on behalf of Adriano Santoni via Smcwg-public Date: Monday, 16 October 2023 at 18:09 To: smcwg-public at cabforum.org Subject: Re: [Smcwg-public] [External Sender] Re: Re: SV certificates devoid of individual attributes CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. I would suggest an amendment in order to correct this unintended result; I'm available to dratf a proposal it if there are any endorsers. Adriano Il 16/10/2023 17:17, Dimitris Zacharopoulos via Smcwg-public ha scritto: NOTICE: Pay attention - external email - Sender is 0100018b3910b1a1-5f63e11d-cb86-4599-8385-07abf817d4d1-000000 at amazonses.com I agree it's not a good thing. The SV profile was to support certificates that include attributes of individuals validated by the Enterprise RA. If we allow those to be missing, making it effectively an OV Certificate, seems like an unintended result. Best regards, _______________________________________________ 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 8254 bytes Desc: not available URL: From adriano.santoni at staff.aruba.it Tue Oct 17 06:59:06 2023 From: adriano.santoni at staff.aruba.it (Adriano Santoni) Date: Tue, 17 Oct 2023 08:59:06 +0200 Subject: [Smcwg-public] [External Sender] Re: Re: Re: SV certificates devoid of individual attributes In-Reply-To: References: <0100018b324261c8-759958ef-6e5c-48f1-881a-a9faa732bb01-000000@email.amazonses.com> <0100018b38c230fd-55ffb488-7bd3-40dc-bb81-ae9febdeb5fb-000000@email.amazonses.com> <0100018b38e3720f-4c2e834e-186a-4700-916e-63a9126dd9ec-000000@email.amazonses.com> <0100018b3910b1a1-5f63e11d-cb86-4599-8385-07abf817d4d1-000000@email.amazonses.com> <0100018b393f74f3-c92dc116-1edb-4c4e-8958-40777f6ae808-000000@email.amazonses.com> Message-ID: <9d09b275-4783-4500-a78c-332f83a5ec5a@staff.aruba.it> As a first idea, how about rewording that note in ?7.1.4.2.5 the following way? > ?Legacy Generation profiles MAY omit the |subject:givenName|, > |subject:surname|, and |subject:pseudonym| attributes and include only > the |subject:commonName| as described in Section 7.1.4.2.2(a) > , > provided that a Personal Name (see Section 3.1.2) is included in > |subject:commonName|.? > Adriano Il 16/10/2023 18:38, Martijn Katerbarg ha scritto: > > Happy to work with you on that. I do wonder what the cause and > original intent behind this was. > > I wonder if they key lies in the Note added to section 7.1.4.2.5: > > ?Legacy Generation profiles MAY omit the |subject:givenName|, > |subject:surname|, and |subject:pseudonym| attributes and include only > the |subject:commonName| as described in Section 7.1.4.2.2(a) > .? > > Could it be that the original intent here was that subject:givenName, > subject:surname and subject:pseudonym are allowed to be left out, > *only* if subject:commonName was included *and* had either the > pseudonym or givenName+surname in it? > > I could see that as a possible legacy use case, with the intend to > deprecate. I?m not sure if any CA needs that use case at current though. > > Regards, > > Martijn > > *From: *Smcwg-public on behalf of > Adriano Santoni via Smcwg-public > *Date: *Monday, 16 October 2023 at 18:09 > *To: *smcwg-public at cabforum.org > *Subject: *Re: [Smcwg-public] [External Sender] Re: Re: SV > certificates devoid of individual attributes > > CAUTION: This email originated from outside of the organization. Do > not click links or open attachments unless you recognize the sender > and know the content is safe. > > I would suggest an amendment in order to correct this unintended > result; I'm available to dratf a proposal it if there are any endorsers. > > Adriano > > Il 16/10/2023 17:17, Dimitris Zacharopoulos via Smcwg-public ha scritto: > > NOTICE:Pay attention - external email - Sender is > 0100018b3910b1a1-5f63e11d-cb86-4599-8385-07abf817d4d1-000000 at amazonses.com > > > I agree it's not a good thing. The SV profile was to support > certificates that include attributes of individuals validated by > the Enterprise RA. If we allow those to be missing, making it > effectively an OV Certificate, seems like an unintended result. > > Best regards, > > > > _______________________________________________ > > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4620 bytes Desc: Firma crittografica S/MIME URL: From pekka.lahtiharju at teliacompany.com Tue Oct 17 05:50:08 2023 From: pekka.lahtiharju at teliacompany.com (Lahtiharju, Pekka) Date: Tue, 17 Oct 2023 05:50:08 +0000 Subject: [Smcwg-public] [External Sender] Re: Re: SV certificates devoid of individual attributes In-Reply-To: <0100018b395a2a94-d7d11c78-fd9e-431b-a6ae-90f2608922ed-000000@email.amazonses.com> References: <0100018b324261c8-759958ef-6e5c-48f1-881a-a9faa732bb01-000000@email.amazonses.com> <0100018b38c230fd-55ffb488-7bd3-40dc-bb81-ae9febdeb5fb-000000@email.amazonses.com> <0100018b38e3720f-4c2e834e-186a-4700-916e-63a9126dd9ec-000000@email.amazonses.com> <0100018b3910b1a1-5f63e11d-cb86-4599-8385-07abf817d4d1-000000@email.amazonses.com> <0100018b393f74f3-c92dc116-1edb-4c4e-8958-40777f6ae808-000000@email.amazonses.com> <0100018b395a2a94-d7d11c78-fd9e-431b-a6ae-90f2608922ed-000000@email.amazonses.com> Message-ID: Hi, Telia had a legacy use case to create smime certificates to enterprise RA for some teams instead of a single persons. For that purpose it would be good to omit subject:givenName and subject:surname and put group name to CN and still use O value also. I suppose this is one use case for the conditions below? Br Pekka Telia From: Smcwg-public On Behalf Of Martijn Katerbarg via Smcwg-public Sent: Monday, October 16, 2023 7:38 PM To: Adriano Santoni ; SMIME Certificate Working Group Subject: Re: [Smcwg-public] [External Sender] Re: Re: SV certificates devoid of individual attributes Happy to work with you on that. I do wonder what the cause and original intent behind this was. I wonder if they key lies in the Note added to section 7.1.4.2.5: ?Legacy Generation profiles MAY omit the subject:givenName, subject:surname, and subject:pseudonym attributes and include only the subject:commonName as described in Section 7.1.4.2.2(a).? Could it be that the original intent here was that subject:givenName, subject:surname and subject:pseudonym are allowed to be left out, only if subject:commonName was included and had either the pseudonym or givenName+surname in it? I could see that as a possible legacy use case, with the intend to deprecate. I?m not sure if any CA needs that use case at current though. Regards, Martijn From: Smcwg-public > on behalf of Adriano Santoni via Smcwg-public > Date: Monday, 16 October 2023 at 18:09 To: smcwg-public at cabforum.org > Subject: Re: [Smcwg-public] [External Sender] Re: Re: SV certificates devoid of individual attributes CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. I would suggest an amendment in order to correct this unintended result; I'm available to dratf a proposal it if there are any endorsers. Adriano Il 16/10/2023 17:17, Dimitris Zacharopoulos via Smcwg-public ha scritto: NOTICE: Pay attention - external email - Sender is 0100018b3910b1a1-5f63e11d-cb86-4599-8385-07abf817d4d1-000000 at amazonses.com I agree it's not a good thing. The SV profile was to support certificates that include attributes of individuals validated by the Enterprise RA. If we allow those to be missing, making it effectively an OV Certificate, seems like an unintended result. Best regards, _______________________________________________ Smcwg-public mailing list Smcwg-public at cabforum.org https://lists.cabforum.org/mailman/listinfo/smcwg-public This email may contain information which is privileged or protected against unauthorized disclosure or communication. If you are not the intended recipient, please notify the sender and delete this message and any attachments from your system without producing, distributing or retaining copies thereof or disclosing its contents to any other person. Telia Company processes emails and other files that may contain personal data in accordance with Telia Company?s Privacy Policy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From adriano.santoni at staff.aruba.it Thu Oct 19 11:27:37 2023 From: adriano.santoni at staff.aruba.it (Adriano Santoni) Date: Thu, 19 Oct 2023 13:27:37 +0200 Subject: [Smcwg-public] [External Sender] Re: Re: Re: SV certificates devoid of individual attributes In-Reply-To: References: <0100018b324261c8-759958ef-6e5c-48f1-881a-a9faa732bb01-000000@email.amazonses.com> <0100018b38c230fd-55ffb488-7bd3-40dc-bb81-ae9febdeb5fb-000000@email.amazonses.com> <0100018b38e3720f-4c2e834e-186a-4700-916e-63a9126dd9ec-000000@email.amazonses.com> <0100018b3910b1a1-5f63e11d-cb86-4599-8385-07abf817d4d1-000000@email.amazonses.com> <0100018b393f74f3-c92dc116-1edb-4c4e-8958-40777f6ae808-000000@email.amazonses.com> Message-ID: I have created the pull request below. https://github.com/cabforum/smime/pull/218 Even if there exists some niche legacy uses cases, I believe it would be highly preferable to avoid allowing SV certificates that do not match the SV definition and are indistinguishable from OV certs. Besides, it appears that in such particular contexts OV certificates would still meet the need. Looking for endorsers. Adriano Il 16/10/2023 18:38, Martijn Katerbarg ha scritto: > > Happy to work with you on that. I do wonder what the cause and > original intent behind this was. > > I wonder if they key lies in the Note added to section 7.1.4.2.5: > > ?Legacy Generation profiles MAY omit the |subject:givenName|, > |subject:surname|, and |subject:pseudonym| attributes and include only > the |subject:commonName| as described in Section 7.1.4.2.2(a) > .? > > Could it be that the original intent here was that subject:givenName, > subject:surname and subject:pseudonym are allowed to be left out, > *only* if subject:commonName was included *and* had either the > pseudonym or givenName+surname in it? > > I could see that as a possible legacy use case, with the intend to > deprecate. I?m not sure if any CA needs that use case at current though. > > Regards, > > Martijn > > *From: *Smcwg-public on behalf of > Adriano Santoni via Smcwg-public > *Date: *Monday, 16 October 2023 at 18:09 > *To: *smcwg-public at cabforum.org > *Subject: *Re: [Smcwg-public] [External Sender] Re: Re: SV > certificates devoid of individual attributes > > CAUTION: This email originated from outside of the organization. Do > not click links or open attachments unless you recognize the sender > and know the content is safe. > > I would suggest an amendment in order to correct this unintended > result; I'm available to dratf a proposal it if there are any endorsers. > > Adriano > > Il 16/10/2023 17:17, Dimitris Zacharopoulos via Smcwg-public ha scritto: > > NOTICE:Pay attention - external email - Sender is > 0100018b3910b1a1-5f63e11d-cb86-4599-8385-07abf817d4d1-000000 at amazonses.com > > > I agree it's not a good thing. The SV profile was to support > certificates that include attributes of individuals validated by > the Enterprise RA. If we allow those to be missing, making it > effectively an OV Certificate, seems like an unintended result. > > Best regards, > > > > _______________________________________________ > > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4620 bytes Desc: Firma crittografica S/MIME URL: From ashish.dhiman at globalsign.com Fri Oct 20 08:20:54 2023 From: ashish.dhiman at globalsign.com (Ashish Dhiman) Date: Fri, 20 Oct 2023 08:20:54 +0000 Subject: [Smcwg-public] [External Sender] Re: Re: Re: SV certificates devoid of individual attributes In-Reply-To: <0100018b47b2dc1f-b1efe9cd-1d0a-4f56-8237-2026830092c5-000000@email.amazonses.com> References: <0100018b324261c8-759958ef-6e5c-48f1-881a-a9faa732bb01-000000@email.amazonses.com> <0100018b38c230fd-55ffb488-7bd3-40dc-bb81-ae9febdeb5fb-000000@email.amazonses.com> <0100018b38e3720f-4c2e834e-186a-4700-916e-63a9126dd9ec-000000@email.amazonses.com> <0100018b3910b1a1-5f63e11d-cb86-4599-8385-07abf817d4d1-000000@email.amazonses.com> <0100018b393f74f3-c92dc116-1edb-4c4e-8958-40777f6ae808-000000@email.amazonses.com> <0100018b47b2dc1f-b1efe9cd-1d0a-4f56-8237-2026830092c5-000000@email.amazonses.com> Message-ID: Respected: CA/B ? S/MIME Forum Members. I feel the problem that we are trying to solve by prohibiting email address from CN in Legacy will only make things complex rather than solve it. During our discussion, the intent for legacy, always was to have minimum impact on existing practices and give time for wider industry to move to multipurpose or strict profile. I feel, we are defeating the whole purpose of legacy with suggested change, as I am trying to understand how; eliminating email address from CN will help us differentiate a sponsor profile from organization profile. As, Technically, people can still use department at example.com in sponsor profile as email address and also use ashish.dhiman at globalsign.com in Organization Profile as email address. On the other hand, this change will also deviate from current practices for CN use for legacy use cases Also, during implementation, we see in most of the cases; email address used in Sponsor profiles are correct. I think removing email in CN makes legacy no longer like legacy and seems to make it stricter than multi and strict where its allowed. There is also no indication that the intent for changes, will be achieved without mandatory use of Given Name and Sur Name in Legacy profile, which is again a big change considering legacy intent, and make these profiles similar to multi and strict version. Overall, this change seems to defeat its goal of supporting wider ecosystem for a while. Ashish From: Smcwg-public On Behalf Of Adriano Santoni via Smcwg-public Sent: Thursday, October 19, 2023 5:00 PM To: Martijn Katerbarg ; SMIME Certificate Working Group Subject: Re: [Smcwg-public] [External Sender] Re: Re: Re: SV certificates devoid of individual attributes I have created the pull request below. https://github.com/cabforum/smime/pull/218 Even if there exists some niche legacy uses cases, I believe it would be highly preferable to avoid allowing SV certificates that do not match the SV definition and are indistinguishable from OV certs. Besides, it appears that in such particular contexts OV certificates would still meet the need. Looking for endorsers. Adriano Il 16/10/2023 18:38, Martijn Katerbarg ha scritto: Happy to work with you on that. I do wonder what the cause and original intent behind this was. I wonder if they key lies in the Note added to section 7.1.4.2.5: ?Legacy Generation profiles MAY omit the subject:givenName, subject:surname, and subject:pseudonym attributes and include only the subject:commonName as described in Section 7.1.4.2.2(a).? Could it be that the original intent here was that subject:givenName, subject:surname and subject:pseudonym are allowed to be left out, only if subject:commonName was included and had either the pseudonym or givenName+surname in it? I could see that as a possible legacy use case, with the intend to deprecate. I?m not sure if any CA needs that use case at current though. Regards, Martijn From: Smcwg-public on behalf of Adriano Santoni via Smcwg-public Date: Monday, 16 October 2023 at 18:09 To: smcwg-public at cabforum.org Subject: Re: [Smcwg-public] [External Sender] Re: Re: SV certificates devoid of individual attributes CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. I would suggest an amendment in order to correct this unintended result; I'm available to dratf a proposal it if there are any endorsers. Adriano Il 16/10/2023 17:17, Dimitris Zacharopoulos via Smcwg-public ha scritto: NOTICE: Pay attention - external email - Sender is 0100018b3910b1a1-5f63e11d-cb86-4599-8385-07abf817d4d1-000000 at amazonses.com I agree it's not a good thing. The SV profile was to support certificates that include attributes of individuals validated by the Enterprise RA. If we allow those to be missing, making it effectively an OV Certificate, seems like an unintended result. Best regards, _______________________________________________ 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: From adriano.santoni at staff.aruba.it Fri Oct 20 08:32:49 2023 From: adriano.santoni at staff.aruba.it (Adriano Santoni) Date: Fri, 20 Oct 2023 10:32:49 +0200 Subject: [Smcwg-public] [External Sender] RE: Re: Re: Re: SV certificates devoid of individual attributes In-Reply-To: References: <0100018b324261c8-759958ef-6e5c-48f1-881a-a9faa732bb01-000000@email.amazonses.com> <0100018b38c230fd-55ffb488-7bd3-40dc-bb81-ae9febdeb5fb-000000@email.amazonses.com> <0100018b38e3720f-4c2e834e-186a-4700-916e-63a9126dd9ec-000000@email.amazonses.com> <0100018b3910b1a1-5f63e11d-cb86-4599-8385-07abf817d4d1-000000@email.amazonses.com> <0100018b393f74f3-c92dc116-1edb-4c4e-8958-40777f6ae808-000000@email.amazonses.com> <0100018b47b2dc1f-b1efe9cd-1d0a-4f56-8237-2026830092c5-000000@email.amazonses.com> Message-ID: <80503996-4dc6-4e6f-8d8c-9f1fdea3f927@staff.aruba.it> Ashish, my intent would not be to prohibit anything, but rather to make two types of certificates (OV, SV) distinguishable that otherwise are not, and to make the S/MIME baseline requirements consistent with the definition of Sponsor-Validated. Furthermore, I don't understand why what I'm proposing could cause problems for those who need, for their legacy use case, S/MIME certificates that simultaneously contain Subject.organizationName AND /any type /of email address in the Subject.commonName (like department at example.com or ashish.dhiman at globalsign.com to quote your examples), plus of course locality and organizationIdentifier. In fact, in such use case you can very well use OV-type S/MIME certificates. Don't you? Adriano Il 20/10/2023 10:20, Ashish Dhiman ha scritto: > NOTICE: Pay attention - external email - Sender is > ashish.dhiman at globalsign.com > > > > Respected: CA/B ? S/MIME Forum Members. > > I feel the problem that we are trying to solve by prohibiting email > address from CN in Legacy will only make things complex rather than > solve it. During our discussion, the intent for legacy, always was to > have minimum impact on existing practices and give time for wider > industry to move to multipurpose or strict profile. I feel, we are > defeating the whole purpose of legacy with suggested change, as I am > trying to understand how; eliminating email address from CN will help > us differentiate a sponsor profile from organization profile. As, > Technically, people can still use department at example.com in sponsor > profile as email address and also use ashish.dhiman at globalsign.com in > Organization Profile as email address. > > On the other hand, this change will also deviate from current > practices for CN use for legacy use cases Also, during implementation, > we see in most of the cases; email address used in Sponsor profiles > are correct. > > I think removing email in CN makes legacy no longer like legacy and > seems to make it stricter than multi and strict where its allowed. > There is also no indication that the intent for changes, will be > achieved without mandatory use of Given Name and Sur Name in Legacy > profile, which is again a big change considering legacy intent, and > make these profiles similar to multi and strict version. Overall, this > change seems to defeat its goal of supporting wider ecosystem for a > while. > > Ashish > > *From:* Smcwg-public *On Behalf > Of* Adriano Santoni via Smcwg-public > *Sent:* Thursday, October 19, 2023 5:00 PM > *To:* Martijn Katerbarg ; SMIME > Certificate Working Group > *Subject:* Re: [Smcwg-public] [External Sender] Re: Re: Re: SV > certificates devoid of individual attributes > > I have created the pull request below. > > https://github.com/cabforum/smime/pull/218 > > Even if there exists some niche legacy uses cases, I believe it would > be highly preferable to avoid allowing SV certificates that do not > match the SV definition and are indistinguishable from OV certs. > Besides, it appears that in such particular contexts OV certificates > would still meet the need. > > Looking for endorsers. > > Adriano > > Il 16/10/2023 18:38, Martijn Katerbarg ha scritto: > > Happy to work with you on that. I do wonder what the cause and > original intent behind this was. > > I wonder if they key lies in the Note added to section 7.1.4.2.5: > > ?Legacy Generation profiles MAY omit the |subject:givenName|, > |subject:surname|, and |subject:pseudonym| attributes and include > only the |subject:commonName| as described in Section 7.1.4.2.2(a) > .? > > Could it be that the original intent here was that > subject:givenName, subject:surname and subject:pseudonym are > allowed to be left out, *only* if subject:commonName was included > *and* had either the pseudonym or givenName+surname in it? > > > I could see that as a possible legacy use case, with the intend to > deprecate. I?m not sure if any CA needs that use case at current > though. > > Regards, > > Martijn > > *From:* Smcwg-public > on behalf of Adriano > Santoni via Smcwg-public > > *Date:* Monday, 16 October 2023 at 18:09 > *To:* smcwg-public at cabforum.org > > *Subject:* Re: [Smcwg-public] [External Sender] Re: Re: SV > certificates devoid of individual attributes > > CAUTION: This email originated from outside of the organization. > Do not click links or open attachments unless you recognize the > sender and know the content is safe. > > I would suggest an amendment in order to correct this unintended > result; I'm available to dratf a proposal it if there are any > endorsers. > > Adriano > > Il 16/10/2023 17:17, Dimitris Zacharopoulos via Smcwg-public ha > scritto: > > NOTICE: Pay attention - external email - Sender is > 0100018b3910b1a1-5f63e11d-cb86-4599-8385-07abf817d4d1-000000 at amazonses.com > > > I agree it's not a good thing. The SV profile was to support > certificates that include attributes of individuals validated > by the Enterprise RA. If we allow those to be missing, making > it effectively an OV Certificate, seems like an unintended result. > > Best regards, > > > > > _______________________________________________ > > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4620 bytes Desc: Firma crittografica S/MIME URL: From infra-bot at cabforum.org Sun Oct 22 07:34:28 2023 From: infra-bot at cabforum.org (Infrastructure Bot) Date: Sun, 22 Oct 2023 07:34:28 +0000 Subject: [Smcwg-public] Weekly github digest (S/MIME Certificate Working Group) Message-ID: <0100018b564e864d-97a4cbeb-9440-4aa1-bdec-e313a855a50b-000000@email.amazonses.com> Issues ------ * cabforum/smime (+0/-0/?2) 2 issues received 2 new comments: - #199 Repeated subject DN attributes (1 by romanf) https://github.com/cabforum/smime/issues/199 - #7 CAA (1 by CBonnell) https://github.com/cabforum/smime/issues/7 [Future Version] Pull requests ------------- * cabforum/smime (+1/-0/?2) 1 pull requests submitted: - Modified note 1 in 7.1.4.2.5 to ensure that an SV certificate always contain Individual (Natural Person) attributes as per definition of SV (by defacto64) https://github.com/cabforum/smime/pull/218 1 pull requests received 2 new comments: - #217 SMCXX: Backdating revocations (2 by TaaviE, russhousley) https://github.com/cabforum/smime/pull/217 Repositories tracked by this digest: ----------------------------------- * https://github.com/cabforum/smime -------------- next part -------------- An HTML attachment was scrubbed... URL: From dzacharo at harica.gr Tue Oct 24 04:16:57 2023 From: dzacharo at harica.gr (Dimitris Zacharopoulos (HARICA)) Date: Tue, 24 Oct 2023 07:16:57 +0300 Subject: [Smcwg-public] [External Sender] Re: Re: Re: SV certificates devoid of individual attributes In-Reply-To: <0100018b47b2e127-c6806ded-e801-438d-92de-4436c1be591b-000000@email.amazonses.com> References: <0100018b324261c8-759958ef-6e5c-48f1-881a-a9faa732bb01-000000@email.amazonses.com> <0100018b38c230fd-55ffb488-7bd3-40dc-bb81-ae9febdeb5fb-000000@email.amazonses.com> <0100018b38e3720f-4c2e834e-186a-4700-916e-63a9126dd9ec-000000@email.amazonses.com> <0100018b3910b1a1-5f63e11d-cb86-4599-8385-07abf817d4d1-000000@email.amazonses.com> <0100018b393f74f3-c92dc116-1edb-4c4e-8958-40777f6ae808-000000@email.amazonses.com> <0100018b47b2e127-c6806ded-e801-438d-92de-4436c1be591b-000000@email.amazonses.com> Message-ID: On 19/10/2023 2:29 ?.?., Adriano Santoni via Smcwg-public wrote: > > I have created the pull request below. > > https://github.com/cabforum/smime/pull/218 > > Even if there exists some niche legacy uses cases, I believe it would > be highly preferable to avoid allowing SV certificates that do not > match the SV definition and are indistinguishable from OV certs. > Besides, it appears that in such particular contexts OV certificates > would still meet the need. > I suggested a small improvement in https://github.com/cabforum/smime/pull/218/files#r1369612850. > Looking for endorsers. > Happy to endorse. Dimitris. > Adriano > > > Il 16/10/2023 18:38, Martijn Katerbarg ha scritto: >> >> Happy to work with you on that. I do wonder what the cause and >> original intent behind this was. >> >> I wonder if they key lies in the Note added to section 7.1.4.2.5: >> >> ?Legacy Generation profiles MAY omit the |subject:givenName|, >> |subject:surname|, and |subject:pseudonym| attributes and include >> only the |subject:commonName| as described in Section 7.1.4.2.2(a) >> .? >> >> Could it be that the original intent here was that subject:givenName, >> subject:surname and subject:pseudonym are allowed to be left out, >> *only* if subject:commonName was included *and* had either the >> pseudonym or givenName+surname in it? >> >> I could see that as a possible legacy use case, with the intend to >> deprecate. I?m not sure if any CA needs that use case at current though. >> >> Regards, >> >> Martijn >> >> *From: *Smcwg-public on behalf of >> Adriano Santoni via Smcwg-public >> *Date: *Monday, 16 October 2023 at 18:09 >> *To: *smcwg-public at cabforum.org >> *Subject: *Re: [Smcwg-public] [External Sender] Re: Re: SV >> certificates devoid of individual attributes >> >> CAUTION: This email originated from outside of the organization. Do >> not click links or open attachments unless you recognize the sender >> and know the content is safe. >> >> I would suggest an amendment in order to correct this unintended >> result; I'm available to dratf a proposal it if there are any endorsers. >> >> Adriano >> >> Il 16/10/2023 17:17, Dimitris Zacharopoulos via Smcwg-public ha scritto: >> >> NOTICE:Pay attention - external email - Sender is >> 0100018b3910b1a1-5f63e11d-cb86-4599-8385-07abf817d4d1-000000 at amazonses.com >> >> >> I agree it's not a good thing. The SV profile was to support >> certificates that include attributes of individuals validated by >> the Enterprise RA. If we allow those to be missing, making it >> effectively an OV Certificate, seems like an unintended result. >> >> Best regards, >> >> >> >> _______________________________________________ >> >> 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: From christophe.bonjean at globalsign.com Tue Oct 24 07:25:52 2023 From: christophe.bonjean at globalsign.com (Christophe Bonjean) Date: Tue, 24 Oct 2023 07:25:52 +0000 Subject: [Smcwg-public] [External Sender] RE: Re: Re: Re: SV certificates devoid of individual attributes In-Reply-To: <0100018b4c375d14-06845541-1a13-4297-9111-352031db6468-000000@email.amazonses.com> References: <0100018b324261c8-759958ef-6e5c-48f1-881a-a9faa732bb01-000000@email.amazonses.com> <0100018b38c230fd-55ffb488-7bd3-40dc-bb81-ae9febdeb5fb-000000@email.amazonses.com> <0100018b38e3720f-4c2e834e-186a-4700-916e-63a9126dd9ec-000000@email.amazonses.com> <0100018b3910b1a1-5f63e11d-cb86-4599-8385-07abf817d4d1-000000@email.amazonses.com> <0100018b393f74f3-c92dc116-1edb-4c4e-8958-40777f6ae808-000000@email.amazonses.com> <0100018b47b2dc1f-b1efe9cd-1d0a-4f56-8237-2026830092c5-000000@email.amazonses.com> <0100018b4c375d14-06845541-1a13-4297-9111-352031db6468-000000@email.amazonses.com> Message-ID: Hi Adriano, >From your proposed change, it seems that you are not considering a mailbox address as an individual (natural person) attribute? Could you provide some context on that? We should also keep in mind the initial purpose of the legacy profile. Even though the suggestion of using an OV profile for CN=email, O=Company might be sensible, we?re still fundamentally modifying the legacy SV profile. Christophe From: Smcwg-public On Behalf Of Adriano Santoni via Smcwg-public Sent: Friday, October 20, 2023 10:33 AM To: Ashish Dhiman ; SMIME Certificate Working Group ; Martijn Katerbarg Subject: Re: [Smcwg-public] [External Sender] RE: Re: Re: Re: SV certificates devoid of individual attributes Ashish, my intent would not be to prohibit anything, but rather to make two types of certificates (OV, SV) distinguishable that otherwise are not, and to make the S/MIME baseline requirements consistent with the definition of Sponsor-Validated. Furthermore, I don't understand why what I'm proposing could cause problems for those who need, for their legacy use case, S/MIME certificates that simultaneously contain Subject.organizationName AND any type of email address in the Subject.commonName (like department at example.com or ashish.dhiman at globalsign.com to quote your examples), plus of course locality and organizationIdentifier. In fact, in such use case you can very well use OV-type S/MIME certificates. Don't you? Adriano Il 20/10/2023 10:20, Ashish Dhiman ha scritto: NOTICE: Pay attention - external email - Sender is ashish.dhiman at globalsign.com Respected: CA/B ? S/MIME Forum Members. I feel the problem that we are trying to solve by prohibiting email address from CN in Legacy will only make things complex rather than solve it. During our discussion, the intent for legacy, always was to have minimum impact on existing practices and give time for wider industry to move to multipurpose or strict profile. I feel, we are defeating the whole purpose of legacy with suggested change, as I am trying to understand how; eliminating email address from CN will help us differentiate a sponsor profile from organization profile. As, Technically, people can still use department at example.com in sponsor profile as email address and also use ashish.dhiman at globalsign.com in Organization Profile as email address. On the other hand, this change will also deviate from current practices for CN use for legacy use cases Also, during implementation, we see in most of the cases; email address used in Sponsor profiles are correct. I think removing email in CN makes legacy no longer like legacy and seems to make it stricter than multi and strict where its allowed. There is also no indication that the intent for changes, will be achieved without mandatory use of Given Name and Sur Name in Legacy profile, which is again a big change considering legacy intent, and make these profiles similar to multi and strict version. Overall, this change seems to defeat its goal of supporting wider ecosystem for a while. Ashish From: Smcwg-public On Behalf Of Adriano Santoni via Smcwg-public Sent: Thursday, October 19, 2023 5:00 PM To: Martijn Katerbarg ; SMIME Certificate Working Group Subject: Re: [Smcwg-public] [External Sender] Re: Re: Re: SV certificates devoid of individual attributes I have created the pull request below. https://github.com/cabforum/smime/pull/218 Even if there exists some niche legacy uses cases, I believe it would be highly preferable to avoid allowing SV certificates that do not match the SV definition and are indistinguishable from OV certs. Besides, it appears that in such particular contexts OV certificates would still meet the need. Looking for endorsers. Adriano Il 16/10/2023 18:38, Martijn Katerbarg ha scritto: Happy to work with you on that. I do wonder what the cause and original intent behind this was. I wonder if they key lies in the Note added to section 7.1.4.2.5: ?Legacy Generation profiles MAY omit the subject:givenName, subject:surname, and subject:pseudonym attributes and include only the subject:commonName as described in Section 7.1.4.2.2(a) .? Could it be that the original intent here was that subject:givenName, subject:surname and subject:pseudonym are allowed to be left out, only if subject:commonName was included and had either the pseudonym or givenName+surname in it? I could see that as a possible legacy use case, with the intend to deprecate. I?m not sure if any CA needs that use case at current though. Regards, Martijn From: Smcwg-public on behalf of Adriano Santoni via Smcwg-public Date: Monday, 16 October 2023 at 18:09 To: smcwg-public at cabforum.org Subject: Re: [Smcwg-public] [External Sender] Re: Re: SV certificates devoid of individual attributes CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. I would suggest an amendment in order to correct this unintended result; I'm available to dratf a proposal it if there are any endorsers. Adriano Il 16/10/2023 17:17, Dimitris Zacharopoulos via Smcwg-public ha scritto: NOTICE: Pay attention - external email - Sender is 0100018b3910b1a1-5f63e11d-cb86-4599-8385-07abf817d4d1-000000 at amazonses.com I agree it's not a good thing. The SV profile was to support certificates that include attributes of individuals validated by the Enterprise RA. If we allow those to be missing, making it effectively an OV Certificate, seems like an unintended result. Best regards, _______________________________________________ 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 8477 bytes Desc: not available URL: From adriano.santoni at staff.aruba.it Tue Oct 24 07:42:47 2023 From: adriano.santoni at staff.aruba.it (Adriano Santoni) Date: Tue, 24 Oct 2023 09:42:47 +0200 Subject: [Smcwg-public] [External Sender] RE: RE: Re: Re: Re: SV certificates devoid of individual attributes In-Reply-To: References: <0100018b324261c8-759958ef-6e5c-48f1-881a-a9faa732bb01-000000@email.amazonses.com> <0100018b38c230fd-55ffb488-7bd3-40dc-bb81-ae9febdeb5fb-000000@email.amazonses.com> <0100018b38e3720f-4c2e834e-186a-4700-916e-63a9126dd9ec-000000@email.amazonses.com> <0100018b3910b1a1-5f63e11d-cb86-4599-8385-07abf817d4d1-000000@email.amazonses.com> <0100018b393f74f3-c92dc116-1edb-4c4e-8958-40777f6ae808-000000@email.amazonses.com> <0100018b47b2dc1f-b1efe9cd-1d0a-4f56-8237-2026830092c5-000000@email.amazonses.com> <0100018b4c375d14-06845541-1a13-4297-9111-352031db6468-000000@email.amazonses.com> Message-ID: Hi Christophe, frankly, it seems obvious to me that an email address is not, generally speaking, an individual attribute. Would you argue that info at example.com is a natural person's attribute? It may be so in specific cases (for example when it is of the type givenname.surname at example.com and the email service provider applies a rule that ensures proper attribution to users and disambiguation of similar names), but it certainly is not so by definition. Evidently a natural person (or more likely more than one) can have access to the mailbox at an address like info at example.com, but it is evident that such address is not specific to any particular natural person in the same sense and in the same way in which givenname and surname are attributes of a natural person. And no, no intent at all to modify the SV profile; quite the opposite: to respect its definition even in the legacy case (where among other things, the needs of niche use cases can very well be satisfied by OV certificates). Adriano Il 24/10/2023 09:25, Christophe Bonjean ha scritto: > > Hi Adriano, > > From your proposed change, it seems that you are not considering a > mailbox address as an individual (natural person) attribute? Could you > provide some context on that? > > We should also keep in mind the initial purpose of the legacy profile. > Even though the suggestion of using an OV profile for CN=email, > O=Company might be sensible, we?re still fundamentally modifying the > legacy SV profile. > > Christophe > > *From:*Smcwg-public *On Behalf Of > *Adriano Santoni via Smcwg-public > *Sent:* Friday, October 20, 2023 10:33 AM > *To:* Ashish Dhiman ; SMIME Certificate > Working Group ; Martijn Katerbarg > > *Subject:* Re: [Smcwg-public] [External Sender] RE: Re: Re: Re: SV > certificates devoid of individual attributes > > Ashish, > > my intent would not be to prohibit anything, but rather to make two > types of certificates (OV, SV) distinguishable that otherwise are not, > and to make the S/MIME baseline requirements consistent with the > definition of Sponsor-Validated. > > Furthermore, I don't understand why what I'm proposing could cause > problems for those who need, for their legacy use case, S/MIME > certificates that simultaneously contain Subject.organizationName AND > /any type /of email address in the Subject.commonName (like > department at example.com or ashish.dhiman at globalsign.com to quote your > examples), plus of course locality and organizationIdentifier. In > fact, in such use case you can very well use OV-type S/MIME > certificates. Don't you? > > Adriano > > Il 20/10/2023 10:20, Ashish Dhiman ha scritto: > > NOTICE:Pay attention - external email - Sender is > ashish.dhiman at globalsign.com > > Respected: CA/B ? S/MIME Forum Members. > > I feel the problem that we are trying to solve by prohibiting > email address from CN in Legacy will only make things complex > rather than solve it. During our discussion, the intent for > legacy, always was to have minimum impact on existing practices > and give time for wider industry to move to multipurpose or strict > profile. I feel, we are defeating the whole purpose of legacy with > suggested change, as I am trying to understand how; eliminating > email address from CN will help us differentiate a sponsor profile > from organization profile. As, Technically, people can still use > department at example.com in sponsor profile as email address and > also use ashish.dhiman at globalsign.com in Organization Profile as > email address. > > On the other hand, this change will also deviate from current > practices for CN use for legacy use cases Also, during > implementation, we see in most of the cases; email address used in > Sponsor profiles are correct. > > I think removing email in CN makes legacy no longer like legacy > and seems to make it stricter than multi and strict where its > allowed. There is also no indication that the intent for changes, > will be achieved without mandatory use of Given Name and Sur Name > in Legacy profile, which is again a big change considering legacy > intent, and make these profiles similar to multi and strict > version. Overall, this change seems to defeat its goal of > supporting wider ecosystem for a while. > > Ashish > > *From:* Smcwg-public > *On Behalf Of* Adriano > Santoni via Smcwg-public > *Sent:* Thursday, October 19, 2023 5:00 PM > *To:* Martijn Katerbarg > ; SMIME Certificate Working > Group > *Subject:* Re: [Smcwg-public] [External Sender] Re: Re: Re: SV > certificates devoid of individual attributes > > I have created the pull request below. > > https://github.com/cabforum/smime/pull/218 > > Even if there exists some niche legacy uses cases, I believe it > would be highly preferable to avoid allowing SV certificates that > do not match the SV definition and are indistinguishable from OV > certs. Besides, it appears that in such particular contexts OV > certificates would still meet the need. > > Looking for endorsers. > > Adriano > > Il 16/10/2023 18:38, Martijn Katerbarg ha scritto: > > Happy to work with you on that. I do wonder what the cause and > original intent behind this was. > > I wonder if they key lies in the Note added to section 7.1.4.2.5: > > ?Legacy Generation profiles MAY omit the |subject:givenName|, > |subject:surname|, and |subject:pseudonym| attributes and > include only the |subject:commonName| as described in Section > 7.1.4.2.2(a) > .? > > Could it be that the original intent here was that > subject:givenName, subject:surname and subject:pseudonym are > allowed to be left out, *only* if subject:commonName was > included *and* had either the pseudonym or givenName+surname > in it? > > > > I could see that as a possible legacy use case, with the > intend to deprecate. I?m not sure if any CA needs that use > case at current though. > > Regards, > > Martijn > > *From:* Smcwg-public > on behalf of > Adriano Santoni via Smcwg-public > > *Date:* Monday, 16 October 2023 at 18:09 > *To:* smcwg-public at cabforum.org > > *Subject:* Re: [Smcwg-public] [External Sender] Re: Re: SV > certificates devoid of individual attributes > > CAUTION: This email originated from outside of the > organization. Do not click links or open attachments unless > you recognize the sender and know the content is safe. > > I would suggest an amendment in order to correct this > unintended result; I'm available to dratf a proposal it if > there are any endorsers. > > Adriano > > Il 16/10/2023 17:17, Dimitris Zacharopoulos via Smcwg-public > ha scritto: > > NOTICE:Pay attention - external email - Sender is > 0100018b3910b1a1-5f63e11d-cb86-4599-8385-07abf817d4d1-000000 at amazonses.com > > I agree it's not a good thing. The SV profile was to > support certificates that include attributes of > individuals validated by the Enterprise RA. If we allow > those to be missing, making it effectively an OV > Certificate, seems like an unintended result. > > Best regards, > > > > > > _______________________________________________ > > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4620 bytes Desc: Firma crittografica S/MIME URL: From christophe.bonjean at globalsign.com Tue Oct 24 08:14:41 2023 From: christophe.bonjean at globalsign.com (Christophe Bonjean) Date: Tue, 24 Oct 2023 08:14:41 +0000 Subject: [Smcwg-public] [External Sender] RE: RE: Re: Re: Re: SV certificates devoid of individual attributes In-Reply-To: References: <0100018b324261c8-759958ef-6e5c-48f1-881a-a9faa732bb01-000000@email.amazonses.com> <0100018b38c230fd-55ffb488-7bd3-40dc-bb81-ae9febdeb5fb-000000@email.amazonses.com> <0100018b38e3720f-4c2e834e-186a-4700-916e-63a9126dd9ec-000000@email.amazonses.com> <0100018b3910b1a1-5f63e11d-cb86-4599-8385-07abf817d4d1-000000@email.amazonses.com> <0100018b393f74f3-c92dc116-1edb-4c4e-8958-40777f6ae808-000000@email.amazonses.com> <0100018b47b2dc1f-b1efe9cd-1d0a-4f56-8237-2026830092c5-000000@email.amazonses.com> <0100018b4c375d14-06845541-1a13-4297-9111-352031db6468-000000@email.amazonses.com> Message-ID: Hi Adriano, There?s no definition to support that a mailbox address is an individual attribute in all cases, but as you indicated there are circumstances where it is (i.e. If the Subscriber or the Enterprise RA assert this is a mailbox address for an individual). I'm not convinced that this is sufficient reason to ban it completely. Although the purpose might be to align with the definition, we are changing the permitted contents of the CommonName, which is a significant change. I also think it?s up to the wider community to indicate whether this is a niche use case, before we consider this a fact. Can we put this on the agenda for further discussion? Christophe From: Adriano Santoni Sent: Tuesday, October 24, 2023 9:43 AM To: Christophe Bonjean ; SMIME Certificate Working Group ; Ashish Dhiman ; Martijn Katerbarg Subject: Re: [External Sender] RE: [Smcwg-public] RE: Re: Re: Re: SV certificates devoid of individual attributes Hi Christophe, frankly, it seems obvious to me that an email address is not, generally speaking, an individual attribute. Would you argue that info at example.com is a natural person's attribute? It may be so in specific cases (for example when it is of the type givenname.surname at example.com and the email service provider applies a rule that ensures proper attribution to users and disambiguation of similar names), but it certainly is not so by definition. Evidently a natural person (or more likely more than one) can have access to the mailbox at an address like info at example.com , but it is evident that such address is not specific to any particular natural person in the same sense and in the same way in which givenname and surname are attributes of a natural person. And no, no intent at all to modify the SV profile; quite the opposite: to respect its definition even in the legacy case (where among other things, the needs of niche use cases can very well be satisfied by OV certificates). Adriano Il 24/10/2023 09:25, Christophe Bonjean ha scritto: Hi Adriano, >From your proposed change, it seems that you are not considering a mailbox address as an individual (natural person) attribute? Could you provide some context on that? We should also keep in mind the initial purpose of the legacy profile. Even though the suggestion of using an OV profile for CN=email, O=Company might be sensible, we?re still fundamentally modifying the legacy SV profile. Christophe From: Smcwg-public On Behalf Of Adriano Santoni via Smcwg-public Sent: Friday, October 20, 2023 10:33 AM To: Ashish Dhiman ; SMIME Certificate Working Group ; Martijn Katerbarg Subject: Re: [Smcwg-public] [External Sender] RE: Re: Re: Re: SV certificates devoid of individual attributes Ashish, my intent would not be to prohibit anything, but rather to make two types of certificates (OV, SV) distinguishable that otherwise are not, and to make the S/MIME baseline requirements consistent with the definition of Sponsor-Validated. Furthermore, I don't understand why what I'm proposing could cause problems for those who need, for their legacy use case, S/MIME certificates that simultaneously contain Subject.organizationName AND any type of email address in the Subject.commonName (like department at example.com or ashish.dhiman at globalsign.com to quote your examples), plus of course locality and organizationIdentifier. In fact, in such use case you can very well use OV-type S/MIME certificates. Don't you? Adriano Il 20/10/2023 10:20, Ashish Dhiman ha scritto: NOTICE: Pay attention - external email - Sender is ashish.dhiman at globalsign.com Respected: CA/B ? S/MIME Forum Members. I feel the problem that we are trying to solve by prohibiting email address from CN in Legacy will only make things complex rather than solve it. During our discussion, the intent for legacy, always was to have minimum impact on existing practices and give time for wider industry to move to multipurpose or strict profile. I feel, we are defeating the whole purpose of legacy with suggested change, as I am trying to understand how; eliminating email address from CN will help us differentiate a sponsor profile from organization profile. As, Technically, people can still use department at example.com in sponsor profile as email address and also use ashish.dhiman at globalsign.com in Organization Profile as email address. On the other hand, this change will also deviate from current practices for CN use for legacy use cases Also, during implementation, we see in most of the cases; email address used in Sponsor profiles are correct. I think removing email in CN makes legacy no longer like legacy and seems to make it stricter than multi and strict where its allowed. There is also no indication that the intent for changes, will be achieved without mandatory use of Given Name and Sur Name in Legacy profile, which is again a big change considering legacy intent, and make these profiles similar to multi and strict version. Overall, this change seems to defeat its goal of supporting wider ecosystem for a while. Ashish From: Smcwg-public On Behalf Of Adriano Santoni via Smcwg-public Sent: Thursday, October 19, 2023 5:00 PM To: Martijn Katerbarg ; SMIME Certificate Working Group Subject: Re: [Smcwg-public] [External Sender] Re: Re: Re: SV certificates devoid of individual attributes I have created the pull request below. https://github.com/cabforum/smime/pull/218 Even if there exists some niche legacy uses cases, I believe it would be highly preferable to avoid allowing SV certificates that do not match the SV definition and are indistinguishable from OV certs. Besides, it appears that in such particular contexts OV certificates would still meet the need. Looking for endorsers. Adriano Il 16/10/2023 18:38, Martijn Katerbarg ha scritto: Happy to work with you on that. I do wonder what the cause and original intent behind this was. I wonder if they key lies in the Note added to section 7.1.4.2.5: ?Legacy Generation profiles MAY omit the subject:givenName, subject:surname, and subject:pseudonym attributes and include only the subject:commonName as described in Section 7.1.4.2.2(a) .? Could it be that the original intent here was that subject:givenName, subject:surname and subject:pseudonym are allowed to be left out, only if subject:commonName was included and had either the pseudonym or givenName+surname in it? I could see that as a possible legacy use case, with the intend to deprecate. I?m not sure if any CA needs that use case at current though. Regards, Martijn From: Smcwg-public on behalf of Adriano Santoni via Smcwg-public Date: Monday, 16 October 2023 at 18:09 To: smcwg-public at cabforum.org Subject: Re: [Smcwg-public] [External Sender] Re: Re: SV certificates devoid of individual attributes CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. I would suggest an amendment in order to correct this unintended result; I'm available to dratf a proposal it if there are any endorsers. Adriano Il 16/10/2023 17:17, Dimitris Zacharopoulos via Smcwg-public ha scritto: NOTICE: Pay attention - external email - Sender is 0100018b3910b1a1-5f63e11d-cb86-4599-8385-07abf817d4d1-000000 at amazonses.com I agree it's not a good thing. The SV profile was to support certificates that include attributes of individuals validated by the Enterprise RA. If we allow those to be missing, making it effectively an OV Certificate, seems like an unintended result. Best regards, _______________________________________________ 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 8477 bytes Desc: not available URL: From adriano.santoni at staff.aruba.it Tue Oct 24 08:31:12 2023 From: adriano.santoni at staff.aruba.it (Adriano Santoni) Date: Tue, 24 Oct 2023 10:31:12 +0200 Subject: [Smcwg-public] [External Sender] RE: RE: RE: Re: Re: Re: SV certificates devoid of individual attributes In-Reply-To: References: <0100018b324261c8-759958ef-6e5c-48f1-881a-a9faa732bb01-000000@email.amazonses.com> <0100018b38e3720f-4c2e834e-186a-4700-916e-63a9126dd9ec-000000@email.amazonses.com> <0100018b3910b1a1-5f63e11d-cb86-4599-8385-07abf817d4d1-000000@email.amazonses.com> <0100018b393f74f3-c92dc116-1edb-4c4e-8958-40777f6ae808-000000@email.amazonses.com> <0100018b47b2dc1f-b1efe9cd-1d0a-4f56-8237-2026830092c5-000000@email.amazonses.com> <0100018b4c375d14-06845541-1a13-4297-9111-352031db6468-000000@email.amazonses.com> Message-ID: <7803ebeb-45ea-406f-b6d4-158a605d9657@staff.aruba.it> Christophe, to facilitate discussion and understanding by everyone, could you explain in detail what worries you? What exactly is the difficulty that, in your opinion, the revision that Dimitris and I (not sure if Martijn is endorsing as well) are proposing would entail? Adriano Il 24/10/2023 10:14, Christophe Bonjean ha scritto: > > Hi Adriano, > > There?s no definition to support that a mailbox address is an > individual attribute in all cases, but as you indicated there are > circumstances where it is (i.e. If the Subscriber or the Enterprise RA > assert this is a mailbox address for an individual). I'm not convinced > that this is sufficient reason to ban it completely. > > Although the purpose might be to align with the definition, we are > changing the permitted contents of the CommonName, which is a > significant change. I also think it?s up to the wider community to > indicate whether this is a niche use case, before we consider this a fact. > > Can we put this on the agenda for further discussion? > > Christophe > > *From:*Adriano Santoni > *Sent:* Tuesday, October 24, 2023 9:43 AM > *To:* Christophe Bonjean ; SMIME > Certificate Working Group ; Ashish Dhiman > ; Martijn Katerbarg > > *Subject:* Re: [External Sender] RE: [Smcwg-public] RE: Re: Re: Re: SV > certificates devoid of individual attributes > > Hi Christophe, > > frankly, it seems obvious to me that an email address is not, > generally speaking, an individual attribute. Would you argue that > info at example.com is a natural person's attribute? It may be so in > specific cases (for example when it is of the type > givenname.surname at example.com and the email service provider applies a > rule that ensures proper attribution to users and disambiguation of > similar names), but it certainly is not so by definition. > > Evidently a natural person (or more likely more than one) can have > access to the mailbox at an address like info at example.com, but it is > evident that such address is not specific to any particular natural > person in the same sense and in the same way in which givenname and > surname are attributes of a natural person. > > And no, no intent at all to modify the SV profile; quite the opposite: > to respect its definition even in the legacy case (where among other > things, the needs of niche use cases can very well be satisfied by OV > certificates). > > Adriano > > Il 24/10/2023 09:25, Christophe Bonjean ha scritto: > > Hi Adriano, > > From your proposed change, it seems that you are not considering a > mailbox address as an individual (natural person) attribute? Could > you provide some context on that? > > We should also keep in mind the initial purpose of the legacy > profile. Even though the suggestion of using an OV profile for > CN=email, O=Company might be sensible, we?re still fundamentally > modifying the legacy SV profile. > > Christophe > > *From:*Smcwg-public > *On Behalf Of *Adriano > Santoni via Smcwg-public > *Sent:* Friday, October 20, 2023 10:33 AM > *To:* Ashish Dhiman > ; SMIME Certificate Working > Group > ; Martijn Katerbarg > > *Subject:* Re: [Smcwg-public] [External Sender] RE: Re: Re: Re: SV > certificates devoid of individual attributes > > Ashish, > > my intent would not be to prohibit anything, but rather to make > two types of certificates (OV, SV) distinguishable that otherwise > are not, and to make the S/MIME baseline requirements consistent > with the definition of Sponsor-Validated. > > Furthermore, I don't understand why what I'm proposing could cause > problems for those who need, for their legacy use case, S/MIME > certificates that simultaneously contain Subject.organizationName > AND /any type /of email address in the Subject.commonName (like > department at example.com or ashish.dhiman at globalsign.com to quote > your examples), plus of course locality and > organizationIdentifier. In fact, in such use case you can very > well use OV-type S/MIME certificates. Don't you? > > Adriano > > Il 20/10/2023 10:20, Ashish Dhiman ha scritto: > > NOTICE:Pay attention - external email - Sender is > ashish.dhiman at globalsign.com > > Respected: CA/B ? S/MIME Forum Members. > > I feel the problem that we are trying to solve by prohibiting > email address from CN in Legacy will only make things complex > rather than solve it. During our discussion, the intent for > legacy, always was to have minimum impact on existing > practices and give time for wider industry to move to > multipurpose or strict profile. I feel, we are defeating the > whole purpose of legacy with suggested change, as I am trying > to understand how; eliminating email address from CN will help > us differentiate a sponsor profile from organization profile. > As, Technically, people can still use department at example.com > in sponsor profile as email address and also use > ashish.dhiman at globalsign.com in Organization Profile as email > address. > > On the other hand, this change will also deviate from current > practices for CN use for legacy use cases Also, during > implementation, we see in most of the cases; email address > used in Sponsor profiles are correct. > > I think removing email in CN makes legacy no longer like > legacy and seems to make it stricter than multi and strict > where its allowed. There is also no indication that the intent > for changes, will be achieved without mandatory use of Given > Name and Sur Name in Legacy profile, which is again a big > change considering legacy intent, and make these profiles > similar to multi and strict version. Overall, this change > seems to defeat its goal of supporting wider ecosystem for a > while. > > Ashish > > *From:* Smcwg-public > *On Behalf Of* > Adriano Santoni via Smcwg-public > *Sent:* Thursday, October 19, 2023 5:00 PM > *To:* Martijn Katerbarg > ; SMIME Certificate > Working Group > > *Subject:* Re: [Smcwg-public] [External Sender] Re: Re: Re: SV > certificates devoid of individual attributes > > I have created the pull request below. > > https://github.com/cabforum/smime/pull/218 > > Even if there exists some niche legacy uses cases, I believe > it would be highly preferable to avoid allowing SV > certificates that do not match the SV definition and are > indistinguishable from OV certs. Besides, it appears that in > such particular contexts OV certificates would still meet the > need. > > Looking for endorsers. > > Adriano > > Il 16/10/2023 18:38, Martijn Katerbarg ha scritto: > > Happy to work with you on that. I do wonder what the cause > and original intent behind this was. > > I wonder if they key lies in the Note added to section > 7.1.4.2.5: > > ?Legacy Generation profiles MAY omit the > |subject:givenName|, |subject:surname|, and > |subject:pseudonym| attributes and include only the > |subject:commonName| as described in Section 7.1.4.2.2(a) > .? > > Could it be that the original intent here was that > subject:givenName, subject:surname and subject:pseudonym > are allowed to be left out, *only* if subject:commonName > was included *and* had either the pseudonym or > givenName+surname in it? > > > > > I could see that as a possible legacy use case, with the > intend to deprecate. I?m not sure if any CA needs that use > case at current though. > > Regards, > > Martijn > > *From:* Smcwg-public > on behalf of > Adriano Santoni via Smcwg-public > > *Date:* Monday, 16 October 2023 at 18:09 > *To:* smcwg-public at cabforum.org > > *Subject:* Re: [Smcwg-public] [External Sender] Re: Re: SV > certificates devoid of individual attributes > > CAUTION: This email originated from outside of the > organization. Do not click links or open attachments > unless you recognize the sender and know the content is safe. > > I would suggest an amendment in order to correct this > unintended result; I'm available to dratf a proposal it if > there are any endorsers. > > Adriano > > Il 16/10/2023 17:17, Dimitris Zacharopoulos via > Smcwg-public ha scritto: > > NOTICE:Pay attention - external email - Sender is > 0100018b3910b1a1-5f63e11d-cb86-4599-8385-07abf817d4d1-000000 at amazonses.com > > I agree it's not a good thing. The SV profile was to > support certificates that include attributes of > individuals validated by the Enterprise RA. If we > allow those to be missing, making it effectively an OV > Certificate, seems like an unintended result. > > Best regards, > > > > > > > _______________________________________________ > > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4620 bytes Desc: Firma crittografica S/MIME URL: From dzacharo at harica.gr Tue Oct 24 08:38:06 2023 From: dzacharo at harica.gr (Dimitris Zacharopoulos (HARICA)) Date: Tue, 24 Oct 2023 11:38:06 +0300 Subject: [Smcwg-public] [External Sender] RE: RE: Re: Re: Re: SV certificates devoid of individual attributes In-Reply-To: <0100018b60c04ab3-6686cf28-c933-422e-9676-4662c322077f-000000@email.amazonses.com> References: <0100018b324261c8-759958ef-6e5c-48f1-881a-a9faa732bb01-000000@email.amazonses.com> <0100018b38e3720f-4c2e834e-186a-4700-916e-63a9126dd9ec-000000@email.amazonses.com> <0100018b3910b1a1-5f63e11d-cb86-4599-8385-07abf817d4d1-000000@email.amazonses.com> <0100018b393f74f3-c92dc116-1edb-4c4e-8958-40777f6ae808-000000@email.amazonses.com> <0100018b47b2dc1f-b1efe9cd-1d0a-4f56-8237-2026830092c5-000000@email.amazonses.com> <0100018b4c375d14-06845541-1a13-4297-9111-352031db6468-000000@email.amazonses.com> <0100018b60c04ab3-6686cf28-c933-422e-9676-4662c322077f-000000@email.amazonses.com> Message-ID: Hi Christophe, please allow me to jump in the conversation, According to the early discussions and the intent of the Sponsored Validated profile, the SV (Enterprise RA) is only allowed to validate the identity of the individual, even for the legacy profile, and add that information in the S/MIME Certificate under the SV-Legacy profile. Your use case does not include any identity information of an individual in the final SV-legacy end-entity S/MIME Certificate. Identity information (first and last name) can be conveyed only via the specific attributes in the subject of the certificate, namely givenName, surname and commonName. If the CA chooses to use the commonName attribute to include the identity of the individual associated with an organization (sponsor), then the CA should add "John Doe" in the commonName, that's ok. However, if the CA wants to use the commonName attribute to include an email address to convey the identity information, then I believe this can be challenged because it will be very difficult to find an official name in an official identity document with the value "john.doe at example.com". With that said, I agree with Adriano that a certificate with a subject of "C=XX, O=Example Inc., CN=john.doe at example.com" does not match the expectations of the Sponsored Validation profile because the Sponsor has no identity to validate :) Best regards, Dimitris. On 24/10/2023 11:14 ?.?., Christophe Bonjean via Smcwg-public wrote: > > Hi Adriano, > > There?s no definition to support that a mailbox address is an > individual attribute in all cases, but as you indicated there are > circumstances where it is (i.e. If the Subscriber or the Enterprise RA > assert this is a mailbox address for an individual). I'm not convinced > that this is sufficient reason to ban it completely. > > Although the purpose might be to align with the definition, we are > changing the permitted contents of the CommonName, which is a > significant change. I also think it?s up to the wider community to > indicate whether this is a niche use case, before we consider this a fact. > > Can we put this on the agenda for further discussion? > > Christophe > > *From:*Adriano Santoni > *Sent:* Tuesday, October 24, 2023 9:43 AM > *To:* Christophe Bonjean ; SMIME > Certificate Working Group ; Ashish Dhiman > ; Martijn Katerbarg > > *Subject:* Re: [External Sender] RE: [Smcwg-public] RE: Re: Re: Re: SV > certificates devoid of individual attributes > > Hi Christophe, > > frankly, it seems obvious to me that an email address is not, > generally speaking, an individual attribute. Would you argue that > info at example.com is a natural person's attribute? It may be so in > specific cases (for example when it is of the type > givenname.surname at example.com and the email service provider applies a > rule that ensures proper attribution to users and disambiguation of > similar names), but it certainly is not so by definition. > > Evidently a natural person (or more likely more than one) can have > access to the mailbox at an address like info at example.com, but it is > evident that such address is not specific to any particular natural > person in the same sense and in the same way in which givenname and > surname are attributes of a natural person. > > And no, no intent at all to modify the SV profile; quite the opposite: > to respect its definition even in the legacy case (where among other > things, the needs of niche use cases can very well be satisfied by OV > certificates). > > Adriano > > Il 24/10/2023 09:25, Christophe Bonjean ha scritto: > > Hi Adriano, > > From your proposed change, it seems that you are not considering a > mailbox address as an individual (natural person) attribute? Could > you provide some context on that? > > We should also keep in mind the initial purpose of the legacy > profile. Even though the suggestion of using an OV profile for > CN=email, O=Company might be sensible, we?re still fundamentally > modifying the legacy SV profile. > > Christophe > > *From:*Smcwg-public > *On Behalf Of *Adriano > Santoni via Smcwg-public > *Sent:* Friday, October 20, 2023 10:33 AM > *To:* Ashish Dhiman > ; SMIME Certificate Working > Group > ; Martijn Katerbarg > > *Subject:* Re: [Smcwg-public] [External Sender] RE: Re: Re: Re: SV > certificates devoid of individual attributes > > Ashish, > > my intent would not be to prohibit anything, but rather to make > two types of certificates (OV, SV) distinguishable that otherwise > are not, and to make the S/MIME baseline requirements consistent > with the definition of Sponsor-Validated. > > Furthermore, I don't understand why what I'm proposing could cause > problems for those who need, for their legacy use case, S/MIME > certificates that simultaneously contain Subject.organizationName > AND /any type /of email address in the Subject.commonName (like > department at example.com or ashish.dhiman at globalsign.com to quote > your examples), plus of course locality and > organizationIdentifier. In fact, in such use case you can very > well use OV-type S/MIME certificates. Don't you? > > Adriano > > Il 20/10/2023 10:20, Ashish Dhiman ha scritto: > > NOTICE:Pay attention - external email - Sender is > ashish.dhiman at globalsign.com > > Respected: CA/B ? S/MIME Forum Members. > > I feel the problem that we are trying to solve by prohibiting > email address from CN in Legacy will only make things complex > rather than solve it. During our discussion, the intent for > legacy, always was to have minimum impact on existing > practices and give time for wider industry to move to > multipurpose or strict profile. I feel, we are defeating the > whole purpose of legacy with suggested change, as I am trying > to understand how; eliminating email address from CN will help > us differentiate a sponsor profile from organization profile. > As, Technically, people can still use department at example.com > in sponsor profile as email address and also use > ashish.dhiman at globalsign.com in Organization Profile as email > address. > > On the other hand, this change will also deviate from current > practices for CN use for legacy use cases Also, during > implementation, we see in most of the cases; email address > used in Sponsor profiles are correct. > > I think removing email in CN makes legacy no longer like > legacy and seems to make it stricter than multi and strict > where its allowed. There is also no indication that the intent > for changes, will be achieved without mandatory use of Given > Name and Sur Name in Legacy profile, which is again a big > change considering legacy intent, and make these profiles > similar to multi and strict version. Overall, this change > seems to defeat its goal of supporting wider ecosystem for a > while. > > Ashish > > *From:* Smcwg-public > *On Behalf Of* > Adriano Santoni via Smcwg-public > *Sent:* Thursday, October 19, 2023 5:00 PM > *To:* Martijn Katerbarg > ; SMIME Certificate > Working Group > > *Subject:* Re: [Smcwg-public] [External Sender] Re: Re: Re: SV > certificates devoid of individual attributes > > I have created the pull request below. > > https://github.com/cabforum/smime/pull/218 > > Even if there exists some niche legacy uses cases, I believe > it would be highly preferable to avoid allowing SV > certificates that do not match the SV definition and are > indistinguishable from OV certs. Besides, it appears that in > such particular contexts OV certificates would still meet the > need. > > Looking for endorsers. > > Adriano > > Il 16/10/2023 18:38, Martijn Katerbarg ha scritto: > > Happy to work with you on that. I do wonder what the cause > and original intent behind this was. > > I wonder if they key lies in the Note added to section > 7.1.4.2.5: > > ?Legacy Generation profiles MAY omit the > |subject:givenName|, |subject:surname|, and > |subject:pseudonym| attributes and include only the > |subject:commonName| as described in Section 7.1.4.2.2(a) > .? > > Could it be that the original intent here was that > subject:givenName, subject:surname and subject:pseudonym > are allowed to be left out, *only* if subject:commonName > was included *and* had either the pseudonym or > givenName+surname in it? > > > > > I could see that as a possible legacy use case, with the > intend to deprecate. I?m not sure if any CA needs that use > case at current though. > > Regards, > > Martijn > > *From:* Smcwg-public > on behalf of > Adriano Santoni via Smcwg-public > > *Date:* Monday, 16 October 2023 at 18:09 > *To:* smcwg-public at cabforum.org > > *Subject:* Re: [Smcwg-public] [External Sender] Re: Re: SV > certificates devoid of individual attributes > > CAUTION: This email originated from outside of the > organization. Do not click links or open attachments > unless you recognize the sender and know the content is safe. > > I would suggest an amendment in order to correct this > unintended result; I'm available to dratf a proposal it if > there are any endorsers. > > Adriano > > Il 16/10/2023 17:17, Dimitris Zacharopoulos via > Smcwg-public ha scritto: > > NOTICE:Pay attention - external email - Sender is > 0100018b3910b1a1-5f63e11d-cb86-4599-8385-07abf817d4d1-000000 at amazonses.com > > I agree it's not a good thing. The SV profile was to > support certificates that include attributes of > individuals validated by the Enterprise RA. If we > allow those to be missing, making it effectively an OV > Certificate, seems like an unintended result. > > Best regards, > > > > > > > _______________________________________________ > > 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: From christophe.bonjean at globalsign.com Tue Oct 24 09:43:00 2023 From: christophe.bonjean at globalsign.com (Christophe Bonjean) Date: Tue, 24 Oct 2023 09:43:00 +0000 Subject: [Smcwg-public] [External Sender] RE: RE: Re: Re: Re: SV certificates devoid of individual attributes In-Reply-To: References: <0100018b324261c8-759958ef-6e5c-48f1-881a-a9faa732bb01-000000@email.amazonses.com> <0100018b38e3720f-4c2e834e-186a-4700-916e-63a9126dd9ec-000000@email.amazonses.com> <0100018b3910b1a1-5f63e11d-cb86-4599-8385-07abf817d4d1-000000@email.amazonses.com> <0100018b393f74f3-c92dc116-1edb-4c4e-8958-40777f6ae808-000000@email.amazonses.com> <0100018b47b2dc1f-b1efe9cd-1d0a-4f56-8237-2026830092c5-000000@email.amazonses.com> <0100018b4c375d14-06845541-1a13-4297-9111-352031db6468-000000@email.amazonses.com> <0100018b60c04ab3-6686cf28-c933-422e-9676-4662c322077f-000000@email.amazonses.com> Message-ID: Hi Dimitris, The definition for sponsor-validated refers to individual attributes but not individual identity information at the moment. My perspective is that there are use cases where the email can be considered an individual attribute. I suggest we further discuss this on our next WG call. Christophe From: Dimitris Zacharopoulos (HARICA) Sent: Tuesday, October 24, 2023 10:38 AM To: Christophe Bonjean ; SMIME Certificate Working Group ; Adriano Santoni ; Ashish Dhiman ; Martijn Katerbarg Subject: Re: [Smcwg-public] [External Sender] RE: RE: Re: Re: Re: SV certificates devoid of individual attributes Hi Christophe, please allow me to jump in the conversation, According to the early discussions and the intent of the Sponsored Validated profile, the SV (Enterprise RA) is only allowed to validate the identity of the individual, even for the legacy profile, and add that information in the S/MIME Certificate under the SV-Legacy profile. Your use case does not include any identity information of an individual in the final SV-legacy end-entity S/MIME Certificate. Identity information (first and last name) can be conveyed only via the specific attributes in the subject of the certificate, namely givenName, surname and commonName. If the CA chooses to use the commonName attribute to include the identity of the individual associated with an organization (sponsor), then the CA should add "John Doe" in the commonName, that's ok. However, if the CA wants to use the commonName attribute to include an email address to convey the identity information, then I believe this can be challenged because it will be very difficult to find an official name in an official identity document with the value "john.doe at example.com". With that said, I agree with Adriano that a certificate with a subject of "C=XX, O=Example Inc., CN=john.doe at example.com " does not match the expectations of the Sponsored Validation profile because the Sponsor has no identity to validate :) Best regards, Dimitris. On 24/10/2023 11:14 ?.?., Christophe Bonjean via Smcwg-public wrote: Hi Adriano, There?s no definition to support that a mailbox address is an individual attribute in all cases, but as you indicated there are circumstances where it is (i.e. If the Subscriber or the Enterprise RA assert this is a mailbox address for an individual). I'm not convinced that this is sufficient reason to ban it completely. Although the purpose might be to align with the definition, we are changing the permitted contents of the CommonName, which is a significant change. I also think it?s up to the wider community to indicate whether this is a niche use case, before we consider this a fact. Can we put this on the agenda for further discussion? Christophe From: Adriano Santoni Sent: Tuesday, October 24, 2023 9:43 AM To: Christophe Bonjean ; SMIME Certificate Working Group ; Ashish Dhiman ; Martijn Katerbarg Subject: Re: [External Sender] RE: [Smcwg-public] RE: Re: Re: Re: SV certificates devoid of individual attributes Hi Christophe, frankly, it seems obvious to me that an email address is not, generally speaking, an individual attribute. Would you argue that info at example.com is a natural person's attribute? It may be so in specific cases (for example when it is of the type givenname.surname at example.com and the email service provider applies a rule that ensures proper attribution to users and disambiguation of similar names), but it certainly is not so by definition. Evidently a natural person (or more likely more than one) can have access to the mailbox at an address like info at example.com , but it is evident that such address is not specific to any particular natural person in the same sense and in the same way in which givenname and surname are attributes of a natural person. And no, no intent at all to modify the SV profile; quite the opposite: to respect its definition even in the legacy case (where among other things, the needs of niche use cases can very well be satisfied by OV certificates). Adriano Il 24/10/2023 09:25, Christophe Bonjean ha scritto: Hi Adriano, >From your proposed change, it seems that you are not considering a mailbox address as an individual (natural person) attribute? Could you provide some context on that? We should also keep in mind the initial purpose of the legacy profile. Even though the suggestion of using an OV profile for CN=email, O=Company might be sensible, we?re still fundamentally modifying the legacy SV profile. Christophe From: Smcwg-public On Behalf Of Adriano Santoni via Smcwg-public Sent: Friday, October 20, 2023 10:33 AM To: Ashish Dhiman ; SMIME Certificate Working Group ; Martijn Katerbarg Subject: Re: [Smcwg-public] [External Sender] RE: Re: Re: Re: SV certificates devoid of individual attributes Ashish, my intent would not be to prohibit anything, but rather to make two types of certificates (OV, SV) distinguishable that otherwise are not, and to make the S/MIME baseline requirements consistent with the definition of Sponsor-Validated. Furthermore, I don't understand why what I'm proposing could cause problems for those who need, for their legacy use case, S/MIME certificates that simultaneously contain Subject.organizationName AND any type of email address in the Subject.commonName (like department at example.com or ashish.dhiman at globalsign.com to quote your examples), plus of course locality and organizationIdentifier. In fact, in such use case you can very well use OV-type S/MIME certificates. Don't you? Adriano Il 20/10/2023 10:20, Ashish Dhiman ha scritto: NOTICE: Pay attention - external email - Sender is ashish.dhiman at globalsign.com Respected: CA/B ? S/MIME Forum Members. I feel the problem that we are trying to solve by prohibiting email address from CN in Legacy will only make things complex rather than solve it. During our discussion, the intent for legacy, always was to have minimum impact on existing practices and give time for wider industry to move to multipurpose or strict profile. I feel, we are defeating the whole purpose of legacy with suggested change, as I am trying to understand how; eliminating email address from CN will help us differentiate a sponsor profile from organization profile. As, Technically, people can still use department at example.com in sponsor profile as email address and also use ashish.dhiman at globalsign.com in Organization Profile as email address. On the other hand, this change will also deviate from current practices for CN use for legacy use cases Also, during implementation, we see in most of the cases; email address used in Sponsor profiles are correct. I think removing email in CN makes legacy no longer like legacy and seems to make it stricter than multi and strict where its allowed. There is also no indication that the intent for changes, will be achieved without mandatory use of Given Name and Sur Name in Legacy profile, which is again a big change considering legacy intent, and make these profiles similar to multi and strict version. Overall, this change seems to defeat its goal of supporting wider ecosystem for a while. Ashish From: Smcwg-public On Behalf Of Adriano Santoni via Smcwg-public Sent: Thursday, October 19, 2023 5:00 PM To: Martijn Katerbarg ; SMIME Certificate Working Group Subject: Re: [Smcwg-public] [External Sender] Re: Re: Re: SV certificates devoid of individual attributes I have created the pull request below. https://github.com/cabforum/smime/pull/218 Even if there exists some niche legacy uses cases, I believe it would be highly preferable to avoid allowing SV certificates that do not match the SV definition and are indistinguishable from OV certs. Besides, it appears that in such particular contexts OV certificates would still meet the need. Looking for endorsers. Adriano Il 16/10/2023 18:38, Martijn Katerbarg ha scritto: Happy to work with you on that. I do wonder what the cause and original intent behind this was. I wonder if they key lies in the Note added to section 7.1.4.2.5: ?Legacy Generation profiles MAY omit the subject:givenName, subject:surname, and subject:pseudonym attributes and include only the subject:commonName as described in Section 7.1.4.2.2(a) .? Could it be that the original intent here was that subject:givenName, subject:surname and subject:pseudonym are allowed to be left out, only if subject:commonName was included and had either the pseudonym or givenName+surname in it? I could see that as a possible legacy use case, with the intend to deprecate. I?m not sure if any CA needs that use case at current though. Regards, Martijn From: Smcwg-public on behalf of Adriano Santoni via Smcwg-public Date: Monday, 16 October 2023 at 18:09 To: smcwg-public at cabforum.org Subject: Re: [Smcwg-public] [External Sender] Re: Re: SV certificates devoid of individual attributes CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. I would suggest an amendment in order to correct this unintended result; I'm available to dratf a proposal it if there are any endorsers. Adriano Il 16/10/2023 17:17, Dimitris Zacharopoulos via Smcwg-public ha scritto: NOTICE: Pay attention - external email - Sender is 0100018b3910b1a1-5f63e11d-cb86-4599-8385-07abf817d4d1-000000 at amazonses.com I agree it's not a good thing. The SV profile was to support certificates that include attributes of individuals validated by the Enterprise RA. If we allow those to be missing, making it effectively an OV Certificate, seems like an unintended result. Best regards, _______________________________________________ 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 8477 bytes Desc: not available URL: From Stephen.Davidson at digicert.com Tue Oct 24 18:57:04 2023 From: Stephen.Davidson at digicert.com (Stephen Davidson) Date: Tue, 24 Oct 2023 18:57:04 +0000 Subject: [Smcwg-public] Approved Minutes of SMCWG September 27, 2023 In-Reply-To: <0100018ae6881c16-8ff0ce42-95c0-47e6-8f10-895a0face992-000000@email.amazonses.com> References: <0100018ae6881c16-8ff0ce42-95c0-47e6-8f10-895a0face992-000000@email.amazonses.com> Message-ID: Minutes of SMCWG September 27, 2023 These are the Approved Minutes of the Teleconference described in the subject of this message. Corrections and clarifications where needed are encouraged by reply. Attendees Abhishek Bhat - (eMudhra), Andrea Holland - (VikingCloud), Andreas Henschel - (D-TRUST), Ashish Dhiman - (GlobalSign), Ben Wilson - (Mozilla), Bilal Ashraf - (SSL.com), Cade Cairns - (Google), Clint Wilson - (Apple), Hazhar Ismail - (MSC Trustgate Sdn Bhd), Inaba Atsushi - (GlobalSign), Inigo Barreira - (Sectigo), Judith Spencer - (CertiPath), Keshava Nagaraju - (eMudhra), Li-Chun Chen - (Chunghwa Telecom), Mrugesh Chandarana - (IdenTrust), Nome Huang - (TrustAsia Technologies, Inc.), Paul van Brouwershaven - (Entrust), Pekka Lahtiharju - (Telia Company), Rebecca Kelley - (Apple), Renne Rodriguez - (Apple), Rollin Yu - (TrustAsia Technologies, Inc.), Russ Housley - (Vigil Security LLC), Scott Rea - (eMudhra), Stefan Selbitschka - (rundQuadrat), Stephen Davidson - (DigiCert), Tadahiko Ito - (SECOM Trust Systems), Thomas Zermeno - (SSL.com), Tim Crawford - (CPA Canada/WebTrust), Tsung-Min Kuo - (Chunghwa Telecom), Wendy Brown - (US Federal PKI Management Authority), Yashwanth TM - (eMudhra) 1. Roll Call The Roll Call was taken. 2. Read Antitrust Statement The statement was read concerning the antitrust policy, code of conduct, and intellectual property rights agreement. 3. Review Agenda Minutes were prepared by Stephen Davidson. 4. Approval of minutes from last teleconference The minutes were approved from the following teleconferences: . September 13 5. Discussion Russ Housley noted that the draft RFC for CAA for S/MIME was approaching conclusion and publication. Stephen Davidson said that, once the RFC was published, the SMCWG would move to introduce a ballot requiring CAA for S/MIME with a long implementation window. Russ also noted that a new RFC was underway that would replace the one referenced for otherName of type id-on-SmtpUTF8Mailbox. Stephen again noted the issues list is being actively updated at https://github.com/cabforum/smime/issues and encouraged SMCWG members to comment there. He is working on a draft SM04 ballot of further corrections which may be seen at https://github.com/srdavidson/smime/blob/Ballot-SMC04/SBR.md. The WG discussed proposed text to incorporate intermediate CAs in the definition of Extant S/MIME CA. Stephen noted an email sent to the list by Martijn Katerbarg describing that backdating of revocations was now permitted in both the Code Signing and TLS BR, but is not described in the S/MIME BR. Clint Wilson said he had no strong objection to adding this allowance, as it would not block a user from accessing old emails. Russ noted that the CS and TLS BR vary in their description of invalidityDate versus revocationDate. Scott Rea said is unknown if email software is generally aware of the invalidityDate extension but clear standards might make it more attractive. Wendy Brown said that email software UI is often not specific about "problems relating the certificate" including expiry and revocation and wondered if such a requirement should be expressed as a MAY rather than a SHOULD. Paul van Brouwershaven and Stefan Selbitschka said that email software treated time stamps loosely so the effectiveness of revocation times was reduced. Stephen asked if the WG had any sway to affect those industry standards, other than to ensure that revocation times were as accurate as possible. Stephen described proposed text in the draft SMC04 which requires "the proper stacking" of address fields (for example, only allowing streetAddress if locality or state was present). No objections were raised. Stephen described proposed text in the draft SMC04 to reference the new ETSI TS 119 411-6 in sections 8.4 and 8.6. He said he would also share it with ACAB'c, and no objections were raised. Stephen described proposed text in the draft SMC04 to clarify the keyUsage table. No objections were raised. The WG discussed the agenda for the CABF #60 meeting. Topics included Pseudonym, organisationIdentifier and jurisdiction level setting, CAA for S/MIME. Other possible topics raised included extensions showing ERA involvement, attestation of keys, and whether to adopt a table format such as recently introduced to the TLS BR in ballot SC62. Clint noted that he would like the deprecation timeline for the Legacy generation to be discussed. Ben Wilson noted that he welcomed suggestions from Certificate Issuers that might be considered for the roadmap of email client software. 6. Any Other Business None 7. Next call Next call: Thursday, October 5, 2023 at the CABF#60, see wiki for details. Adjourned -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5293 bytes Desc: not available URL: From Stephen.Davidson at digicert.com Tue Oct 24 19:36:21 2023 From: Stephen.Davidson at digicert.com (Stephen Davidson) Date: Tue, 24 Oct 2023 19:36:21 +0000 Subject: [Smcwg-public] Draft SMCWG agenda - Wednesday, October 25, 2023 Message-ID: SMCWG Agenda Draft SMCWG agenda - Wednesday, October 25, 2023 at 11:00 am Eastern Time Here is a draft agenda for the teleconference described in the subject of this message. Please review and propose changes if necessary. 1. Roll Call 2. Note well: Antitrust / Compliance Statement 3. Review Agenda 4. Approval of past minutes * F2F CABF#60 minutes still pending 5. Discussion * Note: Upcoming Ballot SMC04 on ETSI TS 119 411-6 * Note: CAA for SMIME RFC https://rfc-editor.org/rfc/rfc9495.html * Discussion of naming in Sponsor- versus Organization-validated * Possible implementation survey via CCADB * Call schedule confirmation * Note: Github issues review https://github.com/cabforum/smime/issues 6. Any other business 7. Next meeting: Wednesday, November 8, 2023 at 11:00 am Eastern Time Adjourn -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5293 bytes Desc: not available URL: From Stephen.Davidson at digicert.com Wed Oct 25 17:18:27 2023 From: Stephen.Davidson at digicert.com (Stephen Davidson) Date: Wed, 25 Oct 2023 17:18:27 +0000 Subject: [Smcwg-public] Ballot SMC04: Addition of ETSI TS 119 411-6 to audit standards - discussion period begins Message-ID: Ballot SMC04: Addition of ETSI TS 119 411-6 to audit standards Purpose of Ballot: The ballot proposes changes to the S/MIME Baseline Requirements, and in others to make corrections. The affected sections include: * Clarify the Revisions table in section 1.2.1 to more clearly differentiate the effective date (publication of the version) from additional compliance dates; and * Add ETSI TS 119 411-6 as an audit criteria in Sections 1.6.3, 8.4, and 8.6. The following motion has been proposed by Stephen Davidson of DigiCert and endorsed by Dimitris Zacharopoulos of HARICA and Paul van Brouwershaven of Entrust. - MOTION BEGINS - This ballot modifies the "Baseline Requirements for the Issuance and Management of Publicly-Trusted S/MIME Certificates" ("S/MIME Baseline Requirements") resulting in Version 1.0.2. The proposed modifications to the S/MIME Baseline Requirements may be found at https://github.com/cabforum/smime/compare/241e92cde85c25d7e0d4a5c70118ecadacd4d72b...c6916c7156a711b59f8e6790ff0ee0fedb7bd270. The SMCWG Chair or Vice-Chair is permitted to update the Relevant Dates and Version Number of the S/MIME Baseline Requirements to reflect final dates. - MOTION ENDS - This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows: Discussion (7 days) Start Time: October 25, 2023 17:00 UTC End Time: November 1, 2023 17:00 UTC -------------- next part -------------- An HTML attachment was scrubbed... URL: From Stephen.Davidson at digicert.com Fri Oct 27 19:32:54 2023 From: Stephen.Davidson at digicert.com (Stephen Davidson) Date: Fri, 27 Oct 2023 19:32:54 +0000 Subject: [Smcwg-public] November Schedule Changes for SMCWG Message-ID: Hello: Just a reminder that at the recent SMCWG teleconference, the following schedule changes were agreed: Nov 8 - Cancelled due to conflicts with IETF and PQC conference Nov 15 - Add a catchup teleconference Nov 22 - Cancelled due to US holiday You should see some calendar invite/changes coming through. Regards, Stephen -------------- next part -------------- An HTML attachment was scrubbed... URL: From infra-bot at cabforum.org Sun Oct 29 07:34:22 2023 From: infra-bot at cabforum.org (Infrastructure Bot) Date: Sun, 29 Oct 2023 07:34:22 +0000 Subject: [Smcwg-public] Weekly github digest (S/MIME Certificate Working Group) Message-ID: <0100018b7a5af224-35c28dc1-7e76-4aeb-9736-085df0d9fa95-000000@email.amazonses.com> Pull requests ------------- * cabforum/smime (+2/-0/?0) 2 pull requests submitted: - SMC04 (by srdavidson) https://github.com/cabforum/smime/pull/220 - SMC04 (by srdavidson) https://github.com/cabforum/smime/pull/219 Repositories tracked by this digest: ----------------------------------- * https://github.com/cabforum/smime -------------- next part -------------- An HTML attachment was scrubbed... URL: From Stephen.Davidson at digicert.com Mon Oct 30 18:27:42 2023 From: Stephen.Davidson at digicert.com (Stephen Davidson) Date: Mon, 30 Oct 2023 18:27:42 +0000 Subject: [Smcwg-public] Considering CAA for the S/MIME Baseline Requirements Message-ID: Hello: The S/MIME Certificate Working Group (SMCWG) of the CA/Browser Forum proposes to add a requirement for CAs issuing publicly-trusted S/MIME certificates to implement Certificate Authority Authorization (CAA) checking. Public-trust CAs have used CAA for some time when issuing TLS certificates, and the new RFC 9495 extends CAA with a new property tag for "issuemail". The benefit is that domain holders will be able to specify CAs they authorize to issue certificates on their behalf separately for TLE and for S/MIME. The current plan is to allow up to 12 months for CAs to implement CAA following publication of the amending ballot to the S/MIME Baseline Requirements. The SMCWG is now starting work on that amending ballot. We encourage both Certificate Issuers as well as PKI application software providers involved in issuing S/MIME certificates to become familiar with RFC 9495, and welcome feedback on the pending requirement and implementation timeframe. With kind regards, Stephen Davidson Chair, S/MIME Certificate Working Group -------------- next part -------------- An HTML attachment was scrubbed... URL: From Bruce.Morton at entrust.com Mon Oct 30 18:48:09 2023 From: Bruce.Morton at entrust.com (Bruce Morton) Date: Mon, 30 Oct 2023 18:48:09 +0000 Subject: [Smcwg-public] Considering CAA for the S/MIME Baseline Requirements In-Reply-To: <0100018b81d78c70-b27aa186-7bf6-4a70-8597-38ee9c179874-000000@email.amazonses.com> References: <0100018b81d78c70-b27aa186-7bf6-4a70-8597-38ee9c179874-000000@email.amazonses.com> Message-ID: Hi Stephen, I think the wrong link was provided as the link below does not show a new plan for CAA. Thanks, Bruce. From: Smcwg-public On Behalf Of Stephen Davidson via Smcwg-public Sent: Monday, October 30, 2023 2:28 PM To: smcwg-public at cabforum.org Subject: [EXTERNAL] [Smcwg-public] Considering CAA for the S/MIME Baseline Requirements Hello: The S/MIME Certificate Working Group (SMCWG) of the CA/Browser Forum proposes to add a requirement for CAs issuing publicly-trusted S/MIME certificates to implement Certificate Authority Authorization (CAA) checking. Public-trust CAs Hello: The S/MIME Certificate Working Group (SMCWG) of the CA/Browser Forum proposes to add a requirement for CAs issuing publicly-trusted S/MIME certificates to implement Certificate Authority Authorization (CAA) checking. Public-trust CAs have used CAA for some time when issuing TLS certificates, and the new RFC 9495 extends CAA with a new property tag for "issuemail". The benefit is that domain holders will be able to specify CAs they authorize to issue certificates on their behalf separately for TLE and for S/MIME. The current plan is to allow up to 12 months for CAs to implement CAA following publication of the amending ballot to the S/MIME Baseline Requirements. The SMCWG is now starting work on that amending ballot. We encourage both Certificate Issuers as well as PKI application software providers involved in issuing S/MIME certificates to become familiar with RFC 9495, and welcome feedback on the pending requirement and implementation timeframe. With kind regards, Stephen Davidson Chair, S/MIME Certificate Working Group Any email and files/attachments transmitted with it are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Stephen.Davidson at digicert.com Mon Oct 30 19:30:10 2023 From: Stephen.Davidson at digicert.com (Stephen Davidson) Date: Mon, 30 Oct 2023 19:30:10 +0000 Subject: [Smcwg-public] Considering CAA for the S/MIME Baseline Requirements In-Reply-To: References: <0100018b81d78c70-b27aa186-7bf6-4a70-8597-38ee9c179874-000000@email.amazonses.com> Message-ID: Hi Bruce - that's correct. I was linking to the current SBR for those who aren't familiar with it. We'll soon be looking at the draft CAA text (which is a WIP at https://github.com/srdavidson/smime/blob/CAA/SBR.md) Best, Stephen From: Bruce Morton Sent: Monday, October 30, 2023 3:48 PM To: Stephen Davidson ; SMIME Certificate Working Group Subject: RE: Considering CAA for the S/MIME Baseline Requirements Hi Stephen, I think the wrong link was provided as the link below does not show a new plan for CAA. Thanks, Bruce. From: Smcwg-public > On Behalf Of Stephen Davidson via Smcwg-public Sent: Monday, October 30, 2023 2:28 PM To: smcwg-public at cabforum.org Subject: [EXTERNAL] [Smcwg-public] Considering CAA for the S/MIME Baseline Requirements Hello: The S/MIME Certificate Working Group (SMCWG) of the CA/Browser Forum proposes to add a requirement for CAs issuing publicly-trusted S/MIME certificates to implement Certificate Authority Authorization (CAA) checking. Public-trust CAs Hello: The S/MIME Certificate Working Group (SMCWG) of the CA/Browser Forum proposes to add a requirement for CAs issuing publicly-trusted S/MIME certificates to implement Certificate Authority Authorization (CAA) checking. Public-trust CAs have used CAA for some time when issuing TLS certificates, and the new RFC 9495 extends CAA with a new property tag for "issuemail". The benefit is that domain holders will be able to specify CAs they authorize to issue certificates on their behalf separately for TLE and for S/MIME. The current plan is to allow up to 12 months for CAs to implement CAA following publication of the amending ballot to the S/MIME Baseline Requirements . The SMCWG is now starting work on that amending ballot. We encourage both Certificate Issuers as well as PKI application software providers involved in issuing S/MIME certificates to become familiar with RFC 9495, and welcome feedback on the pending requirement and implementation timeframe. With kind regards, Stephen Davidson Chair, S/MIME Certificate Working Group Any email and files/attachments transmitted with it are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5293 bytes Desc: not available URL: