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.
Assigned to Werner for Part 1.
| Status | Assigned | Task | ||
|---|---|---|---|---|
| Resolved | justus | T3058 Implement GUI for compliance mode | ||
| Resolved | justus | T3059 Make information that a verifyresult / decrypt result was compliant to a compliance mode available through GPGME |
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.
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:
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.
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.
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?
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.
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.