GnuPG needs to report compliance when decrypting symmetrically encrypted packet.

Implemented in gpg, gpgsm, and gpgme with all bindings.

Yes.

Reading that PDF I guess we need the same functionality in gpgsm too, right?

In T3059#98047, @werner wrote:

DSA is signature-only but VS-NfD is only about encryption. Thus signatures are out of scope.

DSA is signature-only but VS-NfD is only about encryption. Thus signatures are out of scope. Even key management is out of scope. OTOH, certain algorithms are simply not allowed. This means we can't use SHA-1 except for specified and approved usages (in our case OpenPGP fingerprints).

Yes. mark them as non-compliant.

In T3059#98040, @aheinecke wrote:

In T3059#98039, @justus wrote:

Afaics the document does not specify the following. OpenPGP messages can carry multiple signatures, and the session key can be encrypted by multiple keys. I will implement the following logic:

1. A verification operation is compliant if one of the signatures is compliant.
2. A decryption operation is compliant if all of the algorithms used to encrypt the session keys are compliant.

Sounds exactly right to me.

In T3059#98039, @justus wrote:

Afaics the document does not specify the following. OpenPGP messages can carry multiple signatures, and the session key can be encrypted by multiple keys. I will implement the following logic:

1. A verification operation is compliant if one of the signatures is compliant.
2. A decryption operation is compliant if all of the algorithms used to encrypt the session keys are compliant.

Afaics the document does not specify the following. OpenPGP messages can carry multiple signatures, and the session key can be encrypted by multiple keys. I will implement the following logic:

In T3059#98015, @werner wrote:

g10/misc.c:gnupg_pk_is_compliant is my take on puble key algorithms.

See kerckhoffs:~wk/ST-Gpg4VSNfD-v0.6.pdf - eventually this will be published but right now we don't have clearance from the BSI to do that.

g10/misc.c:gnupg_pk_is_compliant is my take on puble key algorithms. For cipher algorithm, we will only allow AES* and digest SHA-2-*. Other details are in a document we have in an project internal wiki - I'll send you a copy.

Ok, good to know. However, I still need more information about what it means to comply with CO_DE_VS. Any pointers?

I thought about this but in the end it is unlikely that we will see request for other protection profiles. Thus I did spend a single bit on the German thing. Further, it is quite possible that a message matches several profiles and than bit fields come really handy. For the very limited circle of users a dedicated sub system for such things would be overkill.

The GPGME API uses field names like 'is_de_vs', but isn't that short-sighted because we hardcode names of compliance modes into the API? Also, 'vs' seems to match both 'VERSCHLUSSSACHE – VERTRAULICH' and 'VERSCHLUSSSACHE – NUR FÜR DEN DIENSTGEBRAUCH'.