Jun 8 2017
Jun 7 2017
GnuPG needs to report compliance when decrypting symmetrically encrypted packet.
Jun 6 2017
Jun 1 2017
Implemented in gpg, gpgsm, and gpgme with all bindings.
May 31 2017
Reading that PDF I guess we need the same functionality in gpgsm too, right?
May 30 2017
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.
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:
May 29 2017
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'.