From Stephen.Davidson at digicert.com Tue Jan 5 22:30:24 2021 From: Stephen.Davidson at digicert.com (Stephen Davidson) Date: Tue, 5 Jan 2021 22:30:24 +0000 Subject: [Smcwg-public] Draft SMCWG agenda - Wednesday, January 6, 2021 Message-ID: SMCWG Agenda Draft SMCWG agenda - Wednesday, January 6, 2021 at 11:00 am Eastern Time Here is a draft CA 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 teleconferences of November 25 and December 9, 2020 5. Discussion of: ********* Roadmap for SMCWG work ********* Discussion of Certificate Policy types: permissive/legacy versus strict 6. Any other business 7. Next call: January 20, 2021 at 11:00 am Eastern Time Adjourn -------------- next part -------------- An HTML attachment was scrubbed... URL: From Stephen.Davidson at digicert.com Sun Jan 17 13:48:32 2021 From: Stephen.Davidson at digicert.com (Stephen Davidson) Date: Sun, 17 Jan 2021 13:48:32 +0000 Subject: [Smcwg-public] Approved Minutes of SMCWG November 25, 2020 Message-ID: Minutes of SMCWG November 25, 2020 These are the Approved Minutes of the Teleconference described in the subject of this message. Attendees Adrian Mueller (SwissSign), Ahmad Syafiq Md Zaini (MSC Trustgate.com), Ali Gholami (Telia Company), Andreas Henschel (D-TRUST), Atsushi Inaba (GlobalSign), Ben Wilson (Mozilla), Burkhard Wiegel (Zertificon), Chris Kemmerer (SSL.com), Corey Bonnell (DigiCert), David Kluge (Google), Dean Coclin (DigiCert), Dimitris Zacharopoulos (HARICA), Don Sheehy (WebTrust), Doug Beattie (GlobalSign), Enrico Entschew (D-TRUST), Hazhar Ismail (MSC Trustgate.com), Hongquan Yin (Microsoft), India Donald (Federal PKI), James Knapp (Federal PKI), Janet Hines (SecureTrust), Li-Chun Chen (Chunghwa Telecom), Mads Henriksveen (BuyPass), Matthias Wiedenhorst (ACAB'c), Nazmi Abd Hadi (MSC Trustgate.com), Neil Dunbar (TrustCor), Patrycja Tulinska (PSW), Pedro Fuentes (OISTE), Russ Housley (Vigil Security), Stephen Davidson (DigiCert), Tadahiko Ito (SECOM Trust Systems), Thomas Connelly (Federal PKI), Tim Crawford (WebTrust), Tim Hollebeek (DigiCert), 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 The Chair proposed deferring the discussion of new membership, and adding a new agenda item relating to certificate policy OIDs. 4. Approval of minutes from last teleconference The minutes of the November 11 teleconference were approved. 5. Discussion of certificate profile Stephen shared a preview of the S/MIME Baseline Requirements section 7 in markdown format, currently in a private GitHub Repository. The draft uses the table format agreed upon in earlier meetings. With the help of the Infrastructure WG, the plan is to move towards using the cabf-smcwg-br repository in early 2021 including for commenting and tracking of issues. In part based upon Doug Beattie's comment on the public list, a discussion was held on certificate-policy OIDs. The OID arc 2.23.140.1.5 has been reserved for the S/MIME Baseline Requirements (SBR). The proposal is to adopt familiar validation levels (DV, OV, IV) as found in TLS - with an additional level for personal certs that include organizational details. Dimitris Zacharopoulos suggested this should be linked to OV; Corey Bonnell subsequently suggested the term "Sponsored Validation" (SV) to describe this level. {joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-policies(1) smime-baseline(5) domain-validation (1)} (2.23.140.1.5.1) {joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-policies(1) smime-baseline(5) organization-validation (2)} (2.23.140.1.5.2) {joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-policies(1) smime-baseline(5) sponsored-validation (3)} (2.23.140.1.5.3) {joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-policies(1) smime-baseline(5) individual-validation (4)} (2.23.140.1.5.4) If required, extensions may be defined under the CABF certificate-extensions arc 2.23.140.2. Examples might include identifiers for keys generated or stored on cryptotokens etc. Stephen Davidson proposed that certain Subject attributes be restricted, mandatory or optional depending on the certificate policy. Tim Hollebeek suggested that initial versions of the standard should be inclusive of common Issuer practice. Wendy Brown indicated that the L and S fields might be considered optional except if required to disambiguate the Subject. A discussion was held regarding the Subject attributes described in RFC 3739 Section 3.1.2: domainComponent countryName commonName surname givenName pseudonym serialNumber title organizationName organizationalUnitName stateOrProvinceName localityName A particular focus involved attributes such as title and in particular pseudonym, which may be beyond the ability of the CA to verify. It was agreed that some might make sense in a "Sponsored Validation" context. It was indicated that pseudonym may reasonably be used for profile names or English adopted names for international names. It was agreed that at this stage we will focus on which fields might be allowed for the various certificate-policy levels - knowing that we must return to the required verification steps later in the process. Certificate Issuers were requested to identify if they used Subject attributes not identified here. Wendy Brown mentioned the use of dnQualifier to disambiguate Subjects, and indicated the range of uses of the CommonName field, such as "Stephen Davidson (contractor)". Dimitris Zacharopoulos raised the use of the organizationIdentifier attribute in OV certificates. It was pointed out that the Subject email field was deprecated albeit still in common use. A discussion began regarding rfc822name and the extent to which the SBR should seek to define an email address. Lacking time, the remaining agenda items were deferred to a future meeting. 6. Any Other Business It was agreed that the December 23, 2020 meeting would be cancelled. 7. Next call The next call will take place on December 9, 2020 at 11:00am Eastern Time. Adjourned -------------- next part -------------- An HTML attachment was scrubbed... URL: From Stephen.Davidson at digicert.com Sun Jan 17 13:50:48 2021 From: Stephen.Davidson at digicert.com (Stephen Davidson) Date: Sun, 17 Jan 2021 13:50:48 +0000 Subject: [Smcwg-public] Approved Minutes of SMCWG December 9, 2020 Message-ID: Minutes of SMCWG December 09, 2020 Attendees Adrian Mueller (SwissSign), Ahmad Syafiq Md Zaini (MSC Trustgate.com), Ali Gholami (Telia Company), Andrea Holland (SecureTrust), Andreas Henschel (D-TRUST), Arno Fiedler (Arno Fiedler), Atsushi Inaba (GlobalSign), Ben Wilson (Mozilla), Chris Kemmerer (SSL.com), Corey Bonnell (DigiCert), David Kluge (Google), Dean Coclin (DigiCert), Don Sheehy (WebTrust), Doug Beattie (GlobalSign), Enrico Entschew (D-TRUST), Hazhar Ismail (MSC Trustgate.com), Hongquan Yin (Microsoft), James Knapp (Federal PKI), Janet Hines (SecureTrust), Jeff Ward (WebTrust), Li-Chun Chen (Chunghwa Telecom), Mads Henriksveen (BuyPass), Morad Abou Nasser (TeleTrust), Patrycja Tulinska (PSW), Pedro Fuentes (OISTE), Rich Smith (Sectigo), Rufus Buschart (TeleTrust), Russ Housley (Vigil Security), Sebastian Schulz (GlobalSign), Stephen Davidson (DigiCert), Tadahiko Ito (SECOM Trust Systems), Thomas Zermeno (SSL.com), Tim Crawford (WebTrust), Tim Hollebeek (DigiCert) 1. Roll Call The Roll Call was taken. 2. Read Antitrust Statement The Antitrust/Compliance Statement was read. 3. Review Agenda There was discussion relating to the change in CABF mailers, noting that members should check the listserv archives if they have not been receiving messages recently. Some mail systems started quarantining messages with the change in mailer. 4. Approval of minutes from last teleconference It was noted that some members did not receive the draft Minutes of the November 25 call. Those will be re-distributed and approval of those Minutes is deferred until a later date. 5. New member Following discussion and confirmation of eligibility, the membership of KPMG Korea as an Interested Party was confirmed by consensus. 6. Discussion of certificate profile Extensive discussion took place regarding the certificate policy object identifiers for different forms of S/MIME certificates. {joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-policies(1) smime-baseline(5) mailbox-validation (1)} (2.23.140.1.5.1) {joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-policies(1) smime-baseline(5) organization-validation (2)} (2.23.140.1.5.2) {joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-policies(1) smime-baseline(5) sponsored-validation (3)} (2.23.140.1.5.3) {joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-policies(1) smime-baseline(5) individual-validation (4)} (2.23.140.1.5.4) Corey Bonnell proposed to use the name "mailbox-validation" for the basic form of S/MIME certificate to avoid confusion with DV or EV TLS. Ben Wilson noted that the S/MIME BR (SBR) standard should not cause a revocation event for certificates issued before its effective date. Russ Hously said that should not be a concern as only certificates including the SBR OIDs would be subject to the SBR. There was discussion relating to the Subject and other fields that should be mandatory or optional/disallowed in each type of cert. Doug Beattie suggested having some form of "legacy" OID(s) that would be more permissive but would have a sunset date. The "final" SBR OIDs would be more defined. Tim Hollebeek suggested that those OIDs could be further iterated as the SBR evolved. There was discussion regarding the use of Common Name and Email in the Subject by client software, and the absence of such. Hongquan Yin subsequently followed up describing Outlook's behavior. Common Name will be used as the "Display Name" for the subject the of the certificate in some places in the UI. If present, Email may be used as one of the email addresses. The Subject Alternative Name extension is also examined for rfc822Names. The email address can be specified there and not included in the Subject. Tadahiko Ito pointed out that client software may present mail account names in precedence to information in the certificate. There was discussion of fields like Pseudonym and Serial Number which may include values that are not possible for a public CA to verify. It was proposed these may be acceptable in the Sponsored Validation category where an Enterprise RA may be able to validate the information. It was also suggested that use of those fields may be more appropriate for private trust. Stephen Davidson asked Certificate Issuers to review their certificate populations to see if the Subject DN fields were used beyond the basic attributes so far discussed (and noting if the certificate is solely intended for S/MIME or is multipurpose). Rufus Buschart indicated that the SBR would need to accommodate international naming conventions (giving the example of countries where individuals may have multiple names but express a preference to specific names in a cert). A discussion was held on keyUsage combinations as described in ETSI TS 319 421-2. A discussion took place regarding rfc822names, and whether the SBR should seek to explicitly describe what was an allowable email address. Consensus was that the SBR should simply elaborate the relevant standards. It was proposed that in the SAN may include directoryName and otherName such as UPN only if they contain information verified by the CA (or Enterprise RA). Certificate Issuers were asked to review and provide feedback of their practices in this area. A discussion was undertaken to define commonly used Exetnsions. Doug Beattie proposed an ultimate goal of defining "S/MIME only" certificates - that would eventually deprecate the use of multipurpose certs (in the belief that many of the unusual Subject attributes and Extensions may be related to those alternate use cases rather than the S/MIME use). It was raised that some other use cases can rely upon the emailProtection EKU, such as PDF signing. It was proposed that an eventual CABF WG might be created for document signing but in meantime interested parties such as Adobe should be invited to join or monitor the SMCWG. 7. Any Other Business It was agreed that the December 23, 2020 meeting will be cancelled. 8. Next call The next call will take place on January 6, 2021 at 11:00am Eastern Time. Adjourned -------------- next part -------------- An HTML attachment was scrubbed... URL: From Stephen.Davidson at digicert.com Tue Jan 19 17:45:07 2021 From: Stephen.Davidson at digicert.com (Stephen Davidson) Date: Tue, 19 Jan 2021 17:45:07 +0000 Subject: [Smcwg-public] User Interface for S/MIME Message-ID: Hello: In our recent discussions about S/MIME the question has arisen how Certificate Consumers (i.e., email software) use information from the S/MIME certificate in the user interface. I am hoping that our colleagues at Google, Microsoft, Mozilla/Thunderbird, Zertificon - and others - can provide more information on questions like: * What is the default display for user name in the mailbox for a signed certificate? * What configuration options are available to enterprise users (for example to customize the display of subject identity info)? * Are there options to leverage S/MIME certificate information that may not be displayed (for example to make trust decisions)? If there are pointers/URLs to public information that would be helpful. On a recent call, TeleTrust representatives also voiced a willingness to speak with their members on the subject of how they configured S/MIME or used S/MIME certificate information. That would be useful. Many thanks, Stephen -------------- next part -------------- An HTML attachment was scrubbed... URL: From Stephen.Davidson at digicert.com Tue Jan 19 19:00:30 2021 From: Stephen.Davidson at digicert.com (Stephen Davidson) Date: Tue, 19 Jan 2021 19:00:30 +0000 Subject: [Smcwg-public] Draft SMCWG agenda - Wednesday, January 20, 2021 Message-ID: SMCWG Agenda Draft SMCWG agenda - Wednesday, January 20, 2021 at 11:00 am Eastern Time Here is a draft CA 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 January 6, 2021 5. Continuation of discussion of leaf Certificate Policy types: permissive/legacy versus strict 6. Any other business 7. Next call: February 3, 2021 at 11:00 am Eastern Time Adjourn -------------- next part -------------- An HTML attachment was scrubbed... URL: