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 <stephen.farrell@xxxxxxxxx> > Sent: Wednesday, January 2, 2019 4:20 PM > To: Tim Hollebeek <tim.hollebeek@xxxxxxxxxxxx>; Salz, Rich > <rsalz@xxxxxxxxxx>; Paul Hoffman <paul.hoffman@xxxxxxxx>; Russ > Housley <housley@xxxxxxxxxxxx> > Cc: spasm@xxxxxxxx; draft-ietf-lamps-hash-of-root-key-cert-extn@xxxxxxxx; > IETF <ietf@xxxxxxxx> > 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 <spasm-bounces@xxxxxxxx> On Behalf Of Salz, Rich > >> Sent: Wednesday, January 2, 2019 3:32 PM > >> To: Paul Hoffman <paul.hoffman@xxxxxxxx>; Russ Housley > >> <housley@xxxxxxxxxxxx> > >> Cc: spasm@xxxxxxxx; > >> draft-ietf-lamps-hash-of-root-key-cert-extn@xxxxxxxx; > > IETF > >> <ietf@xxxxxxxx> > >> 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 > >> Spasm@xxxxxxxx > >> https://www.ietf.org/mailman/listinfo/spasm
<<attachment: smime.p7s>>
