The language being used in this discussion so far does not seem to reflect the actual text of the BRs. A CA is currently under no obligation to "notify" the subscriber prior to revocation. Rather, a CA is under obligation to "work with the Subscriber... to establish whether or not the certificate will be revoked".
In many cases, no back and forth is required to satisfy that requirement. For example, if a Subscriber uses the ACME API to request revocation of their own certificate, then that request can reasonably be seen to satisfy all obligations to "work with" the Subscriber and the certificate can be revoked immediately. As another example, if a Subscriber Agreement says something to the effect of "The Subscriber acknowledges and accepts that, if any party notifies the CA that your certificate is invalid or compromised, the CA will determine at its sole discretion whether to revoke your certificate", then when a key compromise is demonstrated, the CA has already satisfied its "work with" obligation and may revoke the certificate immediately. Thus any reading of "work with" as being equivalent to "notify ahead of time" is a meaningful (and ahistorical) semantic change in the reading of that requirement, and collection of contact information is not necessary to satisfy the current requirement. Aaron On Tuesday, December 7, 2021 at 5:02:55 PM UTC-8 Matt Palmer wrote: > On Tue, Dec 07, 2021 at 07:56:46PM +0000, Corey Bonnell wrote: > > Hi Matt, > > > > > My reading of that specific requirement is that the subscriber > agreement > > > must contain that stipulation, and *if* a subscriber receives an > > > instruction and fails to respond to it, they are in breach of the > > > agreement. I don't read it as requiring the CA to issue instructions in > > > any particular circumstance. > > > > BR section 4.9.5 has specific obligations for the CA to notify the > > Subscriber of pending revocations due to Key Compromise, etc. > > I think you can reasonably read 4.9.5 even broader than that, since it > requires communication with the subscriber *any* time a Certificate Problem > Report is received. > > > BR 9.6.3 (7) provides assurance that the Subscriber will respond to such > > communications to ensure timely replacement of certificates. > > Hmm, I don't think 9.6.3(7) is *quite* that specific (as it merely says > that > subscriber must "respond to the CA's instructions", rather than talking > about timely replacement of certificates specifically) but it's not germane > to the point at hand, so I don't see a need to debate the point > extensively. > > > However, if the CA does not collect any Subscriber contact information, > > then the CA cannot execute on its obligations to notify the Subscriber. > > Agreed. > > > In turn, if > > such communication from the CA cannot be sent to the Subscriber due to > > lack of contact information, then it follows that the Subscriber will not > > be able to fulfill their obligation for 9.6.3 (7). > > This is where I'm still getting stuck. I can't see how a subscriber's > obligation to respond is relevant until they've received instructions from > the CA. If we agree that I have to give you $20 cash each time we see each > other, and I then go hide in a cave where you can't find me, I don't ever > need to have $20 in my pocket. > > > Therefore, I believe it is incumbent that CAs collect information for at > > least one method of contact so that both the CA-to-Subscriber > notification > > obligation and the Subscriber's obligation to respond to the CA can be > > fulfilled. > > I agree that 4.9.5 requires a CA to collect and maintain contact > information > for subscribers so they can fulfill their obligations. I'm still not seeing > how 9.6.3 (7) requires the CA to do same, though -- it's too much of a > stretch for my ageing joints. > > - Matt > > -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/a6d6fc05-105a-4032-ae3f-9de2a22a4ea9n%40mozilla.org.
