Re: [cabfpub] [Servercert-wg] [EXTERNAL]Re: Ballot SC6 - Revocation Timeline Extension

[Wayne Thayer via Public]

On Tue, Sep 4, 2018 at 11:10 AM Ryan Sleevi via Servercert-wg <
servercert...@cabforum.org> wrote:

>
> On Tue, Sep 4, 2018 at 1:53 PM Dimitris Zacharopoulos 
> wrote:
>
>> The CA will still get an "unclean" report anyway because of the RFC5280
>>> violation or the mis-issuance per se, we are not debating that. I am only
>>> pointing out the requirement to revoke within 24 hours or 5 days. Does this
>>> make it clearer?
>>>
>>
>> You are, though, because that's not accurate to suggest the CA is
>> guaranteed to get a modified opinion / qualified report. If the BRs endorse
>> this, as you propose, then it's no longer a BR violation.
>>
>>
>> That is a very strange interpretation of the BRs, at least for me. IMO,
>> if a CA issues a Certificate that has incorrect encoding, it is definitely
>> a violation of the BRs under a specific section and that is expected to be
>> in the Auditor findings. If the BRs allowed that certificate to remain
>> valid until the Subscriber rolled-over and not be revoked in 24 hours or 5
>> days but with disclosing the case (as you had suggested in earlier posts),
>> then that would not be an additional violation. Now, we live situations
>> where CAs are doing multiple violations; one being the mis-issuance and
>> another by not revoking within 24 hours.
>>
>
> We've had this discussion before, though, about creative interpretations
> of RFC 5280 being applied.
>
>
>> If the information was, say, inaccurate (the domain ownership was lost
>> due to court order), but the CA determined to optimize for availability,
>> then the CA isn't in violation of the BRs or RFC 5280 if they decide not to
>> revoke.
>>
>>
>> I'm not saying that all cases would be allowed to use this extension. We
>> seem to have separated two "classes" of revocation cases; those with
>> 24-hour and 5-day window. Perhaps the 5-day window cases might be
>> considered for extension, or not even all of them. In any case, I have no
>> strong feelings about this, just wanted this discussion to take place so we
>> have a mutual understanding of the challenges that need to be balanced.
>>
>
> As noted, I disagree with your assessment about risk (24 vs 5), but also
> more fundamentally, the view that providing availability for relying
> parties is somehow in the best determination of the CA.
>
> Consider this recently issued certificate from DigiCert -
> https://crt.sh/?id=628153824=cablint,x509lint,zlint
>
> Here, the certificate contains an invalid RSAPublicKey - the DER-encoding
> of the exponent is not minimally encoded, in that it has a leading zero
> byte. No doubt, this RSAPublicKey came from the Subscriber/Applicant - that
> is, it wasn't generated by DigiCert. I suspect DigiCert probably just took
> the value directly from a BER-encoded CSR and transplanted it, versus
> re-encoding it.
>
> One creative interpretation of CAs is to cite RFC 5280, Section 4.1, and
> note that "For signature calculation, the data that is to be signed is
> encoded using the ASN.1 distinguished encoding rules (DER)", re-echoed in
> 4.1.1.3. It should come as no surprise, then, that CAs found not to be
> issuing certificates properly formed have been arguing that their
> certificates are not mis-issued - merely, they signed something not-DER, so
> they're not-certificates (not missued-certificates). Or, alternatively,
> they've argued that the presentation format doesn't need to be DER,
> provided that the signatureValue is computed over the DER - that is, that
> Relying Parties should re-encode the BER to DER and see if the signatures
> match. If they don't, it's just "invalid signature" - not "misissued
> certificate". When you look at TLS' RFCs, you see it refers to X.509v3, not
> RFC 5280's profile of X.509v3, and that's similarly been used for creative
> interpretation.
>
> Similarly, such CAs will cite RFC 3279, which states that the RSA public
> key MUST be encoded using the ASN.1 type RSAPublicKey. However, through
> creative wording, the description of "The DER encoded RSAPublicKey is the
> value of the BIT STRING subjectPublicKey" can be read as non-exclusive -
> that is, that it could permit other inclusions.
>
> So this is a concrete example of where your argument doesn't hold water,
> and precisely the danger in trying to come up with this ranked hierarchies
> of revocation.
>
> However, let's further expand this thought experiment, and think about
> what the consequences are of having the CA make such a determination
> (Availability > Competent and Correct operation). A CA is naturally
> incentivized to optimize for Availability - the CA who never revokes their
> Subscriber certs is the CA to pick, the same as the CA that always picks
> the maximum validity period rather than the minimum. This is something
> we've seen time and time again - the worse a CA is, for the ecosystem, the
> more popular it becomes relative to its competitors. But equally, a CA that
> issues such invalid certificates, but encourages 

Re: [cabfpub] [Servercert-wg] [EXTERNAL]Re: Ballot SC6 - Revocation Timeline Extension

[Ryan Sleevi via Public]

On Tue, Sep 4, 2018 at 1:53 PM Dimitris Zacharopoulos 
wrote:

> The CA will still get an "unclean" report anyway because of the RFC5280
>> violation or the mis-issuance per se, we are not debating that. I am only
>> pointing out the requirement to revoke within 24 hours or 5 days. Does this
>> make it clearer?
>>
>
> You are, though, because that's not accurate to suggest the CA is
> guaranteed to get a modified opinion / qualified report. If the BRs endorse
> this, as you propose, then it's no longer a BR violation.
>
>
> That is a very strange interpretation of the BRs, at least for me. IMO, if
> a CA issues a Certificate that has incorrect encoding, it is definitely a
> violation of the BRs under a specific section and that is expected to be in
> the Auditor findings. If the BRs allowed that certificate to remain valid
> until the Subscriber rolled-over and not be revoked in 24 hours or 5 days
> but with disclosing the case (as you had suggested in earlier posts), then
> that would not be an additional violation. Now, we live situations where
> CAs are doing multiple violations; one being the mis-issuance and another
> by not revoking within 24 hours.
>

We've had this discussion before, though, about creative interpretations of
RFC 5280 being applied.


> If the information was, say, inaccurate (the domain ownership was lost due
> to court order), but the CA determined to optimize for availability, then
> the CA isn't in violation of the BRs or RFC 5280 if they decide not to
> revoke.
>
>
> I'm not saying that all cases would be allowed to use this extension. We
> seem to have separated two "classes" of revocation cases; those with
> 24-hour and 5-day window. Perhaps the 5-day window cases might be
> considered for extension, or not even all of them. In any case, I have no
> strong feelings about this, just wanted this discussion to take place so we
> have a mutual understanding of the challenges that need to be balanced.
>

As noted, I disagree with your assessment about risk (24 vs 5), but also
more fundamentally, the view that providing availability for relying
parties is somehow in the best determination of the CA.

Consider this recently issued certificate from DigiCert -
https://crt.sh/?id=628153824=cablint,x509lint,zlint

Here, the certificate contains an invalid RSAPublicKey - the DER-encoding
of the exponent is not minimally encoded, in that it has a leading zero
byte. No doubt, this RSAPublicKey came from the Subscriber/Applicant - that
is, it wasn't generated by DigiCert. I suspect DigiCert probably just took
the value directly from a BER-encoded CSR and transplanted it, versus
re-encoding it.

One creative interpretation of CAs is to cite RFC 5280, Section 4.1, and
note that "For signature calculation, the data that is to be signed is
encoded using the ASN.1 distinguished encoding rules (DER)", re-echoed in
4.1.1.3. It should come as no surprise, then, that CAs found not to be
issuing certificates properly formed have been arguing that their
certificates are not mis-issued - merely, they signed something not-DER, so
they're not-certificates (not missued-certificates). Or, alternatively,
they've argued that the presentation format doesn't need to be DER,
provided that the signatureValue is computed over the DER - that is, that
Relying Parties should re-encode the BER to DER and see if the signatures
match. If they don't, it's just "invalid signature" - not "misissued
certificate". When you look at TLS' RFCs, you see it refers to X.509v3, not
RFC 5280's profile of X.509v3, and that's similarly been used for creative
interpretation.

Similarly, such CAs will cite RFC 3279, which states that the RSA public
key MUST be encoded using the ASN.1 type RSAPublicKey. However, through
creative wording, the description of "The DER encoded RSAPublicKey is the
value of the BIT STRING subjectPublicKey" can be read as non-exclusive -
that is, that it could permit other inclusions.

So this is a concrete example of where your argument doesn't hold water,
and precisely the danger in trying to come up with this ranked hierarchies
of revocation.

However, let's further expand this thought experiment, and think about what
the consequences are of having the CA make such a determination
(Availability > Competent and Correct operation). A CA is naturally
incentivized to optimize for Availability - the CA who never revokes their
Subscriber certs is the CA to pick, the same as the CA that always picks
the maximum validity period rather than the minimum. This is something
we've seen time and time again - the worse a CA is, for the ecosystem, the
more popular it becomes relative to its competitors. But equally, a CA that
issues such invalid certificates, but encourages non-revocation, equally
encourages the rest of the ecosystem to do so, such that it becomes the
norm - a de facto standard of incompatibility.

If the client does not aggressively police this - at verification time -
then the ecosystem falters, because 

Re: [cabfpub] [Servercert-wg] [EXTERNAL]Re: Ballot SC6 - Revocation Timeline Extension

[Dimitris Zacharopoulos via Public]

On 4/9/2018 8:22 μμ, Ryan Sleevi wrote:



On Tue, Sep 4, 2018 at 1:08 PM Dimitris Zacharopoulos 
mailto:ji...@it.auth.gr>> wrote:




On 4/9/2018 5:53 μμ, Ryan Sleevi wrote:

I do not believe there is any justifiable or defensible reason to
extend the 5 days requirement, nor do I believe the CA should be
expected to have a 'clean' audit should they chose to do so.

CAs facing challenges of their own creation should not be
exploring "How do I keep these certs working", but "How do I make
sure I don't issue violating certs to begin with". Anything less
is gross negligence, and not the system we should be striving to
build.


Ryan, it's fine we disagree, however allow me to clarify one more
thing. I had a very different picture for the CA that got this
case. It was not "How do I keep these certs working" but "How do I
balance the need for RPs to access a service ("Availability" in
terms of C-I-A), which is also a pressing matter for Subscribers,
and "the requirement to revoke the certificate in 24 hours or 5 days".


I disagree that this is the correct prioritization. A bad CA should 
not be prioritizing availability - that sort of perverse incentive 
structure is one that several now-distrusted CAs have argued, 
precisely because it sets the wrong expectations. We've seen CAs 
unsuccessfully argue that even though they didn't validate the domain 
properly, or could not demonstrate that validation, it's still more 
important to availability.


This is no different than if your website is made inaccessible because 
your hosting provider failed to pay their power bill. I can understand 
it's inconvenient to lack availability, but your service provider is 
the one that failed, and they don't get to steal power in order to 
optimize your availability.


The CA will still get an "unclean" report anyway because of the
RFC5280 violation or the mis-issuance per se, we are not debating
that. I am only pointing out the requirement to revoke within 24
hours or 5 days. Does this make it clearer?


You are, though, because that's not accurate to suggest the CA is 
guaranteed to get a modified opinion / qualified report. If the BRs 
endorse this, as you propose, then it's no longer a BR violation.


That is a very strange interpretation of the BRs, at least for me. IMO, 
if a CA issues a Certificate that has incorrect encoding, it is 
definitely a violation of the BRs under a specific section and that is 
expected to be in the Auditor findings. If the BRs allowed that 
certificate to remain valid until the Subscriber rolled-over and not be 
revoked in 24 hours or 5 days but with disclosing the case (as you had 
suggested in earlier posts), then that would not be an additional 
violation. Now, we live situations where CAs are doing multiple 
violations; one being the mis-issuance and another by not revoking 
within 24 hours.


If the information was, say, inaccurate (the domain ownership was lost 
due to court order), but the CA determined to optimize for 
availability, then the CA isn't in violation of the BRs or RFC 5280 if 
they decide not to revoke.


I'm not saying that all cases would be allowed to use this extension. We 
seem to have separated two "classes" of revocation cases; those with 
24-hour and 5-day window. Perhaps the 5-day window cases might be 
considered for extension, or not even all of them. In any case, I have 
no strong feelings about this, just wanted this discussion to take place 
so we have a mutual understanding of the challenges that need to be 
balanced.




There is no safe way to do what you ask, nor is it reasonable to do 
what you ask. For a system built on trust, it requires trust in the 
competencies of CAs. The reality of SSL/TLS is that the cost for 
mistakes is externalized on the ecosystem - on to Subscribers, Relying 
Parties, and Application Providers - while the profits from those 
mistakes are centralized with the CA. That's a fundamentally 
imbalanced system, yet the reality we live it, but that doesn't mean 
we should further seek to exacerbate those imbalances.


Understood. Thanks for the nice discussion.

Dimitris.
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] [Servercert-wg] [EXTERNAL]Re: Ballot SC6 - Revocation Timeline Extension

[Ryan Sleevi via Public]

On Tue, Sep 4, 2018 at 1:08 PM Dimitris Zacharopoulos 
wrote:

>
>
> On 4/9/2018 5:53 μμ, Ryan Sleevi wrote:
>
> I do not believe there is any justifiable or defensible reason to extend
> the 5 days requirement, nor do I believe the CA should be expected to have
> a 'clean' audit should they chose to do so.
>
> CAs facing challenges of their own creation should not be exploring "How
> do I keep these certs working", but "How do I make sure I don't issue
> violating certs to begin with". Anything less is gross negligence, and not
> the system we should be striving to build.
>
>
> Ryan, it's fine we disagree, however allow me to clarify one more thing. I
> had a very different picture for the CA that got this case. It was not "How
> do I keep these certs working" but "How do I balance the need for RPs to
> access a service ("Availability" in terms of C-I-A), which is also a
> pressing matter for Subscribers, and "the requirement to revoke the
> certificate in 24 hours or 5 days".
>

I disagree that this is the correct prioritization. A bad CA should not be
prioritizing availability - that sort of perverse incentive structure is
one that several now-distrusted CAs have argued, precisely because it sets
the wrong expectations. We've seen CAs unsuccessfully argue that even
though they didn't validate the domain properly, or could not demonstrate
that validation, it's still more important to availability.

This is no different than if your website is made inaccessible because your
hosting provider failed to pay their power bill. I can understand it's
inconvenient to lack availability, but your service provider is the one
that failed, and they don't get to steal power in order to optimize your
availability.


> The CA will still get an "unclean" report anyway because of the RFC5280
> violation or the mis-issuance per se, we are not debating that. I am only
> pointing out the requirement to revoke within 24 hours or 5 days. Does this
> make it clearer?
>

You are, though, because that's not accurate to suggest the CA is
guaranteed to get a modified opinion / qualified report. If the BRs endorse
this, as you propose, then it's no longer a BR violation. If the
information was, say, inaccurate (the domain ownership was lost due to
court order), but the CA determined to optimize for availability, then the
CA isn't in violation of the BRs or RFC 5280 if they decide not to revoke.

There is no safe way to do what you ask, nor is it reasonable to do what
you ask. For a system built on trust, it requires trust in the competencies
of CAs. The reality of SSL/TLS is that the cost for mistakes is
externalized on the ecosystem - on to Subscribers, Relying Parties, and
Application Providers - while the profits from those mistakes are
centralized with the CA. That's a fundamentally imbalanced system, yet the
reality we live it, but that doesn't mean we should further seek to
exacerbate those imbalances.
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] [Servercert-wg] [EXTERNAL]Re: Ballot SC6 - Revocation Timeline Extension

[Dimitris Zacharopoulos via Public]

On 4/9/2018 5:53 μμ, Ryan Sleevi wrote:



On Mon, Sep 3, 2018 at 1:48 PM Dimitris Zacharopoulos 
mailto:ji...@it.auth.gr>> wrote:




On 24/8/2018 4:10 μμ, Ryan Sleevi wrote:



On Fri, Aug 24, 2018 at 1:42 AM Dimitris Zacharopoulos via
Servercert-wg mailto:servercert...@cabforum.org>> wrote:

I'm not sure if this has been discussed before (sorry if I
missed did),
but I would like to bring up the fact that there might be
Subscribers
who suffer a Key Compromise (like the ones distributed with
their own
software or embedded within customer devices), who would be
willing to
leave the compromised Certificate/Key out there until they
find a way to
replace it (that might take more than 24 hours or 5 days).
This is a
case where the Subscriber weighs the impact of Availability
in the
security properties of the offered service more than
Confidentiality.


I don't agree that the Subscriber's wishes should trump the
Relying Parties. Otherwise, we never would have deprecated SHA-1
or RSA-1024.


I agree that for cases where the risk of compromise is high (like
the SHA-1 or RSA-1024 deprecation) and the impact to the ecosystem
equally high, there should be firm requirements that mitigate this
risk. However, cases such as [1] about improper encoding of IP
Addresses as dNSName type in SAN extension, which is properly
validated information but clearly non-conformant to the
requirements, that IMHO seems to have a lower risk to the
ecosystem and impact to the Relying Parties. The impact of the
Relying Parties losing access to these services seems greater if
the CA were to revoke the Certificate within 24 hours (or even
after 5 days, because the Subscriber is not able to update their
system sooner than 5 days).


I disagree.

The only reason I am following-up on this is because there will
certainly be CAs in the future that will be tempted to violate the
5-day rule if they come across a dilemma like the one SHECA is
facing. The public would benefit from a disclosure requirement for
revocation cases where the revocation time must extended the 5
days requirement. CAs will have no excuse if they do not revoke
mis-issued certificates within the 5-day rule and not use the
disclosure provision to extend the 5-day rule and share the
particular revocation case with the public. IMO, it is better for
CAs to share pro-actively, rather than getting caught and share
the information anyway, under worse conditions.


I do not believe there is any justifiable or defensible reason to 
extend the 5 days requirement, nor do I believe the CA should be 
expected to have a 'clean' audit should they chose to do so.


CAs facing challenges of their own creation should not be exploring 
"How do I keep these certs working", but "How do I make sure I don't 
issue violating certs to begin with". Anything less is gross 
negligence, and not the system we should be striving to build.


Ryan, it's fine we disagree, however allow me to clarify one more thing. 
I had a very different picture for the CA that got this case. It was not 
"How do I keep these certs working" but "How do I balance the need for 
RPs to access a service ("Availability" in terms of C-I-A), which is 
also a pressing matter for Subscribers, and "the requirement to revoke 
the certificate in 24 hours or 5 days".


The CA will still get an "unclean" report anyway because of the RFC5280 
violation or the mis-issuance per se, we are not debating that. I am 
only pointing out the requirement to revoke within 24 hours or 5 days. 
Does this make it clearer?



Thanks,
Dimitris.
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] [Servercert-wg] [EXTERNAL]Re: Ballot SC6 - Revocation Timeline Extension

[Ryan Sleevi via Public]

On Mon, Sep 3, 2018 at 1:48 PM Dimitris Zacharopoulos 
wrote:

>
>
> On 24/8/2018 4:10 μμ, Ryan Sleevi wrote:
>
>
>
> On Fri, Aug 24, 2018 at 1:42 AM Dimitris Zacharopoulos via Servercert-wg <
> servercert...@cabforum.org> wrote:
>
>> I'm not sure if this has been discussed before (sorry if I missed did),
>> but I would like to bring up the fact that there might be Subscribers
>> who suffer a Key Compromise (like the ones distributed with their own
>> software or embedded within customer devices), who would be willing to
>> leave the compromised Certificate/Key out there until they find a way to
>> replace it (that might take more than 24 hours or 5 days). This is a
>> case where the Subscriber weighs the impact of Availability in the
>> security properties of the offered service more than Confidentiality.
>>
>
> I don't agree that the Subscriber's wishes should trump the Relying
> Parties. Otherwise, we never would have deprecated SHA-1 or RSA-1024.
>
>
> I agree that for cases where the risk of compromise is high (like the
> SHA-1 or RSA-1024 deprecation) and the impact to the ecosystem equally
> high, there should be firm requirements that mitigate this risk. However,
> cases such as [1] about improper encoding of IP Addresses as dNSName type
> in SAN extension, which is properly validated information but clearly
> non-conformant to the requirements, that IMHO seems to have a lower risk to
> the ecosystem and impact to the Relying Parties. The impact of the Relying
> Parties losing access to these services seems greater if the CA were to
> revoke the Certificate within 24 hours (or even after 5 days, because the
> Subscriber is not able to update their system sooner than 5 days).
>

I disagree.


> The only reason I am following-up on this is because there will certainly
> be CAs in the future that will be tempted to violate the 5-day rule if they
> come across a dilemma like the one SHECA is facing. The public would
> benefit from a disclosure requirement for revocation cases where the
> revocation time must extended the 5 days requirement. CAs will have no
> excuse if they do not revoke mis-issued certificates within the 5-day rule
> and not use the disclosure provision to extend the 5-day rule and share the
> particular revocation case with the public. IMO, it is better for CAs to
> share pro-actively, rather than getting caught and share the information
> anyway, under worse conditions.
>

I do not believe there is any justifiable or defensible reason to extend
the 5 days requirement, nor do I believe the CA should be expected to have
a 'clean' audit should they chose to do so.

CAs facing challenges of their own creation should not be exploring "How do
I keep these certs working", but "How do I make sure I don't issue
violating certs to begin with". Anything less is gross negligence, and not
the system we should be striving to build.
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] [Servercert-wg] [EXTERNAL]Re: Ballot SC6 - Revocation Timeline Extension

[Dimitris Zacharopoulos via Public]

On 24/8/2018 4:10 μμ, Ryan Sleevi wrote:



On Fri, Aug 24, 2018 at 1:42 AM Dimitris Zacharopoulos via 
Servercert-wg > wrote:


I'm not sure if this has been discussed before (sorry if I missed
did),
but I would like to bring up the fact that there might be Subscribers
who suffer a Key Compromise (like the ones distributed with their own
software or embedded within customer devices), who would be willing to
leave the compromised Certificate/Key out there until they find a
way to
replace it (that might take more than 24 hours or 5 days). This is a
case where the Subscriber weighs the impact of Availability in the
security properties of the offered service more than Confidentiality.


I don't agree that the Subscriber's wishes should trump the Relying 
Parties. Otherwise, we never would have deprecated SHA-1 or RSA-1024.


I agree that for cases where the risk of compromise is high (like the 
SHA-1 or RSA-1024 deprecation) and the impact to the ecosystem equally 
high, there should be firm requirements that mitigate this risk. 
However, cases such as [1] about improper encoding of IP Addresses as 
dNSName type in SAN extension, which is properly validated information 
but clearly non-conformant to the requirements, that IMHO seems to have 
a lower risk to the ecosystem and impact to the Relying Parties. The 
impact of the Relying Parties losing access to these services seems 
greater if the CA were to revoke the Certificate within 24 hours (or 
even after 5 days, because the Subscriber is not able to update their 
system sooner than 5 days).


The only reason I am following-up on this is because there will 
certainly be CAs in the future that will be tempted to violate the 5-day 
rule if they come across a dilemma like the one SHECA is facing. The 
public would benefit from a disclosure requirement for revocation cases 
where the revocation time must extended the 5 days requirement. CAs will 
have no excuse if they do not revoke mis-issued certificates within the 
5-day rule and not use the disclosure provision to extend the 5-day rule 
and share the particular revocation case with the public. IMO, it is 
better for CAs to share pro-actively, rather than getting caught and 
share the information anyway, under worse conditions.


Dimitris.


[1]: 
https://groups.google.com/d/msg/mozilla.dev.security.policy/2RCO0P-gX0g/CYJHeU7eAwAJ 






If a Subscriber doesn't want their Certificate revoked because that
might have a significant impact/damage in their service Availability,
isn't that something the ecosystem should respect and allow? Shouldn't
this be treated on a case-by-case basis? I would be in favor of
entering
clauses in the BRs to allow more than 5 days before revocation for
certain such cases, provided that the CA and the affected Subscriber
would have to disclose the case to the CA/B Forum, as Ryan
suggested in
previous discussions. Just disclosing the fact should be enough. It
would just be an additional option for the CAs and the Subscribers
that
would improve today's practices. As Jeremy demonstrated, there are
several real cases today, where CAs try to extend the 24hours
revocation
window in order to balance that Availability risk for the Subscribers
and -I might add- the Relying Parties that want to have access to the
Subscriber's services. I believe there are RPs out there that value
availability more than confidentiality. I'm not one of them, but... :)


Thoughts?
Dimitris.


___
Servercert-wg mailing list
servercert...@cabforum.org 
http://cabforum.org/mailman/listinfo/servercert-wg



___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] [Servercert-wg] [EXTERNAL]Re: Ballot SC6 - Revocation Timeline Extension

[Ryan Sleevi via Public]

On Fri, Aug 24, 2018 at 1:42 AM Dimitris Zacharopoulos via Servercert-wg <
servercert...@cabforum.org> wrote:

> I'm not sure if this has been discussed before (sorry if I missed did),
> but I would like to bring up the fact that there might be Subscribers
> who suffer a Key Compromise (like the ones distributed with their own
> software or embedded within customer devices), who would be willing to
> leave the compromised Certificate/Key out there until they find a way to
> replace it (that might take more than 24 hours or 5 days). This is a
> case where the Subscriber weighs the impact of Availability in the
> security properties of the offered service more than Confidentiality.
>

I don't agree that the Subscriber's wishes should trump the Relying
Parties. Otherwise, we never would have deprecated SHA-1 or RSA-1024.


>
> If a Subscriber doesn't want their Certificate revoked because that
> might have a significant impact/damage in their service Availability,
> isn't that something the ecosystem should respect and allow? Shouldn't
> this be treated on a case-by-case basis? I would be in favor of entering
> clauses in the BRs to allow more than 5 days before revocation for
> certain such cases, provided that the CA and the affected Subscriber
> would have to disclose the case to the CA/B Forum, as Ryan suggested in
> previous discussions. Just disclosing the fact should be enough. It
> would just be an additional option for the CAs and the Subscribers that
> would improve today's practices. As Jeremy demonstrated, there are
> several real cases today, where CAs try to extend the 24hours revocation
> window in order to balance that Availability risk for the Subscribers
> and -I might add- the Relying Parties that want to have access to the
> Subscriber's services. I believe there are RPs out there that value
> availability more than confidentiality. I'm not one of them, but... :)
>
>
> Thoughts?
> Dimitris.
>
>
> ___
> Servercert-wg mailing list
> servercert...@cabforum.org
> http://cabforum.org/mailman/listinfo/servercert-wg
>
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] [Servercert-wg] [EXTERNAL]Re: Ballot SC6 - Revocation Timeline Extension

[Dimitris Zacharopoulos via Public]

I'm not sure if this has been discussed before (sorry if I missed did),
but I would like to bring up the fact that there might be Subscribers
who suffer a Key Compromise (like the ones distributed with their own
software or embedded within customer devices), who would be willing to
leave the compromised Certificate/Key out there until they find a way to
replace it (that might take more than 24 hours or 5 days). This is a
case where the Subscriber weighs the impact of Availability in the
security properties of the offered service more than Confidentiality.

If a Subscriber doesn't want their Certificate revoked because that
might have a significant impact/damage in their service Availability,
isn't that something the ecosystem should respect and allow? Shouldn't
this be treated on a case-by-case basis? I would be in favor of entering
clauses in the BRs to allow more than 5 days before revocation for
certain such cases, provided that the CA and the affected Subscriber
would have to disclose the case to the CA/B Forum, as Ryan suggested in
previous discussions. Just disclosing the fact should be enough. It
would just be an additional option for the CAs and the Subscribers that
would improve today's practices. As Jeremy demonstrated, there are
several real cases today, where CAs try to extend the 24hours revocation
window in order to balance that Availability risk for the Subscribers
and -I might add- the Relying Parties that want to have access to the
Subscriber's services. I believe there are RPs out there that value
availability more than confidentiality. I'm not one of them, but... :)


Thoughts?
Dimitris.


___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] [Servercert-wg] [EXTERNAL]Re: Ballot SC6 - Revocation Timeline Extension

[Wayne Thayer via Public]

Doug,

On Thu, Aug 23, 2018 at 12:26 PM Doug Beattie 
wrote:

> Wayne and Ryan,
>
>
>
> I received some good out-of-band suggestions so I’m passing those along.
>
>
>
> Generally - though not always (e.g. zero days) - attacks are seen as
> 'possible', then 'feasible' before they become 'demonstrable'; there's
> nothing stopping CAs (at their own discretion) from requiring reissuance of
> customer certs based on a possible/feasible attacks - long before the risk
> of the attack becoming demonstrable.
>
>
>
> CAs adopting this methodology may stay ahead of the game (as much as one
> can) by proactively reissuing certs for keys that 'may'
> (possibly/feasibly/reasonably) be at risk of an attack‎. This provides
> better security to customers, the ecosystem, and has the large potential to
> drastically reduce the number of certs that need to be revoked and reissued
> within 5 days if this methodology becomes proven or economically feasible.
> Regardless of how CAs handle these in the possible/feasible/reasonable
> categories, drawing the line at demonstrated/proven seems like a reasonable
> statement for triggering the 5 day revocation rule.
>
>
>
>
If this is to be a 5-day requirement, then I think it needs to move out of
the definition of Key Compromise as you originally suggested. Key
Compromise is inextricably linked to the 24-hour revocation window. Are
there concerns with allowing 5-days to revoke vulnerable certificates?
>

> How about something like this:
>
>
>
> **Key Compromise**: A Private Key is said to be compromised if: a) its
> value has been disclosed to an unauthorized person, b) an unauthorized
> person has had access to the private key, or c) there exists a demonstrated
> or proven method to obtain the Private Key.
>
>
>
>
This is awfully close to the new #11: The CA is made aware of a practical
technique that exposes the Subscriber's Private Key to compromise.

I would still like to have the example of Debian weak keys somewhere, but
it could be under #11 if we agree that 5-days for revocation is acceptable.
I'm also okay with tweaking the language to "demonstrated or proven method"
if you prefer, resulting in:

11. The CA is made aware of a demonstrated or proven method that exposes
the Subscriber's Private Key to compromise, methods have been developed
that can easily calculate it based on the Public Key (such as a Debian weak
key, see http://wiki.debian.org/SSLkeys), or if there is clear evidence
that the specific method used to generate the Private Key was flawed.

- Wayne

Doug
>
>
>
> *From:* Public  *On Behalf Of *Doug Beattie
> via Public
> *Sent:* Thursday, August 23, 2018 1:38 PM
> *To:* Ryan Sleevi 
> *Cc:* servercert...@cabforum.org; CABFPub 
> *Subject:* Re: [cabfpub] [Servercert-wg] [EXTERNAL]Re: Ballot SC6 -
> Revocation Timeline Extension
>
>
>
> Exactly, let’s try to improve the language.
>
>
>
> If anyone has some better idea for how to replace this with the intended
> purpose, let’s hear it!
>
> “A Private Key is also considered compromised if methods have been
> developed that can easily calculate it based on the Public Key (such as a
> Debian weak key, see http://wiki.debian.org/SSLkeys) or if there is clear
> evidence that the specific method used to generate the Private Key was
> flawed.”
>
>
>
> Maybe:
>
> “a vulnerability has been exploited to disclose private keys”
>
>
>
> “there exist documented methods that can be used to easily extract and
> release Private Keys”  (we may need to define easily in terms of some
> measure of difficulty)
>
>
>
>
>
> Doug
>
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] [Servercert-wg] [EXTERNAL]Re: Ballot SC6 - Revocation Timeline Extension

[Doug Beattie via Public]

Wayne and Ryan,

 

I received some good out-of-band suggestions so I’m passing those along.

 

Generally - though not always (e.g. zero days) - attacks are seen as 
'possible', then 'feasible' before they become 'demonstrable'; there's nothing 
stopping CAs (at their own discretion) from requiring reissuance of customer 
certs based on a possible/feasible attacks - long before the risk of the attack 
becoming demonstrable.

 

CAs adopting this methodology may stay ahead of the game (as much as one can) 
by proactively reissuing certs for keys that 'may' 
(possibly/feasibly/reasonably) be at risk of an attack‎. This provides better 
security to customers, the ecosystem, and has the large potential to 
drastically reduce the number of certs that need to be revoked and reissued 
within 5 days if this methodology becomes proven or economically feasible. 
Regardless of how CAs handle these in the possible/feasible/reasonable 
categories, drawing the line at demonstrated/proven seems like a reasonable 
statement for triggering the 5 day revocation rule.

 

How about something like this:

 

**Key Compromise**: A Private Key is said to be compromised if: a) its value 
has been disclosed to an unauthorized person, b) an unauthorized person has had 
access to the private key, or c) there exists a demonstrated or proven method 
to obtain the Private Key.

 

Doug

 

From: Public  On Behalf Of Doug Beattie via Public
Sent: Thursday, August 23, 2018 1:38 PM
To: Ryan Sleevi 
Cc: servercert...@cabforum.org; CABFPub 
Subject: Re: [cabfpub] [Servercert-wg] [EXTERNAL]Re: Ballot SC6 - Revocation 
Timeline Extension

 

Exactly, let’s try to improve the language.

 

If anyone has some better idea for how to replace this with the intended 
purpose, let’s hear it!

“A Private Key is also considered compromised if methods have been developed 
that can easily calculate it based on the Public Key (such as a Debian weak 
key, see http://wiki.debian.org/SSLkeys) or if there is clear evidence that the 
specific method used to generate the Private Key was flawed.”

 

Maybe:

“a vulnerability has been exploited to disclose private keys”

 

“there exist documented methods that can be used to easily extract and release 
Private Keys”  (we may need to define easily in terms of some measure of 
difficulty)

 

 

Doug

 

From: Ryan Sleevi  
Sent: Thursday, August 23, 2018 12:29 PM
To: Doug Beattie 
Cc: servercert...@cabforum.org; Wayne Thayer ; CABFPub 

Subject: Re: [Servercert-wg] [EXTERNAL]Re: [cabfpub] Ballot SC6 - Revocation 
Timeline Extension

 

So I think the intent here is to capture both structural weakness and known 
weakness.

 

The framing of "has been exploited to disclose private keys" has the issue that 
it requires proof of demonstration. We saw that with Heartbleed, in which some 
CAs refused to revoke certificates until specific, individual servers were 
shown to have been compromised - even though the methodology existed to do so.

 

However, at the same time, we want to be careful with an overly broad "the 
Private Key could potentially be compromised" - because that goes the other 
way, into something extremely broad where, sure, most private keys on most 
servers are going to be vulnerable to electromagnetic emissions attacks, and so 
does that count?

 

So that's where the current approach is, or at least attempting to, thread the 
needle by balancing out with 'easily calculated' or 'clear evidence'.

 

That said, I'm all in favor of trying to provide clarity here, which is the 
intent is that if it is compromised, or easily compromised, that should be 
reasonable suspicion and call to action. I realize some CAs are going to still 
haggle over the definition of "easily", because that's not going to be a clear 
cut-and-dried answer, but maybe there's an opportunity to improve the language 
within those goals?

 

On Thu, Aug 23, 2018 at 11:54 AM Doug Beattie mailto:doug.beat...@globalsign.com> > wrote:

Ryan,

 

Yes, I mis-spoke and said the opposite of what I had intended.  We should 
generalize this statement so it applies to the 24 hour rule.


Change this:

“ A Private Key is also considered compromised if methods have been developed 
that can easily calculate it based on the Public Key (such as a Debian weak 
key, see http://wiki.debian.org/SSLkeys) or if there is clear evidence that the 
specific method used to generate the Private Key was flawed.”

 

To something like this:

“a vulnerability has been exploited to disclose private keys”

 

Why?

-  Including examples in definitions can imply you only need to look at 
those, and 

-  listing only computational efforts and poor key quality doesn’t 
cover all the cases.  

 

I’m open to a better statement, but it should cover “all cases”.

 

 

From: Ryan Sleevi mailto:sle...@google.com> > 
Sent: Thursday, August 23, 2018 11:44 AM
To: Doug Beattie mailto:doug.beat...@glo

Re: [cabfpub] [Servercert-wg] [EXTERNAL]Re: Ballot SC6 - Revocation Timeline Extension

[Doug Beattie via Public]

Exactly, let’s try to improve the language.

 

If anyone has some better idea for how to replace this with the intended 
purpose, let’s hear it!

“A Private Key is also considered compromised if methods have been developed 
that can easily calculate it based on the Public Key (such as a Debian weak 
key, see http://wiki.debian.org/SSLkeys) or if there is clear evidence that the 
specific method used to generate the Private Key was flawed.”

 

Maybe:

“a vulnerability has been exploited to disclose private keys”

 

“there exist documented methods that can be used to easily extract and release 
Private Keys”  (we may need to define easily in terms of some measure of 
difficulty)

 

 

Doug

 

From: Ryan Sleevi  
Sent: Thursday, August 23, 2018 12:29 PM
To: Doug Beattie 
Cc: servercert...@cabforum.org; Wayne Thayer ; CABFPub 

Subject: Re: [Servercert-wg] [EXTERNAL]Re: [cabfpub] Ballot SC6 - Revocation 
Timeline Extension

 

So I think the intent here is to capture both structural weakness and known 
weakness.

 

The framing of "has been exploited to disclose private keys" has the issue that 
it requires proof of demonstration. We saw that with Heartbleed, in which some 
CAs refused to revoke certificates until specific, individual servers were 
shown to have been compromised - even though the methodology existed to do so.

 

However, at the same time, we want to be careful with an overly broad "the 
Private Key could potentially be compromised" - because that goes the other 
way, into something extremely broad where, sure, most private keys on most 
servers are going to be vulnerable to electromagnetic emissions attacks, and so 
does that count?

 

So that's where the current approach is, or at least attempting to, thread the 
needle by balancing out with 'easily calculated' or 'clear evidence'.

 

That said, I'm all in favor of trying to provide clarity here, which is the 
intent is that if it is compromised, or easily compromised, that should be 
reasonable suspicion and call to action. I realize some CAs are going to still 
haggle over the definition of "easily", because that's not going to be a clear 
cut-and-dried answer, but maybe there's an opportunity to improve the language 
within those goals?

 

On Thu, Aug 23, 2018 at 11:54 AM Doug Beattie mailto:doug.beat...@globalsign.com> > wrote:

Ryan,

 

Yes, I mis-spoke and said the opposite of what I had intended.  We should 
generalize this statement so it applies to the 24 hour rule.


Change this:

“ A Private Key is also considered compromised if methods have been developed 
that can easily calculate it based on the Public Key (such as a Debian weak 
key, see http://wiki.debian.org/SSLkeys) or if there is clear evidence that the 
specific method used to generate the Private Key was flawed.”

 

To something like this:

“a vulnerability has been exploited to disclose private keys”

 

Why?

-  Including examples in definitions can imply you only need to look at 
those, and 

-  listing only computational efforts and poor key quality doesn’t 
cover all the cases.  

 

I’m open to a better statement, but it should cover “all cases”.

 

 

From: Ryan Sleevi mailto:sle...@google.com> > 
Sent: Thursday, August 23, 2018 11:44 AM
To: Doug Beattie mailto:doug.beat...@globalsign.com> >; servercert...@cabforum.org 
 
Cc: Wayne Thayer mailto:wtha...@mozilla.com> >; CABFPub 
mailto:public@cabforum.org> >
Subject: Re: [Servercert-wg] [EXTERNAL]Re: [cabfpub] Ballot SC6 - Revocation 
Timeline Extension

 

Doug,

 

I'm not sure I understand - how do you see them fitting under the 5 day rule?

 

On Thu, Aug 23, 2018 at 11:40 AM Doug Beattie via Servercert-wg 
mailto:servercert...@cabforum.org> > wrote:

Wayne,

 

I wanted to see if we we could trim down the definition of Key Compromise a bit 
more to just this:

 

**Key Compromise**: A Private Key is said to be compromised if its value has 
been disclosed to an unauthorized person or an unauthorized person has had 
access to it. 

 

I think we can remove this from your current definition because these 
situations will fall under the 5 day rule, not the 24 hour rule: 

“A Private Key is also considered compromised if methods have been developed 
that can easily calculate it based on the Public Key (such as a Debian weak 
key, see http://wiki.debian.org/SSLkeys) or if there is clear evidence that the 
specific method used to generate the Private Key was flawed.”

 

 

From: Wayne Thayer <  wtha...@mozilla.com> 
Sent: Tuesday, August 21, 2018 4:58 PM
To: Ryan Sleevi <  sle...@google.com>
Cc: Bruce Morton <  
bruce.mor...@entrustdatacard.com>; CA/B Forum Server Certificate WG Public 
Discussion List <  
servercert...@cabforum.org>; Mike Reilly (WDG) < 
 mike.rei...@microsoft.com>; Doug 

Re: [cabfpub] [Servercert-wg] [EXTERNAL]Re: Ballot SC6 - Revocation Timeline Extension

[Ryan Sleevi via Public]

So I think the intent here is to capture both structural weakness and known
weakness.

The framing of "has been exploited to disclose private keys" has the issue
that it requires proof of demonstration. We saw that with Heartbleed, in
which some CAs refused to revoke certificates until specific, individual
servers were shown to have been compromised - even though the methodology
existed to do so.

However, at the same time, we want to be careful with an overly broad "the
Private Key could potentially be compromised" - because that goes the other
way, into something extremely broad where, sure, most private keys on most
servers are going to be vulnerable to electromagnetic emissions attacks,
and so does that count?

So that's where the current approach is, or at least attempting to, thread
the needle by balancing out with 'easily calculated' or 'clear evidence'.

That said, I'm all in favor of trying to provide clarity here, which is the
intent is that if it is compromised, or easily compromised, that should be
reasonable suspicion and call to action. I realize some CAs are going to
still haggle over the definition of "easily", because that's not going to
be a clear cut-and-dried answer, but maybe there's an opportunity to
improve the language within those goals?

On Thu, Aug 23, 2018 at 11:54 AM Doug Beattie 
wrote:

> Ryan,
>
>
>
> Yes, I mis-spoke and said the opposite of what I had intended.  We should
> generalize this statement so it applies to the 24 hour rule.
>
>
> Change this:
>
> “ A Private Key is also considered compromised if methods have been
> developed that can easily calculate it based on the Public Key (such as a
> Debian weak key, see http://wiki.debian.org/SSLkeys) or if there is clear
> evidence that the specific method used to generate the Private Key was
> flawed.”
>
>
>
> To something like this:
>
> “a vulnerability has been exploited to disclose private keys”
>
>
>
> Why?
>
> -  Including examples in definitions can imply you only need to
> look at those, and
>
> -  listing only computational efforts and poor key quality
> doesn’t cover all the cases.
>
>
>
> I’m open to a better statement, but it should cover “all cases”.
>
>
>
>
>
> *From:* Ryan Sleevi 
> *Sent:* Thursday, August 23, 2018 11:44 AM
> *To:* Doug Beattie ;
> servercert...@cabforum.org
> *Cc:* Wayne Thayer ; CABFPub 
> *Subject:* Re: [Servercert-wg] [EXTERNAL]Re: [cabfpub] Ballot SC6 -
> Revocation Timeline Extension
>
>
>
> Doug,
>
>
>
> I'm not sure I understand - how do you see them fitting under the 5 day
> rule?
>
>
>
> On Thu, Aug 23, 2018 at 11:40 AM Doug Beattie via Servercert-wg <
> servercert...@cabforum.org> wrote:
>
> Wayne,
>
>
>
> I wanted to see if we we could trim down the definition of Key Compromise
> a bit more to just this:
>
>
>
> **Key Compromise**: A Private Key is said to be compromised if its value
> has been disclosed to an unauthorized person or an unauthorized person has
> had access to it.
>
>
>
> I think we can remove this from your current definition because these
> situations will fall under the 5 day rule, not the 24 hour rule:
>
> “A Private Key is also considered compromised if methods have been
> developed that can easily calculate it based on the Public Key (such as a
> Debian weak key, see http://wiki.debian.org/SSLkeys) or if there is clear
> evidence that the specific method used to generate the Private Key was
> flawed.”
>
>
>
>
>
> *From:* Wayne Thayer 
> *Sent:* Tuesday, August 21, 2018 4:58 PM
> *To:* Ryan Sleevi 
> *Cc:* Bruce Morton ; CA/B Forum Server
> Certificate WG Public Discussion List ; Mike
> Reilly (WDG) ; Doug Beattie <
> doug.beat...@globalsign.com>; Tim Hollebeek ;
> CA/Browser Forum Public Discussion List 
> *Subject:* Re: [Servercert-wg] [EXTERNAL]Re: [cabfpub] Ballot SC6 -
> Revocation Timeline Extension
>
>
>
> Thanks for the comments Mike. Based on the discussion, I would propose two
> changes:
>
>
>
> 1. Regarding your second point about "The technical content or format of
> the Certificate presents an unacceptable risk", my interpretation of the
> language in the context of the section is that the "given period of time"
> must be no more than 5 days, which doesn't make a lot of sense. Bruce's
> interpretation seems more reasonable but not what the current wording
> really means.  If this language only comes into effect after a deadline is
> set, as implied by the example, then any requirement to revoke can be
> stipulated by whomever set the deadline (root program or CAB Forum ballot).
> It follows that this reason for revocation (in both the Subscriber and
> Subordinate CA sections) is unnecessary and can be removed.
>
>
>
> 2. Regarding the third point, add the Subscriber in addition to the
> "entity reporting the Certificate Problem Report" as someone to consult
> when deciding when to revoke the certificate. I think the other
> clarifications you suggested are already covered.
>
>
>
> Here are the changes I've captured from the 

Re: [cabfpub] [Servercert-wg] [EXTERNAL]Re: Ballot SC6 - Revocation Timeline Extension

[Doug Beattie via Public]

Ryan,

 

Yes, I mis-spoke and said the opposite of what I had intended.  We should 
generalize this statement so it applies to the 24 hour rule.


Change this:

“ A Private Key is also considered compromised if methods have been developed 
that can easily calculate it based on the Public Key (such as a Debian weak 
key, see http://wiki.debian.org/SSLkeys) or if there is clear evidence that the 
specific method used to generate the Private Key was flawed.”

 

To something like this:

“a vulnerability has been exploited to disclose private keys”

 

Why?

-  Including examples in definitions can imply you only need to look at 
those, and 

-  listing only computational efforts and poor key quality doesn’t 
cover all the cases.  

 

I’m open to a better statement, but it should cover “all cases”.

 

 

From: Ryan Sleevi  
Sent: Thursday, August 23, 2018 11:44 AM
To: Doug Beattie ; servercert...@cabforum.org
Cc: Wayne Thayer ; CABFPub 
Subject: Re: [Servercert-wg] [EXTERNAL]Re: [cabfpub] Ballot SC6 - Revocation 
Timeline Extension

 

Doug,

 

I'm not sure I understand - how do you see them fitting under the 5 day rule?

 

On Thu, Aug 23, 2018 at 11:40 AM Doug Beattie via Servercert-wg 
mailto:servercert...@cabforum.org> > wrote:

Wayne,

 

I wanted to see if we we could trim down the definition of Key Compromise a bit 
more to just this:

 

**Key Compromise**: A Private Key is said to be compromised if its value has 
been disclosed to an unauthorized person or an unauthorized person has had 
access to it. 

 

I think we can remove this from your current definition because these 
situations will fall under the 5 day rule, not the 24 hour rule: 

“A Private Key is also considered compromised if methods have been developed 
that can easily calculate it based on the Public Key (such as a Debian weak 
key, see http://wiki.debian.org/SSLkeys) or if there is clear evidence that the 
specific method used to generate the Private Key was flawed.”

 

 

From: Wayne Thayer mailto:wtha...@mozilla.com> > 
Sent: Tuesday, August 21, 2018 4:58 PM
To: Ryan Sleevi mailto:sle...@google.com> >
Cc: Bruce Morton mailto:bruce.mor...@entrustdatacard.com> >; CA/B Forum Server Certificate WG 
Public Discussion List mailto:servercert...@cabforum.org> >; Mike Reilly (WDG) 
mailto:mike.rei...@microsoft.com> >; Doug Beattie 
mailto:doug.beat...@globalsign.com> >; Tim 
Hollebeek mailto:tim.holleb...@digicert.com> >; 
CA/Browser Forum Public Discussion List mailto:public@cabforum.org> >
Subject: Re: [Servercert-wg] [EXTERNAL]Re: [cabfpub] Ballot SC6 - Revocation 
Timeline Extension

 

Thanks for the comments Mike. Based on the discussion, I would propose two 
changes:

 

1. Regarding your second point about "The technical content or format of the 
Certificate presents an unacceptable risk", my interpretation of the language 
in the context of the section is that the "given period of time" must be no 
more than 5 days, which doesn't make a lot of sense. Bruce's interpretation 
seems more reasonable but not what the current wording really means.  If this 
language only comes into effect after a deadline is set, as implied by the 
example, then any requirement to revoke can be stipulated by whomever set the 
deadline (root program or CAB Forum ballot). It follows that this reason for 
revocation (in both the Subscriber and Subordinate CA sections) is unnecessary 
and can be removed.

 

2. Regarding the third point, add the Subscriber in addition to the "entity 
reporting the Certificate Problem Report" as someone to consult when deciding 
when to revoke the certificate. I think the other clarifications you suggested 
are already covered.

 

Here are the changes I've captured from the discussion to-date:

 

https://github.com/wthayer/documents/commit/2d427a74f604d635609602bed2808e5d96ee03ad

 

I'll publish a 'version 2' of the ballot when it appears that there are no 
further concerns.

 

- Wayne

 

 

On Tue, Aug 21, 2018 at 10:08 AM Ryan Sleevi mailto:sle...@google.com> > wrote:

 

On Tue, Aug 21, 2018 at 1:01 PM Bruce Morton via Servercert-wg 
mailto:servercert...@cabforum.org> > wrote:

Per Mike’s items:

 

1.  7 days would be preferable as this would provide a “business week” for 
the CA to investigate the issue. It will also provide 2 extra days to have 
reach and discuss the issue with the Reporter and the Subscriber.

As Mike summarized correctly, Google felt and feels that 7 days is too long. We 
repeatedly asked for specific examples and details of where the additional time 
would be valuable, and to date, no CA has provided them. We had previously 
proposed that anything longer should require a mandatory public, unredacted 
incident report from the CA, and the concession to avoid such a requirement was 
to find a balance, while also ensuring that CAs were gathering and collecting 
concrete reports to provide that.

 

2.  Given the examples for unacceptable risk, I would assume that this 

Re: [cabfpub] [Servercert-wg] [EXTERNAL]Re: Ballot SC6 - Revocation Timeline Extension

[Ryan Sleevi via Public]

Doug,

I'm not sure I understand - how do you see them fitting under the 5 day
rule?

On Thu, Aug 23, 2018 at 11:40 AM Doug Beattie via Servercert-wg <
servercert...@cabforum.org> wrote:

> Wayne,
>
>
>
> I wanted to see if we we could trim down the definition of Key Compromise
> a bit more to just this:
>
>
>
> **Key Compromise**: A Private Key is said to be compromised if its value
> has been disclosed to an unauthorized person or an unauthorized person has
> had access to it.
>
>
>
> I think we can remove this from your current definition because these
> situations will fall under the 5 day rule, not the 24 hour rule:
>
> “A Private Key is also considered compromised if methods have been
> developed that can easily calculate it based on the Public Key (such as a
> Debian weak key, see http://wiki.debian.org/SSLkeys) or if there is clear
> evidence that the specific method used to generate the Private Key was
> flawed.”
>
>
>
>
>
> *From:* Wayne Thayer 
> *Sent:* Tuesday, August 21, 2018 4:58 PM
> *To:* Ryan Sleevi 
> *Cc:* Bruce Morton ; CA/B Forum Server
> Certificate WG Public Discussion List ; Mike
> Reilly (WDG) ; Doug Beattie <
> doug.beat...@globalsign.com>; Tim Hollebeek ;
> CA/Browser Forum Public Discussion List 
> *Subject:* Re: [Servercert-wg] [EXTERNAL]Re: [cabfpub] Ballot SC6 -
> Revocation Timeline Extension
>
>
>
> Thanks for the comments Mike. Based on the discussion, I would propose two
> changes:
>
>
>
> 1. Regarding your second point about "The technical content or format of
> the Certificate presents an unacceptable risk", my interpretation of the
> language in the context of the section is that the "given period of time"
> must be no more than 5 days, which doesn't make a lot of sense. Bruce's
> interpretation seems more reasonable but not what the current wording
> really means.  If this language only comes into effect after a deadline is
> set, as implied by the example, then any requirement to revoke can be
> stipulated by whomever set the deadline (root program or CAB Forum ballot).
> It follows that this reason for revocation (in both the Subscriber and
> Subordinate CA sections) is unnecessary and can be removed.
>
>
>
> 2. Regarding the third point, add the Subscriber in addition to the
> "entity reporting the Certificate Problem Report" as someone to consult
> when deciding when to revoke the certificate. I think the other
> clarifications you suggested are already covered.
>
>
>
> Here are the changes I've captured from the discussion to-date:
>
>
>
>
> https://github.com/wthayer/documents/commit/2d427a74f604d635609602bed2808e5d96ee03ad
>
>
>
> I'll publish a 'version 2' of the ballot when it appears that there are no
> further concerns.
>
>
>
> - Wayne
>
>
>
>
>
> On Tue, Aug 21, 2018 at 10:08 AM Ryan Sleevi  wrote:
>
>
>
> On Tue, Aug 21, 2018 at 1:01 PM Bruce Morton via Servercert-wg <
> servercert...@cabforum.org> wrote:
>
> Per Mike’s items:
>
>
>
> 1.  7 days would be preferable as this would provide a “business
> week” for the CA to investigate the issue. It will also provide 2 extra
> days to have reach and discuss the issue with the Reporter and the
> Subscriber.
>
> As Mike summarized correctly, Google felt and feels that 7 days is too
> long. We repeatedly asked for specific examples and details of where the
> additional time would be valuable, and to date, no CA has provided them. We
> had previously proposed that anything longer should require a mandatory
> public, unredacted incident report from the CA, and the concession to avoid
> such a requirement was to find a balance, while also ensuring that CAs were
> gathering and collecting concrete reports to provide that.
>
>
>
> 2.  Given the examples for unacceptable risk, I would assume that
> this item would have a deadline set in the BRs. We have done this before
> with non-registered domain name certificates. So if the certificate has not
> been revoked by the deadline, then it must be revoked immediately. As such,
> perhaps this requirement should be better defined and also moved to the 24
> hour section.
>
> 3.  I do agree that the CA should work with both the Reporter and the
> Subscriber; however, please note that the investigation may mean that the
> certificate will not be revoked. Also, having a preliminary report within
> 24 hours may not be feasible to have a report with substantial substance as
> there may not be time to discuss with the Subscriber. I do suggest that
> within 24 hours the CA should advise the Reporter and the Subscriber that
> an investigation has started which may result in the certificate being
> revoked.
>
> I don't think this is something we'd agree on. As noted above, our goal is
> to improve the transparency. There are some who've said that the best
> solution to these issues is to know what it's like by going to work for a
> CA. Absent changing employers, the next best thing is going to be to
> improve the transparency of the ecosystem, which will improve the 

Re: [cabfpub] [Servercert-wg] [EXTERNAL]Re: Ballot SC6 - Revocation Timeline Extension

[Doug Beattie via Public]

Wayne,

 

I wanted to see if we we could trim down the definition of Key Compromise a bit 
more to just this:

 

**Key Compromise**: A Private Key is said to be compromised if its value has 
been disclosed to an unauthorized person or an unauthorized person has had 
access to it. 

 

I think we can remove this from your current definition because these 
situations will fall under the 5 day rule, not the 24 hour rule: 

“A Private Key is also considered compromised if methods have been developed 
that can easily calculate it based on the Public Key (such as a Debian weak 
key, see http://wiki.debian.org/SSLkeys) or if there is clear evidence that the 
specific method used to generate the Private Key was flawed.”

 

 

From: Wayne Thayer  
Sent: Tuesday, August 21, 2018 4:58 PM
To: Ryan Sleevi 
Cc: Bruce Morton ; CA/B Forum Server 
Certificate WG Public Discussion List ; Mike Reilly 
(WDG) ; Doug Beattie ; 
Tim Hollebeek ; CA/Browser Forum Public Discussion 
List 
Subject: Re: [Servercert-wg] [EXTERNAL]Re: [cabfpub] Ballot SC6 - Revocation 
Timeline Extension

 

Thanks for the comments Mike. Based on the discussion, I would propose two 
changes:

 

1. Regarding your second point about "The technical content or format of the 
Certificate presents an unacceptable risk", my interpretation of the language 
in the context of the section is that the "given period of time" must be no 
more than 5 days, which doesn't make a lot of sense. Bruce's interpretation 
seems more reasonable but not what the current wording really means.  If this 
language only comes into effect after a deadline is set, as implied by the 
example, then any requirement to revoke can be stipulated by whomever set the 
deadline (root program or CAB Forum ballot). It follows that this reason for 
revocation (in both the Subscriber and Subordinate CA sections) is unnecessary 
and can be removed.

 

2. Regarding the third point, add the Subscriber in addition to the "entity 
reporting the Certificate Problem Report" as someone to consult when deciding 
when to revoke the certificate. I think the other clarifications you suggested 
are already covered.

 

Here are the changes I've captured from the discussion to-date:

 

https://github.com/wthayer/documents/commit/2d427a74f604d635609602bed2808e5d96ee03ad

 

I'll publish a 'version 2' of the ballot when it appears that there are no 
further concerns.

 

- Wayne

 

 

On Tue, Aug 21, 2018 at 10:08 AM Ryan Sleevi mailto:sle...@google.com> > wrote:

 

On Tue, Aug 21, 2018 at 1:01 PM Bruce Morton via Servercert-wg 
mailto:servercert...@cabforum.org> > wrote:

Per Mike’s items:

 

1.  7 days would be preferable as this would provide a “business week” for 
the CA to investigate the issue. It will also provide 2 extra days to have 
reach and discuss the issue with the Reporter and the Subscriber.

As Mike summarized correctly, Google felt and feels that 7 days is too long. We 
repeatedly asked for specific examples and details of where the additional time 
would be valuable, and to date, no CA has provided them. We had previously 
proposed that anything longer should require a mandatory public, unredacted 
incident report from the CA, and the concession to avoid such a requirement was 
to find a balance, while also ensuring that CAs were gathering and collecting 
concrete reports to provide that.

 

2.  Given the examples for unacceptable risk, I would assume that this item 
would have a deadline set in the BRs. We have done this before with 
non-registered domain name certificates. So if the certificate has not been 
revoked by the deadline, then it must be revoked immediately. As such, perhaps 
this requirement should be better defined and also moved to the 24 hour section.

3.  I do agree that the CA should work with both the Reporter and the 
Subscriber; however, please note that the investigation may mean that the 
certificate will not be revoked. Also, having a preliminary report within 24 
hours may not be feasible to have a report with substantial substance as there 
may not be time to discuss with the Subscriber. I do suggest that within 24 
hours the CA should advise the Reporter and the Subscriber that an 
investigation has started which may result in the certificate being revoked.

I don't think this is something we'd agree on. As noted above, our goal is to 
improve the transparency. There are some who've said that the best solution to 
these issues is to know what it's like by going to work for a CA. Absent 
changing employers, the next best thing is going to be to improve the 
transparency of the ecosystem, which will improve the trust overall. CAs are 
already required to conduct their activities within 24 hours - this doesn't 
relax that particular item, but allows them to make it available as a report, 
while offering greater flexibility. That seems a meaningful compromise to 
balance the need for transparency while providing CAs and Subscribers some 
degree of 

Re: [cabfpub] [Servercert-wg] [EXTERNAL]Re: Ballot SC6 - Revocation Timeline Extension

[Ryan Sleevi via Public]

This is where the reporting bit came in. Responses inline.

On Tue, Aug 21, 2018 at 2:19 PM Jeremy Rowley 
wrote:

> I’m surprised no one has given any examples yet. There are a lot of them
> if you go through the revocation requests:
>
>1. Certs reported on a long weekend where we can’t reach anyone at the
>organization. You’re looking at 4 days there in the US sometimes. Outside
>of the US there can be up to a week or so where response are difficult
>(especially in Europe and China)
>
> I think it's worth understanding why it's important/necessary to obtain
contact with the organization. Is it because you lack evidence, or to
provide notice? I think there's a significant difference between these two.


>
>1.
>2. See the Blizzard cert that we had to revoke. (Although this mixes
>investigation with revocation timelines)
>
> Right, I'm aware of what you're referencing, but I'm not sure I see how it
relates. Could you elaborate on what you see here? I thought the
investigation was fairly cut and dry.


>
>1.
>2. Sometimes we get requests for revocation through third parties
>alleging key compromise without proof. Takes a while for them to generate a
>CSR and send it over.
>
> Sure, but don't you think it's fair to say the CA hasn't obtained evidence
of revocation? And if the reporter disagrees with the CA's assessment
(about whether the evidence constitutes proof of compromise), they at least
have a response from the CA's investigation and determination that they can
then discuss, and understand publicly whether the CA's made a mistake in
that assessment, and how to improve the controls around that.


>
>1.
>2. Emails about cert misuse on sites that contain wares or similar
>items can take 7 days to figure out whether it is indeed  phishing or
>something similar.
>
> A solution there is don't revoke certs for content ;)


>
>1.
>
>
>
> I’d have to dig out the exact emails on each off these to send over, but 7
> days for investigation is pretty short unless we get a copy of the private
> key in the first go-around from the reporting entity.
>
>
>
>
>
> *From:* Public  *On Behalf Of *Ryan Sleevi
> via Public
> *Sent:* Tuesday, August 21, 2018 11:08 AM
> *To:* Bruce Morton ;
> servercert...@cabforum.org
> *Cc:* CABFPub 
> *Subject:* Re: [cabfpub] [Servercert-wg] [EXTERNAL]Re: Ballot SC6 -
> Revocation Timeline Extension
>
>
>
>
>
> On Tue, Aug 21, 2018 at 1:01 PM Bruce Morton via Servercert-wg <
> servercert...@cabforum.org> wrote:
>
> Per Mike’s items:
>
>
>
> 1.  7 days would be preferable as this would provide a “business
> week” for the CA to investigate the issue. It will also provide 2 extra
> days to have reach and discuss the issue with the Reporter and the
> Subscriber.
>
> As Mike summarized correctly, Google felt and feels that 7 days is too
> long. We repeatedly asked for specific examples and details of where the
> additional time would be valuable, and to date, no CA has provided them. We
> had previously proposed that anything longer should require a mandatory
> public, unredacted incident report from the CA, and the concession to avoid
> such a requirement was to find a balance, while also ensuring that CAs were
> gathering and collecting concrete reports to provide that.
>
>
>
> 2.  Given the examples for unacceptable risk, I would assume that
> this item would have a deadline set in the BRs. We have done this before
> with non-registered domain name certificates. So if the certificate has not
> been revoked by the deadline, then it must be revoked immediately. As such,
> perhaps this requirement should be better defined and also moved to the 24
> hour section.
>
> 3.  I do agree that the CA should work with both the Reporter and the
> Subscriber; however, please note that the investigation may mean that the
> certificate will not be revoked. Also, having a preliminary report within
> 24 hours may not be feasible to have a report with substantial substance as
> there may not be time to discuss with the Subscriber. I do suggest that
> within 24 hours the CA should advise the Reporter and the Subscriber that
> an investigation has started which may result in the certificate being
> revoked.
>
> I don't think this is something we'd agree on. As noted above, our goal is
> to improve the transparency. There are some who've said that the best
> solution to these issues is to know what it's like by going to work for a
> CA. Absent changing employers, the next best thing is going to be to
> improve the transparency of the ecosystem, which will improve the trust
> overall. CAs are already required to conduct t

Re: [cabfpub] [Servercert-wg] [EXTERNAL]Re: Ballot SC6 - Revocation Timeline Extension

[Tim Hollebeek via Public]

For #14, there is the case where some CAs were using revocations to terminate 
Free Trial certificates that weren’t paid for at the end of the free trial, but 
that was always a really really really really bad idea anyway.

 

I may not have used enough reallys.

 

For #15, you mean every large CA.  Down in the long tail of CAs, there are some 
CAs that appear to be blissfully ignorant of much of what goes on with the BRs.

 

-Tim

 

14. Revocation is required by the CA’s Certificate Policy and/or Certification 
Practice Statement; or 

- I don’t know of any CPS that goes beyond these requirements for TLS certs. 

 

15. The technical content or format of the Certificate presents an unacceptable 
risk to Application Software Suppliers or Relying Parties (e.g. the CA/Browser 
Forum might determine that a deprecated cryptographic/signature algorithm or 
key size presents an unacceptable risk and that such Certificates should be 
revoked and replaced by CAs within a given period of time).

- This one isn’t an issue either. By the time something passes with the BRs, 
every CA is well aware of the need to migrate. 

 

From: Ryan Sleevi mailto:sle...@google.com> > 
Sent: Tuesday, August 21, 2018 1:44 PM
To: Jeremy Rowley mailto:jeremy.row...@digicert.com> >
Cc: CABFPub mailto:public@cabforum.org> >; Bruce Morton 
mailto:bruce.mor...@entrustdatacard.com> >; 
servercert...@cabforum.org <mailto:servercert...@cabforum.org> 
Subject: Re: [cabfpub] [Servercert-wg] [EXTERNAL]Re: Ballot SC6 - Revocation 
Timeline Extension

 

This is where the reporting bit came in. Responses inline.

On Tue, Aug 21, 2018 at 2:19 PM Jeremy Rowley mailto:jeremy.row...@digicert.com> > wrote:

I’m surprised no one has given any examples yet. There are a lot of them if you 
go through the revocation requests:

1.  Certs reported on a long weekend where we can’t reach anyone at the 
organization. You’re looking at 4 days there in the US sometimes. Outside of 
the US there can be up to a week or so where response are difficult (especially 
in Europe and China)

I think it's worth understanding why it's important/necessary to obtain contact 
with the organization. Is it because you lack evidence, or to provide notice? I 
think there's a significant difference between these two.

 

1.   
2.  See the Blizzard cert that we had to revoke. (Although this mixes 
investigation with revocation timelines)

Right, I'm aware of what you're referencing, but I'm not sure I see how it 
relates. Could you elaborate on what you see here? I thought the investigation 
was fairly cut and dry.

 

1.   
2.  Sometimes we get requests for revocation through third parties alleging 
key compromise without proof. Takes a while for them to generate a CSR and send 
it over.

Sure, but don't you think it's fair to say the CA hasn't obtained evidence of 
revocation? And if the reporter disagrees with the CA's assessment (about 
whether the evidence constitutes proof of compromise), they at least have a 
response from the CA's investigation and determination that they can then 
discuss, and understand publicly whether the CA's made a mistake in that 
assessment, and how to improve the controls around that.

 

1.   
2.  Emails about cert misuse on sites that contain wares or similar items 
can take 7 days to figure out whether it is indeed  phishing or something 
similar.

A solution there is don't revoke certs for content ;)

 

1.   

 

I’d have to dig out the exact emails on each off these to send over, but 7 days 
for investigation is pretty short unless we get a copy of the private key in 
the first go-around from the reporting entity. 

 

 

From: Public mailto:public-boun...@cabforum.org> 
> On Behalf Of Ryan Sleevi via Public
Sent: Tuesday, August 21, 2018 11:08 AM
To: Bruce Morton mailto:bruce.mor...@entrustdatacard.com> >; servercert...@cabforum.org 
<mailto:servercert...@cabforum.org> 
Cc: CABFPub mailto:public@cabforum.org> >
Subject: Re: [cabfpub] [Servercert-wg] [EXTERNAL]Re: Ballot SC6 - Revocation 
Timeline Extension

 

 

On Tue, Aug 21, 2018 at 1:01 PM Bruce Morton via Servercert-wg 
mailto:servercert...@cabforum.org> > wrote:

Per Mike’s items:

 

1.  7 days would be preferable as this would provide a “business week” for 
the CA to investigate the issue. It will also provide 2 extra days to have 
reach and discuss the issue with the Reporter and the Subscriber.

As Mike summarized correctly, Google felt and feels that 7 days is too long. We 
repeatedly asked for specific examples and details of where the additional time 
would be valuable, and to date, no CA has provided them. We had previously 
proposed that anything longer should require a mandatory public, unredacted 
incident report from the CA, and the concession to avoid such a requirement was 
to find a balance, while also ensuring that CAs were gathering and collecting 
concrete report

Re: [cabfpub] [Servercert-wg] [EXTERNAL]Re: Ballot SC6 - Revocation Timeline Extension

[Jeremy Rowley via Public]

Lack of evidence sometimes, to provide notice others. Sometimes its getting 
ahold of the person requesting revocation for some reason. Here are the reasons 
and some of the things we’ve seen. Sometimes we can tell just by looking but a 
lot of allegations we get involve a more thorough investigation: 

 

1. The Subscriber requests in writing that the CA revoke the Certificate; 

- Need to contact the subscriber to confirm this was indeed requested. 
Sometimes these just come through a general alias so figuring out if it was the 
subscriber takes a bit of work. 

 

2. The Subscriber notifies the CA that the original certificate request was not 
authorized and does not retroactively grant authorization; 

-  Again, need to contact the subscriber to confirm. Especially if this was 
alleged somewhere on a website rather than the through the designated channels. 

 

3. The CA obtains evidence that the Subscriber’s Private Key corresponding to 
the Public Key in the Certificate suffered a Key Compromise or no longer 
complies with the requirements of Sections 6.1.5 and 6.1.6; 

- TBH, this one is the easiest to confirm as it requires evidence of the key 
compromise. Investigations on this one are doable in a shorter time period.

 

4. The CA obtains evidence that the Certificate was misused; 

- Misuse depends on the circumstances. Usually requires investigation about the 
use with the subscriber.

 

5. The CA is made aware that a Subscriber has violated one or more of its 
material obligations under the Subscriber Agreement or Terms of Use; 

- Again, requires investigation on what is actually being done. What section 
did they breach? Usually this involves legal on both sides and is a pain in the 
butt. It never concludes within 24 hours (or even 5 days).

 

6. The CA is made aware of any circumstance indicating that use of a 
Fully-Qualified Domain Name or IP address in the Certificate is no longer 
legally permitted (e.g. a court or arbitrator has revoked a Domain Name 
Registrant’s right to use the Domain Name, a relevant licensing or services 
agreement between the Domain Name Registrant and the Applicant has terminated, 
or the Domain Name Registrant has failed to renew the Domain Name); 

- Requires confirmation with the court/licensing service. If this is a 
registrar, expect a super long response time. 7 days would be a boon.

 

7. The CA is made aware that a Wildcard Certificate has been used to 
authenticate a fraudulently misleading subordinate Fully-Qualified Domain Name; 

- Requires involvement of the subscriber to see what happened.

 

8. The CA is made aware of a material change in the information contained in 
the Certificate; 

- We’re made aware of this a lot (change in name, address, etc). Usually it 
requires investigation with a government entity or with the company itself.

 

9. The CA is made aware that the Certificate was not issued in accordance with 
these Requirements or the CA’s Certificate Policy or Certification Practice 
Statement; 

- Often straight-forward but sometimes it can involve a good deal of 
investigation into logs. This one usually doesn’t take us more than a couple of 
hours though.

 

10. The CA determines that any of the information appearing in the Certificate 
is inaccurate or misleading; 

- This is hard one to determine sometimes but it doesn’t often involve the 
customer.

 

11. The CA ceases operations for any reason and has not made arrangements for 
another CA to provide revocation support for the Certificate;

- Never see this happen

 

12. The CA’s right to issue Certificates under these Requirements expires or is 
revoked or terminated, unless the CA has made arrangements to continue 
maintaining the CRL/OCSP Repository; 

- Sort of happened with Symantec. However they made arrangements to continue 
maintaining the repository.

 

13. The CA is made aware of a possible compromise of the Private Key of the 
Subordinate CA used for issuing the Certificate; 

- This hasn’t happened in my experience

 

14. Revocation is required by the CA’s Certificate Policy and/or Certification 
Practice Statement; or 

- I don’t know of any CPS that goes beyond these requirements for TLS certs. 

 

15. The technical content or format of the Certificate presents an unacceptable 
risk to Application Software Suppliers or Relying Parties (e.g. the CA/Browser 
Forum might determine that a deprecated cryptographic/signature algorithm or 
key size presents an unacceptable risk and that such Certificates should be 
revoked and replaced by CAs within a given period of time).

- This one isn’t an issue either. By the time something passes with the BRs, 
every CA is well aware of the need to migrate. 

 

From: Ryan Sleevi  
Sent: Tuesday, August 21, 2018 1:44 PM
To: Jeremy Rowley 
Cc: CABFPub ; Bruce Morton 
; servercert...@cabforum.org
Subject: Re: [cabfpub] [Servercert-wg] [EXTERNAL]Re: Ballot SC6 - Revocation 
Timeline Extension

 

This is where the reporting

Re: [cabfpub] [Servercert-wg] [EXTERNAL]Re: Ballot SC6 - Revocation Timeline Extension

[Wayne Thayer via Public]

Thanks for the comments Mike. Based on the discussion, I would propose two
changes:

1. Regarding your second point about "The technical content or format of
the Certificate presents an unacceptable risk", my interpretation of the
language in the context of the section is that the "given period of time"
must be no more than 5 days, which doesn't make a lot of sense. Bruce's
interpretation seems more reasonable but not what the current wording
really means.  If this language only comes into effect after a deadline is
set, as implied by the example, then any requirement to revoke can be
stipulated by whomever set the deadline (root program or CAB Forum ballot).
It follows that this reason for revocation (in both the Subscriber and
Subordinate CA sections) is unnecessary and can be removed.

2. Regarding the third point, add the Subscriber in addition to the "entity
reporting the Certificate Problem Report" as someone to consult when
deciding when to revoke the certificate. I think the other clarifications
you suggested are already covered.

Here are the changes I've captured from the discussion to-date:

https://github.com/wthayer/documents/commit/2d427a74f604d635609602bed2808e5d96ee03ad

I'll publish a 'version 2' of the ballot when it appears that there are no
further concerns.

- Wayne


On Tue, Aug 21, 2018 at 10:08 AM Ryan Sleevi  wrote:

>
>
> On Tue, Aug 21, 2018 at 1:01 PM Bruce Morton via Servercert-wg <
> servercert...@cabforum.org> wrote:
>
>> Per Mike’s items:
>>
>>
>>
>> 1.  7 days would be preferable as this would provide a “business
>> week” for the CA to investigate the issue. It will also provide 2 extra
>> days to have reach and discuss the issue with the Reporter and the
>> Subscriber.
>>
> As Mike summarized correctly, Google felt and feels that 7 days is too
> long. We repeatedly asked for specific examples and details of where the
> additional time would be valuable, and to date, no CA has provided them. We
> had previously proposed that anything longer should require a mandatory
> public, unredacted incident report from the CA, and the concession to avoid
> such a requirement was to find a balance, while also ensuring that CAs were
> gathering and collecting concrete reports to provide that.
>
>
>> 2.  Given the examples for unacceptable risk, I would assume that
>> this item would have a deadline set in the BRs. We have done this before
>> with non-registered domain name certificates. So if the certificate has not
>> been revoked by the deadline, then it must be revoked immediately. As such,
>> perhaps this requirement should be better defined and also moved to the 24
>> hour section.
>>
>> 3.  I do agree that the CA should work with both the Reporter and
>> the Subscriber; however, please note that the investigation may mean that
>> the certificate will not be revoked. Also, having a preliminary report
>> within 24 hours may not be feasible to have a report with substantial
>> substance as there may not be time to discuss with the Subscriber. I do
>> suggest that within 24 hours the CA should advise the Reporter and the
>> Subscriber that an investigation has started which may result in the
>> certificate being revoked.
>>
> I don't think this is something we'd agree on. As noted above, our goal is
> to improve the transparency. There are some who've said that the best
> solution to these issues is to know what it's like by going to work for a
> CA. Absent changing employers, the next best thing is going to be to
> improve the transparency of the ecosystem, which will improve the trust
> overall. CAs are already required to conduct their activities within 24
> hours - this doesn't relax that particular item, but allows them to make it
> available as a report, while offering greater flexibility. That seems a
> meaningful compromise to balance the need for transparency while providing
> CAs and Subscribers some degree of flexibility.
>
>
>
>>
>>
>> Thanks, Bruce.
>>
>>
>>
>> *From:* Servercert-wg [mailto:servercert-wg-boun...@cabforum.org] *On
>> Behalf Of *Mike Reilly (GRC) via Servercert-wg
>> *Sent:* August 21, 2018 12:17 PM
>> *To:* Doug Beattie ; CA/B Forum Server
>> Certificate WG Public Discussion List ; Tim
>> Hollebeek ; Wayne Thayer > >
>> *Cc:* CA/Browser Forum Public Discussion List 
>> *Subject:* [EXTERNAL]Re: [Servercert-wg] [cabfpub] Ballot SC6 -
>> Revocation Timeline Extension
>>
>>
>>
>> Hi all.  Some areas of clarification requested from the Microsoft team:
>>
>>
>>
>>- I don’t remember why 5 days was chosen vs. 7 or 3 days.  I believe
>>it was we felt 7 days was too long but 5 days was reasonable.  I believe 
>> we
>>also considered the scenario where an incident occurs on a Friday evening
>>of a three day weekend and the difficulty of the CA dealing with a
>>subscriber who may be unavailable over a weekend for a non-urgent
>>revocation requirement.  5 days covered that scenario without being too 
>> far
>>past 24 hours.  3 

Re: [cabfpub] [Servercert-wg] [EXTERNAL]Re: Ballot SC6 - Revocation Timeline Extension

[Jeremy Rowley via Public]

I’m surprised no one has given any examples yet. There are a lot of them if you 
go through the revocation requests:

1.  Certs reported on a long weekend where we can’t reach anyone at the 
organization. You’re looking at 4 days there in the US sometimes. Outside of 
the US there can be up to a week or so where response are difficult (especially 
in Europe and China)
2.  See the Blizzard cert that we had to revoke. (Although this mixes 
investigation with revocation timelines)
3.  Sometimes we get requests for revocation through third parties alleging 
key compromise without proof. Takes a while for them to generate a CSR and send 
it over.
4.  Emails about cert misuse on sites that contain wares or similar items 
can take 7 days to figure out whether it is indeed  phishing or something 
similar. 

 

I’d have to dig out the exact emails on each off these to send over, but 7 days 
for investigation is pretty short unless we get a copy of the private key in 
the first go-around from the reporting entity. 

 

 

From: Public  On Behalf Of Ryan Sleevi via Public
Sent: Tuesday, August 21, 2018 11:08 AM
To: Bruce Morton ; servercert...@cabforum.org
Cc: CABFPub 
Subject: Re: [cabfpub] [Servercert-wg] [EXTERNAL]Re: Ballot SC6 - Revocation 
Timeline Extension

 

 

On Tue, Aug 21, 2018 at 1:01 PM Bruce Morton via Servercert-wg 
mailto:servercert...@cabforum.org> > wrote:

Per Mike’s items:

 

1.  7 days would be preferable as this would provide a “business week” for 
the CA to investigate the issue. It will also provide 2 extra days to have 
reach and discuss the issue with the Reporter and the Subscriber.

As Mike summarized correctly, Google felt and feels that 7 days is too long. We 
repeatedly asked for specific examples and details of where the additional time 
would be valuable, and to date, no CA has provided them. We had previously 
proposed that anything longer should require a mandatory public, unredacted 
incident report from the CA, and the concession to avoid such a requirement was 
to find a balance, while also ensuring that CAs were gathering and collecting 
concrete reports to provide that.

 

2.  Given the examples for unacceptable risk, I would assume that this item 
would have a deadline set in the BRs. We have done this before with 
non-registered domain name certificates. So if the certificate has not been 
revoked by the deadline, then it must be revoked immediately. As such, perhaps 
this requirement should be better defined and also moved to the 24 hour section.

3.  I do agree that the CA should work with both the Reporter and the 
Subscriber; however, please note that the investigation may mean that the 
certificate will not be revoked. Also, having a preliminary report within 24 
hours may not be feasible to have a report with substantial substance as there 
may not be time to discuss with the Subscriber. I do suggest that within 24 
hours the CA should advise the Reporter and the Subscriber that an 
investigation has started which may result in the certificate being revoked.

I don't think this is something we'd agree on. As noted above, our goal is to 
improve the transparency. There are some who've said that the best solution to 
these issues is to know what it's like by going to work for a CA. Absent 
changing employers, the next best thing is going to be to improve the 
transparency of the ecosystem, which will improve the trust overall. CAs are 
already required to conduct their activities within 24 hours - this doesn't 
relax that particular item, but allows them to make it available as a report, 
while offering greater flexibility. That seems a meaningful compromise to 
balance the need for transparency while providing CAs and Subscribers some 
degree of flexibility.

 

 

 

Thanks, Bruce.

 

From: Servercert-wg [mailto:servercert-wg-boun...@cabforum.org 
<mailto:servercert-wg-boun...@cabforum.org> ] On Behalf Of Mike Reilly (GRC) 
via Servercert-wg
Sent: August 21, 2018 12:17 PM
To: Doug Beattie mailto:doug.beat...@globalsign.com> >; CA/B Forum Server Certificate WG Public 
Discussion List mailto:servercert...@cabforum.org> 
>; Tim Hollebeek mailto:tim.holleb...@digicert.com> >; Wayne Thayer mailto:wtha...@mozilla.com> >
Cc: CA/Browser Forum Public Discussion List mailto:public@cabforum.org> >
Subject: [EXTERNAL]Re: [Servercert-wg] [cabfpub] Ballot SC6 - Revocation 
Timeline Extension

 

Hi all.  Some areas of clarification requested from the Microsoft team:

 

*   I don’t remember why 5 days was chosen vs. 7 or 3 days.  I believe it 
was we felt 7 days was too long but 5 days was reasonable.  I believe we also 
considered the scenario where an incident occurs on a Friday evening of a three 
day weekend and the difficulty of the CA dealing with a subscriber who may be 
unavailable over a weekend for a non-urgent revocation requirement.  5 days 
covered that scenario without being too far past 2

Re: [cabfpub] [Servercert-wg] [EXTERNAL]Re: Ballot SC6 - Revocation Timeline Extension

[Ryan Sleevi via Public]

On Tue, Aug 21, 2018 at 1:01 PM Bruce Morton via Servercert-wg <
servercert...@cabforum.org> wrote:

> Per Mike’s items:
>
>
>
> 1.  7 days would be preferable as this would provide a “business
> week” for the CA to investigate the issue. It will also provide 2 extra
> days to have reach and discuss the issue with the Reporter and the
> Subscriber.
>
As Mike summarized correctly, Google felt and feels that 7 days is too
long. We repeatedly asked for specific examples and details of where the
additional time would be valuable, and to date, no CA has provided them. We
had previously proposed that anything longer should require a mandatory
public, unredacted incident report from the CA, and the concession to avoid
such a requirement was to find a balance, while also ensuring that CAs were
gathering and collecting concrete reports to provide that.


> 2.  Given the examples for unacceptable risk, I would assume that
> this item would have a deadline set in the BRs. We have done this before
> with non-registered domain name certificates. So if the certificate has not
> been revoked by the deadline, then it must be revoked immediately. As such,
> perhaps this requirement should be better defined and also moved to the 24
> hour section.
>
> 3.  I do agree that the CA should work with both the Reporter and the
> Subscriber; however, please note that the investigation may mean that the
> certificate will not be revoked. Also, having a preliminary report within
> 24 hours may not be feasible to have a report with substantial substance as
> there may not be time to discuss with the Subscriber. I do suggest that
> within 24 hours the CA should advise the Reporter and the Subscriber that
> an investigation has started which may result in the certificate being
> revoked.
>
I don't think this is something we'd agree on. As noted above, our goal is
to improve the transparency. There are some who've said that the best
solution to these issues is to know what it's like by going to work for a
CA. Absent changing employers, the next best thing is going to be to
improve the transparency of the ecosystem, which will improve the trust
overall. CAs are already required to conduct their activities within 24
hours - this doesn't relax that particular item, but allows them to make it
available as a report, while offering greater flexibility. That seems a
meaningful compromise to balance the need for transparency while providing
CAs and Subscribers some degree of flexibility.



>
>
> Thanks, Bruce.
>
>
>
> *From:* Servercert-wg [mailto:servercert-wg-boun...@cabforum.org] *On
> Behalf Of *Mike Reilly (GRC) via Servercert-wg
> *Sent:* August 21, 2018 12:17 PM
> *To:* Doug Beattie ; CA/B Forum Server
> Certificate WG Public Discussion List ; Tim
> Hollebeek ; Wayne Thayer 
> *Cc:* CA/Browser Forum Public Discussion List 
> *Subject:* [EXTERNAL]Re: [Servercert-wg] [cabfpub] Ballot SC6 -
> Revocation Timeline Extension
>
>
>
> Hi all.  Some areas of clarification requested from the Microsoft team:
>
>
>
>- I don’t remember why 5 days was chosen vs. 7 or 3 days.  I believe
>it was we felt 7 days was too long but 5 days was reasonable.  I believe we
>also considered the scenario where an incident occurs on a Friday evening
>of a three day weekend and the difficulty of the CA dealing with a
>subscriber who may be unavailable over a weekend for a non-urgent
>revocation requirement.  5 days covered that scenario without being too far
>past 24 hours.  3 days was felt to be too short and 7 days seemed too
>long.  Correct?
>- Regarding point 11. Will this "given period of time" means up to 5
>days as well?  Point 11 reads: *“The technical content or format of
>the Certificate presents an unacceptable risk to Application Software
>Suppliers or Relying Parties (e.g. the CA/Browser Forum might determine
>that a deprecated cryptographic/signature algorithm or key size presents an
>unacceptable risk and that such Certificates should be revoked and replaced
>by CAs within a given period of time)”*
>- There is also a bit of confusion about the following statement as it
>is still governed by the 5 day requirement so we’re not sure why it’s
>called out this way.  *“Within 24 hours of receiving a problem report,
>the CA is now required to report back to both the entity reporting the
>problem and the Subscriber on the CA's findings, and to work with the
>reporter to establish a date by which the CA will revoke the certificate.”*
> Should this be clarified to include both the reporter and the Subscriber
>included in both steps to reduce potential impact to relying parties.
>Perhaps add more clarification in this statement:
>   - Report back the findings to reporter and the Subscriber within 24
>   hours
>   - Work with the reporter and the Subscriber to revoke within 5 days
>
>
>
> Thanks, Mike
>
>
>
> *From:* Servercert-wg  *On Behalf Of