Make information that a verifyresult / decrypt result was compliant to a compliance mode available through GPGME
Closed, ResolvedPublic

Description

While we know if keys in general are compliant a single signature or encryption may have used a non compliant algorithm. This information is needed to present the results in compliance mode.

  1. Add this to gnupg
  2. Add this to gpgme
  3. Add this to gpgme++

Assigned to Werner for Part 1.

aheinecke created this object in space S1 Public.
justus claimed this task.May 29 2017, 10:49 AM
justus added a subscriber: werner.

I need more information about what it means to comply with CO_DE_VS. Any pointers?

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

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.

VS and VS-NfD are the same at the technical level.

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

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.

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.

In T3059#98015, @werner wrote:

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

That document also lists DSA with certain parameters as conforming. Are those conditions not met by OpenPGP, or is that an oversight in the current implementation?

For cipher algorithm, we will only allow AES* and digest SHA-2-*.

Also 3DES afaics.

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.

Furthermore, the document seems to suggest that encrypted messages that are not signed are compliant. For me that implies that messages encrypted in a compliant way that carry a non-compliant signature are non-compliant, thus are rated worse than the same message with the non-compliant signature stripped.

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.

Furthermore, the document seems to suggest that encrypted messages that are not signed are compliant. For me that implies that messages encrypted in a compliant way that carry a non-compliant signature are non-compliant, thus are rated worse than the same message with the non-compliant signature stripped.

Yes. The presentation of that result then belongs to the GUI. For Example for a Compliant Message with an Uncompliant Signature I would show only the Decryption result as "Compliant" and maybe show the signature as yellow or not show some green "Verified Sender" bar. Only for compliant signatures I would positively show "Green! Yay Super compliant message!" And if Authenticity is an issue users may be trained only to treat "Yay Super compliant message!" as authentic.

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.

I'm not sure if I can do 2. actually, because only public keys with a certain key size are compliant, and I only know the key size for keys that I have. Shall I mark operations involving unknown keys as non-compliant, or is there a way to infer the key size from the pubkey packet?

Yes. mark them as non-compliant.

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

Using 3DES is still fine.

In T3059#98047, @werner wrote:

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

But the document you gave me talks quite a lot about signing data and how to verify signatures.

Even key management is out of scope.

It also talks about key management, but I haven't looked at it.

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

justus closed this task as Resolved.Jun 1 2017, 2:19 PM

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

justus reopened this task as Open.Jun 7 2017, 11:02 AM

GnuPG needs to report compliance when decrypting symmetrically encrypted packet.

justus closed this task as Resolved.Jun 8 2017, 2:24 PM