Hi,
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 <derek(_at_)ihtfp(_dot_)com>
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."
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 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.
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.
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.
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
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