[Cscwg-public] Final minutes of CSCWG Jan 13, 2022

[Corey Bonnell]

I believe these are the minutes for the January 27th meeting. The minutes
for the January 13th meeting were posted and published about a month ago.

 

Thanks,

Corey

From: Cscwg-public <cscwg-public-bounces at cabforum.org> On Behalf Of Dean
Coclin via Cscwg-public
Sent: Thursday, February 24, 2022 12:31 PM
To: cscwg-public at cabforum.org
Subject: [Cscwg-public] Final minutes of CSCWG Jan 13, 2022

 

Here are the final minutes for the subject call

Attendance: 

Andrea Holland - SecureTrust , Ashish Dhiman - GlobalSign, Atsushi Inaba -
GlobalSign, Bruce Morton - Entrust, Corey Bonnell - DigiCert, Dean Coclin -
DigiCert, Dimitris Zacharopoulos - HARICA, Ian McMillan - Microsoft, Inigo
Barreira - Sectigo, Jeff Ward - WebTrust, Karina Sirota - Microsoft, Kiran
Tummala - Microsoft, Michael Sykes - SSL.com, Mohit Kumar - GlobalSign, Tim
Crawford - WebTrust, Tim Hollebeek - DigiCert 

Minutes of January 13th 2022 approved.

 

Interested Party Request

Bruce: A request to join as an Interested Party, this person is a sole
proprietorship. No reason to reject. Dean confirmed information and voiced
approval. HGMS Information Technology Solutions out of the Philippines.

Tim H: No objections.

 

CSC-6 Subscriber Key Protection 

Ian: We were waiting for feedback. Tim said he had feedback from some folks
and Bruce pointed out timing that current deadline is September 1st and
should be pushed out by 3 months. So I changed it to December 1 2022.

Tim H: Not a compliance friendly date. 

Bruce: Why is that?

Tim H: It is into the holiday code freeze season. It isn't the worst because
we could finish early, but I would be happier with November 15th if we want
that date area.

Ian: Go right before Thanksgiving?

Bruce: I think the 15th works fine with me. Of course, it could be done
before the date not on the date. So, I think November 15th is available even
if we said the date is December.

Tim: I would like us to set a precedent to not have compliance dates between
like November 15th and January 15th. It would be great if we could agree
forum wide on some popular compliance dates and just have 6 of them
scattered across the calendar so we don't have to keep having this
conversation.

Ian: That would be great. I am good with November 15th. Everyone good with
that as well?

Tim H: Most of the internal comments, there are a lot of them, are mainly
word smithing and tweaking to get the language to match the intent. Don't
expect any substantive changes. They are all important changes but there are
no bombs or opening up any new discussion topics. We are just fixing it so
it looks better. Providing it tomorrow

Ian: I will update draft with new date and Tim's feedback. Then send out a
draft and asking for endorsers.

 

Timestamping Certificate Validity Period

Ian: Today the max validity period with the certificate is 135 months. For
windows and how we consume the timestamping certificate the 11.25 year has
no true barring on whether the timestamp is actually valid to us. Tor the
timestamp counter signature is actually valid to us. We look at the time of
the timestamp and the certificate's validity period of not only the
timestamping authority's endpoint signing certificate but also the code
signing certificate. And if that time is within those certificates validity
period it is good to us. The question that has come up with is does his jive
with what Java sees. I followed up with some java people and they said they
ignore it.

Bruce: They state that if the CS cert is expired or revoked then the
signature is not valid any more irrespective of whether it was time stamped
or not. You can have a long, long, timestamp on it and it doesn't matter
because it is all based on the CS cert and not on the timestamping
certificate.

Ian: For us internally and what you see on like Windows or any Microsoft
signed files that we are timestamping with our own timestamping authority
the max validity period of those is 12 months. That proves that we have been
doing it for many years and there has been no issues from that. There is no
reason for us to require people to carry 11.25 years timestamping
certificate for an end entity signing.  Granted one of things in the CSBRs
that account for the key rotation hygiene is the requirement to rotate the
keys for a timestamping end entity certificate every 15 months. Dimitris and
folks have brought up what is wrong with those keys not being rotated and
just using the full 135 months validity period. And just using that key pair
going forward because we protect it with the same level as an offline CA.  

Tim H: Both perspectives are correct. Current situation is the worse of both
worlds. We could have 11 year timestamp certificates that we could use for
all 11 years or 1 year timestamp certificates that we use for 1 year. We
shouldn't have timestamp certificates that have 11 year expiration date, but
you can only use for 1 year.

Ian: My perspective is I do not like the 11 year validity. I am okay because
we are rotating or requiring rotation every 15 months of those key pairs.
But you still have a key pair and a certificate that is going to be valid
for 11 years, so if those get lost it is still valid and usable. I prefer
the model where we have max validity is 15 months for the end entity
certificate and you rotate that certificate every 15 months. Because that
certificate that key pair are highly used and anyone can use them. Every TSA
out there is publicly accessible to anybody authenticated. 

Tim H: I would also like to mention the fact that we have an upcoming crypto
transition. As far as security properties I don't think this is largely
relevant, but the optics of issuing 10 year TSA certificates right not
especially moving from what we are doing right now to 10 year validity TSA
certificates seems unwise.

Ian: Yup.

Dimitris: Why are you saying that about the TSA? How are the TSA different
from the SubCAs.

Tim H: It is a weak preference and mostly about optics. Everybody is
rotating their keys every 15 months right now anyway. I think we should just
stick with that.

Dimitris: Do you mean the end entity TLS certificates or the code signing
certificates. TSA are quite longer

Tim H: You are only suppose to be using them for first 15 months.

Corey: The key cannot be 15 months.

Dimitris: Right, but the certificate lives for 10 years.

Tim H: For no reason, yes. The actual reason is because people were
concerned that there were applications out there that was checking the
validity of the TSA certificate in the future for verifying the signature as
opposed to verifying the validity of the TSA signature at the time of the
signature which is the correct way to do certificate checking. So the
requirements are actually wrong and we should just fix them.

Dimitris: Right but what did Oracle say, they don't check the TSA. They just
stop executing the code if the signing certificate is expired.

Bruce: Correct. It is the same discussion when we asked them about
invalidity. They don't actually care when the certificate is revoked, if the
certificate is revoked all signatures are bad.

Dimitris: Just had a discussion on the Validation Subcommittee about OCSP
and the keys associated with the OCSP responders. Which are suppose to be as
protected as the SubCA. There was a question whether it would be okay to
reuse that key for a subsequent certificate. I could renew a certificate for
the same key pair for another 15 months then another 15 months always
reusing the same key pair. 

Bruce: So I think that we should apply the same, right? I think as Ian says
we should have the smaller validity period, but since the keys are protected
at the same level as a SubCA the keys do not have to be rotated.

Tim H: Agreed.

Bruce: That is thew same thing you can do for an OCSP responder assuming
that you keep the key ON the HSM. 

Ian: The only problem I see with that is the timestamp certificates like our
own for instance. We use it well over 1 billion times a month like 3-4
billion times per month. From a crypto attack perspective it is
significantly weaking the guarantees we can make on that key pair.

Tim: Why use the word significantly? That number of signing operations
doesn't affect the security of the key according to any research I am aware
of.

Ian: From our own crypto analysis folks inside of Microsoft 

Tim H: I would like to see their analysis of why they think that

Ian: I can follow up with them and discuss it, but I know from our own
policies we don't reuse keys.

Tim H: I applaud you for doing that, because if you're doing high volume
signing like that it is a good idea to rotate like you're doing. But I think
it is being rotated because of good hygiene not because there is actually
any possible decrease in the security of the key.

Ian: Primarily we do it for hygiene wise policy wise because it has come
down from the crypto experts.

Tim H: We could go in that direction. So the key rollover for other types of
certificates is actually a much furrier topic, but these are certificates
controlled by the CA. So it would be relatively easy with enough transition
time to expect key rollover for these TSAs.

Corey: Primary difference is the current CSBRs contemplate a scenario where
the TSA key can be compromised. But since these are stored in a level 3 HSMs
at the same security level that a ICA would be, we are not particularly
concerned about a key compromise. Am I understanding the rationale
correctly?

Bruce: Yes.

Tim: Yes and no. We are concerned in the same way as a CA key compromise.
You are dealing with an entirely different type of recovery.

Corey: On positive benefit with a mandated key rollover you're are limiting
the scope of signed application code and the impact. For example, you use a
key pair for 10 years and your CA gets compromised. You now have to
blocklist 10 years of signed timestamp tokens. Now everyone has to go a
resign and maybe the software vendor doesn't exist anymore. Whereas if it is
15 months, you just have a year of compromise and affected software code and
that is a big difference. 

Tim H: It is, and that is why I think it is a good idea for key hygiene.

Bruce: But if the attack is on the HSM where both the subordinates CA key is
and the TSA key is. What if they just do the subordinate CA key instead 

Tim H: Right

Corey: CSBRs are currently written is timestamping ICA is supposed to be
offline key material treated the same way as a root CA is. If you are
following that design then that shouldn't be possible. A compromise at the
end entity TSA key pair won't necessarily be TSICA key compromise. 

Tim H: Is there a realistic scenario where an attacker is able to get a hold
of that and doesn't get a hold of the root key, which is managed for the
same controls? Why am I worried about the TSA key if I have popped that HSM?

Corey: Because that one necessarily has to be online, but the ICA and
associated root key material would be in the offline CA.

Ian: End entities are online and available for attack no just physically but
logically, for anyone on the network versus ICA is offline in an air gapped
environment.

Corey: Yes, This is one place where CBRS are unclear on this point. But
given you only have to issue CRLs corresponding to TSICAs only once a year
like you do for offline roots. They do envision that you do put your TSICA
key material offline, but it is not very explicit. You have to read between
the lines.

Tim H: Let's fix it to be explicit and maybe we make mandate rollover a part
of it.

Dimitris: W still need to consider OCSP in that regard as well.

Tim H: That is a related topic. Whether we want to do rollover for OCSP is
an interesting question that has a different security analysis. The 11 years
confuses people so if we could fix that that would be awesome. 

Bruce: Where do we go from here? Keep discussing or drafting a ballot

Tim H: How do people feel about rolling over keys for timestamping, we are
fine with it, but we are only one voice.

Dimitris: I don't like it very much since EIDAS doesn't require rollover
timestamping certificates. I don't have strong pushback.

Tim H: How would you feel if there were a separation of EIDAS timestamping
servers and code signing timestamping servers, so you didn't have to satisfy
both?

Dimitris: We are doing that the last year. We had to separate our
Timestamping Authorities because of different rules. We are going to have to
have a separate key rollover rule for codes signing timestamping and not
rotating for the other. I think that was the reason we added the policy OID
in our certificates, right?

Bruce: Do we want to pause on this?

Corey: It is worthy of further discussion, Maybe after we get the key
protection and the format change we can have a follow up discussion and
ballot to clarify the aspects around the timestamp authority operation.

Bruce: Okay we will pause on this and bring it up after Ian's ballot and
formatting change are done.

 

Time stamping policy OIDs

Tim H: We were looking at the recent ballot, it appears we have written the
ballot so that the policy OID indicating that a timestamp server is
acceptable for code signing. Written in such a way that you must add the
timestamping policy OID to every single timestamping end-entity certificate
you have out there. Just because it chains up to a Microsoft trusted root
and not because it's particularly intended for Microsoft code signing and in
particular there are a lot of those out there that are intended for EIDAS or
other use cases. And the entire goal was to split these apart. It appears
that we made a mistake in the ballot and if you are trying to split them
apart, that you would have to split them apart all the way up to the chain
to a non-Microsoft trusted root, which is not what I think we intended. I
was wondering if other people had the same interpretation or whether the
goal was that you are suppose to find your timestamping end-entity
certificates that are intended for Code Singing, so that Microsoft can later
distrust the non-intended ones. If we just add that OID to every single
end-entity timestamping certificate out there we haven't really changed
anything. I wondered what people thought of that and whether we need to
update the language to say that in order to be used for Microsoft, in order
to be used for CA/B forum, code signing OID must be present as opposed to
just this OID must be present.

Inigo: We are thinking always use the timestamp as long ca be used with the
signature. It doesn't matter if it's signing a code or signing a document.
The timestamping itself is a service. You can timestamp a document without
putting a signature on it or timestamp anything. It has to have it's own
OID. When it is related to CA/B Forum which is mainly used only with code
signing that is different. But the service itself is another service, you
can have CAs that issue certificates and TSAs that issue timestamps and you
can combine both, but both are different.

Tim H: From a technical point of view, you are right. And that is the
problem we are trying to solve. It is possible today to arbitrarily use any
timestamping server with any arbitrary code signing certificate. The problem
that the timestamping server that you are pointing to might not be managed
in accordance with the guidelines of the CA/B Forum Code Signing Working
Group and Microsoft's rules. There is no way for Microsoft to tell which
TSAs are managed in accordance with these guidelines and which are managed
in accordance with EIDAs guidelines for example, which may say different
things about key protection and key rollover and things like that. We need
to know which TSA are being operated under the rules of Microsoft Code
Signing. Adding a policy OID seems like a great way of doing it, but if CAs
add it to every single certificate that chains up to Microsoft like the
current ballot appears to be forcing them to do then we have gained no new
information about which ones are intended to be Microsoft timestamping TSAs
and which should be trusted and which are not compliant with Microsoft
timestamping and should not be used for Microsoft code signing.

Inigo: Well I might agree to have specific OIDs for timestamping similar as
we have for CAs.

Tim H: If you have an EIDAS TSA which is not in compliance with CA/B Forum
CS, and therefore cannot have that policy OID, are you required to have that
policy OID just because it's chained to Microsoft?  IF I have TSA that I
don't want to add that OID to because it's not managed according to those
policies and would fail the audit. Do you have to issue it off a completely
different root that is not trusted by Microsoft because I don't want to add
this OID because it not appropriate? And would specify that this certificate
is managed in this way. I think we messed up on the ballot.

Bruce: This document states how subordinate CAs are suppose to be done to
issue code signing certificates and how subordinate CAs are suppose to be
done to issue timestamp authority certificates. This document tells us how
to operate at timestamp authority. Trying to say that this item was signed
using a TSA that meets all the requirements. I am not understanding the
problem, you are saying we have to do it for all?

Tim H: The way the requirement is stated it would exist for any timestamping
end-entity certificate that happens to chain, though any path, to a
Microsoft trusted root, right?

Bruce: Where did you get the Microsoft trusted root, how did you extend
that?

Tim H: That is the only way I know how to determine what the scope is for
this particular baseline requirements. The CSBR scope is everything trusted
under Microsoft CS trusted roots, right?

Corey: To Tim's point, if you look at the audit requirements in the
Microsoft root program policy you are going to see that non EV code signing
and timestamping certificates have to have a CSBR audit. The way it is
currently written there is no carve out for TSA certificates and the ICA
certificates that don't have this OID. Right now there is an obligation to
put this in universally if you chain up to Microsoft which I don't think was
the intent.

Dimitris: I am confused though, I don't think there is requirement in the
current CSBRs that a timestamping certificate must have this OID.

Tim H: if you can prove this to me, I would love to be proved that are
reading is wrong.

Dimitris: Shared current CSBRs. Highlighted Appendix B. Section (5)
Timestamp Certificates A. certificatePolicies bullet 1.

Tim H: That is one part of it.

Corey: If you go up to the TLS ICAs profile you can see it is applicable to
all TLS ICAs issued after March 31st of this year.  

Dimitris: It is for the ICAs not for the timestamping certificate. 

Corey: If you want your policies to chain then you will have to include that
in the end entity.

Inigo: Another alternative would be to have all TSA be audited and
certified. And be presented to the Microsoft root stores like another CA. So
only those certified could be included. 

Tim: I think that was the intent to use the policy identifier in the
timestamp certificates in the same language that Dimitris showed, which was
very helpful, thank you. That was the intent we want by asserting the policy
OID in the timestamping end-entity certificate you are asserting this is a
compliant CSBR timestamping end-entity certificate and not just a random
timestamping certificate. 

Dimitris: There can be requirements in the EIDAS TSAs that are in compliance
with CSBRs.

Tim: Yeah, one could imagine complying with both. But one could also imagine
not complying with both an we think that should be allowed as well.

Bruce: We should propose a change in text. It would be less restrictive and
not more restrictive.

Corey: Even if we do that, there would have to be a modification to the
Microsoft root program policy because that is where the audit obligation
comes from. A carve out needs to be added to exclude TSA certificates issued
after this date that don't contain the policy OID. 

Inigo: The current requirements for the timestamps are very few.

Tim: It should be a minor change, but wanted to discuss it with everyone
before we started writing language.

Ian: Would like to see the language so we can review and figure out what we
would like to see done.

Tim: Are you okay if we propose draft changes to Microsoft policy?

Ian: We would love to hear your opinions, of course.

Karina: Are policies are not set in stone. We have had many of you on this
call reach out and say something you wrote doesn't make sense, so feel free
to reach out at any point. We have a whole gang of people to read over it
and see what we can do.

Tim H: Thank you.

Dimitris: Thank you that is great feedback. Karina, do you want us to send
you individual proposed changes or if we could discuss this in the CAB forum
or not

Tim H: We are one of the people who often discuss these things privately
with Microsoft and so I wanted to get people to agree that it's okay to
discuss Microsoft policy publicly on the CAB Forum mailing list because I
think it would be quite useful.

 

F2F Agenda

Bruce: We have 2 hours slotted for the meeting. Items that we wanted to talk
about was the Signing service.

Dean: At F2F, we are asking each working group to do a short presentation on
what they accomplished in 2021 and what they want to accomplish in 2022, can
be ballots passed or proposed. It should be 2-3 slides max and around 10-15
minutes. We want to plan for a 2-hour slot for whatever topics we want.

Bruce: Dean when should we talk about what we want to do in 2022? Is that
now or at the next meeting?

Ian: We have at least one more meeting. 

Bruce: February 10th.

Dean: We can start discussing now and continue it to next time.

Bruce: I know we have been working on it for a while, but the subscriber key
protection, reformatting, and signing service. Those are 3 items we want to
do.

Tim H: Are we mostly done with key protection? Signing service is a great
one, since we will be working on it through most of this year. 

Bruce: It doesn't hurt to put it there as it doesn't go into effective until
November 15th.

Tim H: Fair.

Bruce: and as an introduction. I would like to do some rationalization once
we have the document in the new format, to remove the references to the SSL
BRs and EV guidelines and fix with one liners or adding the text.

Tim H: Is your goal to make the document stand more independently?

Ian: I would love to see that.

Tim H: That is a reasonable priority.

Bruce: Make it readable.

Ian: We are still locked in on version 1.6.9 for the TLS BRs we should be
all the way to the current version and creating a cadence of being able to
keep up.

Tim H: We are in good shape since not a lot has happened there that is
relevant here. Another related discussion topic though is the ongoing
discussion int the Net Sec WG about how to keep the network requirements
uniform across all the working groups. That will heavily impact this working
group.

Ian: We already bound to the latest version

Tim H: Yes, Problem with that that Google has an issue with the server cert
side.

Ian: If all the working groups say we are good with this version than we can
all stop and dissolve the NetSec WG. Otherwise, you'll end up with 3 working
groups with 3 different versions but I am one CA so how would that be
implemented.

Tim H: That is what I brought up but a couple of months ago. Freezing works
very well for external references it doesn't work very well for the NCSSRs.
So having each working group try to independently pick what version number
they are using is a recipe for disaster.

Ian: The NetSec document should be the minimum to cover all that the
browsers and operating systems want and each WG could put in more specific
items.

Tim: I was saying we should fix versions because that is best practice in
the industry. Because this divergent problem across the NCSSRs I think the
NCSSRs are special. It is just the same group of people on a different
working group. We should let them roll across all the working groups and if
you don't like something that is coming in the next version it go to NetSec
WG and argue against it. If it passes the NetSec WG, it is independent
enough, we should just grab the current stuff. What the auditors going to
think if NetSec passes something then we need 3 different WG to apply it and
decide if it is appropriate or not to include it in their document at 3
different times. version

Ian: What are you going to do as a CA you are just going to go with the
latest version and implement.

Tim H: CS is going about it the right way. Just have to convince everyone
else.

Tim C: We are planning on making it a standalone document and standalone
audit requirement. Being in different versions would really subvert that.

Bruce: Where were we going with that?

Tim H: Unless other working groups disagree, I think code signing has it
right and there is nothing this WG has to do. I wanted to raise it here for
awareness in case we go a different direction. 

Bruce: I thought we were linking it something we wanted to accomplish this
year?

Tim H: I think I took us on a siderail.

Dimitris: Deprecated the existing EV Code Signing guidelines. 

Tim H: Retiring in favor of the merged document.

Dimitris: There are two documents the CSBRs and the old one is still in
effect theoretically. We have stopped updating it.

Bruce: Is it not already deprecated? We are not updating it and we aren't
auditing against it?

Dimitris: In ETIS for several years we had the TS standard then we had the
EN ETSI 411 part one that we were audited against, but there will still some
CAs audited against the old one. They were accepted because most of the
standards accepted the old ones. I don't think the Microsoft program has
been updated to require the new.

Tim H: One last amendment that they are out of date and point to the new
doc.

Dimitris: That is what I had in mind.

Bruce: Added to the list. Finalize these items in the 10th meeting. Our
meeting would be on the 24th at the F2F. We can prepare the slides between
the 10th and the 24th. Any other items on the agenda.

Dean: Last call for F2F for in person, there are still slots available.
Vaccine cards are required and masks must be worn. 

 

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20220228/49a5f3d8/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4990 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20220228/49a5f3d8/attachment-0001.p7s>