<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=iso-8859-1"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:"Yu Gothic";
panose-1:2 11 4 0 0 0 0 0 0 0;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"\@Yu Gothic";
panose-1:2 11 4 0 0 0 0 0 0 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle18
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link="#0563C1" vlink="#954F72" style='word-wrap:break-word'><div class=WordSection1><p class=MsoNormal>Attendees:<o:p></o:p></p><p class=MsoNormal>Andrea Holland, Aneta Wojtczak, Ben Wilson, Bruce Morton, Clint Wilson, Corey Bonnell, Dimitris Zacharopoulos, Doug Beattie, Enrico Entschew, Iņigo Barreira, Janet Hines, Joanna Fox, Johnny Reading, Kati Davids, Martjin Katerbarg, Niko Carpenter, Rebecca Kelley, Ryan Dickson, Stephen Davidson, Steven Deitte, Thomas Zermeno, Tim Hollebeek, Trevoli Ponds-White, Tyler Myers, Wayne Thayer<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Tim read the anti-trust statement.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Agenda for today is discussing the CRL validity period ballot proposal and certificate profiles.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Wayne mentioned that he wanted to discuss CNAME delegation to the CA. Tim mentioned that there has been background discussion on this topic and we can discuss today.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>CRL validity period ballot:<o:p></o:p></p><p class=MsoNormal>Tim: Spent some time reviewing to find potential bugs and found one that was flagged on the list.<o:p></o:p></p><p class=MsoNormal>Corey: I have concerns with side effects of making a global change to fix a local problem. For example, Random Values. A CA today may allow for Random Values to be valid for 30 days and X seconds, which would now be non-compliant.<o:p></o:p></p><p class=MsoNormal>Trev: Perhaps we can future-date clarity changes to avoid things like that.<o:p></o:p></p><p class=MsoNormal>Tim: I agree. Since this issue isn't urgent, we can put a future date.<o:p></o:p></p><p class=MsoNormal>Trev: Yes, I think that's a good practice. Since the intent is to clarify minor things, we should put a future effective date so we can focus on more urgent concerns.<o:p></o:p></p><p class=MsoNormal>Wayne: I'm supportive of taking more time to allow people to assess impact of the ballot. Should we move the effective date to June 1st or July 1st.<o:p></o:p></p><p class=MsoNormal>Corey: My understanding is that we are modifying the conventions in section 1. We should put an effective date in section 1 as well.<o:p></o:p></p><p class=MsoNormal>Wayne: Originally, I had the change scoped to CRLs and later added the text in section 1. We can remove the change in section 1.<o:p></o:p></p><p class=MsoNormal>Tim: I like it being document-wide. We can make the document-wide change effective on June 1st. There will be ambiguity until June 1st for the sections outside CRL, but that ambiguity exists today.<o:p></o:p></p><p class=MsoNormal>Corey: Right, we're not making the situation any worse by adding an effective date to the document-wide convention change. If anything, we're making it better by setting the right course.<o:p></o:p></p><p class=MsoNormal>Wayne: So we'll make the change to the CRL section and add the effective date to conventions.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Tim: As an aside, I'm looking to creating a cleanup ballot since we haven't done one in a while. I'm looking to do a ballot that's a cleanup and not introduce more controversial clarifications and changes. Let me know if there's anything that anyone wants to have addressed.<o:p></o:p></p><p class=MsoNormal>Clint: There are some GitHub issues that are marked as cleanup items.<o:p></o:p></p><p class=MsoNormal>Tim: Yes, there's a wide variety. I'm looking to get those fixed.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Certificate Profiles:<o:p></o:p></p><p class=MsoNormal>Tim: I'm going to go through my F2F presentation and we can discuss each point here to gain consensus on next steps.<o:p></o:p></p><p class=MsoNormal>Dimitris: Is the goal to revisit all the high level issues, determine how we will proceed, and then update the ballot?<o:p></o:p></p><p class=MsoNormal>Tim: Yes.<o:p></o:p></p><p class=MsoNormal>Trev: It would be good to share your presentation here to refresh everyone's memory and also inform those who weren't at the F2F. Also, questions might have come up since the F2F.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>- Cross Certificates must have EKUs<o:p></o:p></p><p class=MsoNormal>Corey: Current practice is to omit EKUs for cross certificates, so it is definitely a change.<o:p></o:p></p><p class=MsoNormal>Tim: But a good one?<o:p></o:p></p><p class=MsoNormal>Corey: As long as there are no client interoperability issues with it, this should be no problem.<o:p></o:p></p><p class=MsoNormal>Wayne: My only concern is that this is a change in requirements. Should it be a separate ballot?<o:p></o:p></p><p class=MsoNormal>Trev: I agree with Wayne.<o:p></o:p></p><p class=MsoNormal>Tim: The original intent of the profiles work was not to introduce large changes to existing practice and this is such a change.<o:p></o:p></p><p class=MsoNormal>Wayne: I'm sure this may affect some CAs and it's potentially easy to miss in a larger ballot.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>- First policy OID must be CABF reserved OID<o:p></o:p></p><p class=MsoNormal>Tim: This is something that I originally was not a fan of but I understand the inertia of changing certificate-processing software. However, this provides useful guidance so I'm in favor of including it.<o:p></o:p></p><p class=MsoNormal>Dimitris: I'm in favor of it, but it falls into the same category as the previous topic. It'll be considered a mis-issuance if a reserved OID isn't in the first position.<o:p></o:p></p><p class=MsoNormal>Doug: If a browser doesn't want to trust a certificate because the OIDs aren't in a particular order that's one thing but treating it as a mis-issuance is heavy-handed.<o:p></o:p></p><p class=MsoNormal>Clint: We should make this a SHOULD. It gives guidance but also avoids mis-issuance.<o:p></o:p></p><p class=MsoNormal>Trev: Should it be its own ballot? <o:p></o:p></p><p class=MsoNormal>Tim: That's a good idea. I'd like to avoid a ballot explosion, so maybe one ballot to introduce the format changes and another for requirements changes?<o:p></o:p></p><p class=MsoNormal>Wayne: I think this one is fine if it's a SHOULD.<o:p></o:p></p><p class=MsoNormal>Trev: Are we making it a SHOULD so that we eventually make it a MUST?<o:p></o:p></p><p class=MsoNormal>Corey: I'm wondering if there are plans on the Certificate Consumer side to implement proper policy-chaining that would cause this to become a MUST sooner.<o:p></o:p></p><p class=MsoNormal>Doug: I think for now we can make this a SHOULD.<o:p></o:p></p><p class=MsoNormal>Tim: At first, I hated this client behavior. But I think that stemmed from it being undocumented. If it's documented, perhaps long term we can make it a MUST.<o:p></o:p></p><p class=MsoNormal>Trev: Perhaps we can make this a MUST next year?<o:p></o:p></p><p class=MsoNormal>Tim: I think that's reasonable.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>- Changes to Name Constraints<o:p></o:p></p><p class=MsoNormal>Corey: There's a couple of things here. To prohibit issuance of trusted certificates with dNSNames, you add a single dNSName entry under excludedSubtrees. However, for rfc822Name and sRVName, it's more complex. You need to add an entry to permittedSubtrees to prohibit issuance. Also problematic is that the current profiles draft specifies sRVName constraints in a way that violates ASN.1 syntax, so we need to revisit this.<o:p></o:p></p><p class=MsoNormal>Dimitris: Why do we need any provisions for sRVName? We currently don't handle sRVNames in the BRs.<o:p></o:p></p><p class=MsoNormal>Corey: This stemmed from current Mozilla policy, which requires constraints on sRVName to be considered technically constrained. However, I know of no way to express them correctly given the specification. When the clause in Mozilla Policy was added, there was an expectation that sRVNames would be permitted by the BRs but that never happened.<o:p></o:p></p><p class=MsoNormal>Dimitris: So an empty string for sRVNames doesn't work?<o:p></o:p></p><p class=MsoNormal>Corey: Yes, because the ASN.1 syntax for sRVName has a constraint that at least 1 character must be present.<o:p></o:p></p><p class=MsoNormal>Dimitris: I don't have an objection to update the BRs to account for sRVNames, but it should be a separate ballot.<o:p></o:p></p><p class=MsoNormal>Corey: Perhaps the best approach may be to not tackle sRVNames at all in the first iteration of the profiles draft and instead revisit sRVNames more completely at a later point.<o:p></o:p></p><p class=MsoNormal>Tim: I think that makes sense especially since we don't have a good solution here.<o:p></o:p></p><p class=MsoNormal>Wayne: I agree.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>- Cross Certificates<o:p></o:p></p><p class=MsoNormal>Tim: This definition brings great clarity, but may change things for some CAs.<o:p></o:p></p><p class=MsoNormal>Dimitris: My understanding is that a Cross Certificate was always a Subordinate CA certificate.<o:p></o:p></p><p class=MsoNormal>Tim: I think if you look in the wild you'll find Cross Certificates that aren't 100% compliant Subordinate CA certificates.<o:p></o:p></p><p class=MsoNormal>Doug: Since you need to include the subject DN for the Root certificate in the Cross Certificate, it might not comply with the requirements for Subordinate CA naming.<o:p></o:p></p><p class=MsoNormal>Wayne: I think considering Cross Certs to be Sub CA certs is already widely believed to be a requirement amongst Root Programs, so I'm struggling to see this as a normative change.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>- AKI/SKI<o:p></o:p></p><p class=MsoNormal>Corey: I'm still not sure what the rationale is for the first bullet point (making inclusion of AKI in self-signed Root certificates a SHOULD). I did some digging after the F2F and the only relevant thing I found was a Chrome commit comment for some test certificate generation script. Ryan mentioned a slowdown if there was a collision of key identifiers but beyond that I didn't find anything.<o:p></o:p></p><p class=MsoNormal>Ryan: From my understanding, this was a hint to the certificate path-builder that it encountered a root certificate and didn't need to process others. I can bring more information for the next meeting.<o:p></o:p></p><p class=MsoNormal>Corey: That would be helpful, as my thinking was that the absence of the AKI would be the signal that you encountered a Root certificate.<o:p></o:p></p><p class=MsoNormal>Trev: Since this is an optimization that Google wants, it should be its own ballot. It's not a clarification as it deals with a new software implementation so it should have a future effective date.<o:p></o:p></p><p class=MsoNormal>Corey: That makes sense.<o:p></o:p></p><p class=MsoNormal>Ryan: This would be a SHOULD-level requirement, so there is no additional enforcement mechanism on the CA operator, so I see this as relatively safe for this community. I understand the alternative perspective, which is what is the requirement change a year from now. I'll dig up more on this.<o:p></o:p></p><p class=MsoNormal>Tim: DigiCert has a policy that we comply with SHOULDs unless we know of a reason not to, so we consider them to be softly normative.<o:p></o:p></p><p class=MsoNormal>Corey: That's the correct approach. When violating a SHOULD, you should understand the rationale for the SHOULD-level requirement so you can make an informed decision.<o:p></o:p></p><p class=MsoNormal>Trev: That's why I think there's value in having this be a separate ballot. It can explain the value of following the SHOULD and the ramifications of not.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>- Bans of various kinds<o:p></o:p></p><p class=MsoNormal>Tim: Banning LDAP URIs is also being discussed in the SMIME WG. <o:p></o:p></p><p class=MsoNormal>Corey: For TLS, they are definitely the exception more than the rule.<o:p></o:p></p><p class=MsoNormal>Tim: Add it to the normative change list so people don't miss it?<o:p></o:p></p><p class=MsoNormal>Corey: That makes sense.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>(certificatePolicies in OCSP responder certificates)<o:p></o:p></p><p class=MsoNormal>Corey: If you look at Censys, existing practice is that many CAs include. I don't feel too strongly if they go away, but it's a matter of timelines.<o:p></o:p></p><p class=MsoNormal>Dimitris: If you consider the OCSP certificate to be as critical as the CA certificate, then a Relying Party would need to take a look under which policy the certificate was issued.<o:p></o:p></p><p class=MsoNormal>Tim: That's a good point. We had a similar issue in code signing where there was no policy OID for timestamping to denote which timestamp authority certificates were under CSBR scope.<o:p></o:p></p><p class=MsoNormal>Trev: Do we have a profile in the draft for OCSP responder certificates?<o:p></o:p></p><p class=MsoNormal>Tim: Yes.<o:p></o:p></p><p class=MsoNormal>Trev: Doesn't it seem odd to define a profile in the BRs but not allow the policy to be expressed in the certificate?<o:p></o:p></p><p class=MsoNormal>Tim: Yes, and also potentially goes against adding policy OIDs to all certificates that comply with the BRs. Perhaps we should go the opposite direction and require certificatePolicies.<o:p></o:p></p><p class=MsoNormal>Trev: Yes, either we should have a profile and a policy or we don't care how they are defined and not have a profile.<o:p></o:p></p><p class=MsoNormal>Corey: I like the idea of specifying the profile in the BRs since it's good guidance for CAs. I could go either way on whether certificatePolicies is included.<o:p></o:p></p><p class=MsoNormal>Trev: Yes, I don't have strong feelings either way but it seems inconsistent.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>- QCStatements as a SHOULD NOT<o:p></o:p></p><p class=MsoNormal>Tim: The current draft lists certain extensions, but for everything not listed, it's a SHOULD NOT. Absent further clarifying text in the profiles, this could be read as a potential ban on QCStatements in the future.<o:p></o:p></p><p class=MsoNormal>Dimitris: I believe Ryan has changed the position on this. Enrico asked whether there is a plan to ban QCStatements at the last teleconference call and Ryan said no. So this SHOULD NOT is inconsistent with that statement. Perhaps we can look at all extensions that have been historically included in certificates and make them a MAY with all others being a SHOULD NOT.<o:p></o:p></p><p class=MsoNormal>Tim: Yes, but we'll have to undergo that exercise. That could be significant work.<o:p></o:p></p><p class=MsoNormal>Dimitris: Agreed. Perhaps we can move this to version 2.0.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>- Serial number bounds<o:p></o:p></p><p class=MsoNormal>Tim: We should state the length of serial numbers is based on the DER-encoded value. There was resistance to this, but I never understood why. We should add this.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>- Non-TLS CAs<o:p></o:p></p><p class=MsoNormal>Tim: This is thorny and we only got to the hand-wavy level.<o:p></o:p></p><p class=MsoNormal>Dimitris: The first bullet point (intermediates issued by Roots under BR scope must include CABF OIDs) makes sense. But then we need a policy to denote non-TLS.<o:p></o:p></p><p class=MsoNormal>Corey: There was an argument made that the subordinate CA certificate profile in the BRs applies to non-TLS CAs today. However, if you follow that argument, then by including a CABF OID in the non-TLS CA, you will be granting technical capability for that "non-TLS CA" to issue TLS Subscriber certificates that will be trusted by clients that implement policy-chaining as opposed to EKU-chaining.<o:p></o:p></p><p class=MsoNormal>Dimitris: If we have a separate policy OID, then we won't grant technical capability.<o:p></o:p></p><p class=MsoNormal>Corey: Yes, but that's a future approach. The argument previously made was that the BRs require the inclusion of BR policy OIDs in non-TLS CAs today.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>- More Open Questions<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>(Domain Names in Subject Fields requiring DCV, example given was O=SSL.com)<o:p></o:p></p><p class=MsoNormal>Tim: I believe this is not a supportable interpretation. Just because a dot appears in a subject field doesn't mean that field value is now a domain name that needs to be validated. Does anyone believe this is a valid interpretation?<o:p></o:p></p><p class=MsoNormal>Trev: I do not.<o:p></o:p></p><p class=MsoNormal>Clint: I'm not saying that it's reasonable to require DCV for SSL.com, but it would be strange if the Subscriber couldn't complete DCV. This seems more like a legal issue than a CAB Forum issue.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>(Backdating)<o:p></o:p></p><p class=MsoNormal>Tim: There was an attempt to prohibit backdating altogether but this is complicated by precertificates as the final certificate validity period must match the previously issued precertificate. Since this was brought up in June and there have been no proposals to address, I suggest we allow for back/forward-dating of +/- 48 hours.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Tim: We're out of time; we'll pick up next time with a discussion of delegating DCV to the CA.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Meeting adjourned.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Thanks,<o:p></o:p></p><p class=MsoNormal>Corey<o:p></o:p></p></div></body></html>