Re: Impact of ROCA (CVE-2017-15361) in subkey vs. private key?

Le 2017-10-31 à 13:01, Peter Lebbing a écrit : > Revocations are done by the primary key. If the user has lost the secret > primary, they should fetch their revocation certificate, not fool around with > the subkeys ;-). (Incidentally, this is why you don't need revocation > certificates for

Re: Impact of ROCA (CVE-2017-15361) in subkey vs. private key?

On 31/10/17 11:56, Lachlan Gunn wrote: > The only difficulty is when the owner doesn't have the secret key > anymore, and so can't re-revoke it. Then you might want to keep it from > being disseminated further. Revocations are done by the primary key. If the user has lost the secret primary,

Re: Impact of ROCA (CVE-2017-15361) in subkey vs. private key?

Le 2017-10-31 à 12:48, Peter Lebbing a écrit : > Having read my follow-up, do you now agree? If the subkey is revoked as > "compromised", all is well and good? I can't see any reason why this should be problematic. And for signatures that you know for sure are pre-ROCA, it makes sense to keep

Re: Impact of ROCA (CVE-2017-15361) in subkey vs. private key?

On 31/10/17 11:45, Lachlan Gunn wrote: > No, I don't think so I was already writing a follow-up but was momentarily blocked on the right way to phrase some of it :-). Our mails crossed. Having read my follow-up, do you now agree? If the subkey is revoked as "compromised", all is well and good?

Re: Impact of ROCA (CVE-2017-15361) in subkey vs. private key?

On 31/10/17 11:39, Peter Lebbing wrote: > And yes, the subkey should also be revoked with reason "compromised", for the > reason you state. And only now the penny drops. I suppose a system checking for ROCA might rightfully take offense at a subkey revoked as "superseded" or "lost"[1], because

Re: Impact of ROCA (CVE-2017-15361) in subkey vs. private key?

Le 2017-10-31 à 12:39, Peter Lebbing a écrit : > To clarify, do you agree if I reword the paragraph you contest as: > > But, I agree that the reverse is not true: a compromised subkey does not > compromise the primary key in any way I can think of. And systems > checking for ROCA should not

Re: Impact of ROCA (CVE-2017-15361) in subkey vs. private key?

On 31/10/17 01:08, Lachlan Gunn wrote: > I'm not sure that this is 100% correct.  The first part is true, but > signatures > of a key that has been revoked because it was superseded or lost are valid up > to > the revocation date, whereas ROCA-affected keys are compromised to some degree > and

Re: Impact of ROCA (CVE-2017-15361) in subkey vs. private key?

2017-10-30 23:44 GMT+10:30 Peter Lebbing : > But, I agree that the reverse is not true: a compromised subkey does not > compromise the primary key in any way I can think of. And systems > checking for ROCA should not reject a certificate because there is > something wrong

Re: Impact of ROCA (CVE-2017-15361) in subkey vs. private key?

On 29/10/17 23:08, Damien Goutte-Gattat wrote: > This is also true the other way around: knowing the primary private key > does not allow to deduce the private subkey(s). This is technically correct but in practice the point can be almost moot, depending on the threat model. When you know the

Re: Impact of ROCA (CVE-2017-15361) in subkey vs. private key?

On 10/29/2017 07:18 PM, Shannon C wrote: Assuming that the secret key was generated outside of an Infineon chip, but that subsequently subkeys were generated by a chip with the ROCA vulnerability, does that compromise the main private key, or only the subkey? There is no mathematical link

Re: Impact of ROCA (CVE-2017-15361) in subkey vs. private key?

> On 29 Oct 2017, at 19:18, Shannon C wrote: > > I can't find anyone talking about this particular issue. Assuming that the > secret key was generated outside of an Infineon chip, but that subsequently > subkeys were generated by a chip with the ROCA vulnerability, does