[cabf_validation] Draft Minutes for the Validation Subcommittee Server Certificate Working Group Teleconference - 13 January 2022

[Slaughter, Michael]

These are the draft minutes of the teleconference described in the subject of this message as prepared by Michael Slaughter (Amazon).
Please review the minutes and propose edits if necessary. These minutes will be considered for approval at the next meeting. The recording of the meeting will be deleted once the minutes are approved.
Attendees (in alphabetical order)
Wayne Thayer, Tim Hollebeek, Amanda Mendieta,, Andrea Holland, Aneta Wojtczak, Ben Wilson, Bruce Morton, Clint Wilson, Corey Bonnell, Daryn Wright, Dimitris Zacharopoulos, Doug Beattie, Dustin Hollenback, Enrico Entschew, Iñigo Barreira, Janet Hines, Joanna Fox, Johnny Reading, Jose Guzman, Kati Davids, Martijn Katerbarg, Michael Slaughter, Niko Carpenter, Paul van Brouwershaven, Pekka Lahtiharju, Rebecca Kelley, Ryan Dickson, Ryan Sleevi, Stephen Davidson, Thomas Zermeno, Trevoli Ponds-White, Tyler Myers and Wendy Brown.
Agenda

  1.  Nomination of Corey as Validation Subcommittee Chair
  2.  Method 7, when the CA is involved (Amazon)
  3.  Mozilla Compliance Self-Assessment
  4.  CRL validity period ballot (SC52)
  5.  Unicode usage - Script spoofing, symbols and other characters

Minutes
Preparation

  *   The recording started
  *   Roll call was taken by Tim
  *   The antitrust statement was read by Tim
  *   Minute taker was assigned (Michael Slaughter)

1. Nomination of Corey as Validation Subcommittee Chair

Tim proposed naming Corey Bonnell as the new chair of the validation subcommittee.

Wayne endorsed Corey and offered to continue to serve the committee in a supporting role.

Tim asked if the group would be comfortable confirming Corey as chair through consensus given the large attendance on the call. Dimitris responded that consensus is fine.

Corey Bonnell was named chair of the Validation Subcommittee. Congratulations Corey!

2. Method 7, when the CA is involved (Amazon)

Tim started the discussion by asking if Trev would like to comment on the discussion taking place in the e-mail thread with subject: “[cabf_validation] Method 7, when the CA is involved”.

Trev asked Doug for confirmation that his question on the mailing list regarding how private keys are handled in AWS was addressed which Doug affirmed. Trev then asked why the inability to export a private key from AWS mattered in the context of the e-mail thread.

Ryan S. clarified that it used to matter because the revocation requirement was that the applicant and subscriber must not share a private key. Ryan S. further explained that the rule did not work for CDNs and was fixed in the BRs but Amazon’s policies pre-date that. The key point is that in the case of Amazon, AWS is the subscriber and AWS is abiding by the agreement as opposed to ATS (Amazon Trust Services) performing the validation itself.

Dimitris said that we have previously discussed that there is not a meaningful difference between an applicant or subscriber delegating the CNAME to a CA, a third-party or a reseller for the purpose of domain validation. Dimitris noted that while subscriber agreements require two parties thus preventing a CA from signing its own agreement, there is nothing that would prevent a CA from creating a third-party entity and affiliate to effectively accomplish the same thing.

Ryan S. agreed that there are loopholes and referenced prior discussions around a reseller that e-mailed DigiCert private keys that went into the boundary of a CA’s obligation. He said that when it comes to the validation process, what matters is that it is the applicant that needs to demonstrate control and that it is important for the applicant to have the challenge values required to perform that demonstration of control. While there are third parties, applicant representatives and entities with signing authority, whatever the model it is the applicant that needs to perform the validation. The line between a CDN and reseller is something that the BRs have not tackled but the question of the CA performing the validation should be clearer because it comes down to the question of is the applicant demonstrating control.

Dimitris responded that if the applicant delegated their DNS to the CA then it would be identical to delegating DNS to a CDN or a reseller.

Ryan S. replied that the difference is that when it comes to a CDN or reseller it is not the applicant providing the “random value” to itself.

Dimitris agreed and said that the issue exists with the method itself. If we can delegate the CNAME to another entity then it is not the applicant that is demonstrating control.

Ryan S. said that 3.2.2.4 is defining a protocol where there’s a secret value that is constructed by the CA which is then reflected by the applicant to CA that confirms the value. The intent here is that whatever channel that the applicant is using to request the certificate from the CA they use that same channel to reflect that secret back to the CA. The notion of the CA asking themselves for a secret that the CA knows creates a disconnect because that’s breaking part of the protocol leg. If the applicant gives their secret to someone else to prove things that’s also different. In the situation of CNAME delegation, we are saying that the applicant is not in possession of the secret themselves. There is no authentication of that request using that secret which is the issue and why it’s prohibited.

Corey noted that the BRs are little bit confusing when it comes to defining random values vs. random tokens. Certain validation methods such E-MAIL require secret values while other methods such as DNS or HTTP validation do not require that value to remain secret.

Tim agreed and said that the there was a proposed ballot in the past that would have clarified the definition of the random value and random token by using different terms since they have very different security properties. Tim indicated that he would like to revisit that and fix it at some point.

Ryan S. said this discussion reminds him of past discussions around Peter Bowen’s proposed method “3.2.2.4.13” also known as the “DNS operator exception for non-DNS operators“. That exception, which was discussed at the Herndon, VA F2F, allows a CA that is also a registrar can use the fact that a certificate request comes from the same account that is bound to the DNS.

Ryan S. said that the question being asked here is whether we are trying to validate a certificate request or are we trying to validate a relationship with a CA that allows all requests. The conversations in the past couple of months have focused on binding to an account which suggests that the authorization is not for a request. Recent changes to 3.2.2.4 such as shortening the reuse period of a validation however, indicate explicitly that these are intended to be request authorizations. Are you authorizing certificate requests or are you authorizing certificate accounts? This is the tension that is underplaying some of the issues here.

Tim responded that it ultimately comes down to what do we want. What does ownership or control mean? The dealing with Random Value performs the same role by verifying that the delegation still exists which is an important security property. It’s worth actually writing down the security analysis of some of these proposed methods and figuring out if they actually do what we want or if they don’t do what we want instead of just hand waving about general principles.

Wayne said that he agrees that the core problem here is whether we’re delegating to what Ryan S. referred to as an account or what I consider permanent domain control approval or whether it’s something that we have to repeat every time. Wayne said that there are benefits to automation when someone can authorize a domain on an ongoing basis and not have to touch it every time to do a renewal. Wayne continued that obviously there are ways that they can automate the process but being able to set a CAA record that says I authorize this CA to issue certs for my domain as a domain validation process is worth talking about but is unclear if we’re open to trying to do that or not.

Trev asked Wayne to clarify if by permanent, he intended to say revokable which Wayne confirmed he did. Trev continued on to say that the methods are oriented towards validating each request and agrees that it is not great for automation. Trev asked if we are interested in having the ability to for people to be able to say “I would like to delegate until such time” and “I no longer want to delegate”.

Wayne asked if we next write-up a domain validation method that relies on a CAA extension that stays in effect as long as the domain controller leaves it there.

Ryan S. said that may be interesting but there are a number of complexities including Trev’s point about making the persistent delegation revocable and various CA security implications. Ryan S. said that you want the CA to check for the value prior to every issuance and not rely on a one year thing which is not something that is provided for in 3.2.2.4 today. Ryan S. agreed that it is worth at least discussing what we would like to have and figure out how to fit that in if that is what we want.

Wayne said noted that the BRs don’t do a good job of distinguishing between an applicant and when the CA is the applicant. Wayne asked when CNAME delegation is performed by the CA when issuing certificates for itself, is that an example of CA delegation to the CA or does that mean they’re verifying controls from the actual applicant?

Tim affirmed the latter and agreed that the lack of clarity in the BR around a CA issuing certificates for itself is a major problem. Tim said that they treat themselves as an applicant when appropriate and as the CA when appropriate in that self-issuance scenario.

Ryan S. said that applicant is the entity that controls or operates the device named in the certificate. In the situation of DigiCert issuing certificates for DigiCert.com<http://digicert.com/>, DigiCert is the applicant since they’ve agreed to a “terms of use” because they are an affiliate of the C A - because they are the CA. Ryan S. said it gets messy when it comes to the definition of subscribers versus applicants but agreed with Dimitris’ point that it comes down to figuring out who is agreeing to the contract.

Wayne said that if a site was hosted by Google in Google Cloud Services with a certificate issued by Google Trust Services you could argue that Google Cloud is the applicant and Google Trust Services is the CA but you could also argue that they’re really the same entity. This presents another gray area wanted to see if other people are concerned.

Ryan S. said that he was deeply concerned about that aspect and that it came down to determining who was the applicant and applicant representative in this situation that is agreeing to the subscriber agreement. Ryan S. said that the Google Cloud team held a lot of conversations and deep dives to ensure that Google Cloud was also going to abide by the BRs in the design.

3. - Mozilla Compliance Self-Assessment
Wayne introduced the topic by explaining that the Mozilla compliance self-assessment was recently updated and had some questions that made him wonder if things have changed since they were originally implemented when compared to the stricter more literal interpretation that we have taken BRs over the past three to four years. The most glaring example is section 3.2.2.4 which was modified three or four years ago to say “CAs shall maintain a record of which domain validation method was used including the relevant BR version number”.

Wayne said what a pain it would be if that literally meant the CAs had to update their system to log a new BR version every time the version number of the BRs changed. Wayne said that he knows a number of CAs are not literally logging the relevant BR version number and asked if we need to do something about that. Wayne said that looking at the questions Mozilla asked made him question if he could really say he met the rule.

Ryan S. asked why wouldn’t CA log the BR version number and be able to support retroactive explorations to identify the version of the BRs the system was assessed against at a given point in time.

Trev responded that a CA wouldn’t necessarily make a change in their system for every ballot using the Spring cleanup ballot as an example since that would only impact processes outside of the system.

Ryan S. responded with a question about why CAs would not maintain a global state tracker for such situations.

Tim said that the important point is the goal here and that a lot of CAs are interpreting the goal of the requirement as the CA must be able to determine which version of the BRs was in effect at the point in time when an issue occurred. Tim said this does not require a CA to have a database table entry with a BR version for every certificate and that a lot of CAs have interpreted the requirement as having the ability to figure that out for every single certificate.

Wayne agreed with Tim on how it was interpreted 3 to 4 years ago and asked if that interpretation was still valid.

Ben called out that the process that we’ve adopted now is to adopt a new number and retire the old number.

Ryan S. said that the reason why we have version number was to figure out situations where there’s an interpretation issue with related sections such as the reuse period. The intent was to capture not only the method used but also the underlying assumptions. That information should be readily accessible and queryable particularly for incidents.

Tim said to no confuse method and BR version. The method needs to be recorded because it can be hard to figure that out but the fact is there is only one relevant version of the BRs at any given point in time.

Dimitris added that it’s even more complicated because the CA must keep track of the BR version at both the time of validation and the time of issuance.

Trev said that she is wondering about how quickly would the CA need to push that version number and asked if timing considerations are part of the goal. She added that if we start to get too specific about expecting these things and doesn’t want to get into another “one-second over” discussion because the requirements are unclear.

Ryan S. agreed with Trev and Dimitris and said that if there are ambiguities then we should absolutely resolve them in a safe way that doesn’t cause a bunch of need for revocations.

Tim said that he was assuming when CAs reuse validations they know the exact time and date where the previous validation was performed. It occurs to me that some CAs might not be doing that. If you are not doing that you are in for a world of hurt, so please do that.

Wayne asked if we want to do anything about the language “CAs shall maintain a record of which domain validation method including relevant BR version number they used to validate every domain.” or assume that the language is fine.

Tim said that the language might be too specific and recommended that we start an e-mail thread for more discussion on the topic.

Wayne took the action to start the e-mail thread.

4. CRL Validity Ballot (SC52)

Wayne said we should restart the ballot.

Tim said that he knows that people have opinions and agreed that the discussion should be moved to the list.

5. Unicode usage - Script spoofing, symbols and other characters
Paul introduced the topic by saying that he shared a report he generated on the list about some issues he detected within subject DNs in relation to the issue from Sectigo on Mojibake encodings or characters in the certificate. Paul said he identified a number of things that don’t look good but aren’t strictly prohibited. This includes Unicode replacement characters, non-principal or zero wide spaces and other characters that clearly do not belong within the organizational name. There are also more advanced issues such as the mixing of scripts such as Greek and Latin.

Paul asked the validation working group if this is something we care about and want to address or do we want to have some guidelines around these encoding issues?

Tim said that it’s vaguely complicated since some of these things are potentially okay but they’re also within spitting distance of security issues.

Paul said that some problems are clearly not okay. Unicode characters should not be in any string and the zero white space character has no meaning within any printed text.

Ryan S. asked if the characters are in the authorized data set. Using EV as an example, if it from the registration authority is that ok? “Garbage in, garbage out” but that’s an upstream problem.

Tim said it’s similar to the “companies house” example. If I register backslash in companies house as my company name is that now my legitimate company name.

Ryan S. to the extent that we accept companies house as a legitimate data source. The question is if this is in the authorized data set. The examples that Paul as raised may indicate that there are breakdowns in CA pipelines or it may indicate that registration agencies are sloppy or liberal and to the extent that we respect the sovereignty of those registration agencies, maybe that’s not our problem. I guess the question is if we tackle this by ensuring that there’s a consistent understanding of what a reliable data source is in the case of OV and what a qualified QGIS/QIIS means in the case of EV then maybe this problem becomes a flag that says you have an ingestion problem but if that is what upstream says, then that is what upstream says.

Tim asked Paul if he wanted to make it a mini-project to figure out what’s good and what’s going on here.

Paul said even if businesses provide data that is encode with errors should we ignore those errors or should we encode our systems to say well this is not the proper data so we can’t accept it. That stance might prevent that subscriber from getting a certificate or going back to their business registration to get information updated.

Tim said those actions might take some time and they might be facing a renewal. We would have to think carefully about the consequences of how we face this.

Ryan S. said that on a technical level as the only thing that matters here is the domain. These have no bearing on a TLS connection so there is a compelling argument that says if these are aligned with upstream then that’s great and if we have a consistent understanding of upstream then we can revisit the question of if those sources are appropriate. Ryan S. said I can appreciate challenging the authority based on the quality but to get there first we have to enumerate who the authorities are.

Tim agreed with Ryan S. and said that the first step is making sure that everybody moves in the direction of better agreement with the upstream sources.

Next meeting is January 27th and will be run by Corey.

Adjourned.




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20220124/99251f27/attachment-0001.html>