This needs Werner's input.

How does gpg behave if the newest encryption subkey is not compliant, but an older still valid encryption subkey is compliant? Will gpg use the newest compliant encryption subkey if de-vs compliance is enabled? Or will it deny encryption because the newest encryption subkey isn't compliant.

Similar question for signing. Will gpg, in de-vs compliance mode, ignore non-compliant signing (sub)keys and use the newest compliant signing subkey? Or will signing fail if the newest signing subkey is non-compliant?

I need to evaluate this. However, what we can can do already now is to ignore all Auth keys - they don't matter at all and it is pretty convenient to have Brainpool primary and encryption subkey but an ed25519 auth subkey on a card. That is because ssh does not support Brainpool. We should show such a key (i.e. Yubikey) as compliant.

In the keylist of Kleopatra or in the recipient selection of GpgOL we needed to display if the operation with these keys can be VS-NfD compliant or not. I have an encryption subkey which is compliant and aonther one that is not compliant, both are valid. Currently GnuPG will use the "last modified" of the two. And since it is not transparent to Kleopatra which subkey is used, kleopatra could not show "Encrypting to this key is compliant". Which was a requirement. Since we only tell GnuPG the fingerprint of the primary subkey as recipient, to me we would need to either directly add the subkey we want to use as recipient (with ! ) or we cannot really show it. Well maybe with a version check if GnuPG is adding this now.

Since most keys have one or two user IDs and one signing key and another encryption subkey we ended up with a simplification that says: "Kleopatra shows a key as compliant if all subkeys are compilant and all user IDs are certified." Since we needed a binary state for the whole key / certificate if it is VS-NfD compliant as a recipient.

Now as we have implemented the exploded model where each userid is an item we could also relax that. The rationale here has always been to be more conservative with this policy indication of wether or not something is VS-NfD compilant since the argumentation was that when in doubt users should create a new key especially for VS-NfD and not use some old key with multiple, non vs-nfd usages etc. as that leads the user to have a clearer seperation between their VS-NfD key and their "general" key, which they are also allowed to store / use on a non-vsnfd system.

This is libkleos check to display wether or not a key is compliant, this has been refactored and changed over the time to reduce duplicated checks but the logic for that has always been the same:

bool Kleo::DeVSCompliance::allSubkeysAreCompliant(const GpgME::Key &key)
{
    if (!isActive()) {
        return true;
    }
    // there is at least one usable subkey
    const auto usableSubkeys = Kleo::count_if(key.subkeys(), [](const auto &sub) {
        return !sub.isExpired() && !sub.isRevoked();
    });
    if (usableSubkeys == 0) {
        qCDebug(LIBKLEO_LOG) << __func__ << "No usable subkeys found for key" << key;
        return false;
    }
    // and all usable subkeys are compliant
    return Kleo::all_of(key.subkeys(), [](const auto &sub) {
        return sub.isDeVs() || sub.isExpired() || sub.isRevoked();
    });
}

bool Kleo::DeVSCompliance::userIDIsCompliant(const GpgME::UserID &id)
{
    if (!isActive()) {
        return true;
    }
    return (id.parent().keyListMode() & GpgME::Validate) //
        && !id.isRevoked() //
        && id.validity() >= GpgME::UserID::Full //
        && allSubkeysAreCompliant(id.parent());
}

bool Kleo::DeVSCompliance::keyIsCompliant(const GpgME::Key &key)
{
    if (!isActive()) {
        return true;
    }
    return (key.keyListMode() & GpgME::Validate) //
        && allUserIDsHaveFullValidity(key) //
        && allSubkeysAreCompliant(key);
}

Answer in non #dkgmode: Seems I don't need to evaluate the details then. However, excluding auth only keys should be a no-brainer.

Backported for VSD 3.3