[cabf_validation] Minutes of meeting of 9th April

[Robin Alden]

9th April 2020 - Validation subcommittee

4pm UK time (BST)

Minutes - Robin Alden



Present:

Wayne Thayer

Doug Beattie

Anrea Holland

Aneta Wojtczak-Iwanicka

Ben Wilson

Bruce Morton

Clint Wilson

Corey Bonell

Daniela Hood

Dimitris Zacharopoulos

Janet Hines

Joanna Fox

Mike Reilly

Rich Smith

Robin Alden

Ryan Sleevi

Shelley Brewer

Trev Ponds-White

Wendy Brown

Tim Hollebeek



Antitrust Statement was read by Tim H.



Tim:

The thing to talk about first is Information Sources.

Status update about where we are.

People were wanting to know how they could be used before disclosed. - What the process of getting to a full list would look like.



Ryan: I circulated on the serverCert list a draft ballot on disclosure of sources

https://github.com/sleevi/cabforum-docs/pull/11

and

https://cabforum.org/pipermail/servercert-wg/2020-April/001815.html

CAs can issue with whatever sources they want as long as they disclose.

Doesn't require disclosure in the CPS, just public disclosure.

not QIS or QGIS, just recognition of legal existence.



We're trying to find out if different CAs use different validation sources in the same country.

If so, is that because of ambiguity in the language, or different understandings of the legal obligations.

How long do the sources change?

How often are new sources added?



After we have gathered information, work out if we can codify a CA Forum 'allowed' list for sources of legal existence.



Wayne: Doug made a comment suggesting we split into phases since the effective date (September) is pretty close.



Ryan: 2 parts.

1) On the last call it sounded more optimistic that CAs, with 6 months notice, would be able to disclose their sources prior to issuance.



2) We asked about allowing disclosure after issuance.

We discussed that on the previous call, but it sounds like there are further discussions to be had.



Tim: How would 'after-issuance disclosure' work if we allowed it.



Ryan: From github, the suggestion is that in case new sources are needed urgently they should be usable immediately and then the list of sources updated within 30-60 days afterwards.



Doug: We had a similar discussion previously on whitelists.  There may have to be a process to allow retrospective updates until the list can be updated.



Ryan: that was when we talked about having a CABF-wide whitelists

We can get a feel for how often these sources are changing, how often these urgent requests come in.

This doesn't require action by the CABF, just that the CA go to their site and publish the list.

The intent was to figure out what it would look like if the CA is in full control of the timeline.

That was the hesitation to allow the CA to publish afterwards.

Ryan: The intent is that CAs can use whatever they want, but publish before you use.



Rich: Inside CAs, the validation teams will not be aware of this initiative or this repository or the requirement to publish.

All US states register corporations through the Secretary of state.

The location of that website will likely change the next time there is a new Secretary of state.

The source is still the same, e.g. the California Secretary of State, but the website and the link location is different.

Is that a new source we have to declare?



Ryan: No, the intent is that you list the entity - e.g. the California Secretary of State.

Trying to figure out the challenge to timelines, you figure out that this entry for C=US, ST=CA, is the California Secretary of State.

The CA's compliance team will evaluate a source as approved, publish to the allow list, and then use it.

Publish on your website (the CA website, not the CABF site) when you've updated the allow list.

The only requirement is that you publish on your website when you've updated the allow list.



Comments from Rich, Joanna, Trev that immediate website updates are not practicable.

CA compliance department don't control repository websites.



Ryan: We are trying to get transparency because of some CAs making bad calls.



Trev: What if the CA had to disclose the timescale to publication?

Ryan: Problematic because that puts the onus back on the browsers ..



Wayne: Repositories are not highly dynamic content.

You're looking for there to be some level of automation to updating the list so that its relatively easy for a validation group to go through the process and get a website updated.

Classic trade off of automation vs speed of implementation.

CAs may need to do it in a batch process - initially maybe taking a week.

Given time, could be automated, which would meet your goal.



Ryan: Trying to understand the challenges to automation.  Is 6 months to automate a challenge - or is 9 months easier?

This is something you could have in a google sheet and your repository could link to the sheet.

There are a spectrum of options.



Tim: But this is the sort of list that needs oversight so not just anyone can edit and add to the list.

We could force CAs to build a solution to this, but we need all the CAs (even the smallest) to be able to do it.

If disclosure needs to be long enough timecale for the smallest CA to be able to publish the info that means we will have a longer timeline than we might really need.

Whereas if we say 'you have a week or so' means that even a small CA can do it manually.



Ryan: I don't think building a process based on manual gets us to where we need to be, so I'm very cautious about encouraging CAs to go build a process that includes manual updates.

It is very unfair for CAs to build manual solutions, how long will it take to retro-fit that to an automatic solution.

Not sure I understand the problem.

CAs already have a process of vetting that a given source meets the EV guidelines. Escalate to the compliance team, or whatever.  Even if just goes and looks in its own validation manuals.

If your compliance team can edit the sheet and click 'approve' then that should be enough?

I hear you that there is a spectrum of challenges, but don't think manual solutions get us toward systemic industry-wide progress.



Tim: We don't yet have the data to know what the policy will look like.

We don't want to re-run the CAA disclosure, which ended up with everyone adding on the last available day a statement that they didn't do CAA.  I would rather we had more disclosures earlier.



Wendy: Understand the drive to automation but different people have different controls - websites vs policy vs compliance.

Different companies operate differently.  This may not be automatable in near-time.



Ryan: I understand the status-quo but want to change it.  We already have a repository where a number of different pieces of info are published.



Wendy: Similar to the change control mechanism you would like to see, not everyone's change control mechanism will be the same.



Wayne: The proposed change just requires the info to be somewhere on the web and that the location of where to find it to be named in the repository.

We are not talking about regularly updating the repository itself.



Ryan: OCSP is part of the repository, CRLs are part of the repository - so it is not just a legal repository.



Wayne: can be updated anywhere, but the location is pointed to from the CPS or the CCADB.

Ryan pointed out that the proposed ballot is very permissive as to the location.



Trev: Are people more concerned about the time, or about being able to automate?



Robin: It seems that there is a suspicion somewhere that a CA is going to put something into a cert and then when challenged find a new source of information that they will claim that they used as a post-hoc disclosure in response to an incident.



Ryan: concern over CAs ability to reliably disclose post-hoc.  E.g. issuance of subordinate CAs in the CCADB.  That consistently fails to happen.

Any sort of after the fact disclosure gets forgotten.  Is that cert now misissued if 7 or 14 days afterwards you did not disclose?  Good to avoid the opportunity for failure.

Hence make the requirement pre-issuance disclosure.

If there are challenges to getting the disclosure made that sounds like it should have an automatable solution.



Joanne: I have to fight for space on the roadmap to get projects like this done.

Automation like this is not doable without buy-in from engineering & execs.  I think we all need that sort of support.

Implementing automatic updates is not 0 effort and not free.  Just saying the effort is not always trivial.



Ryan: There is always more being asked.  Prioritization.  Is it better to have information sources with a whole load of qualifications and limits, or better to have automation in place?

If you told me CAs do their scheduling in a 5 yr plan, ...   that could mean it might take 5 years to get rid of the next SHA-1.

I do understand.  Trying to understand how we move to an agile ecosystem.

At some point we could just say it takes more resources to be a globally trusted CA.

What would we be sacrificing?  We could do this (an ecosystem good) - or we could do that (e.g. help customers do billing better), and the answer to is always transparency.  I sense that September is hard for automation.  Good to understand where those challenges are.

If we can get it in 6 months with a 7 day post-hoc timeline, maybe that is an acceptable tradeoff in the short term.



Mike Reilly: This is important for our root program as well.  I do want to see solid recommendations on the timeline to get there.

If it's helpful as a forcing program we can have discussion with leadership at the different CAs.



Wayne: The actual ballot doesn't require that the info is in the repository, just that the location of the information is in the CPS.  Maybe we can ask CAs to give that some thought.

I think there is an opportunity to phase this in.  Publication post-issuance from September, and pre-issuance 6 months after that.



Tim: Yes, we can already publish this (because we did), but I don't want the solution to have to wait an extra 6 months while people automate..



Ryan: If looking at a more aggressive phase-in, in 3 months with 7 days post-hoc publication, and automation in a year, at least we've figured out where the boundaries are.  That addresses a lot of the concern for the hesitation.



Dimitris: You mentioned google sheet, what about a github repository? - Is it absolutely anything?



Ryan: Yes, anything! - as per the ballot language.



Dimitris: .. but github isn't us, it's github.  Would that be considered a 3rd party?



Ryan: You're saying that would make them a delegated 3rd party? - That gets to the heart of the question we've had other times, is a CDN or an ISP a delegated 3rd party?  It's a grey area.

It would be 3rd party if you outsource the process of preparing and publishing the information to (say) Accenture.  That feels much closer to a delegated 3rd party.

What you're describing feels closer to the CDN case - and we've not, as a forum, been very clear about whether that is or is not.



Certificate profiles.

Tim: Moving on to the skeleton of the certificate profile.  See the sheet 'Draft Certificate Profiles' linked to from https://wiki.cabforum.org/validation

should we split out required vs. optional? That sort of thing.



Ryan: Yes, that's fair.  I struggled with it because when we get to the Distinguished Name side of things, the formatting on DN is from the BRs.  E.g. Street or Locality.  I was trying to split out the contents of the field, but yes, there are some fields required, some optional, some optional depending on other fields.

1st the conditions when required, when optional

2nd the rules on the content themselves.



E.g. Can you have a non-HTTP URL for the CPS URI?

E.g. If you have a required value in a field, are you also able to have other optional content present in it?

E.g. http URI for AIA.  Can you also have an LDAP URI for AIA?

That has implication for relying parties.  E.g. if http URI must be the first URI.

I wasn't locking in too much on those required / optional fields, until we've fleshed out more of the additional profiles like subordinate CA.

But root CA was easiest because the only place we have those sort of splits is in the DN.

We'll continue to flesh it out with the other cert profiles and the we'll see if that holds generally true.



Ben: What about organizational identifiers in the root? - That's for the EU trust list.  Has that been discussed?



Ryan: Whether or not it is permitted..?

This is an attempt to define a profile, and whether or not that is allowed.

On DN, one of the things to flesh out is 'any other value'.

E.g. in row 15, any other value as defined in the DN section (7.1.2.4)  That's not there yet.  One of the things we talked about on the last call was E.g. Locality is defined for subscriber certs, but it is ambiguous for root and subordinates.

Can a root have it, and if so what are the rules.

If you don't take a default deny perspective, 7.1.2.4 allows you to put whatever other fields you want in.

Another view is that it has to be validated according to the validation rules.

As suggested here, if you have localityName , it 'must contain the subjects locality info as defined by 3.2.2.1'.  That makes sense for a root rather than saying that locality is free-form.



Tim: If you haven't all had a chance to do so please take a look at what Ryan has on the spreadsheet and discuss it on the list to see if we're getting to a reasonable place.



Ryan: The wiki link is world editable for collaboration.

Doug: Comments in the doc?

Ryan: Sure, or follow Tim's suggestion and discuss on the list. Can click on the chat bar (next to share) and subscribe to all notifications.

Tim: Do whatever works for you.  Once you come to a conclusion, put it on the list, maybe.



Wayne: You can 'comment' on a cell, too.  Right click, comments.



Next meeting in 2 weeks.



Regards
Robin Alden

Sectigo Limited



From: Validation <validation-bounces at cabforum.org> On Behalf Of Tim Hollebeek via Validation
Sent: 09 April 2020 15:21
To: CABforum3 <validation at cabforum.org>
Subject: [cabf_validation] Agenda



CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.





1.      Start recording, anti-trust, assign minute-taker
2.      Status update on disclosure of information sources
3.      Continue discussion of certificate profile skeleton



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20200409/53b2a0d3/attachment-0001.html>