[Top] [All Lists]

Re: [openpgp] User ID Attribute Subpacket

2019-02-20 13:23:36
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]


(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 '' 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

Cool.  But not useful to me ;)

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

Kind regards,


openpgp mailing list