Re: [Jmap] Benjamin Kaduk's Discuss on draft-ietf-jmap-core-14: (with DISCUSS and COMMENT)

[Benjamin Kaduk <[e-mail]>]

On Sun, Mar 03, 2019 at 10:11:07PM -0500, Neil Jenkins wrote:
> On Mon, 4 Mar 2019, at 14:02, Benjamin Kaduk wrote:
> > > > > > Also, when these expirations fire (e.g., for Basic Authentication
> > > > > > credentials), we need a normative requirement to actually destroy the
> > > > > > private credentials; there's a lot going on here so maybe I missed it,
> > > > > > but I don't think I saw one.
> > > > > 
> > > > > I think we already have this. The spec says:
> > > > > 
> > > > > *The push subscription is tied to the credentials used to authenticate the API request that created it. Should these credentials expire or be revoked, the push subscription MUST be destroyed by the JMAP server.*
> > > > > 
> > > > > Or were you referring to something else?
> > > > 
> > > > I was thinking that you need to clear out the memory/disk storage that hold
> > > > the credentials (e.g., password), as well as destroying the subscription
> > > > object. We don't want plaintext credentials floating around longer than
> > > > needed.
> > > 
> > > Which credentials are you referring to here? The push subscription doesn't contain any except I guess for the URL itself; I can note that this and the encryption keys MUST be securely erased from memory/storage immediately when the subscription is destroyed? If you're referring to the client's credentials, we're explicitly talking about when they've been expired or revoked, so are already useless.
> > 
> > I may have been confused about whether this was JMAP Client/JMAP Server or
> > JMAP Server/push server interactions. That is, I was thinking about the
> > JMAP server clearing out any keys or credentials it had for the second sort
> > of interaction.
> 
> OK, so yes this translates to clearing out the URL and any client-generated encryption keys. I have added:
> 
> *When a push subscription is destroyed, the server MUST securely erase the URL and encryption keys from memory and storage as soon as possible.*

Cool; thanks!