[PATCH] gpg: enable key-to-card upload for cert-only keys

[Dominik Heidler]

Would changing the specification require a new gnupg-card with updated card-os? How difficult is it to perform such a change?

On 4. Februar 2014 02:54:06 MEZ, NIIBE Yutaka <gniibe at fsij.org> wrote:
>On 2014-02-03 at 09:08 +0100, Dominik Heidler wrote:
>> If I understand you correctly, you want to add a S-only slot to the
>> card.
>
>Yes.  More specifically, I am considering to extend the
>_specification_, so that a card (in future) can optionally has S-only
>slot.
>
>> That would only make sence, if the existing SC slot would then allow
>> C-only keys.
>
>My point is that C-only slot will make sense more coherently, when
>we modify (or clarify) the specification of OpenPGP card.
>
>> So your idea is about having the following key slots on the card:
>> S1: C (or SC?)
>> S2: S
>> S3: E
>> S4: A
>
>Fundamental difference is that, a key (or a subkey) in OpenPGP has
>flags, while a key in _OpenPGP card_ has predefined capability for a
>slot.  Thus, OpenPGP card cannot cover all possible usages of OpenPGP
>key, but some parts of them.  For example, a OpenPGP key with flag
>C+S+E+A can't map to a single key of OpenPGP card.  (For such a key,
>GnuPG requires user's decision to which slot and which usage, when
>user asks importing.)
>
>Currently, the specification of OpenPGP card is defined as:
>
>    S1: <S>
>    S2: <E>
>    S3: <A>
>
>And, while a key in a slot with <E> and <A> are more or less as
>similar as a key E and A in OpenPGP, <S> is somewhat ambiguous or
>there is a room of different interpretations.  I think that <S> is
>interpreted as S+C in OpenPGP (which is common for a primary key).
>But I know people who put their S-only subkey to <S> slot.  And you
>want to put your C-only primary key to <S> slot.
>
>My idea is something like:
>
>    S1: For OpenPGP primary key (Certification, and Signature possibly)
>    S2: Encryption (for OpenPGP subkey with E-only)
>    S3: Authentication (for OpenPGP subkey with A-only)
>    Optional S4: Signature (for OpenPGP subkey with S-only, or others)
>
>I think that this covers all existing usages (including yours) and my
>own usage in future.
>
>Well, it would be me who go too far.
>
>Let's consider a specification or an interpretation with no optional
>S4 slot.
>
>It's most likely to me:
>
>    (A)
>    S1: For OpenPGP primary key (Certification plus Signature)
>    S2: Encryption (for OpenPGP subkey with E-only)
>    S3: Authentication (for OpenPGP subkey with A-only)
>
>With this, it is a kind of abuse for a user to import S-only subkey to
>S1 (although it works with current implementation of GnuPG).  It is
>correct for GnuPG not to support importing C-only key for S1 slot.
>
>It would be:
>
>    (B)
>    S1: For OpenPGP primary key (Certification, and Signature possibly)
>    S2: Encryption (for OpenPGP subkey with E-only)
>    S3: Authentication (for OpenPGP subkey with A-only)
>
>With this, C-only key should be supported for S1.
>
>
>Or:
>
>    (C)
>   S1: For any OpenPGP key/subkey (Certification, or Signature, others)
>    S2: Encryption (for OpenPGP subkey with E-only)
>    S3: Authentication (for OpenPGP subkey with A-only)
>
>With this, C-only key should be supported for S1, too.
>
>
>If (A) is the case for current specification, modifying the
>implementation based on (B)/(C) is wrong.