Subject: Re: [openpgp] OpenPGP extension to allow for Primary Encrypt-only Keys

From: Werner Koch <[email-masked]>
Date: Mon, 01 Sep 2014 14:15:15 +0200

On Thu, 28 Aug 2014 22:09, [email-masked] said:

> Another thing it does is add a new "User ID Attribute" type to the User
> Attributes list so that you could use a single signature to certify both
> an "ID" and an image together.

Is the intention that a user ID attribute shall in general be handled
the same way as a user id packet?  This would raise the question whether
a certification is based on only or all the user id, the image, or any
future sub packets.  Given that you assume certain constrains on an
implementation, the intended use would require only a self-signature.
Can you clarify that in the draft?

  4.4.  The 'vers' Notation

   This notation defines the product version number (which could be a
   release number, year, or some other identifier to differentiate
   different versions of the same make/model).  It is a free form
   string.

I would suggest to use a different name.  "vers" might be confused with
the protocol or key version, what about "mver", "pver, or "pvers"?

Shalom-Salam,

   Werner

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

---

From: "Derek Atkins" <[email-masked]>
Date: Mon, 1 Sep 2014 09:13:30 -0400

Hi,

> Can you clarify that in the draft?

RFC4880 already says that that the User Attribute Packet should be treated
the same as the User ID Packet and can be used in all the places that a
User ID Packet can be used.  I'm just trying to add a place where you
could insert an actual "User ID" into the attribute packet so you don't
need two signatures to have both an ID and Image (and other attributes). 
I don't think there is any confusion; a signature over the User Attribute
Packet would be a signatue over the whole packet (meaning all subpackets
in the attribute).

However I can make this more clear.

> the protocol or key version, what about "mver", "pver, or "pvers"?

I'm not sure how it would get confused, but I'm not tied to "vers".  I'll
change it to pver.  I'm also adding a bunch more.  I'll submit a new draft
tomorrow; today is a holiday to technically I'm not working ;)

Thank you for your review sand comments.

>    Werner

-derek

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

---

From: Werner Koch <[email-masked]>
Date: Mon, 01 Sep 2014 18:01:56 +0200

> User ID Packet can be used.  I'm just trying to add a place where you

Alright.  I was in GnuPG and not in standard mode.  GnuPG skips the
attribute packets for trust computations because it would be surprising
if your key is valid because someone signed you photo and you don't even
see your photo on the command line.  We may need to reconsider this if
people start using the WoT based on your new user ID attribute.

> I'm not sure how it would get confused, but I'm not tied to "vers".  I'll

For example, we have a "Version:" armor header and "vers" looks like
some kind of abbreviation.  Right, they have technically nothing in
common but the notation will be listed and the armor headers may also be
noticed by the user.  No big deal, though.

Salam-Shalom,

   Werner

---

From: Derek Atkins <[email-masked]>
Date: Tue, 02 Sep 2014 13:27:10 -0400

Hi,

> people start using the WoT based on your new user ID attribute.

I added this text:

    Note that RFC 4880 already allows an User Attribute packet anywhere
    a User ID packet can be used.  See RFC 4880 section 5.2.3.19
    (Primary User ID) for more information on self-signatures over these
    kinds of packets.  Any signature on a User Attribute packet covers
    all subpackets.  Implementations MAY decide to trust the User ID
    Subpacket.

> noticed by the user.  No big deal, though.

Let me think more on this as I revise the draft.  I'll get another copy
out later today.

-derek

---

From: Derek Atkins <[email-masked]>
Date: Tue, 02 Sep 2014 15:44:21 -0400

Hi,

Attached please find the -01 version of this draft.

This version:

     * changed 'vers' notation to 'pvers'
     * added some new notations (prodid, lot, qty, and hash)
     * added some text about signatures over the User (ID) Attribute
       (sub)packet per our conversation

Please send me any additional comments.

Thanks,

-derek 

Internet Engineering Task Force                                D. Atkins
Internet-Draft                                      SecureRF Corporation
Updates: 4880 (if approved)                           September 02, 2014
Intended status: Standards Track
Expires: March 06, 2015

               OpenPGP Extensions for Device Certificates
              draft-atkins-openpgp-device-certificates-01

Abstract

   The OpenPGP Message Formats defined in RFC 4880 specify packet
   formats and methods for combining those packets to form messages and
   certificates.  However RFC 4880 made an architectural decision that
   keys are owned by users and must be self-certified.  New use cases
   have emerged where that is not the case.  There is a desire to have
   certificates that are not tied to a user (e.g. device certificates)
   and may only have encryption keys so may not even be self
   certifiable.  This draft specifies extensions to (and updates) RFC
   4880 that loosen the definitions of certificates in order to enable
   userless certificates without self-certifications.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on March 06, 2015.

Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of

Atkins                   Expires March 06, 2015                 [Page 1]

Internet-Draft         OpenPGP Device Certificates        September 2014

   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Device Certificate Format . . . . . . . . . . . . . . . . . .   3
   3.  User ID Attribute Subpacket . . . . . . . . . . . . . . . . .   4
   4.  Device Certification Notations  . . . . . . . . . . . . . . .   4
     4.1.  The 'manu' Notation . . . . . . . . . . . . . . . . . . .   4
     4.2.  The 'make' Notation . . . . . . . . . . . . . . . . . . .   5
     4.3.  The 'model' Notation  . . . . . . . . . . . . . . . . . .   5
     4.4.  The 'prodid' Notation . . . . . . . . . . . . . . . . . .   5
     4.5.  The 'pvers' Notation  . . . . . . . . . . . . . . . . . .   5
     4.6.  The 'lot' Notation  . . . . . . . . . . . . . . . . . . .   5
     4.7.  The 'qty' Notation  . . . . . . . . . . . . . . . . . . .   5
     4.8.  The 'loc' and 'dest' Notations  . . . . . . . . . . . . .   5
     4.9.  The 'hash' Notation . . . . . . . . . . . . . . . . . . .   5
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
     6.1.  PGP User Attribute Types  . . . . . . . . . . . . . . . .   6
     6.2.  Signature Notation Data Subpacket Types . . . . . . . . .   6
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   OpenPGP [RFC4880] defines a standard, compact format for, among other
   things, sharing keys and signature certificates.  Unfortunately the
   specification is user-focused, assuming that there are people sitting
   at the ends and creating and managing those keys.  New use cases have
   come up where that is not the case and the endpoint for these keys
   are devices, not users.  Yet we still want to be able to certify
   these device keys.

   Since the publication of RFC 4880, new use cases have emerged that
   don't fit into the existing standard models.  For example, the
   Internet of Things have introduced devices that need to certify
   device-level encryption keys but cannot self-certify and have no user
   associated.  This draft suggests extensions to RFC 4880 that enable

Atkins                   Expires March 06, 2015                 [Page 2]

Internet-Draft         OpenPGP Device Certificates        September 2014

   those use cases and make it easier to have device certificates using
   OpenPGP.

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

2.  Device Certificate Format

   RFC 4880 section 12.1 defines a v4 Public Key Format as a sequence of
   packets starting with a Primary Key and then a sequence of packets
   and subpackets that add Revocations, User IDs, and Signatures.

   The description in RFC 4880 requires a User ID.  Implementors of this
   specification can loosen that requirement such that an augmented V4
   device certificate looks like the following sequence (no longer
   requiring a User ID packet):

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

   Note that RFC 4880 section 11.1 defines this same sequence in text
   for transferable public keys.  Implementors of this specification can
   change that definition from "One or more User ID packets" to "Zero or
   more User ID packets".

   Moreover, one more relaxation from section 12.1.  RFC 4880 states
   that "In a V4 key, the primary key MUST be a key capable of
   certification."  Implementors of this specification can loosen that
   restriction as well, such that in V4 augmented key, the primary key
   MAY be a key capable of certification.

   A primary key capable of making signatures SHOULD be accompanied by
   either a certification signature (on a User ID or User Attribute) 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.  Implementations MUST accept encryption-only
   primary keys without a signature.

Atkins                   Expires March 06, 2015                 [Page 3]

Internet-Draft         OpenPGP Device Certificates        September 2014

3.  User ID Attribute Subpacket

   Section 5.12 of RFC 4880 defines the User Attribute Packet which can
   be used in lieu of a User ID Packet.  Whereas the User ID Packet only
   allows a single UTF-8 string content, the User Attribute Packet
   allows the addition of multiple attributes in subtype packets.
   Unfortunately RFC 4880 only defined a single Attribute Subpacket, the
   Image Attribute.  This means that you need two signatures if you want
   to have an ID and an image.

   To solve that problem for device certificates we define a new User
   Attribute Subpacket, the User ID Attribute Subpacket, type #[IANA --
   assignment TBD1].  A User ID Attribute subpacket, just like a User ID
   packet, consists of UTF-8 text that is intended to represent the name
   and email address of the key holder.  By convention, it includes an
   RFC 2822 [RFC2822] mail name-addr, but there are no restrictions on
   its content.  For devices, it may be the device identifier.  The
   packet length in the header specifies the length of the User ID.

   Note that RFC 4880 already allows an User Attribute packet anywhere a
   User ID packet can be used.  See RFC 4880 section 5.2.3.19 (Primary
   User ID) for more information on self-signatures over these kinds of
   packets.  Any signature on a User Attribute packet covers all
   subpackets.  Implementations MAY decide to trust the User ID
   Subpacket.

4.  Device Certification Notations

   OpenPGP defines a signature notation data packet that allows
   implementors and users to add extra data to signatures.  RFC 4880
   defined a registry for a global namespace and requires using
   [email-masked] domain-name notations otherwise.  Many of the devices
   targeted by this specification have limited storage capability, so it
   behooves an implementor to limit the extraneous storage.

   These notation can be important when you have a third-party device
   certification.  That third party might want to add extra data about
   the device to its signature certification.  In order to keep the
   certificate smaller we define a set of notations that MAY be used
   when signing a device certificate.

4.1.  The 'manu' Notation

   The "manu" notation is a string that declares the device
   manufacturer's name.  The certifier key is asserting this string
   (which may or may not be related to the User ID of the certifier's
   key).

Atkins                   Expires March 06, 2015                 [Page 4]

Internet-Draft         OpenPGP Device Certificates        September 2014

4.2.  The 'make' Notation

   This notation defines the product make.  It is a free form string.

4.3.  The 'model' Notation

   This notation defines the product model name/number.  It is a free
   form string.

4.4.  The 'prodid' Notation

   This notation contains the product identifier.  It is a free form
   string.

4.5.  The 'pvers' Notation

4.6.  The 'lot' Notation

   This notation defines the product lot number (which is an indicator
   of the batch of product).  It is a free form string.

4.7.  The 'qty' Notation

   This notation defines the quantity of items in this package.  It is a
   decimal integer representation with no punctuation, e.g. "10",
   "1000", "10000", etc.

4.8.  The 'loc' and 'dest' Notations

   The "loc" and 'dest' notations declare a GeoLocation as defined by
   RFC 5870 [RFC5870] but without the leading "geo:" header.  For
   example, if you had a GeoLocation URI of "geo:13.4125,103.8667" you
   would encode that in these notations as "13.4125,103.8667".

   The 'loc' notation is meant to encode the geo location where the
   signature was made.  The 'dest' notation is meant to encode the geo
   location where the device is "destined" (i.e., a "destination" for
   the device).

4.9.  The 'hash' Notation

   A 'hash' notation is a means to include external data in the contents
   of a signature without including the data itself.  This is done by

Atkins                   Expires March 06, 2015                 [Page 5]

Internet-Draft         OpenPGP Device Certificates        September 2014

   hashing the external data separately and then including the data's
   name and hash in the signature via this notation.  This is useful,
   for example, to have an external "manifest," "image," or other data
   that might not be vital to the signature itself but still needs to be
   protected and authenticated without requiring a second signature.

   The 'hash' notation has the following structure:

   o  A single byte specifying the length of the name of the hashed data

   o  A UTF-8 string of the name of the hashed data

   o  A single byte specifying the hash algorithm (see RFC 4880 section
      9.4)

   o  The binary hash output of the hashed data using the specified
      algorithm.  (The length of this data is implicit based on the
      algorithm specified).

   Due to its nature a 'hash' notation is not human readable and MUST
   NOT be marked as such when used.

5.  Acknowledgements

   A big thank you to Werner Koch, David Shaw, Jon Callas, and David
   Leon Gil for their input on the concepts and text of this document.

6.  IANA Considerations

   This document requests IANA to register several items within the
   OpenPGP parameters (or the "name space" in the terminology of
   [RFC5226]) created by [RFC4880].

6.1.  PGP User Attribute Types

   This specification asks IANA to register a PGP User Attribute Type:

                +-------+-----------+--------------------+
                | Value | Attribute |     Reference      |
                +-------+-----------+--------------------+
                |  TBD1 |  User ID  | This Doc Section 3 |
                +-------+-----------+--------------------+

                       Table 1: User Attribute Types

6.2.  Signature Notation Data Subpacket Types

Atkins                   Expires March 06, 2015                 [Page 6]

Internet-Draft         OpenPGP Device Certificates        September 2014

   This specification asks IANA to register a set of OpenPGP Signature
   Notation Data Subpacket Types defined in Section 4.  The following
   table is a summary of the requested registrations.

   +--------------+---------+--------------------------+---------------+
   |   Allowed    |   Name  |           Type           |   Reference   |
   |    Values    |         |                          |               |
   +--------------+---------+--------------------------+---------------+
   |  Any String  |   manu  |    Manufacturer Name     |    This doc   |
   |              |         |                          |  Section 4.1  |
   +--------------+---------+--------------------------+---------------+
   |  Any String  |   make  |       Product Make       |    This doc   |
   |              |         |                          |  Section 4.2  |
   +--------------+---------+--------------------------+---------------+
   |  Any String  |  model  |      Product Model       |    This doc   |
   |              |         |                          |  Section 4.3  |
   +--------------+---------+--------------------------+---------------+
   |  Any String  |  prodid |        Product ID        |    This doc   |
   |              |         |                          |  Section 4.4  |
   +--------------+---------+--------------------------+---------------+
   |  Any String  |  pvers  |     Product Version      |    This doc   |
   |              |         |                          |  Section 4.5  |
   +--------------+---------+--------------------------+---------------+
   |  Any String  |   lot   |    Product Lot Number    |    This doc   |
   |              |         |                          |  Section 4.6  |
   +--------------+---------+--------------------------+---------------+
   |   Decimal    |   qty   |     Package Quantity     |    This doc   |
   |   Integer    |         |                          |  Section 4.7  |
   |    String    |         |                          |               |
   +--------------+---------+--------------------------+---------------+
   |  A geo: URI  |   loc   |   Current Geo-location   |    This doc   |
   | without the  |         |    Latitude/Longitude    |  Section 4.8  |
   |    "geo:"    |         |                          |               |
   +--------------+---------+--------------------------+---------------+
   |  A geo: URI  |   dest  | Destination Geo-location |    This doc   |
   | without the  |         |    Latitude/Longitude    |  Section 4.8  |
   |    "geo:"    |         |                          |               |
   +--------------+---------+--------------------------+---------------+
   |     Hash     |   hash  |   The Hash of external   |    This doc   |
   |   Notation   |         |           data           |  Section 4.9  |
   |     data     |         |                          |               |
   +--------------+---------+--------------------------+---------------+

                   Table 2: Device Certificate Notations

7.  Security Considerations

   The Security Considerations of [RFC4880] apply.

Atkins                   Expires March 06, 2015                 [Page 7]

Internet-Draft         OpenPGP Device Certificates        September 2014

   OpenPGP was designed with security in mind, with many smart,
   intelligent people spending a lot of time thinking about the
   ramifications of their decisions.  Removing the requirement for self-
   certifying User ID (and User Attribute) packets on a key means that
   someone could surreptitiously add an unwanted ID to a key and sign
   it.  If enough "trusted" people sign that surreptitious identity then
   other people might believe it.  The attack could wind up sending
   encrypted mail destined for alice to some other target, bob, because
   someone added "alice" to bob's key without bob's consent.

   In the case of device certificates the device itself does not have
   any consent.  It is given an identity by the device manufacturer and
   the manufacturer can insert that ID on the device certificate,
   signing it with the manufacturer's key.  If another people wants to
   label the device by another name, they can do so.  There is no harm
   in multiple IDs, because the verification is all done based on who
   has signed those IDs.

   When a key can self-sign, it is still suggested to self-certify IDs,
   even if it no longer required by this modification to OpenPGP.  This
   at least signals to recipients of keys that yes, the owner of this
   key asserts that this identity belongs to herself.  Note, however,
   that mallet could still assert that he is 'alice' and could even
   self-certify that.  So the attack is not truly different.  Moreover,
   in the case of device certificates, it's more the manufacturer than
   the device that wants to assert an identity (even if the device could
   self-certify).

   There is no signaling whether a key is using this new, looser-
   requirement key format.  An attacker could therefore just remove the
   self-signature off a published key.  However one would hope that wide
   publication would result in another copy still having that signature
   and it being returned quickly.  However, the lack of signaling also
   means that a user with an application following RFC 4880 directly
   would see a key following this specification as "broken" and may not
   accept it.

   On a different note, including the "geo" notation could leak
   information about where a signer is located.  However it is just an
   assertion (albeit a signed assertion) so there is no verifiable truth
   to the location information released.  Similarly, all the rest of the
   signature notations are pure assertions, so they should be taken with
   the trustworthiness of the signer.

Atkins                   Expires March 06, 2015                 [Page 8]

Internet-Draft         OpenPGP Device Certificates        September 2014

   Combining the User ID with the User Attribute means that an ID and
   image would not be separable.  For a person this is probably not
   good, but for a device it's unlikely the image will change so it
   makes sense to combine the ID and image into a single signed packet
   with a single signature.

8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4880]  Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
              Thayer, "OpenPGP Message Format", RFC 4880, November 2007.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

8.2.  Informative References

   [RFC2822]  Resnick, P., "Internet Message Format", RFC 2822, April
              2001.

   [RFC5870]  Mayrhofer, A. and C. Spanring, "A Uniform Resource
              Identifier for Geographic Locations ('geo' URI)", RFC
              5870, June 2010.

Author's Address

   Derek Atkins
   SecureRF Corporation
   100 Beard Sawmill Rd, Suite 350
   Shelton, CT  06484
   US

   Phone: +1 617 623 3745
   Email: [email-masked], [email-masked]

Atkins                   Expires March 06, 2015                 [Page 9]

---

From: Werner Koch <[email-masked]>
Date: Mon, 08 Sep 2014 15:43:36 +0200

>        (sub)packet per our conversation

Fine with me.

Salam-Shalom,

   Werner

---

From: Derek Atkins <[email-masked]>
Date: Mon, 08 Sep 2014 10:59:56 -0400

>>        (sub)packet per our conversation

Thanks!  Now I'm just waiting for input from David Leon Gil who wanted
to make some stylistic comments.

I've got another draft that I'm ready to submit shortly on encoding
Algebraic Eraser public keys.  I'll send that out for review later
today.

Thanks!!

-derek

---

From: "Daniel A. Nagy" <[email-masked]>
Date: Tue, 09 Sep 2014 15:34:04 +0200

Question:

Does this specification allow for signature/certification keys without
user ID and self-certification? I am a bit confused with the wording.
Please indicate in your answer which section allows (or prohibits) such
keys. Maybe, we could make it more explicit?

Regards,

Daniel

On 09/02/2014 09:44 PM, Derek Atkins wrote:
> _______________________________________________
> openpgp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/openpgp
>

---

From: Derek Atkins <[email-masked]>
Date: Tue, 09 Sep 2014 10:30:04 -0400

"Daniel A. Nagy" <[email-masked]> writes:

> user ID and self-certification? 

Yes, it is allowed.

>    I am a bit confused with the wording.

Section 2 allows it through the definition of the "Augmented v4 device
certificate".  Wording suggestions to make it more clear are welcome.  I
suppose your confusion is my use of the word "can" throughout that
section?

-derek

---

From: "Daniel A. Nagy" <[email-masked]>
Date: Fri, 12 Sep 2014 14:37:27 +0200

Thank you!

> suppose your confusion is my use of the word "can" throughout that

I got confused by this:

"A primary key capable of making signatures SHOULD be accompanied by
   either a certification signature (on a User ID or User Attribute) or
   a signature directly on the key.
...
It MAY accept public keys without an
   accompanying signature."

Basically, it says that signature-capable primary keys without
certification are not really proper, but sufficiently liberal
implementation may still accept them.

Now, the only thing a self-certification directly on the key proves is
that the public key is not bogus; it does, indeed, have a private
counterpart, right?

Regards,

Daniel

---

From: "Derek Atkins" <[email-masked]>
Date: Fri, 12 Sep 2014 09:17:07 -0400

Hi,

> implementation may still accept them.

Correct.  Do I need to reword that or add something to make that more clear?

> that the public key is not bogus; it does, indeed, have a private

That and a self-assertion of any particular notations in the signature.

Thanks,

-derek

---

From: "Daniel A. Nagy" <[email-masked]>
Date: Mon, 15 Sep 2014 10:55:39 +0200

Hi,

> Correct.  Do I need to reword that or add something to make that more clear?

Not necessarily. Perhaps reordering the sentences (and changing
referring pronouns accordingly) so that these two statements would be
right after one another would make it easier to understand.

> That and a self-assertion of any particular notations in the signature.

Right. Thanks!

---

From: Derek Atkins <[email-masked]>
Date: Mon, 15 Sep 2014 11:36:22 -0400

Hi,

> right after one another would make it easier to understand.

How about if I split it up into two paragraphs and reorder/reword a bit:

  A primary key capable of making signatures SHOULD be accompanied by
  either a certification signature (on a User ID or User Attribute) or a
  signature directly on the key.

  Implementations MUST accept encryption-only primary keys without a
  signature.  It also MUST allow importing any key accompanied either by
  a certification signature or a signature on itself.  It MAY accept
  signature-capable primary keys without an accompanying signature.

-derek