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:
0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys
Attachment:
signature.asc
Description: OpenPGP digital signature
