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
derek(_at_)ihtfp(_dot_)com www.ihtfp.com
Computer and Internet Security Consultant
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp