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: From Paul.vanBrouwershaven at entrust.com Fri Jan 29 16:12:56 2021 From: Paul.vanBrouwershaven at entrust.com (Paul van Brouwershaven) Date: Fri, 29 Jan 2021 16:12:56 +0000 Subject: [Smcwg-public] CAA and S/MIME In-Reply-To: References: <3c11a9ac-ecdf-bbaa-6d03-9c813baaea9a@trustcorsystems.com>, Message-ID: While the BR only specifies how CAA must be implemented/used for TLS certificates the CAA RFC is not limited to just TLS certificates, the RFC 8659 (and previously RFC 6844) begins with: The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify one or more Certification Authorities (CAs) authorized to issue certificates for that domain name. This does make sense as this would create a `deny all, except` principle where you need to give explicit permission like as in a good firewall configuration. But I agree that there should be a possibility to change permission per certificate type and to drop restrictions where needed (such as for S/MIME with shared mail providers). I'm currently not in favor of having a new S/MIME specific property, and one for client certs, document signing, etc. as where does it stop. It would also not allow to have separate `iodef` settings for example (or only enable them for TLS). We could define one new parameter to define the certificate type, the standard already has a reversed policy property which was used in the draft RFC to limit issuance on policy OID. Rob pointed me at the draft CAA specification that had a policy property value instead of a CA domain name. https://datatracker.ietf.org/doc/html/draft-hallambaker-donotissue-04#section-3.1.2 This could work with cabforum defined OID's, the advantage from using OID's is that it would support an OID prefix, and it would be easier for CAs to enforce. But it's not very user friendly..? This would allow: $ORIGIN example.com . CAA 0 issue "ca1.example.net; policy=2.23.140.1" // Only cabforum . CAA 0 issue "ca2.example.net; policy=2.23.140.1.5" // SMIME . CAA 0 issue "ca3.example.net; policy=2.23.140.1.2" // DV, OV, IV . CAA 0 issue "ca4.example.net; policy=2.23.140.1.1" // EV For user friendliness, we could define a new parameter such as `type` with the same intention but based on a name value: This would allow: $ORIGIN example.com . CAA 0 issue "ca1.example.net" . CAA 0 issue "ca2.example.net; type=smime" . CAA 0 issue "ca3.example.net; type=tls" . CAA 0 issue "ca4.example.net; type=tls-ev" Where: * ca1 could issue any type of certificate not explicitly specified (so no S/MIME, or TLS certificates in this example) * ca2 could issue only smime certificates * ca3 could issue any type of TLS certificate except for EV * ca4 could issue only EV TLS certificates Alternatively, we could define two parameters, one for the certificate type and one for the assurance level, this would give: $ORIGIN example.com . CAA 0 issue "ca1.example.net" . CAA 0 issue "ca2.example.net; type=smime" . CAA 0 issue "ca3.example.net; type=tls" . CAA 0 issue "ca4.example.net; type=tls; level=ev;" The challenge for all these methods is how do we drop CAA limitations, as we want something like: $ORIGIN example.com . CAA 0 issue "ca1.example.net" . CAA 0 issue "*; type=smime" But that is not allowed by the RFC. If we would define a separate property per certificate type but follow the RFC and honoring the inheritance, we would still have the same challenge of stopping the inheritance . $ORIGIN example.com . CAA 0 issue "ca1.example.net" . CAA 0 issuesmime "ca2.example.net" . CAA 0 issuetls "ca3.example.net" . CAA 0 issuetlsev "ca4.example.net" Maybe we could simply create an 'unrestricted' parameter to overrule the RFC?: $ORIGIN example.com . CAA 0 issue "ca1.example.net" . CAA 0 issue "; type=smime; unrestricted=true" Paul ________________________________ From: Smcwg-public on behalf of Tim Hollebeek via Smcwg-public Sent: Monday, October 26, 2020 15:25 To: Neil Dunbar ; SMIME Certificate Working Group Subject: [EXTERNAL]Re: [Smcwg-public] CAA and S/MIME This is how I feel about the issue. CAA is potentially an interesting improvement to the S/MIME ecosystem, but the current tags and implementation were meant for TLS, and shouldn?t be reused. The RFC has an extension mechanism which can easily be used to add new tags for S/MIME issuance, and issuance of other kinds of non-TLS certificates. -Tim From: Smcwg-public On Behalf Of Neil Dunbar via Smcwg-public Sent: Monday, October 26, 2020 6:03 AM To: smcwg-public at cabforum.org Subject: Re: [Smcwg-public] CAA and S/MIME On 24/10/2020 16:21, Stephen Davidson via Smcwg-public wrote: Hello: The topic of Certification Authority Authorisation (CAA) has arisen a number of times in relation to the evolving S/MIME Baseline. I highlight a discussion on that subject related to the Mozilla policy: https://github.com/mozilla/pkipolicy/issues/135 A significant number of email providers ? such as gmail.com, outlook.com, protonmail.com, and others ? have CAA records. Questions for us to address later in our discussions: * Is CAA a desired requirement of the S/MIME Baseline? * Should the S/MIME Baseline rely upon the existing requirements stated in the TLS BR, or is the S/MIME use case sufficiently different to merit a separate CAA tag? Generally, I'm a fan of allowing organisations (however defined) to specify their policy requirements for publicly trusted certificates via CAA records; so I would say "yes", it is a desired requirement of the S/MIME baseline. I would certainly expect it to make its way into the root program requirements at some point, and having a pan-root program consensus on those requirements beats having overlapping or potentially conflicting requirements. That said, I'm not a fan of ninja semantics (changing the meaning of a deployed resource where the deployer might not have considered its eventual full scope) - it seems to me that the "issue" and "issuewild" tags were framed with TLS certificates in mind[*], and I think extending "issue" to cover S/MIME could have effects on domain owners which were not expected. In other words, we would be saying to them that all certificates are hereby covered, without them having any means of expressing the policy "I want CA X to issue TLS certificates, but any CA could issue S/MIME certificates"; so I'm less of a fan of reducing the expressive potential of domain owners. To that extent, I think that I'd prefer tags like "issue-tls", "issue-tls-wildcard", "issue-email", and so on, with similar semantics which work over "issue" and "issuewild" right now. Once those are in effect, then you could extend the "issue" tag to mean "all certificates" as a shorthand, while leaving finer detailed policy expressions. However, that goes further than anything the S/MIME WG could reasonably pronounce upon. But "issue-email" to cover S/MIME certs falls within its charter and seems to have a clearer scope. There's even an opportunity to allow domain owners to specify the validation methods permissible for issuance, but that's a whole different discussion. Just my opinion, of course. Neil [*] Genuine question: would "issuewild" have any meaning outside of TLS certificates? -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim.hollebeek at digicert.com Fri Jan 29 18:18:30 2021 From: tim.hollebeek at digicert.com (Tim Hollebeek) Date: Fri, 29 Jan 2021 18:18:30 +0000 Subject: [Smcwg-public] CAA and S/MIME In-Reply-To: References: <3c11a9ac-ecdf-bbaa-6d03-9c813baaea9a@trustcorsystems.com>, Message-ID: Paul, You might want to review the previous discussions of this issue on MDSP, where it was made pretty clear, including by the author of the RFC, that the "issue" tag was intended to be specific to the web. CAA for certificate type has also been discussed quite a bit here at the Forum recently (it was an idea we introduced about three years ago and were pushing), so you might want to review the long discussion of those proposals and why they didn't move forward. It's not clear why you think there are problems with having both 'issue' and 'issueesmime', especially since your analysis seems to assume that if they're both there, they interact in some way. They should not, and that seems to be the source of the problems you're trying to highlight. What one wants is to be able to clearly state the policy for each ecosystem, without interactions. Interactions between different certificate ecosystems are the cause of most of PKIs problems, and we should be looking to eliminate cross-PKI interactions, not introduce new ones. It's pretty straightforward to do that with a new tag. No additional properties or semantics are required. And the process of adding a new tag is something this group has already successfully done once ("CAA CONTACT"). -Tim From: Paul van Brouwershaven Sent: Friday, January 29, 2021 11:13 AM To: Neil Dunbar ; SMIME Certificate Working Group ; Tim Hollebeek Cc: Kirk Hall Subject: Re: [Smcwg-public] CAA and S/MIME While the BR only specifies how CAA must be implemented/used for TLS certificates the CAA RFC is not limited to just TLS certificates, the RFC 8659 (and previously RFC 6844) begins with: The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify one or more Certification Authorities (CAs) authorized to issue certificates for that domain name. This does make sense as this would create a `deny all, except` principle where you need to give explicit permission like as in a good firewall configuration. But I agree that there should be a possibility to change permission per certificate type and to drop restrictions where needed (such as for S/MIME with shared mail providers). I'm currently not in favor of having a new S/MIME specific property, and one for client certs, document signing, etc. as where does it stop. It would also not allow to have separate `iodef` settings for example (or only enable them for TLS). We could define one new parameter to define the certificate type, the standard already has a reversed policy property which was used in the draft RFC to limit issuance on policy OID. Rob pointed me at the draft CAA specification that had a policy property value instead of a CA domain name. https://datatracker.ietf.org/doc/html/draft-hallambaker-donotissue-04#sectio n-3.1.2 This could work with cabforum defined OID's, the advantage from using OID's is that it would support an OID prefix, and it would be easier for CAs to enforce. But it's not very user friendly..? This would allow: $ORIGIN example.com . CAA 0 issue "ca1.example.net; policy=2.23.140.1" // Only cabforum . CAA 0 issue "ca2.example.net; policy=2.23.140.1.5" // SMIME . CAA 0 issue "ca3.example.net; policy=2.23.140.1.2" // DV, OV, IV . CAA 0 issue "ca4.example.net; policy=2.23.140.1.1" // EV For user friendliness, we could define a new parameter such as `type` with the same intention but based on a name value: This would allow: $ORIGIN example.com . CAA 0 issue "ca1.example.net" . CAA 0 issue "ca2.example.net; type=smime" . CAA 0 issue "ca3.example.net; type=tls" . CAA 0 issue "ca4.example.net; type=tls-ev" Where: * ca1 could issue any type of certificate not explicitly specified (so no S/MIME, or TLS certificates in this example) * ca2 could issue only smime certificates * ca3 could issue any type of TLS certificate except for EV * ca4 could issue only EV TLS certificates Alternatively, we could define two parameters, one for the certificate type and one for the assurance level, this would give: $ORIGIN example.com . CAA 0 issue "ca1.example.net" . CAA 0 issue "ca2.example.net; type=smime" . CAA 0 issue "ca3.example.net; type=tls" . CAA 0 issue "ca4.example.net; type=tls; level=ev;" The challenge for all these methods is how do we drop CAA limitations, as we want something like: $ORIGIN example.com . CAA 0 issue "ca1.example.net" . CAA 0 issue "*; type=smime" But that is not allowed by the RFC. If we would define a separate property per certificate type but follow the RFC and honoring the inheritance, we would still have the same challenge of stopping the inheritance . $ORIGIN example.com . CAA 0 issue "ca1.example.net" . CAA 0 issuesmime "ca2.example.net" . CAA 0 issuetls "ca3.example.net" . CAA 0 issuetlsev "ca4.example.net" Maybe we could simply create an 'unrestricted' parameter to overrule the RFC?: $ORIGIN example.com . CAA 0 issue "ca1.example.net" . CAA 0 issue "; type=smime; unrestricted=true" Paul _____ From: Smcwg-public > on behalf of Tim Hollebeek via Smcwg-public > Sent: Monday, October 26, 2020 15:25 To: Neil Dunbar >; SMIME Certificate Working Group > Subject: [EXTERNAL]Re: [Smcwg-public] CAA and S/MIME This is how I feel about the issue. CAA is potentially an interesting improvement to the S/MIME ecosystem, but the current tags and implementation were meant for TLS, and shouldn't be reused. The RFC has an extension mechanism which can easily be used to add new tags for S/MIME issuance, and issuance of other kinds of non-TLS certificates. -Tim From: Smcwg-public > On Behalf Of Neil Dunbar via Smcwg-public Sent: Monday, October 26, 2020 6:03 AM To: smcwg-public at cabforum.org Subject: Re: [Smcwg-public] CAA and S/MIME On 24/10/2020 16:21, Stephen Davidson via Smcwg-public wrote: Hello: The topic of Certification Authority Authorisation (CAA) has arisen a number of times in relation to the evolving S/MIME Baseline. I highlight a discussion on that subject related to the Mozilla policy: https://github.com/mozilla/pkipolicy/issues/135 A significant number of email providers - such as gmail.com, outlook.com, protonmail.com, and others - have CAA records. Questions for us to address later in our discussions: * Is CAA a desired requirement of the S/MIME Baseline? * Should the S/MIME Baseline rely upon the existing requirements stated in the TLS BR, or is the S/MIME use case sufficiently different to merit a separate CAA tag? Generally, I'm a fan of allowing organisations (however defined) to specify their policy requirements for publicly trusted certificates via CAA records; so I would say "yes", it is a desired requirement of the S/MIME baseline. I would certainly expect it to make its way into the root program requirements at some point, and having a pan-root program consensus on those requirements beats having overlapping or potentially conflicting requirements. That said, I'm not a fan of ninja semantics (changing the meaning of a deployed resource where the deployer might not have considered its eventual full scope) - it seems to me that the "issue" and "issuewild" tags were framed with TLS certificates in mind[*], and I think extending "issue" to cover S/MIME could have effects on domain owners which were not expected. In other words, we would be saying to them that all certificates are hereby covered, without them having any means of expressing the policy "I want CA X to issue TLS certificates, but any CA could issue S/MIME certificates"; so I'm less of a fan of reducing the expressive potential of domain owners. To that extent, I think that I'd prefer tags like "issue-tls", "issue-tls-wildcard", "issue-email", and so on, with similar semantics which work over "issue" and "issuewild" right now. Once those are in effect, then you could extend the "issue" tag to mean "all certificates" as a shorthand, while leaving finer detailed policy expressions. However, that goes further than anything the S/MIME WG could reasonably pronounce upon. But "issue-email" to cover S/MIME certs falls within its charter and seems to have a clearer scope. There's even an opportunity to allow domain owners to specify the validation methods permissible for issuance, but that's a whole different discussion. Just my opinion, of course. Neil [*] Genuine question: would "issuewild" have any meaning outside of TLS certificates? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4940 bytes Desc: not available URL: From Paul.vanBrouwershaven at entrust.com Fri Jan 29 19:08:13 2021 From: Paul.vanBrouwershaven at entrust.com (Paul van Brouwershaven) Date: Fri, 29 Jan 2021 19:08:13 +0000 Subject: [Smcwg-public] CAA and S/MIME In-Reply-To: References: <3c11a9ac-ecdf-bbaa-6d03-9c813baaea9a@trustcorsystems.com>, , Message-ID: Do I understand you correctly that in your opinion domain name owners should not have the ability to restrict all certificate issuance with a single record? I don't think we can expect that a domain name owner would add CAA records for every ecosystem (if they even know about there existence) because these ecosystems want to be independent. If you have a link to the relevant discussion on MDSP that would be great! ________________________________ From: Tim Hollebeek Sent: Friday, 29 January 2021, 19:18 To: Paul van Brouwershaven; Neil Dunbar; SMIME Certificate Working Group Cc: Kirk Hall Subject: [EXTERNAL] RE: [Smcwg-public] CAA and S/MIME WARNING: This email originated outside of Entrust. DO NOT CLICK links or attachments unless you trust the sender and know the content is safe. Paul, You might want to review the previous discussions of this issue on MDSP, where it was made pretty clear, including by the author of the RFC, that the ?issue? tag was intended to be specific to the web. CAA for certificate type has also been discussed quite a bit here at the Forum recently (it was an idea we introduced about three years ago and were pushing), so you might want to review the long discussion of those proposals and why they didn?t move forward. It?s not clear why you think there are problems with having both ?issue? and ?issueesmime?, especially since your analysis seems to assume that if they?re both there, they interact in some way. They should not, and that seems to be the source of the problems you?re trying to highlight. What one wants is to be able to clearly state the policy for each ecosystem, without interactions. Interactions between different certificate ecosystems are the cause of most of PKIs problems, and we should be looking to eliminate cross-PKI interactions, not introduce new ones. It?s pretty straightforward to do that with a new tag. No additional properties or semantics are required. And the process of adding a new tag is something this group has already successfully done once (?CAA CONTACT?). -Tim From: Paul van Brouwershaven Sent: Friday, January 29, 2021 11:13 AM To: Neil Dunbar ; SMIME Certificate Working Group ; Tim Hollebeek Cc: Kirk Hall Subject: Re: [Smcwg-public] CAA and S/MIME While the BR only specifies how CAA must be implemented/used for TLS certificates the CAA RFC is not limited to just TLS certificates, the RFC 8659 (and previously RFC 6844) begins with: The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify one or more Certification Authorities (CAs) authorized to issue certificates for that domain name. This does make sense as this would create a `deny all, except` principle where you need to give explicit permission like as in a good firewall configuration. But I agree that there should be a possibility to change permission per certificate type and to drop restrictions where needed (such as for S/MIME with shared mail providers). I'm currently not in favor of having a new S/MIME specific property, and one for client certs, document signing, etc. as where does it stop. It would also not allow to have separate `iodef` settings for example (or only enable them for TLS). We could define one new parameter to define the certificate type, the standard already has a reversed policy property which was used in the draft RFC to limit issuance on policy OID. Rob pointed me at the draft CAA specification that had a policy property value instead of a CA domain name. https://datatracker.ietf.org/doc/html/draft-hallambaker-donotissue-04#section-3.1.2 This could work with cabforum defined OID's, the advantage from using OID's is that it would support an OID prefix, and it would be easier for CAs to enforce. But it's not very user friendly..? This would allow: $ORIGIN example.com . CAA 0 issue "ca1.example.net; policy=2.23.140.1" // Only cabforum . CAA 0 issue "ca2.example.net; policy=2.23.140.1.5" // SMIME . CAA 0 issue "ca3.example.net; policy=2.23.140.1.2" // DV, OV, IV . CAA 0 issue "ca4.example.net; policy=2.23.140.1.1" // EV For user friendliness, we could define a new parameter such as `type` with the same intention but based on a name value: This would allow: $ORIGIN example.com . CAA 0 issue "ca1.example.net" . CAA 0 issue "ca2.example.net; type=smime" . CAA 0 issue "ca3.example.net; type=tls" . CAA 0 issue "ca4.example.net; type=tls-ev" Where: ? ca1 could issue any type of certificate not explicitly specified (so no S/MIME, or TLS certificates in this example) ? ca2 could issue only smime certificates ? ca3 could issue any type of TLS certificate except for EV ? ca4 could issue only EV TLS certificates Alternatively, we could define two parameters, one for the certificate type and one for the assurance level, this would give: $ORIGIN example.com . CAA 0 issue "ca1.example.net" . CAA 0 issue "ca2.example.net; type=smime" . CAA 0 issue "ca3.example.net; type=tls" . CAA 0 issue "ca4.example.net; type=tls; level=ev;" The challenge for all these methods is how do we drop CAA limitations, as we want something like: $ORIGIN example.com . CAA 0 issue "ca1.example.net" . CAA 0 issue "*; type=smime" But that is not allowed by the RFC. If we would define a separate property per certificate type but follow the RFC and honoring the inheritance, we would still have the same challenge of stopping the inheritance . $ORIGIN example.com . CAA 0 issue "ca1.example.net" . CAA 0 issuesmime "ca2.example.net" . CAA 0 issuetls "ca3.example.net" . CAA 0 issuetlsev "ca4.example.net" Maybe we could simply create an 'unrestricted' parameter to overrule the RFC?: $ORIGIN example.com . CAA 0 issue "ca1.example.net" . CAA 0 issue "; type=smime; unrestricted=true" Paul ________________________________ From: Smcwg-public > on behalf of Tim Hollebeek via Smcwg-public > Sent: Monday, October 26, 2020 15:25 To: Neil Dunbar >; SMIME Certificate Working Group > Subject: [EXTERNAL]Re: [Smcwg-public] CAA and S/MIME This is how I feel about the issue. CAA is potentially an interesting improvement to the S/MIME ecosystem, but the current tags and implementation were meant for TLS, and shouldn?t be reused. The RFC has an extension mechanism which can easily be used to add new tags for S/MIME issuance, and issuance of other kinds of non-TLS certificates. -Tim From: Smcwg-public > On Behalf Of Neil Dunbar via Smcwg-public Sent: Monday, October 26, 2020 6:03 AM To: smcwg-public at cabforum.org Subject: Re: [Smcwg-public] CAA and S/MIME On 24/10/2020 16:21, Stephen Davidson via Smcwg-public wrote: Hello: The topic of Certification Authority Authorisation (CAA) has arisen a number of times in relation to the evolving S/MIME Baseline. I highlight a discussion on that subject related to the Mozilla policy: https://github.com/mozilla/pkipolicy/issues/135 A significant number of email providers ? such as gmail.com, outlook.com, protonmail.com, and others ? have CAA records. Questions for us to address later in our discussions: * Is CAA a desired requirement of the S/MIME Baseline? * Should the S/MIME Baseline rely upon the existing requirements stated in the TLS BR, or is the S/MIME use case sufficiently different to merit a separate CAA tag? Generally, I'm a fan of allowing organisations (however defined) to specify their policy requirements for publicly trusted certificates via CAA records; so I would say "yes", it is a desired requirement of the S/MIME baseline. I would certainly expect it to make its way into the root program requirements at some point, and having a pan-root program consensus on those requirements beats having overlapping or potentially conflicting requirements. That said, I'm not a fan of ninja semantics (changing the meaning of a deployed resource where the deployer might not have considered its eventual full scope) - it seems to me that the "issue" and "issuewild" tags were framed with TLS certificates in mind[*], and I think extending "issue" to cover S/MIME could have effects on domain owners which were not expected. In other words, we would be saying to them that all certificates are hereby covered, without them having any means of expressing the policy "I want CA X to issue TLS certificates, but any CA could issue S/MIME certificates"; so I'm less of a fan of reducing the expressive potential of domain owners. To that extent, I think that I'd prefer tags like "issue-tls", "issue-tls-wildcard", "issue-email", and so on, with similar semantics which work over "issue" and "issuewild" right now. Once those are in effect, then you could extend the "issue" tag to mean "all certificates" as a shorthand, while leaving finer detailed policy expressions. However, that goes further than anything the S/MIME WG could reasonably pronounce upon. But "issue-email" to cover S/MIME certs falls within its charter and seems to have a clearer scope. There's even an opportunity to allow domain owners to specify the validation methods permissible for issuance, but that's a whole different discussion. Just my opinion, of course. Neil [*] Genuine question: would "issuewild" have any meaning outside of TLS certificates? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dzacharo at harica.gr Sat Jan 30 06:57:34 2021 From: dzacharo at harica.gr (Dimitris Zacharopoulos (HARICA)) Date: Sat, 30 Jan 2021 08:57:34 +0200 Subject: [Smcwg-public] CAA and S/MIME In-Reply-To: <010001774f8bdd4b-ef868c77-9dc5-409e-9746-32f7160a1b9e-000000@email.amazonses.com> References: <3c11a9ac-ecdf-bbaa-6d03-9c813baaea9a@trustcorsystems.com> <010001774f8bdd4b-ef868c77-9dc5-409e-9746-32f7160a1b9e-000000@email.amazonses.com> Message-ID: <2e6bb2af-3931-b391-603c-a5de9ead7b1f@harica.gr> I also believe that Domain Name owners should have a different tag per certificate type. It doesn't make sense to have a "one tag to rule them all". So, if an owner wants to restrict ALL certificate issuance to one CA for TLS and S/MIME, two CAA records would need to be added. Dimitris. On 29/1/2021 9:08 ?.?., Paul van Brouwershaven via Smcwg-public wrote: > Do I understand you correctly that in your opinion domain name owners > should not have the ability to restrict all certificate issuance with > a single record? > > I don't think we can expect that a domain name owner would add CAA > records for every ecosystem (if they even know about there existence) > because these ecosystems want to be independent. > > If you have a link to the relevant discussion on MDSP that would be great! > > ------------------------------------------------------------------------ > *From:* Tim Hollebeek > *Sent:* Friday, 29 January 2021, 19:18 > *To:* Paul van Brouwershaven; Neil Dunbar; SMIME Certificate Working Group > *Cc:* Kirk Hall > *Subject:* [EXTERNAL] RE: [Smcwg-public] CAA and S/MIME > > WARNING: This email originated outside of Entrust. > DO NOT CLICK links or attachments unless you trust the sender and know > the content is safe. > > Paul, > > You might want to review the previous discussions of this issue on > MDSP, where it was made pretty clear, including by the author of the > RFC, that the ?issue? tag was intended to be specific to the web.? CAA > for certificate type has also been discussed quite a bit here at the > Forum recently (it was an idea we introduced about three years ago and > were pushing), so you might want to review the long discussion of > those proposals and why they didn?t move forward. > > It?s not clear why you think there are problems with having both > ?issue? and ?issueesmime?, especially since your analysis seems to > assume that if they?re both there, they interact in some way.? They > should not, and that seems to be the source of the problems you?re > trying to highlight. > > What one wants is to be able to clearly state the policy for each > ecosystem, without interactions. Interactions between different > certificate ecosystems are the cause of most of PKIs problems, and we > should be looking to eliminate cross-PKI interactions, not introduce > new ones. > > It?s pretty straightforward to do that with a new tag.? No additional > properties or semantics are required.? And the process of adding a new > tag is something this group has already successfully done once (?CAA > CONTACT?). > > -Tim > > *From:* Paul van Brouwershaven > *Sent:* Friday, January 29, 2021 11:13 AM > *To:* Neil Dunbar ; SMIME Certificate > Working Group ; Tim Hollebeek > > *Cc:* Kirk Hall > *Subject:* Re: [Smcwg-public] CAA and S/MIME > > While the BR only specifies how CAA must be implemented/used for TLS > certificates the CAA RFC is not limited to just TLS certificates, the > RFC 8659 (and previously RFC 6844) begins with: > > The Certification Authority Authorization (CAA) DNS Resource Record > > ? ?allows a DNS domain name holder to specify one or more > Certification > > ? ?Authorities (CAs) authorized to issue certificates for that domain > > ? ?name. > > This does make sense as this would create a `deny all, except` > principle where you need to give explicit permission like as in a good > firewall configuration. But I agree that there should be a possibility > to change permission per certificate type and to drop restrictions > where needed (such as for S/MIME with shared mail providers). > > I'm currently not in favor of having a new S/MIME specific property, > and one for client certs, document signing, etc. as where does it > stop. It would also not allow to have separate `iodef` settings for > example (or only enable them for TLS). > > We could define one new parameter to define the certificate type, the > standard already has a reversed policy property which was used in the > draft RFC to limit issuance on policy OID. Rob pointed me at the draft > CAA specification that had a?policy property value instead of a CA > domain name. > > https://datatracker.ietf.org/doc/html/draft-hallambaker-donotissue-04#section-3.1.2 > > > This could work with cabforum defined OID's, the advantage from using > OID's is that it would support an OID prefix, and it would be easier > for CAs to enforce. But it's not very user friendly..? > > This would allow: > > ? ?$ORIGIN example.com > ? ?. ? ? ? CAA 0 issue "ca1.example.net; policy=2.23.140.1"?? // Only > cabforum > ? ?. ? ? ? CAA 0 issue "ca2.example.net; policy=2.23.140.1.5" // SMIME > ? ?. ? ? ? CAA 0 issue "ca3.example.net; policy=2.23.140.1.2" // DV, > OV, IV > ? ?. ? ? ? CAA 0 issue "ca4.example.net; policy=2.23.140.1.1" // EV > > For user friendliness, we could define a new parameter such as `type` > with the same intention but based on a name value: > > This would allow: > > ? ?$ORIGIN example.com > ? ?. ? ? ? CAA 0 issue "ca1.example.net" > ? ?. ? ? ? CAA 0 issue "ca2.example.net; type=smime" > ? ?. ? ? ? CAA 0 issue "ca3.example.net; type=tls" > ? ?. ? ? ? CAA 0 issue "ca4.example.net; type=tls-ev" > Where: > ?ca1 could issue any type of certificate not explicitly specified (so > no S/MIME, or TLS certificates in this example) > ?ca2 could issue only smime certificates > ?ca3 could issue any type of TLS certificate except for EV > ?ca4 could issue only EV TLS certificates > > Alternatively, we could define two parameters, one for the certificate > type and one for the assurance level, this would give: > > ? ?$ORIGIN example.com > ? ?. ? ? ? CAA 0 issue "ca1.example.net" > ? ?. ? ? ? CAA 0 issue "ca2.example.net; type=smime" > ? ?. ? ? ? CAA 0 issue "ca3.example.net; type=tls" > ? ?. ? ? ? CAA 0 issue "ca4.example.net; type=tls; level=ev;" > > The challenge for all these methods is how do we drop CAA limitations, > as we want something like: > > ? ?$ORIGIN example.com > ? ?. ? ? ? CAA 0 issue "ca1.example.net" > ? ?. ? ? ? CAA 0 issue "*; type=smime" > But that is not allowed by the RFC. > > If we would define a separate property per certificate type but follow > the RFC and honoring the inheritance, we would still have the same > challenge of stopping the inheritance . > > ? ?$ORIGIN example.com > ? ?. ? ? ? CAA 0 issue "ca1.example.net" > ? ?. ? ? ? CAA 0 issuesmime "ca2.example.net" > ? ?. ? ? ? CAA 0 issuetls "ca3.example.net" > ? ?. ? ? ? CAA 0 issuetlsev "ca4.example.net" > > Maybe we could simply create an 'unrestricted' parameter to overrule > the RFC?: > > ? ?$ORIGIN example.com > ? ?. ? ? ? CAA 0 issue "ca1.example.net" > ? ?. ? ? ? CAA 0 issue "; type=smime; unrestricted=true" > > > Paul > > ------------------------------------------------------------------------ > > *From:*Smcwg-public > on behalf of Tim Hollebeek > via Smcwg-public > > *Sent:* Monday, October 26, 2020 15:25 > *To:* Neil Dunbar >; SMIME Certificate Working Group > > > *Subject:* [EXTERNAL]Re: [Smcwg-public] CAA and S/MIME > > This is how I feel about the issue.? CAA is potentially an interesting > improvement to the S/MIME ecosystem, but the current tags and > implementation were meant for TLS, and shouldn?t be reused. > > The RFC has an extension mechanism which can easily be used to add new > tags for S/MIME issuance, and issuance of other kinds of non-TLS > certificates. > > -Tim > > *From:* Smcwg-public > *On Behalf Of *Neil Dunbar > via Smcwg-public > *Sent:* Monday, October 26, 2020 6:03 AM > *To:* smcwg-public at cabforum.org > *Subject:* Re: [Smcwg-public] CAA and S/MIME > > On 24/10/2020 16:21, Stephen Davidson via Smcwg-public wrote: > > Hello: > > The topic of Certification Authority Authorisation (CAA) has > arisen a number of times in relation to the evolving S/MIME Baseline. > > I highlight a discussion on that subject related to the Mozilla > policy: https://github.com/mozilla/pkipolicy/issues/135 > > > A significant number of email providers ? such as gmail.com, > outlook.com, protonmail.com, and others ? have CAA records. > > > Questions for us to address later in our discussions: > > * Is CAA a desired requirement of the S/MIME Baseline? > * Should the S/MIME Baseline rely upon the existing requirements > stated in the TLS BR, or is the S/MIME use case sufficiently > different to merit a separate CAA tag? > > Generally, I'm a fan of allowing organisations (however defined) to > specify their policy requirements for publicly trusted certificates > via CAA records; so I would say "yes", it is a desired requirement of > the S/MIME baseline. I would certainly expect it to make its way into > the root program requirements at some point, and having a pan-root > program consensus on those requirements beats having overlapping or > potentially conflicting requirements. > > That said, I'm not a fan of ninja semantics (changing the meaning of a > deployed resource where the deployer might not have considered its > eventual full scope) - it seems to me that the "issue" and "issuewild" > tags were framed with TLS certificates in mind[*], and I think > extending "issue" to cover S/MIME could have effects on domain owners > which were not expected. In other words, we would be saying to them > that all certificates are hereby covered, without them having any > means of expressing the policy "I want CA X to issue TLS certificates, > but any CA could issue S/MIME certificates"; so I'm less of a fan of > reducing the expressive potential of domain owners. > > To that extent, I think that I'd prefer tags like "issue-tls", > "issue-tls-wildcard", "issue-email", and so on, with similar semantics > which work over "issue" and "issuewild" right now. Once those are in > effect, then you could extend the "issue" tag to mean "all > certificates" as a shorthand, while leaving finer detailed policy > expressions. However, that goes further than anything the S/MIME WG > could reasonably pronounce upon. But "issue-email" to cover S/MIME > certs falls within its charter and seems to have a clearer scope. > There's even an opportunity to allow domain owners to specify the > validation methods permissible for issuance, but that's a whole > different discussion. > > Just my opinion, of course. > > Neil > > [*] Genuine question: would "issuewild" have any meaning outside of > TLS certificates? > > > > _______________________________________________ > 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 Paul.vanBrouwershaven at entrust.com Sat Jan 30 07:23:35 2021 From: Paul.vanBrouwershaven at entrust.com (Paul van Brouwershaven) Date: Sat, 30 Jan 2021 07:23:35 +0000 Subject: [Smcwg-public] [EXTERNAL] Re: CAA and S/MIME In-Reply-To: <2e6bb2af-3931-b391-603c-a5de9ead7b1f@harica.gr> References: <3c11a9ac-ecdf-bbaa-6d03-9c813baaea9a@trustcorsystems.com> <010001774f8bdd4b-ef868c77-9dc5-409e-9746-32f7160a1b9e-000000@email.amazonses.com>, <2e6bb2af-3931-b391-603c-a5de9ead7b1f@harica.gr> Message-ID: Looking at it from a commercial point of view I get the interest to separate all type of certificates (everything that prevents issuance costs money). From a security point of view it's sounds like a firewall that only allows me to block known issues. As in your firewall, you want to deny all and then start allowing what should pas through. Allowing something new could be a internal request like you would for for all dns records (like you also do not give the whole company access to your dns system or your firewall and most corporate devices don't allow users to install any applications without prior approval). If you let everything though you are out of control. Like in the early days of the internet we worked with block lists. Today everything is based on permit list, including SPF, DKIM and actually the CAA RFC. Should we not focus on security and control above convenience and commercial interest? Sent from my mobile device. ________________________________ From: Dimitris Zacharopoulos (HARICA) Sent: Saturday, January 30, 2021 7:57:34 AM To: Paul van Brouwershaven ; SMIME Certificate Working Group ; Tim Hollebeek ; Neil Dunbar Cc: Kirk Hall Subject: [EXTERNAL] Re: [Smcwg-public] CAA and S/MIME WARNING: This email originated outside of Entrust. DO NOT CLICK links or attachments unless you trust the sender and know the content is safe. I also believe that Domain Name owners should have a different tag per certificate type. It doesn't make sense to have a "one tag to rule them all". So, if an owner wants to restrict ALL certificate issuance to one CA for TLS and S/MIME, two CAA records would need to be added. Dimitris. On 29/1/2021 9:08 ?.?., Paul van Brouwershaven via Smcwg-public wrote: Do I understand you correctly that in your opinion domain name owners should not have the ability to restrict all certificate issuance with a single record? I don't think we can expect that a domain name owner would add CAA records for every ecosystem (if they even know about there existence) because these ecosystems want to be independent. If you have a link to the relevant discussion on MDSP that would be great! ________________________________ From: Tim Hollebeek Sent: Friday, 29 January 2021, 19:18 To: Paul van Brouwershaven; Neil Dunbar; SMIME Certificate Working Group Cc: Kirk Hall Subject: [EXTERNAL] RE: [Smcwg-public] CAA and S/MIME WARNING: This email originated outside of Entrust. DO NOT CLICK links or attachments unless you trust the sender and know the content is safe. Paul, You might want to review the previous discussions of this issue on MDSP, where it was made pretty clear, including by the author of the RFC, that the ?issue? tag was intended to be specific to the web. CAA for certificate type has also been discussed quite a bit here at the Forum recently (it was an idea we introduced about three years ago and were pushing), so you might want to review the long discussion of those proposals and why they didn?t move forward. It?s not clear why you think there are problems with having both ?issue? and ?issueesmime?, especially since your analysis seems to assume that if they?re both there, they interact in some way. They should not, and that seems to be the source of the problems you?re trying to highlight. What one wants is to be able to clearly state the policy for each ecosystem, without interactions. Interactions between different certificate ecosystems are the cause of most of PKIs problems, and we should be looking to eliminate cross-PKI interactions, not introduce new ones. It?s pretty straightforward to do that with a new tag. No additional properties or semantics are required. And the process of adding a new tag is something this group has already successfully done once (?CAA CONTACT?). -Tim From: Paul van Brouwershaven Sent: Friday, January 29, 2021 11:13 AM To: Neil Dunbar ; SMIME Certificate Working Group ; Tim Hollebeek Cc: Kirk Hall Subject: Re: [Smcwg-public] CAA and S/MIME While the BR only specifies how CAA must be implemented/used for TLS certificates the CAA RFC is not limited to just TLS certificates, the RFC 8659 (and previously RFC 6844) begins with: The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify one or more Certification Authorities (CAs) authorized to issue certificates for that domain name. This does make sense as this would create a `deny all, except` principle where you need to give explicit permission like as in a good firewall configuration. But I agree that there should be a possibility to change permission per certificate type and to drop restrictions where needed (such as for S/MIME with shared mail providers). I'm currently not in favor of having a new S/MIME specific property, and one for client certs, document signing, etc. as where does it stop. It would also not allow to have separate `iodef` settings for example (or only enable them for TLS). We could define one new parameter to define the certificate type, the standard already has a reversed policy property which was used in the draft RFC to limit issuance on policy OID. Rob pointed me at the draft CAA specification that had a policy property value instead of a CA domain name. https://datatracker.ietf.org/doc/html/draft-hallambaker-donotissue-04#section-3.1.2 This could work with cabforum defined OID's, the advantage from using OID's is that it would support an OID prefix, and it would be easier for CAs to enforce. But it's not very user friendly..? This would allow: $ORIGIN example.com . CAA 0 issue "ca1.example.net; policy=2.23.140.1" // Only cabforum . CAA 0 issue "ca2.example.net; policy=2.23.140.1.5" // SMIME . CAA 0 issue "ca3.example.net; policy=2.23.140.1.2" // DV, OV, IV . CAA 0 issue "ca4.example.net; policy=2.23.140.1.1" // EV For user friendliness, we could define a new parameter such as `type` with the same intention but based on a name value: This would allow: $ORIGIN example.com . CAA 0 issue "ca1.example.net" . CAA 0 issue "ca2.example.net; type=smime" . CAA 0 issue "ca3.example.net; type=tls" . CAA 0 issue "ca4.example.net; type=tls-ev" Where: ? ca1 could issue any type of certificate not explicitly specified (so no S/MIME, or TLS certificates in this example) ? ca2 could issue only smime certificates ? ca3 could issue any type of TLS certificate except for EV ? ca4 could issue only EV TLS certificates Alternatively, we could define two parameters, one for the certificate type and one for the assurance level, this would give: $ORIGIN example.com . CAA 0 issue "ca1.example.net" . CAA 0 issue "ca2.example.net; type=smime" . CAA 0 issue "ca3.example.net; type=tls" . CAA 0 issue "ca4.example.net; type=tls; level=ev;" The challenge for all these methods is how do we drop CAA limitations, as we want something like: $ORIGIN example.com . CAA 0 issue "ca1.example.net" . CAA 0 issue "*; type=smime" But that is not allowed by the RFC. If we would define a separate property per certificate type but follow the RFC and honoring the inheritance, we would still have the same challenge of stopping the inheritance . $ORIGIN example.com . CAA 0 issue "ca1.example.net" . CAA 0 issuesmime "ca2.example.net" . CAA 0 issuetls "ca3.example.net" . CAA 0 issuetlsev "ca4.example.net" Maybe we could simply create an 'unrestricted' parameter to overrule the RFC?: $ORIGIN example.com . CAA 0 issue "ca1.example.net" . CAA 0 issue "; type=smime; unrestricted=true" Paul ________________________________ From: Smcwg-public > on behalf of Tim Hollebeek via Smcwg-public > Sent: Monday, October 26, 2020 15:25 To: Neil Dunbar >; SMIME Certificate Working Group > Subject: [EXTERNAL]Re: [Smcwg-public] CAA and S/MIME This is how I feel about the issue. CAA is potentially an interesting improvement to the S/MIME ecosystem, but the current tags and implementation were meant for TLS, and shouldn?t be reused. The RFC has an extension mechanism which can easily be used to add new tags for S/MIME issuance, and issuance of other kinds of non-TLS certificates. -Tim From: Smcwg-public > On Behalf Of Neil Dunbar via Smcwg-public Sent: Monday, October 26, 2020 6:03 AM To: smcwg-public at cabforum.org Subject: Re: [Smcwg-public] CAA and S/MIME On 24/10/2020 16:21, Stephen Davidson via Smcwg-public wrote: Hello: The topic of Certification Authority Authorisation (CAA) has arisen a number of times in relation to the evolving S/MIME Baseline. I highlight a discussion on that subject related to the Mozilla policy: https://github.com/mozilla/pkipolicy/issues/135 A significant number of email providers ? such as gmail.com, outlook.com, protonmail.com, and others ? have CAA records. Questions for us to address later in our discussions: * Is CAA a desired requirement of the S/MIME Baseline? * Should the S/MIME Baseline rely upon the existing requirements stated in the TLS BR, or is the S/MIME use case sufficiently different to merit a separate CAA tag? Generally, I'm a fan of allowing organisations (however defined) to specify their policy requirements for publicly trusted certificates via CAA records; so I would say "yes", it is a desired requirement of the S/MIME baseline. I would certainly expect it to make its way into the root program requirements at some point, and having a pan-root program consensus on those requirements beats having overlapping or potentially conflicting requirements. That said, I'm not a fan of ninja semantics (changing the meaning of a deployed resource where the deployer might not have considered its eventual full scope) - it seems to me that the "issue" and "issuewild" tags were framed with TLS certificates in mind[*], and I think extending "issue" to cover S/MIME could have effects on domain owners which were not expected. In other words, we would be saying to them that all certificates are hereby covered, without them having any means of expressing the policy "I want CA X to issue TLS certificates, but any CA could issue S/MIME certificates"; so I'm less of a fan of reducing the expressive potential of domain owners. To that extent, I think that I'd prefer tags like "issue-tls", "issue-tls-wildcard", "issue-email", and so on, with similar semantics which work over "issue" and "issuewild" right now. Once those are in effect, then you could extend the "issue" tag to mean "all certificates" as a shorthand, while leaving finer detailed policy expressions. However, that goes further than anything the S/MIME WG could reasonably pronounce upon. But "issue-email" to cover S/MIME certs falls within its charter and seems to have a clearer scope. There's even an opportunity to allow domain owners to specify the validation methods permissible for issuance, but that's a whole different discussion. Just my opinion, of course. Neil [*] Genuine question: would "issuewild" have any meaning outside of TLS certificates? _______________________________________________ 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 dzacharo at harica.gr Sat Jan 30 08:57:40 2021 From: dzacharo at harica.gr (Dimitris Zacharopoulos (HARICA)) Date: Sat, 30 Jan 2021 10:57:40 +0200 Subject: [Smcwg-public] [EXTERNAL] Re: CAA and S/MIME In-Reply-To: References: <3c11a9ac-ecdf-bbaa-6d03-9c813baaea9a@trustcorsystems.com> <010001774f8bdd4b-ef868c77-9dc5-409e-9746-32f7160a1b9e-000000@email.amazonses.com> <2e6bb2af-3931-b391-603c-a5de9ead7b1f@harica.gr> Message-ID: <884ef387-c76f-15f9-a2d1-02097d597887@harica.gr> Not having these CAA records is a permission to issue. No DNS access is required to adjust anything. If a concerned Domain Name owner wants to use CAA to restrict issuance to a specific set of CAs, they better know what they're doing because it might disable their ability to get publicly trusted certificates. It's just like setting up SPF/DKIM (the mail system works fine without it). The mail admin should know what to do otherwise mails might be lost if something is not configured properly. Dimitris. On 30/1/2021 9:23 ?.?., Paul van Brouwershaven wrote: > Looking at it from a commercial point of view I get the interest to > separate all type of certificates (everything that prevents issuance > costs money). From a security point of view it's sounds like a > firewall that only allows me to block known issues. > > As in your firewall, you want to deny all and then start allowing what > should pas through. > > Allowing something new could be a internal request like you would for > for all dns records (like you also do not give the whole company > access to your dns system or your firewall and most corporate devices > don't allow users to install any applications without prior approval). > > If you let everything though you are out of control. Like in the early > days of the internet we worked with block lists. Today everything is > based on permit list, including SPF, DKIM and actually the CAA RFC. > > Should we not focus on security and control above convenience and > commercial interest? > > Sent from my mobile device. > ------------------------------------------------------------------------ > *From:* Dimitris Zacharopoulos (HARICA) > *Sent:* Saturday, January 30, 2021 7:57:34 AM > *To:* Paul van Brouwershaven ; > SMIME Certificate Working Group ; Tim > Hollebeek ; Neil Dunbar > > *Cc:* Kirk Hall > *Subject:* [EXTERNAL] Re: [Smcwg-public] CAA and S/MIME > WARNING: This email originated outside of Entrust. > DO NOT CLICK links or attachments unless you trust the sender and know > the content is safe. > I also believe that Domain Name owners should have a different tag per > certificate type. It doesn't make sense to have a "one tag to rule > them all". > > So, if an owner wants to restrict ALL certificate issuance to one CA > for TLS and S/MIME, two CAA records would need to be added. > > > Dimitris. > > On 29/1/2021 9:08 ?.?., Paul van Brouwershaven via Smcwg-public wrote: >> Do I understand you correctly that in your opinion domain name owners >> should not have the ability to restrict all certificate issuance with >> a single record? >> >> I don't think we can expect that a domain name owner would add CAA >> records for every ecosystem (if they even know about there existence) >> because these ecosystems want to be independent. >> >> If you have a link to the relevant discussion on MDSP that would be >> great! >> >> ------------------------------------------------------------------------ >> *From:* Tim Hollebeek >> >> *Sent:* Friday, 29 January 2021, 19:18 >> *To:* Paul van Brouwershaven; Neil Dunbar; SMIME Certificate Working >> Group >> *Cc:* Kirk Hall >> *Subject:* [EXTERNAL] RE: [Smcwg-public] CAA and S/MIME >> >> WARNING: This email originated outside of Entrust. >> DO NOT CLICK links or attachments unless you trust the sender and >> know the content is safe. >> >> Paul, >> >> You might want to review the previous discussions of this issue on >> MDSP, where it was made pretty clear, including by the author of the >> RFC, that the ?issue? tag was intended to be specific to the web.? >> CAA for certificate type has also been discussed quite a bit here at >> the Forum recently (it was an idea we introduced about three years >> ago and were pushing), so you might want to review the long >> discussion of those proposals and why they didn?t move forward. >> >> It?s not clear why you think there are problems with having both >> ?issue? and ?issueesmime?, especially since your analysis seems to >> assume that if they?re both there, they interact in some way.? They >> should not, and that seems to be the source of the problems you?re >> trying to highlight. >> >> What one wants is to be able to clearly state the policy for each >> ecosystem, without interactions.? Interactions between different >> certificate ecosystems are the cause of most of PKIs problems, and we >> should be looking to eliminate cross-PKI interactions, not introduce >> new ones. >> >> It?s pretty straightforward to do that with a new tag.? No additional >> properties or semantics are required.? And the process of adding a >> new tag is something this group has already successfully done once >> (?CAA CONTACT?). >> >> -Tim >> >> *From:* Paul van Brouwershaven >> >> *Sent:* Friday, January 29, 2021 11:13 AM >> *To:* Neil Dunbar >> ; SMIME Certificate Working Group >> ; Tim >> Hollebeek >> >> *Cc:* Kirk Hall >> *Subject:* Re: [Smcwg-public] CAA and S/MIME >> >> While the BR only specifies how CAA must be implemented/used for TLS >> certificates the CAA RFC is not limited to just TLS certificates, the >> RFC 8659 (and previously RFC 6844) begins with: >> >> The Certification Authority Authorization (CAA) DNS Resource Record >> >> ? ?allows a DNS domain name holder to specify one or more >> Certification >> >> ? ?Authorities (CAs) authorized to issue certificates for that domain >> >> ? ?name. >> >> This does make sense as this would create a `deny all, except` >> principle where you need to give explicit permission like as in a >> good firewall configuration. But I agree that there should be a >> possibility to change permission per certificate type and to drop >> restrictions where needed (such as for S/MIME with shared mail >> providers). >> >> I'm currently not in favor of having a new S/MIME specific property, >> and one for client certs, document signing, etc. as where does it >> stop. It would also not allow to have separate `iodef` settings for >> example (or only enable them for TLS). >> >> We could define one new parameter to define the certificate type, the >> standard already has a reversed policy property which was used in the >> draft RFC to limit issuance on policy OID. Rob pointed me at the >> draft CAA specification that had a?policy property value instead of a >> CA domain name. >> >> https://datatracker.ietf.org/doc/html/draft-hallambaker-donotissue-04#section-3.1.2 >> >> >> This could work with cabforum defined OID's, the advantage from using >> OID's is that it would support an OID prefix, and it would be easier >> for CAs to enforce. But it's not very user friendly..? >> >> This would allow: >> >> ? ?$ORIGIN example.com >> ? ?. ? ? ? CAA 0 issue "ca1.example.net; policy=2.23.140.1"?? // Only >> cabforum >> ? ?. ? ? ? CAA 0 issue "ca2.example.net; policy=2.23.140.1.5" // SMIME >> ? ?. ? ? ? CAA 0 issue "ca3.example.net; policy=2.23.140.1.2" // DV, >> OV, IV >> ? ?. ? ? ? CAA 0 issue "ca4.example.net; policy=2.23.140.1.1" // EV >> >> For user friendliness, we could define a new parameter such as `type` >> with the same intention but based on a name value: >> >> This would allow: >> >> ? ?$ORIGIN example.com >> ? ?. ? ? ? CAA 0 issue "ca1.example.net" >> ? ?. ? ? ? CAA 0 issue "ca2.example.net; type=smime" >> ? ?. ? ? ? CAA 0 issue "ca3.example.net; type=tls" >> ? ?. ? ? ? CAA 0 issue "ca4.example.net; type=tls-ev" >> Where: >> ?ca1 could issue any type of certificate not explicitly specified (so >> no S/MIME, or TLS certificates in this example) >> ?ca2 could issue only smime certificates >> ?ca3 could issue any type of TLS certificate except for EV >> ?ca4 could issue only EV TLS certificates >> >> Alternatively, we could define two parameters, one for the >> certificate type and one for the assurance level, this would give: >> >> ? ?$ORIGIN example.com >> ? ?. ? ? ? CAA 0 issue "ca1.example.net" >> ? ?. ? ? ? CAA 0 issue "ca2.example.net; type=smime" >> ? ?. ? ? ? CAA 0 issue "ca3.example.net; type=tls" >> ? ?. ? ? ? CAA 0 issue "ca4.example.net; type=tls; level=ev;" >> >> The challenge for all these methods is how do we drop CAA >> limitations, as we want something like: >> >> ? ?$ORIGIN example.com >> ? ?. ? ? ? CAA 0 issue "ca1.example.net" >> ? ?. ? ? ? CAA 0 issue "*; type=smime" >> But that is not allowed by the RFC. >> >> If we would define a separate property per certificate type but >> follow the RFC and honoring the inheritance, we would still have the >> same challenge of stopping the inheritance . >> >> ? ?$ORIGIN example.com >> ? ?. ? ? ? CAA 0 issue "ca1.example.net" >> ? ?. ? ? ? CAA 0 issuesmime "ca2.example.net" >> ? ?. ? ? ? CAA 0 issuetls "ca3.example.net" >> ? ?. ? ? ? CAA 0 issuetlsev "ca4.example.net" >> >> Maybe we could simply create an 'unrestricted' parameter to overrule >> the RFC?: >> >> ? ?$ORIGIN example.com >> ? ?. ? ? ? CAA 0 issue "ca1.example.net" >> ? ?. ? ? ? CAA 0 issue "; type=smime; unrestricted=true" >> >> >> Paul >> >> ------------------------------------------------------------------------ >> >> *From:*Smcwg-public > > on behalf of Tim >> Hollebeek via Smcwg-public > > >> *Sent:* Monday, October 26, 2020 15:25 >> *To:* Neil Dunbar > >; SMIME Certificate Working >> Group > >> *Subject:* [EXTERNAL]Re: [Smcwg-public] CAA and S/MIME >> >> This is how I feel about the issue.? CAA is potentially an >> interesting improvement to the S/MIME ecosystem, but the current tags >> and implementation were meant for TLS, and shouldn?t be reused. >> >> The RFC has an extension mechanism which can easily be used to add >> new tags for S/MIME issuance, and issuance of other kinds of non-TLS >> certificates. >> >> -Tim >> >> *From:* Smcwg-public > > *On Behalf Of *Neil >> Dunbar via Smcwg-public >> *Sent:* Monday, October 26, 2020 6:03 AM >> *To:* smcwg-public at cabforum.org >> *Subject:* Re: [Smcwg-public] CAA and S/MIME >> >> On 24/10/2020 16:21, Stephen Davidson via Smcwg-public wrote: >> >> Hello: >> >> The topic of Certification Authority Authorisation (CAA) has >> arisen a number of times in relation to the evolving S/MIME Baseline. >> >> I highlight a discussion on that subject related to the Mozilla >> policy: https://github.com/mozilla/pkipolicy/issues/135 >> >> >> A significant number of email providers ? such as gmail.com, >> outlook.com, protonmail.com, and others ? have CAA records. >> >> >> Questions for us to address later in our discussions: >> >> * Is CAA a desired requirement of the S/MIME Baseline? >> * Should the S/MIME Baseline rely upon the existing >> requirements stated in the TLS BR, or is the S/MIME use case >> sufficiently different to merit a separate CAA tag? >> >> Generally, I'm a fan of allowing organisations (however defined) to >> specify their policy requirements for publicly trusted certificates >> via CAA records; so I would say "yes", it is a desired requirement of >> the S/MIME baseline. I would certainly expect it to make its way into >> the root program requirements at some point, and having a pan-root >> program consensus on those requirements beats having overlapping or >> potentially conflicting requirements. >> >> That said, I'm not a fan of ninja semantics (changing the meaning of >> a deployed resource where the deployer might not have considered its >> eventual full scope) - it seems to me that the "issue" and >> "issuewild" tags were framed with TLS certificates in mind[*], and I >> think extending "issue" to cover S/MIME could have effects on domain >> owners which were not expected. In other words, we would be saying to >> them that all certificates are hereby covered, without them having >> any means of expressing the policy "I want CA X to issue TLS >> certificates, but any CA could issue S/MIME certificates"; so I'm >> less of a fan of reducing the expressive potential of domain owners. >> >> To that extent, I think that I'd prefer tags like "issue-tls", >> "issue-tls-wildcard", "issue-email", and so on, with similar >> semantics which work over "issue" and "issuewild" right now. Once >> those are in effect, then you could extend the "issue" tag to mean >> "all certificates" as a shorthand, while leaving finer detailed >> policy expressions. However, that goes further than anything the >> S/MIME WG could reasonably pronounce upon. But "issue-email" to cover >> S/MIME certs falls within its charter and seems to have a clearer >> scope. There's even an opportunity to allow domain owners to specify >> the validation methods permissible for issuance, but that's a whole >> different discussion. >> >> Just my opinion, of course. >> >> Neil >> >> [*] Genuine question: would "issuewild" have any meaning outside of >> TLS certificates? >> >> >> >> _______________________________________________ >> 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 Stephen.Davidson at digicert.com Sat Jan 30 23:03:20 2021 From: Stephen.Davidson at digicert.com (Stephen Davidson) Date: Sat, 30 Jan 2021 23:03:20 +0000 Subject: [Smcwg-public] Approved Minutes of SMCWG January 6, 2021 Message-ID: Minutes of SMCWG January 6, 2021 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), Andrea Holland (SecureTrust), Andreas Henschel (D-TRUST), Atsushi Inaba (GlobalSign), Ben Wilson (Mozilla), Bruce Morton (Entrust DataCard), Burkhard Wiegel (Zertificon), Chris Kemmerer (SSL.com), Christian Heutger (PSW), Corey Bonnell (DigiCert), Dean Coclin (DigiCert), Don Sheehy (WebTrust), Doug Beattie (GlobalSign), Enrico Entschew (D-TRUST), Hazhar Ismail (MSC Trustgate.com), James Knapp (Federal PKI), Janet Hines (SecureTrust), Jeff Ward (WebTrust), Li-Chun Chen (Chunghwa Telecom), Mads Henriksveen (BuyPass), Markus Wichmann (TeleTrust), Matthias Wiedenhorst (ACAB'c), Mevre Tunca (Zertificon), Morad Abou Nasser (TeleTrust), Neil Dunbar (TrustCor), Patrycja Tulinska (PSW), Pedro Fuentes (OISTE), Rufus Buschart (TeleTrust), Russ Housley (Vigil Security), Sebastian Schulz (GlobalSign), Stephen Davidson (DigiCert), Tadahiko Ito (SECOM Trust Systems), Thomas Connelly (Federal PKI), Tim Crawford (WebTrust), 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 November 25 and December 9 teleconference were approved. 5. Discussion of certificate profile A discussion took place about the work approach in the first quarter of 2021. It was agreed that the WG would focus upon defining Certificate Policies that accommodated a permissive approach (for example allowing multipurpose certificates and a wider range of fields) as well as a pure S/MIME approach. The goal is to move the leaf certificate profile sections of the draft S/MIME Baseline Requirements (SBR) into the CABF GitHub at the end of the quarter. In addition the WG will consider starting to collect pending issues for discussion in the CABF GitHub. The intent is to focus upon the Issuing CA and Root CA profile requirements in Q2. Sebastian Schulz suggested that the focus should initially be on a strict S/MIME approach (i.e., the profile the WG has proposed as mailbox-validation) rather than trying to define standards around legacy practice. Wendy Brown questioned the benefit of allowing only strict/SMIME when it appears currently that the majority of certificates in use are multipurpose of some form, and that the profiles the WG is proposing as sponsored-validation and individual-validation should be allowed for multipurpose signing use. Stephen Davidson noted that the permissive profile would intend to allow flexibility, although perhaps not with the same breadth of current practice as the SBR should define a validation regime for each allowed attribute. Tadahiko Ito proposed that the SBR should ultimately require protection of the private key for signing certificates that include the nonRepudation keyUsage. Wendy Brown suggested that the WG further enquire how the Certificate Consumers use the certificate information in UI, and the extent to which enterprise solutions allow custom configuration that may rely upon certificate information. Sebastian Schulz offered to assist. Morad Abou Nasser offered to take specific questions to the enterprise members of TeleTrust. Tadahiko Ito emphasized that the SBR must accommodate international names. Russ Housley said that different vendors had varying roadmaps for adoption. Doug Beattie stated that some trusted CAs were moving to new dedicated hierarchies by certificate type, so the strict S/MIME profile would be necessary for those starting with a clean slate. He said that the permissive/legacy profile could initially be loose, but should have a timeline to be tightened as to which fields might be used. Stephen Davidson noted that many CAs approached personal certificates from the validation point of view - for example, by doing high identity validation of the certificate holder, they desire to make a signing certificate useful in multiple contexts including signing documents or S/MIME. It was suggested in a stricter approach that the same validation might support different dedicated certificates for those uses. 6. Any Other Business 7. Next call The next call will take place on January 20, 2021 at 11:00am Eastern Time. Adjourned -------------- next part -------------- An HTML attachment was scrubbed... URL: From Stephen.Davidson at digicert.com Sat Jan 30 23:17:05 2021 From: Stephen.Davidson at digicert.com (Stephen Davidson) Date: Sat, 30 Jan 2021 23:17:05 +0000 Subject: [Smcwg-public] Draft SMCWG agenda - Wednesday, February 3, 2021 Message-ID: SMCWG Agenda Draft SMCWG agenda - Wednesday, February 3, 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 January 20, 2021 5. Proposed new member rundQuadrat OG as Certificate Consumer https://r2mail2.com, https://rundquadrat.at 6. Continuation of discussion of end entity profiles (Multipurpose, Strict) 7. Any other business 8. Next call: February 17, 2021 at 11:00 am Eastern Time Adjourn -------------- next part -------------- An HTML attachment was scrubbed... URL: