Hi,
Wiktor Kwapisiewicz
<wiktor=40metacode(_dot_)biz(_at_)dmarc(_dot_)ietf(_dot_)org> writes:
Hi Justus,
On 20.02.2019 11:30, Justus Winter wrote:
Based on these observations I challenge the claim that the proposed
subpacket adds any value to the standard, and propose to remove it.
I agree.
Obviously I don't ;)
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.
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 'manu@device-certs.example').
That would keep OpenPGP as small as possible without parts that most
implementations would basically omit.
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.
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)
Cool. But not useful to me ;)
-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