Mailing List Archive

Rationale/reasons for splitting Sign and Authenticate into two separate subkeys in a work-environment?
Hi!

I'm currently helping my workplace test out Yubikeys - to see how/if they
could help us with our software development. One expected benefit is to
allow developers cryptographically sign Git commits/tags (e.g).

My question is based on this awesome answer by Thomas Pornin:
https://security.stackexchange.com/a/43591;
*In a work-environment, what benefits does one gain by having separate
Authentication/Signing (sub)keys?*

I understand and agree with the rationale of keeping a separate Encryption
key (so that this could be shared with your employer), but that rationale
does not extend for Signing/Authenticating (presuming a trustworthy
workplace which doesn't need to fake authentication/signing of employees).
--
Med vennlig hilsen/Kind regards,
Christian Chavez
Phone/Tlf: +47 922 22 603
Re: Rationale/reasons for splitting Sign and Authenticate into two separate subkeys in a work-environment? [ In reply to ]
On 22 Dec 2020, at 13:31, Christian Chavez via Gnupg-users <gnupg-users@gnupg.org> wrote:

> My question is based on this awesome answer by Thomas Pornin: https://security.stackexchange.com/a/43591 <https://security.stackexchange.com/a/43591>;
> In a work-environment, what benefits does one gain by having separate Authentication/Signing (sub)keys?
>
> I understand and agree with the rationale of keeping a separate Encryption key (so that this could be shared with your employer), but that rationale does not extend for Signing/Authenticating (presuming a trustworthy workplace which doesn't need to fake authentication/signing of employees).

Keep in mind that in some workplaces the building of that trust explicitly includes the need for counter-intelligence - and hence a legitimate use of fake signatures.

Though I have a hard time imagining a use case in the european private sector for that.

Dw.
Re: Rationale/reasons for splitting Sign and Authenticate into two separate subkeys in a work-environment? [ In reply to ]
Hi Dirk-Willem!
Thanks for your reply - but I'm unfortunately lost as to your (what I
surmise is your implied) hypothetical use-case?

Ref:
On Tue, Dec 22, 2020 at 2:56 PM Dirk-Willem van Gulik <dirkx@webweaving.org>
wrote:

> Keep in mind that in some workplaces the building of that trust explicitly
> includes the need for counter-intelligence - and hence a legitimate use of
> fake signatures.
> Though I have a hard time imagining a use case in the european private
> sector for that.
>

Would you mind elaborating on when you'd foresee/imagine such a
non-european/non-private sector have a need for this?
There's nothing that would stop the user in question utilizing multiple
separate "main" keys, and not just separate sub-keys per A, S, E
capability in your scenario (even when A and S capabilities reside on the
_same_ private/public sub-key pair).

--
Med vennlig hilsen/Kind regards,
Christian Chavez
Phone/Tlf: +47 922 22 603
Re: Rationale/reasons for splitting Sign and Authenticate into two separate subkeys in a work-environment? [ In reply to ]
On 22 Dec 2020, at 16:16, Christian Chavez <x10an14@gmail.com> wrote:

> Thanks for your reply - but I'm unfortunately lost as to your (what I surmise is your implied) hypothetical use-case?

It is a very common requirement that you find in gov. procurement documents/requirements of cryptographic technology that lives in a chipcard, HSM, etc -- the need to be able to forge signatures for counter intelligence.

Dw.
_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Rationale/reasons for splitting Sign and Authenticate into two separate subkeys in a work-environment? [ In reply to ]
Nvm, apologies for the spam.
I retract my question now after having conferred with a third-party.

I understand now your hypothetical scenario - thanks!

Does anyone else have any thoughts on the reduced complexity of juggling
multiple (sub?)keys vs the security implications of not separating
Authentication/Signing to different (sub?)keys?

On Tue, Dec 22, 2020 at 4:16 PM Christian Chavez <x10an14@gmail.com> wrote:

> Hi Dirk-Willem!
> Thanks for your reply - but I'm unfortunately lost as to your (what I
> surmise is your implied) hypothetical use-case?
>
> Ref:
> On Tue, Dec 22, 2020 at 2:56 PM Dirk-Willem van Gulik <
> dirkx@webweaving.org> wrote:
>
>> Keep in mind that in some workplaces the building of that trust
>> explicitly includes the need for counter-intelligence - and hence a
>> legitimate use of fake signatures.
>> Though I have a hard time imagining a use case in the european private
>> sector for that.
>>
>
> Would you mind elaborating on when you'd foresee/imagine such a
> non-european/non-private sector have a need for this?
> There's nothing that would stop the user in question utilizing multiple
> separate "main" keys, and not just separate sub-keys per A, S, E
> capability in your scenario (even when A and S capabilities reside on the
> _same_ private/public sub-key pair).
>
> --
> Med vennlig hilsen/Kind regards,
> Christian Chavez
> Phone/Tlf: +47 922 22 603
>


--
Med vennlig hilsen/Kind regards,
Christian Chavez
Phone/Tlf: +47 922 22 603
Re: Rationale/reasons for splitting Sign and Authenticate into two separate subkeys in a work-environment? [ In reply to ]
On 2020-12-22T13:31:42+0100 Christian Chavez via Gnupg-users
<gnupg-users@gnupg.org> wrote 2.8K bytes:

>I'm currently helping my workplace test out Yubikeys - to see how/if
>they could help us with our software development. One expected benefit
>is to allow developers cryptographically sign Git commits/tags (e.g).

I hope I'm not the only one on this list that may have left innocuous
commits forged under the name of someone who didn't work there anymore
to prove that a less ethical person may have already gotten away with
actually committing malicious code.

I was in an org once that had a neat system of generating SSH keys on
hardware tokens, and then distributing them to the servers that each
person should have access to. It was hella cool. I did something
similar with my home LAN by swapping ssh-agent for gpg-agent on my
terminals, and using a keyserver to distribute my public key to devices.

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users