[cabfpub] Google decision to impose a negative UI for SHA-1 certificates in 6-12 weeks

Ryan Sleevi sleevi at google.com
Mon Aug 25 16:04:07 MST 2014

Indeed, in which I was reiterating the correct venue for discussing this,
much like Mozilla policy is discussed in mozilla.dev.security.policy

On Mon, Aug 25, 2014 at 4:02 PM, kirk_hall at trendmicro.com <
kirk_hall at trendmicro.com> wrote:

>  Ryan, I was responding to your message below on the Public list for the
> CAB Forum.
> *From:* public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] *On
> Behalf Of *Ryan Sleevi
> *Sent:* Monday, August 25, 2014 8:51 AM
> *To:* Dean Coclin
> *Cc:* CABFPub
> *Subject:* Re: [cabfpub] Agenda for Beijing F2F 16-18 September 2014
> Small correction:
> sudden -> recent
> very little notice -> six months notice
> I'm not sure that there is much to discuss, however, at least not within
> the Forum. Chromium has announced plans for UI changes that had previously
> been discussed at length in the Forum during our F2F in February. There is
> already a venue for discussing these changes, one which permits and
> encourages full public participation, and we welcome further contributions.
> I suspect that such a conversation in the Forum, with or without Google's
> participation, would thus be nonproductive, unless the proposal is that we
> reexamine codifying these dates in the BRs, a move we would certainly
> welcome.
> *From:* Ryan Sleevi [mailto:sleevi at google.com]
> *Sent:* Monday, August 25, 2014 4:56 PM
> *To:* Kirk Hall (RD-US)
> *Cc:* CABFPub (public at cabforum.org)
> *Subject:* Re: [cabfpub] Google decision to impose a negative UI for
> SHA-1 certificates in 6-12 weeks
> Happy to continue discussing this in the proper forum, which, as has been
> noted in the past, is
> https://groups.google.com/a/chromium.org/d/msg/security-dev/2-R4XziFc7A/NDI8cOwMGRQJ
> In which the relevant bits for the minutes were already provided.
> specifically
> https://groups.google.com/a/chromium.org/d/msg/security-dev/2-R4XziFc7A/OAvNrBvhD5QJ
> On Mon, Aug 25, 2014 at 3:46 PM, kirk_hall at trendmicro.com <
> kirk_hall at trendmicro.com> wrote:
>  Ryan, you have indicated in a couple of emails that Google warned CAs
> six months ago about its plans for SHA-1.  I assume you mean at the
> CA/Browser Forum meeting at Google’s office in February?  If so, I have
> pasted in the minutes below – it’s not clear to me from these minutes that
> Google was going to require users with SHA-1 certificates expiring after
> 2015 to replace those certs in 2014 or have a negative UI in Google.
> The Minutes from the meeting speak for themselves, but my general
> recollection of the discussion is as follows.
> ·         Everyone acknowledged that Microsoft was dropping support for
> SHA-1 as of January 1, 2017 (and no new SHA-1 certs could be issued
> starting Jan. 1, 2016 to help prepare for this change), but Microsoft said
> it might move the date forward or backward, depending on circumstances.
> Everyone was in support of eliminating SHA-1.
> ·         We discussed putting a sunset date for SHA-1 in the Baseline
> Requirements, but  given that Microsoft said it might change the sunset
> date, it made little sense to fix a date in the BRs that could then be
> changed based on Microsoft’s future decisions.
> ·         Google indicated it also supported SHA-1 phase-out.
> ·         We then discussed different ways to notify users and complete
> the transition of all sites to SHA-2 (or better) by the start of 2017.
> My company, Trend Micro, only issues one- and two-year certs, and we have
> already modified our systems so that no customer can get a SHA-1
> certificate that expires after Dec. 31, 2016.  So we don’t need any help in
> getting all our customers to SHA-2 by 2017.  But Google’s new policy means
> we now have to move a large group of our customers to new one-year SHA-1
> certs (or SHA-2 certs for those customers whose systems can work with
> SHA-2) over the next 6-12 weeks, which was totally unexpected and in the
> case of our customers serves no real purpose.
> You have mentioned that Google is trying to avoid a “flag day” on January
> 1, 2017 – a worthy goal, but that was never going to happen for any of our
> customers.  By forcing most SSL certificate customers to change out all
> their SHA-1 certs in the next 6-12 weeks, Google is more or less creating a
> “flag day” in the next 6-12 weeks, for relatively little benefit.
> *Wouldn’t it make more sense for Google to impose its rules in a later
> Chrome release (after Chrome 39) – such as six months from now – to avoid
> this upcoming flag day*?  Google can apply its policy of showing a
> negative UI for SHA-1 certs that expire in 2016 and 2017 (so Google will
> accomplish its stated goals of making users start the change soon, and not
> wait until the end of 2016), but will be giving users more time to adjust.
> Please understand that CAs have virtually no trouble in issuing /
> reissuing short term SHA-1 certs and new SHA-2 certs to their customers, so
> by pushing out the date of Google’s new policy by six months Google would
> not be doing CAs a favor.  However, no matter how hard CAs try to tell
> customers what’s coming from Google in the next few weeks, not all
> customers will be able to respond in Google’s preferred time frame.  What’s
> the harm in moving this flag day out a few months so users have more time
> to react?
> Here are the minutes from the February Forum meeting:
>  Wednesday, 19 February 2014 Browser News
> *Mozilla (Brian Smith):*
> 1. Working on changing to new cert verification library for FF30 which
> will be released in 16 weeks “Path bldg. for cert chains in a more sensible
> way”. Helps increase compatibility and will allow them to add new features
> in certs like CT.
> 2. Half way done in implementing “must staple” extension. Working to
> revise Phil Baker’s IETF draft and getting it published. Overall goal: make
> OCSP staple secure. This will help promote OCSP stapling as a good solution
> against key compromise. OCSP fetching discussion going on now. 7% of
> handshakes use OCSP stapling. Would like to increase to 100%.
> 3. The new path building logic will be an option in FF29. They will
> recommend that each CA test against their own certs
> 4. FF29 to remove most or all of 1024 bit roots. CA’s need to get back to
> Mozilla with any significant impact CAs that have legacy roots that have
> been cross signed would be affected. Mozilla will accept requests from CAs
> to build in intermediates into Mozilla if that will help prevent many web
> sites from breaking (contact Brian).
> 5. Timeline for FF29: April 29th (remove 1024 roots and new path building
> code optional). FF30: June 10th (new path building code enabled for all)
> 6. No decision made yet on SHA-1 deprecation. Awaiting feedback from CAs
> on MSFT proposal.
> *Google Chrome (Ryan Sleevi)*
> 1. Transitioning away from NSS to OpenSSL stack except on Windows and
> Android. Win will continue with Crypto API Effect on moving to
> OpenSSL-parsing rules. No special UI for bridge certs but will support them.
> 2. Looking at programmatic enforcement of BRs
> 3. CT reqt to be discussed later
> 4. Chrome does not support internal server names from public roots (this
> has been true for some time now). Will not show lock.
> *Microsoft (Tom Albertson)*
> 1. SHA-1 announcement published ***
> *SHA1 Sunsetting / Grandfathering Strategy*
> Ben: We should work on a path forward to make sure everyone is aware of
> the current plan to eliminate SHA-1. We might want to see if there is a way
> to allow exceptions for an initial grandfather period, along with the
> sunset period when everything gets turned off, because there are likely to
> be some that will object to a hard deadline.
> Tom: Removal of roots may have some affect.
> Richard: Four million users in China are relying on Windows XP, SP2, which
> cannot use SHA2.
> Brian: If browsers enforced SHA2, then end users would stop approaching
> CAs asking for SHA1 certificates.
> When large, popular websites start using SHA2, then everyone will want to
> upgrade their browsers.
> Brian: With TLS 1.2, the client can send the server a list of algorithms
> it supports, and maybe we could get server vendors to start adding an
> ability to select SHA1 vs. SHA2 based on what the TLS 1.2 client sends,
> like what has been done for EC certificates vs. RSA certificates. This
> might work with markets with localized issues like China and Japan. Also,
> large ecommerce sites have economies of scale to create customized code to
> serve SHA1 to SHA1 clients and SHA2 to SHA2 clients, so maybe we should
> make them aware of this possibility. They would be willing to do more work
> than the general population of server administrators.
> Robin: We cannot, however, partition the Internet into different zones -
> SHA1 vs. SHA2.
> Dean: How does this work on the browser side?
> Brian: In Firefox, the user gets a warning that says, “we cannot verify
> that this was issued by a trusted issuer.” Then we let users click through
> it – we basically treat it as an invalid signature.
> Dean: What about Chrome?
> Ryan: You will get an invalid certificate, based on whether it uses
> CryptoAPI. Whether it is over-rideable depends on whether it is an invalid
> server certificate, then no, but if it is an untrusted server certificate,
> then yes, it is over-rideable.
> Dean: What about Internet Explorer?
> Tom: You will not be able to have an https connection.
> Ben: Regardless of whether all of the browsers implement SHA1 sunsetting,
> there will still be users who do not upgrade their browsers, so the issue
> is how do we gracefully transition, because regardless of the cutoff date,
> there will be a tail that follows after that date. We should be looking for
> statistics – who has moved, why haven’t people moved to SHA2, etc., and
> based on that we could see whether any grandfathering rule makes sense,
> because no CA wants to violate a rule.
> Chris: As a general rule, we seem to have a double sunset. We take a date
> to our customers, and they start to implement it. Then our customers come
> back to us with news about their problems, or their customers’ problems.
> And then through an organic process we come up with a grandfather policy.
> Wayne: I wonder if we should be setting deadlines at this point. Microsoft
> has a date and a time next year at which to re-evaluate the policy, and
> then we have our users and a security policy we’re trying to implement
> without breaking things, so that is when we should evaluate between
> breaking things and the sunset.
> Brian: If we wait too long, then we’ll have some CAs who have the
> situation under control and those that don’t. Then, if things change, those
> CAs who have handled the transition responsibly will feel they are being
> treated unfairly. For instance, a CA issuing a certificate without OCSP
> could sell certificates more cheaply in violation of the rules. By June
> 2015, we need to be able to say that we have identified all of the
> potential issues.
> Chris: We need to have a process for future migrations. So, if Microsoft
> says, “we need to move over to this specification, but until customers
> begin to feel the pain, we don’t know what all of the issues are. Then,
> when they complain, we give them a temporary, 1-year reprieve while a
> better solution is developed.
> Brian: We should definitely consider shortening the lifetimes of SHA1
> certificates—they shouldn’t be longer than a year. So, we need to put into
> the Baseline Requirements a maximum lifetime for a certificate with a SHA1
> signature.
> Bob: We’re trying to reduce our risk, because we want to reduce the number
> of certificates with SHA1 and the negative impact that will occur when it
> is known that SHA1 is insecure.
> Richard: We should issue the user two certificates. That way, at the
> appropriate time, the user can just switch over from their SHA1 certificate
> to their SHA2 certificate.
> Rick: I like that idea, and we’re also considering that approach. It’s
> easier for us and for the customer, so we’d prefer that strategy rather
> than shortening lifetime.
> Bob: We need to have the customer experience pain with a SHA1 certificate,
> or it won’t work.
> Brian: What is the problem with limiting SHA1 to one year?
> Rick: We have a number of platforms for selling certificates, and let’s
> say a customer buys a three-year certificate, and we deliver a SHA2
> certificate, and they tell us that a SHA2 certificate doesn’t work. It’s
> much easier just to say, here are your two certificates. There is no longer
> a need to refund because we’ve at least given them what they’ll need over
> that three-year period.
> Brian: It still doesn’t make sense to be selling and giving customers
> something that you know will not work two years from now.
> Rick: If Microsoft re-evaluates in June 2015, it could push the date out.
> Tom: It is most likely that the date will stay right where it is.
> Rick: It is possible, so that’s why.
> Tom: It’s not really a date that we’re going to be looking at the
> fragility of SHA1. Because we know SHA1 is already fragile. We are looking
> at the actual exposure to customers. We are trying to figure out who gets
> harmed by using SHA1. Right now, we don’t see enough harm to justify
> pushing out the date. I recommend getting your customers started on SHA2
> now, that way, it will reduce your refunds.
> Rick: We are pushing SHA2.
> Brian: What do you think about my idea that changing server software to
> recognize that the server supports SHA2 and then serving up one certificate
> or another based on that?
> Tom: Anything we can do to promote SHA2 is a good thing, like TLS 1.2.
> Ryan Sleevi: It’s tricky. It requires action by both people on the server
> side and client side. With Chrome, we’ve seen some issues. For instance
> with ECDSA certificates, on OSX 8 verification of certificates was broken
> but TLS worked, so you have to engage in snipping to try and figure out
> what is going on. Is the TLS handshake issue coming from a Safari
> configuration or from Chrome? And there are other issues with certificate
> verification and relying on the OS. It goes back to attempting what we
> believe is a balanced approach for the user experience by telling the user
> that we don’t have full confidence in this site but allowing the user to
> proceed, but this may become more serious over time. So we’ll transition
> the user by not giving an EV indication. We’re also not going to require
> users to click through warnings.
> Brian: I can understand the ECC issue because Chrome has to support
> Windows XP that doesn’t have ECC, but as far as I know, Chrome doesn’t run
> on any platform that doesn’t support SHA2. So, when you’re running on SP 2,
> what do you do with the supported signature algorithms field of the TLS
> handshake for TLS 1.2?
> Ryan: Probably the wrong thing. [image: Description: :-)]
> Brian: Presumably, you could fix that, too.
> Ryan: Yes, we can, and we hope to resolve that in TLS 1.3, although
> supporting TLS 1.2 has been messy enough.
> Ben: Assuming the Microsoft date is not going to change, can we take that
> as a given and work around the variables that we can change and identify
> what is not going to change?
> Kirk: As Chris noted, there are two sunsets--the stated one and the panic
> one. The one thing to think about is whether Microsoft is really going to
> just turn SHA1 off so it doesn’t work. The sunset is January 2017. We could
> say that we couldn’t sell any SHA1 cert after July1 of the previous year so
> people try to get into panic mode and then give them 30-day certificates.
> Ryan: We have had discussions with cryptographers about this, “oh crap,
> panic mode” and probable collisions and without giving CAs false hope,
> there might be things that browsers could do to pre-identify potential
> collisions based on certain characteristics and that might provide a little
> bit more of a transition phase. We might be able to look at those in SHA1
> and block those certificates.
> Ben: Whatever we do should not allow customers or other CAs wiggle out by
> not having to do it. It should be above board and strict and
> programmatically enforced, and just start people toward that pain point
> without CAs having to be the police on it, because there would be chances
> of undercutting it.
> Wayne: What I’ve heard here today has changed my opinion, instead of
> assuming that all CAs are smart enough not to issue SHA1 certificates that
> expire after January 1, 2017, we should have a policy that says starting
> January 1, 2015, you’re not allowed to issue a certificate with a SHA1
> algorithm that expires after January 1, 2017. When I read Microsoft policy,
> that’s what I get, but that’s not really what it says. Maybe that is a way
> to move it forward.
> Brian: That’s almost exactly what I recommended that Firefox do, except I
> said 2014. I don’t see why we should keep accepting certificates after
> there has been time for CAs to adjust, that have a validity period that
> ends after January 1, 2017. If CAs say they need 6 months, to implement
> some changes before they are ready to do that, then that type of policy is
> very reasonable, not just for CA/B Forum to put in the BRs, but for
> browsers to start enforcing that on January 1, 2015.
> Doug: I prefer to not set a certain date because when you’re selling
> certificates, it is hard to set the price for an 18-month or 20-month
> certificate. I think that we set maximum validity periods on certain dates.
> For instance, say April 2014 is a 2-year max validity SHA1 certificate, but
> not an end date—it’s easier to program for a 2-year or a 1-year certificate.
> Wayne: My interpretation the way I hear what you are saying is after
> January 1, 2015, with my system is that I will no longer be able to sell a
> SHA1 Certificate to a customer for more than 1 year. But at the same time,
> other CAs might have different systems, but they are stuck with that.
> Brian: I understand what you’re saying.
> Chris: There’s a pro and con to what you’re saying, we want to be careful,
> but we can actually communicate this to our customers all at the same time
> in terms of policy. We could just pick a hard date.
> Brian: It makes a lot of sense for the software developers to look at the
> cryptographic concerns that have been raised and determine that based on
> these concerns, as far as securing our products goes, we stop accepting
> these certificates after this date, based on what we know, and create some
> kind of document for it. IETF is already working on that anyway, and then
> say, here is an open standard that we are going to implement. For CAs
> selling certificates to customers, then you have an open, public
> recommendation that you can point people to. Put the blame on the software
> companies.
> Rick: I agree with Doug and I disagree with Wayne. We can tell customers
> that we can sell them a SHA1 certificate that goes beyond January 1, 2017,
> but on that date your Windows box will stop trusting it. We are already
> giving that warning to customers, so it is superfluous to tell customers
> also that before then the browsers will stop trusting it. There is already
> a built in sunset date. I’d like to have the flexibility to issue beyond
> that date with the understanding that I’ll communicate with my customers.
> It just makes it a lot easier to comply.
> Ryan: It is possible that the certificate will work well beyond the sunset
> date if they are not on a system with Windows update.
> Kirk: What about a requirement that you tell a customer if you sell them a
> SHA1 certificate with an expiration date beyond 2017 it probably will not
> work on a certain applications? That sounds like it would cover what
> Symantec is already doing and it should reduce the number of customer
> support calls if we give that notice.
> Ben: What if with that motion we included some type of endorsement or
> recognition of Microsoft’s date? Then we’re self-regulating without having
> to enforce a requirement.
> Ryan: We’ve seen examples in the Forum of exceptions, but here we have an
> opportunity to work with root programs and state what has been determined
> as best practice. This could be folded into audit requirements and if you
> can’t meet the requirement then you can work with the root program for
> additional time in which to comply.
> Bob: CAs should not be selling three-year SHA1 certificates at this point.
> We shouldn’t leave a policy that allows CAs to pre-sell SHA1 certificates.
> Dean: It’s not because we are trying to sell SHA1 certificates, it is that
> customers want to buy them. Customers want to buy three-year certificates;
> they do not want to buy one-year certificates.
> Bob: The point is that you have to stop selling three-year SHA1
> certificates.
> Doug: Not necessarily. They can get a replacement certificate for free,
> only it’s a SHA2. At their leisure, they can upgrade to a SHA256.
> Rick: Clearly, after January 1, 2017, we cannot sell a SHA1 certificate of
> any duration. Our current path is best. We sell them a three-year SHA2
> certificate. If they come back and say they need a SHA1 certificate, we
> give them a three-year SHA1 certificate, and we tell them, at some point,
> you’ll probably need to switch back to the SHA2 certificate.
> Ryan: I understand where Bob is coming from on a policy perspective, but
> wouldn’t it be better to provide a warning to customers.
> Rick: That’s what we’re doing.
> Dean: Even NIST didn’t have a SHA2 certificate.
> Brian: If we cannot agree within the Forum, then individual root programs
> should announce what they intend to do. The advantage of doing it within
> the Forum is that there is consistency and everyone knows what to expect.
> As I understand the reason for the Baseline Requirements, they were to give
> CAs more consistency across browser root program policies.
> Ben: We could follow the Symantec approach and then just revoke
> certificates at that date, and it isn’t that auditable, but at least it
> gives people a date to look at, or on the other hand, maybe people want
> SHA1 certificates beyond that date, and we just leave it up to the browsers
> to turn SHA1 support off on January 1, 2017, and then who would want one of
> those certificates.
> Kirk: I see Rick’s point, why not allow people to use it past 2017.
> Rick: That’s not my point.
> Kirk: Well, I see the reasoning behind warning the user and giving them
> both a SHA1 and SHA2 certificate.
> Ryan: This pushes support to the browsers because when a site operator
> does not switch over to SHA2 people will say the browser doesn’t work. So,
> regardless of the sunset date, we’ll have to start taking away your
> security benefits soon, but it would be better to find a solution based on
> policy. If we cannot come to agreement on policy, like Brian said, then we
> are going to have different approaches, but we cannot have a situation
> where we’re going to allow CAs to run SHA1 certificates up the wire and
> pass the cost on to the browsers. The reality is that when a site breaks,
> it is not the site operator that suffers, it’s the users, and users don’t
> contact the site operator, they contact the browser or they go on social
> media and complain.
> Moudrick: We need a date for not issuing them and we need a date for not
> recognizing them.
> Ryan: That’s why we need these dates—to balance these burdens.
> Dean: The Microsoft policy has two dates. It says stop issuing SHA1 on 1
> January 2016 and that on 1 January 2017 it will stop recognizing SHA1
> certificates.
> Rick: That’s why I’m saying we need flexibility.
> Chris: The two certificates solves the refund-revenue-recognition problem.
> There is no return policy because they have something they can move over to.
> Ben: Why can’t we just adopt the Microsoft policy as the Baseline
> Requirements rule?
> Chris: Don’t we have to go with that? I was hoping we could coordinate a
> unified voice. The meeting in 2015 is not going to result in any change.
> Ryan: It is all fine that we as a CA/Browser Forum can agree on something,
> but we need to get the attention of site operators and users on this. If
> January 2016 is the date that CAs cease issuing SHA1 certificates, but site
> operators are installing 3-year certificates until then, we’re going to see
> problems when they have forgotten about it. If we cannot resolve this in
> the CA/Browser Forum, it will be something the browsers will start working
> on to get that messaging out.
> Chris: Rick, could you start putting a pain point out to customers
> starting January 2015?
> Rick: I don’t know. On one of our retail platforms, the customer buys the
> certificate based on lifetime first and then they have to choose whether it
> is SHA1 or SHA2.
> Chris: It would be great if we can all come to consensus on this together.
> Doug: I agree with Rick, because it confuses the customer because they
> want to buy a three-year certificate and they fear anything but SHA1.
> Ryan: We have known about concern with SHA1 since 2009.
> Bob: So we should be experimenting now, not in 2016.
> Ben: It sounds like most of us have some hybrid solution in place already.
> Brian: One of the reasons we should work on this now is to reduce our
> support costs in 2017. Our goal isn’t to cause anyone pain or inconvenience
> now, but to ensure that in 2017 any inconvenience or pain is as close to
> zero as possible and to make this fair to every CA, because if it is coded
> in the browser, then there are no exceptions, and everyone can plan
> accordingly. Whatever way, some CAs are going to experience some pain in
> transitioning to whatever the migration plan is implemented.
> Rick: We need to lead by example, and all CA/Browser Forum members should
> lead by example by installing SHA2 on our own websites.
> Brian: I’m not saying we all move to SHA2, I’m saying we shouldn’t have
> certificates valid into 2017 with SHA1.
> Ryan: There are market realities for why we’re all still using SHA1, but
> we need to find ways to ratchet up SHA2 so that other software vendors,
> site operators, and industry players see the move to SHA2.
> Brian: Browser checks will be implemented regardless of what the Forum
> decides, but I think the purpose of this discussion is come up with a
> unified policy statement about this issue. I believe that if we adopt
> language similar to what Microsoft has said, then CAs will have something
> to point customers to as an industry-wide standard as background for
> explaining one way or another
> Dean: I agree, but I don’t think we need to go beyond with additional
> requirements. We can’t have additional, different browser requirements.
> Iñigo: Is this for just SSL?
> Tom: No. All certificates.
> Richard: In China, the big challenge is that online trade is in the
> billions of dollars and end users will have a problem.
> Brian: But these big sites that do large amounts of business will be able
> to come up with solutions for their end users that are still on SHA1.
> Bob: Ryan has said that in Chrome they will implement a countdown meter
> that tells end users that in X days the website will stop working because
> the server has not migrated from SHA1.
> Richard: But maybe government support in China will help.
> Chris: If we can decide something here, then that will be of help with
> that.
> Ben: For a ballot, is there anything more we need to say?
> Dean: Let’s put the Microsoft language into a draft ballot and circulate
> it for discussion and comment.
> Kirk: Let’s prepare a nice PDF white paper like what we have for the
> deprecation of internal server names for the Forum that explains what is
> going to happen. Microsoft has a list of devices that don’t support SHA2,
> which we can include in the white paper as appendix. The white paper would
> say, check the list now and if you’re device is on the list, switch that
> device out now because it won’t work with SHA2.
> Ben: Good idea, because we have to remember to do outreach on this.
> *Kirk R. Hall*
> Operations Director, Trust Services
> Trend Micro
> +1.503.753.3088
> The information contained in this email and any attachments is confidential
> and may be subject to copyright or other intellectual property protection.
> If you are not the intended recipient, you are not authorized to use or
> disclose this information, and we request that you notify us by reply mail or
> telephone and delete the original message from your mail system.
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
> The information contained in this email and any attachments is confidential
> and may be subject to copyright or other intellectual property protection.
> If you are not the intended recipient, you are not authorized to use or
> disclose this information, and we request that you notify us by reply mail or
> telephone and delete the original message from your mail system.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20140825/e5babdef/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 168 bytes
Desc: not available
Url : https://cabforum.org/pipermail/public/attachments/20140825/e5babdef/attachment-0001.png 

More information about the Public mailing list