Re: [Smcwg-public] Background for discussion of Legacy Profiles

[Ben Wilson via Smcwg-public]

Hi all,

I am currently aligned with Wendy’s and Judith’s concerns expressed on the
recent call about sunsetting the Legacy profile, but I look forward to
discussing this further in Bergamo. The Legacy profile provides greater
flexibility, and migrating to only the Multipurpose and Strict profiles may
have unforeseen consequences. While no one else has explicitly stated they
are not ready for this move, the Mozilla Root Program has integrated the
S/MIME BRs into our root store policy, necessitating support for diverse
use cases while ensuring broad compliance. We need to ensure that everyone
not involved in the S/MIME WG is prepared for such a significant move, and
we might find out about problems when it is too late to address them. For
instance, we could see compliance issues in Bugzilla from CA operators who
are currently enabled with the email trust bit, or we might receive a root
inclusion request from a CA operator unwilling or unable to restrict
issuance to only strict or multipurpose certificates.

In summary, I'd just like to understand the issues better and minimize
disruption and compliance issues down the road.

I look forward to your thoughts and suggestions.

Thanks,

Ben


On Thu, Apr 11, 2024 at 8:40 AM Stephen Davidson via Smcwg-public <
smcwg-public@cabforum.org> wrote:

> Hello all:
>
>
>
> I attach the summary that we reviewed in the SMCWG call yesterday.
>
>
>
> It highlights the differences between the Legacy generation profiles and
> the Multipurpose/Strict profiles, including links to the relevant text
> sections in the S/MIME BR.
>
>
>
>
> https://cabforum.org/posts/2024/2024-04-10-legacy-deprecation/SMCWG_20240410_Final.pdf
>
>
>
> This should facilitate review and feedback to help the SMCWG determine
> appropriate steps and timelines to migrate to the Multipurpose/Strict
> profiles.
>
>
>
> Regards, Stephen
> ___
> Smcwg-public mailing list
> Smcwg-public@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/smcwg-public
>
___
Smcwg-public mailing list
Smcwg-public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/smcwg-public

Re: [Smcwg-public] Ballot SMC06v2: Post implementation clarification and corrections

[Ben Wilson via Smcwg-public]

Mozilla votes "yes" on Ballot SMC-006v2.

On Fri, Apr 5, 2024, 7:58 AM Kateryna Aleksieieva via Smcwg-public <
smcwg-public@cabforum.org> wrote:

> Certum votes "Yes" to Ballot SMC06v2
>
> Kind regards,
>
> *Kateryna Aleksieieva*
> --
> *Od:* Smcwg-public  w imieniu
> użytkownika Stephen Davidson via Smcwg-public 
> *Wysłane:* czwartek, 4 kwietnia 2024 20:15
> *Do:* smcwg-public@cabforum.org 
> *Temat:* *** Uwaga! Mozliwy SPAM / PHISHING *** [Smcwg-public] Ballot
> SMC06v2: Post implementation clarification and corrections
>
>
> *Ballot SMC06: Post implementation clarification and corrections*
>
>
>
> *Purpose of Ballot:*
>
>
>
> The ballot proposes changes to the S/MIME Baseline Requirements to provide
> clarifications and corrections arising from the implementation of the
> S/MIME BR and initial audits.
>
>
>
> The following motion has been proposed by Stephen Davidson of DigiCert and
> endorsed by Martijn Katerbarg of Sectigo and Roman Fischer of SwissSign.
>
>
>
> *— 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.4.
>
>
>
> The proposed modifications to the S/MIME Baseline Requirements may be
> found at
> https://github.com/srdavidson/smime/compare/ed36440d7c967732aa08739b14cc29bed257a67d...246fab8b8880aa62cec95b6d055b872173d4dadf
> 
>
>
>
> 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 (9 days)
>
> Start Time: Tuesday March 26, 2024 17:00 UTC
>
> End Time: Thursday April 4, 2024 17:00 UTC
>
>
>
> Vote for approval (7 days)
>
> Start Time: Thursday April 4, 2024 17:00 UTC
>
> End Time: Thursday April 11, 2024 17:00 UTC
>
>
>
> IPR Review (30 days)
>
>
> ___
> Smcwg-public mailing list
> Smcwg-public@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/smcwg-public
>
___
Smcwg-public mailing list
Smcwg-public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/smcwg-public

Re: [Smcwg-public] Voting period begins for SMC-05: Adoption of CAA for S/MIME

[Ben Wilson via Smcwg-public]

Mozilla votes "yes" on Ballot SMC-005.

On Wed, Jan 10, 2024 at 4:32 PM Corey Bonnell via Smcwg-public <
smcwg-public@cabforum.org> wrote:

> *Ballot SMC05: Adoption of CAA for S/MIME*
>
>
>
> *Purpose of Ballot:*
>
>
>
> The ballot proposes changes to the S/MIME Baseline Requirements to
> introduce the use of Certification Authority Authorization (CAA) Processing
> for Email Addresses as defined in RFC 9495. It also includes minor
> typographic corrections.
>
>
>
> The following motion has been proposed by Corey Bonnell of DigiCert and
> endorsed by Dimitris Zacharopoulos of HARICA and Ben Wilson of Mozilla.
>
>
>
> *— MOTION BEGINS —*
>
>
>
> This ballot modifies Version 1.0.2 of the “Baseline Requirements for the
> Issuance and Management of Publicly-Trusted S/MIME Certificates” (“S/MIME
> Baseline Requirements”) resulting in Version 1.0.3.
>
>
>
> The proposed modifications to the S/MIME Baseline Requirements may be
> found at
> https://github.com/cabforum/smime/compare/5fb2a7ee94d1c5684d5f32af11572e8c10cd2f8c...1fbbdc8f908e6eba779b4ea0de1cbfd20e156c3a
> 
>
>
>
> 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: Wednesday January 3, 2024 18:00 UTC
>
> End Time: Wednesday January 10, 2024 23:30 UTC
>
>
>
> Vote for approval (7 days)
>
> Start Time: January 10, 2024 23:30 UTC
>
> End Time: January 17, 2024 23:30 UTC
>
>
>
> IPR Review (30 days)
>
>
> ___
> Smcwg-public mailing list
> Smcwg-public@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/smcwg-public
>
___
Smcwg-public mailing list
Smcwg-public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/smcwg-public

Re: [Smcwg-public] CAA for S/MIME

[Ben Wilson via Smcwg-public]

It would be great if we could coordinate with a SCWG ballot that requires
that CAA be put in section 3.2.2.8.  However, as I said on the recent call,
there might be a CA or two that has already populated section 3.2.2.8 of
their CP/CPS with something else.

On Thu, Dec 7, 2023 at 8:59 AM Stephen Davidson via Smcwg-public <
smcwg-public@cabforum.org> wrote:

> Thanks Bruce.  That section is planned to be deleted.
>
>
> https://github.com/srdavidson/smime/compare/241e92cde85c25d7e0d4a5c70118ecadacd4d72b...c8b0c9ff9fa28c2c7abeb2871aaa2d60a19842ed
>
>
>
> I can certainly move the content to 3.2.2.4 but I see that the TLS BR are
> considering gathering their the CAA information in 3.2.2.8 which may be
> confusing for CAs?
>
>
>
> The use of 4.2 would allow consistency across the two docs.
>
>
>
>
>
>
>
> *From:* Bruce Morton 
> *Sent:* Wednesday, December 6, 2023 9:09 PM
> *To:* Stephen Davidson ; SMIME Certificate
> Working Group 
> *Subject:* RE: CAA for S/MIME
>
>
>
> I think we need to fix this section:
>
>
>
> 3.2.2.4 CAA records
>
> This version of the S/MIME Baseline Requirements does not require the CA
> to check for CAA records. The CAA property tags for `issue`, `issuewild`,
> and `iodef` as specified in [RFC 8659](
> https://datatracker.ietf.org/doc/html/rfc8659) are not recognized for the
> issuance of S/MIME Certificates.
>
>
>
> I would really like to add all CAA requirements to section 3.2.2.4, since
> it is called CAA records. This would be in line with this TLS BR comment
> https://github.com/cabforum/servercert/issues/466.
>
>
>
>
>
> Thanks, Bruce.
>
>
>
> *From:* Smcwg-public  *On Behalf Of 
> *Stephen
> Davidson via Smcwg-public
> *Sent:* Wednesday, December 6, 2023 1:00 PM
> *To:* smcwg-public@cabforum.org
> *Subject:* [EXTERNAL] [Smcwg-public] CAA for S/MIME
>
>
>
> Hello:
>
>
>
> Here is an updated diff for the CAA text following our discussions today:
>
>
>
> -As suggested by Cade, to add the TTL/8hr reference consistent with the
> TLS BR.
>
> -To add the implementation dates in 2.2 and 4.2
>
>
>
>
> https://github.com/srdavidson/smime/compare/241e92cde85c25d7e0d4a5c70118ecadacd4d72b...43228a41a5cc99a3301c4066621787cde7e0f79a
>
>
>
> The plan will be to move this to ballot at the start of 2024, so I
> encourage CAs to engage with operations teams and/or software vendors on
> the suitability of the implementation dates.
>
>
>
> Best regards, Stephen
>
>
>
>
>
> *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.*
> ___
> Smcwg-public mailing list
> Smcwg-public@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/smcwg-public
>
___
Smcwg-public mailing list
Smcwg-public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/smcwg-public

Re: [Smcwg-public] VOTE FOR APPROVAL Ballot SMC04: Addition of ETSI TS 119 411-6 to audit standards

[Ben Wilson via Smcwg-public]

Mozilla votes "Yes" on Ballot SMC 004 (Addition of ETSI TS 119 411-6).

On Wed, Nov 1, 2023 at 11:07 AM Stephen Davidson via Smcwg-public <
smcwg-public@cabforum.org> wrote:

> Hello:
>
>
>
> The voting period for Ballot SMC04 has started. Votes must be cast on the
> SMCWG public list and in accordance with the Charter and By-Laws.
>
> Voting on SMC04 concludes on 08 November 2023 at 17:00 UTC.
>
>
>
> Regards, Stephen
>
>
>
>
>
> *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
>
>
>
> Vote for approval (7 days)
>
> Start Time: November 1, 2023 17:00 UTC
>
> End Time: November 8, 2023 17:00 UTC
>
>
>
>
> ___
> Smcwg-public mailing list
> Smcwg-public@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/smcwg-public
>
___
Smcwg-public mailing list
Smcwg-public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/smcwg-public

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

[Ben Wilson via Smcwg-public]

gt;
>
> 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@cabforum.org 
> 
> *Subject: *Re: [Smcwg-public] [External Sender] Re: [EXTERNAL]-Re: Fields
> for S/MIME CSRs
>
> Not necessarily: the email address can be transmitted to the CA as a
> separate datum.
>
> Indeed, I would say that this is preferable because it allows syntax
> checking on the email address without even starting to look at the CSR,
> from which in my opinion only the public key should be taken.
>
> Adriano
>
>
>
> Il 29/09/2023 21:21, Ben Wilson via Smcwg-public ha scritto:
>
> NOTICE: Pay attention - external email - Sender is
> 0100018ae263a9a7-3e84e260-b7d7-43c5-85cb-d1425682cb27-000...@amazonses.com
>
>
>
>
>
> Shouldn't at least the email address be included, and verified, of course,
> by the CA?
>
>
>
> On Fri, Sep 29, 2023, 11:35 AM Pedro FUENTES  wrote:
>
> +1
>
>
>
>
>
> Le 29 sept. 2023 à 17:52, Clint Wilson via Smcwg-public <
> smcwg-public@cabforum.org> a écrit :
>
> Hi all,
>
>
>
> In my opinion, CSRs should really be limited to conveying the public key
> and a proof of possession of the private key; the fields included therein
> *may* act as confirmatory signals for a CA, but shouldn’t be directly
> relied upon e.g. to generate a tbsCertificate. Rather, the values placed in
> fields of a tbsCertificate should originate from the CA’s validated data
> store to ensure that the only paths for data to become part of a signed
> certificate are through static configurations (e.g. signatureAlgorithm) or
> known-validated data.
>
>
>
> There’s plenty of nuance we can discuss as well, but generally speaking I
> believe it’s bad practice to rely on fields in the CSR.
>
>
>
> Cheers,
>
> -Clint
>
>
>
> On Sep 29, 2023, at 8:27 AM, Ben Wilson via Smcwg-public <
> smcwg-public@cabforum.org> wrote:
>
>
>
> All,
>
> I'm interested in gathering information from Certificate Issuers about the
> kind of information that they would like to collect/extract from the CSRs
> they receive from S/MIME certificate applicants. This information could be
> used to refine a system to generate CSRs that result in certificates
> compliant with the various profiles defined in the S/MIME BRs.
> Alternatively, what is the minimum amount of information that CAs might
> expect to obtain from CSRs? In other words, which fields should a CSR
> generator integrated with a Certificate Consumer's software support?
>
> Thanks,
>
> Ben
>
> ___
> Smcwg-public mailing list
> Smcwg-public@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/smcwg-public
>
>
>
> ___
> Smcwg-public mailing list
> Smcwg-public@cabforum.org
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cabforum.org_mailman_listinfo_smcwg-2Dpublic=DwICAg=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY=SdzPRXhti18pWLmVPVZwDOe4My0SBGtWzL3HSt02tHKsXpWQUw9YUb_QzXtxZYtw=5yodJ9UuvfVvN_CqY53dyFJyNwYRRJDEfhmuysvXrQA=
>
>
>
> ___
>
> Smcwg-public mailing list
>
> Smcwg-public@cabforum.org
>
> https://lists.cabforum.org/mailman/listinfo/smcwg-public
>
>
>
> ___
>
> Smcwg-public mailing list
>
> Smcwg-public@cabforum.org
>
> https://lists.cabforum.org/mailman/listinfo/smcwg-public
>
>
> --
> Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u
> niet de geadresseerde bent of dit bericht abusievelijk aan u is
> toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht
> te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van
> welke aard ook, die verband houdt met risico's verbonden aan het
> elektronisch verzenden van berichten.
> This message may contain information that is not intended for you. If you
> are not the addressee or if this message was sent to you by mistake, you
> are requested to inform the sender and delete the message. The State
> accepts no liability for damage of any kind resulting from the risks
> inherent in the electronic transmission of messages.
> ___
> Smcwg-public mailing list
> Smcwg-public@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/smcwg-public
>
___
Smcwg-public mailing list
Smcwg-public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/smcwg-public

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

[Ben Wilson via Smcwg-public]

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

On Fri, Sep 29, 2023 at 1:33 PM Pedro FUENTES  wrote:

> That’s an interesting point, but the same than there’s no need to consider
> the domains coming in the CSR to issue TLS certificates, I personally don’t
> see the practical need here.
>
> For example… We could have an Enterprise RA that can issue certs for any
> email address in a set of preauthorized domains and this would just make
> the content of the CSR quite irrelevant.
>
> In our case, we rely on other security methods (e.g. authentication
> credentials to the certificate management system) to link the certificate
> request attributes, the domain validation method and the public key in the
> CSR. We just think is better to rely on the verified information and not on
> whatever the CSR had.
>
> Le 29 sept. 2023 à 21:21, Ben Wilson  a écrit :
>
> 
> Shouldn't at least the email address be included, and verified, of course,
> by the CA?
>
> On Fri, Sep 29, 2023, 11:35 AM Pedro FUENTES  wrote:
>
>> +1
>>
>>
>> Le 29 sept. 2023 à 17:52, Clint Wilson via Smcwg-public <
>> smcwg-public@cabforum.org> a écrit :
>>
>> Hi all,
>>
>> In my opinion, CSRs should really be limited to conveying the public key
>> and a proof of possession of the private key; the fields included therein
>> *may* act as confirmatory signals for a CA, but shouldn’t be directly
>> relied upon e.g. to generate a tbsCertificate. Rather, the values placed in
>> fields of a tbsCertificate should originate from the CA’s validated data
>> store to ensure that the only paths for data to become part of a signed
>> certificate are through static configurations (e.g. signatureAlgorithm) or
>> known-validated data.
>>
>> There’s plenty of nuance we can discuss as well, but generally speaking I
>> believe it’s bad practice to rely on fields in the CSR.
>>
>> Cheers,
>> -Clint
>>
>> On Sep 29, 2023, at 8:27 AM, Ben Wilson via Smcwg-public <
>> smcwg-public@cabforum.org> wrote:
>>
>> All,
>> I'm interested in gathering information from Certificate Issuers about
>> the kind of information that they would like to collect/extract from the
>> CSRs they receive from S/MIME certificate applicants. This information
>> could be used to refine a system to generate CSRs that result in
>> certificates compliant with the various profiles defined in the S/MIME BRs.
>> Alternatively, what is the minimum amount of information that CAs might
>> expect to obtain from CSRs? In other words, which fields should a CSR
>> generator integrated with a Certificate Consumer's software support?
>> Thanks,
>> Ben
>> ___
>> Smcwg-public mailing list
>> Smcwg-public@cabforum.org
>> https://lists.cabforum.org/mailman/listinfo/smcwg-public
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cabforum.org_mailman_listinfo_smcwg-2Dpublic=DwMFaQ=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=AFTYu1HAQdkStwzgxyDbKOLyDwTHEezL5yeqoxeZ0fc=3Ai2uFDmuPvkjzx8-NXCPUEmAIzjkD-8sGOWakiphpuCLfulDVnTYuieselnddbL=DlmLTfjyPj2kGhM6d66NyUTRj15XswMU-gv6MKDY5F8=>
>>
>>
>> ___
>> Smcwg-public mailing list
>> Smcwg-public@cabforum.org
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cabforum.org_mailman_listinfo_smcwg-2Dpublic=DwICAg=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY=SdzPRXhti18pWLmVPVZwDOe4My0SBGtWzL3HSt02tHKsXpWQUw9YUb_QzXtxZYtw=5yodJ9UuvfVvN_CqY53dyFJyNwYRRJDEfhmuysvXrQA=
>>
>>
___
Smcwg-public mailing list
Smcwg-public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/smcwg-public

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

[Ben Wilson via Smcwg-public]

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@cabforum.org> a écrit :
>
> Hi all,
>
> In my opinion, CSRs should really be limited to conveying the public key
> and a proof of possession of the private key; the fields included therein
> *may* act as confirmatory signals for a CA, but shouldn’t be directly
> relied upon e.g. to generate a tbsCertificate. Rather, the values placed in
> fields of a tbsCertificate should originate from the CA’s validated data
> store to ensure that the only paths for data to become part of a signed
> certificate are through static configurations (e.g. signatureAlgorithm) or
> known-validated data.
>
> There’s plenty of nuance we can discuss as well, but generally speaking I
> believe it’s bad practice to rely on fields in the CSR.
>
> Cheers,
> -Clint
>
> On Sep 29, 2023, at 8:27 AM, Ben Wilson via Smcwg-public <
> smcwg-public@cabforum.org> wrote:
>
> All,
> I'm interested in gathering information from Certificate Issuers about the
> kind of information that they would like to collect/extract from the CSRs
> they receive from S/MIME certificate applicants. This information could be
> used to refine a system to generate CSRs that result in certificates
> compliant with the various profiles defined in the S/MIME BRs.
> Alternatively, what is the minimum amount of information that CAs might
> expect to obtain from CSRs? In other words, which fields should a CSR
> generator integrated with a Certificate Consumer's software support?
> Thanks,
> Ben
> ___
> Smcwg-public mailing list
> Smcwg-public@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/smcwg-public
>
>
> ___
> Smcwg-public mailing list
> Smcwg-public@cabforum.org
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cabforum.org_mailman_listinfo_smcwg-2Dpublic=DwICAg=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY=SdzPRXhti18pWLmVPVZwDOe4My0SBGtWzL3HSt02tHKsXpWQUw9YUb_QzXtxZYtw=5yodJ9UuvfVvN_CqY53dyFJyNwYRRJDEfhmuysvXrQA=
>
>
___
Smcwg-public mailing list
Smcwg-public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/smcwg-public

[Smcwg-public] Fields for S/MIME CSRs

[Ben Wilson via Smcwg-public]

All,
I'm interested in gathering information from Certificate Issuers about the
kind of information that they would like to collect/extract from the CSRs
they receive from S/MIME certificate applicants. This information could be
used to refine a system to generate CSRs that result in certificates
compliant with the various profiles defined in the S/MIME BRs.
Alternatively, what is the minimum amount of information that CAs might
expect to obtain from CSRs? In other words, which fields should a CSR
generator integrated with a Certificate Consumer's software support?
Thanks,
Ben
___
Smcwg-public mailing list
Smcwg-public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/smcwg-public

Re: [Smcwg-public] Validation of Information for Name-Constrained SubCAs

[Ben Wilson via Smcwg-public]

Thanks!  The reason I asked -- I'm finalizing the Mozilla Root Store Policy
v. 2.9, and I'm thinking of referencing "3.2.2" as a way to broadly cover
the validation of information that might go in a name-constrained sub CA.
Thanks again,
Ben

On Tue, Aug 8, 2023 at 2:17 PM Stephen Davidson <
stephen.david...@digicert.com> wrote:

> Hi Ben:
>
>
> The reference to Section 3.2.2.3 goes with the "or has been authorized by
> the domain registrant to act on the registrant's behalf" part only.  The
> typical verification of the domain under active control of the registrant
> would be done via Section 3.2.2.1.
>
>
>
> A possible clarification might be phrased as:
>
>
>
> "The CA SHALL confirm that the Applicant has registered the FQDN contained
> in the rfc822Name* in line with the verification practices of Section
> 3.2.2.1, *or has been authorized by the domain registrant to act on the
> registrant’s behalf in line with the verification practices of Section
> 3.2.2.3."
>
>
>
> Best, Stephen
>
>
>
>
>
> *From:* Smcwg-public  *On Behalf Of *Ben
> Wilson via Smcwg-public
> *Sent:* Tuesday, August 8, 2023 4:56 PM
> *To:* SMIME Certificate Working Group 
> *Subject:* [Smcwg-public] Validation of Information for Name-Constrained
> SubCAs
>
>
>
> Does anyone recall offhand why section 7.1.5 doesn't also refer to section
> 3.2.2.1?
>
>
>
> Section 7.1.5 says, "The CA SHALL confirm that the Applicant has
> registered the FQDN contained in the rfc822Name or has authorized by the
> domain registrant to act on the registrant’s behalf in line with the
> verification practices of Section 3.2.2.3."   Section 3.2.2.3 is
> "Validating applicant as operator of associated mail server(s)", and
> section 3.2.2.1 is "Validating authority over mailbox via domain."  Was
> there a concern that 3.2.2.1 was too broad and that validation had to be
> done pursuant to section 3.2.2.3?  And what about section 3.2.2.2
> (validating control over mailbox via email).
>
>
>
> Thanks,
>
>
>
> Ben
>
___
Smcwg-public mailing list
Smcwg-public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/smcwg-public

[Smcwg-public] Validation of Information for Name-Constrained SubCAs

[Ben Wilson via Smcwg-public]

Does anyone recall offhand why section 7.1.5 doesn't also refer to section
3.2.2.1?

Section 7.1.5 says, "The CA SHALL confirm that the Applicant has registered
the FQDN contained in the rfc822Name or has authorized by the domain
registrant to act on the registrant’s behalf in line with the verification
practices of Section 3.2.2.3."   Section 3.2.2.3 is "Validating applicant
as operator of associated mail server(s)", and section 3.2.2.1 is "Validating
authority over mailbox via domain."  Was there a concern that 3.2.2.1 was
too broad and that validation had to be done pursuant to section 3.2.2.3?
And what about section 3.2.2.2 (validating control over mailbox via email).

Thanks,

Ben
___
Smcwg-public mailing list
Smcwg-public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/smcwg-public

Re: [Smcwg-public] FW: MRSP 2.9: S/MIME BRs Transition Timeline

[Ben Wilson via Smcwg-public]

I have posted this on our Mozilla CA wiki page for additional guidance
during this S/MIME BRs transition -
https://wiki.mozilla.org/CA/Transition_SMIME_BRs#Audit_Migration_Plan.
Ben

On Tue, Jun 20, 2023 at 6:21 PM Stephen Davidson via Smcwg-public <
smcwg-public@cabforum.org> wrote:

> FYI, for thoroughness:  MDSP announcement re S/MIME BR.
>
> Regards, Stephen
>
>
>
>
>
>
>
> *From:* dev-security-pol...@mozilla.org  *On
> Behalf Of *Ben Wilson
> *Sent:* Friday, June 16, 2023 1:37 PM
> *To:* dev-secur...@mozilla.org 
> *Subject:* MRSP 2.9: S/MIME BRs Transition Timeline
>
>
>
> Greetings,
>
> Our proposal for a migration plan towards having Certification Authorities
> (CAs) follow the CA/Browser Forum’s Baseline Requirements for S/MIME
> Certificates (S/MIME BRs) is as follows, keeping in mind that the Effective
> Date for version 1.0.0 of the S/MIME BRs is September 1, 2023, and assuming
> that ETSI and WebTrust audit criteria are in place for S/MIME BR audits by
> September 1, 2023.
>
> Any root CA certificate being considered for inclusion after September 1,
> 2023, must be audited according to the S/MIME BRs if the email trust bit is
> to be enabled, and the CA operator’s CP or CPS must state that they follow
> the current version of the S/MIME BRs. Note that the CA operator’s first
> S/MIME BR audit may be a Point-in-Time audit if the audit period will be
> less than 60 days, and the audit statement may list non-compliances to be
> resolved within the next annual audit period.
>
> CA root certificates and subordinate CA certificates that are technically
> capable of issuing S/MIME certificates that chain up (either directly or
> transitively) to a root certificate that has the email (S/MIME) trust bit
> enabled in Mozilla's CA Certificate Program shall be audited with a
> Period-of-Time audit according to the S/MIME BRs between September 1, 2023,
> and August 31, 2024, and annually thereafter. For CA operators to maintain
> their current annual audit cycles, the new S/MIME BR audit should be
> provided along with the other audits that the CA operator provides annually.
>
>- The audit period start date for the first S/MIME BR audit will be
>September 1, 2023, or earlier.
>
>
>- At the CA operator’s option, the first S/MIME BR audit may cover the
>   entire audit period.
>   - The initial audit period start date for the first S/MIME BR audit
>   cannot be before the effective date of a CA operator’s CP or CPS that
>   confirms the CA operator’s compliance with the current version of the
>   S/MIME BRs.
>
>
>- If the CA operator’s existing regular audit period for other audit
>types ends after October 30, 2023, then we will expect to receive an S/MIME
>BR audit that covers September 1, 2023, through the end of that audit
>period (i.e. a Period-of-Time audit).
>
>
>- If the CA operator’s first S/MIME BR audit period would be less than
>   60 days (e.g. audit period being September 1, 2023, to October 30, 
> 2023),
>   then a Point-in-Time audit may be performed.
>
>
>- The first S/MIME BR audit for each CA root certificate and
>subordinate CA certificate may include a reasonable list of non-compliances
>that the CA operator (or subordinate CA operator) is not yet in compliance
>with.
>
>
>- Only one Incident Bug needs to be filed containing the list of the
>   non-compliances in a CA operator’s first S/MIME BR audit.
>
>
>- Submission of the second S/MIME BR audit report is expected to
>confirm that the issues that were listed in the first S/MIME BR audit
>report have been resolved.
>
> We look forward to your constructive feedback on the proposed transition
> timeline.
>
>
>
> Regards,
>
>
>
> Ben and Kathleen
>
> --
> You received this message because you are subscribed to the Google Groups "
> dev-security-pol...@mozilla.org" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to dev-security-policy+unsubscr...@mozilla.org.
> To view this discussion on the web visit
> https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtabGSZqHeAF1BkaepgYXh73-c12%3DrxfChiUfPcC10TaH0Q%40mail.gmail.com
> 
> .
> ___
> Smcwg-public mailing list
> Smcwg-public@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/smcwg-public
>
___
Smcwg-public mailing list
Smcwg-public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/smcwg-public

[Smcwg-public] Scope of S/MIME BRs and No EKU in an S/MIME Certificate

[Ben Wilson via Smcwg-public]

All,
For TLS Certificates, I think it was discovered that they would still work
if there was no EKU in them (or maybe that was just the chaining down from
Intermediate CA certificates).  Anyway, I have commented in a discussion on
the Mozilla Dev-Security-Policy list

about the scope of the Mozilla Root Store Policy as it applies to SMIME
certificates. Presence of the anyEKU EKU should bring them in scope of
Mozilla policy, but what about end entity certificates that have no EKU?
Does anyone want to comment on that thread in MDSP?
Thanks,
Ben
___
Smcwg-public mailing list
Smcwg-public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/smcwg-public

[Smcwg-public] Mozilla Wiki Page for S/MIME BR Transition Issues

[Ben Wilson via Smcwg-public]

All,

I have created a wiki page (https://wiki.mozilla.org/CA/Transition_SMIME_BRs)
to address miscellaneous issues that might arise for CAs in their
transition toward compliance with the CA/Browser Forum’s Baseline
Requirements for S/MIME Certificates (S/MIME BRs). (The wiki page is for
items that are not directly explained in the upcoming version 2.9 of the
Mozilla Root Store Policy.)

The first issue addressed in the wiki page relates to the re-issuance of
existing intermediate CAs used for issuing S/MIME certificates. Based on
language provided by Corey Bonnell, the wiki page explains how Mozilla
expects S/MIME CA re-issuance to occur.

We may add explanations about other items of concern to the wiki page in
the future, and if so, I’ll advise you accordingly.

Thanks,

Ben
___
Smcwg-public mailing list
Smcwg-public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/smcwg-public