Requiring OCSP for EV (was Re: [ct-policy] Proposed changes to EV/CT Plan)
Ryan Sleevi
bcc: ct-policy
cc: net-dev, security-dev
Responses inline.
On Nov 24, 2014 10:39 AM, "Rob Stradling" <robs...@gmail.com> wrote:
>
>
> On 20/11/14 21:37, Ryan Sleevi wrote:
>>
>>
>> On Thu, Nov 20, 2014 at 7:50 AM, Rob Stradling <robs...@gmail.com> wrote:
>>>
>>>
>>> On 20/11/14 15:46, Richard Salz wrote:
>>> <snip>
>>>>
>>>> And again, if there aren't enough logs out there, stapling does nothing. And by my reading of the spec and [trans] mailing list discussions, I took stapling to be a temporary thing until SCT embedding was done. Apparently that's not correct, but it sure does (did) seem like a reasonable interpretation of things.
>>>
>>>
>>> There are no plans to deprecate any of the 3 SCT distribution mechanisms (certificate extension, OCSP response extension, SCT TLS extension), so to label any of them as "temporary" is misleading IMHO.
>>
>>
>> There are indeed no plans to deprecate embedding SCTs. However, embedding SCTs is fundamentally more risky than stapling, because once issued, it cannot be changed. Stapling provides a robust means for ongoing transparency, but requires server operators to support it.
>>
>> Thus embedding is conceptually transitional until stapling becomes ubiquitous, after which stapling will be the "preferred" method.
>
>
> I fear that OCSP stapling will never become truly ubiquitous. Even when the feature is available in the server software, some server operators don't want to allow outbound connections from their servers.
>
>
>> Note that for EV certificates, it is extremely likely that stapling will become mandatory in the future, so that too will address some of these issues.
>
>
> Ryan, could you explain this statement?
> Should we interpret it as an official announcement that Google intends to start requiring OCSP Stapling for EV in Chrom[e|ium] at some point in the future?
Rob, Surely you don't think I would slip in a requirement that subtlely, do you? :)
I would say that it's very much under early discussion, but there is hardly any commitment to require it. I would say we aren't alone in discussing it, though.
However, it is worth noting that this is not a CA concern so much as a site operator concern. CAs do not have to change any of their infrastructure to support stapling, beyond simply supporting OCSP, which is already required. This is about deployment considerations in order to have the browser signal high confidence and security signals to the user.
> Or are you saying that you intend to propose a CABForum ballot re: mandatory inclusion of the Must-Staple certificate extension in EV certs?
> Or what?
>
I think we are constantly evaluating ways to ensure that the security levels we communicate to users reflects both the degree of assurances we, as a UA, have, but also what user expectations are when using Chrome.
Consider, for example, that Chrome 41 now communicates when you're using outdated crypto (e.g. non-AEAD, non-PFS, TLS <1.2), rather than wording that implies that 256-bit CBC is better than 128-bit GCM. Support for these bare minimum modes is already required by HTTP/2, for example (Section 9.2.2), and is increasingly the only level of TLS in which we have reasonable confidence. You can already see this in the TLS 1.3 drafts.
For users, the expectation is that an EV certificate represents not just assurances of the site's identity, but some degree of security. Regardless of whether or not that is truly possible with EV (since it suffers the "same origin problem" of being the same origin as DV, ergo DV is the true security level of EV), it definitely does not align with users' perceived expectations to have a site serving an EV certificate over SSL3 (as an unfortunate number do...)
I expect that as we discuss more, we will have more concrete proposals for the community at large. However, I would say the zeitgeist is very much that EV should represent the "meeting the minimum of high security" - which would be PFS, AEAD, and TLS1.2+.
For certificates, we know revocation is broken in many practical ways. I think similar to ciphersuites, it may be treated that EV evaluation is implicitly (not explicitly) Must-Staple. If a site fails to staple a fresh OCSP response, downgrading to DV seems an eminently reasonable course of action, since we lack the assurances as to certificate's freshness and accuracy. This is the same as downgrading to DV when we lack confidence and assurance that the CA is operating according to their stated policies and in the public interest; that is to say, when we lack SCT information.
> For Chrome, AIUI you already aim to have your CRLSets cover all EV certs, so why demand OCSP Stapling for EV as well?
>
This is not correct, and something we have repeatedly clarified. CRLSets first and foremost has been a means to deal with emergency revocations outside of the binary updates, such as those employed by Firefox, or system updates, such as those employed by Microsoft (prior to certificate distrust lists, which operate comparably) or Apple. Our commitment is to rapid response, and the focus here is on intermediates and certificates with powerful/dangerous capabilities that put a broad base of users at risk.
In the course of developing this, we saw an opportunity to optimize some of the CRL delivery for end-entity certs, but this was merely opportunistic. While we still employ it, especially for CAs that can provide meaningful revocation information, this is a "nice to have", and may be removed in the future. While I'm sure this would kick off a centithread alone, I don't think we should focus on this.
> What about when the RFC6962 TLS extension is being used - would OCSP Stapling still be mandatory then?
For EV treatment, I think the discussion of CT would be independent of OCSP. That is, treating EV as implicitly OCSP Must-Staple is NOT for CT purposes (although it IS quite convenient for these), but for basic assurances of the EV certificate itself, and to allow CAs the ability they desire, which is the ability to revoke such certificates in a way that actually works for the WebPKI.
As a CA, nominally, this requires no action - any such changes would be server deployment. However, as gatekeepers of a secure Internet, whose business models and marketing depend very much on the promotion of security, this is a fantastic opportunity for CAs to invest in meaningful improvements towards the infrastructure of their customers. Solutions like Let's Encrypt and SSLMate show there are ample opportunities for CAs to help their customers meaningfully move the needle of security further.
For example, if you know of customers of yours who are wary to deploy positive technologies like OCSP stapling, perhaps you can work with them to understand their needs and find alternative ways for OCSP deployment, such as push-models rather than pull. Many CAs have invested heavily in solutions to facilitate air gapped networks and offline signing use cases, and I can think of few people more qualified to understand the problems, challenges, and possible solutions for these sets of issues than the CAs themselves.
>
> Thanks.
>
> --
> Rob Stradling
> Senior Research & Development Scientist
> COMODO - Creating Trust Online
>
>
Richard Salz
>>> become mandatory in the future, so that too will address some of these
>>> issues.
> However, it is worth noting that this is not a CA concern so much as a site
> operator concern. CAs do not have to change any of their infrastructure to
> support stapling
change. But yes, the bigger impact is probably on those running the
web server.
> For certificates, we know revocation is broken in many practical ways.
non-existent. :)
Once the cert is CT-logged, then a standard OCSP response should
suffice, rather than an SCT-OCSP, right?
Ryan Sleevi
On Nov 24, 2014 4:08 PM, "Richard Salz" <rich...@gmail.com> wrote:
>
> >>> Note that for EV certificates, it is extremely likely that stapling will
> >>> become mandatory in the future, so that too will address some of these
> >>> issues.
>
> When you say OCSP staple, do you mean staple with SCT's?
No, stapling in general. That is, how SCTs are treated is independent of how revocation is treated.
>
> > However, it is worth noting that this is not a CA concern so much as a site
> > operator concern. CAs do not have to change any of their infrastructure to
> > support stapling
>
> If you mean SCT-OCSP then I'd think that this would be a responder
> change. But yes, the bigger impact is probably on those running the
> web server.
>
Exactly so, but I can't see us requiring this. That is, it offers a path for CAs to deal with a variety of a logs without having to make a one time decision on which logs to use at issuance.
> > For certificates, we know revocation is broken in many practical ways.
>
> I'd go stronger than that -- fundamentally broken or essentially
> non-existent. :)
>
> Once the cert is CT-logged, then a standard OCSP response should
> suffice, rather than an SCT-OCSP, right?
Correct. But a requirement of OCSP stapling on the deployment side should hopefully make it easier for CAs to deal with SCT issuance in the future, by deferring it to OCSP response time (whether online or offline is up to the CA)
Richard Salz
(Er, we just agreed; must be a cold day in hell today :)
Rob Stradling
<snip>
>> Note that for EV certificates, it is extremely likely that stapling will become mandatory in the future, so that too will address some of these issues.
>
>
> Ryan, could you explain this statement?
> Should we interpret it as an official announcement that Google intends to start requiring OCSP Stapling for EV in Chrom[e|ium] at some point in the future?Rob, Surely you don't think I would slip in a requirement that subtlely, do you? :)
I would say that it's very much under early discussion, but there is hardly any commitment to require it. I would say we aren't alone in discussing it, though.
However, it is worth noting that this is not a CA concern so much as a site operator concern.
CAs do not have to change any of their infrastructure to support stapling, beyond simply supporting OCSP, which is already required. This is about deployment considerations in order to have the browser signal high confidence and security signals to the user.
> Or are you saying that you intend to propose a CABForum ballot re: mandatory inclusion of the Must-Staple certificate extension in EV certs?
> Or what?
>I think we are constantly evaluating ways to ensure that the security levels we communicate to users reflects both the degree of assurances we, as a UA, have, but also what user expectations are when using Chrome.
Consider, for example, that Chrome 41 now communicates when you're using outdated crypto (e.g. non-AEAD, non-PFS, TLS <1.2), rather than wording that implies that 256-bit CBC is better than 128-bit GCM. Support for these bare minimum modes is already required by HTTP/2, for example (Section 9.2.2), and is increasingly the only level of TLS in which we have reasonable confidence. You can already see this in the TLS 1.3 drafts.
For users, the expectation is that an EV certificate represents not just assurances of the site's identity, but some degree of security. Regardless of whether or not that is truly possible with EV (since it suffers the "same origin problem" of being the same origin as DV, ergo DV is the true security level of EV), it definitely does not align with users' perceived expectations to have a site serving an EV certificate over SSL3 (as an unfortunate number do...)
I expect that as we discuss more, we will have more concrete proposals for the community at large. However, I would say the zeitgeist is very much that EV should represent the "meeting the minimum of high security" - which would be PFS, AEAD, and TLS1.2+.
For certificates, we know revocation is broken in many practical ways. I think similar to ciphersuites, it may be treated that EV evaluation is implicitly (not explicitly) Must-Staple. If a site fails to staple a fresh OCSP response, downgrading to DV seems an eminently reasonable course of action, since we lack the assurances as to certificate's freshness and accuracy. This is the same as downgrading to DV when we lack confidence and assurance that the CA is operating according to their stated policies and in the public interest; that is to say, when we lack SCT information.
> For Chrome, AIUI you already aim to have your CRLSets cover all EV certs, so why demand OCSP Stapling for EV as well?
>This is not correct, and something we have repeatedly clarified.
CRLSets first and foremost has been a means to deal with emergency revocations outside of the binary updates, such as those employed by Firefox, or system updates, such as those employed by Microsoft (prior to certificate distrust lists, which operate comparably) or Apple. Our commitment is to rapid response, and the focus here is on intermediates and certificates with powerful/dangerous capabilities that put a broad base of users at risk.
In the course of developing this, we saw an opportunity to optimize some of the CRL delivery for end-entity certs, but this was merely opportunistic. While we still employ it, especially for CAs that can provide meaningful revocation information, this is a "nice to have", and may be removed in the future. While I'm sure this would kick off a centithread alone, I don't think we should focus on this.
> What about when the RFC6962 TLS extension is being used - would OCSP Stapling still be mandatory then?
For EV treatment, I think the discussion of CT would be independent of OCSP. That is, treating EV as implicitly OCSP Must-Staple is NOT for CT purposes (although it IS quite convenient for these), but for basic assurances of the EV certificate itself, and to allow CAs the ability they desire, which is the ability to revoke such certificates in a way that actually works for the WebPKI.
As a CA, nominally, this requires no action - any such changes would be server deployment. However, as gatekeepers of a secure Internet, whose business models and marketing depend very much on the promotion of security, this is a fantastic opportunity for CAs to invest in meaningful improvements towards the infrastructure of their customers. Solutions like Let's Encrypt and SSLMate show there are ample opportunities for CAs to help their customers meaningfully move the needle of security further.
For example, if you know of customers of yours who are wary to deploy positive technologies like OCSP stapling, perhaps you can work with them to understand their needs and find alternative ways for OCSP deployment, such as push-models rather than pull. Many CAs have invested heavily in solutions to facilitate air gapped networks and offline signing use cases, and I can think of few people more qualified to understand the problems, challenges, and possible solutions for these sets of issues than the CAs themselves.
[1] http://www.ietf.org/proceedings/91/slides/slides-91-trans-6.pdf
[2] https://tools.ietf.org/html/draft-hallambaker-compressedcrlset
Ryan Sleevi
On Nov 24, 2014 10:59 PM, "Rob Stradling" <robs...@gmail.com> wrote:
>
>
> On 24/11/14 14:18, Ryan Sleevi wrote:
> <snip>
>>
>> >> Note that for EV certificates, it is extremely likely that stapling will become mandatory in the future, so that too will address some of these issues.
>>
>> >
>> >
>> > Ryan, could you explain this statement?
>> > Should we interpret it as an official announcement that Google intends to start requiring OCSP Stapling for EV in Chrom[e|ium] at some point in the future?
>>
>> Rob, Surely you don't think I would slip in a requirement that subtlely, do you? :)
>
>
> Ryan, I don't think you would do that intentionally. But I would like to avoid a repeat of the SHA-1 deprecation policy kerfuffle, where none of the CAs were aware of your alleged "announcement" for several months!
>
Well, I can't help that CAs present and discussing the matter then claimed ignorance of the very topic they spent an hour discussing and raising concerns on.
>
>> I would say that it's very much under early discussion, but there is hardly any commitment to require it. I would say we aren't alone in discussing it, though.
>>
>> However, it is worth noting that this is not a CA concern so much as a site operator concern.
>
>
> It's very much a CA concern! i.e. How many of our EV cert customers whose servers can't do OCSP stapling would ask us for their money back, because they can't achieve the EV indicator in Chrome?
>
If you sell a product that promises something will appear a certain way in a third party product, both now and in the future, then yes, you're selling something beyond your ability to support.
It would certain be a concern for CAs if customer deployment was something you insured against. The reality is you will have sold them a product that meets all of your technical obligations, and it is a matter for the customer to operationally deploy.
>
>> CAs do not have to change any of their infrastructure to support stapling, beyond simply supporting OCSP, which is already required. This is about deployment considerations in order to have the browser signal high confidence and security signals to the user.
>>
>> > Or are you saying that you intend to propose a CABForum ballot re: mandatory inclusion of the Must-Staple certificate extension in EV certs?
>> > Or what?
>> >
>>
>> I think we are constantly evaluating ways to ensure that the security levels we communicate to users reflects both the degree of assurances we, as a UA, have, but also what user expectations are when using Chrome.
>>
>> Consider, for example, that Chrome 41 now communicates when you're using outdated crypto (e.g. non-AEAD, non-PFS, TLS <1.2), rather than wording that implies that 256-bit CBC is better than 128-bit GCM. Support for these bare minimum modes is already required by HTTP/2, for example (Section 9.2.2), and is increasingly the only level of TLS in which we have reasonable confidence. You can already see this in the TLS 1.3 drafts.
>>
>> For users, the expectation is that an EV certificate represents not just assurances of the site's identity, but some degree of security. Regardless of whether or not that is truly possible with EV (since it suffers the "same origin problem" of being the same origin as DV, ergo DV is the true security level of EV), it definitely does not align with users' perceived expectations to have a site serving an EV certificate over SSL3 (as an unfortunate number do...)
>>
>> I expect that as we discuss more, we will have more concrete proposals for the community at large. However, I would say the zeitgeist is very much that EV should represent the "meeting the minimum of high security" - which would be PFS, AEAD, and TLS1.2+.
>>
>> For certificates, we know revocation is broken in many practical ways. I think similar to ciphersuites, it may be treated that EV evaluation is implicitly (not explicitly) Must-Staple. If a site fails to staple a fresh OCSP response, downgrading to DV seems an eminently reasonable course of action, since we lack the assurances as to certificate's freshness and accuracy. This is the same as downgrading to DV when we lack confidence and assurance that the CA is operating according to their stated policies and in the public interest; that is to say, when we lack SCT information.
>>
>> > For Chrome, AIUI you already aim to have your CRLSets cover all EV certs, so why demand OCSP Stapling for EV as well?
>> >
>>
>> This is not correct, and something we have repeatedly clarified.
>
>
> Thanks for clarifying again then. I must have missed your earlier clarifications.
>
>
>> CRLSets first and foremost has been a means to deal with emergency revocations outside of the binary updates, such as those employed by Firefox, or system updates, such as those employed by Microsoft (prior to certificate distrust lists, which operate comparably) or Apple. Our commitment is to rapid response, and the focus here is on intermediates and certificates with powerful/dangerous capabilities that put a broad base of users at risk.
>>
>> In the course of developing this, we saw an opportunity to optimize some of the CRL delivery for end-entity certs, but this was merely opportunistic. While we still employ it, especially for CAs that can provide meaningful revocation information, this is a "nice to have", and may be removed in the future. While I'm sure this would kick off a centithread alone, I don't think we should focus on this.
>>
>> > What about when the RFC6962 TLS extension is being used - would OCSP Stapling still be mandatory then?
>>
>> For EV treatment, I think the discussion of CT would be independent of OCSP. That is, treating EV as implicitly OCSP Must-Staple is NOT for CT purposes (although it IS quite convenient for these), but for basic assurances of the EV certificate itself, and to allow CAs the ability they desire, which is the ability to revoke such certificates in a way that actually works for the WebPKI.
>>
>> As a CA, nominally, this requires no action - any such changes would be server deployment. However, as gatekeepers of a secure Internet, whose business models and marketing depend very much on the promotion of security, this is a fantastic opportunity for CAs to invest in meaningful improvements towards the infrastructure of their customers. Solutions like Let's Encrypt and SSLMate show there are ample opportunities for CAs to help their customers meaningfully move the needle of security further.
>>
>> For example, if you know of customers of yours who are wary to deploy positive technologies like OCSP stapling, perhaps you can work with them to understand their needs and find alternative ways for OCSP deployment, such as push-models rather than pull. Many CAs have invested heavily in solutions to facilitate air gapped networks and offline signing use cases, and I can think of few people more qualified to understand the problems, challenges, and possible solutions for these sets of issues than the CAs themselves.
>
>
> Although it's still very new, I'm more optimistic right now about the chances of our CRL compression [1] [2] proposal fixing the revocation problem than I am about the chances of OCSP stapling fixing it. Because CRL compression wouldn't need server software changes and wouldn't rely on server operators being convinced to enable server features.
>
>
> [1] http://www.ietf.org/proceedings/91/slides/slides-91-trans-6.pdf
>
> [2] https://tools.ietf.org/html/draft-hallambaker-compressedcrlset
>
>
> --
> Rob Stradling
> Senior Research & Development Scientist
> COMODO - Creating Trust Online
>
Hi Rob,
I'm far, far less optimistic at all about CRL compression, which I've shared before publicly during IETF 91 and privately, and would rather focus on the technology we have - which not only works, but works rather well - than on inventing yet another mechanism.
If your challenge is figuring out whether to invest R&D into CRL compression or to work with your customers to help encourage a wider adoption of OCSP Stapling, I would absolutely encourage you to focus on the latter.
Cheers,
Ryan
Rob Stradling
On Nov 24, 2014 10:59 PM, "Rob Stradling" <robs...@gmail.com> wrote:
>
>
> On 24/11/14 14:18, Ryan Sleevi wrote:
> <snip>
>>
>> >> Note that for EV certificates, it is extremely likely that stapling will become mandatory in the future, so that too will address some of these issues.
>>
>> >
>> >
>> > Ryan, could you explain this statement?
>> > Should we interpret it as an official announcement that Google intends to start requiring OCSP Stapling for EV in Chrom[e|ium] at some point in the future?
>>
>> Rob, Surely you don't think I would slip in a requirement that subtlely, do you? :)
>
>
> Ryan, I don't think you would do that intentionally. But I would like to avoid a repeat of the SHA-1 deprecation policy kerfuffle, where none of the CAs were aware of your alleged "announcement" for several months!
>Well, I can't help that CAs present and discussing the matter then claimed ignorance of the very topic they spent an hour discussing and raising concerns on.
Then, 6 months later, you did make a policy announcement about your SHA-1 deprecation plan, with a timescale that most (if not all) of the CAs considered to be unfairly aggressive. You used the fact that a discussion had taken place 6 months earlier to justify that aggressive timescale.
I don't understand why you think it was reasonable to expect the CAs to divine your future, not-yet-announced policy from a discussion about what Chrome might possibly do at some point in the future.
Possibilities are indistinguishable from noise. Policies are what count.
That said, I'm optimistic that we won't see a repeat of this sort of kerfuffle, on the basis of your post to the ct-policy list a few days ago that said:
"When a change to the policy is announced to this list, it will be quite clear that the policy has changed. Until then, the policy HAS NOT changed - it is merely being discussed."
BTW, it seems odd that the Chrome Root Certificate Policy page [1] doesn't even mention your SHA-1 deprecation plan! Does that mean it's not actually your policy yet?!?
[1] http://www.chromium.org/Home/chromium-security/root-ca-policy
>> I would say that it's very much under early discussion, but there is hardly any commitment to require it. I would say we aren't alone in discussing it, though.
>>
>> However, it is worth noting that this is not a CA concern so much as a site operator concern.
>
>
> It's very much a CA concern! i.e. How many of our EV cert customers whose servers can't do OCSP stapling would ask us for their money back, because they can't achieve the EV indicator in Chrome?
>If you sell a product that promises something will appear a certain way in a third party product, both now and in the future, then yes, you're selling something beyond your ability to support.
It would certain be a concern for CAs if customer deployment was something you insured against. The reality is you will have sold them a product that meets all of your technical obligations, and it is a matter for the customer to operationally deploy.
Like it or not, customers buy EV certs because they want the green bar to appear in their customers' browsers.
<snip>
Hi Rob,
I'm far, far less optimistic at all about CRL compression, which I've shared before publicly during IETF 91 and privately, and would rather focus on the technology we have - which not only works, but works rather well - than on inventing yet another mechanism.
If your challenge is figuring out whether to invest R&D into CRL compression or to work with your customers to help encourage a wider adoption of OCSP Stapling, I would absolutely encourage you to focus on the latter.
Cheers,
Ryan
What, if any, are your fundamental objections to CRL compression?
Thanks.
Ryan Sleevi
On 25/11/14 05:46, Ryan Sleevi wrote:
On Nov 24, 2014 10:59 PM, "Rob Stradling" <robs...@gmail.com> wrote:
>
>
> On 24/11/14 14:18, Ryan Sleevi wrote:
> <snip>
>>
>> >> Note that for EV certificates, it is extremely likely that stapling will become mandatory in the future, so that too will address some of these issues.
>>
>> >
>> >
>> > Ryan, could you explain this statement?
>> > Should we interpret it as an official announcement that Google intends to start requiring OCSP Stapling for EV in Chrom[e|ium] at some point in the future?
>>
>> Rob, Surely you don't think I would slip in a requirement that subtlely, do you? :)
>
>
> Ryan, I don't think you would do that intentionally. But I would like to avoid a repeat of the SHA-1 deprecation policy kerfuffle, where none of the CAs were aware of your alleged "announcement" for several months!
>Well, I can't help that CAs present and discussing the matter then claimed ignorance of the very topic they spent an hour discussing and raising concerns on.
Ryan, AFAIK nobody who was present at the CABForum F2F during which that discussion occurred has tried to claim that that discussion did not occur. I wasn't there, but I see from the minutes that that discussion did occur! But that's all it was: a discussion. You did not make a policy announcement at that time. AFAICT, you didn't say "we're definitely going to do this at some point" and you didn't indicate any intent to effect any changes sooner than the timescale that Microsoft had already published.
Then, 6 months later, you did make a policy announcement about your SHA-1 deprecation plan, with a timescale that most (if not all) of the CAs considered to be unfairly aggressive. You used the fact that a discussion had taken place 6 months earlier to justify that aggressive timescale.
I don't understand why you think it was reasonable to expect the CAs to divine your future, not-yet-announced policy from a discussion about what Chrome might possibly do at some point in the future.
Possibilities are indistinguishable from noise. Policies are what count.
That said, I'm optimistic that we won't see a repeat of this sort of kerfuffle, on the basis of your post to the ct-policy list a few days ago that said:
"When a change to the policy is announced to this list, it will be quite clear that the policy has changed. Until then, the policy HAS NOT changed - it is merely being discussed."
BTW, it seems odd that the Chrome Root Certificate Policy page [1] doesn't even mention your SHA-1 deprecation plan! Does that mean it's not actually your policy yet?!?
[1] http://www.chromium.org/Home/chromium-security/root-ca-policy
Peter Bowen
> On Mon, Dec 1, 2014 at 1:51 PM, Rob Stradling <robs...@gmail.com> wrote:
>>
>> considered to be unfairly aggressive. You used the fact that a discussion
>> had taken place 6 months earlier to justify that aggressive timescale.
>>
>> kerfuffle, on the basis of your post to the ct-policy list a few days ago
>> that said:
>> "When a change to the policy is announced to this list, it will be quite
>> clear that the policy has changed. Until then, the policy HAS NOT changed -
>> it is merely being discussed."
>
>>> I would say that it's very much under early discussion, but there is
>>> hardly any commitment to require it. I would say we aren't alone in
>>> discussing it, though.
>>>
>>> However, it is worth noting that this is not a CA concern so much as a
>>> site operator concern.
>>
>> It's very much a CA concern! i.e. How many of our EV cert customers
>> whose servers can't do OCSP stapling would ask us for their money back,
>> because they can't achieve the EV indicator in Chrome?
>>
>>> If you sell a product that promises something will appear a certain way in
>>> a third party product, both now and in the future, then yes, you're selling
>>> something beyond your ability to support.
>>>
>>> It would certain be a concern for CAs if customer deployment was something
>>> you insured against. The reality is you will have sold them a product that
>>> meets all of your technical obligations, and it is a matter for the customer
>>> to operationally deploy.
>>>
>> That the CA has met all of their technical obligations isn't much of a
>> sales pitch for EV certs, unfortunately.
>>
>> Like it or not, customers buy EV certs because they want the green bar to
>> appear in their customers' browsers.
agreement on what product the browsers are asking CAs to provide. It
does appear that customers (both browser users and server operators)
are asking for a product that allows them to cause the browser to
provide certain UI features, namely a "secure" icon (for all "SSL
certificates") and a "green bar" (for "Extended Validation"
certificates).
Is there a clear statement of what Chrom(e|ium) expects of CAs? The
root certificate policy page has a little of it, but it does not
appear to clearly convey the full picture.
Thanks,
Peter
Ryan Sleevi
From this thread and others, it seems clear there is not a general
agreement on what product the browsers are asking CAs to provide. It
does appear that customers (both browser users and server operators)
are asking for a product that allows them to cause the browser to
provide certain UI features, namely a "secure" icon (for all "SSL
certificates") and a "green bar" (for "Extended Validation"
certificates).
Is there a clear statement of what Chrom(e|ium) expects of CAs? The
root certificate policy page has a little of it, but it does not
appear to clearly convey the full picture.
Thanks,
Peter