<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:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle20
{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;}
/* List Definitions */
@list l0
{mso-list-id:1776973135;
mso-list-template-ids:1690964888;}
@list l1
{mso-list-id:1826436751;
mso-list-type:hybrid;
mso-list-template-ids:-1686571608 264282306 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l1:level1
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l2
{mso-list-id:2139178553;
mso-list-template-ids:-1746776056;}
@list l2:level1
{mso-level-start-at:4;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></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><span style='font-size:12.0pt'>Here are the final minutes from the subject call:<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Attendees: Andrea Holland - (SecureTrust), Bruce Morton - (Entrust), Corey Bonnell - (DigiCert), Dean Coclin - (DigiCert), Dimitris Zacharopoulos - (HARICA), Ian McMillan - (Microsoft), Inaba Atsushi - (GlobalSign), Janet Hines - (SecureTrust), Martijn Katerbarg - (Sectigo), Roberto Quionones - (Intel), Tim Crawford - (CPA Canada/WebTrust), Tim Hollebeek - (DigiCert), Tomas Gustavsson - (PrimeKey), Trevoli Ponds-White - (Amazon)<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><ol style='margin-top:0in' start=1 type=1><li class=MsoListParagraph style='margin-left:0in;mso-list:l1 level1 lfo3'><span style='font-size:12.0pt'>The Anti-trust statement was read<o:p></o:p></span></li><li class=MsoListParagraph style='margin-left:0in;mso-list:l1 level1 lfo3'><span style='font-size:12.0pt'>Minutes of the last call were approved. Minutes from the F2F will be approved on the next call after the attendance is added.<o:p></o:p></span></li><li class=MsoListParagraph style='margin-left:0in;mso-list:l1 level1 lfo3'><span style='font-size:12.0pt'>Ballot: Malware based revocation: Here is the discussion on this topic: <o:p></o:p></span></li></ol><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Martijn Katerbarg: I think the Dimitris commented on the public list on a proposal to actually requires you to backdate verification dates. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>I don't know if you intended that to be included in this ballot or have that a separate item.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Dimitris Zacharopoulos: I just wanted to ask, how would people feel about a change like this since we are trying to address an issue for subscribers that are signing malware.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>I think this course of action would be actually more effective, to protect the relying parties trying to use that malware.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Bruce Morton: Aren’t we already allowed to backdate?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Tim Hollebeek: Yes we are. That's where I kind of wanted to ask you about this Dimitris, because I understand your motivation, but there's a couple of problems with mandating it. Because if I'm understanding your intention correctly, it's like, you're basically saying that you have to choose a back date that guarantees that the ecosystem is no longer exposed to the identified malware. If that's your goal right?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Dimitris: yes<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Tim Hollebeek: Okay I mean it's a noble goal, I think the problem is if you look at a lot of these scenarios they're very complicated and there's a lot of times there's close contact with the root programs and discussing sort of the various trade offs of various effective states that you might choose and a lot of times the date that ends up getting agreed on for various reasons is not the one that is as far back as possible just because there might be a very critical driver for a particular operating system that gets affected and you know we should move towards ways of doing single signings so that that doesn't happen as much but the reality is we can't quite. I don't know how you would write the requirements in such a way that they captured the reality of kind of how this works in real world scenarios today without writing a bunch of mandates that probably would cause more harm than good in at least some scenarios.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Dimitris Zacharopoulos: Well, if there is a malware out there that causes real damage, for me it's pretty simple, there is existing language in CSBRs that we need to find if there's going to be an impact for are there good signatures let's say that are out there but in the lack of any of that information, backdating to the date of the not before would, also be an option.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Tim Hollebeek: Well, it's certainly an option, but, I mean, going beyond what we currently have written, you would have to mandate some rules around how what dates you can and can't use. Right? And, I don't know, perhaps somebody smarter than I can come up with language for that would actually work but I'm kind of skeptical that the language can be written. I could be wrong.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Ian McMillan: I'm with what Tim's saying here, and there's tons of cases that that will encounter with commodity malware that's been signed that a revocation of that certificate has very little impact of the broad ecosystem, but there are those edge cases, and they're becoming more and more prevalent. unfortunately, where the impact of that revocation is way too big, and it actually has more impact and damage than the malware is having on the ecosystem if we were to do that revocation. Drivers are a great case in point, where it can cause blue screens on devices, but I don't know how we write that language other than saying, you know what Tim was saying, you work with your root programs to determine what's the right backdating but I don't I don't know how we write good language that someone can actually audit that.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Dimitris Zacharopoulos: Usually we write the requirements that, we serve the majority of cases and then we can focus on the edge cases. If you're saying, the edge cases are more than the normal cases, then it's a little bit reversed. And for this particular one, we are so flexible that a CA can decide whether to backdate or not back date, you know, depending on the language, so that's audited. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>I think it's pretty complicated to deal with this ballot. So, I think I will agree with both of you that we'll probably need more time to think about this. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Trevoli: What ballot are we talking about?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Dimitris Zacharopoulos: The ballot for the malware.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Trevoli: Okay. Is there like a link someone can put in chat?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Dimitris Zacharopoulos: I put it on the chat<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Dean Coclin-Any other actions you want to take on this? <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Martijn Katerbarg: No, I think everything else is pretty much settled. Unless anything else comes up right now. Cory did push 1 suggestion which I committed yesterday, which was a no brainer cause it matched everything else. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>I don't know if the original endorsers are still okay with that. If they are. I'd like to try and push forward with it.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Ian McMillan: Yeah, let me have another review of the git hub of the current state and I'll probably be willing to endorse unless I find anything that really sticks out to me, but I was one of the original endorsers, I believe.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Martijn Katerbarg: Yeah, and the 2nd was Bruce so.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Bruce Morton: I've looked at it today. I was going to call out, we have a lower case problem report and I don't know whether that should be<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>an upper case certificate problem report.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Martijn Katerbarg: Line 508, I see it.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Bruce Morton: I think that was the only thing.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Dimitris Zacharopoulos: I think it's correct not to be a certificate problem report. Because you have a problem report, and then you are doing an additional investigation and you might discover some more things. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Bruce: I don't think it'll impact anything in the big picture <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Dimitris: yes now I read it again I think you're correct Bruce<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Martijn Katerbarg: Okay, that makes sense to align it. I think we mentioned it 3 times elsewhere as well. Let me go do that right away and then wait for Ian and then we can move forward.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Bruce Morton And what was the outcome about the number of days? For example, 7 days must be within 14 days. Is there an outcome there?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Martijn Katerbarg: There were some comments from Chris from GlobalSign. I know personally, I don't think 14 days sounds acceptable.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>I've asked for other opinions, unless other people think waiting 14 days as maximum sounds reasonable, we can discuss that<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Bruce Morton: Ian, what do you think, what's tolerable from the Windows side.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Ian McMillan: I really don't like waiting. We're trying to, just overall our trend is trying to reduce the time it takes to get a revocation out just even in our own programs and just generically in this space.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>We realize, if you look at other platforms, they don't take weeks, months, which some of these revocations can tak,e and for good reason. And not all of those are really related to a CA, taking a long time. It's more less around just overall how you do revocation in Windows.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>But we're trying to reduce that time, so I would like to see it be reduced for sure, but I don't want to be unreasonable and that's where I really lean on what you guys say and need because you're the ones who have to operationally do this.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Bruce Morton: It seems that on the SSL side, you have 24 hours or 5 days and, there is no malware.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>And this side where you have malware, we're giving them an extra 2 days or we would give them an extra 9 days, we bumped up to 14 days, and there's malware. And it's the fault of the subscriber, right? It's their key, so I don't know why we're giving them so much grace.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Dimitris Zacharopoulos: If they violate the subscriber agreement for signing suspect code.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Ian McMillan: Yeah, it's for all those reasons, you should just revoke but what Tim called out is very real. A revocation, because the signing certificate, and those private keys can be used for 39 months maximum, they signed so much code and it could be one of those cases where the subscriber was a victim and now we revoke and we actually hurt the ecosystem more because of that revocation.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Trevoli: So, one thing: I know this is carry over language from the previous. But one thing that stands out to me about these dates: Is there a strong need to include “the CA and subscriber may determine a reasonable date”. But then the date can't be more than 7 days.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Why offer that option to the subscriber when, you might, they might only be 3 days? It just seems like that's like an unnecessary back and forth step and you could just eliminate that and say, notify the subscriber the certificate will be revoked on this date.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Bruce: So you're basically saying it should be 7 days, is the maximum and this, and we can revoke earlier and that's really the subscribers call.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Trevoli: No I'm saying we shouldn't give the subscriber an option. The problem with giving the subscriber an option is, what if it's a three day weekend in the country that the subscriber is in?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Bruce Morton: But if I have the subscriber who wants that certificate revoked now? And then why would I carry it out for 7 days?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Trevoli: Oh, sure. I think we should we should change the language to be clear because it sounds like, negotiate with the subscriber to if it's tomorrow or if it's 2 days from now, I would read it, as a subscriber that didn't want my certificate revoked, as these rules say, I can have this max amount of time. I don't read this as a subscriber, I get to request that we revoked sooner.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Martijn Katerbarg: No, I do agree with you and one of the reasons is that the current language already has this reasonable date, but it doesn't have any set time limit so basically it could determine, let's leave it for another year. That's really what I want to limit at this point. I think maybe it goes too far to right away set it at the maximum, maybe 2 days.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Trevoli: Exactly. That's what I'm saying is, reasonable is in the eye of the beholder and what you need.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>And the language says reasonable date, but it has to be 7 days after the report was received.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Martijn Katerbarg: But the CA doesn't need to agree with that. Even the CA can always revoke earlier.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Trevoli: They can I, I guess what I'm saying is, including that language implies that we have to have a back and forth discussion and offer options.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Tim Hollebeek: I actually think Trev is onto something. I don't see how the 72 hours actually makes this proposal a lot better. The contact within 24 hours is great. I don't see why whether the subscriber responds or not.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>I mean, starting with it, it's sometimes subscribers, like Trev said, there are a variety of reasons why they may not respond within 24 hours and having that language that implies that there is sort of this back and forth negotiation and a lot of times these emails take, because it's kind of a tense situation sometimes, you know, the conversations don't go particularly quickly. Having it this complicated is going to cause more problems than it solves.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Ian McMillan: Unfortunately, though previously, it was even more complicated, wasn't it? <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>While I see the subscriber in this case, there shouldn't be that much of a negotiation, Especially if they're unresponsive and you shouldn't be giving them a, well, it's implied that I can get a, a max of 7 days so, I always want the max of 7 days.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>It should be more of the control of the CA. The CA makes this determination if the CA Is looking at it and says, hey, I talked with the subscriber, I looked at the subscriber across the ecosystem, and I see revoking would have a bigger damage of the ecosystem, then you've made that choice and that's your justification. It's ultimately the choice unless the root program or, this goes to a different part of the requirements, comes and say,s no you must revoke at this time.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Trevoli: Yeah, I guess I'm suggesting to the language, say something like the CA must notify the subscriber within 24 hours of the report.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>with the revocation date for the certificate. And then that revocation date must not be more than 7 calendar days after the report is received if the subscriber actually writes back. It's a reasonable amount of time and says, hey, can you just revoke it tomorrow?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Instead, you know, can you revoke it immediately, we're totally cool with this. Please do. So then why don't we revoke it sooner?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Ian McMillan: What if I go the other way, what if I'm Solar Winds and I come along and I say, hey, actually revoking, will put the entire ecosystem of all my customers at a security disadvantage. It actually reduces the security posture of all of these customers that I have immediately. I need revocation to happen, or I've shipped a new version that's signed with the new cert and I have all of my major customers or whatever number. Give me 6 months. Those are very rare cases, how do we manage that <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Trevoli: I think that kind of like two options off the top of my head are:<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>We acknowledge that that is a situation that is untethered from the rules and undesirable but you have to notify the trust stores to let them know that this is a thing that you were going to do is you're just going to literally be in violation of the rules and this is why.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Or, and, I'm dubious that this is ideal or that we should change the revocation requirements to carve out a process by which CAs can say, or submit a plan similar to the, In the network requirements, how there’s that thing where you have to fix a critical, or you have to have a plan within 96 hours. But, I mean that's kind of the thing, like, I think that if you acknowledge that, that's always something someone has to make an incident report for. I mean, that it's a formal process through the browser programs and it's always a violation.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>In Mozilla, it would just go in your audit report.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Tim Hollebeek: So maybe there's a couple of things we can put together maybe that help with this because we only have to write the rules for revocation based on malware so the hypothetical <i>what if the customer wants the certificate revoked earlier</i> we don't have to write special rules for that because that certificate must be revoked upon request from customer, we already have that as a revocation reason right now so you just got a second reason on top that you have to revoke and since the customer requested revocation, you don't have a choice, you have to revoke and the same thing with if Microsoft decides, we don't like what's going on in this particular situation, we want this particular revoked faster for this, that, or the other reason, we already have rules in the Microsoft root program that allows them to do that. So, those cases are already handled.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Maybe we can say something like, you either have 7 days to revoke the certificate, or submit a plan for revocation to certificate consumers. And so now, these certificate consumers have a plan and if they think that the plan is not effective, their recourse is they have this ability to request revocation on their own.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Ian McMillan: Yeah, that's great. Tim. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Trevoli: I think that's a lot more clear to.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Corey Bonnell: If the risk of making this more complicated, I'm wondering if maybe there should be another aspect we should be looking at additionally and that's with code signing certificates if you revoke code signing certificates, all signed software doesn't necessarily become invalidated. It's based on, if it's time stamped code, it could still be potentially valid, if the revocation date was after the time of signing.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>I'm wondering if maybe we want to add some language here like, you work with a subscriber to determine the earliest time of compromise, because, the case where you have device drivers or something like that, that might have been signed and timestamped before the time of compromise, there's no reason to invalidate those but the things that are signed after the compromise, reasonably you would want to invalidate.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Tim Hollebeek: You're absolutely right, but I'm trying to avoid writing language around that just because I've been involved in these efforts and I think your chances of writing language that successfully captures what you said is zero, at least, in any meaningful way. It's going to have caveats where people are, that's sort of the world we live in today where it's like, yeah, you're supposed to make a best effort to determine what the appropriate revocation date is in backdated to the appropriate time and it's really messy and I think you do have to kind of make it a little bit more flexible in the way we discussed. This is one of those areas where at some point, there has to be some discretion for CAs, and root programs have to incorporate into their evaluation of CAs, how CAs use their discretion within the lines, in addition to whether they are crossing the lines. I think it's perfectly reasonable to have a conversation with a CA that consistently takes 6 days and 23 hours about whether they are actually following the spirit of the requirements even if they're following the strict requirements. I don't know that you can get better than that. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Dimitris Zacharopoulos: Well, judging from the entire conversation, I think from what I've heard there is a lot of a burden being shifted from the certificate consumer here to the CA, about determining the impact to the ecosystem, meaning that, a successful hacker is going to 1st,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>sign the driver, distribute it everywhere, and then write malware to steal personal data from millions of people, and people are going to think that it's going to cause more impact to backdate that certificate, that would then invalidate the driver. So it’s a very, delicate situation and there should be some better solutions within Microsoft to white list a driver or something rather than having the CA going through all these hoops to determine what's the correct date for not causing damage to the entire world.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>But, yeah, Tim, I agree with you. It's sounds impossible. We should probably take a stab at it at some point and just to confirm your theory. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Tim: Like I said, there's some things we can do, I think, to submit a plan idea is a great one. The direction in which there might be a crack of light that we want to move towards is perhaps if we have some requirement around disclosure of a CA’s practices around how fast they manage to revoke certificates so that there can at least be some transparency about which CAs are actively trying to do a good job to protect the ecosystem by finding reasonable dates and taking reasonable information into account and as I’ve mentioned, let's say the data shows that one CA 99.9% of the time takes six days and twenty three hours and fifty nine minutes to revoke certificates, well you know exactly what's going on there and then we can think about whether there needs to be ecosystem improvements, but maybe a little bit of transparency would go a long way towards causing people to behave better.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><ol style='margin-top:0in' start=4 type=1><li class=MsoListParagraph style='margin-left:0in;mso-list:l1 level1 lfo3'><span style='font-size:12.0pt'>Ballot: Signing Service Update. Here’s the discussion on this topic:<o:p></o:p></span></li></ol><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Bruce Morton: We're working on updating our signing service requirements. No ballot number yet.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Dimitris: It’s CSCWG - 16<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Bruce: We've done a bunch of proposed changes and there's a bunch of comments here, and I was just going through the comments and a lot of them were from Dimitris So, I don't think it's closed and we can just look at the document on the screen.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>We were talking about if should we be calling up the Net Sec document in a number of places, and you suggested that we strike it out I suggest that we want to make sure that someone running a timestamp authority or a signing service knew that applies to them since the NetSec document is talking about CAs. But then, I think maybe we just call it up in section 6.7, where NetSec called up and explicitly call it timestamp authorities and signing service. And then we've already put it into the subsections of 8.4 where it's called up as an audit requirement. Does that sound like it's a good direction to go to? (Dimitris-Yes)<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Bruce Morton: Okay, so I was just suggesting that we move this stuff regarding air gap stuff to the timestamp ballot that I think Ian will work on in the future some time.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>And then you said, should we allow combined reports? I agree. We should allow combined reports.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>If a CA is running a CA, a signing service and a timestamp authority, I don't believe we need multiple reports.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>So we can put that in I thought it was understood, since you called it out, then someone might understand it that you need separate reports.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>We're fine with combined audit reports?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Dimitris Zacharopoulos: thumbs ups are from me and Ian.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Bruce Morton: Okay, so Martijn is not on the call now but was asking if this fine that we changed it from manufacturer certificate to basically a certification type of certificate.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Tim Hollebeek: I think that's what was meant, right?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Bruce Morton: Yeah, but he, he said, he thought it meant key attestation and I, I don't think it ever meant that. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Tim Hollebeek: No, it meant FIPS certificate.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Manufacturers FIPS certificate is what it should have said.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Bruce Morton: OK so we leave that.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Dimitris Zacharopoulos: hold on which section exactly. Is that.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>It's in the service, not signing service.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Tim Hollebeek: We need to be careful because we do use key attestation in the new key protection requirements.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Dimitris Zacharopoulos: Private key storage for signing services Yes.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Correct yeah, there's no key attestation here. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Bruce Morton: Right. They're running an HSM and they're going to be audited. So why do we need key attestation?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Dimitris Zacharopoulos: do we need to expand also on the FIPS or common criteria or are we basically accepting what's on the 2nd paragraph? (Bruce: no)<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>So, we don't need to be very explicit here. Good. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Bruce Morton: Right. It's applying the type of certificate not the type of HSM.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>So you're suggesting this update for the audit requirements, so I don't think there's any objections to that. That was the request.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Dimitris Zacharopoulos: Yeah. Even though it's for the time stamping and, we agree to have a separate ballot. This is very basic.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Bruce Morton: Just so everybody knows I broke out the audit criteria, so that rather than all being lumped into one under CA, I broke it out to CA, timestamp authority and signing service. So if we just broke out signing service, then the timestamp authority would be a snowflake, so I, we just made the 3 different items, so it is impacting it a little bit, but we're not providing the requirements to the timestamp authority we’re just hopefully stating them differently. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Tim: Wait, how is that not a requirement?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Dimitris Zacharopoulos: it is a requirement per ETSI standard.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Tim Hollebeek: Dimitris’ fix looks like a good fix to me. I'm wondering why we aren't just applying it.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Bruce Morton: I was suggesting we should apply it. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Tim: Oh, okay. Sorry. I agree. Dimitris text looks right to me.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Bruce Morton: Okay, Ian was asking about if we want to move from level 2 level 3.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>We should have a date when we have to go to that. I never thought of that. A date does make sense.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>The other question is, is there any existing signing service out there that's using Level 2? If there's none, then, maybe we don't need a date<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Ian McMillan: I don't know.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Tim Hollebeek: the other thing is we could just put a date just because, but here's the problem and we need to look into that because we could put a date because if there isn't one, it doesn't matter. But the problem is, if we pick a date, and if somebody is using a level two HSM in a signing service, replacing an HSM is not something you do on a short timeline. So if there is anybody, I think we need everybody to just kind of go and say, hey, I'll check and make sure what we're using and, but, yeah, we should publicize it pretty widely.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Bruce Morton: I would push this out to whatever, greater than 6 months after the ballot was approved. So I don't know what that date would be<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Ian McMillan: I would say, 12 months<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Tim Hollebeek: Yeah if we're just going to pick a random date to avoid having everybody go and look, I would pick 12.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>And I actually we're going to go and look anyway, because even 12 months can be a little bit interesting for changing HSMs at scale.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Bruce Morton: I'm just going to say I need to do that.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Dimitris Zacharopoulos: it's more than the HSM, it's also an audit.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Tim Hollebeek: Exactly. But, I think it's good for everybody just look at whether level 2 signing services exist or not, and then maybe we can get away with just not having a date and just saying, okay.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Bruce Morton: Dimitris would like to update the signing service definition to be this definition here (shown on screen).<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Dimitris Zacharopoulos: I explained it a little further down, because the way it's written, it says it that signs code.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Bruce Morton: I didn't know if it just meant remotely signs a hash of the code or something of that, right?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Dimitris Zacharopoulos: And I also didn't want to use the word hash. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Ian McMillan: I've seen 2 types of signing services, there's the ones that ingest the content that they intend to sign and they're signing the code itself, or like, what Dimitris is calling out there, just ingesting the digest hash that needs to be signed. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Bruce Morton: doesn't the service take the code, create a hash and that's what it signs or it gets a hash and that’s what it signs? Doesn’t it sign the same thing In both cases?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Ian McMillan: not always, we have even in our internals, we have digests signing process where we have sign tool only send us a digest. We've created a plug in that works with sign tool that, we never ingest the code for our signing service. The signing service only ever gets and we only ever process the hash that needs to be signed that was created by the sign tool<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Bruce Morton: I'm in I'm in agreement with you there, but in the end, do we only sign the hash regardless of what we received?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>(Ian: yeah). Okay. So, why do we have an “or” if we're only signing 1 thing?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Tim Hollebeek: So, that's the thing. I think it's an implementation detail. I think when you say the sentence signs code using a code signing certificate, what you mean in engineering language is either the hash is taken somewhere else or the hash is taken locally. And then the hash is signed, because that's kind of how signature signing works for objects. Having to restate that in the requirement in definition I think is unhelpful.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Dimitris Zacharopoulos: I just wanted to I want to make sure that people that want to implement signing services, they will see that there are at least 2 dominating use cases that are used.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Bruce Morton: It doesn't bother me to leave this as is<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Tim Hollebeek: So, if we want the clarification, we should, perhaps put a may, or a note somewhere stating that the hashing need not happen within the signing service it's okay if somebody submits just a hash, because that's actually a useful thing to say explicitly, because there are some reasons including, let's say in the future if we want to add some scanning requirements or things like that, there are some reasons why you might want some signing services to see the code instead of just a hash.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>But today, I think it's actually an interesting point. I just don't think we should muck with the definition. I think it's probably some verbiage that exists in some other section.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Bruce Morton: I think I agree that definition isn't clear enough, right? Because someone's going to say, I'm not signing code. The definition I think needs to be fixed<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Tim Hollebeek: Really?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Bruce Morton: Well, if someone's going to say, I'm not signing code, I'm signing a hash.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>And then you get into this little debate well that's what we meant and so I think Dimitris was trying to write down, that's what we meant. We meant it could be the code, or it could be data associated with the code<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Tim Hollebeek: I think I think we still have to say that outside of the definition. And that's because as I'm running through things I might say in my head I end up trying to say things like the hash may be calculated by the subscriber or by the signing service and that's a requirement and requirements don't belong in definitions<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Bruce Morton: Then should we put the word <i>hash</i> in this? Because I think code signing is more of a marketing term than it is a technical term. It doesn't sound like a spec term. Unless we go and define, or have we defined code signing?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Dimitris Zacharopoulos: when we define a signing service, the best place to clarify what we mean by signing service is the definition itself. But for the implementation of and requirements around signing services I agree we should put it in a different place but we're just talking about the definition<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Tim Hollebeek: But that's the thing that I disagree with you about. I think the clarification isn't about the definition.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>The clarification is about what exactly the requirements are around how code signing works and where certain operations like hashing may or may not be performed and so I think it's more around the actual requirements of what we mean by signing service and what they're allowed to sign than it is around the actual definition of what a signing service is.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Dimitris Zacharopoulos: If you see it signs code with the capital C, then that’s what is described here is not the hash. It comes out of scope<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Tim Hollebeek: Well, I get the argument that you're saying, I think we need requirements to clarify that the interpretation that Bruce and you are saying that, that is not a correct reading of this, and that if you're signing objects that if you're signing a number of bites, that's short enough to be a hash, you are signing code. And that's just because that's how code signing works.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Ian McMillan: The data that you sign associated with that code is actually the <i>to be signed</i> hash. The TBS hash<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Tim Hollebeek: Yeah, that's the thing, it's always a hash. So when you say, <i>sign code</i>, somebody can't really say I'm signing a hash therefore, I'm not signing code because when you sign code, you're always signing hashes.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Bruce Morton: But sorry, the subscriber has a signing service.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Subscriber has a signing application. Subscriber creates a hash and provides that to the signing service to sign and activates the key.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>They get back the signed hash and then the signer prepares the code signature because now it has the code, the signed hash, the certificate, so the code signing is done by the subscriber. It's getting an input from the signing service, but it's not getting that the signed code, not necessarily.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Tim Hollebeek: You're right, the definition does need to be improved. I think the, the point that you made about the fact that the actual production of the signature doesn't necessarily happen at the signing service is actually a valid one and that's a bigger problem with this definition, beyond the whole thing about just, whether it’s a hash or not.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Trevoli: Do we need to define code? I know they're called code signing certificates. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Tim: We do have a definition. It is defined. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Trevoli: No, no, I'd say, do we need to? Does the word code need to be inside in the signing service definition.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Bruce: I don't think so, but,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Trevoli: I mean, we care more about who's controlling the keys then what is being signed?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Bruce Morton: We don't know that it was code that was hashed actually. Right?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Dimitris: We are a code signing working group. If you say it signs objects, then it becomes weird…<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Trevoli: then I'm saying that the signing service is the concern about control of the keys.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>So it feels like the signing service definition should talk about something like that.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Dimitris Zacharopoulos: But we have a plan to add some more requirements to the signing service, like, checking, maybe in the future checking for malware.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Tim Hollebeek: Right. And so that's the interesting thing is, it actually really is an interesting question of whether the signing services required to see the code or not. And, in fact, we may actually end up diverging into the spot where we may actually include in signatures at some point in the future, whether the signing service has seen the object it has signed or not. Because of the fact that, in the case of only the hash was submitted, obviously, it wasn't scanned.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Ian McMillan: I don't I don't think it's requiring scanning. It's too overarching and it gets into confidentiality issues. I don’t want to see missile targeting system software ever in a signing service. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Bruce Morton It’s the wrong direction as well. I thought the direction was we were trying to protect the keys and not….<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Now all the signing service has to be the expert on finding malware <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Ian McMillan: No, and it shouldn’t and we'll never have a consistent means to have a signing service properly, or even defining what's proper code signing or scanning is another really difficult problem. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Bruce Morton: Okay, so I think we have to step back then and redefine signing service, so why don't we take that as an action item?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Bruce Morton – Dimitris, do you want to try that or should I try that or?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Dimitris Zacharopoulos: Somebody else should try a different definition. I think.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Ian McMillan: I can take a stab at it too.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Thanks again and Trev I'd love to have your feedback. You have a good fresh perspective. We've been talking about signing services for a long time.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Bruce Morton: We were trying to remove this term that says <i>signing services secure infrastructure</i>.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Because it says we transferred to subscriber outside of the signing service infrastructure. We don't want the signing service to transport any keys. But we do allow a CA to create keys for a subscriber, and I assume a CA can delegate that service to a delegated 3rd party.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>So that's why we swapped out <i>signing service</i> with CAs and delegated 3rd parties secure infrastructure.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Dimitris Zacharopoulos: But the problem is that a signing service could be a delegated 3rd party.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Bruce Morton: No the CA is not obligated to be a signing service. So you don't have to have a signing service. It's not an obligation.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>You can only delegate things that you're obligated to do.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Dimitris Zacharopoulos: So, let's assume there is a signing service that is a partner of the CA, or affiliated with the CA. Then would that signing service be okay to generate keys and then sending those out to the subscriber?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Bruce Morton: Well, there's nothing stopping a signing service from being a 3rd party or a associate or a partner or anything. We didn't say that the signing service has to be the CA.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Dimitris Zacharopoulos: I thought we wanted to prevent this from happening, so we didn't want the keys to be transported outside.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Bruce Morton<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Agreed. So we don't want the signing service to do this, so we're not allowing the signing service to transport the keys.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>So, we are allowing a CA to create a token and put keys on a token and transport them to the customer. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Tim Hollebeek: The customer keys leaving the signing service, they're not signing service keys, leaving the signing service.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Ian McMillan: Yeah, we don't want to allow the customer keys outside of the signing service.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Dimitris Zacharopoulos: now I understand the intention, what you were trying to do, and thanks for that<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>So just need to do a fresh read of this to make sure it delivers<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Tim Hollebeek: Ian is right so that, isn't this trying to do something that we didn't want to do, because the whole purpose of the signing service is to protect the end user keys, this is saying how you transport the end user keys to the customer. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Bruce Morton: This doesn't apply to the signing service. This applies that if the CA wants to generate keys for the subscriber, how they would transport those keys to the subscriber.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Tim Hollebeek: So these are non signing service keys.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Bruce Morton: Yeah, this is what CAs are currently allowed to do. Right now we're allowed to generate soft keys and send them to them as long as they're encrypted using the 128 bit encryption.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Tim Hollebeek: Yeah, I was just assuming we're in the signing service section due to the fact that the text previous said signing service, but<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Bruce: Right. So it's private key delivery to subscriber and it said signing service security. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Tim: Yeah, that's an error in the current, right?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Bruce; Yeah, we wanted to remove any call out to the signing service cause I would want them to deliver keys.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Dimitris Zacharopoulos <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Bruce, would you be okay if we added an additional sentence that says that, signing services are not allowed to transport subscriber keys<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>outside their infrastructure<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Tim: we should add that<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Dimitris: Yeah, because I read it 2 or 3 times and I also considered people could misunderstand the delegated 3rd party to also mean, a signing service. Which is not the CA.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Trevoli: Yeah, I like that suggestion Dimitris. Or should we add to that specifically once consumed or once ingested.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Once a signing service has ingested a key, then it should not be exported.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Dean Coclin: We're coming up at the top of the hour and I think we're going to have to interrupt this spirited discussion at this point. Bruce can we just close out at this point and pick it up at the next meeting.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Bruce Morton : Yeah, so we'll close that. So maybe Dimitris do you want to provide that sentence?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span lang=ES style='font-size:12.0pt'>Dimitris Zacharopoulos</span><span style='font-size:12.0pt'>: Sure. Yeah. I'll add it.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>7. Other business: None<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>8. Next Meeting December 15<sup>th</sup><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'>Meeting Adjourned<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><b><span style='font-family:"Arial",sans-serif;color:#0174C3'>Dean Coclin<o:p></o:p></span></b></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p></div></body></html>