Verify and store all relevant packets

Bug #1042050 reported by Casey Marshall
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
hockeypuck
Fix Released
Critical
Casey Marshall

Bug Description

Now that we've got the opaque packets parsing nicely, we need to store everything in the database for a given key, and validate what we can.

New tables will need to be added for all possible packet types. Signatures and signed packets should be validated to prevent someone from adding garbage to a key. This is the relevant part of RFC4880 we'll need to store:

11. Packet Composition

   OpenPGP packets are assembled into sequences in order to create
   messages and to transfer keys. Not all possible packet sequences are
   meaningful and correct. This section describes the rules for how
   packets should be placed into sequences.

11.1. Transferable Public Keys

   OpenPGP users may transfer public keys. The essential elements of a
   transferable public key are as follows:

     - One Public-Key packet

     - Zero or more revocation signatures

Callas, et al Standards Track [Page 67]

RFC 4880 OpenPGP Message Format November 2007

     - One or more User ID packets

     - After each User ID packet, zero or more Signature packets
       (certifications)

     - Zero or more User Attribute packets

     - After each User Attribute packet, zero or more Signature packets
       (certifications)

     - Zero or more Subkey packets

     - After each Subkey packet, one Signature packet, plus optionally a
       revocation

   The Public-Key packet occurs first. Each of the following User ID
   packets provides the identity of the owner of this public key. If
   there are multiple User ID packets, this corresponds to multiple
   means of identifying the same unique individual user; for example, a
   user may have more than one email address, and construct a User ID
   for each one.

   Immediately following each User ID packet, there are zero or more
   Signature packets. Each Signature packet is calculated on the
   immediately preceding User ID packet and the initial Public-Key
   packet. The signature serves to certify the corresponding public key
   and User ID. In effect, the signer is testifying to his or her
   belief that this public key belongs to the user identified by this
   User ID.

   Within the same section as the User ID packets, there are zero or
   more User Attribute packets. Like the User ID packets, a User
   Attribute packet is followed by zero or more Signature packets
   calculated on the immediately preceding User Attribute packet and the
   initial Public-Key packet.

   User Attribute packets and User ID packets may be freely intermixed
   in this section, so long as the signatures that follow them are
   maintained on the proper User Attribute or User ID packet.

   After the User ID packet or Attribute packet, there may be zero or
   more Subkey packets. In general, subkeys are provided in cases where
   the top-level public key is a signature-only key. However, any V4
   key may have subkeys, and the subkeys may be encryption-only keys,
   signature-only keys, or general-purpose keys. V3 keys MUST NOT have
   subkeys.

Callas, et al Standards Track [Page 68]

RFC 4880 OpenPGP Message Format November 2007

   Each Subkey packet MUST be followed by one Signature packet, which
   should be a subkey binding signature issued by the top-level key.
   For subkeys that can issue signatures, the subkey binding signature
   MUST contain an Embedded Signature subpacket with a primary key
   binding signature (0x19) issued by the subkey on the top-level key.

   Subkey and Key packets may each be followed by a revocation Signature
   packet to indicate that the key is revoked. Revocation signatures
   are only accepted if they are issued by the key itself, or by a key
   that is authorized to issue revocations via a Revocation Key
   subpacket in a self-signature by the top-level key.

   Transferable public-key packet sequences may be concatenated to allow
   transferring multiple public keys in one operation.

Casey Marshall (cmars)
Changed in hockeypuck:
assignee: nobody → Casey Marshall (cmars)
Casey Marshall (cmars)
Changed in hockeypuck:
status: Triaged → Fix Committed
Revision history for this message
Casey Marshall (cmars) wrote :

Went with hybrid packet-based approach.

Casey Marshall (cmars)
Changed in hockeypuck:
milestone: none → 0.1
status: Fix Committed → Fix Released
Revision history for this message
Casey Marshall (cmars) wrote :

Verification will be done separately in LP: #1044770

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.