From selbitschka at rundquadrat.at Mon Mar 1 10:18:46 2021 From: selbitschka at rundquadrat.at (Stefan Selbitschka) Date: Mon, 1 Mar 2021 11:18:46 +0100 Subject: [Smcwg-public] Methods for email verification In-Reply-To: <01000177d13764fd-df4658ca-11e2-43b7-b73b-224111fb41ad-000000@email.amazonses.com> References: <01000177b23abbfa-b645ad5e-7f68-44ae-9924-b7bb8349bff2-000000@email.amazonses.com> <01000177b5d9a0a0-654ef877-ed50-4b4a-b5c9-532ed2db2dc1-000000@email.amazonses.com> <01000177b5f592f6-bb681f57-da13-4f29-be77-044595f39b01-000000@email.amazonses.com> <01000177c417d8b2-35f1b297-a888-4040-a41e-20c95feb71aa-000000@email.amazonses.com> <01000177cfcac1f0-7d3454b2-6e9a-4008-8340-7936ca3eea7a-000000@email.amazonses.com> <01000177d13764fd-df4658ca-11e2-43b7-b73b-224111fb41ad-000000@email.amazonses.com> Message-ID: <8c00a2d0-7641-99ca-7f8e-2d426bfa7759@rundquadrat.at> Sorry for my late feedback but I was busy last week. Following your discussion about the reuse of validation to issue multiple certificate the question is how long should a validation last? Especially if we talk about validation via email it could be problematic if the validation last more then a day, since we cannot control the providers mailbox handling, reuse of email addresses etc. Just consider the case where I'm requesting a certificate for a email distribution group and get kicked out after some days. I'm should not be able to request another certificate without a prove of possession of the mailbox. To minimize a possible attack surface I would prefer a validation for every issuance. Maybe it make sense to distinguish between a complete validation and a simple proof of possession (may by sending a otp token or whatever), if a validation is getting to complex to do it more often. Since I'm the newbee here my apologies if I missed some prior discussion about that topic which led to that conclusion. regards Stefan On 2/24/21 12:26 AM, Stephen Davidson via Smcwg-public wrote: > Thanks for the feedback. > > ? > > Yes I wrote that section intending a mailbox re-verification at each > cert issuance. > > ? > > But I appreciate the arguments in favor of having a re-use period for > that first verification, particularly in cases where certs may be > periodically reissued, or when multiple certs are to be issued at the > same time (as in the case of split signing and encryption certs). > > ? > > I will adapt that proposed text. > > ? > > As you may have noticed in Doug?s email, we have now made the draft > SMIME BR public at https://github.com/srdavidson/smime/tree/PreSBR > in a ?PreSBR? branch, > which you can view or Watch.? It?s in active development now and this > will be the working version of the SBR; it will be pulled into the > cabf-smime repository later when the dust settles. > > ? > > Best regards, Stephen > > ? > > ? > > *From:* Smcwg-public *On Behalf Of > *Doug Beattie via Smcwg-public > *Sent:* Tuesday, February 23, 2021 12:48 PM > *To:* Tim Hollebeek ; Dimitris Zacharopoulos > (HARICA) ; SMIME Certificate Working Group > ; Wendy Brown - QT3LB-C > *Subject:* Re: [Smcwg-public] Methods for email verification > > ? > > Tim ? I Agree. > > ? > > My initial question that started this thread was asking about this > statement in section 3.2.2.2.2: > ?https://github.com/srdavidson/smime/blob/PreSBR/SBR.md#32222--validating-control-over-email-address-via-email > > > * Completed validations of Applicant control over the email address > must be performed _for each Certificate issuance_. > > This sounds like you can?t re-use the email box validation at all, so I > wanted to see if we can clarify that.? We don?t have the same statement > in the prior section 3.2.2.2.1 > https://github.com/srdavidson/smime/blob/PreSBR/SBR.md#32221--validating-authority-over-email-address-via-domain > > and assume normal re-use of domain validation applies there. > > ? > > Wendy Brown asked a similar question to see if they same validation can > be used for issuance of 2 certs (signing and encryption).? If we take > the words in 3.2.2.2.2 literally, the answer is no. > > ? > > If we remove that line in the spec, then both question are resolved, but > does issuing a second cert to the same email address WITHOUT verifying > the email address reduce security?? In all cases of domain/email > validation re-use, you must make sure it?s the same subscriber.? This > might be done via sending an email (most logical and surely compliant), > but there may be service providers that host and are the > Applicant/Subscriber on behalf of the owner of the mailbox. Does the > mail box owner need to click a link every time the service provider > creates a new cert for them?? When the Enterprise does not want to hand > over full control to issue certs for ALL mailboxes within that domain, > it needs to be done at the mail box level with the mail box owner in the > loop. ?Permitting re-use of the email box level validation provides some > value. > > ? > > Doug > > ? > > ? > > *From:* Tim Hollebeek > > *Sent:* Tuesday, February 23, 2021 11:30 AM > *To:* Dimitris Zacharopoulos (HARICA) >; SMIME Certificate Working Group > >; Wendy > Brown - QT3LB-C >; Doug > Beattie > > *Subject:* RE: [Smcwg-public] Methods for email verification > > ? > > Right, we should follow the CABF validation reuse rules.? I.e. as long > as they?re both issued within the validation reuse timeframe, the second > can reuse the first?s validation. > > ? > > One of the annoying things is that CABF policies and traditional PKI > policies say basically the same thing in two different ways. > > ? > > Traditional PKIs have no provisions for reuse of validation, but define > issuance categories like ?renewal? and ?replacement? that have > pared-down validation and issuance rules based on the existence of a > previously issued certificate with the same validated information. > > ? > > CABF PKIs forbid ?renewal?, etc and treat everything as a new issuance, > but have validation reuse requirements that in practice ? tend to have > exactly the same effect.? You can renew (etc) a certificate without > having to completely redo the validation for previously validated > information. > > ? > > It?s mostly just tomayto tomahto, but it is a pain for PKIs that span > both worlds. > > ? > > -Tim > > ? > > *From:* Smcwg-public

> *On Behalf Of *Dimitris > Zacharopoulos (HARICA) via Smcwg-public > *Sent:* Sunday, February 21, 2021 5:17 AM > *To:* Wendy Brown - QT3LB-C >; SMIME Certificate Working Group > >; Doug > Beattie > > *Subject:* Re: [Smcwg-public] Methods for email verification > > ? > > ? > > On 18/2/2021 6:25 ?.?., Wendy Brown - QT3LB-C via Smcwg-public wrote: > > also could a single?validation of the email address be used for > issuance of both the signature & encryption certs in the case of the > dual certs vs single cert case? > > > That makes perfect sense to me. > > Validations in general should be allowed to be reused as it is allowed > in other Certificate types. > > > Dimitris. > > Wendy > > Wendy Brown > Supporting GSA FPKI > Protiviti Government Services > > ?703-965-2990 (cell) > > wendy.brown at gsa.gov > wendy.brown at protiviti.com > > ? > > ? > > On Thu, Feb 18, 2021 at 10:54 AM Doug Beattie via Smcwg-public > > wrote: > > Hi Stephen, > > ? > > I?m not sure I agree with this statement in section 3.2.2.2.2 > Validating control over email address via email > > ? > > * Completed validations of Applicant control over the email > address must be performed _for each Certificate issuance_. > > ? > > I?d like to permit re-use of that validation over and over for > the re-use period for that subscriber if possible.? Is there a > reason we preclude that?? For example, an email gateway provider > might validate this email address and then want to replace > certificates more frequently than 397 days, but this would > require emails to the email box to act on that. > > ? > > Doug > > ? > > ? > > *From:* Smcwg-public

> *On Behalf Of > *Stephen Davidson via Smcwg-public > *Sent:* Wednesday, February 17, 2021 6:02 PM > *To:* SMIME Certificate Working Group

> > *Subject:* [Smcwg-public] Methods for email verification > > ? > > Hello all: > > ? > > Following our discussion on the call today, I attach draft text > for section 3.2.2.2 of the SMIME BR (SBR) that deals with 1) > Validating authority over email address via domain and 2) > Validating control over email address via email. > > ? > > It aims to fulfill the requirements of the Mozilla policy.? It > includes comments with some questions that require further > discussion.? Additional methods can be addressed in future > versions of the SBR. > > ? > > Many thanks for Doug and Sebastian at GlobalSign for their help > in drafting this.? We?ll discuss this in a future meeting, but > feel free to also provide feedback here. > > ? > > Many thanks, Stephen > > _______________________________________________ > 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 > > ? > > > _______________________________________________ > Smcwg-public mailing list > Smcwg-public at cabforum.org > https://lists.cabforum.org/mailman/listinfo/smcwg-public > From Stephen.Davidson at digicert.com Mon Mar 15 19:57:09 2021 From: Stephen.Davidson at digicert.com (Stephen Davidson) Date: Mon, 15 Mar 2021 19:57:09 +0000 Subject: [Smcwg-public] Draft SMCWG agenda - Wednesday, March 17, 2021 Message-ID: SMCWG Agenda Draft SMCWG agenda - Wednesday, March 17, 2021 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. Read Antitrust / Compliance Statement 3. Review Agenda 4. Approval of minutes from teleconference of February 17, 2021 5. Continuation of discussion of end entity profiles 7. Any other business 8. Next call: Wednesday, March 31, 2021 at 11:00 am Eastern Time Adjourn -------------- next part -------------- An HTML attachment was scrubbed... URL: From Stephen.Davidson at digicert.com Wed Mar 17 14:35:51 2021 From: Stephen.Davidson at digicert.com (Stephen Davidson) Date: Wed, 17 Mar 2021 14:35:51 +0000 Subject: [Smcwg-public] FW: Draft SMCWG agenda - Wednesday, March 17, 2021 In-Reply-To: References: Message-ID: I am sending the attached again, as I just realized it does not seem to have gone out to the list despite being in my sent folder. Regards, Stephen SMCWG Agenda Draft SMCWG agenda - Wednesday, March 17, 2021 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. Read Antitrust / Compliance Statement 3. Review Agenda 4. Approval of minutes from teleconference of February 17, 2021 5. Continuation of discussion of end entity profiles 7. Any other business 8. Next call: Wednesday, March 31, 2021 at 11:00 am Eastern Time Adjourn -------------- next part -------------- An HTML attachment was scrubbed... URL: From Stephen.Davidson at digicert.com Tue Mar 23 21:22:59 2021 From: Stephen.Davidson at digicert.com (Stephen Davidson) Date: Tue, 23 Mar 2021 21:22:59 +0000 Subject: [Smcwg-public] Approved Minutes of SMCWG February 17, 2021 Message-ID: Minutes of SMCWG February 17, 2021 These are the Draft Minutes of the Teleconference described in the subject of this message. Corrections and clarifications where needed are encouraged by reply. Attendees Andreas Henschel (D-TRUST), Adrian Mueller (SwissSign), Andrea Holland (SecureTrust), Ali Gholami (Telia Company), Atsushi Inaba (GlobalSign), Burkhard Wiegel (Zertificon), Bruce Morton (Entrust), Ben Wilson (Mozilla), Chris Kemmerer (SSL.com), Christy Berghoff (Federal PKI), Corey Bonnell (DigiCert), David Chen (TWCA), Don Sheehy (WebTrust), Doug Beattie (GlobalSign), Dimitris Zacharopoulos (HARICA), Hazhar Ismail (MSC Trustgate.com), James Knapp (Federal PKI), Janet Hines (SecureTrust), Jeff Ward (WebTrust), Klauss Voss (Zertificon), Mevre Tunca (Zertificon), Matthias Wiedenhorst (ACAB'c), Mads Henriksveen (BuyPass), Niko Carpenter (SecureTrust), Pedro Fuentes (OISTE), Patrycja Tulinska (PSW), Li-Chun Chen (Chunghwa Telecom), Sebastian Schulz (GlobalSign), Stefan Selbitschka (rundQuadrat), Stephen Davidson (DigiCert), Tadahiko Ito (SECOM Trust Systems), Thomas Connelly (Federal PKI), Tim Hollebeek (DigiCert), Tsung-Min Kuo (Chunghwa Telecom) 1. Roll Call The Roll Call was taken. 2. Read Antitrust Statement The Antitrust/Compliance Statement was read. 3. Review Agenda 4. Approval of minutes from last teleconference The minutes of the February 3 teleconference were approved. 5. New Member Declaration Existing CABF members Apple (Certificate Consumer) and AC Camerfirma (Certificate Issuer) were confirmed as members of the SMCWG. 6. Discussion of certificate profile A discussion was undertaken on the format of our presentation to the upcoming CABF Virtual Face to Face, both to describe our progress towards creating the draft S/MIME Standard and to seek clarification several points. These topics include: * Certificate policy types * Continued use of commonName and email fields which are "discouraged but permitted" in other cert types * Validity periods, balancing policy agility with user key management * Proposals for validation of email control or authorization * Moving the Draft SBR to GitHub Stephen Davidson noted that our charter emphasizes that the SMCWG should leverage the work of other CABF WG standards. He proposed tying to specific versions of the referenced standards to prevent unintended "drift via changing reference". Discussion continued from the previous call regarding certificate policy types in which it was proposed to expand the array of policy types as follows: * Mailbox-validation: The simplest S/MIME, including only email address. The same email control verification methods apply across all S/MIME types. * Organizational-validation: Includes Organization details (legal entity) only. Example uses include invoice or statement mailers, etc. * Sponsored-validation: An Organization "sponsors" certificates including personal details or mailbox names (validated by a delegated Enterprise RA) in conjunction with Org details and domains (validated by the CA). Typical use is employee S/MIME. * Individual-validation: Includes personal details (for natural person). May include verified Org info. For each of these, the following types would exist: * Legacy: A basic profile that encompasses a range of reasonable existing practices to bring them into an auditable environment. * Multipurpose: A more formal profile - but allows multipurpose use (e.g., signing in context of email or documents, clientAuth) * Strict: Dedicated to S/MIME use, in line with the growing use of specialised Root hierarchies. Stephen indicated that the Subject of the Multipurpose and Strict policies would likely be similar. He indicated that in future versions we may choose to vary the keyUsages available by type, but that would require wider community feedback. Tim Hollebeek indicated allows flexibility to bring the wide variety of S/MIME use cases into an auditable framework, and that the good/better/best of the types would allow a roadmap for tightening of standards. Dimitris Zacharopoulos reminded that we must stay focused on our primary goal which is S/MIME profiles. Sebastian Schulz supported the focus on Strict profiles. Tim indicated that much would flow across the profiles, and at this stage only a few CAs have dedicated hierarchies by type so this standard will be able to adapt with time. Tom Connelly emphasized that we need to be careful in balancing simplicity for the CA but creating usability problems for users (for example by cutting allowed validity periods or by doing away with multipurpose certificates). Tim agreed that we must be aware of user needs and not simply move complexity around. Stephen agreed to distribute draft text on the methods for 1) validating authority over email address via domain and 2) validating control over email address via email (the two requirements of the Mozilla policy.) 6. Any Other Business None 7. Next call The March 3 call of the SMCWG has been cancelled but will be replaced by an overall meeting of the CABF (the Virtual F2F). Further details to follow. Adjourned -------------- next part -------------- An HTML attachment was scrubbed... URL: From Stephen.Davidson at digicert.com Tue Mar 23 21:27:49 2021 From: Stephen.Davidson at digicert.com (Stephen Davidson) Date: Tue, 23 Mar 2021 21:27:49 +0000 Subject: [Smcwg-public] Approved Minutes of SMCWG February 17, 2021 In-Reply-To: <0100017860f84ba2-a890fc6d-aa0a-4a42-8e5d-88c59f8d28c7-000000@email.amazonses.com> References: <0100017860f84ba2-a890fc6d-aa0a-4a42-8e5d-88c59f8d28c7-000000@email.amazonses.com> Message-ID: Correction: removing a remaining reference to draft. My apologies. Stephen From: Smcwg-public On Behalf Of Stephen Davidson via Smcwg-public Sent: Tuesday, March 23, 2021 6:23 PM To: SMIME Certificate Working Group Subject: [Smcwg-public] Approved Minutes of SMCWG February 17, 2021 Minutes of SMCWG February 17, 2021 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 Andreas Henschel (D-TRUST), Adrian Mueller (SwissSign), Andrea Holland (SecureTrust), Ali Gholami (Telia Company), Atsushi Inaba (GlobalSign), Burkhard Wiegel (Zertificon), Bruce Morton (Entrust), Ben Wilson (Mozilla), Chris Kemmerer (SSL.com), Christy Berghoff (Federal PKI), Corey Bonnell (DigiCert), David Chen (TWCA), Don Sheehy (WebTrust), Doug Beattie (GlobalSign), Dimitris Zacharopoulos (HARICA), Hazhar Ismail (MSC Trustgate.com), James Knapp (Federal PKI), Janet Hines (SecureTrust), Jeff Ward (WebTrust), Klauss Voss (Zertificon), Mevre Tunca (Zertificon), Matthias Wiedenhorst (ACAB'c), Mads Henriksveen (BuyPass), Niko Carpenter (SecureTrust), Pedro Fuentes (OISTE), Patrycja Tulinska (PSW), Li-Chun Chen (Chunghwa Telecom), Sebastian Schulz (GlobalSign), Stefan Selbitschka (rundQuadrat), Stephen Davidson (DigiCert), Tadahiko Ito (SECOM Trust Systems), Thomas Connelly (Federal PKI), Tim Hollebeek (DigiCert), Tsung-Min Kuo (Chunghwa Telecom) 1. Roll Call The Roll Call was taken. 2. Read Antitrust Statement The Antitrust/Compliance Statement was read. 3. Review Agenda 4. Approval of minutes from last teleconference The minutes of the February 3 teleconference were approved. 5. New Member Declaration Existing CABF members Apple (Certificate Consumer) and AC Camerfirma (Certificate Issuer) were confirmed as members of the SMCWG. 6. Discussion of certificate profile A discussion was undertaken on the format of our presentation to the upcoming CABF Virtual Face to Face, both to describe our progress towards creating the draft S/MIME Standard and to seek clarification several points. These topics include: * Certificate policy types * Continued use of commonName and email fields which are "discouraged but permitted" in other cert types * Validity periods, balancing policy agility with user key management * Proposals for validation of email control or authorization * Moving the Draft SBR to GitHub Stephen Davidson noted that our charter emphasizes that the SMCWG should leverage the work of other CABF WG standards. He proposed tying to specific versions of the referenced standards to prevent unintended "drift via changing reference". Discussion continued from the previous call regarding certificate policy types in which it was proposed to expand the array of policy types as follows: * Mailbox-validation: The simplest S/MIME, including only email address. The same email control verification methods apply across all S/MIME types. * Organizational-validation: Includes Organization details (legal entity) only. Example uses include invoice or statement mailers, etc. * Sponsored-validation: An Organization "sponsors" certificates including personal details or mailbox names (validated by a delegated Enterprise RA) in conjunction with Org details and domains (validated by the CA). Typical use is employee S/MIME. * Individual-validation: Includes personal details (for natural person). May include verified Org info. For each of these, the following types would exist: * Legacy: A basic profile that encompasses a range of reasonable existing practices to bring them into an auditable environment. * Multipurpose: A more formal profile - but allows multipurpose use (e.g., signing in context of email or documents, clientAuth) * Strict: Dedicated to S/MIME use, in line with the growing use of specialised Root hierarchies. Stephen indicated that the Subject of the Multipurpose and Strict policies would likely be similar. He indicated that in future versions we may choose to vary the keyUsages available by type, but that would require wider community feedback. Tim Hollebeek indicated allows flexibility to bring the wide variety of S/MIME use cases into an auditable framework, and that the good/better/best of the types would allow a roadmap for tightening of standards. Dimitris Zacharopoulos reminded that we must stay focused on our primary goal which is S/MIME profiles. Sebastian Schulz supported the focus on Strict profiles. Tim indicated that much would flow across the profiles, and at this stage only a few CAs have dedicated hierarchies by type so this standard will be able to adapt with time. Tom Connelly emphasized that we need to be careful in balancing simplicity for the CA but creating usability problems for users (for example by cutting allowed validity periods or by doing away with multipurpose certificates). Tim agreed that we must be aware of user needs and not simply move complexity around. Stephen agreed to distribute draft text on the methods for 1) validating authority over email address via domain and 2) validating control over email address via email (the two requirements of the Mozilla policy.) 6. Any Other Business None 7. Next call The March 3 call of the SMCWG has been cancelled but will be replaced by an overall meeting of the CABF (the Virtual F2F). Further details to follow. Adjourned -------------- next part -------------- An HTML attachment was scrubbed... URL: From Stephen.Davidson at digicert.com Mon Mar 29 19:25:41 2021 From: Stephen.Davidson at digicert.com (Stephen Davidson) Date: Mon, 29 Mar 2021 19:25:41 +0000 Subject: [Smcwg-public] Draft SMCWG agenda - Wednesday, March 31, 2021 Message-ID: SMCWG Agenda Draft SMCWG agenda - Wednesday, March 31, 2021 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. Read Antitrust / Compliance Statement 3. Review Agenda 4. Approval of minutes from teleconference of March 17, 2021 5. Order of business: ********* Review of progress on S/MIME Baseline Requirements (BR) draft ********* Review of draft mailbox verification methods ********* Discussion of baseline for Mailbox-validated certificates 8. Any other business 9. Next call: Wednesday, April 14, 2021 at 11:00 am Eastern Time Adjourn -------------- next part -------------- An HTML attachment was scrubbed... URL: