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

[NIIBE Yutaka]

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.
--