Re: [openpgp] User ID Attribute Subpacket

["Derek Atkins" <[e-mail]>]

On Mon, March 4, 2019 10:02 am, Justus Winter wrote:
>
> 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.

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.

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

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.

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

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

What don't you understand about it?

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

-derek

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