Re: [openpgp] User ID Attribute Subpacket
"Derek Atkins" <derek@ihtfp.com> Thu, 21 February 2019 14:41 UTC
Return-Path: <derek@ihtfp.com>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB50C12F18C for <openpgp@ietfa.amsl.com>; Thu, 21 Feb 2019 06:41:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.689
X-Spam-Level:
X-Spam-Status: No, score=-1.689 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=ihtfp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rHshjF3m5VCh for <openpgp@ietfa.amsl.com>; Thu, 21 Feb 2019 06:40:57 -0800 (PST)
Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DEAA12D7F8 for <openpgp@ietf.org>; Thu, 21 Feb 2019 06:40:57 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 55FCCE2042; Thu, 21 Feb 2019 09:40:55 -0500 (EST)
Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 13927-02; Thu, 21 Feb 2019 09:40:45 -0500 (EST)
Received: by mail2.ihtfp.org (Postfix, from userid 48) id 9C3CAE2044; Thu, 21 Feb 2019 09:40:45 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1550760045; bh=7OrUhAr3z4dIfNxAMzT/TIB5zf2hzsg0BDLoCtb3hxU=; h=In-Reply-To:References:Date:Subject:From:To:Cc; b=DLogMStUQ0HFPYvnPbN641WAw2gRo4r4eBJi2N2E+FNf+Dwj/ppcFprHUo//K9Ikm 5v0pxi/Vu+hDIXCvH2boQLCEJ81rmD1gAszVNyE0CXtoAwyb1sVgw/16qqyO3QO26m cQDctoJwWv5qdF+4mOrUT9tJGKSN0ugWJ0SPLc9Q=
Received: from 99.46.190.172 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Thu, 21 Feb 2019 09:40:45 -0500
Message-ID: <1741f774aa08d0df4a3ca481339bb733.squirrel@mail2.ihtfp.org>
In-Reply-To: <ba6a5323-965f-d468-5e02-3d1d0cd669d0@metacode.biz>
References: <CA+t5QVsS871zG30dhW_GZ9ALq8bDASD-D3p0YQp9iGJEXUddmA@mail.gmail.com> <d34d0310-2851-dc4b-b5b3-79c7ec530e73@metacode.biz> <CA+t5QVsTATuw4pRhEdMOogh3YA237Rd2zOzzX3B3tZL04tfE0w@mail.gmail.com> <d7bf74c8-8415-da7a-4bf9-5bd455fb657e@metacode.biz> <sjmwolu30jc.fsf@securerf.ihtfp.org> <ba6a5323-965f-d468-5e02-3d1d0cd669d0@metacode.biz>
Date: Thu, 21 Feb 2019 09:40:45 -0500
From: Derek Atkins <derek@ihtfp.com>
To: Wiktor Kwapisiewicz <wiktor=40metacode.biz@dmarc.ietf.org>
Cc: Derek Atkins <derek@ihtfp.com>, openpgp@ietf.org, Justus Winter <justuswinter@gmail.com>
User-Agent: SquirrelMail/1.4.22-14.fc20
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Virus-Scanned: Maia Mailguard 1.0.2a
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/02vKiqj0hK_Oi1TJROmXLMqLbZQ>
Subject: Re: [openpgp] User ID Attribute Subpacket
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/openpgp/>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Feb 2019 14:41:01 -0000
Hi Wiktor, On Wed, February 20, 2019 2:23 pm, Wiktor Kwapisiewicz wrote: > Hi Derek, > [snip] >> 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"? Yes.. > 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). 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. >> 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? 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. >> 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 :) 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. >>> 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. 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. > 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? 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. >>> [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 :) Sure, but I'm not looking for you to recommend something. :) Thanks, > Kind regards, > Wiktor -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant
- [openpgp] User ID Attribute Subpacket Justus Winter
- Re: [openpgp] User ID Attribute Subpacket Wiktor Kwapisiewicz
- Re: [openpgp] User ID Attribute Subpacket Justus Winter
- Re: [openpgp] User ID Attribute Subpacket Wiktor Kwapisiewicz
- Re: [openpgp] User ID Attribute Subpacket Derek Atkins
- Re: [openpgp] User ID Attribute Subpacket Wiktor Kwapisiewicz
- Re: [openpgp] User ID Attribute Subpacket Derek Atkins
- Re: [openpgp] User ID Attribute Subpacket Wiktor Kwapisiewicz
- Re: [openpgp] User ID Attribute Subpacket Derek Atkins
- Re: [openpgp] User ID Attribute Subpacket Justus Winter
- Re: [openpgp] User ID Attribute Subpacket Derek Atkins
- Re: [openpgp] User ID Attribute Subpacket Justus Winter
- Re: [openpgp] User ID Attribute Subpacket Derek Atkins
- Re: [openpgp] User ID Attribute Subpacket Justus Winter
- Re: [openpgp] User ID Attribute Subpacket Peter Pentchev
- Re: [openpgp] User ID Attribute Subpacket Justus Winter
- Re: [openpgp] User ID Attribute Subpacket Werner Koch