Re: [openpgp] User ID Attribute Subpacket

[Justus Winter <[e-mail]>]

On Mon, Mar 4, 2019 at 4:35 PM Derek Atkins <[e-mail]> wrote:
> On Mon, March 4, 2019 10:02 am, Justus Winter wrote:
> > 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?
>
> 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.

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.

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

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