Re: [openpgp] User ID Attribute Subpacket

[Justus Winter <[e-mail]>]

On Mon, Mar 4, 2019 at 3:38 PM Derek Atkins <[e-mail]> wrote:
> On Mon, March 4, 2019 5:38 am, Justus Winter wrote:
> > Sorry, this makes no sense at all.
> >
> > On Wed, Feb 20, 2019 at 5:08 PM Derek Atkins <[e-mail]> wrote:
> >> 2) The reason for the User ID Attribute subpacket was that we wanted to
> >>    have multiple Attribute subpackets included in the certificate in a
> >>    primary signature, but this was not possible with 4880.  My memory is
> >
> > User Attribute subpackets are not in the signature, but in the User
> > Attribute
> > packet.
>
> Please re-read what I wrote.  Note that when I say "in the signature" I
> mean "protected by the signature."  This could also be read as "included
> in the hash that is signed."

Given that in OpenPGP, Signatures have Subpackets, and your proposal
is also about adding notations, which is stored in said subpackets, "in the
signatures" is too ambiguous to discuss the matter.

> Also, if you read draft-atkins-openpgp-device-certificates (even though it
> expired), it explains this in gory detail:
>
>    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] ...]
>
> The issue at hand was that you cannot make a single signature that covers
> both a User ID packet and a User Attribute packet.  Moreover, the format
> REQUIRED a User ID packet, which meant that if you wanted to sign a bunch
> of User Attributes you HAD to have TWO signatures in the certificate.

I support dropping the requirement of a UserID or UserAttribute packet.

> My goal was to reduce that to a SINGLE signature by allowing the User ID
> to exist as a User Attribute Subpacket.  This would let you use the User
> Attribute signature type and include a User ID (attribute subpacket) along
> with additional attribute subpackets all protected by a single signature.
>
> > The only thing that having UserID subpackets for the User Attribute packet
> > is that you can have multiple userids bound by one binding signature.  But
> > that is a feature that I dislike, because then we can no longer strip down
> > TPKs so that they only include a subset of the userids, which can enhance
> > the privacy of our users.  This is important for pEp, Autocrypt, and
> > Hagrid.
>
> It is not the only thing -- see above.  It lets you bind a User ID and
> additional attributes with a single signature, which is the primary goal.

I'm still confused by what you mean by "additional attributes".  Your proposal
states:

   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.

So your usecase is to have a UserAttribute packet, with a single UserID
subpacket, and one or more Image subpackets, bound by a single signature.
Is that correct?

> Note that you can already have multiple UserIDs on a key.  If your main
> gripe is that you could have multiple User ID Attribute Subpackets bound
> by the same signature, I am fine if you want to limit that and say that an
> implementation MUST NOT (or SHOULD NOT) include more than one in a single
> Attribute packet.

My gripe is that UserID subpackets seem redundant, therefore needlessly
complicating the standard, and neither this discussion, your draft, nor the
language that ended up in draft-06 properly motivates the redundancy.

> 1) I want to enable a certificate where the primary key cannot sign

Fine with me.

> 2) I want to have a single binding signature that binds a User ID AND
> additional attributes

This is what I don't understand.

> 3) I want to enable a reduction in space consumption due to a bunch of
> notations that we use
> 4) I introduced some additional notation types which we use (and should be
> useful to others)

Fine with me.

Thanks,
Justus