Bugzilla

Trev,

I don’t want this to seem personally targeting, either individually or as if I have a bone to pick with Amazon. However, this incident report seems vastly inconsistent with the level of transparency and detail, both of that expected on incident reports and in terms of what Amazon has demonstrated it is capable of for other industries.

I’m going to point out a few examples in Comment #19, because I am hoping this is just a temporary oversight, and not representative of a pattern for Amazon Trust Services, despite the growing evidence that it unfortunately is.

You refer to your internal review as being part of the conclusion, but share zero technical details here. This review has been ongoing for three months, and it is not unreasonable to expect a report with details commiserate with the policy team working full time on this issue for months. If this wasn’t a full time affair, which is at least the baseline expectation when delaying, then I think the past updates were misleading the community about this, which is why I flagged Comment #17.

It also appears that these details were and are a contributing factor to Amazon intentionally and knowingly continuing to violate states policy. If the risk is so great, then it benefits both CAs and users to articulate precisely what you determined, to be aware of and consider the risk. Details, not conclusions, help inform CAs and help the community validate that the conclusion is supported by accurate and actionable data. It would mostly seem like you discovered that Comment #1’s recommendation three months ago was a good recommendation, but that it took you three months ago to confirm that.

The timing for the revocation itself is concerning. It sounds like Amazon Trust Services is not capable of, nor prepared for, complying with the Baseline Certificates when it comes to misissued certificates. The plan, as best I can tell, is to let everything issued naturally expire, rather than automatically rotate and replace the certificates. If Amazon looks through countless CA incidents through the past decade, it would be clear that when CAs are misissued, CAs get revoked, and those can invalidate the extant certificates. This is why CAs have been encouraged to automate their issuance, combined with shorter lifetimes, and to continue to invest in ways to further respond (e.g. ARI). Based on the proposed action, and with the complete dearth of meaningful detail, it would seem that Amazon has completely failed to prepare to meet industry baselines or be aware of other CAs’ incidents and lessons. My hope is that this is not the case, but this is where and why being detailed and clear in the reports helps avoid that appearance.

While I am sympathetic to the argument that “we didn’t misissue the leaves, and we didn’t ‘intend’ for this intermediate to be the one for issuance,” the basic reality that all CAs are expected to be prepared for is change, so that whether the next Heartbleed or the next DigiNotar, replacing certs is so boring and routine that it doesn’t even merit angst. I would hope Amazon would at least hold itself internally to the standard set by CAs like GlobalSign, DigiCert, Entrust, and others, in terms of recognize that when intermediates need to get replaced, they are done so in a timely fashion. If others can and have done it, why can’t and doesn’t ATS, and what does that say about the state of operations and implementation?

As to the actual timelines, in the absence of data, they seem to demonstrate either no awareness of the requirements or no respect for the community of users that rely on CAs. Amazon is stating that it takes it two and a half years to stop issuing, when the expectation is that CAs should be prepared closer to the order of 2.5 minutes to 2.5 days. If there is some data that justifies this, then it’s essential to share, which Amazon has not.

In the event this feels like a “bring me a rock” by listing everything wrong with this report, a more constructive question/goal:

What would it take to have this certificate revoked within the next 30 days, which is still 18x longer then the time permitted by the BRs? This would mean transitioning new issuance to a new intermediate, as well as replacing certificates to minimize path building issues.

Trev,

I don’t want this to seem personally targeting, either individually or as if I have a bone to pick with Amazon. However, this incident report seems vastly inconsistent with the level of transparency and detail, both of that expected on incident reports and in terms of what Amazon has demonstrated it is capable of for other industries.

I’m going to point out a few examples in Comment #19, because I am hoping this is just a temporary oversight, and not representative of a pattern for Amazon Trust Services, despite the growing evidence that it unfortunately is.

You refer to your internal review as being part of the conclusion, but share zero technical details here. This review has been ongoing for three months, and it is not unreasonable to expect a report with details commiserate with the policy team working full time on this issue for months. If this wasn’t a full time affair, which is at least the baseline expectation when delaying, then I think the past updates were misleading the community about this, which is why I flagged Comment #17.

It also appears that these details were and are a contributing factor to Amazon intentionally and knowingly continuing to violate states policy. If the risk is so great, then it benefits both CAs and users to articulate precisely what you determined, to be aware of and consider the risk. Details, not conclusions, help inform CAs and help the community validate that the conclusion is supported by accurate and actionable data. It would mostly seem like you discovered that Comment #1’s recommendation three months ago was a good recommendation, but that it took you three months to confirm that.

The timing for the revocation itself is concerning. It sounds like Amazon Trust Services is not capable of, nor prepared for, complying with the Baseline Requirements when it comes to misissued certificates. The plan, as best I can tell, is to let everything issued naturally expire, rather than automatically rotate and replace the certificates. If Amazon looks through countless CA incidents through the past decade, it would be clear that when CAs are misissued, CAs get revoked, and those can invalidate the extant certificates. This is why CAs have been encouraged to automate their issuance, combined with shorter lifetimes, and to continue to invest in ways to further respond (e.g. ARI). Based on the proposed action, and with the complete dearth of meaningful detail, it would seem that Amazon has completely failed to prepare to meet industry baselines or be aware of other CAs’ incidents and lessons. My hope is that this is not the case, but this is where and why being detailed and clear in the reports helps avoid that appearance.

While I am sympathetic to the argument that “we didn’t misissue the leaves, and we didn’t ‘intend’ for this intermediate to be the one for issuance,” the basic reality that all CAs are expected to be prepared for is change, so that whether the next Heartbleed or the next DigiNotar, replacing certs is so boring and routine that it doesn’t even merit angst. I would hope Amazon would at least hold itself internally to the standard set by CAs like GlobalSign, DigiCert, Entrust, and others, in terms of recognize that when intermediates need to get replaced, they are done so in a timely fashion. If others can and have done it, why can’t and doesn’t ATS, and what does that say about the state of operations and implementation?

As to the actual timelines, in the absence of data, they seem to demonstrate either no awareness of the requirements or no respect for the community of users that rely on CAs. Amazon is stating that it takes it two and a half years to stop issuing, when the expectation is that CAs should be prepared closer to the order of 2.5 minutes to 2.5 days. If there is some data that justifies this, then it’s essential to share, which Amazon has not.

In the event this feels like a “bring me a rock” by listing everything wrong with this report, a more constructive question/goal:

What would it take to have this certificate revoked within the next 30 days, which is still 18x longer then the time permitted by the BRs? This would mean transitioning new issuance to a new intermediate, as well as replacing certificates to minimize path building issues.

Trev,

I don’t want this to seem personally targeting, either individually or as if I have a bone to pick with Amazon. However, this incident report seems vastly inconsistent with the level of transparency and detail, both of that expected on incident reports and in terms of what Amazon has demonstrated it is capable of for other industries.

I’m going to point out a few examples in Comment #19, because I am hoping this is just a temporary oversight, and not representative of a pattern for Amazon Trust Services, despite the growing evidence that it unfortunately is.

You refer to your internal review as being part of the conclusion, but share zero technical details here. This review has been ongoing for three months, and it is not unreasonable to expect a report with details commiserate with the policy team working full time on this issue for months. If this wasn’t a full time affair, which is at least the baseline expectation when delaying, then I think the past updates were misleading the community about this, which is why I flagged Comment #17.

It also appears that these details were and are a contributing factor to Amazon intentionally and knowingly continuing to violate stated policy. If the risk is so great, then it benefits both CAs and users to articulate precisely what you determined, to be aware of and consider the risk. Details, not conclusions, help inform CAs and help the community validate that the conclusion is supported by accurate and actionable data. It would mostly seem like you discovered that Comment #1’s recommendation three months ago was a good recommendation, but that it took you three months to confirm that.

The timing for the revocation itself is concerning. It sounds like Amazon Trust Services is not capable of, nor prepared for, complying with the Baseline Requirements when it comes to misissued certificates. The plan, as best I can tell, is to let everything issued naturally expire, rather than automatically rotate and replace the certificates. If Amazon looks through countless CA incidents through the past decade, it would be clear that when CAs are misissued, CAs get revoked, and those can invalidate the extant certificates. This is why CAs have been encouraged to automate their issuance, combined with shorter lifetimes, and to continue to invest in ways to further respond (e.g. ARI). Based on the proposed action, and with the complete dearth of meaningful detail, it would seem that Amazon has completely failed to prepare to meet industry baselines or be aware of other CAs’ incidents and lessons. My hope is that this is not the case, but this is where and why being detailed and clear in the reports helps avoid that appearance.

While I am sympathetic to the argument that “we didn’t misissue the leaves, and we didn’t ‘intend’ for this intermediate to be the one for issuance,” the basic reality that all CAs are expected to be prepared for is change, so that whether the next Heartbleed or the next DigiNotar, replacing certs is so boring and routine that it doesn’t even merit angst. I would hope Amazon would at least hold itself internally to the standard set by CAs like GlobalSign, DigiCert, Entrust, and others, in terms of recognize that when intermediates need to get replaced, they are done so in a timely fashion. If others can and have done it, why can’t and doesn’t ATS, and what does that say about the state of operations and implementation?

As to the actual timelines, in the absence of data, they seem to demonstrate either no awareness of the requirements or no respect for the community of users that rely on CAs. Amazon is stating that it takes it two and a half years to stop issuing, when the expectation is that CAs should be prepared closer to the order of 2.5 minutes to 2.5 days. If there is some data that justifies this, then it’s essential to share, which Amazon has not.

In the event this feels like a “bring me a rock” by listing everything wrong with this report, a more constructive question/goal:

What would it take to have this certificate revoked within the next 30 days, which is still 18x longer then the time permitted by the BRs? This would mean transitioning new issuance to a new intermediate, as well as replacing certificates to minimize path building issues.

Trev,

I don’t want this to seem personally targeting, either individually or as if I have a bone to pick with Amazon. However, this incident report seems vastly inconsistent with the level of transparency and detail, both of that expected on incident reports and in terms of what Amazon has demonstrated it is capable of for other industries.

I’m going to point out a few examples in Comment #19, because I am hoping this is just a temporary oversight, and not representative of a pattern for Amazon Trust Services, despite the growing evidence that it unfortunately is.

You refer to your internal review as being part of the conclusion, but share zero technical details here. This review has been ongoing for three months, and it is not unreasonable to expect a report with details commiserate with the policy team working full time on this issue for months. If this wasn’t a full time affair, which is at least the baseline expectation when delaying, then I think the past updates were misleading the community about this, which is why I flagged Comment #17.

It also appears that these details were and are a contributing factor to Amazon intentionally and knowingly continuing to violate stated policy. If the risk is so great, then it benefits both CAs and users to articulate precisely what you determined, to be aware of and consider the risk. Details, not conclusions, help inform CAs and help the community validate that the conclusion is supported by accurate and actionable data. It would mostly seem like you discovered that Comment #1’s recommendation three months ago was a good recommendation, but that it took you three months to confirm that.

The timing for the revocation itself is concerning. It sounds like Amazon Trust Services is not capable of, nor prepared for, complying with the Baseline Requirements when it comes to misissued certificates. The plan, as best I can tell, is to let everything issued naturally expire, rather than automatically rotate and replace the certificates. If Amazon looks through countless CA incidents through the past decade, it would be clear that when CAs are misissued, CAs get revoked, and those can invalidate the extant certificates. This is why CAs have been encouraged to automate their issuance, combined with shorter lifetimes, and to continue to invest in ways to further respond (e.g. ARI). Based on the proposed action, and with the complete dearth of meaningful detail, it would seem that Amazon has completely failed to prepare to meet industry baselines or be aware of other CAs’ incidents and lessons. My hope is that this is not the case, but this is where and why being detailed and clear in the reports helps avoid that appearance.

While I am sympathetic to the argument that “we didn’t misissue the leaves, and we didn’t ‘intend’ for this intermediate to be the one for issuance,” the basic reality that all CAs are expected to be prepared for is change, so that whether the next Heartbleed or the next DigiNotar, replacing certs is so boring and routine that it doesn’t even merit angst. I would hope Amazon would at least hold itself internally to the standard set by CAs like GlobalSign, DigiCert, Entrust, and others, in terms of recognizing that when intermediates need to get replaced, they are done so in a timely fashion. If others can and have done it, why can’t and doesn’t ATS, and what does that say about the state of operations and implementation?

As to the actual timelines, in the absence of data, they seem to demonstrate either no awareness of the requirements or no respect for the community of users that rely on CAs. Amazon is stating that it takes it two and a half years to stop issuing, when the expectation is that CAs should be prepared closer to the order of 2.5 minutes to 2.5 days. If there is some data that justifies this, then it’s essential to share, which Amazon has not.

In the event this feels like a “bring me a rock” by listing everything wrong with this report, a more constructive question/goal:

What would it take to have this certificate revoked within the next 30 days, which is still 18x longer then the time permitted by the BRs? This would mean transitioning new issuance to a new intermediate, as well as replacing certificates to minimize path building issues.