Re: [openpgp] User ID Attribute Subpacket

[Wiktor Kwapisiewicz <[e-mail]>]

Hi Derek,

On 20.02.2019 17:08, Derek Atkins wrote:
> 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.

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

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

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

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

This depends on the FQDN, e.g. using '@ihtfp.com' 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?

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

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.

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

>> [0] I did experiment with putting URIs in User IDs for extended info
>> (https://github.com/wiktor-k/distributed-ids#distributed-ids)
> 
> Cool.  But not useful to me ;)

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

Kind regards,
Wiktor

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