On Mon, Mar 4, 2019 at 3:38 PM Derek Atkins <derek(_at_)ihtfp(_dot_)com> wrote:
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."
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.
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.
I support dropping the requirement of a UserID or UserAttribute packet.
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.
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?
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.
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.
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
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp