[Servercert-wg] Final minutes of SCWG call on Jan 18th

Fri Feb 2 09:54:30 UTC 2024

These are the final Minutes of the Teleconference described in the subject
of this message. 

Server Certificate Working Group Meeting

Attendance:

Yashwanth - eMudhra

Brianca Martin - Amazon

Paul van Brouwershaven

Wayne Thayer - Fastly

Andrea Holland - VikingCloud

Jaime Hablutzel - WISeKey

Marcelo Silva - Visa

Atsushi INABA - GlobalSign

Bindi Davé - DigiCert

Steven Deitte - GoDaddy

Stephen Davidson - DigiCert

Rich Smith - DigiCert

David Kluge - Google Trust Services

Brittany Randall - GoDaddy

Scott Rea - eMudhra

Michelle Coon - OATI

Enrico Entschew - D-Trust

Lynn Jeun - VISA

Kyle O’Malley - Google

Fi Yoneda - JPRS

Tadahiko Ito - SECOM

Rebecca Kelley - Apple

zhangxiao - SHECA

Rich Kapushinski - CommScope

Tobias Josefowitz - Opera

jasmine - SHECA

Bruce Morton - Entrust

Ben Wilson - Mozilla

Adam Jones - Microsoft

Doug Beattie- Globalsign

Bhat Abhishek - eMudhra

Miguel Sanchez - Google Trust Services

Chris Clements - Google Chrome

Alvin.Wang - SHECA

Corey Bonnell - DigiCert

Cade Cairns - Google Trust Services

Nargis Mannan - Viking Cloud

Adrian Mueller - SwissSign

Nome Huang - TrustAsia

Janet Hines - VikingCloud

Johnny Reading - GoDaddy

Marcelo Silva - Visa

Dean Coclin - DigiCert

Martijn Katerbarg - Sectigo

Bhat Abhishek - eMudhra

Trevoli Ponds-White - Amazon Trust Services

Nicol So - CommScope

Paul van Brouwershaven - Entrust

Yihang - SHECA

Rollin Yu - TrustAsia

Clint Wilson - Apple

Peter Miskovic - Disig

Yoshihiko Matsuo - JPRS

Dustin Hollenback - Microsoft

Lucy Buecking - IdenTrust

Karina Sirota Goodley -microsoft

Keshava N - eMudhra

Inigo Barreira - Sectigo

Nate Smith - GoDaddy

Thomas Zermeno - SSL.com

Mark Nelson - IdenTrust

Fi Yoneda - JPRS

Karina Sirota Goodley - Microsoft

Marco Schambach - IdenTrust

Yashwanth - eMudhra

Mads Henriksveen - Buypass

Jos Purvis - Fastly

Dimitris Zacharopoulos - HARICA

Aaron Gable - ISRG

Corey Rasmussen - OATI

1. Minutes:

a. Roll Call

              1. No new members 

2. Membership

a. Sun ShengNan: as interested party

              1. Dean Coclin asked questions and waiting a response

b. CommScope: move from associate to full membership 

3. Review Agenda

a. SC65: EVGs as per RFC 3647 (update)

b. Clarification on organization in EVGs, I.e., VATEL for Greece. (See
ballots)

c. Use of DTPs: Definition clarification, uses,

d. Reversing “whichever is greater” CAA language (Issue #474)

4. Previous Minutes

a. 7 December: Circulated on 11 January

b. 4 January - Minutes have not been circulated yet

5. Read Antitrust Statement

Inigo Barreira read the Antitrust Statement

6. SC65: EVGs as per RFC 3647 (update)

Inigo:

There were comments on the final draft and some sections that were missing,
and I would like to have a short recap. About a month ago, the idea was to
follow the whole section of the RFC, and where it was included in all the
different sections that the docent must follow. For example, change section
1.1 from the scope to overview, just changing the name. The main concern was
the proof of possession of the private key. The section 3.2.1 that has been
include. And that will that meant that we had had to change all the section,
11 into a new, (3.2.2 )it’s basically the same, but just 1 more number. Also
created the others that were remaining, even 2.3 and 2.4. And also a change
in this section 8. All things checked. So the idea behind this updating of
the EVGs, is just to follow well, that's been discussed a lot, so to follow
this RFC, and have all the docents align. So, you see the work of the CAs,
auditors, and group programs. To finally see what is required in those
sections. This been discussed for some time, but in this case, this policy
still needs two endorsers. This is also affecting some other working groups
like Code Signing, and anything that these changes will impact, in some of
the CA CPRs and CPSs, because of the numbering change. If you have any
comments or anything you would like to add or need more time to review,
please speak up for those that have been involved in this discussion.

Clint Wilson:

Does that include also checking other docents referencing sections of the
EVGs or just internal to the EVGs?

Inigo:

I checked the internal ones that I updated, but when clicking on the new
3.2, it's going to the right one, but I can make a double check.

Dimitris: 

I haven't looked at the red line, and I asse that you also proposed changes
to the baseline requirements, right? That have the new references to the new
sections. That's I think that was what Clint was trying to say? (Clint: Yes)
Or are we only changing is your proposal only to change the EV guidelines
docent at this point, or is it also changing at the same time as the BRs? 

Inigo:

This is only for the EVGs

Dimitris:

So, then we need to look at the baseline requirements for any references.

Inigo:

They point to section 11 (that won’t exist anymore if we approve this one),
so, if we want to do or going that way, then it has to be synchronized
somehow.

Dimitris:

You can do it in the same ballot. Actually, updating the BR's is very easy.
You just point to the new references, and we do it both at the same time. We
have changed both docents in one ballot before.

Trevoli Ponds-White:

We can only do that for the TLS BRs, right.

Dimitris:

Yeah, of course, the code signing point to a specific version of the
guidelines.

Trevoli Ponds-White:

Great. So they could just do a ballot after.

Dimitris:

I will try to take a look before the next meeting. Because I did some
similar work in the code signing working group. I'll be able to make some
comments when I take a closer look. 

7. Clarification on organization in EVGs, I.e., VATEL for Greece. (See
ballots)

Inigo:

This is now in discussion period. Ballot 68. 

Dimitris:

We had some discussion about this in the S/MIME working group. There may be
a concern, that we are pointing to a docent that may change in the future
and we may never find out about it. However they were counter argents that
we already point to an iso docent and several other external docents that
may change and the for would not know about that as well. I think Clint was
the one that raised some concerns, but he's going to respond to the list if
he has any stronger feelings.

Clint Wilson:

I think that the explanation provided yesterday addressed my concerns
sufficiently.

Dimitris:

If there are no objections raised during the discussion period, I plan on
starting the voting period right after.

8. Use of DTPs

Inigo:

The use of Delegated Third Parties (DTPs), has been discussed also last week
in the validation sub-committee, and has been also mentioned in other
working groups. I would like to know if there is a need, or do we need a
clarification on the definition of what a DTP is. I would like to get the
other working groups or the validation sub-committee to clarify. I would
like to open the discussion here and see if there's anything that we should
do in this working group, or just leave on to the others.

Aaron Gable:

I think this is most obviously the domain of the validation subcommittee,
which I think is why it was discussed there extensively last week. And why
the current email thread has been forwarded to the validation subcommittee
mailing list. I also think it's a fairly important topic and it's
appropriate to discuss it in the parents working group of that subcommittee.
For folks who haven't been following the mailing list, after the validation
sub committee meeting last week, I put forward a proposal for a single
sentence that could be added to the baseline requirements to make it very
clear that third party recursive resolvers count as delegated third parties
when performing DNS lookups for the purpose of any sort of domain
validation. I don't feel super strongly about the sentence that I proposed.
I just wanted to have a concrete starting point for people to discuss from
there. So far no one has raised any objections to that proposed sentence. I
think at this point, I'm sort of looking for; Do people have specific
feedback on that proposed sentence, either whether we should add it or not?
Also whether it should be phrased differently or not? If people don't have
specific feedback on that sentence, then honestly, I think I would be
looking for endorsers for a ballot to actually add it, because I think it's
a very simple and straightforward path forward from here.

Dimitris:

So, I like that approach. I tried to highlight that in my email in December.
If we see concrete examples, of something that the community considers that
it should not be allowed, like the DNS lookups. Also I would add the whois
APIs, although the BRs are a little bit clearer in that respect, because it
says the CA must directly communicate with the register. However, we could
add that as well in this ballot. More like a clarification for the whois
part. As we go forward and discuss the DTP in the validation subcommittee,
or in this working group, in a more horizontal way. At the same time, we
will have clear guidelines so that others are making similar mistakes. So,
I'd be happy to endorse any ballot that is in this direction.

David Kluge:

The question Aaron, if for me, in the sentence that you posted, it seemed to
generalize it and say that all requests made to. Because if result of us,
operated by third parties, would be deemed to delegate third parties. That
narrows down all just the definition as it is at the moment. One of the
factors that decides over whether it is one or not is whether the resolver
is in the CAs audit’s scope. I wanted to understand a little more is what
why do you think that's insignificant of the proposal that you made, as I
read it, if that wasn't a significant factor.

Aaron Gable:

I think that, if the recursive resolver is used by the CA, are within their
audit scope, that's probably good enough for me. I think this is absolutely
the sort of thing that can and should be workshopped as this moves towards
actual ballot. You're right, there is a distinction between, operated by the
CA and within the CAs audit scope. 

Cade Cairns:

I have a quick question, or remark followed by a question, I guess, in
reviewing the original ballot that introduced this language it seems looking
at the emails. From the time that the intent wasn't so much to limit. Just
DNS and we've also seen some discussions ,or DNS specifically, and it seems
that there have also been some discussions on the mailing list about what
other services might fall into scope. And I'm wondering if we should
consider where to draw the line and be a little bit more specific, rather
than targeting just DNS, as people could make the same argents about the
network.

Aaron Gable:

I absolutely agree. Backing up a second, it is my view that adding this
proposed sentence does not change anything in the BRs, this is a
clarification and that the same. Already exists in the BRs. So, adding
additional clarifications for other services, like email providers, or
whois, or things like that, certainly makes sense, should not be necessary,
but in practice very well, maybe, et cetera, Et cetera. I think from my
perspective, I am more than happy to continue discussion about other
potential services that should have similar clarifications added. But I
don't want to let bike shedding about who is an email services and stuff
like that prevent us from getting a clarification like this into the docent.
And so that's why I started with just this very simple sentence about DNS
only and if we want to have the more complex discussions happen very
quickly, then awesome, let's do it all in one ballot. I was very worried
that they were going to expand the scope and I didn't want to let that
derail this particular one.

Cade Cairns:

That's fair and reasonable. To the earlier points raised about whether or
not it falls into the CAs audit scope. Would ask to include that as an
important consideration, from our perspective.

Mads Henriksveen:

Just from my point of view, but I think it's important to focus on the
external services, which is not allowed to use for domain validation. I
think that's my main concern right now. I'm not quite sure how this fits
with the comment from around the scope of it, but I think it’s very
important to get some clarifications of which type of external services
should not be used for domain validations. And I like the proposal from
Aaron, and I’m happy to endorse this if you want to go for about.

Aaron Gable:

I think the next step here is, I will put together a git hub PR, adding
something very similar to the current sentence, circulate it as a proposal.
And then, I'll wait to get official confirmation from both Mads and Dimitris
that they're willing to endorse that version of the language before, sending
it as an actual beginning of discussion period. I think just so people have
a heads up. I think what I will probably do is I will just change the very
end of this sentence to say, “I E, without the use of recursive resolver is
operated outside the CAs audit scope”, and just leave it at that for this
version.

Dimitris:

Would you be willing to also add some clarification for the whois service,
which has also been discussed in the community.

Aaron Gable:

I would be happy to. I would appreciate it if someone else would draft that
sentence.

9. Reversing “whichever is greater” CAA language (Issue #474)

Inigo:

Moving to the next topic, well, the next two topics. One of the issues we
have in GitHub. Last month, Wayne asked me for discussing this new RFC about
test keys. And the other issue is the latest one from the other day about
reversing the whichever is greater.

Wayne Thayer:

At a high level, I’m concerned about a lack of agreement on what the CAs
responsibility is in terms of being aware of compromised private keys. The
language in the BRs is pretty ambiguous, and in discussion on the list with
Clint, I think it was pretty clear that there was some disagreement in what
the expectations are for the CA.

Dimitris:

Just a quick comment, I think CAs would like to have very clear and specific
rules around what sources should be used to block keys, in any way. Test
Keys and RFC 9500 is a good source. Maybe other sources like that, but it
needs to be as explicit as possible. We also had a ballot for the Debian
wikis, which didn't pass. I don't recall it if this is related as a
proposal. Is this combined with that old ballot or is this something
completely new?

Wayne Thayer:

I think the issues are in different sections of the BRs. So we could tackle
them all together? Yes. But I think they're similar, but slightly different.

Dimitris:

Okay, just wanted to know what the goal is, but if it looks like if there
are different sections, then we can start treating them differently. And if
they meet somewhere in the along the way.

TTL of the CAA records. Whichever is greater in the eight hours

Inigo: 

Continuing with the open issues that I put in the agenda just took the
latest one. Just open two days ago. It's just how we clarify just when
checking the TTL of the CAA records. Whichever is greater in the eight
hours.

Clint Wilson:

I really just noticed this as I was reading through the S/MIME CA ballot
that recently passed, and we voted in support of. So, I don't think this is
something like a pressing issue, but in reading through it kind of struck me
that it seems very counterintuitive to be setting a caching value that could
be greater than the TTL, set on a resource record. The point of the TTL, is
for the DNS operator to set that maxim value. Probably this should have been
whichever is less from the beginning. I'm not sure of the history there or
if there is any there, but it just seemed totally antithetical to the point
of the TTL value in the first place. So that was kind of the first component
of this that that I noticed. The second component of it was the recursive
nature of DNS. Which means that we could be looking up multiple records in
pulling the CAA Record. And it seems like it might make sense to be
honouring those TTLs, like if you're if you're going through and you find a
resource record necessary to resolve the CAA record that has a TTL lower
than that of the CAA record itself. It seems like that's sort of the value
that we should be pulling as the caching value. Because it's required to
pull the CAA Record itself. So that is the kind of the second part of it.
The first part, I feel more confident on, like, the whichever is less it
seems correct and then the recursive thing, I think maybe it's is correct
but I'm not as confident there.

Aaron Gable:

This is the thing that has also struck me as odd multiple times in my head.
I convinced myself that it actually made sense. And I don't know if this is
historical reasoning. The thing that convince me that it made sense is that
looking up CAA Records is quite expensive. You might have to query many
different DNS names as you work your way up the chain. If you don't find a
CAA Record at any of the more deeply nested subdomains. And so, to me, the
whichever is greater language made sense as a form of, if there was a long
TTL on this, then you can respect that TTL. But if there's a very short TTL,
you can still reuse the value you found for up to eight hours similar to how
the BRs in general allow you to reuse the fact that you looked at the text
record for 398 days. It’s just a very short version of the validation docent
reuse. So that's how I convinced myself that the existing language made
sense to avoid doing very expensive CAA queries, like every few minutes.
Regarding your second point, I don't think there's a lot of purpose in
keeping track of a bunch of different TTLs that you look up as you traverse
upwards. As you traverse up, towards the root zone starting from this deeply
sub domain, the results of the CA lookup at each of those points are either
no record or some record. If there is some record, then you respect that
one, and if there is no record, then there's not a TTL on no record. So I
think we only have to care about the TTL of the CA Record you actually use.

Clint Wilson:

To your first point, that does make some sense. I was just thinking of it
more in like, DNS land and the first part is DNS land and the second part of
the sentence is BR land, and it’s like two separate things. Like, we're not
saying, ignore the TTL, we’re just saying reusing the data that’s been
pulled as validation evidence. For the second part, that was kind of a
similar conclusion that I came to. I don't know that this would actually
change anything for anyone, if you're doing this recursive resolution of DNS
records. You're basically going to find one record that has a TTL, but then
it did seem like there were possibly circumstances where there would be DNS
records that you relied on. 

Tobias Josefowitz:

I wanted to mention the delegations, I definitely have some like 10 minute
delegations, right? And okay, so they could change and then control could
change and the CA Record could in that sense be outdated. 

Corey Bonnell:

It's not an issue filed on GitHub and definitely had some thoughts about
some of the rationale and proposal being discussed. My understanding of the
TTL, is that it's a directive to DNS revolvers on how long they can cash the
retrieved record. It's not really a limitation on the end user application,
retrieving the record and how long they can use it. So, you know, kind of a
simple example that demonstrates that is someone that has a CAA Record, with
a TTL of zero, which means it's an instruction to a DNS resolver to not cash
that record, and catch it (retrieve it) fresh every time it's looked up. A
TTL of zero would mean, though, if we extend that the CAA processing would
mean that it would be impossible to get a certificate issue because the
record would immediately expire. So, I think eight hours might be a bit
long, but my understanding is that there Is there so domain owners that do
have a of zero or a very, very small amount measured in seconds, are still
able to get certificates issued. But the eight hours is sufficiently fresh
so that there is a change in the DNS, the CA has to respect it.

Clint Wilson:

I think that is reasonable. What Aaron said; sort of safety buffer for CAs
to not need to just constantly query. I think that separation in my mind of
just this is like a BR provision, rather than a DS provision. It’s
downstream use of the record. Not actually caching the record itself. 

Martijn Katerbarg:

I kind of agree. I'm not against switching it around, but in that case, I
think maybe we need to state that. There's still a minim amount of time that
could reuse it. Exactly. For the cases where maybe TTL is 10 seconds or
less, or something like that. Tentative being leave the language as it is,
but add a maxim time because I think that the real problem we could see here
is that someone could have said a TTL for 25 years. And then could use the
same record for 25 years and I'm thinking that's exactly the type of thing
we do want to prevent. So, maybe if we don't want to switch it around, we
should probably, at least at a maxim to that to what we're going to allow.
So either minim or maxim, and I support right away.

Aaron Gable:

I personally really like the number of eight hours, simply because Let's
Encrypt would like to reduce our domain control validation, docent reuse
timeline to exactly match the CAA timeline. So we are either checking domain
control validation and CAA at the same time, or reusing both and never
reusing domain control validation, by having to recheck CAA just for
simplicity purposes. Reducing it below eight hours would start making that
comparatively difficult. Obviously not impossible, there are CAs that never
do domain control validation reuse at all, but our scale having some amounts
of reuse is very handy for us. I prefer to not reduce it below eight hours,
But that's a very weak reference that certainly could be overruled by other
factors.

Valid Status

Inigo:

All right, move to the next topic, which is the valid status. So we have
some bullets under consideration. So we have come in their discussion
period, but there are some others that are. Almost there. Let's start from
the last one, the update of logging requirements. I think that is proposed
by Martijn.

Martijn Katerbarg:

So we have this discussion about two months ago. the update language
basically brings a must log and should not log provision to specifically the
firewall and regular activities. And, yeah, could 1 endorser at this point I
don't know if anyone has other comments or suggestions on it if not. We're
looking for another endorse or to see if we can move forward on that valid.

Inigo:

Moving on, the next one which is being proposed by Aaron.

Aaron Gable:

Yes. So the current status on that is that the mailing list thread has some
people expressing that they support the currently proposed language, there's
a little bit of ongoing discussion on the get hub pull request, but no
definitive conclusions over there yet. I am still seeking endorsers, but if
people want to take a look at the pull requests to the proposed language
there, and decide whether or not they want to endorse, then we can get it
moving towards official discussion period.

Inigo:

Another one was about subscriber agreement and terms of use consolidation. I
don't know the current status of this one.

Ben Wilson: 

So that's Ballot 67. I need to touch base with Dustin. I think he's on the
call, but we haven't touched base since the holidays, and it hasn't started
discussion yet.

Dustin Hollenback:

I'll schedule a meeting with you.

Inigo:

Here was another one, which was about the profiles clean up.

Corey Bonnell:

There's been no real progress on that since October. It sounds like there's
been a couple of discussions and GitHub on for the refinements to the
certificate profiles. Some of which might involve normally requirements
changes. I think there was an issue on key usage changes that might affect a
couple of CAs that a couple folks were looking to see pulled into the BRs.
So, I'm wondering if it’s actually more expedient to kind of treat this
ballot is like a profiles ballot 2.0, And expand the scope a bit.

10. Other Business

Inigo:

let's move on to the next Item, which is any other business.

Dimitris:

I'm just going to mention that the working group needs to start working on
the agenda for the next face to face. So if people have any thoughts,
there's a draft agenda on the wiki, and start proposing additional topics
that you may want to cover.

Inigo:

Next call will be February 1st.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20240202/e5bceea5/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6630 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20240202/e5bceea5/attachment-0001.p7s>