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: