<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=us-ascii"><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:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin-top:0in;
margin-right:0in;
margin-bottom:8.0pt;
margin-left:0in;
line-height:105%;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@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>I believe these are the minutes for the January 27<sup>th</sup> meeting. The minutes for the January 13<sup>th</sup> meeting were posted and published about a month ago.<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><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal style='margin-bottom:0in;line-height:normal'><b>From:</b> Cscwg-public <cscwg-public-bounces@cabforum.org> <b>On Behalf Of </b>Dean Coclin via Cscwg-public<br><b>Sent:</b> Thursday, February 24, 2022 12:31 PM<br><b>To:</b> cscwg-public@cabforum.org<br><b>Subject:</b> [Cscwg-public] Final minutes of CSCWG Jan 13, 2022<o:p></o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Here are the final minutes for the subject call<o:p></o:p></span></p><p class=MsoNormal><b>Attendance</b>: <o:p></o:p></p><p class=MsoNormal>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 <o:p></o:p></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Minutes of January 13<sup>th</sup> 2022 approved.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Interested Party Request<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Tim H: No objections.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>CSC-6 Subscriber Key Protection <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Ian: We were waiting for feedback. Tim said he had feedback from some folks and Bruce pointed out timing that current deadline is September 1<sup>st</sup> and should be pushed out by 3 months. So I changed it to December 1 2022.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Tim H: Not a compliance friendly date. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Bruce: Why is that?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>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 15<sup>th</sup> if we want that date area.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Ian: Go right before Thanksgiving?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Bruce: I think the 15<sup>th</sup> works fine with me. Of course, it could be done before the date not on the date. So, I think November 15<sup>th</sup> is available even if we said the date is December.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Tim: I would like us to set a precedent to not have compliance dates between like November 15<sup>th</sup> and January 15<sup>th</sup>. 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.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Ian: That would be great. I am good with November 15<sup>th</sup>. Everyone good with that as well?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>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<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Ian: I will update draft with new date and Tim’s feedback. Then send out a draft and asking for endorsers.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Timestamping Certificate Validity Period<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>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. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>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. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Ian: Yup.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Dimitris: Why are you saying that about the TSA? How are the TSA different from the SubCAs.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Dimitris: Do you mean the end entity TLS certificates or the code signing certificates. TSA are quite longer<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Tim H: You are only suppose to be using them for first 15 months.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Corey: The key cannot be 15 months.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Dimitris: Right, but the certificate lives for 10 years.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>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. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Tim H: Agreed.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Bruce: That is thew same thing you can do for an OCSP responder assuming that you keep the key ON the HSM. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Ian: From our own crypto analysis folks inside of Microsoft <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Tim H: I would like to see their analysis of why they think that<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Ian: I can follow up with them and discuss it, but I know from our own policies we don’t reuse keys.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Ian: Primarily we do it for hygiene wise policy wise because it has come down from the crypto experts.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>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?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Bruce: Yes.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>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. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Tim H: It is, and that is why I think it is a good idea for key hygiene.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>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 <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Tim H: Right<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>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. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>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?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Corey: Because that one necessarily has to be online, but the ICA and associated root key material would be in the offline CA.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Corey: Yes, This is one place where CBRS are unclear on this point. But given you only have to issue CRLs corresponding to <span style='text-transform:uppercase'>TSICAs</span> 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.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Tim H: Let’s fix it to be explicit and maybe we make mandate rollover a part of it.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Dimitris: W still need to consider OCSP in that regard as well.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>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. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Bruce: Where do we go from here? Keep discussing or drafting a ballot<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Tim H: How do people feel about rolling over keys for timestamping, we are fine with it, but we are only one voice.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Dimitris: I don’t like it very much since EIDAS doesn’t require rollover timestamping certificates. I don’t have strong pushback.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>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?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>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?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Bruce: Do we want to pause on this?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Bruce: Okay we will pause on this and bring it up after Ian’s ballot and formatting change are done.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Time stamping policy OIDs<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Inigo: Well I might agree to have specific OIDs for timestamping similar as we have for CAs.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>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?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>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?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Bruce: Where did you get the Microsoft trusted root, how did you extend that?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>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?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Dimitris: I am confused though, I don’t think there is requirement in the current CSBRs that a timestamping certificate must have this OID.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Tim H: if you can prove this to me, I would love to be proved that are reading is wrong.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Dimitris: Shared current CSBRs. Highlighted Appendix B. Section (5) Timestamp Certificates A. certificatePolicies bullet 1.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Tim H: That is one part of it.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Corey: If you go up to the TLS ICAs profile you can see it is applicable to all TLS ICAs issued after March 31<sup>st</sup> of this year. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Dimitris: It is for the ICAs not for the timestamping certificate. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Corey: If you want your policies to chain then you will have to include that in the end entity.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>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. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>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. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Dimitris: There can be requirements in the EIDAS TSAs that are in compliance with CSBRs.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Bruce: We should propose a change in text. It would be less restrictive and not more restrictive.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>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. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Inigo: The current requirements for the timestamps are very few.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Tim: It should be a minor change, but wanted to discuss it with everyone before we started writing language.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Ian: Would like to see the language so we can review and figure out what we would like to see done.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Tim: Are you okay if we propose draft changes to Microsoft policy?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Ian: We would love to hear your opinions, of course.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Tim H: Thank you.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>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<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>F2F Agenda<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Bruce: We have 2 hours slotted for the meeting. Items that we wanted to talk about was the Signing service.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Bruce: Dean when should we talk about what we want to do in 2022? Is that now or at the next meeting?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Ian: We have at least one more meeting. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Bruce: February 10<sup>th</sup>.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Dean: We can start discussing now and continue it to next time.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>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. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Bruce: It doesn’t hurt to put it there as it doesn’t go into effective until November 15<sup>th.<o:p></o:p></sup></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Tim H: Fair.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Tim H: Is your goal to make the document stand more independently?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Ian: I would love to see that.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Tim H: That is a reasonable priority.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Bruce: Make it readable.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Ian: We already bound to the latest version<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Tim H: Yes, Problem with that that Google has an issue with the server cert side.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>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<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Ian: What are you going to do as a CA you are just going to go with the latest version and implement.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Tim H: CS is going about it the right way. Just have to convince everyone else.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Tim C: We are planning on making it a standalone document and standalone audit requirement. Being in different versions would really subvert that.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Bruce: Where were we going with that?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>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. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Bruce: I thought we were linking it something we wanted to accomplish this year?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Tim H: I think I took us on a siderail.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Dimitris: Deprecated the existing EV Code Signing guidelines. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Tim H: Retiring in favor of the merged document.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Dimitris: There are two documents the CSBRs and the old one is still in effect theoretically. We have stopped updating it.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Bruce: Is it not already deprecated? We are not updating it and we aren’t auditing against it?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Tim H: One last amendment that they are out of date and point to the new doc.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Dimitris: That is what I had in mind.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Bruce: Added to the list. Finalize these items in the 10<sup>th</sup> meeting. Our meeting would be on the 24<sup>th</sup> at the F2F. We can prepare the slides between the 10<sup>th</sup> and the 24<sup>th</sup>. Any other items on the agenda.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'>Dean: Last call for F2F for in person, there are still slots available. Vaccine cards are required and masks must be worn. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;line-height:105%'><o:p> </o:p></span></p></div></body></html>