Symantec Webinars - SHA1 Deprecation_with intro

On behalf of the Symantec Corporation Trust Services business I would like to welcome all of you joining today and thank you for choosing Symantec as your solution provider. My name is Frank Agurto-Machado, senior systems engineer in Trust Services and I will be your presenter for today's event. We're happy to speak to you today about the SHA-1 deprecation and what you need to know. With that we'll go ahead and begin. Before we begin, let's discuss today's agenda. We'll be focusing on some terminology and maybe some quick housekeeping, so we'll talk to that for a little bit. We'll definitely talk about the Symantec migration path and what the Symantec plan is there. A recap on the certification authority browser forum or CAB/F baseline requirements for SHA-1 deprecation, the browser interpretation moving forward and what you need to be ready for. Remember this is with current browsers. Last we'll discuss Symantec being your security partner along with questions and answers, and how we're going to be there to assist you. And of course at the very end we'll have a question and answer period as well with the time left on the web seminar. So with that we'll go ahead and begin. So let's discuss some terms you will hear throughout the presentation. For those who are familiar with or dealing with the situation already, a lot of this is probably par for the course; for those who have not been dealing with the situation or not been dealing with the SHA-1 deprecation requirement on SSL certificates in your enterprise, this is good to know information. So let's talk about SHA-1: secure hashing algorithm one. It offers messaging hashing sizes at about a 160-bit message digest It's been here for quite a long time. From a Symantec perspective we've been using it even when we were at VeriSign Incorporated, we were using SHA-1; we stopped using message digest years ago, because we felt it was eventually going; it wasn't a matter of if, but when it was going to be broken, and it was, of course. So we've been using it for years prior to the industry requirement to go to SHA-1 - from message digest to SHA-1. OK? As a matter of housekeeping under the SHA-1 before I move on, some of our roots out there were signed under message digest too; we simply changed those for a matter of just good housekeeping or uniformity: we didn't have to change them in the industry, but again we did this because of course the look of uniformity throughout the root hierarchy, but always remember that our roots are kept offline; they're kept in Symantec data centers, which are not known, of course, and are well secured, and we use military-grade data centers etc. For the online CAs as well that are signed under SHA-2, even the SHA-1 versions they are also kept in Symantec data centers; we do not use third parties for hosting or third-party personnel; they're all done by Symantec personnel based on our own security infrastructure requirements, OK? So with that we will move on. So SHA-2, this consists of six suites, two of which are truncated under the SHA-2 512 functionality, so for all intents and purposes, what you would see being used in the industry will only make that equivalent to four crypto hash functions that are out there: SHA-224, SHA-256, SHA-384, and SHA-512; at the end the last two are truncated so again, you might see that if you look at Wikipedia or some other technical definition website you might see that as well but I wanted to make sure I explained that through, that from an industry perspective of what's tangible or consumable by the customer, by Symantec's customer in this case, you would see four functions being used in the industry - but again, from our perspective of what Symantec's doing, we're not really touching SHA-224. It's not really being used too heavily and we immediately advanced from a proactive perspective to SHA-256, but as a matter of FYI for those who are listening, we also have a SHA-384 root out in the industry, so at some point you might see that being utilized and if it is, it's already out there. And again, this is what we do as a thought and leadership provider in our industry: we tend to park roots out there very early as our SSL architects look at the industry and see how it's changing, we listen in to the governing bodies above the CAB/F and that kind of dictates where things will be going, and for those who have been paying attention to that as well, you may see things like elliptic curve, digital signature algorithms, those kind of things coming to light, not necessarily industry standard but definitely becoming more and more popular because now you start getting security and functionality or performance together: with elliptic curve as an example, so again, without getting off course, that's why I've talked about six crypto-functions, though really there's only four that will probably be readily available for the industry, and again a lot of that is going to be based on industry support, so that's web browser vendors, web applications, etc. Let's talk about a term that's pretty familiar: SSL: secure socket layer. It's basically a secure communication protocol between you know your traditional client-server environment. Client is a more metaphorical term because you have server to server, device-device, things like that that connect to host, that act as a server or I probably should even say client host, but again it's done over HTTPS for the most part, right, whether you're doing HTTPS over SOAP or any other kind of developer based application out there; again, secure socket layer has many uses, of course: that's kind of the premise of this discussion. So, Certificate Intelligence Center. For those who have not dealt with our enterprise-based solutions this will be very definitely a very foreign term, but for those who have heard it before, it falls under our enterprise solution that we call managed PKI for SSL, not Symantec Trust Center Enterprise. It falls under more of the larger scope of the solution. We call it MSSL, but again it's more of a holistic SSL discovery and automation, but it's more of an option at this point, and again it's a holistic discovery of all SSL certificates in an enterprise ecosystem, right, so not just the Symantec SSL certificates that are residing out there; Certificate Intelligence Center or CIC can touch everything SSL based on what the administrator decides they want scanned, and of course it works based on port or socket criteria which is IPM port assembly. OK so again you're going to hear that later on in the presentation. So let's talk about certificate authority browser form or the CAB/F. For those that aren't familiar with the CAB/F, it's not necessarily the upper governing body like the IETF or the NIST or any organization like that; it's more kind of a buffering governing body between them and us, us being not necessarily public CAs but also the consumer who buys public CA-based products, so really it's kind of a governing body of best PKI practices, in this case for SSL, within the Internet community and is comprised of all public CAs and browser vendors so not necessarily web application vendors your IBMs, your Ciscos who use or take advantage of open SSL but even OpenSSL as an organization are not necessarily bound to CAB/F but us as public CAs and browsers, we are, because we work very close together as you see today with browsers how they respond to SSL-based pages, so a lot of what we do in there again as public CAs and browser vendors can become almost some levels of uniformity, so really in the beginning it was designed under Extended Validation - for those who aren't familiar with that, that's the green bar that's in your address bar that your extended validation certificates will give you, but the premise of that, of Extended Validation, is a uniform way of authentication and without beating my hands on my chest from a Symantec perspective that uniform way of authentication was literally we used to utilize it at Verisign but under our authentication team we did that for years and what we did is kind of watered it down and generalized it so that other public CAs as well to could follow this basic standard of doing which is an additional seven steps of authentication of issuing EV certificates but again going back to the premise that's what created the CA browser forum; and again, us working with Microsoft and some others, and others agreeing to jump on, and again now the way the CAB/F works in the community is more like an umbrella, so it's more now an umbrella governing body that kind of says look, these are best PKI practices to best protect the customer, not necessarily to say this is what NIST want so we'll just do it, and and and by no means am I saying this in a pejorative or anything like that but in a sense that this is the way that we will do this is a way that best protects the customers so we'll apply these practices to our browsers and public CAs to to an issuing certificate. So a long story short, think of it as if I had to put pictures - I'm a pictures guy - at the very top you have your governing bodies like NIST and IETF and some others, ICANN etc, IANA, and then under that you would have CAB/F and under that you would have everything enterprise network that falls under all our customers, OK? So we're kind of putting it into some perspective there. And last but not least from a terminology perspective let's talk about the Symantec/Verisign Root CAs. Unfortunately that can still be a little confusing. It's been almost three years and some change, a little bit longer, since the Symantec acquisition of VeriSign trust services or certificate services, which basically is all our certificates, managed PKI, our retail certificates our device certificates, our client PKI certificates; anything that can basically warrant a certificate under that service was purchased by Symantec, but the roots, because they have such a long longevity or they have longevity and they're more rated by generation as opposed to you know it's only good for a few years root CAs can last as long as 20 or 30 years so you'll still see the VeriSign name on there, but those VeriSign roots are maintained and owned by Symantec, so they're VeriSign in name only and I say VeriSign not VeriSign Incorporated, and again they're fully owned and managed by Symantec personnel in Symantec data centers. In some cases the security model has been drastically changed there, and I say that in a positive way, but again there's no kind of outsourcing or anything of our Root CAs: the offline root key pairs are again kept in HSMs in Symantec data centers; the online root CAs are the same model; but again all maintained and owned by Symantec. So go and take a second longer look at that terminology page, and then we'll go ahead and move on. OK, so let's talk about migration path. This is the SHA-1 Sunset requirements and the CAB/F BRs. Again for those who aren't familiar with the CA browser forum, BRs are baseline requirements: this is kind of the baseline, right, like any policy that we have, we don't want to talk about that we're not talking about that pejoratively, we are talking about just on a normal day where all the lights in the lab are working and the sun's shining this is just normal, how things are supposed to work and this is from an industry perspective, but when we use the term sunset we get more kind of into the Symantec world of how we do things, so we always use what's called a sunsetting methodology and we did this at Verisign and we do this now at Symantec, because Trust Services kind of rides on its own little island and we've had such a successful run of the way we do things that we're allowed to keep a lot of those policies in place because they work, so again we're not fixing it, because it's not broken; if anything we're tweaking it and ratcheting it to make that policy work even better for customers, but sunsetting has been something we've done for a really long time in the trust service world: sunsetting means that we're really only as strong as our weakest customer we'll only move as fast as our slowest customer, and again I don't want to put those or make them sound derogatory towards customers that aren't updating quickly, but we do have to take all of that into consideration, and so what we say this SHA-1 sunset requirement is, is always think of it as is the farthest we can go out to allow you as our customer to utilize SHA-1, so from the perspective of looking at, you know, what our public pages are issuing certificates or what we call the Symantec Trust Center and Trust Center Enterprise world, back in October and December 2014 there were three basic things that happened there in that time frame: we changed our default signature to SHA-256. Doesn't mean you could not still use SHA-1, doesn't mean mean it's still not available today per se but again we made it the default function, so ideally we want you here but if you can't we can still allow you to kind of go there so to speak and then the end validity for SHA-1 certificates was established as no later than 01/01/ 2017 and again I don't mean this as a pejorative but you may have seen in Microsoft's blog they stated look, 01/01/2017, we're going to start doing something, put those SHA-1 roots out there, maybe we'll remove them, maybe we will turn around and we'll disable them, well I'm really not but again I say it kind of loosely because I've seen it if you were a part of the 1024 to 2048 change there was kind of this wishy-washy gray area stuff happening out in the industry right, and again I don't mean that to point the finger at one vendor or anything it's more in a sense that just, you know, changes happen, and as the security landscape adjusts it's a ripple effect on what it does to web applications, what it does to browsers, what it does to public CAs and how they operate in the community, so sometimes you just say OK, no, we're going to do this without a doubt, OK, because they loosened up maybe we'll loosen up here as well, so again you kind of see this change, but what the the bottom line is here, where I'm going here, the direction I'm going here is that Microsoft came up with the 01/01/2017 date, and that's a really good hard line; it's got some distance; it gives customers time to kind of have that cushion, to start getting ready for adjustment, and again we established that date as well. And then the last, there, the SHA-1 functionality is going to be removed 12/31/2015, so the way I like to say it to customers - and I kind of say it, you know, facetiously - is kind of "smoke em if you got em", right, kind of an old naval term, right, when back in my old military days I'd be on the boat going afloat somewhere and again they would say the smoking lounge and I am by far not a smoker, but not to get off on a tangent it was that, you know, you use the same terminology, now is a time where you better take advantage of it, right, as it's not going to be here very much longer, and that's kind of the way I try to position it for customers when I speak to them is that is that you want to take advantage of it now to set up your cushion, and so what does that mean? That means if we have certificates expiring in 2016 we’re going to honor them, but now is the time to get those issuances out there because of the fact that of course it's going away by the end of this year. So does that mean you wait till 23:59 you know on 12/30/2015? That's completely up to you, but the bottom line is to make it clear to our customer base that it is going away this year; you should be ready for that; and for those who haven't planned for this we really want to start paying attention to what's going to be happening, because of course this is industry standard; this is not, this is happening to the whole internet community right this is not something Symantec, you know got all wild here and said OK we're going to start doing this is just the best way to go; this is an agreement between all public Certification Authorities and browser vendors, right, and if you look at technology from appliances to web applications that reside on those appliances, they're all adapting very quickly. Take OpenSSL as an example: it already supports elliptic curve and DSA and things like that so from a conglomerate organization standpoint of multiple vendors and their OpenSSLs adapting very quickly as well so they see the changes and the good things are coming from them and they're adapting. OK? So let's take a second look at that. Before I move on I'd like to go into a polling question and that way we can go from there. So give me one second here. So what I'm going to start with: Have you run into any challenges with SHA-1 deprecation and of course it has multiple choice so go ahead and take a second and let's start going to get those votes out there if you can please. And again I'll repeat the question: Have you run into any challenges with the SHA-1 deprecation so far and of course yes I can't locate them; B) maybe yes I'm having some compatibility issues, which we have seen: as an example, some appliances out there, the version of web application they're using says it supports SHA-256, but when you go to use a SHA-256 cert it doesn't work, but you put your SHA-1 cert on, it works with flying colors, and that's from a real-world example that I ran into with some of my customers. Again I am not going to say vendors' names because I don't say it's a vendor issue per se; I think that it's just, you know, adapting web applications and the ripple effect that it creates when utilizing whether it be the suite sizes under SHA-2 etc. and of course C is, you know, maybe everything's working just fine; D and E: maybe we're just not there yet; maybe I'm finally getting around to it; you know, maybe depending again on the size of the infrastructure and the footprint that I'm applying this to, but again take a second, go ahead and answer those. All right. Let's go ahead and move on. So in this light let's talk about the CAB/F. Let's do a little more of a recap of what the CAB/F's been doing thus far, and we'll go back to about 2012. So again let's talk about the timelines a little bit further. As you may recall, the migration from MD5 to SHA-1 came to a close in about 2012. This was the most recent change in hash algorithms, right: We were using message digest and we switched over to SHA-1; but we from a Symantec perspective, and again I'd like to say it as being the leader in this space, we were using SHA-1 a very long time, much prior to 2012 we'd already adopted SHA-1 and we knew it was just the better way to go, but again this speaks to how it got comp... how again this message digest could be compromised, and again like I said earlier SHA-1 is just the better way to go. But it's just that for us it was just a matter of re-signing our roots, we didn't necessarily need to re-key everything, right, re-key meaning we needed to create new key pairs and so forth: we literally just re-signed, so an example: if you have an older message digest version of a root out there and then we resigned as SHA-1, it's the same key pair, so both will actually work to authenticate the SSL session, and again so we take ubiquity into consideration because part of what keeps us as one of the best CAs on the internet is our levels of ubiquity, so as a percentile of how far our root is integrated into point of sale devices, mobile devices, older and new tablets, different versions of the Android OS, etc so again we have to look at sometimes just re-signing we don't necessarily re-institute the wheel in that area, OK? And again we did it to the entire hierarchy of course, because of course it's a matter of continuity, right, so putting SHA-1 here SHA-2 there and MD here doesn't make a lot of sense, so again, uniformity is the best way to go, and again it's being proactive from our perspective as well and again remember that the roots that we've done this to are maintained on the Symantec back-end: no third parties; we're not using off-the-shelf solutions; these are things that we built from the ground up. And the reality is this is why you see the cost that runs in our products, because we do this ourselves; we don't rely on third parties; we are not making you rely on us that we rely on a third party, right: it's not a contract relying on a contract etc. we're not outsourcing this stuff; these are things that are homegrown and that we do ourselves. That doesn't mean we don't use third-party products: we absolutely do; we just don't use pre-built off-the-shelf solutions. These are infrastructures that we designed ourselves from the ground up to ensure that we're providing the best throughput and the best levels of security for our customers, but again I digress; let's get back on track to see the browser forum. But again, remember that our roots are offline, and so when you see roots that are not necessarily signed in SHA-1 it doesn't mean that that root is prone to attack because in order for that to happen, that hacker or teams of hackers would have to attack us at Symantec and if you notice there's a lot of articles out there too, some on LinkedIn and some other areas on I want to say eWeek and some others that have talked about why some of the bigger CAs aren't being attacked: it doesn't mean we sit there beating our hands on our chest and saying hey, know we're not worried about it, but we put a lot of money back into what we do, because is this is what we do as a security service under the Symantec umbrella, but it doesn't mean that we won't ever be attacked; no, and I'm not inviting that by any means, but it means that we put a lot of money back into there. Is it really worth someone's time to try to come after us? Probably not in some cases. Now is it worth trying to intercept at the customer level? Absolutely. Does it make the customer a target? Sometimes it does, but the bottom line is from a security perspective what we do with our roots our roots are offline and we keep them offline; we don't keep them in safes because of the fact that if there ever was a physical attack that we couldn't protect the CAs we could we could easily or fast and more quickly zero out an HSM as opposed to let's say go and get a safe and try to break the media or or bend the PCMCIA card to create the mess to burn itself or something in a sense of destroying the root, so it's not overtaken, but again you know that we take a lot of measures and we're constantly - I want to say we're constantly revamping those functions; we're upping our crypto facilities; we're obtaining higher levels of HIPS for crime and things like that for our CAs and the HSMs they reside on, but again, these are the things; this is what we do; this is what we spend our time and money putting back into, to better protect our customers and better protect the services we're providing, because if you look out there and again I'll digress for a second and then I'll move on, but if you look at the industry over the last three to five years, the certificate itself is not being attacked - that's pretty uniform stuff; the CAB/F says it has to be; what happens is it's the serviceability of that CA, so depending on how you're credentialing your customers to come into your back-end and do functions, and form and function things with their certificates, that becomes, you know, kind of the straw that breaks the camel's back, and so what happens is they go after the serviceability of it and when a CA is compromised from that perspective you really start having to ask the hard questions: is this really the CA I want to be with, because they've been broken: not necessarily at the certificate level but at the level of their bread and butter which is their serviceability, and again, not to bad-mouth another CA; this is just the state of how things are and what happened, so I'm not trying to change history; the history is already there, right, and I am not looking backwards, I am kind of keeping us in a forward-looking projection, but the bottom line is other CAs have been been compromised and you really have to ask that question because it's the serviceability of the CAs, it's not just the product itself and again, the product itself is very straightforward: it's a certificate, it has got to follow a uniform set of rules by the community that we all agree upon So again, anyway this is kind of again, you get what you pay for is kind of the way I believe it, OK? And again, I like to say that is PKI as a service: I heard from a customer tell me once; I think that's an outstanding way to put it in perspective, is it really is kind of PKI as a service: you own it, you manage it, but we maintain the infrastructure and we watch the industry, where the industry's going and in some cases, and a lot of cases, we stay proactive to where the industry's going and we adapt accordingly and that's why a lot of times you'll see these changes sometimes every two to three years, three to four years like recently because we see where the industry's going, we see what's happening, we're keeping an ear to to the track constantly to make sure that again, those changes are there that we start adapting our customers, and at the same time if customers are coming back to us with feedback, whether that be questions or concerns, we're taking it back to the CAB/F and letting them know, look, this is the direction we're seeing it going, you know, can we adapt and things like that. That's why you'll see product changes as well, OK? So let's go ahead and move on to the next slide; think we have been on this long enough. So the situation's not much different generally speaking. As some of you may recall, our 1024/ 2048 migration as an example. This was also a process that created a term of gray area we're in today where we still accept 1024, but 2048 is ideal, right, so we're kind of in that gray area now where you can still kind of use SHA-1, we make it available, but ideally we want you using SHA-256, that's kind of where we're at today. So while that again goes back to the sunsetting methodology of doing things only as fast as our slowest customer so to speak, it also kind of makes things a little convoluted, I guess, for the customer: where really should I be? Ideally you should be here is where we try to project it, but if you have to go back here you still have that cushion, but again, if you ever look at our pages where you can use SHA-1, it is in a very limited capacity, it's only for a year; we're not letting you modify end dates or any kind of crazy stuff like that; you're really on a small, or a short and narrow path, because of course it's going away. But at some point we did remove the 1024 allowances as a whole with any incoming CSRs, right, so at some point you just saw 1024 go away. You're going to see the the same thing with SHA-1: at some point SHA-1 is just going to go away this year: you're just not going to see it there any more, but the bottom line is are you ready? That's really what it boils down to. Are you ready for that change, because if you're not, then it's really going to come and kind of be a slap in the face, and we don't want it to be that for the customer. We're trying to again buckle down and make sure we're ready now, so that way we're handling any "onesie twosie" things that are happening, which we've done: we've done special ceremonies, and again, because this is quote-unquote stuff we had done ourselves and we control, we can make those adaptations, we can do it pretty easily. Does it incur a cost? The reality is yes, but we're not lying about it; we're not waiting till the last minute and saying oh by the way you owe us five grand for a ceremony; we let you know in the beginning. I as a systems engineer, who do pre-qualification, I really try to deter customers from doing special ceremonies; that's kind of - without getting on a tangent here, I really try to say look, can you buckle down, can you get it done this way? If we have to do a special ceremony we can, but ideally it's got to be more of a last resort type of thing because we manually upload everything after that, and so you know, again, managing that certificate becomes a little different than what you would do in a traditional issuance as an example, and again I'll digress, just giving you an example again. OK? And again, other products under the trust services umbrella will be following this soon enough, right: as you see the key size has changed; code signing key size has changed; client PKI, their code signing size, I mean their code signing client certificate key sizes are starting to get longer as well, so just because you're seeing an SSL does not mean there's no ripple effect there; there definitely is a ripple effect, but a lot of the ripple effect that you see from a Symantec perspective we do it as a matter of good housekeeping; we know eventually these others, these things quote-unquote are going to be affected, so a lot of times we just start adapting them now and getting them ready for those changes, OK? And again, just like we were talking about SHA-1 today, 1024, the key size was never really broken. 768 was; key sizes below that were: with the changes in computing power they were broken, but is 1024 breakable? From a theoretical perspective yes, it's breakable. So it's not a matter of if, it's a matter of when, and so of course that's why we adapted. Same thing with SHA-1: SHA-1 has not broken yet, and that's the one thing you'll probably hear me say throughout this presentation more than a couple of times is that look, SHA-1 is not broken, SHA-1 is still working and it's out there. But can it be broken? It's not a matter of if, it's a matter of when. At some point it probably will be broken. The flaws that are there may be coming faster and faster to the surface to be broken because of the changes of computing power, changes in technology and the enterprise network, etc., and just the accessibility of faster computers these days, the accessibility of faster processors and phones. Not that I want to tie everything to computing power, but it does kind of, the conversation does kind of go circular, right, it does kind of reside back to those areas. The things that can get me in there faster are computers and micro-computing power type things: phones, whatever, tablets, whatever, and apps are becoming more nimble and more agile with those faster processors, and of course more and more exploits are out there as we start expanding the breadth of network technology and other things that reside in our network, again, mobile computing against desktop computing and things like that, right? And again I keep digressing here but a lot of this, a lot of areas that have become more work for you as network administrators and IT administrators that you have to govern, right, and I'm sure I'm probably getting a name in on that from a lot but there is, and I hear this every day when I'm working with customers, every day I'm dealing with large and hybrid enterprises that are just now I got to adapt to this, oh by the way I've got a point-of-sale device out there; how the heck am I going to adapt that root without spending money to get a subcontractor to go out there and do this, whether it be in a Taco Bell or Cabelas or whatever, but again all these things as I as an IT adminstrator I have to get a handle on, right, and again this is where you start seeing the security landscape adapt accordingly, OK? But on the same note, you know, we utilize the sunsetting methodology to best service our customers. Again, we're only as fast as our slowest customer, as strong as our weakest customer that may have a hard time conjuring resources to get this done: the reality is it takes the village, whether you're doing it to the public here and now I have to go back to the planning phase to my panel inside my company to get all the teams crowd together to start going and finding all their SSL certificates, but again that's why that sunsetting methodology is proving very successful for us because we take all that into consideration and we try to adapt the best we can, but at the same time we also have to kind of put a little pressure on you as a customer and say look, you've got to get this moving; what can we do to help you get there? Can we talk to your vendors - which we've done - to get them to say why aren't they adapting this software and sometimes it's a version change: that version change costs money, so we we try to help the customer the best we can is the bottom line, OK? All certificates from a public CA that are tied to a public root must comply with the CAB/F baseline requirements, right? That is - in our industry that's kind of the gospel, that's kind of what we're following, that's what we have to go with moving forward is that baseline requirement, and I would say for those who are not familiar with it, I would say get used to it, right? Without sounding overly facetious, because those baseline requirements? That's becoming kind of the bottom line of how we do things; that's becoming the premise of how SSL operates in the community. To give you an example: so you've seen things like the 4-year function go away on SSL certificates. That wasn't Symantec waking up one day saying look that's bad practice, let's get rid of it. Did we wake up one day and think of that? Yeah, absolutely, but we had to bring it up to the CAB/F; we couldn't make that adaptation without letting the CAB/F know because again other CAs will probably want to follow that at some point. Do browser vendors agree with that? And so again there's some level of uniformity that we have to bring attention to the CAB/F,but at the same time if customers are saying something is not making a lot of sense we also bring that up to the CAB/F and again we have to base a lot of that on revenue and product size and things like that but again customer feedback is always welcome; it's not just that just doesn't reside at Symantec and actually a lot of times we take it to our representative, we take it to the CAB/F and we assure that there's agreement. We have to talk to a third-party auditing teams because they're the ones who come into the CA at any time and some cases too audit us, and we have to be sure that if we are going to allow these kind of exceptions and things like that, it is not going to hurt us in an audit, because if we get hurt in an audit, we technically can't issue SSL certificates in some cases, so there's a lot of ripple effect once again that gets affected in the industry. OK? So moving on. In the hybrid enterprise model, customers can manage their certificates under the Symantec provisioning model; they can do this with private or public trusted SSL certificates. For all intents and purposes today we're going to stay with public, but we do have products in the private SSL realm. Again that's for a separate conversation. The private model is especially interesting as you can have access to multiple functions while only paying for a product. And again that kind of leads into our enterprise product, but that's not what we're talking about today. But yeah, this product line we can focus on internal certificates that contain illegitimate top-level domains like a .org or .local or something and again, I kind of keep going back to it, but but there are - or you doing it yourself is kind of the way it goes, right: either I'm going to have a third party do it for me or I'm going to do it myself and I'm going to do it myself, that is still considered private SSL from a very general perspective, right, because if you look at the industry you really only have two trust models: public and private trust; you don't have this gray area "well I'm kind of trusted". Some CAs Some CAs are like that: they're kind of trusted in some but not trusted in others, but really it's still considered public trust, or really still becomes - the reality is, the fortunate reality becomes a black and white model. But private trust, you can kind of do whatever you want, and we've capitalized on some of that, because we used to do that, way back in my early days, without giving away age, way back in my VeriSign days in the early 2000s, 2001 to be specific, we stopped doing private SSL, because you have the Microsofts, you have the OpenSSLs, you had those other companies that could generate their own roots and didn't really at that point it wasn't worth paying a third party to do it but then you get the care and feeding of self-signed CAs and that's really where the rubber meets the road; that's where things start getting very very expensive, very heavy, especially private CAs aren't always a revenue-generating environments so it becomes harder to kind of budget that thing, especially when you've got to re-provision, you've got to retrain people, you've got to update your key modules, you've got to update HSMs, whatever: crypto updates can be very expensive. I'll give you an example: we updated our crypto facilities quite a few years ago, give or take, and we're talking in the very high millions that it cost us, right, but again that's at a public CA level. Take it up to a private level where you still may be mimicking some of the same things; some of the things we do are not that far off from what you do with a self-signed model, but again the difference with us in that aspect outside of being a public CA is that we apply the same security model to our private side as we do to our public side. But again, let me get back on track, but that's just kind of talking about, you know, how the things that CAB/F is going to be eliminating for best practices can still be done in the private side, and we do offer a product that doesn't have to follow those CAB/F requirements, but you can still get the lifecycle management tools out of there as well. Anyway, getting back on track: I won't talk much more about the private, there's a lot of areas I can go into but I'll just say today let's look at it from a public perspective. Anything you're going to do that's not going to be accepted by the public world, right? Baseline requirements, again the kind of Gospel that we follow as public CAs and browser vendors, you're going to have to do it privately, and so again what happens in the private realm? Well, I'm only as trusted as far as my root CA is propagated, so it's not inherent trust. Public, the trust is inherent: again that black and white model. But private, you've got to control that; you're going to do it through a third party or you're going to do it yourself, but again that CA has got to get out there in some way shape or form to eliminate that trust error and with current browsers, right, or some current client applications that might have more logic in some cases, or less logic, it it eliminates runaway processes, or kind of that weird, quirky area. It's very cryptic, but I think from a user perspective maybe I don't have the root and my cert store and things like that, OK? But again, getting on track here, from the area of public recognition, you know, once ICANN has awarded a domain to someone or an entity, anyone already utilizing the general top-level domain will have their certificate revoked within 120 days of registration, so that goes back a couple of steps to what I was talking about with illegitimate top-level domains: we used to be able to do that with public SSL or .local, and we had a few customers doing that for years, but now again we get back into that - I'm kind of going circular in the conversation, so I'm jumping in a lot of areas, but it gets back now that you can't do that with public trust anymore; it's going away; I have to do it with private now, so now the good thing is I got some kind of leverage, right; I'm doing public or private here, but where do I want my private self-signed certificates from? Do I want them from a third party or do I do it myself? Again, a lot of stuff happening based on that basic premise of best practices in baseline requirements. Again sorry for the confusion, for muddying the waters a little bit there, but jumping to the map there's obviously a lot going on in these timeframes of 2012, 2013, 2014, because now - and again we're just doing a recap - of those things that are the baseline requirements, that gospel so to speak, that's happening to the Internet community, the SSL community in particular, that customers at the end of the day are left to do the work; they have to follow it with because as public CAs we're going to hard-line it and start setting those up and make them available for customers, OK? So let's jump to the next slide. So now, moving into 2015, we see the changes in SSL certificate end validities similar to the gTLD issue and the non-FQDN issue, but at an earlier point SSL certificates could utilize one to four years; remember I talked about it a little while ago that the four-year just kind of went away, and we put statements out there, and email campaigns, but the bottom line is it just went away. There wasn't a whole lot of this is why we're getting rid of it but we knew it was the best practice. We've looked at some of the sectors, industry sectors where our customers operate: financials as an example, who are really tight on what they do with certificates; they weren't exceeding three years, three years was almost taboo with some customers I spoke to, but four years was just not happening and so again we went and took that back to the CAB/F and we reviewed all this as public CAs and browser vendors once again, and four years just kind of wasn't winning the vote, so it went away, is basically what happened, OK? But the best practice is really no longer than 39 months; we say 39 months because you have that 90-day window to renew, so 36 but inherently it's 39 months. And again, along with the lifecycle changes by October 1 2016 all certificates under public trust may contain only an FQDN or fully qualified domain name for the common name and the SAN values. For those who aren't familiar with SAN, it means subject alternative name. Think of it as your driver's license and you have multiple aliases on your driver's license: that's essentially what a Subject Alternative Name is. You may hear a different reference like unified communication. Unified communication model and SAN tie together at a premise: SAN is what's being used but unified communication use is slightly different because of applications. Microsoft is an example, but again I don't say this as a derogatory term, but in the sense that again you know just how other vendors may use it. But when we talk about fully qualified domain names, that's all that can be in your public trust certificates: you can't have IP addresses; you can't have short names or NetBIOS names that have to follow that public trust model, OK? And again, remember what I said earlier: the baseline requirements of what's acceptable in the internet community. So take another second to look at that, and we'll jump down here. OK. So, moving past the FQDN values for public trusted SSL certificates: we're not really completely migrating to the SHA-1 deprecation yet, but we're getting there, right, but again, similar to the 1024-bit migration from the prior year. So what I mean by that again is kind of the same institute of techniques and processes we're applying. Did we learn our lesson from what we've seen with the 1024 migration? Absolutely. Some of our communication models changed, but again kind of the same set of processes, same steps, almost the same path we're following, because again it was something in a certificate that was being changed; we didn't necessarily have to go and reinstitute the wheel, we could change out a few spokes for lack of a better term. We could re-sign some key pairs, but you'll see our intermediates definitely changed: they went from G3 to G4 or things like that, again because those with intermediate CAs they don't have to be collected in the industry; intermediate CAs are the public CAs' job to distribute, and the customer who installs the SSL certificate installs the intermediate and then it gets handed out during the handshake, so for us, changing intermediate CAs absolutely makes sense and what you'll start noticing is maybe you'll see a VeriSign root - once again going back to the very beginning - but you'll see Symantec written all over the intermediate. And once you're really having application compatibility issues that's again tom-ay-to, tom-ah-to: they're all under the same ownership it's just now we're starting to change things over to Symantec, and over time, as roots get older and as we're propagating new roots like we have been recently, you'll start seeing Symantec show up like on DSA, digital signature algorithm: you'll start seeing Symantec's name on there as opposed to VeriSign and things that, OK? But again, any certificates with SHA-1 under public trust cannot expire post 1/1/2017. We have a working list of customers that we're currently working with. Again, you know, I don't want to make it sound kind of Gestapo-ish, like we're chasing after them or anything or nightsticking on the data centre door, but we're actually working very closely with them; you know, again, it's that "what can we do for you; how can we best service you in this area to get you up to speed because we're only as fast as you can adapt", but again, some of this quote-unquote stuff we really don't have a lot of choice, this is the industry yelling at us, so we've got to move you along, here we've got to get you updated and again sometimes that's making communication with vendors through TSANet or directly to our contacts that we have, or again doing what we can to help the customer to get them you know absolutely there, but it's always that sunsetting methodology, OK? With that let's move on. So the security landscape is changing its technology updates at a faster pace, and for a lot of us in IT administration we've been seeing this, obviously, right? Refreshes are no longer four and five years; sometimes they're two and three years; in some cases depending on the device maybe it's a year, like a mobile phone or something but again because you're talking about single core, dual core, even to some extent quad-core and Atom-based processors, it's extremely fast and extremely small and also this device becomes a little rocket in your hand, right, but again, it's a very powerful little device, but those refresh rates sometimes change because of the adaptations of technology and depending where that person resides, whether it's field sales, whether they're working in a knock somewhere, but they've got to have really fast communication: again, without getting on a long tangent on that you may just see updates change at a quicker pace, but as the leader in our space we see seek to stay proactive and work with partnering vendors to ensure best-of-breed PKI practices, so again just because it's dictated at the CAB/F doesn't mean we're not already looking ahead; in some cases we try to set the bar in the way we do things and how we adapt our security practices. As an example: private and public root architectures. In some enterprises they may not be looked at under the same looking glass. From the Symantec perspective, because we have such a broad customer base, we treat our private and public trust models exactly the same: we apply the same amount of levels, the same best-of-breed security practices there, and again, because of course why would we want to divvy that up and take any chances when we can just kind of set one baseline that's way up there right, so to speak, that's really good security, and again its all about you, it's protecting you as a customer, not just protecting our stuff: that all kind of goes hand in hand, that quote-unquote stuff, right, it's all that: it's protecting the customers that's using that stuff, right? As we said earlier with those CAs you know, without saying names, that have been infiltrated at one point or another, maybe they've recouped from that now, but why start the race in second when you can start the race in first and just maintain first is the way I've looked at it, being a military guy. Why would I want to start the race and fall back to second and I'm not saving any wind that way; I'll get to the front and stay there, and that's what we've done as a leader, and again, we treat our infrastructure that way as well and our practices so it's always kind of keep us first in that running, but again, to do that, sometimes you've got to spend more, you've got to do it yourself, you don't rely on third-parties to do it because now my customer is relying on me to rely on my third party to stay proactive and all that approach as well. And if you take things like revocation, where third parties have went down, causing customer certificates to not work at all, again, that's bread-and-butter stuff quote-unquote, right, we don't want to take advantage, don't want to mince words on that and say oh, its OK here and there; that's never OK for certificates not to work for a customer and things like that, but again we recognize these changes to be difficult for customers, that's why we're doing the presentation and other things and campaigns etc., but whether the complexity of the enterprise network to just being able to make contact with all teams we apply the sunsetting methodology again to provide our customers as much time as possible to adapt to the industry changes, and again those things aren't going away. What gives us the flexibility to make those adaptations to the existing rules is the ownership of our infrastructures, of our infrastructures, again I've kind of just beat the drum a little bit so I won't beat it too much farther, but again we don't treat PKI as a commodity, and I think that's the key to remember like back in my day i worked for a large company with a 3 in front of it, that sold network interface cards before there was the invention of the LAN on motherboard or the LOM, and I remember that we didn't treat network interface cards as a commodity either, I mean eventually we just kind of fell into that because you can integrate it anywhere and everywhere, but we used our parallel tasking technology and it really paid to have that card. Was it more Was it more expensive than your average network interface card? Sure it was, but the speed and the functionality of what it did was vastly, just outdid the other cards that were on the market, but again, technology changes, and things can - you know micro-computing etc. but again going back to that is that we don't treat SSL that way and again I'm trying to say SSL will eventually be integrated in a chipset or anything; in some cases it is, like vPro as an example, but we don't treat SSL certificates as a commodity; commodity, not the certificate itself, because remember that's kind of uniform, because industry all have to apply the same set of rules, but it's the services that give you that certificate that's where the rubber meets the road, and that's what we don't commoditize, and an example of that would be off-the-shelf solutions that are pre-built for you to use, so I just plug it in and I'm doing revocation. We don't do that. We build it from the ground up; we take the F5s we take the A10 Thunders; we take the Citrix Netscalers and Cisco devices and the Junipers and we put them in our environment and we scale them and we structure them in a way that best services throughput, but also best services our security model as well and again I'm just going to throw some random terms out there but again like I said we use third-party products to construct our backend etc. but really it's about the infrastructure and the services it provides, that's where that's again this is what we do, right, and if we didn't do this well, then we wouldn't be number one in our spaces, and again it's kind of just me beating my hands on my chest a little bit but adaptation to a certificate nomenclature, things like that those can be done through ceremonies, again we can do it pretty quick, almost two times a week in some cases - manually, by the way - it's because we own our infrastructures, that's kind of what it all boils down to. Where others say we just can't do that, give us two weeks, we can do it fairly quickly, sometimes we can even do emergency ceremonies, emergency ceremony is very fast, and get that done, OK? But on an additional note, Symantec is a founding member and a large part of the CAB/F, that is key to remember, and we're part of the decision-making process. we're kind of the panel leaders there but even if you're not a panel leader it's public safety and you have to follow those rules, so sometimes when you're looking at CAs, that's the question to ask, you know: where are you in that process? Are you a follower or are you a leader? Because that a lot of times tells you where they're going, tells you you how much of the bread and butter - how much money they're putting back into that bread and butter of what they do, and things like that. And again I'm not trying to sell that or spiel kind of more kind of putting it all in perspective so there's money when you start dealing with PKI there's lot of free-floating data out there; a lot of stuff to grab at. Where do I need PKI in my infrastructure, how am I going to implement it and things like that. The clock's ticking. Let's move us on. But you should expect more migration-type changes in the future as Symantec and the CAB/F seek to make the Internet a safer place for you. And again not so much just for the enterprise, but really at the end of the day is kind of where the rubber meets the road to bring that user back to the internet. Remember back in the 2011 timeframe, somewhat earlier, that one Christmas year we kind of didn't have a lot of online presence because of the recession, all kinds of crazy stuff going on out there, but we always look at that as keeping your user, which inherently is you as our customer, keeps them on the internet, keeps them doing it because we're making it a safer environment, right. I'm not going to take my kids to the playground if the chain link fence is run down, and and there's a bunch of some kind of shady characters hanging out there, but if someone comes in and cleans that park up, starts putting nice white nets on the basketball hoops and sitting there and cleaning the kids' playground, then yeah I'm going to be kind of, you know, adept at bringing my kids back there. That's kind of saying we're treating the internet, I guess, without making funny comparisons or quirky or campy comparisons, but we're keeping that play area clean, and that's the internet, right, keeping security there and making sure it's sound and making sure the users are doing their due dilligence, paying for products and really putting their money into your products, again which which is kind of why we're there, but but the bottom line is you should expect more migration type change in the future, as the security landscape is changing a lot faster and you really just want to be ready for what's happening, and we're doing the best we can to adapt to our customers as well. That kind of brings us to the end of that timeline and before we get into this timeline let's let's do another polling question as we start to wind down here. Gimme one second here. We're going to actually talk about another another question here in just a second. OK so in this one lets talk about let's talk about how are your locating all your SHA-1 SSL certificates in your ecosystem, and this is a pretty straightforward question, but again, you know, are you using an internal discovery tool or using Nmap or some other fun stuff, you know, are you using VA tools that can do https capturing on the side or do you have a third-party discovery tool; once again, it could be you know like a Qualys, it could be CIC or what have you. Maybe not necessarily direct emphasis but, you know, the secondary emphasis on https capturing like an IPC60 or something. Or you don't have a discovery tool; there's other means of doing it or other methods, or really I just don't know, I'm not there yet. But bottom line, let's take a second, just a couple of seconds and answer that and when we do it we're going to move on here, OK? Actually let me jump back one slide: I really didn't describe this one, but this is a nice slide to look at because this is a very very kind of in-your-face but simple model of saying look this is what this year the particular browsers are going to be doing, right, if you look at Chrome, if you look at your Firefoxes, you look at your IEs, your Internet Explorers, even your Spartans in some cases of what there was in 2010 they're going to start adapting differently to how SSL operates. And again not being in favor of one of the other but some cases like I said, you look at the way SHA-1 is being utilized and these are different dates whether it be through, or starting January 1, or, you know, from through May 31st 2016, you're going to start seeing certain changes there; maybe you'll get a security warning; maybe you'll get something over the lock, but they'll still let you do it, but eventually if you work your way down to the right here under the SHA-1 like with Chrome as an example: with build 42 you're going to start seeing a red X on that lock, right, if it's still SHA-1, so what does that mean? So that means if I have SHA-1 certificates out there I'm kind of still at the mercy of the browser, right, I'm still having to worry about how the browser even though Symantec says it's OK or another vendor does say look you can still use SHA-1 for a little, we'll still honor your quote-unquote stuff until 2016, but that doesn't mean the browser's going to play fair in that way, the browser may come back and say hey you know what, you're using what's called obsolete cryptography; it doesn't mean that it's bad, it doesn't mean that is broken, but you know, hey, it's not the latest and greatest quote-unquote stuff that's available. So what does that mean? it always applies to two sides of a coin: the internal and the external aspect of things. Is it generating more calls internally? Is it inherently, somewhere on paper, is that costing me money as a company owner, or as a division owner that has to decide budgeting, those kind of things, right. So again, we try to move as fast as our slowest customers, but from you as a customer perspective that directly affects you, does this affect revenues, the bottom line? Does it affect that? And that sometimes will propel how fast you get these adaptations in there, but again, be ready: this is stuff that's happening now. Chrome 39 is already out there; if you allow Chrome as part your baseline policy to be used in your ecosystem, you should be expecting these kinds of things to happen. And 2017, that's coming up pretty fast, so you only want to start getting ready for that if you haven't been, OK. Take another second, go and look at that, then we're going to jump down to the number line and again we're kind of moving a bit slow on time or we're losing time so I'm going to hurry up and get us through this. But let's talk quickly about the timeline here. Really what I want to jump into is I don't like to look too far back; I'm kind of a forward-facing looking guy, I try to stay positive in that respect but let's look at 2015 Starting early 2015, Firefox is already starting to show some errors there, and of course Chrome was already, but Firefox is jumping on board, so what does that mean? That means not necessarily CAB/F stuff quote-unquote but it means the browsers kind of all follow the same suit at some point, and again I don't mean that derogatory, but but they all see where the industry's going as well and all these vendors are paying attention to that stuff, right, and and as you start clicking down to 2015/16/17, you start seeing that they're all kind of getting on that same path, right, at some point the bottom line is that at some point SHA-1 is just not going to look good in your browser; may not even be accepted. Take non-chaining certificates as an example. Non-chaining means there's no intermediate CA, there's SSL cert directly to a root; you don't see that any more, and if you do provide it with a self-signer and you dump the root into the cert store, if you try to connect over IE as an example, IE is going to say something back to you which rightly so: browsers should be doing that. Browsers are doing now what they should have been doing five six seven eight years ago: they're being more interactive in the model, they're telling you look, don't click OK to go, it takes a click acknowledgement if you want to go to that page because there's a reason I'm not sending you there, that you should be very concerned about that because of phishing, because of infiltration, because of sometimes somebody planting an exploit and waiting four or five months and then coming in there secretly and starting taking information. The federal government: it happens at the highest levels of security, and again they're kind of following that Google model: everything's being done over SSL now, and again I'm not capitalizing on what's going and aim hits out over one or the other, just that you start seeing the similarities: they're getting on the same path, which is creating a bigger table at it, or a bigger ripple effect to how all operating systems and web interfaces and other things are starting to adapt to what's happening with cryptography, right, and again we really want to pay attention to that, not because I work at Symantec and that's who's on my paychecks, but it's because it's going to affect you in some shape or form if you've got even a minute footprint on the internet, this stuff affects you, right? This stuff - and not affects you as my customers, but it affects you as man I got to go walk in to work every day and deal with this stuff; I got to figure out an action plan to get me adapted and make sure that my customers are protected, right? Let's jump on here, we're going to move pretty quickly. So let's talk about Symantec's responses to what's happening out there. Right, again, limiting the validity periods for SHA-1. And again we're going to actually block them at the end of this year, but if you have certificates that expire in 2016 we'll honor them. And again, we're going to stop issuing after this year: 12/31/2015 Remember, "smoke em if you got em": if you need to get your SHA-1 certs you'd better do it now, better start doing it from here on out throughout this year; my recommendation is probably build somewhat of an action plan, as being a leader, when I was young jarhead in the Marines we used to think you always start with the end result, work your way back to the beginning and a good leader will have already done that, worked their way back and say OK, this is how I'm going to get to that end result. If that hasn't been done I'd probably start to recommend that pretty heavily, right, because this stuff is going away; this is industry; this is not something again that Symantec just decided to up and one day do, this is something affecting everything we do on the internet. And of course we already have SHA-256 intermediates out there. You get a SHA-256 cert today it'll be off a SHA-256 intermediate; the industry doesn't require that SHA-1 root yet or the SHA-256 root, excuse me, but we have the universal root already out there, and of course SHA-256 certificates will carry standard validity periods: one, two, three years, pretty much the same stuff there, right, quote-unquote, nothing's changing from that aspect, and of course when you get into the hybrid enterprise or when you start dealing with the managed model you start looking at private SSL, right, which is under the managed PKI for SSL model, but that's for those accounts only and I'll digress: that's not really part of where we're going from a product perspective, but those are just letting you know, the things that we do holistically to support that. So you know what to do? You want to discover and locate all those SHA-1 certificates, whether you're using internal tools, or CIC to manage PKI for SSL, but again you want to start locating all those SHA-1 certificates. You want to create a migration plan, you want: do I have hardware / software conflicts, am I just going to have to update the stuff, right. Some of this is probably for a lot of you just common sense; stuff is going to fall into place, but have we thought about that yet, have we thought about potential compatibility issues. Then we talked about certificates expiring before January 1 2016, they're going to be renewed with SHA-2; this is what's going to happen. Or you might be able to still get SHA-1 for a limited time, right, again about a year, but if you renew them now you're going to get the SHA-1 still, but after 12/31/2015, there's no dice at that point here, you have to go with SHA-2. Are you ready for that? That's really what it boils down to. Have you installed the correct SHA-2 intermediate? So while it sounds kind of hokey, I tell customers did you go to our installation pages? I don't doubt you know how to put it into, you know, to OpenSSL or into your F5, but did you go there and grab that CA-bundle file that carries the SHA-2 intermediates, because if you didn't, well, you've kind of got the shotgun pointed at your foot at this point: you're setting yourself up for failure and you're going to set yourself for a long support call, we're going to walk you through all this. And sometimes just replacing the certs, if it's like a java-based keystore and you installed things non-systematically and you have to go and make changes, that sometimes can get very finicky, so you're setting yourself up for a support call and I tell customers: follow the instructions, we put them out there for a reason: it has nothing to do with the intelligence of the server administrator, has everything to do with doing things properly to make sure that we facilitate all the proper services to you. OK? And again, SHA-1 certificates expiring after 1 January 2016, at any time I can replace them: I'll get a SHA-2 certificate and replacements are offered at no charge. Always remember that we offer replacements up the life of a certificate at no charge, OK? Some additional references: Am I using SHA-1 certificates, how do I replace my SHA-1 certs, how do I replace my SHA-1 intermediate CA you know again that's getting into SHA-2, we have our links right there. The links will be available, you can click on them anytime and again after this we can always give you a PDF version of the deck with the hyperlinks as well, but whether it be Symantec GeoTrust or RapidSSL or any of the family of Symantec-owned CAs we definitely have SHA-1 help pages there. Well, they differ slightly, sure, but it's all kind of the general area, right, it's getting over the SHA-1 hump so to speak And additional resources at this point, dealing with getting a certificate signing request, installation, how to manage SHA-1 deprecation, things like that, those are all areas that we have under our knowledgebase as well, so it's all public-viewable information. And last but not least let's talk, right. Call your sales rep or your account manager, email technical support someone in there, to get the things that you need answered to either myself or to the support team and then I try to take the most objective way that I can with customers, but again getting you to the end result, OK? And that wraps up my section. So we're over time; I'm going to look at a couple of questions here. I'm just going to answer one; I got about a minute 55 here. So let's do the the first questions: I've been purchasing SSL certs for our websites for the last six years. Are they already SHA-2 compliant for my Tomcat key stores? The answer would be yes. But I would go back and say check on your version of Tomcat. Does Tomcat support SHA-256? If it's a third party that's OEMed it and owns it then you've got some support or you're going to be checking forms, but absolutely make sure that web application truly supports it and again we allow grace periods when you install certificate for you can revoke it you can still get your money back on it so I would say absolutely if you can test it do that definitely, OK? And it says do my cert expires in early 2016 can I upgrade my cert to SHA-2 now? I would imagine they meant at no cost - and how? You would replace it, and if you replace your certificate throughout the life of the certificate you never get charged for it, the new key pairs will come out with the original or the new public key will come out with the original and validity and of course when you replace it if it goes past let's say the 2017 you will automatically get SHA-2, in some cases using Symantec trust centre, whether it be enterprise or not, its going to be automatically defaulted to SHA-256. So absolutely you can adapt. Lots of other questions in here. I'm going to answer all of you, and again, I usually get a spreadsheet and I work it and I will answer every question I didn't respond today but for the sake that we're over I'm going to end the presentation here and I want to thank you for your time today, thank you for joining, and we look forward to doing upcoming presentations for you. There is an area here that you can grade the presentation and grade my ability to give a presentation I ask that you do that. Feedback is always accepted and we ask that you have a great day. Thank you for your time.