Subject: [openpgp] Device Certificates for RFC4880bis

From: Derek Atkins <[email-masked]>
Date: Thu, 11 Feb 2016 16:43:47 -0500

Hi,

Over the past year or so I've posted several versions of
draft-atkins-openpgp-device-certificates.  It seemed to have general
approval among the crowd and I received many good comments and suggested
improvements.  Then the working group opened up again and we started
working on 4880bis.  To that end, I took it upon myself to integrate the
device-certificates into a patch to 4880bis markdown instead of leaving
it as a standalone document.

Please see the attached patch.

-derek

>From ce8b2bf371348340df22c1f73f29cff2acf32c70 Mon Sep 17 00:00:00 2001
From: Derek Atkins <[email-masked]>
Date: Thu, 11 Feb 2016 16:35:20 -0500
Subject: [PATCH] Integrate Device-Certificate Draft

---
 middle.mkd | 196 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++---
 1 file changed, 188 insertions(+), 8 deletions(-)

diff --git a/middle.mkd b/middle.mkd
index 80c0a61..2b41bb1 100644
--- a/middle.mkd
+++ b/middle.mkd
@@ -1317,6 +1317,75 @@ addresses.
 If there is a critical notation, the criticality applies to that
 specific notation and not to notations in general.
 
+The following subsections define a set of standard notations.
+
+##### {5.2.3.16.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).
+
+##### {5.2.3.16.2} The 'make' Notation
+
+This notation defines the product make.  It is a free form string.
+
+##### {5.2.3.16.3} The 'model' Notation
+
+This notation defines the product model name/number.  It is a free form string.
+
+##### {5.2.3.16.4} The 'prodid' Notation
+
+This notation contains the product identifier.  It is a free form string.
+
+##### {5.2.3.16.5} The 'pvers' 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.
+
+##### {5.2.3.16.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.
+
+##### {5.2.3.16.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.
+
+##### {5.2.3.16.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).
+
+##### {5.2.3.16.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
+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:
+* A single byte specifying the length of the name of the hashed data
+* A UTF-8 string of the name of the hashed data
+* A single byte specifying the hash algorithm (see section 9.4)
+* 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.2.3.17} Key Server Preferences
 
 (N octets of flags)
@@ -2123,10 +2192,16 @@ The header consists of:
 
 and is followed by the subpacket specific data.
 
-The only currently defined subpacket type is 1, signifying an
-image.  An implementation SHOULD ignore any subpacket of a type that it
-does not recognize.  Subpacket types 100 through 110 are reserved for
-private or experimental use.
+The following table lists the currently known subpackets:
+
+     Type  Attribute Subpacket
+  -------  ---------------------------------------------------------
+        1  Image Attribute Subpacket
+    [TBD1] User ID Attribute Subpacket
+  100-110  Private/Experimental Use
+
+An implementation SHOULD ignore any subpacket of a type that it
+does not recognize.
 
 ### {5.12.1} The Image Attribute Subpacket
 
@@ -2159,6 +2234,22 @@ examination of the image data if it is unable to handle a particular
 version of the image header or if a specified encoding format value is
 not recognized.
 
+### {5.12.2} User ID Attribute Subpacket
+
+A User ID Attribute subpacket has 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 using OpenPGP for device certificates, it may just be the
+device identifier.  The packet length in the header specifies the
+length of the User ID.
+
+Because User Attribute subpackets can be used anywhere a User ID
+packet can be used, implementations MAY choose to trust a signed User
+Attribute subpacket that includes a User ID Attribute subpacket.
+
 ## {5.13} Sym. Encrypted Integrity Protected Data Packet (Tag 18)
 
 The Symmetrically Encrypted Integrity Protected Data packet is a
@@ -2897,6 +2988,13 @@ defining specification.  The initial values for this registry can be
 found in Section 5.12.  Adding a new User Attribute type MUST be done
 through the IETF CONSENSUS method, as described in [](#RFC2434).
 
+This document requests that IANA register the User ID Attribute Type
+found in Section 5.12.2:
+
+  Value   Attribute    Reference
+  -----   ---------    ----------
+  TBD1    User ID      This Document Section 5.12
+
 ### {10.2.1.1} Image Format Subpacket Types
 
 Within User Attribute packets, there is an extensible mechanism for
@@ -2934,6 +3032,28 @@ registry can be found in Section 5.2.3.16.  Adding a new Signature
 Notation Data subpacket MUST be done through the EXPERT REVIEW method,
 as described in [](#RFC2434).
 
+This document requests IANA register the following Signature
+Notatation Data types:
+
+   Allowed Values   Name     Type               Reference
+   --------------   -------  ------------       ----------------
+   Any String       manu     Manufacturer Name  This Doc Section 5.2.3.16.1
+   Any String       make     Product Make       This Doc Section 5.2.3.16.2
+   Any String       model    Product Model      This Doc Section 5.2.3.16.3
+   Any String       prodid   Product ID         This Doc Section 5.2.3.16.4
+   Any String       pvers    Product Version    This Doc Section 5.2.3.16.5
+   Any String       lot      Product Lot Number This Doc Section 5.2.3.16.6
+   Decimal Integer  qty      Package Quantity   This Doc Section 5.2.3.16.7
+     String
+   A geo: URI       loc      Current Geo-       This Doc Section 5.2.3.16.8
+     without the             location
+     "geo:"                  Latitude/Longitude
+   A geo: URI       dest     Destination Geo-   This Doc Section 5.2.3.16.8
+     without the             location
+     "geo:"                  Latitude/Longitude
+   Hash Notation    hash     The Hash of        This Doc Section 5.2.3.16.9
+     data                    external data
+
 #### {10.2.2.2} Key Server Preference Extensions
 
 OpenPGP signatures contain a mechanism for preferences to be specified
@@ -3059,7 +3179,7 @@ transferable public key are as follows:
 
   - Zero or more revocation signatures
 
-  - One or more User ID packets
+  - Zero or more User ID packets
 
   - After each User ID packet, zero or more Signature packets
     (certifications)
@@ -3198,7 +3318,6 @@ of the primary key.
     Primary-Key
        [Revocation Self Signature]
        [Direct Key Signature...]
-        User ID [Signature ...]
        [User ID [Signature ...] ...]
        [User Attribute [Signature ...] ...]
        [[Subkey [Binding-Signature-Revocation]
@@ -3213,8 +3332,19 @@ embedded primary key binding signature.
 In the above diagram, if the binding signature of a subkey has been
 revoked, the revoked key may be removed, leaving only one key.
 
-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
+In a V4 key, the primary key SHOULD be a key capable of
+certification.  There are cases, such as device certificates, where
+the primary key may not be 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.
+
+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.
+
+The subkeys may be keys of any other type.  There may be
 other constructions of V4 keys, too.  For example, there may be a
 single- key RSA key in V4 format, a DSA primary key with an RSA
 encryption key, or RSA primary key with an Elgamal subkey, etc.
@@ -4135,6 +4265,56 @@ SHOULD be rejected.
     seek to eliminate any measurable distinction between the ECC point
     addition and doubling operations.
 
+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 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.
+
+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.
+
 
 # Compatibility Profiles
 
-- 
2.5.0

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

---

From: Werner Koch <[email-masked]>
Date: Fri, 12 Feb 2016 09:11:50 +0100

> +signature-capable primary keys without an accompanying signature.

Why do you want a MUST accept/import here?  I think it would be better
to relax it to SHOULD so that implementations which do not want to
support operations on device certifications can still claim to be
OpenPGP compliant.  Having a need to support encryption only primary
keys does not make sense to all implementations.

Shalom-Salam,

   Werner

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

---

From: "Derek Atkins" <[email-masked]>
Date: Fri, 12 Feb 2016 07:31:55 -0500

> keys does not make sense to all implementations.

OOPS.  You are absolutely correct.  This was an oversight when I did a
cut-and-paste from my previous document.  The MUST made sense when device
certificates were a standalone document, but you're right that this should
be a SHOULD now that it's integrated into 4880bis.

Would you like an updated patch?  Or just change it in your copy?

Thanks,

-derek

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

---

From: Werner Koch <[email-masked]>
Date: Fri, 12 Feb 2016 16:44:34 +0100

> Would you like an updated patch?  Or just change it in your copy?

I can change that easily.

@list: Okay to add Derek's "Device Certificates for RFC4880bis" so that
it will be part of the first RFC-4880bis I-D?

Shalom-Salam,

   Werner

---

From: Werner Koch <[email-masked]>
Date: Thu, 18 Feb 2016 11:08:55 +0100

> it will be part of the first RFC-4880bis I-D?

Silence means agreement ;-).

  commit 3c3120a02d7b44621f3a7361ef75bdb7b7ade259
  Author: Derek Atkins <[email-masked]>
  Date:   Thu Feb 11 16:35:20 2016 -0500

    Integrate Device-Certificate Draft
    
    Changes from Derek's original draft (wk):
     - Change two MUST to SHOULD as agreed upon on the ML.
     - Remove new section numbers.  The section numbers in curly braces
       are only used to refer the RFC-4880 section numbers.

See <http://git.gnupg.org/cgi-bin/gitweb.cgi?p=people/wk/rfc4880bis.git>

Let me know if you want me to provide a formatted draft.

Shalom-Salam,

   Werner