Sorry, I wasn't entirely clear; for this case a certification signature
would be nonsensical. But a direct key signature would. Perhaps:
> A key capable of making signatures SHOULD be accompanied by either a
certification signature or a signature directly on the key. An
implementation MUST allow importing a key accompanied either by a
certification signature or a signature on itself. It MAY accept public keys
without an accompanying signature.
And then a must accept for encryption-only primary keys sans signature.
On Wednesday, August 13, 2014, Derek Atkins <derek(_at_)ihtfp(_dot_)com> wrote:
On Wed, August 13, 2014 12:01 pm, David Leon Gil wrote:
On Wednesday, August 13, 2014, Derek Atkins <derek(_at_)ihtfp(_dot_)com
<javascript:;>> wrote:
I am suggesting a *NEW* I-D (which will hopefully be progressed into an
RFC) that would extend RFC4880 and loosen the v4 key restrictions in
section 12.1 that require a UserID+Self-Signature on a Primary Key.
So, any other comments?
I support the proposal so far as it concerns *encryption* keys as primary
keys; I'd prefer if the MUST support were limited to ECDH keys.
I don't really see much point in permitting *signing* keys without a
proof-of-possession. (If the key isn't able to sign a PoP, what can it
do?)
While I consider this a reasonable restriction, in my use case there is no
need for self-certification. Devices don't have self-identities, only the
keys; identities are supplied by third parties. However I am willing to
make it a "SHOULD Self-Certify" for a key that is capable of signatures to
make it clear that in the general case you should still self-sign when you
can.
Does that work for you?
-derek
--
Derek Atkins 617-623-3745
derek(_at_)ihtfp(_dot_)com <javascript:;> www.ihtfp.com
Computer and Internet Security Consultant
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp