Subject: [openpgp] ECDH and ELG-E primary keys

From: David Leon Gil <[email-masked]>
Date: Fri, 1 Aug 2014 13:43:21 -0400

A quick note re exportable public keys. Apparently the SKS keyservers
will accept(?) ECDH or ELG-E primary public keys:

See, e.g., http://pool.sks-keyservers.net/pks/lookup?op=get&search=0x13A7A60EF2AC27BC
or http://pool.sks-keyservers.net/pks/lookup?op=get&search=0xE7E4C6E20CF902B7

(But there are only 6 examples of these in total... Does anyone know
what software can use them?)

This seems like a sensible deviation from the RFC to me; the benefits
of signing an ECDH or ELG-E key intended solely for (somewhat)
deniable encryption are minimal.

- David

---

From: Werner Koch <[email-masked]>
Date: Mon, 04 Aug 2014 11:50:29 +0200

> what software can use them?)

No software can use those keys becuase they are not capabable of
signing.  They are rejected ("no user Id" because the self-signature
does not check out).

Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

---

From: Ian Bobbitt <[email-masked]>
Date: Mon, 4 Aug 2014 13:06:46 -0400

I'm not so sure I would say "no software" can use them. They're odd in that
they're a bare Public-Key Packet, but that doesn't mean they're unusable.

For example, the first example is a secp256r1 public key for ECDH with
point 54913208749856979301715917236679182042233113041563426424642991739197245983353452579573506780881803740193710199307901035821397170740305648420195074480633099
and SHA256 and 128 bit AES for KDF, as described in RFC6637.

There may exist software that is using the OpenPGP format for exchanging
keys without generating what most software would expect.

On Mon, Aug 4, 2014 at 5:50 AM, Werner Koch <[email-masked]> wrote:

> _______________________________________________
> openpgp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/openpgp
>

---

From: Werner Koch <[email-masked]>
Date: Mon, 04 Aug 2014 22:04:16 +0200

> they're a bare Public-Key Packet, but that doesn't mean they're unusable.

I won't call that an OpenPGP packet.  It is not OpenPGP compatible:

RFC4880, 12.1 Key Structures:

   In a V4 key, the primary key MUST be a key capable of certification.

along with 5.5.2 Public-Key Packet Formats:

   OpenPGP implementations MUST create keys with version 4 format.  V3
   keys are deprecated; an implementation MUST NOT generate a V3 key,
   but MAY accept it.

v3 keys have severe weaknesses for example they rely on MD5.  ECDH is
not capabale of signing/certifying.

Shalom-Salam,

   Werner

---

From: Derek Atkins <[email-masked]>
Date: Tue, 12 Aug 2014 14:56:57 -0400

> not capabale of signing/certifying.

For what it's worth I have a use-case for bare Public Key Packets with
direct signatures, without a user-id packet or a self-signature.

I plan to write up an I-D that will loosen the restrictions in 4880 to
allow this use-case.

Note that this use-case is not for email.  Indeed, these keys are not
even user keys; they are "device keys".  In my use case I'd like to use
RFC4880-style signatures for certifying those device keys.

Hopefully there is some support for this loosening?

>    Werner

-derek

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: Werner Koch <[email-masked]>
Date: Wed, 13 Aug 2014 10:27:36 +0200

> Hopefully there is some support for this loosening?

You mean a feature to create v3 keys?  RFC4880 is quite specific about
creating v3 keys:

Regarding signatres, v3 signatures SHOULD not be used and thus it is
possible to implement them.

In 11.1 transferable key is defined as

     - One Public-Key packet
     - Zero or more revocation signatures
     - One or more User ID packets
     [...]

in 12.1 (Key structures) a v3 key is defined as

           RSA Public Key
              [Revocation Self Signature]
               User ID [Signature ...]
              [User ID [Signature ...] ...]

and a v4 key as

           Primary-Key
              [Revocation Self Signature]
              [Direct Key Signature...]
               User ID [Signature ...]
              [User ID [Signature ...] ...]

Thus a strict interpretation requires a user id packet.  A direct key
signature is only possible with a v4 key.

Shalom-Salam,

   Werner

---

From: "Derek Atkins" <[email-masked]>
Date: Wed, 13 Aug 2014 08:45:27 -0400

Hi,

On Wed, August 13, 2014 4:27 am, Werner Koch wrote:
> You mean a feature to create v3 keys?

No.  Not at all.
[snip]

> in 12.1 (Key structures) [snip] a v4 key as
>
>            Primary-Key

Exactly.  My proposal would be a new I-D that would loosen this
restriction and define a new-style v4+ key as:

           Primary-Key
              .... (rest elided)

I'll note that 12.1 goes on to say:

   In a V4 key, the primary key MUST be a key capable of certification.
   The subkeys may be keys of any other type.  There may be other

and in my proposed I-D I would remove this restriction as well.  Assuming
there is desire for this functionality.  Like I said, *I* have a use case
for this, and if I do I can assume others do too.

Am I more clear on what I intend?  Any comments on this?

-derek

---

From: Werner Koch <[email-masked]>
Date: Wed, 13 Aug 2014 15:30:21 +0200

>               [User ID [Signature ...] ...]

That would be easy to implement.

> Am I more clear on what I intend?  Any comments on this?

Yes.  no.

Shalom-Salam,

   Werner

---

From: "Derek Atkins" <[email-masked]>
Date: Wed, 13 Aug 2014 10:02:59 -0400

> That would be easy to implement.

That was my intention :)

>> Am I more clear on what I intend?  Any comments on this?

Great!  I'll work on the text and get it uploaded for comments.

Thanks,

-derek

---

From: "Brian G. Peterson" <[email-masked]>
Date: Wed, 13 Aug 2014 09:07:51 -0500

> Great!  I'll work on the text and get it uploaded for comments.

I believe Werner's point was that the RFC will not change to support 
your use case.  The old key and signature formats are obsolete, and 
should be abandoned.

Regards,

Brian

-- 
Brian G. Peterson
http://braverock.com/brian/
Ph: 773-459-4973
IM: bgpbraverock

---

From: "Derek Atkins" <[email-masked]>
Date: Wed, 13 Aug 2014 10:27:46 -0400

> your use case.  The old key and signature formats are obsolete, and

Then you didn't read my complete reply to Werner.  I am not suggesting
going back to the old key and signature (v3) formats.  I agree they should
be abandoned.

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.  And
Werner's reply to my suggestion (which you conveniently removed) was that
it would be easily implementable.

So, any other comments?

Thanks,

-derek

---

From: David Leon Gil <[email-masked]>
Date: Wed, 13 Aug 2014 12:01:47 -0400

On Wednesday, August 13, 2014, Derek Atkins <[email-masked]> wrote:

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

---

From: "Derek Atkins" <[email-masked]>
Date: Wed, 13 Aug 2014 12:09:21 -0400

> proof-of-possession. (If the key isn't able to sign a PoP, what can it

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

---

From: David Leon Gil <[email-masked]>
Date: Thu, 21 Aug 2014 11:37:42 -0400

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 <[email-masked]> wrote:

> > On Wednesday, August 13, 2014, Derek Atkins <[email-masked]
> <javascript:;>> wrote:
> >
> >>
>        [email-masked] <javascript:;>             www.ihtfp.com

---

From: Derek Atkins <[email-masked]>
Date: Thu, 21 Aug 2014 16:47:43 -0400

David Leon Gil <[email-masked]> writes:

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

Okay, I think I get the gist of this and I'll incorporate it into my
draft, which I plan to submit (hopefully) tomorrow.  Please read the
draft once it's posted and make sure I got it right?

Thanks for your feedback.

-derek
-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available