Moving over to openpgp(_at_)ietf(_dot_)org from gnupg-devel.
On Mon, Apr 29, 2013 at 1:52 PM, Werner Koch <wk(_at_)gnupg(_dot_)org> wrote:
I don't want the whole X.509 mess introduced in a protocol we tried to
keep clean for real use.
Well actually the contrary seems to be the case... OpenPGP is rather
only used for mail and plain file encryption/signing, which covers of
course already many fields, but nothing advanced.
It would never have any chance to be used for government ID cards, or
similar projects.
Please read 5.11:
...
There is nothing which enforces how you represet the name, you may put
arbitrary data into the UID. However, it is common to use a mail
address and thus GnuPG (by default) checks for that.
Yeah I knew... but right now it's also used for the name of the user,
which is the primary identification property... and it shouldn't be
used for that (from a design POV).
Why should we change somthing which has not shown problems in the
past. If you want X.509, use X.509 for example with gpgsm.
Obviously I don't want X.509 or I'd use it.
And I don't see how this is touched by X.509 anyway.
Of course there showed never problems up with the critical flag,
simply as no-one uses it... yeah I know, gpg understands it... but one
cannot even set it, can one?
On Mon, Apr 29, 2013 at 4:37 AM, Hauke Laging
<mailinglisten(_at_)hauke-laging(_dot_)de> wrote:
1) much more property fields that describe the key holder
That's easy as it can be done with notations; no need to change the protocol.
Well technically,... but there need such common notification to be
defined, for all these properties, which is the important part here.
1) How secure is the key?
2) What is the key used for?
3) How was the identity checked when certifying, how the email address and how
the comment?
Absolutely agreed... especially in a machine understandable way.
4) What statement does this signature make?
That could be done via policy sig subpackets... even though this is
not exactly defined right now.
You should not be forced to sign a UID as a whole.
In principle yes... it’s handy though to have a unique identifier
(which is not the fingerprint) on keys... whether this needs to be
signed by other users or just by the key itself is another question.
1) For compatibility with the signature laws: We really need the option to
extend certifications from UIDs to subkeys. That way you could have a "normal"
key and a CA could be sure that a certain subkey is on a smartcard only.
2) Officially supported offline main keys. Currently just a GnuPG extension.
IMHO the most important feature with respect to security (for everyday usage
keys).
+1
3) Double-digest signatures and double-cipher encryption in case one gets
broken.
Absolutely agreed, though it would be even better to allow arbitrary
number of such.
Maybe one could even think of doing the same with differen crypto
systems (i.e. one that was not vulnerable to Shore ;) )
4) Signature weight: Limit the signing power of a key (to 1/n) so that
signatures of n different keys are enforced for paranoid applications.
+1
5) Seperate header files for encryption. We have detached signatures. Today
you have to rewrite a huge encrypted file if you want to add (or remove)
recipients.
Not so sure about this... to me the rationale behind the detached sigs
is rather that you can keep the signed-only file in clean text.
The encrpyted file is unreadable anyway, so you can also include the
session key in it... and that you can re-encrypt quite fast at a later
point for different users.
On Mon, Apr 29, 2013 at 7:17 AM, Robert J. Hansen
<rjh(_at_)sixdemonbag(_dot_)org> wrote:
I'll make my own wish list simple:
I don't want *anything* new included in the standard unless there exists
at least one user who says, "the absence of this feature is a
showstopper for me and is blocking my adoption of GnuPG." This user
needs to be able to show a real-world use case and be willing to
volunteer to run trials in a real-world environment.
No real-world user? No feature.
Well that's kinda stupid as it boils down to the hen egg problem, ain't it?
Especially that OpenPGP looses ground in most areas (unless perhaps
OpenSource) against X.509 should already show, that there are many
showstoppers.
Cheers,
Phil.
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp