<div dir="ltr"><div>Sorry I wasn't able to make the call. Splitting out a bit from the minutes to have some discussion on the list.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 25, 2021 at 11:55 AM Wayne Thayer via Validation <<a href="mailto:validation@cabforum.org">validation@cabforum.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Corey said that a few interesting changes that weren’t discussed are included. One is the near-universal requirement for the use of UTF8String. Corey said that there is still a lot of use of PrintableString in various fields. This is in 7.1.4.2 on page 80 of the PDF Ryan emailed out. Corey said that he is not aware of discussion of this change in the past.<br><br>Tim said that he proposed this change before and received a lot of push-back. </div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br>Corey said this particularly impacts the commonName field. </div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br>Tim said that we had agreed to avoid introducing big changes in the first version of this effort. RFC 5280 clearly permits PrintableString.<br></div></blockquote><div><br></div><div>Good spotting! This was an accidental oversight/bad transcription on my part as a result of shuffling through different approaches thatI mentioned on the past call.</div><div><br></div><div>This should have been PrintableString or UTF8String, which is the long-standing 2459/3280/5280 requirement - <a href="https://tools.ietf.org/html/rfc5280#section-4.1.2.4">https://tools.ietf.org/html/rfc5280#section-4.1.2.4</a> .</div><div><br></div><div>Hopefully those _two_ options should be uncontroversial, given their 25 year history.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Corey said that there is also a new profile for OCSP delegated responder certificates in section 7.1.2.7 and asked if anyone had thoughts about this. He said that prohibiting the certificatePoliices extension may be a concern. Are any browsers expecting policy chaining for OCSP responder certificates? </div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br>Tim said that CAs who use certificatePolicies to link the CPS to the cert to meet Mozilla requirements may have problems with this.<br></div></blockquote><div><br></div><div>Tim: Could you expand on this? Did I overlook a conflicting browser requirement?</div><div><br></div><div>Mozilla's policy only requires "CAs must provide a way to clearly determine which CP and CPS applies to each of its root and intermediate certificates.", which isn't even a statement about cPSUri in the certificates (which is already forbidden for some cases by our existing requirements). So I'm not sure what you meant here, but happy to fix it up if that's the case.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Corey said that client software that looks at policy chaining might be affected.<br></div></blockquote><div><br></div><div>Note: Client software won't have issues here, because this would follow the RFC 5280 rules (by not explicitly asserting a policy). Policy chaining issues would only exist in this situation if explicitly trying to verify a specific policy for the OCSP responder, which none of the popular verification APIs (e.g. OpenSSL/LibreSSL/BoringSSL, NSS, Java, & Win/Mac/Android/iOS OS APIs) let you even remotely get close to supplying :)</div><div><br></div><div>This is also a logical consequence of the ongoing work to align on CA/B Forum OIDs for things subject to the BRs. As we saw from the browser alignment ballot, where it was already a requirement in root stores, subscriber certificates have been required to include/assert a CA/B Forum OID for some time. This allows verifying APIs to restrict the policy OIDs for, say, TLS, to explicitly CA/B Forum OIDs (or, conversely, measure self-asserted compliance)</div><div><br></div><div>CA-specific policy OIDs don't really make any sense, as we already saw from EV, because they don't provide extra assurance to relying parties that are only measuring/expecting compliance with the CA/B Forum OIDs. At best, they end up encouraging the combination of multiple separate trust frameworks, whether those that want _more_ than the CABF or that want something _different_ than the CABF. Since that is the only remaining technical use case, it doesn't make sense, as we've been discussing since the SHA-1 deprecation that such mixed-framework/mixed-agility approaches are inherently bad ideas.</div><div><br></div><div>For an OCSP responder, the policy OID isn't presently something OCSP verification APIs expect (or even expose). If we did want to use one, we'd need to precisely articulate why. "This OCSP Responder complies with the BRs" doesn't make sense, because it's obvious that if it's a responder for a **subject** cert that complies with the BRs, it's expected to comply with the BRs, so there's no ambiguity.</div><div><br></div><div>I'm all for being relaxed here if we've got an identified technical use case, but I'm not sure we do. Have I overlooked something?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Tim said there are similar concerns about scope with time stamping certificates, and the most clear solution is to use certificatePolicies to assert this.</div></blockquote><div><br></div><div>Tim: Could you elaborate on this? Distinguishing timestamping certificates is done by EKU, not by certificatePolicies.</div><div><br></div><div>For example, if you're doing a Timestamping CA today, from an existing BR root, you already can't use certificatePolicies' cpsUri because of 7.1.2.2 (a) of the existing BRs. Those fields are only permitted for non-Affiliate certificates (the explicit MAY is conditional).</div><div><br></div><div>You can, however, separate by EKU, and if you only use the timestamping EKU, then the Timestamping CA meets the definition of a Technically-Constrained Non-TLS Sub-CA. This is a result of the browser alignment ballot, we now treat no-TLS-or-anyEKU as a sufficiently acceptable technical constraint - per 7.1.5 of existing BRs.</div><div><br></div><div>If you were highlighting TSA-direct-from-root, yeah, that's why I sent the mail to the main servercert-wg@ ( <a href="https://archive.cabforum.org/pipermail/servercert-wg/2021-March/002578.html">https://archive.cabforum.org/pipermail/servercert-wg/2021-March/002578.html</a> ) to try to suss that out and if folks still had that use case with their current/modern hierarchies in 2021. </div><div><br></div><div>One thing I realized that I had on my TODO list written down here, but forgot to transcribe to the list for yesterday's update, was figuring out "non-TLS end-entity" certificates. This is intended as a legacy transition path for CAs that have existing intermediates that didn't comply with root program requirements, but existed before the browser alignment ballot, have multiple EKUs, and the CA has not migrated off/revoked yet. Concretely, say, an intermediate that issues both TLS server certs and email protection certs, despite this no longer being allowed by the BRs and long disallowed by root programs.</div><div><br></div><div>While this is no longer allowed, for CAs with those existing sub-CAs who haven't stopped yet, we probably need a profile to cover "not TLS". The requirements here would be much more relaxed, and be simply around EKU (being present, not containing TLS) and the signature algorithm(s) (so no SHA-1). That _should_ cover the TSA case, if it wasn't already addressed, as well as any not-TLS cases.</div><div><br></div><div>However, even with that approach, I'd prefer to have explicit profiles precisely specifying what roots are signing, even if we offer more flexibility to legacy intermediates. So if folks are still doing TSAs directly from roots, I think we should definitely add a TSA profile, and happy for any CA who wants to point to recent examples of such issuance to work out the profile.</div></div></div>