From Stephen.Davidson at digicert.com Mon Apr 5 22:36:36 2021 From: Stephen.Davidson at digicert.com (Stephen Davidson) Date: Mon, 5 Apr 2021 22:36:36 +0000 Subject: [Smcwg-public] Approved Minutes of SMCWG March 17, 2021 Message-ID: Minutes of SMCWG March 17, 2021 These are the Approved Minutes of the Teleconference described in the subject of this message. Attendees Adrian Mueller (SwissSign), Andrea Holland (SecureTrust), Ali Gholami (Telia Company), Atsushi Inaba (GlobalSign), Burkhard Wiegel (Zertificon), Bruce Morton (Entrust), Ben Wilson (Mozilla), Christy Berghoff (Federal PKI), Clint Wilson (Apple), Corey Bonnell (DigiCert), Curt Spann (Apple), Dean Coclin (DigiCert), Enrico Entschew (D-TRUST), Hazhar Ismail (MSC Trustgate.com), Russ Housley (Vigil Security), James Knapp (Federal PKI), Janet Hines (SecureTrust), Klauss Voss (Zertificon), David Kluge (Google), Inigo Barreira (Sectigo), Juan ?ngel Martin (Camerfirma), Morad Abou Nasser (TeleTrust), Niko Carpenter (SecureTrust), Pedro Fuentes (OISTE), Patrycja Tulinska (PSW), Li-Chun Chen (Chunghwa Telecom), Rebecca Kelley (Apple), Sebastian Schulz (GlobalSign), Stephen Davidson (DigiCert), Thomas Connelly (Federal PKI), Wendy Brown (Federal PKI) 1. Roll Call The Roll Call was taken. 2. Read Antitrust Statement The Antitrust/Compliance Statement was read. 3. Review Agenda It was noted that the listserv may not have been distributing messages, including the agenda (which was redistributed offlist before the meeting). The listserv issues appear to now have been resolved. 4. Approval of minutes from last teleconference The minutes of the February 17 teleconference were approved. 6. Discussion of certificate profile A discussion commenced regarding the allowed fields in the Subject DN for the various S/MIME certificate types: {joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-policies(1) smime-baseline(5) smime-type (X) smime-grade (y)} * Mailbox-validation (1) * Organizational-validation (2) * Sponsored-validation (3) * Individual-validation (4) For each grade: * Strict (1) * Multipurpose (2) * Legacy (3) Clint Wilson asked what minimum fields a Certificate Consumer (client software) might expect to see in an S/MIME certificate as this was relevant to any discussion of the Subject. Curt Spann expanded upon that to ask what is the absolute baseline for all cert fields. It was noted that in previous discussions the WG had worked through requirements known to us including those from Mozilla and gmail. It was noted that following recent discussion in the IETF, https://tools.ietf.org/html/draft-rsalz-use-san-00 would likely not seek to ban the use of CN and Subject Email in S/MIME certs. Corey Bonnell noted that rfc822 SAN was required by RFC 5280 if Subject Email was used. Wendy Brown raised that multiple emails should be allowed in SAN, assuming that the issuer has verified mailbox control/authorization for each address before issuance. All email addresses in the Subject should be in the SAN. Morad Abou Nasser questioned if encryption certificates should be allowed to have multiple mail boxes (vs aliases). It was noted that Outlook has provided some information on S/MIME cert processing to the WG. Sebastien Schulz suggested that we more formally survey the Certificate Consumers. Ben and Clint offered to assist. In the absence of direct feedback, Ben Wilson suggested that test certificates might be created to verify behavior in different clients. Questions might include: * What are the minimum certificate requirements for processing an S/MIME message? * What certificate contents (or absence of contents) would cause S/MIME to fail? * Are there failure messages related to certificate configuration? * What certificate information is used for display to the mailbox owner by default? * In other words, in what order does the software look through cert contents for display? * Is this configurable? * Does the mail client software have issues processing certificates with more than one rfc822 in the SAN? * Does the email software have ability to act upon S/MIME messages based upon information in the certificate? (ie to trigger processing rules) * Are there S/MIME certificate current practices that are known to be problematic for mail clients? 6. Any Other Business None 7. Next call Next call: Wednesday, March 31, 2021 at 11:00 am Eastern Time Adjourned -------------- next part -------------- An HTML attachment was scrubbed... URL: From selbitschka at rundquadrat.at Fri Apr 9 12:00:47 2021 From: selbitschka at rundquadrat.at (Stefan Selbitschka) Date: Fri, 9 Apr 2021 14:00:47 +0200 Subject: [Smcwg-public] Certificate Profiles Message-ID: <83c699cb-42dd-b227-d117-6d3e0234447e@rundquadrat.at> Hi, following the last meeting I reviewed the "Validation-Spreadsheet" and would like to share my thoughts. General: ======== Extensions: ----------- In all profiles the extensions are limited and in strict and multipurpose there "Any other extension" is set to "MUST NOT". If we do this we need a full white list of allowed extensions and I miss at least the following: - Authority Key Identifier - Authority Information Access - Certificate Policies - CRL Distribution Points - Subject Key Identifier May we would add some CT or other extensions ... As an alternative we could write "Any other extension not listed in RFC5280, ...". Subject - E-Mail: ----------------- This is set to "MAY" in all but Sponsored-Validiation where it is a "MUST". I would change this to "MAY" in all cases or is there any reason for require it in case of a sponsored validation? Furthermore I would add some restrictions that if an email address is in the subject email field, the same email address must be present in the subjectAltName extension as rfc822name. Mailbox-Validation: =================== Empty Subject: -------------- I do not know the current state of the "minimum certificate behavior check" suggested on March 17. Maybe we should create a git with certificates with different contents and signed and encrypted messages, so that everybody can test this within his own environment and his MUA. This said the following discussion is focused on my personal experiences and my be dependent on my current environment. Within the mailbox validation profile, at least with strict and multipurpose, we force the use of the email field instead of discourage it if its the only allowed field. From my experiences most implementation expect a non-empty subject within an S/MIME certificate. My suggestion would be to set commonName to "MAY: email" in strict an multipurpose as well. According to RFC5280 4.1.2.6. Subject: --- If subject naming information is present only in the subjectAltName extension (e.g., a key bound only to an email address or URI), then the subject name MUST be an empty sequence and the subjectAltName extension MUST be critical. ---- Do we reflect this in our certificate profiles and require the subjectAltName to be critical in this case? regards stefan -- Stefan Selbitschka rundQuadrat OG - Gesch?ftsf?hrung Mariahilfer Stra?e 61 / 11 1060 Wien Tel: +43 1 2362568 Mobile: +43 660 7863002 Firmenbuch: 316047a UID: ATU64609908 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4280 bytes Desc: S/MIME Cryptographic Signature URL: From Stephen.Davidson at digicert.com Mon Apr 12 18:27:48 2021 From: Stephen.Davidson at digicert.com (Stephen Davidson) Date: Mon, 12 Apr 2021 18:27:48 +0000 Subject: [Smcwg-public] Certificate Profiles In-Reply-To: <01000178b681a665-abb034fc-f22c-40cc-bebe-35b53755178c-000000@email.amazonses.com> References: <01000178b681a665-abb034fc-f22c-40cc-bebe-35b53755178c-000000@email.amazonses.com> Message-ID: Thank you Stefan for your feedback - it's helpful for our ongoing discussion. On the matter of the Extensions - you are correct. The spreadsheets currently focus only on certain fields which may have quite a bit of variability across profiles. Other fields that are more consistent across profiles will be added later. Best, Stephen -----Original Message----- From: Smcwg-public On Behalf Of Stefan Selbitschka via Smcwg-public Sent: Friday, April 9, 2021 9:01 AM To: smcwg-public at cabforum.org Subject: [Smcwg-public] Certificate Profiles Hi, following the last meeting I reviewed the "Validation-Spreadsheet" and would like to share my thoughts. General: ======== Extensions: ----------- In all profiles the extensions are limited and in strict and multipurpose there "Any other extension" is set to "MUST NOT". If we do this we need a full white list of allowed extensions and I miss at least the following: - Authority Key Identifier - Authority Information Access - Certificate Policies - CRL Distribution Points - Subject Key Identifier May we would add some CT or other extensions ... As an alternative we could write "Any other extension not listed in RFC5280, ...". Subject - E-Mail: ----------------- This is set to "MAY" in all but Sponsored-Validiation where it is a "MUST". I would change this to "MAY" in all cases or is there any reason for require it in case of a sponsored validation? Furthermore I would add some restrictions that if an email address is in the subject email field, the same email address must be present in the subjectAltName extension as rfc822name. Mailbox-Validation: =================== Empty Subject: -------------- I do not know the current state of the "minimum certificate behavior check" suggested on March 17. Maybe we should create a git with certificates with different contents and signed and encrypted messages, so that everybody can test this within his own environment and his MUA. This said the following discussion is focused on my personal experiences and my be dependent on my current environment. Within the mailbox validation profile, at least with strict and multipurpose, we force the use of the email field instead of discourage it if its the only allowed field. From my experiences most implementation expect a non-empty subject within an S/MIME certificate. My suggestion would be to set commonName to "MAY: email" in strict an multipurpose as well. According to RFC5280 4.1.2.6. Subject: --- If subject naming information is present only in the subjectAltName extension (e.g., a key bound only to an email address or URI), then the subject name MUST be an empty sequence and the subjectAltName extension MUST be critical. ---- Do we reflect this in our certificate profiles and require the subjectAltName to be critical in this case? regards stefan -- Stefan Selbitschka rundQuadrat OG - Gesch?ftsf?hrung Mariahilfer Stra?e 61 / 11 1060 Wien Tel: +43 1 2362568 Mobile: +43 660 7863002 Firmenbuch: 316047a UID: ATU64609908 From Stephen.Davidson at digicert.com Tue Apr 13 18:32:53 2021 From: Stephen.Davidson at digicert.com (Stephen Davidson) Date: Tue, 13 Apr 2021 18:32:53 +0000 Subject: [Smcwg-public] Draft SMCWG agenda - Wednesday, April 14, 2021 Message-ID: SMCWG Agenda Draft SMCWG agenda - Wednesday, April 14, 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 31, 2021 5. Review draft section 8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS See here. 6. Discussion of baseline for Mailbox-validated - Legacy profile. See here. 7. Any other business 8. Next call: Wednesday, April 28, 2021 at 11:00 am Eastern Time Adjourn -------------- next part -------------- An HTML attachment was scrubbed... URL: From dzacharo at harica.gr Wed Apr 14 15:03:13 2021 From: dzacharo at harica.gr (Dimitris Zacharopoulos (HARICA)) Date: Wed, 14 Apr 2021 18:03:13 +0300 Subject: [Smcwg-public] Draft SMCWG agenda - Wednesday, April 14, 2021 In-Reply-To: <01000178cc821de9-285c883c-4269-4fbf-a67e-dfc6c976c6ad-000000@email.amazonses.com> References: <01000178cc821de9-285c883c-4269-4fbf-a67e-dfc6c976c6ad-000000@email.amazonses.com> Message-ID: <7110724c-153d-867a-67d5-b4bb0cca8acd@harica.gr> Stephen, Can you please allow commenting on these documents? It's very difficult to propose changes and review using the mailing list, but we can proceed as you think best. Dimitris. On 13/4/2021 9:33 ?.?., Stephen Davidson via Smcwg-public wrote: > > > SMCWG Agenda > > > Draft SMCWG agenda - Wednesday, April 14, 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 31, 2021 > > > 5. Review draft section 8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS > See here > . > > > 6. Discussion of baseline for Mailbox-validated ? Legacy profile. > See here > . > > > 7. Any other business > > > 8. Next call: Wednesday, April 28, 2021 at 11:00 am Eastern Time > > > Adjourn > > > _______________________________________________ > 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 Corey.Bonnell at digicert.com Thu Apr 22 01:25:08 2021 From: Corey.Bonnell at digicert.com (Corey Bonnell) Date: Thu, 22 Apr 2021 01:25:08 +0000 Subject: [Smcwg-public] ACME S/MIME specification is now published as RFC 8823 Message-ID: Hello, In case you didn't see it, the ACME S/MIME specification (which has been mentioned a few times on our calls) was published today as RFC 8823: https://www.rfc-editor.org/rfc/rfc8823.html. 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: 4990 bytes Desc: not available URL: From Stephen.Davidson at digicert.com Fri Apr 23 20:17:33 2021 From: Stephen.Davidson at digicert.com (Stephen Davidson) Date: Fri, 23 Apr 2021 20:17:33 +0000 Subject: [Smcwg-public] Approved Minutes of SMCWG March 31, 2021 Message-ID: Minutes of SMCWG March 31, 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 Adrian Mueller (SwissSign), Ali Gholami (Telia Company), Atsushi Inaba (GlobalSign), Bruce Morton (Entrust), Ben Wilson (Mozilla), Chris Kemmerer (SSL.com), Clint Wilson (Apple), Corey Bonnell (DigiCert), Curt Spann (Apple), Dimitris Zacharopoulos (HARICA), Hazhar Ismail (MSC Trustgate.com), Russ Housley (Vigil Security), Janet Hines (SecureTrust), Jeff Ward (WebTrust), Klauss Voss (Zertificon), Inigo Barreira (Sectigo), Matthias Wiedenhorst (ACAB'c), Mads Henriksveen (BuyPass), Morad Abou Nasser (TeleTrust), Patrycja Tulinska (PSW), Li-Chun Chen (Chunghwa Telecom), Rebecca Kelley (Apple), Sebastian Schulz (GlobalSign), Stefan Selbitschka (rundQuadrat), Stephen Davidson (DigiCert), Ahmad Syafiq Md Zaini (MSC Trustgate.com), Tadahiko Ito (SECOM Trust Systems), Tim Crawford (WebTrust), Thomas Connelly (Federal PKI), Tsung-Min Kuo (Chunghwa Telecom), Wendy Brown (Federal PKI) 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 March 17 teleconference were approved. 6. Discussion of certificate profile A review was made of the current state of the draft S/MIME Baseline Requirements (SBR), which have now been pulled into the CABF Repository at: https://github.com/cabforum/smime/blob/PreSBR/SBR.md. The working draft will continue using Stephen Davidson's srdavidson fork but will be periodically pulled into the CABF Repository, so members may choose to fork that CABF version. The preSBR branch will be used as the document is in early editing. Later well adopt the "branch per ballot" approach used by other CABF WG. Members can also use the Issues function in the CABF Repository. The SMCWG charter notes the SBR are "subject to coordination with other Forum CWGs to ensure consistency and avoid redundancy." It was agreed that for the sake of simple reference, most sections will be reproduced in their entirety in the SBR because the text in the BR sometimes required minor revision for suitability in the SBR. However, certain BR sections prone to change such as the BR 3.2.2 will be incorporated by reference to a specific version of the BR. In both cases, when ballots change the BR our group will need to conduct a review of the SBR. A review was made of the draft text for 3.2.2.2 on validation of domain authorization or mailbox control at https://github.com/cabforum/smime/blob/PreSBR/SBR.md#3222--validation-of-domain-authorization-or-control. The BR methods will be adopted for domain authorization, and the SBR describes the requirements for verification of mailbox control. It was agreed that the SBR would maintain its own schedule for verified information reuse in Section 4.2.1. It was agreed that new methods such as acme-smime, acme-sso, or the use of MX records are of interest, but will be considered after v1 of the SBR. It was suggested that members review the text and provide further feedback regarding the SMCWG public list. A discussion took place regarding the proposed profile for Mailbox-validation certificates at https://docs.google.com/spreadsheets/d/1gEq-o4jU1FWvKBeMoncfmhAUemAgGuvVRSLQb7PedLU/edit#gid=718518913. Comments may be left on that sheet, but will have greater prominence on the SMCWG public list. Curt Spann enquired why, in addition to the Strict profile, we also provided Multipurpose and Legacy profiles. Stephen Davidson provided a summary of previous discussions on that point, including the current popular issuance of "signing certs" that had S/MIME as just one use and the charter which admonishes "care will be exercised by the SMCWG to avoid unintended adverse effects" to other use cases. As the charter is to write a standard for certs that include the emailProtection EKU, we need to accommodate different use cases. Sebastian Schulz suggested that we should focus on the Strict S/MIME profile in keeping with the root stores' shifting preference towards single purpose hierarchies. Stephen pointed out that use may not be determined solely by EKU (for example, many AATL signing certs use the emailProtection EKU). Clint Wilson raised that multipurpose certs had some parallel in the TLS world where certs were used in too many cases, hampering agility. Wendy Brown indicated that dedicated hierarchies also have a tradeoff by forcing users to maintain more leaf certs. Stephen pointed out the goal in the first version of the SBR was to set a baseline that could pull the S/MIME ecosystem into an auditable framework which would be refined in future versions. 6. Any Other Business None 7. Next call Next call: Wednesday, April 14, 2021 at 11:00 am Eastern Time Adjourned From Stephen.Davidson at digicert.com Mon Apr 26 20:22:01 2021 From: Stephen.Davidson at digicert.com (Stephen Davidson) Date: Mon, 26 Apr 2021 20:22:01 +0000 Subject: [Smcwg-public] Draft SMCWG agenda - Wednesday, April 28, 2021 Message-ID: SMCWG Agenda Draft SMCWG agenda - Wednesday, April 28, 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 April 14, 2021 5. Goal setting for next CABF F2F 6. Discussion of baseline for Mailbox-validated / Legacy profile. See here. 7. Any other business 8. Next call: Wednesday, May 12, 2021 at 11:00 am Eastern Time Adjourn -------------- next part -------------- An HTML attachment was scrubbed... URL: