Subject: Re: [openpgp] User ID Attribute Subpacket

From: Justus Winter <[email-masked]>
Date: Mon, 4 Mar 2019 11:38:04 +0100

Sorry, this makes no sense at all.

On Wed, Feb 20, 2019 at 5:08 PM Derek Atkins <[email-masked]> 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.

Your other additions, specifying notation data with keys like "charset" are
Signature subpackets, and *are* part of signatures.

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.

>    hazy on what the exact issue was, but IIRC you could EITHER have a
>    UserID packet OR a set of Attribute packets, but not both.  Because I
>    wanted both a UserID *AND* additional attributes in a single
>    signature, this seemed the best way to do it.

Given that you, the person who requested this addition, can no longer make
a solid case for it, I request for the UserID subpacket to be removed.

---

From: "Derek Atkins" <[email-masked]>
Date: Mon, 4 Mar 2019 09:38:05 -0500

Hi,

> User Attribute subpackets are not in the signature, but in the User

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

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.

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 privacy of our users.  This is important for pEp, Autocrypt, and

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.

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.

> a solid case for it, I request for the UserID subpacket to be removed.

I said I was hazy -- this was proposed FIVE YEARS ago, so it's taken me a
while to swap those issues back into my brain.  So let me restate the
issues as to why I did this and request it:

1) I want to enable a certificate where the primary key cannot sign
2) I want to have a single binding signature that binds a User ID AND
additional attributes
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)

The User ID Attribute is really part of #2.

Thanks for your consideration.

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

---

From: Justus Winter <[email-masked]>
Date: Mon, 4 Mar 2019 16:02:48 +0100

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

> of User Attributes you HAD to have TWO signatures in the certificate.

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

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

> implementation MUST NOT (or SHOULD NOT) include more than one in a single

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

This is what I don't understand.

> 4) I introduced some additional notation types which we use (and should be

Fine with me.

Thanks,
Justus

---

From: "Derek Atkins" <[email-masked]>
Date: Mon, 4 Mar 2019 10:35:37 -0500

> signatures" is too ambiguous to discuss the matter.

Fair enough.  In my mind (having been involved in PGP since 1992), it's
pretty obvious, but I can understand your confusion.  I will try to be a
bit more concise.

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

The User Attribute packet was already optional -- it was only the UserID
packet that was required.

> subpacket, and one or more Image subpackets, bound by a single signature.

I'm confused by your confusion.  What part of "additional attributes" do
you not understand?  I'm not trying to be a PITA here, but I'm honestly
not understanding your confusion about what is meant here by what I said.

But to answer your question, yes, I want to have a UserID and an Image
with one binding signature -- and possibly additional future attribute
subpackets, too.

> language that ended up in draft-06 properly motivates the redundancy.

It's not redundant, because you cannot, in 4880, have a userid + image
bound by a single signature.  It only SEEMS redundant to you because they
are effectively performing similar operations, but as it currently stands
you would have a UserID + signature, and then an Image + signature.  So
there is no way to do { UserID + Image } + signature using what's
available in 4880.  Therefore, it is not redundant.

I should note that, having implemented this, the additional code to handle
this is actually quite small!  You can actually reuse a great deal, so
really it's just a protocol number and an additional branch.

> This is what I don't understand.

What don't you understand about it?

-derek

---

From: Justus Winter <[email-masked]>
Date: Mon, 4 Mar 2019 17:26:36 +0100

> with one binding signature -- and possibly additional future attribute

Well, your proposal is about adding some notation data, and I did not imagine
you wanting to burden your embedded devices (for which a mere URI as the
notation data's key is too much) with images.

> really it's just a protocol number and an additional branch.

Is it though?

At this point I need to stress that while such an addition seems trivial, lot's
of these trivial details add up and contribute to the complexity of
the protocol.
Therefore, every addition to it should face scrutiny, even more those that
introduce redundancy.

And it is not just a matter of implementation, but of semantics.

Say you parse a TPK into some data structure, and you have a way to
iterate over the user ids and their binding signatures.  Now, for consistency,
we want to include your user ids.  However, the iterator now has to deal with
two different ways of representing the same thing, and verification of the
corresponding binding signatures is no longer uniform.

So from my perspective, adding subpacket-based user ids has a high cost.
And now that I understand your use case, I wonder if there isn't an easier way
to do what you want, without complicating the standard.

For example, you could store the image as notation data in the binding
signature of a user id.  Seeing that you use notations for other data,
implementing this should be straight forward for you.

Speaking of implementations, GnuPG does not support the user id attribute.
Is there an publicly available implementation that does?

Thanks,
Justus

---

From: Peter Pentchev <[email-masked]>
Date: Tue, 5 Mar 2019 10:14:00 +0200

> notation data's key is too much) with images.

I believe that by "additional attributes" Derek also means "additional
attribute types" - not just images, but other, not yet defined, types of
attributes, in which to keep additional data.  This might be what you're
missing from his explanations - he wants to have a packet that contains
a user ID and *other* attributes, not necessarily images, that might not
take too much space.

G'luck,
Peter

-- 
Peter Pentchev  roam@{ringlet.net,debian.org,FreeBSD.org} [email-masked]
PGP key:        http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13

---

From: Justus Winter <[email-masked]>
Date: Tue, 5 Mar 2019 13:56:35 +0100

> a user ID and *other* attributes, not necessarily images, that might not

If it is not about images, then the case for creating a new UserAttribute
subpacket is even weaker, because Derek's proposal already includes
some predefined keys for notation data.

I don't see why these "additional attributes" can not be included in the
Signature packet as notations.

---

From: Werner Koch <[email-masked]>
Date: Tue, 05 Mar 2019 11:21:09 +0100

Hi!

[The mail got stuck somewhere in the IETF mail system - resending]

> with one binding signature -- and possibly additional future attribute

May I suggest to add a sample of such a packet to appendix A to avoid
confusion by future implementation work?

> really it's just a protocol number and an additional branch.

I concur (although I have not yet come around to implement this in gpg).

Salam-Shalom,

   Werner

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