RE: [lamps] Last Call: <draft-ietf-lamps-hash-of-root-key-cert-extn-02.txt> (Hash Of Root Key Certificate Extension) to Informational RFC

[Tim Hollebeek <[e-mail]>]

I'm not sure the comparison with pins is that useful, because existing pins
generally work out badly because they prevent changing keys, while this
mechanism provides the opportunity to change a key, where no such
opportunity otherwise exists.  If anything, this makes roots of trust _less_
like pinned keys, and in a good way.

But I agree that even if this is a minor issue, perhaps a few sentences
noting it is appropriate.  Just to help out anyone who might not have
thought about it.

-Tim

> -----Original Message-----
> From: Stephen Farrell <[e-mail]>
> Sent: Wednesday, January 2, 2019 4:20 PM
> To: Tim Hollebeek <[e-mail]>; Salz, Rich
> <[e-mail]>; Paul Hoffman <[e-mail]>; Russ
> Housley <[e-mail]>
> Cc: [e-mail]; [e-mail];
> IETF <[e-mail]>
> Subject: Re: [lamps] Last Call: 
> <draft-ietf-lamps-hash-of-root-key-cert-extn-
> 02.txt> (Hash Of Root Key Certificate Extension) to Informational RFC
>
>
> Hiya,
>
> On 02/01/2019 20:57, Tim Hollebeek wrote:
> > I'm sympathetic to perhaps adding a sentence or two, but otherwise I'm
> > struggling to understand the risk as well.
>
> I assume Paul's pointing out that this is another form of key pinning, and
> other instances of pinning haven't worked out so well.
>
> > If an entity is incapable of managing and protecting a replacement
> > root key, perhaps they shouldn't be in the CA business.  And since, at
> > worst, they lose the ability to replace the root key, they aren't in a
> > worse situation than they were if this capability didn't exist.
>
> IIUC Paul's concern is for the relying party, not the CA.
>
> Compared to RPs who do not support this extension, RPs who do support this
> extension may have a harder time with a CA that mucks up pinning, e.g.
> because the CA's HSM vendor has gone out of business or something.
>
> I'm not sure how big a deal that is really but it seems like a fine LC 
> comment
> worthy of resolution to me.
>
> Having just read the draft (for the 1st time), I think it ought say (by 
> inclusion
> or reference) how RPs could handle bad pins, given that there are a small 
> set
> of trust store distributors (browsers, debian etc.) who aren't quite sync'd 
> up.
>
> Cheers,
> S.
>
>
> >
> > -Tim
> >
> >> -----Original Message-----
> >> From: Spasm <[e-mail]> On Behalf Of Salz, Rich
> >> Sent: Wednesday, January 2, 2019 3:32 PM
> >> To: Paul Hoffman <[e-mail]>; Russ Housley
> >> <[e-mail]>
> >> Cc: [e-mail];
> >> [e-mail];
> > IETF
> >> <[e-mail]>
> >> Subject: Re: [lamps] Last Call:
> > <draft-ietf-lamps-hash-of-root-key-cert-extn-
> >> 02.txt> (Hash Of Root Key Certificate Extension) to Informational RFC
> >>
> >> I don't understand what the risk is.
> >>
> >> If a client sees and understands the extension, it can update its
> >> trust
> > store to
> >> have the new key.  If a client does not see, or does not understand,
> >> the extension, then the trust store will have to be updated out of
> >> band, just
> > like it
> >> is now.
> >>
> >> CA's that use this extension must take proper care to ensure that the
> > private
> >> key is not exposed.
> >>
> >>
> >> _______________________________________________
> >> Spasm mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/spasm