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

[Clint Wilson via Smcwg-public]

Hi,

I agree with your summary, Ben, but am struggling with the “how” and the “when”.

I don’t know if I’m alone in this, but it would be helpful to me to have the 
concerns that have been raised also outlined in text somewhere (ideally with 
details and data and all that good stuff). To be honest, at this point I’m not 
entirely sure which concerns were addressed as part of the discussion on recent 
calls, which concerns are outstanding, what the proposed remediation(s) or 
resolution(s) might be from both those who share the concerns and those who 
don’t, what questions related to individual concerns remain unanswered, what 
data exists to give any indication regarding the likely overall impact for each 
concern, or really what the path forward looks like.

Apple had originally planned to restrict S/MIME validity periods to 2 years 
(something Gmail has done for a long time, aiui). Instead, that limit was 
increased to 3 years in 2021 based on an understanding from CAs that 
substantive efforts would be made to ensure the future deprecation of this 
longer validity period and a _very_ clear indication that deprecation of the 
Legacy profile was part of this. In the interim 2.5 years, many CAs *have* 
honored those commitments and successfully established systems, processes, 
communication channels, and automation capabilities reinforcing that 
future-facing outlook. On the other hand, in the interim 2.5 years, I have 
*not* seen topics raised by CAs related to the purported negative impact of 
deprecating the Legacy profile except recently and in direct response to 
Stephen's oft-repeated and impressively diligent inquiries regarding the topic. 
Even then, I have not seen problems defined in sufficient detail to allow for 
ecosystem-level solutions to be proposed, designed, or iterated upon.

As in 2021, so today: I am committed to trying to solve these issues, but more: 
to understand and to incorporate that understanding in driving a balanced 
approach to iterative improvement to the SBRs. However, the seemingly 
unchanging status quo related to attempts to discuss and establish timelines 
for reducing S/MIME certificate validity periods is not encouraging confidence 
in this approach.

Disruption is never the goal, but it *is* often an inevitability. In the same 
vein, avoiding disruption is also not the goal; an expectation that disruption 
be completely avoided is no different than a moratorium on future changes to 
the SBRs. Rather, at least in my mind, it’s the level of disruption that we 
should be focused on reducing.

Also, just to repeat again one point: establishing a deprecation date for the 
Legacy profile is likely the _only_ way we actually can ensure that those not 
involved in the S/MIME WG are prepared (or even aware of the need *to* prepare) 
for a shift away from the Legacy profile. If there’s not a target, no one’s 
gonna be aiming anything.

Thanks,
-Clint


> On May 9, 2024, at 2:27 PM, Ben Wilson via Smcwg-public 
>  wrote:
> 
> 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 
> mailto: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, 

Re: [Smcwg-public] [External] Draft proposal to add eIDAS QES as vetting evidence for individual

[Clint Wilson via Smcwg-public]

Hi Judith,

As I understand it, the proposed change is purely additive. That is, currently 
there are no approved frameworks in the SBRs meaning that there is no way for a 
compliant CA to rely upon a digital signature as evidence for the collection of 
Individual identity attributes (or any other purpose, I believe, but haven’t 
checked outside of Section 3.2.4.1 as closely). From my reading, this change 
doesn’t eliminate the ability for those not in the EU to trust existing digital 
signatures as evidence as no such ability exists today. Rather, this change 
would only add the ability to rely on digital signatures created by a subset of 
eIDAS Electronic Qualified Signature Certificates. While that is still limited 
in scope, as you indicate, it also doesn’t remove anything already allowed by 
the SBRs.

Can you help me understand better where you see the current SBRs as allowing 
CAs to rely upon digital signatures in the context of 3.2.4.1 today?

Thank you!
-Clint

> On Apr 25, 2024, at 7:20 AM, Judith Spencer via Smcwg-public 
>  wrote:
> 
> Stephen
> My primary concern with the proposed change is that once it finds it’s way 
> into the BR, anyone not in the EU will be eliminated from trusting existing 
> digital signatures as evidence.  For example, here in the U.S., the U.S. 
> Government has an extremely robust digital credential based on a full 
> background check that is independently assessed and accompanied by reams of 
> documentation, regulation and policy.  Over 7 million individuals hold these 
> credentials.  But by this policy, signatures from this community would not be 
> sufficient as evidence.  The CertiPath community, comprised of major 
> Aerospace Corporations, would likewise be eliminated.  While we don’t employ 
> the same level of background checks in our identity proofing, it is certainly 
> based on sound practice and audited annually under WebTrust for CA, which may 
> not be a “national scheme” but is certainly a robust review process widely 
> recognized in the U.S. and Canada.  
> Unless you are prepared to identify schemes that cover all other regions of 
> the world, I believe it is too early to make this change.  As a compromise, I 
> suggest you could identify eIDAS as the qualifying scheme for Europe and 
> remain silent on the rest of the world.  I recommend you revise the opening 
> as follows:
> “If a digital signature is to be used as evidence in the European Union, the 
> CA or RA SHALL only rely upon the following certificate type:”
> Once sufficient assessment has taken place to include all participating 
> regions, the language could be further modified as you suggest.  
> Judy
>  
> Judith Spencer | PMA Chair | CertiPath, Inc.
> 1900 Reston Metro Plaza, Suite 303, Reston, VA 20190
> PH +1.301.974.4227
> Email judith.spen...@certipath.com 
>  
> From: Smcwg-public  On Behalf Of Stephen 
> Davidson via Smcwg-public
> Sent: Wednesday, April 24, 2024 8:06 PM
> To: smcwg-public@cabforum.org
> Subject: [External] [Smcwg-public] Draft proposal to add eIDAS QES as vetting 
> evidence for individual
>  
>  
> Hello all:
>  
> As discussed today, here is draft language for consideration to allow CAs to 
> rely upon signatures created with eIDAS Qualified certificates as evidence 
> supporting validation of individual identity.
> 
> https://github.com/srdavidson/QES-SMIME-BR/blob/master/QES-proposal.md
>  
> I’d be grateful for feedback on this language.
> Best, Stephen
>  
>  
> ___
> Smcwg-public mailing list
> Smcwg-public@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/smcwg-public



smime.p7s
Description: S/MIME cryptographic signature
___
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

[Clint Wilson via Smcwg-public]

Apple votes YES on Ballot SMC06v2.

> On Apr 4, 2024, at 11:15 AM, Stephen Davidson via Smcwg-public 
>  wrote:
> 
> 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 
> athttps://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



smime.p7s
Description: S/MIME cryptographic signature
___
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

[Clint Wilson via Smcwg-public]

Apple votes YES on Ballot SMC-05.

> On Jan 10, 2024, at 3:32 PM, Corey Bonnell via Smcwg-public 
>  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



smime.p7s
Description: S/MIME cryptographic signature
___
Smcwg-public mailing list
Smcwg-public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/smcwg-public

Re: [Smcwg-public] Certificate Template Information extension and SBR allowance

[Clint Wilson via Smcwg-public]

While I think I agree with the intent of Tim’s statement (especially in the 
context of this discussion and its applicability thereto), taken literally I 
believe it is stating something with broader impact than intended. 
What I mean is that it’s important to carry the complete context of an OID 
over, including the requirements and/or prerequisites outlined for the use of 
an OID (to the extent specified or stipulated by the governing SDO). The 
“right” exists, but so to do obligations coinciding with the use of many (all?) 
OIDs. I believe everyone here’s suitably aware of this, but just wanted to 
state it explicitly so that too much nuance isn’t lost with any potential 
changes made to the text.

Cheers,
-Clint

> On Jan 16, 2024, at 11:27 AM, Martijn Katerbarg via Smcwg-public 
>  wrote:
> 
> > Absolutely. Any OID that comes from a Standards Development Organization is 
> > intended for use by other organizations, and everyone has the “right” to 
> > use them.
> 
>  
> 
> I’d like to be able to read it this way, but I am concerned that the current 
> language is too limiting in this regard.
> 
> Tim, since you also mentioned not liking the language, I’ll see if I can come 
> up with an alternative to make this clear, and also make the implied 
> allowance a stated fact.
> 
>  
> 
> Regards,
> 
> Martijn
> 
> 
> From: Tim Hollebeek 
> Sent: Wednesday, January 10, 2024 10:58:58 pm
> To: Dimitris Zacharopoulos ; SMIME Certificate Working 
> Group 
> Cc: Martijn Katerbarg 
> Subject: RE: [Smcwg-public] Certificate Template Information extension and 
> SBR allowance
> 
> Absolutely.  Any OID that comes from a Standards Development Organization is 
> intended for use by other organizations, and everyone has the “right” to use 
> them.
>  
> -Tim
>  
> From: Dimitris Zacharopoulos  
> Sent: Wednesday, January 10, 2024 12:48 PM
> To: Tim Hollebeek ; SMIME Certificate Working 
> Group 
> Cc: Martijn Katerbarg 
> Subject: Re: [Smcwg-public] Certificate Template Information extension and 
> SBR allowance
>  
> I also believe that any publicly supported and documented X.509 extension 
> (e.g. defined by IETF or ITU-T) are allowed for use by CAs, as long as they 
> are documented in the CA's CPS. 
> 
> Is there anything that prevents it in the current CA/B Forum documents? 
> 
> 
> Thanks,
> DZ.
> 
> Jan 10, 2024 20:38:19 Tim Hollebeek via Smcwg-public 
> mailto:smcwg-public@cabforum.org>>:
> 
> You don’t need a contract to have a right to use someone else’s extension.
> I would say that if Microsoft has public documentation that says or implies 
> that the extension can and should be used by other organizations, then other 
> organizations “have the right” to use that extension.
> That said, I have never liked this language, which comes from the TLS BRs.  I 
> would support making it more clear as to what is and isn’t allowed, and even 
> maybe clarifying what problem is being solved with these requirements.
> -Tim
> From: Smcwg-public  > On Behalf Of Martijn Katerbarg 
> via Smcwg-public
> Sent: Wednesday, January 10, 2024 5:54 AM
> To: SMIME Certificate Working Group  >
> Subject: [Smcwg-public] Certificate Template Information extension and SBR 
> allowance
> Hi all,
> There’s been a request within the S/MIME working group to bring forward 
> issues that have arisen since the adoption of the SBRs. While we’ve not seen 
> a whole lot of issues, we believe we may have discovered one now.
> We offer support for Windows’s own auto-enrollment features. In the past we 
> used to include the “Certificate Template Information” extension (OID 
> 1.3.6.1.4.1.311.21.7) for this purpose. Since we started issuing SBR 
> compliant certificates prior to September 1st, we removed support for this 
> extension on publicly trusted S/MIME certificates.
> As we now have noticed, this has led to a partial breakdown of the 
> auto-enrollment system. From what we understand, the auto-enrollment 
> mechanism is specifically looking for this extension in certificates, if a 
> certificate for a particular required Certificate Template (as specified 
> through AD) is not found, auto-enrollment will “do its job”, and request a 
> new certificate. This can lead to multiple new certificates being installed 
> in a single day, all because the extension is missing.
> We’ve investigated bringing back support for the extension, and are led to 
> the conclusion that no, this extension would not be allowed per the current 
> language. A breakdown:
> Section 7.1.2.4 
> (https://github.com/cabforum/smime/blob/main/SBR.md#7124-all-certificates 
> 
>  ) states:
> “All fields and extensions SHALL be 

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

[Clint Wilson via Smcwg-public]

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@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/smcwg-public



smime.p7s
Description: S/MIME cryptographic signature
___
Smcwg-public mailing list
Smcwg-public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/smcwg-public

Re: [Smcwg-public] CommonNames, Pseudonyms, GivenNames and Surnames

[Clint Wilson via Smcwg-public]

Hi Rob,

I think minimally filing an issue in https://github.com/cabforum/smime/issues 
would be a good thing to do to track this potential conflict.
FWIW, I also think the issue identified is indeed an issue (though probably not 
major) and your proposed updates seem reasonable to me as well.

Cheers,
-Clint

> On Jul 13, 2023, at 6:52 AM, Robert Lee via Smcwg-public 
>  wrote:
> 
> Dear all,
>  
> I’m emailing because I think some further clarification may be needed in 
> section 7.1.4.2.2(a) around commonNames as Personal Names or Pseudonyms 
> (capital ‘P’ based on SMC03 changes).
>  
> What I think is needed is to align some of the uses of commonNames with the 
> existing rules around if subject:pseudonym is present then 
> subject:givenName/subject:surname SHALL NOT be present and the vice versa 
> rule.  My understanding/assumption is that the pseudonym/givenName/surname 
> rules are in place to make an SMIME certificate a Pseudonym cert or a 
> Personal Name cert and not to be both at the same time (especially as putting 
> one’s name into the cert would dramatically reduce any privacy afforded by 
> using a Pseudonym).
>  
> However, the options for commonName in sponsor and individual validated 
> certificates don't entirely work with the above as currently you _could_ have 
> a subject:pseudonym and then put your Personal Name in the commonName which 
> doesn't track with my understanding/assumption of what the 
> pseudonym/givenName/surname rules are supposed to achieve.
>  
> I don’t think it’s a difficult thing to fix though.  Adding the following 
> lines to 7.1.4.2.2(a) should close this hole effectively enough:
>  
> “If the subject:commonName contains a Pseudonym, then the subject:givenName 
> and/or subject:surname attributes SHALL NOT be present.”
>  
> “If the subject:commonName contains a Personal Name, then the 
> subject:pseudonym attribute SHALL NOT be present.”
>  
> If people broadly agree with my suggestion then I’m happy to make a PR into 
> the BRs or somewhere else if, like SMC03, there’ll be a branch collecting 
> changes in someone’s fork of the document.
>  
> Best Regards,
> Rob
>  
> Dr. Robert Lee MEng PhD
> Senior Software Engineer with Cryptography SME
> www.globalsign.co.uk |www.globalsign.eu 
> 
>  
> ___
> Smcwg-public mailing list
> Smcwg-public@cabforum.org 
> https://lists.cabforum.org/mailman/listinfo/smcwg-public



smime.p7s
Description: S/MIME cryptographic signature
___
Smcwg-public mailing list
Smcwg-public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/smcwg-public