So, I've implemented a small widget and p15card class.

For now it is read only and does not show any actions. We could for example show to generate a CSR or another OpenPGP key for such a card. I'm a bit unsure how to decide that. For the current smartcard which we want to present tomorrow we do not want any actions because the smartcard itself is managed by a different application.

The difficultiy for p15card as I understand it is that CardOS / PKCS#15 is just a generic Operating System and how they interact with GnuPG depends a lot on the apps running on the Smartcard. For example we support the Bundesdruckerei card, which have keys for qualified and normal S/MIME operations. But then we also have the Atos Card with R&S apps that I've based the current implementation on and they have a lot of internal keys used for Trusted Disk for example and then additionaly some OpenPGP keys.

My idea for this was that we use the keyRef of the other apps to link the generic PKCS#15 keys to a specific app usage like:

/* Obtain an application specific fingerprint for a key
 * stored on this card.
 * e.g. An App Key Ref would be
 *      OpenPGPCard::pgpSigKeyRef */
std::string appKeyFingerprint(const std::string &appKeyRef) const;

This maps "OpenPGP.1" to the fingerprint of the key returned by std::string signingKeyRef() const;
signingKeyRef for a PKCS#15 card is totally dynamic, like: P15.3F5AF7F52D55E312E7F5349D475EC6D3908A5F7B

But we should talk about this.

As we are adding more and more smartcards I think we should maybe move even more code into the card.h base class. I had to copy around some code from the OpenPGP Card for example and other things are similar to the PIV Card.
Esp. I think that we should add a virtual base implementation for setCardInfo and add mMetaInfo to the base. We could define that mMetaInfo contains everything that SCD learn --force returns, even if that is already parsed into other data members. That way we can always access the info that this command returned later.

void PIVCard::setCardInfo(const std::vector< std::pair<std::string, std::string> > &infos)
{
    qCDebug(KLEOPATRA_LOG) << "Card" << serialNumber().c_str() << "info:";
    for (const auto &pair: infos) {
        qCDebug(KLEOPATRA_LOG) << pair.first.c_str() << ":" << pair.second.c_str();
        if (parseCardInfo(pair.first, pair.second)) {
            continue;
        }
        mMetaInfo.insert(pair.first, pair.second);
    }
}

I have not done this because I did not want to fiddle too much with your architecture @ikloecker without talking to you first. I would like to leave most of that to you. I'll also open a subtask for a "PGPKeyRefWidget" as I needed something like the keyWidgets also in the p15 card.

I'll see about getting at least an atos card to you soon. We do not have many as werner has bricked some ;-)

SCD GETATTR $SIGNKEYID returns the signing key ref. This information is read in get_card_status() and stored in the Card (see rKLEOPATRAd2bf514e4963: Fetch and store IDs of signing key and encryption key for card).

So, if scdaemon returns the dynamic signing key ref of a PKCS#15, then Kleopatra will make use of this already. At least, in those places were Card::signingKeyRef() is already used. A lot of places are still hard-coded to OpenPGPCard::pgpSigKeyRef().

Mmh, right I've used that but I still went with the key-fpr as I saw that and werner suggested this could be used by kleo. But it might be better to just ignore the key-fpr values which you have to explicitly query for PKCS#15 and just use

$SIGNKEYID -> keyref.grip to figure out the signing key for openpgp.

So I have talked with werner about this. The key-fpr is mostly required so that we can search for the public key belonging to the smarcard if we don't have it. This would also be something to do for the openpgp card.

The idea is that we can find the public key belonging to a card through the keygrip.
But if we don't then we can search for the key-fpr and import that key e.g. from LDAP. This is the case in R&S Setups so this is important and not just a corner case.

Current look without public keys:

Current look with public keys: