Subject: [openpgp] User ID Attribute Subpacket

From: Justus Winter <[email-masked]>
Date: Wed, 20 Feb 2019 10:39:29 +0100

Hello,

draft 6 of RFC4880bis proposes a "User ID Attribute Subpacket", but it
does not motivate that addition in any way.  What is the purpose of
it, and what is the advantage over using the userid packet?

Thanks,
Justus

---

From: Wiktor Kwapisiewicz <[email-masked]>
Date: Wed, 20 Feb 2019 10:57:07 +0100

Hi Justus,

> it, and what is the advantage over using the userid packet?

 From what I can see it comes from 
"draft-atkins-openpgp-device-certificates" that was merged in to RFC4880bis.

For details see this thread:

https://mailarchive.ietf.org/arch/msg/openpgp/Ma3P-yM2vTrfx2_Pqf_sq31SruY

(Message-ID: <[email-masked]>)

Kind regards,
Wiktor

-- 
https://metacode.biz/@wiktor

---

From: Justus Winter <[email-masked]>
Date: Wed, 20 Feb 2019 11:30:56 +0100

> (Message-ID: <[email-masked]>)

Interesting.  I skimmed the thread trying to introduce a more structured
kind of user ids [0], but I'm still not convinced that the "User ID
Attribute Subpacket" as proposed in -06 adds any value over the user id
packet.

0: id:[email-masked]

For reference, here is the proposed attribute:

> 5.13.2.  User ID Attribute Subpacket
>
>    A User ID Attribute subpacket has type #[IANA -- assignment TBD1].
>
>    A User ID Attribute subpacket, just like a User ID packet, consists
>    of UTF-8 text that is intended to represent the name and email
>    address of the key holder.  By convention, it includes an RFC 2822
>    [RFC2822] mail name-addr, but there are no restrictions on its
>    content.  For devices using OpenPGP for device certificates, it may
>    just be the device identifier.  The packet length in the header
>    specifies the length of the User ID.
>
>    Because User Attribute subpackets can be used anywhere a User ID
>    packet can be used, implementations MAY choose to trust a signed User
>    Attribute subpacket that includes a User ID Attribute subpacket.

And this is the user id packet:

> 5.12.  User ID Packet (Tag 13)
>
>    A User ID packet consists of UTF-8 text that is intended to represent
>    the name and email address of the key holder.  By convention, it
>    includes an RFC 2822 [RFC2822] mail name-addr, but there are no
>    restrictions on its content.  The packet length in the header
>    specifies the length of the User ID.

As you can see, the text is almost identical, and the text for the
proposed subpacket even admits that it is just like a user id packet.

Furthermore, "[...] User Attribute packets are not a required part of
the OpenPGP standard [...]".

Based on these observations I challenge the claim that the proposed
subpacket adds any value to the standard, and propose to remove it.

Cheers,
Justus

---

From: Wiktor Kwapisiewicz <[email-masked]>
Date: Wed, 20 Feb 2019 11:39:33 +0100

Hi Justus,

> subpacket adds any value to the standard, and propose to remove it.

I agree.

Actually from my casual skimming of the device certifications draft I 
see most of the changes can be implemented over what is already in OpenPGP.

As you've said - User IDs are quite flexible [0] and the other change of 
device certifications - standard notations (that is notation names that 
doesn't contain "@") could just use regular notation names (e.g. 'manu' 
Notation could be [email-masked]').

That would keep OpenPGP as small as possible without parts that most 
implementations would basically omit.

Having said that I wasn't around when it was conceived so probably there 
is some rationale for its inclusion.

Kind regards,
Wiktor

[0] I did experiment with putting URIs in User IDs for extended info 
(https://github.com/wiktor-k/distributed-ids#distributed-ids)

---

From: Derek Atkins <[email-masked]>
Date: Wed, 20 Feb 2019 11:08:39 -0500

Hi,

>> subpacket adds any value to the standard, and propose to remove it.

Obviously I don't ;)

> see most of the changes can be implemented over what is already in

*CAN*, yes, but there are reasons to minimize.  See below.

> As you've said - User IDs are quite flexible [0] and the other change
> of device certifications - standard notations (that is notation names
> that doesn't contain "@") could just use regular notation names
> (e.g. 'manu' Notation could be [email-masked]').
>

Yes, most of what was in the draft could have been implemented using
standard OpenPGP mechanisms.  Indeed, the device-certs draft was not
intended at the time to be incorporated into 4880bis but rather to be a
standalone document that lived along side it.

The main purpose was to enable the smallest certificate possible, but
really the purpose of the device-certs draft was multi-fold:

1) Allow a PGP Key Certificate without a signature key.  The idea here
   is that some small devices may only have a key-agreement key
   available so may not be able to create a signature.  However, 4880
   did not allow this configuration and required a top-level signature
   key and relegated other keys to sub-usage.

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

3) Yes, we could have just used FQDN-based notations, but then we're
   litterally adding at least 13 bytes PER NOTATION.  Given the number
   of notations in use, that was adding on the order of 65-130 BYTES to
   the certificate, or about 10-15%!

> Having said that I wasn't around when it was conceived so probably
> there is some rationale for its inclusion.

Indeed.  Honestly, at the time the intent was to progress the
device-certs draft on its own and register those notations that way.
But then the WG stalled, and Werner kindly incorporated those
definitions into 4880bis.

Still, adding these to 4880bis does not add significant complexity to
the draft but DOES make a marked difference in its usability.  Please do
not remove these improvements.

> (https://github.com/wiktor-k/distributed-ids#distributed-ids)

Cool.  But not useful to me ;)

-derek

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

---

From: Wiktor Kwapisiewicz <[email-masked]>
Date: Wed, 20 Feb 2019 20:23:07 +0100

Hi Derek,

>     key and relegated other keys to sub-usage.

By "signature key" do you mean "certification key"?

Because as far as I can see RFC 4880 definitely allows having the 
primary key being certification only:

"In a V4 key, the primary key MUST be a key capable of certification" [0]

[0]: https://tools.ietf.org/html/rfc4880#section-12.1

(I'm using C-only primary key, it's available via WKD).

>     signature, this seemed the best way to do it.

What would you store in these User ID Attributes that would not be 
possible in regular User IDs?

>     the certificate, or about 10-15%!

This depends on the FQDN, e.g. using [email-masked]' adds only 10 bytes, 
and there are shorter domains. This can be coupled with shortening of 
the keys (e.g. 'prodid' -> 'p') although I admit they look shortened 
already :)

Are all of them needed and used at the same time?

> not remove these improvements.

I don't know what are the criteria for inclusion but when reading the 
rest of the RFC device-certs strike me as something with a narrow focus. 
A stark contrast to otherwise generic and versatile constructs.

 > *CAN*, yes, but there are reasons to minimize.  See below.

Could you share what's the rationale for keys being minimal? From what I 
have seen it has something to do with devices of limited memory but I'm 
eager to know details, are there any implementations of device-certs in 
the wild?

For example what would the User ID Attribute look like?

> Cool.  But not useful to me ;)

Hard to recommend something if I don't know what you're after :)

Kind regards,
Wiktor

---

From: "Derek Atkins" <[email-masked]>
Date: Thu, 21 Feb 2019 09:40:45 -0500

Hi Wiktor,

> Hi Derek,
[snip]
> By "signature key" do you mean "certification key"?

Yes..

> (I'm using C-only primary key, it's available via WKD).

I think you misunderstood my issue.  My issue is exactly what you state
here, that the primary key MUST be a key capable of certification.  That's
exactly what I DO NOT want.  The keys I'm using are NOT capable of
certification, but I still want them to be the primary key.  Hence, I
needed to modify that requirement.

> possible in regular User IDs?

This was from 3-4 years ago, so like I said, memory hazy, and project long
turned over to others..  But my recollection was not just about what was
being stored in the UserID,, but what ELSE was being stored in the same
signature.  Like I said above, my recollection is that I could not store
both a UserID *AND* additional attributes at the same time, so the best
workaround was to add a UserID Attribute so I could.

In short, the specification did not allow us to do what we wanted to do,
which is why I suggested this change.  I do not recall exactly what it
was, and frankly I don't have the time to go dig up the project and see
how we were using it.

> the keys (e.g. 'prodid' -> 'p') although I admit they look shortened

This is not for ihtfp.com -- The 13 bytes is the actual number.  I chose
the registrations to be as short as reasonable.  I didn't want to use 'p'
because I knew in 5-10 years someone would come along and go "what the F
is 'p' for?".  Whereas "prodid" is a bit more self-descriptive.

> Are all of them needed and used at the same time?

Yes.  Hence my 10-15% increase in size!  Indeed, some of them are even
used more than once in a single certificate.

> A stark contrast to otherwise generic and versatile constructs.

True -- which is why it was originally proposed as a separate document. 
I'm fine with it continuing to be a separate document if that's the desire
of the group, but I DO want to make these IANA registrations and I DO want
to make the change to allow for a non-certification primary key.  I'm fine
either way, either the registrations being in 4880bis or resurrecting the
device-certs draft and progressing that alongside 4880bis.

The process just got muddied when the WG was shut down.

> eager to know details, are there any implementations of device-certs in

This is exactly it -- we are storing a certificate on an NFC (or even UHF
RFID) chip that would be presented to a verifier -- and then the chip
would perform a key exchange using the key in the certificate for a
proof-of-possession authentication.  Every byte matters, which is exactly
why we went with OpenPGP and not X509!

> For example what would the User ID Attribute look like?

See above; I don't recall -- I'd have to go dig it up from this 3-4 year
old project.  However, it wasn't the content but the co-existence that was
the issue IIRC.

> Hard to recommend something if I don't know what you're after :)

Sure, but I'm not looking for you to recommend something.  :)

Thanks,

-derek

---

From: Wiktor Kwapisiewicz <[email-masked]>
Date: Thu, 21 Feb 2019 15:46:31 +0100

Hi Derek,

> why we went with OpenPGP and not X509!

Sounds interesting, too bad it's not public, I'd gladly check out the 
implementation details :)

Thanks for taking the time to describe it all!

Kind regards,
Wiktor

---

From: "Derek Atkins" <[email-masked]>
Date: Thu, 21 Feb 2019 10:22:29 -0500

Hi,

> implementation details :)

I will see what I can do about that.  But no promises.  :-)

> Thanks for taking the time to describe it all!

You're welcome.  Thanks for listening :)

-derek