From nobody Fri Jul 1 06:33:14 2016 Return-Path: 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 0530F12D5F7 for ; Fri, 1 Jul 2016 06:33:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 ZbkK4G5Nlf0v for ; Fri, 1 Jul 2016 06:33:10 -0700 (PDT) Received: from zucker2.schokokeks.org (zucker2.schokokeks.org [178.63.68.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7180B12D1DC for ; Fri, 1 Jul 2016 06:33:09 -0700 (PDT) Received: from pc1 ([::ffff:195.1.83.226]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 256bits, ECDHE-RSA-AES256-GCM-SHA384) by zucker.schokokeks.org with ESMTPSA; Fri, 01 Jul 2016 15:33:07 +0200 id 00000000000000F7.0000000057767113.0000608D Date: Fri, 1 Jul 2016 15:33:04 +0200 From: Hanno =?UTF-8?B?QsO2Y2s=?= To: IETF OpenPGP Message-ID: <20160701153304.332d2c95@pc1> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="=_zucker.schokokeks.org-24717-1467379988-0001-2" Archived-At: Subject: [openpgp] Can the OpenPGP vs. S/MIME situation be fixed? X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 13:33:13 -0000 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zucker.schokokeks.org-24717-1467379988-0001-2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Maybe this is a crazy idea, but I wanted to throw it into the discussion. IMHO a big problem with e-mail encryption is that there are two competing "official" standards: OpenPGP and S/MIME. Both are RFCs, so both have a kinda "official" IETF approval. I think it was a big mistake to create two competing standards in the first place, but that was back in the 90s. So we may ask if we want to live forever with this situation or if it can be fixed. One of the most common explanations for the two standards I hear is that S/MIME is the solution for business communications while OpenPGP is more for private users. This never made a lot of sense to me, because there are plenty of situations where "business" people may have to communicate with "private" people. And the requirements aren't any different. E-Mail encryption is supposed to ensure that no unauthorized people can read or manipulate your mail, that doesn't change whether you're using E-Mail for private or business communication. So essentially I think there is no rational case for competing standards. So the question is: Instead of making RFC4880bis a "new OpenPGP standard", could it instead be a successor of both OpenPGP and S/MIME? Maybe it needs a new name, maybe not. There seems to be an smime working group and there is still some activity, although the last RFC was published in 2009. Things would obivously have to be coordinated so that there is wide acceptance of the new standard. Technically it would probably mean to create a compatibility layer to be able to use both X.509 certificates and PGP keys to encrypt. But that shouldn't be too hard, as the keys itself are just numbers, the major difference is just the storage format. Maybe this is a crazy idea, but maybe this could also be a chance to fix one of the biggest mistakes in email encryption. --=20 Hanno B=C3=B6ck https://hboeck.de/ mail/jabber: hanno@hboeck.de GPG: BBB51E42 --=_zucker.schokokeks.org-24717-1467379988-0001-2 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJXdnEQAAoJEKWIAHK7tR5CgNgQAI6BDbK/CwXWD1Rc5AaBjBag o5k9u7CUCzigL7fy5QDZkiLou4Tjm6tDi0hM8RT2HFp2ppLftjY+6ioSG2/Q4s3D x5E+FPfEco7PpxQ9tIWabTguSzbIByDPDp4nnqJmCOvbk9NuRv2kHkD0nlgnTdec 1NzAmz4XQvwIm3qTUJFrcUBjjSQsV5lyUcXv6m//zTKyzq59mjCV+BNtHF1dh1uv IgNYMnQScYMXxwDLiD8rfGs+STq1smhhlJDwHHv0PM0ag7lt+BXPfUdg0Z4Y+c66 TTQyjTTpXmW3ev9FpQdzavc6LkwDbNRKpBNlx7xhIoKN3rHoAl9DMEJ3jEIMLT5/ 3PC+l25h6fxJ9neai09NILl8uC9YkAgTepRocHyRvDONYKn81Fvr+9V8YrvxM383 GgsXNQIq1Q/zj9xQ9irQyMt6NjQKv+Ul2PtOc7CjPWt2KL5tpePdNyxpx1ryFEQ5 Tn+LWkQiUNoveEwnayPPX8QwpCNIv/00jL/1zZmeHPgMV7NHmEB6IKjEEyTIQCm/ MoT4KPezuQ2POjNSLkXqqLwErwQbu5NsWuuiN7VGB78Tjyn/74oflj5OxP+3sZ/W 2mXF3AHxuRR8ksyys9TS47p35Y0yGoyicz2mL/YVrZDiEVtQsS+rxoPSM5+gHR18 NMzAMX23uPbBP9A1hEpP =IxQZ -----END PGP SIGNATURE----- --=_zucker.schokokeks.org-24717-1467379988-0001-2-- From nobody Fri Jul 1 08:01:34 2016 Return-Path: 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 0483012D695 for ; Fri, 1 Jul 2016 08:01:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.034 X-Spam-Level: X-Spam-Status: No, score=-2.034 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=inurbanus.nl 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 DHUrWKVvlXOI for ; Fri, 1 Jul 2016 08:01:30 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D94A12D692 for ; Fri, 1 Jul 2016 08:01:29 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id m127so96913836vkb.3 for ; Fri, 01 Jul 2016 08:01:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inurbanus.nl; s=google-inurb; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gh4U/COEFN7fWPm4KI7nS79F2MgsTXTAwh5gu4ygvKI=; b=c/aAcFeowMgsiEVSgb5TiOsRVW4zVx7gwvXMXAqOQkMzURlHQNR3Z/I/rwfF5f5cZE pKZsBJO+WSbuMyoRhwv9NQhKpJh3jQ1PuOdL0Gw5t9mg7SWgozL88ZsewgnY3GISPosC iNRSFKRCRGlP8zQ0FP7JRUN/cA1e5dnUSDZ7s= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gh4U/COEFN7fWPm4KI7nS79F2MgsTXTAwh5gu4ygvKI=; b=Ino7XK2EH5mGJIAwyqetcCtGAeJ27lqN2md7j1ZHGHB0NqX3zGLE0BZoAhHUp2X5Zd PWIj0s/T3coZekXjSindIvCDQ3Hlk6vMWUBM8UBVyhERAV9/uRcEuy/dh0h3ak50PFhW lFQY6REuYxbe8R4KNMKz9/ah4UA70CxQUbPhyjED9+QogFj05toyjTcDQ8QePjIXIKcA EGXCFbsKzFB3JcDT76fR9LVRLfTry+wePNJMRt7YT7chyrm1mSr+WLv24c5IWXJNUpl7 d8HCQ75yhdEyTBUyzvoMgqntj4qZT5UlDqtPHkW+6RRmDUV3sFLMjVqL78yQcl2xNqPQ ACkQ== X-Gm-Message-State: ALyK8tKGu0XEHaiDv2hsYsfOmut/+vEVlEnRqx1CMZsjCCNqNR4kCMfbJj2t5X2z/fLm5QdgC0ZH70hxMQRr0g== X-Received: by 10.159.54.193 with SMTP id p59mr9992609uap.144.1467385288240; Fri, 01 Jul 2016 08:01:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.86.212 with HTTP; Fri, 1 Jul 2016 08:01:27 -0700 (PDT) In-Reply-To: <20160701153304.332d2c95@pc1> References: <20160701153304.332d2c95@pc1> From: Thijs van Dijk Date: Fri, 1 Jul 2016 17:01:27 +0200 Message-ID: To: =?UTF-8?Q?Hanno_B=C3=B6ck?= Content-Type: multipart/alternative; boundary=94eb2c0494e8dacdc30536944290 Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] Can the OpenPGP vs. S/MIME situation be fixed? X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 15:01:33 -0000 --94eb2c0494e8dacdc30536944290 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hanno, This is not a crazy idea at all. I would welcome and applaud this effort. It's an idea I've been mulling over as well; in fact I'd envisioned taking it one step further and introducing a new (v5?) key format that can transparently embed an X.509 certificate. This way, key signatures as we in the PGP universe know them can work their way into the X.509 world, as a way for a "corporate entity" (for lack of a better word") to endorse an individual, or the other way around. This may have profound implications for the way we anchor trust in, for instance, TLS, as individuals can certify e.g. *"I've verified that this certificate is valid for HTTPS connections to this site"* or even *"I've inspected the operation of this CA and know them to have their act together"*. The main things separating the above fantasy from reality are the fact that a) this would be hugely impractical *even if* the entire world would use PGP, and b) the entire world does not use PGP. Having said that, I would still consider unifying PGP and S/MIME a very worthy direction for 4880bis to take, even if it isn't a prelude to the above "web of trust ALL the things" daydream. -- Thijs van Dijk 6A94 F9A2 DFE5 40E3 067E C282 2AFE 9EFA 718B 6165 On 1 July 2016 at 15:33, Hanno B=C3=B6ck wrote: > Hi, > > Maybe this is a crazy idea, but I wanted to throw it into the > discussion. > > IMHO a big problem with e-mail encryption is that there are two > competing "official" standards: OpenPGP and S/MIME. Both are RFCs, so > both have a kinda "official" IETF approval. > I think it was a big mistake to create two competing standards in the > first place, but that was back in the 90s. So we may ask if we want to > live forever with this situation or if it can be fixed. > > One of the most common explanations for the two standards I hear > is that S/MIME is the solution for business communications while > OpenPGP is more for private users. This never made a lot of sense to > me, because there are plenty of situations where "business" people may > have to communicate with "private" people. And the requirements aren't > any different. E-Mail encryption is supposed to ensure that no > unauthorized people can read or manipulate your mail, that doesn't > change whether you're using E-Mail for private or business > communication. So essentially I think there is no rational case for > competing standards. > > So the question is: Instead of making RFC4880bis a "new OpenPGP > standard", could it instead be a successor of both OpenPGP and S/MIME? > Maybe it needs a new name, maybe not. There seems to be an smime working > group and there is still some activity, although the last RFC was > published in 2009. Things would obivously have to be coordinated so > that there is wide acceptance of the new standard. > > Technically it would probably mean to create a compatibility layer to > be able to use both X.509 certificates and PGP keys to encrypt. But > that shouldn't be too hard, as the keys itself are just numbers, the > major difference is just the storage format. > > Maybe this is a crazy idea, but maybe this could also be a chance to > fix one of the biggest mistakes in email encryption. > > -- > Hanno B=C3=B6ck > https://hboeck.de/ > > mail/jabber: hanno@hboeck.de > GPG: BBB51E42 > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp > > --94eb2c0494e8dacdc30536944290 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hanno,

This is not a crazy idea at all.=
I would welcome and applaud this effort.

It's an idea I've been mulling over as well; in fact I'd envi= sioned taking it one step further and introducing a new (v5?) key format th= at can transparently embed an X.509 certificate.
This way, key si= gnatures as we in the PGP universe know them can work their way into the X.= 509 world, as a way for a "corporate entity" (for lack of a bette= r word") to endorse an individual, or the other way around. This may h= ave profound implications for the way we anchor trust in, for instance, TLS= , as individuals can certify e.g. "I've verified that this cert= ificate is valid for HTTPS connections to this site" or even &q= uot;I've inspected the operation of this CA and know them to have their= act together".
The main things separating the above fan= tasy from reality are the fact that
=C2=A0 =C2=A0a) this would be= hugely impractical even if the entire world would use PGP, and
=C2=A0 =C2=A0b) the entire world does not use PGP.


Having said that, I would still consider unifying PGP= and S/MIME a very worthy direction for 4880bis to take, even if it isn'= ;t a prelude to the above "web of trust ALL the things" daydream.=

--
Thijs van Dijk

<= div>6A94 F9A2 DFE5 40E3 067E =C2=A0C282 2AFE 9EFA 718B 6165


On 1 July 2016 at 15:33, Hanno B=C3=B6ck &l= t;hanno@hboeck.de&= gt; wrote:
Hi,

Maybe this is a crazy idea, but I wanted to throw it into the
discussion.

IMHO a big problem with e-mail encryption is that there are two
competing "official" standards: OpenPGP and S/MIME. Both are RFCs= , so
both have a kinda "official" IETF approval.
I think it was a big mistake to create two competing standards in the
first place, but that was back in the 90s. So we may ask if we want to
live forever with this situation or if it can be fixed.

One of the most common explanations for the two standards I hear
is that S/MIME is the solution for business communications while
OpenPGP is more for private users. This never made a lot of sense to
me, because there are plenty of situations where "business" peopl= e may
have to communicate with "private" people. And the requirements a= ren't
any different. E-Mail encryption is supposed to ensure that no
unauthorized people can read or manipulate your mail, that doesn't
change whether you're using E-Mail for private or business
communication. So essentially I think there is no rational case for
competing standards.

So the question is: Instead of making RFC4880bis a "new OpenPGP
standard", could it instead be a successor of both OpenPGP and S/MIME?=
Maybe it needs a new name, maybe not. There seems to be an smime working group and there is still some activity, although the last RFC was
published in 2009. Things would obivously have to be coordinated so
that there is wide acceptance of the new standard.

Technically it would probably mean to create a compatibility layer to
be able to use both X.509 certificates and PGP keys to encrypt. But
that shouldn't be too hard, as the keys itself are just numbers, the major difference is just the storage format.

Maybe this is a crazy idea, but maybe this could also be a chance to
fix one of the biggest mistakes in email encryption.

--
Hanno B=C3=B6ck
https:/= /hboeck.de/

mail/jabber: hanno@hbo= eck.de
GPG: BBB51E42

_______________________________________________
openpgp mailing list
openpgp@ietf.org<= br> https://www.ietf.org/mailman/listinfo/openpgp


--94eb2c0494e8dacdc30536944290-- From nobody Fri Jul 1 08:10:38 2016 Return-Path: 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 1AB7D12D69E for ; Fri, 1 Jul 2016 08:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) 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 Bv0UFZZCzY2a for ; Fri, 1 Jul 2016 08:10:34 -0700 (PDT) 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 9B89912D14D for ; Fri, 1 Jul 2016 08:10:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 539F4E2039; Fri, 1 Jul 2016 11:10:33 -0400 (EDT) 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 27994-03; Fri, 1 Jul 2016 11:10:30 -0400 (EDT) Received: from securerf.ihtfp.org (IHTFP-DHCP-159.IHTFP.ORG [192.168.248.159]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 77B23E2030; Fri, 1 Jul 2016 11:10:30 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1467385830; bh=mttyTBnmxMoTqj5Py9fCan4xDrDfw/zvjPEziVgKV/c=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=JHCZQYyKqd1eeNCkYECtKzO38T9pu7kRcmv7MG1MFkGDy6Aes49FJAwZ7Rjuq5Axl Rz//m+U3RnP9e2HWHrL2CavKaFxGWzHozrLfWQChis2ipEb19H14NEv6lg/EV/N/9u JbcNv5gFWy7h6pYKM+lakk1m1lksGX4CVJ59cMBA= Received: (from warlord@localhost) by securerf.ihtfp.org (8.15.2/8.14.8/Submit) id u61FATTP009078; Fri, 1 Jul 2016 11:10:29 -0400 From: Derek Atkins To: Hanno =?utf-8?Q?B=C3=B6ck?= References: <20160701153304.332d2c95@pc1> Date: Fri, 01 Jul 2016 11:10:29 -0400 In-Reply-To: <20160701153304.332d2c95@pc1> ("Hanno =?utf-8?Q?B=C3=B6ck=22'?= =?utf-8?Q?s?= message of "Fri, 1 Jul 2016 15:33:04 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] Can the OpenPGP vs. S/MIME situation be fixed? X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 15:10:37 -0000 Hi Hanno, Hanno B=C3=B6ck writes: [snip] > So the question is: Instead of making RFC4880bis a "new OpenPGP > standard", could it instead be a successor of both OpenPGP and S/MIME? > Maybe it needs a new name, maybe not. There seems to be an smime working > group and there is still some activity, although the last RFC was > published in 2009. Things would obivously have to be coordinated so > that there is wide acceptance of the new standard. Unfortunately from a process standpoint that is not an option. That's not to say that we cannot write such a draft/document, but it cannot be "4880bis". > Technically it would probably mean to create a compatibility layer to > be able to use both X.509 certificates and PGP keys to encrypt. But > that shouldn't be too hard, as the keys itself are just numbers, the > major difference is just the storage format. > > Maybe this is a crazy idea, but maybe this could also be a chance to > fix one of the biggest mistakes in email encryption. -derek --=20 Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Fri Jul 1 09:49:06 2016 Return-Path: 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 2C91112B069 for ; Fri, 1 Jul 2016 09:49:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 I0I8kbI-yhsU for ; Fri, 1 Jul 2016 09:49:00 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 679E812D647 for ; Fri, 1 Jul 2016 09:49:00 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id e3so9462195qkd.0 for ; Fri, 01 Jul 2016 09:49:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=vBVib186OdNL0Mu8IAr9dCzFT79Rw7Vjr46oLJTMqm8=; b=BQXFkFbciKsJTdOU737ZzCZuibr3lgjs4EtN2W2S/R8mMD9HM/BoTzpDCzS34CuwyC NEjmXYaL7NJ/EgTe52cWzIIh6XygI2kGm+AqTx+6cP8YN8UIU3zSmkTR2UCPAWBQVsTd T9IP/DEhuzCgJk9ovosom9DevIJRQ5H3gQINd/+XXlqMjIPTAiAPGgaC/8b2+/kFFWTi SmEJ+fsQYkOeYEgkLTJLq0nn0L3aCtA8R0pauUkbz8VgBpaWfdEY68q0OoBXotOGahrt 1so0vMpIyqUaBI1MSpTw5SwZkwPSoMsS8l+MJIZCznqg4Qa6C+8CvpK3EaCQnUW5KV5/ S3cA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=vBVib186OdNL0Mu8IAr9dCzFT79Rw7Vjr46oLJTMqm8=; b=AoGhmeaa8Gzluwp5zhBCViL6t3B7io9Z+MHX0fFfM/sLWJPEHEhT5WwV023mIN9lTN ZzRKgZfyNnXBoyTvX39ZGHD5LLujSypfsKHkMIs3iAXGpcCf6xrLuco4yn/G9AnyCUaU ilr1nzaMMMcXiz8UoLx46wnw2w9MpTq4k54kNOe3Vxmwua7c/4wHI6tP66uhw9qww3xG IVQvV3tE93cHo3p8i4xhUmZKv/pnfwmn3kBBiuyTW+7cj86iutGBmL5RnPLQ06M7+Q+H qdCkLnX94YCg7DBaNL9Gm0OuSxPe5uQTnzwl5wfQGREIZXee/29OKTSmWgrFDvH0mIwN 1UXg== X-Gm-Message-State: ALyK8tJz/SmEeWVg8BpUvzL/XAfl9hQM5j43EmCufuAVw0zXajgJcrEA9vQVjZ8VrEHsER3gaXIvJY+wxVBAXw== X-Received: by 10.55.159.72 with SMTP id i69mr26805037qke.29.1467391739509; Fri, 01 Jul 2016 09:48:59 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.55.16.106 with HTTP; Fri, 1 Jul 2016 09:48:58 -0700 (PDT) In-Reply-To: References: <20160701153304.332d2c95@pc1> From: Phillip Hallam-Baker Date: Fri, 1 Jul 2016 12:48:58 -0400 X-Google-Sender-Auth: GE_OMD65gXf_wu9G0OrvZbNDqyg Message-ID: To: Derek Atkins Content-Type: multipart/alternative; boundary=94eb2c06b730614329053695c3de Archived-At: Cc: IETF OpenPGP , =?UTF-8?Q?Hanno_B=C3=B6ck?= Subject: Re: [openpgp] Can the OpenPGP vs. S/MIME situation be fixed? X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 16:49:04 -0000 --94eb2c06b730614329053695c3de Content-Type: text/plain; charset=UTF-8 I have wanted this for a long time. there are actually three separate problems to be solved. 1) How to make S/MIME work with OpenPGP credentials 2) How to make OpenPGP work with S/MIME credentials 3) How to merge the two specifications into one. The conditions for making the first two happen are easy. If there is a will, IETF will find a way. We already have an OpenPGP group. The chartering of a SPASM group is in the works. I do not think it is going to be at all difficult to get ADs or IESG to approve work to make two existing IETF standards interoperate. That is what IETF is for. The third is still hard because it requires existing infrastructures to merge and that is a long and difficult process unless you can deliver a major improvement in functionality. I just can't see merger of two email security standards offering encryption and signature into one offering that incentive. But that doesn't have to be what we do. I think we do have an option that would be Blu-Ray to OpenPGP and S/MIME's Betamax and VHS. There are in fact three technologies we can build on that offer dramatic improvements in functionality. 1) Linked Timestamp (aka Blockchain) Forget Bitcoin for a minute and proof of work. Linked Timestamps improve the Work Factor of any PKI and you do not in fact need proof of work to guarantee that. There are better, cheaper options to achieve the same result. Let us imagine for a moment that we upgraded the MIT Key Server infrastructure that supports OpenPGP to a similar infrastructure that included technology similar to Certificate Transparency. As soon as a key signing or certificate or whatever is enrolled and the infrastructure synchronizes, the Work Factor for backdating a forgery of that assertion to before the enrollment date goes to 2^256. That is real cryptographic power. 2) Combining the Web of Trust and Brokered Trust (CA) models People have fixed on the idea of one model or the other. What if we choose both. The work factor of the resulting Webs of trust becomes very high very quickly and more importantly the work factor values become objective. 3) Proxy Re-Encryption [NB IPR encumbrance for the next 18 months] Using Recryption, a user can encrypt a document to be read by a named group of users (e.g. secretgroup@example.com) using the public key for that group and upload it to a server. The server can then create decryption keys for each of the users that have been granted access by the administrator by converting the decryption blob for the group into a decryption blob for each authorized recipient. But the server can't decrypt the document itself. Recryption is very very powerful and we should make it the heart and soul of the next generation of message security infrastructure. * Chat rooms which can only be accessed by people who are on the list *These can be text, voice, video, naturally * Dropbox style document repositories * Next generation email * Internal document distribution. Recryption offers real power and we have been ignoring it for too long. Now a program of the type I am describing is obviously not something for SPASM or OpenPGP to discuss. It is way beyond their charter. In fact some folk will probably argue that this is IRTF work, not IETF. But I do have the start of open source (MIT license) code for a system that I believe could grow into this. And the code is almost on the verge of working cross platform. It uses all the modern platforms you would expect, JSON over HTTPS, consensus crypto algorithms, etc. etc. I am trying to follow the path that Tim laid out for the deployment of the Web - start off by concentrating on how to add value to existing code bases. The early Web users weren't actually using HTTP very much. Most of the information they were getting came from FTP, NNTP, WAIS and so on. The main use of HTTP and HTML was to provide a common interchange format for gateways to access legacy gateways. So right now, all the Mathematical Mesh is focused on is making S/MIME and OpenPGP and SSH and Web Usernames/Passwords easy to use. I am working to make existing crypto applications as easy to use as legacy ones. This isn't 'OK usability' meaning follow a long list of instructions. As you all know, I am an obsessive and a perfectionist when it comes to usability. This is security that you won't know is there unless you are asking yourself if something is safe and start looking into it. But if the Mesh succeeds then we get to a point where a significant userbase has private keys established on every single device they use. We have a large client side PKI that can establish trust through Web of Trust, PKI or hybrid methods. Once you have that in place, developing new cryptographic applications to leverage that infrastructure is really straightforward. I could use some help. --94eb2c06b730614329053695c3de Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have wanted this for a long= time. there are actually three separate problems to be solved.

1) How to mak= e S/MIME work with OpenPGP credentials
2) How to make OpenPGP work with S/MIM= E credentials

3) How to merge the two specifications into one.

The conditions f= or making the first two happen are easy. If there is a will, IETF will find= a way. We already have an OpenPGP group. The chartering of a SPASM group i= s in the works. I do not think it is going to be at all difficult to get AD= s or IESG to approve work to make two existing IETF standards interoperate.= That is what IETF is for.

The third is still hard because it requires existi= ng infrastructures to merge and that is a long and difficult process unless= you can deliver a major improvement in functionality. I just can't see= merger of two email security standards offering encryption and signature i= nto one offering that incentive.


But t= hat doesn't have to be what we do. I think we do have an option that wo= uld be Blu-Ray to OpenPGP and S/MIME's Betamax and VHS. There are in fa= ct three technologies we can build on that offer dramatic improvements in f= unctionality.

1) Linked Timestamp (aka Blockchain)

Forget Bitcoin for a minute = and proof of work. Linked Timestamps improve the Work Factor of any PKI and= you do not in fact need proof of work to guarantee that. There are better,= cheaper options to achieve the same result.

Let us imagine for a moment that= we upgraded the MIT Key Server infrastructure that supports OpenPGP to a s= imilar infrastructure that included technology similar to Certificate Trans= parency. As soon as a key signing or certificate or whatever is enrolled an= d the infrastructure synchronizes, the Work Factor for backdating a forgery= of that assertion to before the enrollment date goes to 2^256. That is rea= l cryptographic power.

2) Combining the Web of Trust and Brokered Trust (CA) = models

People have fixed on the idea of one model or the other. What if we ch= oose both. The work factor of the resulting Webs of trust becomes very high= very quickly and more importantly the work factor values become objective.=

3= ) Proxy Re-Encryption

[NB IPR encumbrance for the next 18 months]

Using Recrypt= ion, a user can encrypt a document to be read by a named group of users (e.= g. secretgroup@example.com) = using the public key for that group and upload it to a server. The server c= an then create decryption keys for each of the users that have been granted= access by the administrator by converting the decryption blob for the grou= p into a decryption blob for each authorized recipient. But the server can&= #39;t decrypt the document itself.

Recryption is very very powerful and we sh= ould make it the heart and soul of the next generation of message security = infrastructure.

* Chat rooms which can only be accessed by people who are on = the list
=C2=A0 =C2=A0*These can be text,= voice, video, naturally
* Dropbox style = document repositories
* Next generation e= mail
* Internal document distribution.

Recr= yption offers real power and we have been ignoring it for too long.


Now a program of the type I am describing is = obviously not something for SPASM or OpenPGP to discuss. It is way beyond t= heir charter. In fact some folk will probably argue that this is IRTF work,= not IETF.

But I do have the start of open source (MIT license) code for a sy= stem that I believe could grow into this. And the code is almost on the ver= ge of working cross platform. It uses all the modern platforms you would ex= pect, JSON over HTTPS, consensus crypto algorithms, etc. etc.

I am trying to = follow the path that Tim laid out for the deployment of the Web - start off= by concentrating on how to add value to existing code bases. The early Web= users weren't actually using HTTP very much. Most of the information t= hey were getting came from FTP, NNTP, WAIS and so on. The main use of HTTP = and HTML was to provide a common interchange format for gateways to access = legacy gateways.

So right now, all the Mathematical Mesh is focused on is mak= ing S/MIME and OpenPGP and SSH and Web Usernames/Passwords easy to use. I a= m working to make existing crypto applications as easy to use as legacy one= s. This isn't 'OK usability' meaning follow a long list of inst= ructions. As you all know, I am an obsessive and a perfectionist when it co= mes to usability. This is security that you won't know is there unless = you are asking yourself if something is safe and start looking into it.

But i= f the Mesh succeeds then we get to a point where a significant userbase has= private keys established on every single device they use. We have a large = client side PKI that can establish trust through Web of Trust, PKI or hybri= d methods. Once you have that in place, developing new cryptographic applic= ations to leverage that infrastructure is really straightforward.


<= div class=3D"gmail_default">I could use some help.
--94eb2c06b730614329053695c3de-- From nobody Fri Jul 1 11:28:04 2016 Return-Path: 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 3C91F12D5A2 for ; Fri, 1 Jul 2016 11:28:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 D4XypsP3e0vY for ; Fri, 1 Jul 2016 11:28:01 -0700 (PDT) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FC3712B078 for ; Fri, 1 Jul 2016 11:28:01 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id c34so61840338qte.0 for ; Fri, 01 Jul 2016 11:28:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=25S7ta4r6kAAfDspxxxVmI9GizJ+WLlDge/tO7pO308=; b=LM4NaMVHYNjX472bLHbM8JQ3cjGIJ/u29wItB9qkKTBHkfpEMnMfYS18nJ7qOsevH/ wgV2yvm2K29qjNzSgdqEgDeNA5bKsZ53vkRlGB+8MIqoWHpB/tBP20augTvm9gPWEvD2 okp1a+RGbcVQtQVsXL62x1F8LbKXjg5TO6PQ/HRo3q5aYGQxnmNmC2gfA3g6Ef0gkdKP iVX12bNDhotigUVM2yawScX4CvEXmy0z+cXI6LY4ShN6si+dlO1tJqTbKAjQLaqSwl/m OS8/HVlWLbEz6RV1PA6mZKHOj3dxOEdUZJOvBUEjvc/P32CU1kb6JjCcNeodSViHqcDe FcNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=25S7ta4r6kAAfDspxxxVmI9GizJ+WLlDge/tO7pO308=; b=Yp05Xq4t3QmYxJlg5TmNXkoxj23Rdyy/d76Eehp7hGhASCjwZZYMNzeb4MMo29OWO6 LbmksY0H9wQffBY9jomGftnLhEDuTEME9ZbY7ejoeCaM8izM9kBov9YmFq78T+Ox6/p9 CymmNeKma2WTHLqNdj2KXn2KnwiCK/64pcZIzQCoTaJBddikA9qBRGXGjc8kgiCuv7WI 9jhgpagXpSLWKxKi2j+zOSItw2IRUVlTzdXVWISyFc5NXy/2R5D46lQTd+R+nus99iSF OSDbPeoGudRM31VsExZmdArN6FI1RWwomfmXwlschubzzwEWbRu7ze3aHgS2YeYr3mCq 7K3Q== X-Gm-Message-State: ALyK8tKD0/cXaScHQmwj5ByiW3Cv/5gp55b7CfUOHbFA4p+1uaZQGzOG4aKiy8zOc1GCOdkXTOX5TeQ1Vh8M7Q== X-Received: by 10.237.53.233 with SMTP id d38mr33118545qte.104.1467397680375; Fri, 01 Jul 2016 11:28:00 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.55.16.106 with HTTP; Fri, 1 Jul 2016 11:27:59 -0700 (PDT) In-Reply-To: References: <20160701153304.332d2c95@pc1> From: Phillip Hallam-Baker Date: Fri, 1 Jul 2016 14:27:59 -0400 X-Google-Sender-Auth: cIB7VhO-0UoZbSZucRd7HLwtdHI Message-ID: To: Derek Atkins Content-Type: multipart/alternative; boundary=001a114024e67bae160536972512 Archived-At: Cc: IETF OpenPGP , =?UTF-8?Q?Hanno_B=C3=B6ck?= Subject: Re: [openpgp] Can the OpenPGP vs. S/MIME situation be fixed? X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 18:28:03 -0000 --001a114024e67bae160536972512 Content-Type: text/plain; charset=UTF-8 Just a note to add that the way to get OpenPGP to work with S/MIME would be for experts to get together and write drafts proposing a way to do it. If we have drafts that have support from experts in both camps then getting them through IETF process should not be a roadblock. We don't need to charter or recharter before starting that type of work. We only need to charter before we adopt it somewhere as a working group item. The precondition for that being 'do you have a plan'. --001a114024e67bae160536972512 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Jus= t a note to add that the way to get OpenPGP to work with S/MIME would be fo= r experts to get together and write drafts proposing a way to do it. If we = have drafts that have support from experts in both camps then getting them = through IETF process should not be a roadblock.

We don't need to charter or recharter before sta= rting that type of work. We only need to charter before we adopt it somewhe= re as a working group item. The precondition for that being 'do you hav= e a plan'.
=
--001a114024e67bae160536972512-- From nobody Sat Jul 2 08:09:03 2016 Return-Path: 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 7FDCB12D0C3 for ; Sat, 2 Jul 2016 08:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 bZDhhiqNM9PL for ; Sat, 2 Jul 2016 08:08:58 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FA0912D08E for ; Sat, 2 Jul 2016 08:08:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1467472138; x=1499008138; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=EZ8b16AA7ZPrCjq5QArqX6Q0I4uoC7sycESDmy4Pm4I=; b=KDrybgXoEOnUHVHxjyoYIdx9dhb9RCnXKkOhbnG58LTfic8DCmS+Xj3v N40KwS8fDyEpVUMvjr30VgJ8amcf9PhVtZDT0C1y867OguzAAu8hEYYbJ 7v5RwA4lMPjyqB8HqUtK/s7EWY7MCFjpwelG3nDznhceApVh9Ks378aiY zGXATibvsIUE2fiIC06y9exRh0BkpBahv3cGeO5wOolLNuNCzXf6tQtjC 8nvpW4Hl5P1dkkqhXElOeiqhr3k4gxy9ToqIOOBh4qgNbeLtqavuVRWrV cvjRbR6TQ5HIy/grr7RtwJYQjgAu3mL16rfAkuiqKpK7nChjQ9TdSQn3I Q==; X-IronPort-AV: E=Sophos;i="5.26,563,1459771200"; d="scan'208";a="94530343" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing Received: from uxchange10-fe4.uoa.auckland.ac.nz ([130.216.4.171]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 03 Jul 2016 03:08:56 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.93]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0266.001; Sun, 3 Jul 2016 03:08:56 +1200 From: Peter Gutmann To: Phillip Hallam-Baker , Derek Atkins Thread-Topic: [openpgp] Can the OpenPGP vs. S/MIME situation be fixed? Thread-Index: AQHR050jpR81NF3KlE2UhFa6MyYJKaADrkB6//9SRwCAAj8/3Q== Date: Sat, 2 Jul 2016 15:08:55 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4CB8706@uxcn10-5.UoA.auckland.ac.nz> References: <20160701153304.332d2c95@pc1> , In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.6.3.2] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: IETF OpenPGP , =?iso-8859-1?Q?Hanno_B=F6ck?= Subject: Re: [openpgp] Can the OpenPGP vs. S/MIME situation be fixed? X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2016 15:09:02 -0000 Phillip Hallam-Baker writes:=0A= =0A= >I have wanted this for a long time. there are actually three separate=0A= >problems to be solved.=0A= >=0A= >1) How to make S/MIME work with OpenPGP credentials=0A= >=0A= >2) How to make OpenPGP work with S/MIME credentials=0A= >=0A= >3) How to merge the two specifications into one.=0A= =0A= The first two are pretty easy, I've been doing that for years. For S/MIME,= =0A= use the subjectKeyIdentifier form of the key ID. For PGP, use an=0A= issuerAndSerialNumber in a type-and-value subpacket.=0A= =0A= The third is impossible. While at an abstract level PGP and S/MIME do the= =0A= same thing, the bit-bagging formats used to encode the abstraction are=0A= completely incompatible. You can't make them compatible without either mov= ing=0A= S/MIME to the PGP format or PGP to the S/MIME format. I can't see either o= f=0A= those happening...=0A= =0A= Peter.= From nobody Sat Jul 2 17:24:08 2016 Return-Path: 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 6129312B026 for ; Sat, 2 Jul 2016 17:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 CMTl2uc4z7V8 for ; Sat, 2 Jul 2016 17:24:05 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7C6E128874 for ; Sat, 2 Jul 2016 17:24:05 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id e3so40396950qkd.0 for ; Sat, 02 Jul 2016 17:24:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=OV7YdPFs5U2akjH3DHE6boynhw/UnvjXuZUS0qQoof8=; b=V8RBZZ5rbb8z3NxQFtFjPr84p9+sWOEeRBojUXfrzd0vsTYvwRRCzDkatKnZ5WEAhI 8JSpmmb3UjBelJKqTDlRin+OSc+WwVk/DF56J97CD7AyuHHi9Sr9sn8ruOKYPV88zX95 uQga0NAK8e7OiUjxeoxImTZcI8lgegek7QEcmtOD12jOrDf+H02XSa1II/4/PIzmJ+cZ KhzhrCDYWXv2BROBJEmKHVFzl0YuJipb3OoFbo4xy26dTIa3tjpKfOegjQMIC29BDu2j jVTkAaatQZqMeYLfpvRRwpBFU/VHy/IXxgPk2FMVDDyw+NChN8mD0bDsBt50qg29iqJn zeHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=OV7YdPFs5U2akjH3DHE6boynhw/UnvjXuZUS0qQoof8=; b=do81p26yHMCmy9zZwpPV5yrsCaBuOwS4vUXvGu5vk+3yb3CGF/sGf97D+Aa+3vGQJM 7OF+cGD81tRqG45o1vn+oD5y1dZSJhX3+BkzSsd1VSxKT3BjF20D3oTbg9nzBaob2uzG 7s6AxRWq5wZ7YsuTzYMJ1PBvQggs5ZEFpRUy7zUCBb7h6iJoWCxalWTBq7yPDilw6MWs ouRlITwJwWZc/aFs/uin3NsBHGoqSP6iosqOEa1n9MhmNmS+D3+4p15Srd8SjCi6lw7M N5+uQKJ62SP/17ZAsNOLdI8Kc6lVQHPL+ZhqGzrByO5T8Qicb/LIe1UgAo/joSo6Ht0C oyag== X-Gm-Message-State: ALyK8tJnvMg9dCXbZFaxiAlRInaNyJvkK6/YOLEJVL9oSUNx/C27SpLUf8Xu2r66ocggFo7Wg2yAixJuEqj94A== X-Received: by 10.55.69.69 with SMTP id s66mr7712672qka.117.1467505444915; Sat, 02 Jul 2016 17:24:04 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.55.16.106 with HTTP; Sat, 2 Jul 2016 17:24:04 -0700 (PDT) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4CB8706@uxcn10-5.UoA.auckland.ac.nz> References: <20160701153304.332d2c95@pc1> <9A043F3CF02CD34C8E74AC1594475C73F4CB8706@uxcn10-5.UoA.auckland.ac.nz> From: Phillip Hallam-Baker Date: Sat, 2 Jul 2016 20:24:04 -0400 X-Google-Sender-Auth: rvoz3uHQ44Jj9s5qYmUm0dkQeXM Message-ID: To: Peter Gutmann Content-Type: multipart/alternative; boundary=001a1148a342c00f930536b03cac Archived-At: Cc: =?UTF-8?Q?Hanno_B=C3=B6ck?= , IETF OpenPGP , Derek Atkins Subject: Re: [openpgp] Can the OpenPGP vs. S/MIME situation be fixed? X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2016 00:24:07 -0000 --001a1148a342c00f930536b03cac Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Jul 2, 2016 at 11:08 AM, Peter Gutmann wrote: > Phillip Hallam-Baker writes: > > >I have wanted this for a long time. there are actually three separate > >problems to be solved. > > > >1) How to make S/MIME work with OpenPGP credentials > > > >2) How to make OpenPGP work with S/MIME credentials > > > >3) How to merge the two specifications into one. > > The first two are pretty easy, I've been doing that for years. For S/MIM= E, > use the subjectKeyIdentifier form of the key ID. For PGP, use an > issuerAndSerialNumber in a type-and-value subpacket. > > The third is impossible. While at an abstract level PGP and S/MIME do th= e > same thing, the bit-bagging formats used to encode the abstraction are > completely incompatible. You can't make them compatible without either > moving > S/MIME to the PGP format or PGP to the S/MIME format. I can't see either > of > those happening... =E2=80=8B That would clearly be impossible if it was what was being proposed. What I am suggesting is rather different, A new application for managing encrypted content, Word, Powerpoint, PDF, etc. that has crypto designed into the metal and also provides a messaging capability. I am suggesting Blu Ray, not trying to develop adapters to play VHS on Betamax. =E2=80=8B --001a1148a342c00f930536b03cac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Sat, Ju= l 2, 2016 at 11:08 AM, Peter Gutmann <pgut001@cs.auckland.ac.nz> wrote:
Phil= lip Hallam-Baker <phill@hallamb= aker.com> writes:

>I have wanted this for a long time. there are actually three separate >problems to be solved.
>
>1) How to make S/MIME work with OpenPGP credentials
>
>2) How to make OpenPGP work with S/MIME credentials
>
>3) How to merge the two specifications into one.

The first two are pretty easy, I've been doing that for years.= =C2=A0 For S/MIME,
use the subjectKeyIdentifier form of the key ID.=C2=A0 For PGP, use an
issuerAndSerialNumber in a type-and-value subpacket.

The third is impossible.=C2=A0 While at an abstract level PGP and S/MIME do= the
same thing, the bit-bagging formats used to encode the abstraction are
completely incompatible.=C2=A0 You can't make them compatible without e= ither moving
S/MIME to the PGP format or PGP to the S/MIME format.=C2=A0 I can't see= either of
those happening...

=E2=80=8B
That would clearly be impossible if= it was what was being proposed.

What I am suggesting is rather = different, A new application for managing encrypted content, Word, Powerpoi= nt, PDF, etc. that has crypto designed into the metal and also provides a m= essaging capability.

I am suggesting Blu Ray, not trying to develop adapters to = play VHS on Betamax.=C2=A0
=E2=80=8B
--001a1148a342c00f930536b03cac-- From nobody Sun Jul 3 00:43:20 2016 Return-Path: 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 41BF512D0CC for ; Sun, 3 Jul 2016 00:43:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no 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 C5QPCqgyCt8Y for ; Sun, 3 Jul 2016 00:43:17 -0700 (PDT) Received: from mail.mugenguild.com (mugenguild.com [5.135.189.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04A4212D09B for ; Sun, 3 Jul 2016 00:43:16 -0700 (PDT) Received: from [10.47.194.64] (unknown [89.204.135.64]) by mail.mugenguild.com (Postfix) with ESMTPSA id 412365FC11; Sun, 3 Jul 2016 09:43:13 +0200 (CEST) Date: Sun, 03 Jul 2016 09:43:05 +0200 From: Vincent Breitmoser To: openpgp@ietf.org, Phillip Hallam-Baker , Peter Gutmann User-Agent: K-9 Mail for Android In-Reply-To: References: <20160701153304.332d2c95@pc1> <9A043F3CF02CD34C8E74AC1594475C73F4CB8706@uxcn10-5.UoA.auckland.ac.nz> Message-ID: <0342C725-9E44-4F34-B4C6-3CDDEE17F1BE@my.amazin.horse> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/signed; boundary="----R9L9KRZL8YALCRRMUY8AIQWYG7OQFH"; protocol="application/pgp-signature"; micalg="pgp-sha512" Archived-At: Cc: Derek Atkins , IETF OpenPGP , =?ISO-8859-1?Q?Hanno_B=F6ck?= Subject: Re: [openpgp] Can the OpenPGP vs. S/MIME situation be fixed? X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2016 07:43:19 -0000 ------R9L9KRZL8YALCRRMUY8AIQWYG7OQFH Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable *queue n+1 competing standards xkcd - V On 3 July 2016 02:24:04 CEST, Phillip Hallam-Baker wrote: >On Sat, Jul 2, 2016 at 11:08 AM, Peter Gutmann > >wrote: > >> Phillip Hallam-Baker writes: >> >> >I have wanted this for a long time=2E there are actually three >separate >> >problems to be solved=2E >> > >> >1) How to make S/MIME work with OpenPGP credentials >> > >> >2) How to make OpenPGP work with S/MIME credentials >> > >> >3) How to merge the two specifications into one=2E >> >> The first two are pretty easy, I've been doing that for years=2E For >S/MIME, >> use the subjectKeyIdentifier form of the key ID=2E For PGP, use an >> issuerAndSerialNumber in a type-and-value subpacket=2E >> >> The third is impossible=2E While at an abstract level PGP and S/MIME >do the >> same thing, the bit-bagging formats used to encode the abstraction >are >> completely incompatible=2E You can't make them compatible without >either >> moving >> S/MIME to the PGP format or PGP to the S/MIME format=2E I can't see >either >> of >> those happening=2E=2E=2E > > >=E2=80=8B >That would clearly be impossible if it was what was being proposed=2E > >What I am suggesting is rather different, A new application for >managing >encrypted content, Word, Powerpoint, PDF, etc=2E that has crypto designed >into the metal and also provides a messaging capability=2E > >I am suggesting Blu Ray, not trying to develop adapters to play VHS on >Betamax=2E >=E2=80=8B ------R9L9KRZL8YALCRRMUY8AIQWYG7OQFH Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iQJOBAABCgA4MRxWaW5jZW50IEJyZWl0bW9zZXIgPHYuYnJlaXRtb3NlckBtdWdl bmd1aWxkLmNvbT4FAld4wgoACgkQe9GDIN6t+hHy8w/9FmEtFIKNitC6rf9gwwB8 XYPH5fDLVKHRdcj46zhmCh8T97rePApvtybY0sOc2fqsZ7e5VEUdfUEq9Hw0c2cE bmVIip+xVZ+lzUdLyJ54nhaVFrT0nAmgm0zueQ4zPEFnVlDtC79j56c7E/FoCVyX mHBbBmAyhKveExNtHgU4NJ3vRPO93MnbgWnMeb17iSFnjT1GsVFJVLEhfB/fiqJy zyqK689XwmkNx+NS7Y3a2sAclZRr8Uvt53/eVF2QcMiEn6BiNpl8tOOPw5UWN05p hPLUgbVNLbYA4+ccCpq6aJDiA8DkvJntKvKfiGYi97I4v7/wQQRc+eeNez/eFkhy uj5BuuLJ5TTxisMBbpm8AdiBGbnqivkNzLtXVpbdjduok+XywiAstG+ezyYwA0xC 9z6n4TGkfw5MiD0F8nTWqF3XI6lnwyWsHG4NgofO9cV9inhJDzGxEhTeOl+ulkEg W70m3xGtRc+fz091b2kQIWECsPUxae7EvUFmeyLUhJRSjo8WbzrJvHHRSluon2Lw 2anagbu5S3IgOGk5hwSc5QXjI34ahS0vdQU/kyNnR6E88ykqb3FXafxXn+AL21yl VUZ0JBS4OXmXS47xedqSi6z5mOwVBu1F7ktssIT3hXBLSQVJZ1oXvC9d8IR+WFhh dStMVNTuNEKvdiQNP0eIIxU= =GX0n -----END PGP SIGNATURE----- ------R9L9KRZL8YALCRRMUY8AIQWYG7OQFH-- From nobody Sun Jul 3 06:11:25 2016 Return-Path: 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 C439312D140 for ; Sun, 3 Jul 2016 06:11:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Yz2pK3YDDpyM for ; Sun, 3 Jul 2016 06:11:22 -0700 (PDT) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5B6112D133 for ; Sun, 3 Jul 2016 06:11:21 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id g4so4252677ith.1 for ; Sun, 03 Jul 2016 06:11:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=TO4YXy2FcbDJz6Tb4ZMJ7dNK5Ye35NHni8Y2cEfPXm0=; b=tmHBVdnrDt1kmnXZoB9K02Qc2eME6mEXDK0L1hC5cToSfvSP/X3s5BT7MzBjar0axB 72ASFg+zL1zphN3/JC20ZBlDr3YnbGBDuD0kdTWsPMXx1NK05hYy8mFZCU0GHUfRo/pt hJeIazcBSRtznq+1QC9nvBhzy5y5nQmcxlCYweTuw0qNVi6tgydBhDXVUHCxd35Af+v6 OlS5Xkd776ktxE3tze7ZV26WI5LHEvn1bkuw9LC2bKrr72N+5NhdkTXG2KHgujwxgfgG Cu0VO/3/YP6mtYVtg+N+bz8o4mjP8Rdee96OXm0MInT1OzrsYCcT83KwXjwZL/AIa2jz JtUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=TO4YXy2FcbDJz6Tb4ZMJ7dNK5Ye35NHni8Y2cEfPXm0=; b=D4JkEkWJ0Dt8+r2JiE9YzD3z9E+j5j0frJ0XqpwOm5KlSbAfaF0PkJtu0w/mGb4RNH 21bTYdGjNWcuo9KZChHylTJdA/nXWL6rqDX0FJi5NUbHhvE01aXNlWu2v0pg388o3GMD pTq6NEeufvMXa3SV+sqAoxqKgdioAOn93XbsWuAT4wRuor9dM0WXTKQtaIuGCihFuT8F OkbSFxnIDWrNYjq7yieypOEmJu3Eq39xrsSVIcQ3L28DQmqxkyCxQIaMymNVqsl7WVml tmppt8QN/yTwU5ZpR3B7uZhRpFrNKpaduU11FzwbcAIwBt8n2fvDB9c8bKZ2H784pgga oUNw== X-Gm-Message-State: ALyK8tKyKQbYCSF/ei0Oto8QRhZyPCly/Eq5sWZfxLtxysPLEpAZt3UZV27fbfet4iIXd6ONRIwQgcKHZCt66A== X-Received: by 10.36.19.138 with SMTP id 132mr1725710itz.76.1467551481016; Sun, 03 Jul 2016 06:11:21 -0700 (PDT) MIME-Version: 1.0 Sender: barryleiba.mailing.lists@gmail.com Received: by 10.107.153.78 with HTTP; Sun, 3 Jul 2016 06:11:20 -0700 (PDT) In-Reply-To: <878txtjnf6.fsf@alice.fifthhorseman.net> References: <878txtjnf6.fsf@alice.fifthhorseman.net> From: Barry Leiba Date: Sun, 3 Jul 2016 09:11:20 -0400 X-Google-Sender-Auth: MAE9507mu_cr20PKbN2PSJvEpnE Message-ID: To: IETF OpenPGP Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [openpgp] call for adoption of draft-koch-openpgp-rfc4880bis X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2016 13:11:24 -0000 Given the responses so far, I think we have enough "yes, adopt" comments to go forward. So there's no need for more "yes" responses. Please post any *objections* by Wednesday, 6 July. Thanks, Barry, as chair On Sat, Jun 25, 2016 at 11:30 AM, Daniel Kahn Gillmor wrote: > hey OpenPGP folks-- > > We've had a slow start on 4880bis, but i'm hoping we can get things > moving again. One of the things we need to do bureaucratically is to > officially adopt a specific draft as the basis of our ongoing work. > > Werner Koch has prepared and submitted the beginnings of the new > revision of RFC 4880, the current version of which you can see here: > > https://tools.ietf.org/html/draft-koch-openpgp-rfc4880bis-02 > > This is a call for adoption of this draft by the OpenPGP WG. Please > speak up soon if you have any concerns, or if you think this document > should not be adopted by the WG for some reason. Please also speak up > if you are in favor of adoption. > > A brief reminder of what adoption by the WG would mean: > > * this draft would become the *starting point* for RFC 4880bis; the > draft is currently not complete, but it would be the basis upon which > the group would build the new proposal. > > * Werner Koch would be the document editor, but the decisions about the > draft would be made by the working group. I want to thank Werner for > his willingness to put in his time as the document editor. > > * Since our charter (https://datatracker.ietf.org/wg/openpgp/charter/) > is aimed primarily at making a revision to RFC 4880, we would > hopefully focus our efforts on contributing review and amendments to > this draft, with a goal of driving it to IETF Last Call within the > year. > > Please give feedback on draft adoption! > > --dkg > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp > From nobody Sun Jul 3 06:39:05 2016 Return-Path: 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 7520C12B007 for ; Sun, 3 Jul 2016 06:39:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no 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 2APIYma32C1J for ; Sun, 3 Jul 2016 06:39:01 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id 4754812B02C for ; Sun, 3 Jul 2016 06:39:01 -0700 (PDT) Received: from fifthhorseman.net (c-174-62-194-216.hsd1.ct.comcast.net [174.62.194.216]) by che.mayfirst.org (Postfix) with ESMTPSA id CFD5AF98B for ; Sun, 3 Jul 2016 09:39:00 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id CAB88202B6; Sun, 3 Jul 2016 09:38:59 -0400 (EDT) From: Daniel Kahn Gillmor To: IETF OpenPGP User-Agent: Notmuch/0.22+69~gd812194 (https://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Sun, 03 Jul 2016 09:38:59 -0400 Message-ID: <87d1muyh70.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: [openpgp] time representation in OpenPGP X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2016 13:39:03 -0000 Hi OpenPGP folks-- RFC 4880 represents time as: ---------- 3.5. Time Fields A time field is an unsigned four-octet number containing the number of seconds elapsed since midnight, 1 January 1970 UTC. ---------- https://tools.ietf.org/html/rfc4880#section-3.5 This wraps around in early 2106, if my math is correct. Would someone like to propose an alternate representation of time for RFC 4880bis? Or is there a clear argument for keeping it as-is? --dkg From nobody Sun Jul 3 06:48:50 2016 Return-Path: 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 B028312D0F0 for ; Sun, 3 Jul 2016 06:48:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.127 X-Spam-Level: X-Spam-Status: No, score=-4.127 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.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 gtpyTY6Q59bI for ; Sun, 3 Jul 2016 06:48:46 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 444A312B006 for ; Sun, 3 Jul 2016 06:48:46 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 522FE42371C; Sun, 3 Jul 2016 13:48:45 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 32D3D423718; Sun, 3 Jul 2016 13:48:45 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1467553725; bh=T7rW81iJFufb2WTbVOj/8fi9W9YF3KJp+9ffx8uKdsw=; l=382; h=From:To:Date:References:In-Reply-To:From; b=vAyYAIGHBfSLNgi5GHRIucQZgkBW4QbaxHkBtsuKZ0kii3DTGIYyKJgz8vAbbaq0g DAGPGIAPz+v//85LozaxNzFoRFgzRQTaElayjERWga/GzagsRvEtP9wuUeX11K2IA4 u9ezTmxE+3Fket47py38FcC0T+hngMnuF2O9W37w= Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.34]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 2E49D1FC88; Sun, 3 Jul 2016 13:48:45 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Sun, 3 Jul 2016 09:48:44 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1130.005; Sun, 3 Jul 2016 09:48:44 -0400 From: "Salz, Rich" To: Daniel Kahn Gillmor , IETF OpenPGP Thread-Topic: [openpgp] time representation in OpenPGP Thread-Index: AQHR1TBHeCsIUihs40Gv9sNg4N7ceKAGuAYA Date: Sun, 3 Jul 2016 13:48:44 +0000 Message-ID: References: <87d1muyh70.fsf@alice.fifthhorseman.net> In-Reply-To: <87d1muyh70.fsf@alice.fifthhorseman.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.42.130] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [openpgp] time representation in OpenPGP X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2016 13:48:48 -0000 > A time field is an unsigned four-octet number containing the number > of seconds elapsed since midnight, 1 January 1970 UTC. Isn't that the classic Unix time_t, which expires in 2038? I suggest we use ASN1 generalized time (which has only a couple of bytes ov= erhead) or ISO 8601 profiled to be like the ASN1 format: YYYY-MM-DD-HH:MM:S= S.sss with fraction optional. From nobody Sun Jul 3 06:57:47 2016 Return-Path: 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 F2AFE12B006 for ; Sun, 3 Jul 2016 06:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sumptuouscapital-com.20150623.gappssmtp.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 wnSqdxY7Wtts for ; Sun, 3 Jul 2016 06:57:42 -0700 (PDT) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D15112D0F3 for ; Sun, 3 Jul 2016 06:57:42 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id q132so103069866lfe.3 for ; Sun, 03 Jul 2016 06:57:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sumptuouscapital-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=xPUeud69Li27tzlHGV4C1j0Ahz9/ERlQn2mqA9ff6HM=; b=yCUjJ+st1CIoZ8v8ooFZSJMFfhg04S0wiM5Z70Tpdo6X4CU07juQqVvQNDUgP82x3A +OzbBddeoktjwqXpLeOnz46rGSeHR4+9NfKxYB4mT+6P7gX1sD5xm+DSp7ceRilddNe/ DHr4i6zzHrZZXRJcyQuLcCAeXxHnrYEz7i9mWrSBmIcaJdsqcISUuN78xKWI2Tzc7DY8 0R3QhpvsDbqMUmGtiE1yzYNZY5e3PDIKmGxXyXJSzq8sMixDtHQPTGpGqukzdEZpXnfb D4BbXoCMTL+QQzVnTWYbDLgyZYt0jJcsd65aI9SctpARXpGuFiWpVHq3Ss+oqJT+Xw0H 277w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=xPUeud69Li27tzlHGV4C1j0Ahz9/ERlQn2mqA9ff6HM=; b=GTeBR0PTG0maCJb+VPOniVKzYeEV19UXs1DxCB0YJPxISwv8MA2em/lYfq/O6fbTeV nezKmGQDquyX6DZR6sT8pNL/6DiOxgdWsCg0OpG7Sz3muU29NsmEHRM2pd9ux2f6Tw/r VXNwPSaAUE+j8/c9tDqaqguctw+7wbYj57XvTjsfTsjcJxy9PYFKtYzLiq2/etgDHG7B h1TYgrbc/EmnK09JgLgZ9wDvfQWNbnf2LKEPDUDf67mAqJp06cbg7SEVxX48ewkhm/Bs ZfYA0io2zUeiDEy0HZiaoBbQP15vHWJ606MUr1uavseppO/2wc6t7vOxbobezyWn3c3R xrbw== X-Gm-Message-State: ALyK8tKPczV6VcwFuCLlnbXg8hjz2385pEMgWMqDe2ITd8XynEcFZXn6IeSnoYYAcvufSg== X-Received: by 10.25.40.8 with SMTP id o8mr1465165lfo.22.1467554259967; Sun, 03 Jul 2016 06:57:39 -0700 (PDT) Received: from [10.144.0.7] (host-37-191-220-247.lynet.no. [37.191.220.247]) by smtp.googlemail.com with ESMTPSA id j12sm3942124lfb.37.2016.07.03.06.57.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 03 Jul 2016 06:57:38 -0700 (PDT) To: "Salz, Rich" , Daniel Kahn Gillmor , IETF OpenPGP References: <87d1muyh70.fsf@alice.fifthhorseman.net> From: Kristian Fiskerstrand Message-ID: <51e9f5c2-fe2a-a699-aa0c-15114cf948f3@sumptuouscapital.com> Date: Sun, 3 Jul 2016 15:57:31 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="j5w8Tgfw2119IKfSR8KkRDFiHveQSJP9w" Archived-At: Subject: Re: [openpgp] time representation in OpenPGP X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2016 13:57:45 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --j5w8Tgfw2119IKfSR8KkRDFiHveQSJP9w Content-Type: multipart/mixed; boundary="oMCbTwO34ILqxxSQKRET4irdmmuGcVbr6" From: Kristian Fiskerstrand To: "Salz, Rich" , Daniel Kahn Gillmor , IETF OpenPGP Message-ID: <51e9f5c2-fe2a-a699-aa0c-15114cf948f3@sumptuouscapital.com> Subject: Re: [openpgp] time representation in OpenPGP References: <87d1muyh70.fsf@alice.fifthhorseman.net> In-Reply-To: --oMCbTwO34ILqxxSQKRET4irdmmuGcVbr6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 07/03/2016 03:48 PM, Salz, Rich wrote: >=20 >> A time field is an unsigned four-octet number containing the >> number of seconds elapsed since midnight, 1 January 1970 UTC. >=20 > Isn't that the classic Unix time_t, which expires in 2038? signed vs unsigned integers (although iirc it isn't explicitly defined for time_t in C) >=20 > I suggest we use ASN1 generalized time (which has only a couple of > bytes overhead) or ISO 8601 profiled to be like the ASN1 format: > YYYY-MM-DD-HH:MM:SS.sss with fraction optional. >=20 ASN1 sounds complex in this case, some form of ISO8601 variant might be helpful. Alternatively expanding the size of the value from 32 bits to 64 bits might be easier to deal with for backwards compatibility reasons. --=20 ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP certificate at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- "Happiness in intelligent people is the rarest thing I know." (Ernest Hemingway) --oMCbTwO34ILqxxSQKRET4irdmmuGcVbr6-- --j5w8Tgfw2119IKfSR8KkRDFiHveQSJP9w Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJXeRnOAAoJECULev7WN52FMYIIAIcfUEqIMZtB885FvPv+ZOng S5rK/bsfN44oIOFVWmflukg5plj0PBFG8945SRtDemil6ZLYI2uV1v5L8cDml9ch EBpRMLI2iTDZs6zeAvfp6bPOIVNQQjWKa2af8fG7AyOyimo3C8Tc2IILB/zRpu/t UoqfUI4eRQaExE689rI1PTG9qSBLdvwVubuiwDd+ESn31bCrJl7MkQa8kq+6C9zI R5Rli+U13bK8tNkYSEOoWYo2CkHbd4dbLeXeqv/+DAolVuuTkX1FoxhjBDXhicBh BhCvft+mDRzVCqOhTOkRzSPaHZvvCooRaTpbs+Sc/k2P1sr0j1IjSoZWIF5TbVs= =+aDd -----END PGP SIGNATURE----- --j5w8Tgfw2119IKfSR8KkRDFiHveQSJP9w-- From nobody Sun Jul 3 07:47:06 2016 Return-Path: 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 6350812D0EA for ; Sun, 3 Jul 2016 07:47:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 GdutYfv-wfOz for ; Sun, 3 Jul 2016 07:47:03 -0700 (PDT) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DF6112D0BF for ; Sun, 3 Jul 2016 07:47:03 -0700 (PDT) Received: by mail-vk0-x230.google.com with SMTP id i63so35976658vkb.2 for ; Sun, 03 Jul 2016 07:47:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GuyisuddDZFSjYHgiVmC9N9vhb/jBOdZ90d/R/Fhytk=; b=ggYGhhkAf8wwYsZsMVnQexifeQ74xoWlki4lXyl5RrwBgrPIOIVMFssevbYunJth8r 8mMM6rbmNNdQa4SyYS5Ko7IVc0RzndmhX7upvSyqIbNc9Lxpf6Bx7QDM3bXabebp4stx 3BRXgZEGsGOi9/R6WAeTBjqKXM9cRnn9+1vY6q8gpy5cfJxTijpHSDL/phCmCiS90eWl DFrB9mZy7XOYA5P2sKNtAvDmUpQtuaqAjs0JMT7g6bShMw9MDmFtbW0adD8VPFpgmOED IGK7aBfZNuPob2xr4WlbNRpMDnZl19cVD02rQE8P66O89dClL94X4U7LLI5xkEUc6cxT b1HA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GuyisuddDZFSjYHgiVmC9N9vhb/jBOdZ90d/R/Fhytk=; b=GxYViRo/MlyrEjKM3x/DssCdaTFhdO6lNsSR6DPd749u0x4f79TmM9Gdzj92WNaRH7 D+P9rxQHyi4dcUBtk3heFqjqlcaKYALIGpjmMU7/KV5aG5ZDb1ZDRK99wZLldLKgI4zd 6xR1uwjRBHWAje8VOfP4GBuzFE4DfsDgRXludv9MYr0NQobKndQ5PN7CV2X1K3gjgAo5 V7gVIcYEgvfS7alvpt2YD0hPWaaNAAYtC1jHjNQ8kcxaW5I4M6MpwpNMJptmOSQWZMIW KhQMWQQMGj5umUHgQyPwbCWDQ1/cdYiX6tnygNfvKTVeQgk26aeGF/C3bVLOrMX6Htf0 eAxg== X-Gm-Message-State: ALyK8tKUJf19UFfg7i4TJcCT6059Zfz5E6/MBSxTFzVtNVy+DnzNThOHjc9qC3Y1kUCGIDP9Xwo1WmUNEMyYog== X-Received: by 10.159.39.193 with SMTP id b59mr1830919uab.109.1467557222036; Sun, 03 Jul 2016 07:47:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.39.194 with HTTP; Sun, 3 Jul 2016 07:47:01 -0700 (PDT) In-Reply-To: References: <20160701153304.332d2c95@pc1> <9A043F3CF02CD34C8E74AC1594475C73F4CB8706@uxcn10-5.UoA.auckland.ac.nz> From: Watson Ladd Date: Sun, 3 Jul 2016 07:47:01 -0700 Message-ID: To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Derek Atkins , IETF OpenPGP , =?UTF-8?Q?Hanno_B=C3=B6ck?= , Peter Gutmann Subject: Re: [openpgp] Can the OpenPGP vs. S/MIME situation be fixed? X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2016 14:47:05 -0000 On Sat, Jul 2, 2016 at 5:24 PM, Phillip Hallam-Baker wrote: > > > On Sat, Jul 2, 2016 at 11:08 AM, Peter Gutmann > wrote: >> >> Phillip Hallam-Baker writes: >> >> >I have wanted this for a long time. there are actually three separate >> >problems to be solved. >> > >> >1) How to make S/MIME work with OpenPGP credentials >> > >> >2) How to make OpenPGP work with S/MIME credentials >> > >> >3) How to merge the two specifications into one. >> >> The first two are pretty easy, I've been doing that for years. For >> S/MIME, >> use the subjectKeyIdentifier form of the key ID. For PGP, use an >> issuerAndSerialNumber in a type-and-value subpacket. >> >> The third is impossible. While at an abstract level PGP and S/MIME do the >> same thing, the bit-bagging formats used to encode the abstraction are >> completely incompatible. You can't make them compatible without either >> moving >> S/MIME to the PGP format or PGP to the S/MIME format. I can't see either >> of >> those happening... The other issue, which is sadly overlooked, is implementation simplicity and UX. Both OpenPGP and S/MIME fail hard on this front for reasons that cannot be fixed easily. If Adam Langley and I cannot easily send encrypted emails to each other (fun story about a summer internship I had) without screwing up multiple times, what hope for the rest of us? Has anyone fuzzed S/MIME clients to see if they parse X509 correctly? My guess is some do, most don't, and you will find exploitable bugs. > > > That would clearly be impossible if it was what was being proposed. > > What I am suggesting is rather different, A new application for managing > encrypted content, Word, Powerpoint, PDF, etc. that has crypto designed into > the metal and also provides a messaging capability. > > I am suggesting Blu Ray, not trying to develop adapters to play VHS on > Betamax. > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp > -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Sun Jul 3 09:49:50 2016 Return-Path: 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 6273012D115 for ; Sun, 3 Jul 2016 09:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (3072-bit key) header.d=crustytoothpaste.net 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 4n2wrcZXEGlL for ; Sun, 3 Jul 2016 09:49:47 -0700 (PDT) Received: from castro.crustytoothpaste.net (sandals-1-pt.tunnel.tserv8.dal1.ipv6.he.net [IPv6:2001:470:1f0e:3f1::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5148F12D0CD for ; Sun, 3 Jul 2016 09:49:47 -0700 (PDT) Received: from vauxhall.crustytoothpaste.net (unknown [IPv6:2001:470:b978:101:6680:99ff:fe4f:73a0]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by castro.crustytoothpaste.net (Postfix) with ESMTPSA id 880FB282A8 for ; Sun, 3 Jul 2016 16:49:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=crustytoothpaste.net; s=default; t=1467564585; bh=fXL+l+h8D0uaBuroN2S4/s6T/C5wYjURvalzB8yyvkA=; h=Date:From:To:Subject:References:In-Reply-To:From; b=YM776y+5ZCfz4OQzanOcSV7TGU0wJP9ybZqBphxRP5zhijVA4IsHspzOQEj5HtdMQ OredLfO2nt2cnTwuvf4OqUKgu8C9r21MSaEWKB16nhruLBU/j8NYxm7x9GSkrf9CW6 EpaWWJeBdCaeaW8QeX3NGTn5Tp7K8mr2wQ8JvsZ7yBRQm8h8uEf/CRSDSQ45j6R2dP C6uF9SCncSJSufXlqduGC7AK6WWK/PUkqBMt0jPRacckGTyo/OejzeYHYTde70T1U/ KPgTuXRPzZfv9sRcop6yBVaZb1M9QwVOuL0u5vkFX+ZRzOsXHjXMqbSfRvatciZDdd LcGW19ZSLqGKGB3QMknaSFfIhqMEaKFgGxyy8niJEEmdiNYC8QIf69ctC5acnZWppv okP0lJ7UoZmbGsu9CaG76MiBPfrGdMOKLAf9lPEiFqqDQovwG/QP94va+b+QyASAWH icGD2VxjqOnj8VejAqkHkgqwKu/IBmEtBtRi90GOGLpuSZwLEYU Date: Sun, 3 Jul 2016 16:49:42 +0000 From: "brian m. carlson" To: IETF OpenPGP Message-ID: <20160703164942.GB327700@vauxhall.crustytoothpaste.net> References: <87d1muyh70.fsf@alice.fifthhorseman.net> <51e9f5c2-fe2a-a699-aa0c-15114cf948f3@sumptuouscapital.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="6sX45UoQRIJXqkqR" Content-Disposition: inline In-Reply-To: <51e9f5c2-fe2a-a699-aa0c-15114cf948f3@sumptuouscapital.com> X-Machine: Running on vauxhall using GNU/Linux on x86_64 (Linux kernel 4.6.0-1-amd64) User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [openpgp] time representation in OpenPGP X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2016 16:49:49 -0000 --6sX45UoQRIJXqkqR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 03, 2016 at 03:57:31PM +0200, Kristian Fiskerstrand wrote: > On 07/03/2016 03:48 PM, Salz, Rich wrote: > > I suggest we use ASN1 generalized time (which has only a couple of > > bytes overhead) or ISO 8601 profiled to be like the ASN1 format: > > YYYY-MM-DD-HH:MM:SS.sss with fraction optional. > >=20 >=20 > ASN1 sounds complex in this case, some form of ISO8601 variant might be > helpful. >=20 > Alternatively expanding the size of the value from 32 bits to 64 bits > might be easier to deal with for backwards compatibility reasons. I'd strongly recommend simply using a 64-bit (signed?) integer. It's compact, avoids time zones (which are a source of bugs), and is the logical extension. If we use an ISO-8601 variant, it should actually conform with ISO 8601 (unlike GeneralizedTime), and provide a unique encoding for a given time. Determinism and uniqueness help avoid collisions and other types of attacks that might come down the line later, and makes validation much easier. --=20 brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | https://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: https://keybase.io/bk2204 --6sX45UoQRIJXqkqR Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.1.13 (GNU/Linux) iQIcBAEBCgAGBQJXeUImAAoJEL9TXYEfUvaLvl4QALwBAxcV1G9igMH3ZhQTQTZL nDAYEtuT3c4/lKU1Spq2ZC6VTeqHZNXyBmOztG+Yu8jnNTdvEjVJzNOzznhd2G3g HJjkSs8zjFGhp9A2F8hIj7R0axMCAXEGn5FAFfcKlRJZGm8mJ9+eMw9iCmQd8tPC +Lr2MxjoA8kgpdVWBFpH5Nu/F602NKcb6xDLQcIU8J/61AU+pasPcGVEhAqGV8D7 HFbu+qUr3kRnQInGEQtp2BbTjdkuN9Key3FhhOa5jyf5Q/JPeVmpEipEMeQY9rTX SoE/m7eCkm5l2CiT6LvA/rdHkCWznsK95yZHIDAO281jaCYjBO+QIiB7aLuGjgtq 9437bEFR224kJtokq47HMgrEQVvxqXQxTwBEB7cjdBXBi5YkcpZXlLtO4f9W1RwT dnAkCTkESsEMBecPqZ5cbF8uMy5fKrdGOIEPiuTAXq4KXkx/vpZ5gLLLS/uHroA/ XD6VjJJaHYUHkexdzNGZI+Rr6E8636JRZZNiz3wfGNGrYLuvXGi7Tdjd6PbB6+6M mQt0ZbVKbji6oSFjBf56nAc7USht9ZkLyApJtkfuaG8Gsrq8XbdnS0t1VP1bGcPy iliNTI99WxvqVUl1WDZoHGSlh/A1uieyh+qhIIRTk6Nq3A0U00ngav/rPzz0tbYu +bhQ4atR0mJpF9omzGF8 =hSB1 -----END PGP SIGNATURE----- --6sX45UoQRIJXqkqR-- From nobody Sun Jul 3 09:53:26 2016 Return-Path: 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 B00D612D115 for ; Sun, 3 Jul 2016 09:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sumptuouscapital-com.20150623.gappssmtp.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 QAv3i0LqdZCa for ; Sun, 3 Jul 2016 09:53:22 -0700 (PDT) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13FF9128E19 for ; Sun, 3 Jul 2016 09:53:22 -0700 (PDT) Received: by mail-lf0-x235.google.com with SMTP id q132so104460668lfe.3 for ; Sun, 03 Jul 2016 09:53:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sumptuouscapital-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=28cFv132Lno7YbzcDxc8qzHnp/5S0FIxZsovmBuVLiQ=; b=CsVdWIzO5RaPxuMkftINNU3cN8dHmqBqCmPtlb+dGXHSBUgM+ApbGWhDT13kJuzLvE 8whPPwI9RA9TGP0RzJ9f3aRQKBCuZoJmnuFJFNZZzCre8jWOfEcaWdwUfh3B1vcJcAcP /87n+KBOLNDknydIX5o8h1PpKwJmDNVNagSJkoCWJVQgW6eEaRXZj9veRedcAIISvAz8 pm9eQc1ympPoX+6S976ZwC1ANs+g/DgGw2hhmPa51CIq7d9iFQ5dnYUWMZfua0gv7HNA k6i3NUc3MqTc7M0vgXfsgHfhshIhmifSfbV3w1E0CMnPPJpbsVhQrK7Led4qQY4N7dzd tAiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=28cFv132Lno7YbzcDxc8qzHnp/5S0FIxZsovmBuVLiQ=; b=c+/ZBedZJfq/sqUuYITKr+rwmhLn60bm6xY5n9LKZXGHz+OHGIDzxf++qqUZX/qu4S 4vjCrxgugiBrkRMiJClfsXtZwFlX+mi6A4SPCUxVwFGFOD6GrPOnb7rtGIIgeCq+JuOm uj/cKPHltqbwwoTOpJf88HrE0HbtcLo0LEmRWqTnZuXi1Jo6wmMoY+iGQkLKD0aF1MlQ NvAOYdEs99vgtXha/87OUlGRAgYAZyV2EJX71GaUj5wIufd4xDKFPLXI6WUy20OuVdwZ KHNIUlYok+jaiKCQd2yqs/PJQXgFKfnnFIk417n7Yjh20x116U1nX4vWJffWsnfW+7c3 8aLQ== X-Gm-Message-State: ALyK8tINkfK8jVaKK5PRkO7hHdN3wCWsNasJaM0JMTxYUADFD3YbsCwsrhwgjYUY9KtCZg== X-Received: by 10.25.16.210 with SMTP id 79mr2291428lfq.127.1467564799966; Sun, 03 Jul 2016 09:53:19 -0700 (PDT) Received: from [10.144.0.7] (host-37-191-220-247.lynet.no. [37.191.220.247]) by smtp.googlemail.com with ESMTPSA id u13sm2454605lja.15.2016.07.03.09.53.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 03 Jul 2016 09:53:18 -0700 (PDT) To: "brian m. carlson" , IETF OpenPGP References: <87d1muyh70.fsf@alice.fifthhorseman.net> <51e9f5c2-fe2a-a699-aa0c-15114cf948f3@sumptuouscapital.com> <20160703164942.GB327700@vauxhall.crustytoothpaste.net> From: Kristian Fiskerstrand Message-ID: Date: Sun, 3 Jul 2016 18:53:14 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <20160703164942.GB327700@vauxhall.crustytoothpaste.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="bUD0bRodUkMNHIoPFd7XLJPlX6TBNT4w7" Archived-At: Subject: Re: [openpgp] time representation in OpenPGP X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2016 16:53:24 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --bUD0bRodUkMNHIoPFd7XLJPlX6TBNT4w7 Content-Type: multipart/mixed; boundary="j4HRxg5rb39m8PwaQGqe90anSLXuQis6j" From: Kristian Fiskerstrand To: "brian m. carlson" , IETF OpenPGP Message-ID: Subject: Re: [openpgp] time representation in OpenPGP References: <87d1muyh70.fsf@alice.fifthhorseman.net> <51e9f5c2-fe2a-a699-aa0c-15114cf948f3@sumptuouscapital.com> <20160703164942.GB327700@vauxhall.crustytoothpaste.net> In-Reply-To: <20160703164942.GB327700@vauxhall.crustytoothpaste.net> --j4HRxg5rb39m8PwaQGqe90anSLXuQis6j Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 07/03/2016 06:49 PM, brian m. carlson wrote: > On Sun, Jul 03, 2016 at 03:57:31PM +0200, Kristian Fiskerstrand wrote: >> On 07/03/2016 03:48 PM, Salz, Rich wrote: >>> I suggest we use ASN1 generalized time (which has only a couple of >>> bytes overhead) or ISO 8601 profiled to be like the ASN1 format: >>> YYYY-MM-DD-HH:MM:SS.sss with fraction optional. >>> >> >> ASN1 sounds complex in this case, some form of ISO8601 variant might b= e >> helpful. >> >> Alternatively expanding the size of the value from 32 bits to 64 bits >> might be easier to deal with for backwards compatibility reasons. >=20 > I'd strongly recommend simply using a 64-bit (signed?) integer. It's current is 32 bit unsigned, so it'd be unsigned still > compact, avoids time zones (which are a source of bugs), and is the This could be countered by specifying always using UTC, but I agree the parsing is more complex than a simple time epoch without any obvious benefits. --=20 ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP certificate at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- Donec eris sospes, multos numerabis amicos. Tempora si fuerint nubila, solus eris. As long as you are wealthy,you will have many friends. When the tough times come, you will be left alone --j4HRxg5rb39m8PwaQGqe90anSLXuQis6j-- --bUD0bRodUkMNHIoPFd7XLJPlX6TBNT4w7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJXeUL6AAoJECULev7WN52FbhAH/i7Bbm2APAfEnCxEm8IWwha8 6ZZAcIEoCcOedCw6xjMbNH7qvZWJxl3vaIItNliog61aE/CIgcexq+4eFqdpQtuN KM2/lDxUAVDBLquNIz0UxAhQa9S6j7SetTZkCWDQ7ZCAeJsM/ab0SraMR2pENe+O GZZtUCRJ+nU3AyuBRzrOlRQuKXlJxAWdy/iVJ26xnKsMecQpHwGKHjHED7vGgjzl g/cSK88s0KE1f02ehmOQOhq+XASbs/68TTV49S6ZJ1HrCQGKsbbgUHkqgSVaedxg PJoyw1iWJVZjJn1ciafdoIcuO3MPF65+JTy08iWn0+/nqvjH0wtJp4xkE9t5dEo= =Q8vf -----END PGP SIGNATURE----- --bUD0bRodUkMNHIoPFd7XLJPlX6TBNT4w7-- From nobody Sun Jul 3 16:26:28 2016 Return-Path: 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 2D78512D14F for ; Sun, 3 Jul 2016 16:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no 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 mNltTu-iWTKa for ; Sun, 3 Jul 2016 16:26:24 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id A551B12D14A for ; Sun, 3 Jul 2016 16:26:24 -0700 (PDT) Received: from fifthhorseman.net (c-174-62-194-216.hsd1.ct.comcast.net [174.62.194.216]) by che.mayfirst.org (Postfix) with ESMTPSA id 668C6F98B; Sun, 3 Jul 2016 19:26:23 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id BA154202B6; Sun, 3 Jul 2016 19:26:22 -0400 (EDT) From: Daniel Kahn Gillmor To: Hanno =?utf-8?Q?B=C3=B6ck?= , IETF OpenPGP In-Reply-To: <20160701153304.332d2c95@pc1> References: <20160701153304.332d2c95@pc1> User-Agent: Notmuch/0.22+69~gd812194 (https://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Sun, 03 Jul 2016 19:26:19 -0400 Message-ID: <874m86xq04.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] Can the OpenPGP vs. S/MIME situation be fixed? X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2016 23:26:26 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Fri 2016-07-01 09:33:04 -0400, Hanno B=C3=B6ck wrote: > IMHO a big problem with e-mail encryption is that there are two > competing "official" standards: OpenPGP and S/MIME. Both are RFCs, so > both have a kinda "official" IETF approval. > I think it was a big mistake to create two competing standards in the > first place, but that was back in the 90s. So we may ask if we want to > live forever with this situation or if it can be fixed. I agree with Hanno that this is a real concern, but we're currently chartered with a simpler goal: revising the OpenPGP standard to use sensible modern crypto going forward. If we can do that well, then i'd be all for thinking about a PGP/MIME update also, but i'd rather not hold up 4880bis on this. I think we should be clear about what it would take to do what you're proposing; there are two main angles: * certificate interoperability (OpenPGP certs vs. X.509 certs) * message interoperability (PGP/MIME vs. S/MIME) We should avoid foreclosing either form of interop with 4880bis, and if simple modifications to 4880bis point the way toward easier future interop without bogging down the process, including them would be fine. But anything that obstructs or delays the goals of the charter should probably be put off for future work. (and remember: if we sort out 4880bis rapidly, "future work" doesn't have to mean "the far future" -- let's show that we can get a straightforward 4880bis done this year or early 2017 at the latest!) --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJXeZ8bXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFREIyRTc0RjU2RkNGMkI2NzI5N0I3MzUy NEVDRkY1QUZGNjgzNzBBAAoJECTs/1r/aDcKnWMP/RiPlzIXMYa++VvmtCOkEaIg QnknWQ8R/vGuaD43+w23V2vfJn+lIXWbGIsoePQslLWm5vZ/h4CiuvQoO56DkFuU x8no4Yc3pDnES2K/U6a/kcqJJw1Yq1yX/29JpbBn7XIOQEz3uSeTMp/MBJICKrbB jcGyxx4OSPD3rsCgMUTCe1Ga680RDFFmHo50A38I4CRgu9nxrMFn0Tx01GjWPfGu Bf53IgOBR9oNaMS2xSQRWdyBYIxTk/6IvDwhcheM03AHAoPEgsh6jswv+q7I+e72 vEZAt5JvfUXbxyS9HFlUfKpRxm3c8++yJtchzM4/aNswT139xOliplBtRBmC+e0a /ixWgDGtgSaqbW8COiYLcSb3IfSnaJgG5WRFfVIN61F7eha5DcK2y7RVddby3iHH re4OZzV7TfYVVtXLHbRbP8XF0OKpFGLwcyuZ2RjJ9MBuaoMWca4iF5+RhxFmvA0g y25pL2jYP7EY25pIMeJJjWNPW/QR+Og3W3JBio+QPO0NCftGGfVHuph4qmkZml6C iFvoXMCeImd4pyTtnxtJaAA1Qzf2R1qxFOxF3CRDtjQyFptJ+d2HFuXciWM4T24H 567+30i1O9CSxe/jQffuqmJshI+LMU6wkbL7wRIo30uTiKBwK0sig8WtTHLGrXqh XkrFtBb0PCickVAKO4ZF =I88c -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Jul 3 20:41:29 2016 Return-Path: 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 0250B12D091 for ; Sun, 3 Jul 2016 20:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 9gaOKH-6H7z4 for ; Sun, 3 Jul 2016 20:41:24 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D910C12B01B for ; Sun, 3 Jul 2016 20:41:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1467603683; x=1499139683; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=11FfhzarekBMTkklVo9milv1/exrA+sz26fSDi6bUqU=; b=oCTmExySm5KI6rtAZ3SDci3KNZCabJ20+iqyFQyca25wssbto6cbIvkL oY9n3+hslbIeKg3CNKAn82C7oTKYJ79gj/LgwdIsVtaq8SSUGruM2Q9CG NwKVx1QyrfuZvwTtBm1C7/TWX6Lg1TUmc2ldv2jEMtnAoqXKfQKmmrVRW f/wVhLDH/7C4CYptyIY3sde8Cao5m8gQ+usxov8WJYkdoe434DHXr4+Hb YBFwkDpDgTUeqoGRRxzqxRXTWX0PRUd8x772jh5/Vh++29r5qQOz2iQdY rnLe0EsRIhXp9JRD7tqWLDdeNOdy9QL0H14Bh+ppNY78A2QQBFAMf0EdN Q==; X-IronPort-AV: E=Sophos;i="5.26,572,1459771200"; d="scan'208";a="94819549" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 04 Jul 2016 15:41:18 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.93]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0266.001; Mon, 4 Jul 2016 15:41:18 +1200 From: Peter Gutmann To: Daniel Kahn Gillmor , =?iso-8859-1?Q?Hanno_B=F6ck?= , IETF OpenPGP Thread-Topic: [openpgp] Can the OpenPGP vs. S/MIME situation be fixed? Thread-Index: AQHR050jpR81NF3KlE2UhFa6MyYJKaAGlDWAgAEQVZg= Date: Mon, 4 Jul 2016 03:41:18 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4CB97D2@uxcn10-5.UoA.auckland.ac.nz> References: <20160701153304.332d2c95@pc1>, <874m86xq04.fsf@alice.fifthhorseman.net> In-Reply-To: <874m86xq04.fsf@alice.fifthhorseman.net> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.6.2.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [openpgp] Can the OpenPGP vs. S/MIME situation be fixed? X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2016 03:41:28 -0000 Daniel Kahn Gillmor writes:=0A= =0A= >I think we should be clear about what it would take to do what you're=0A= >proposing; there are two main angles:=0A= >=0A= >* certificate interoperability (OpenPGP certs vs. X.509 certs)=0A= =0A= This is easily solved in a technical spec, just define (to use the approach= =0A= I've been using in my code, which as worked more or less seamlessy for some= =0A= years), the use of sKID for S/MIME and issuerAndSerialNumber for PGP.=0A= =0A= >* message interoperability (PGP/MIME vs. S/MIME)=0A= =0A= This can't be solved by a technical spec, it's an application issue which y= ou=0A= resolve by e.g. writing a PGP plugin for Outlook.=0A= =0A= Peter.=0A= From nobody Sun Jul 3 21:05:32 2016 Return-Path: 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 4505112D1DC for ; Sun, 3 Jul 2016 21:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 QnXAfCBmvYRX for ; Sun, 3 Jul 2016 21:05:28 -0700 (PDT) Received: from resqmta-po-01v.sys.comcast.net (resqmta-po-01v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:160]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 009CD12D1D3 for ; Sun, 3 Jul 2016 21:05:27 -0700 (PDT) Received: from resomta-po-08v.sys.comcast.net ([96.114.154.232]) by resqmta-po-01v.sys.comcast.net with SMTP id Jv8RbOWdvkzylJv8RbJxRl; Mon, 04 Jul 2016 04:05:27 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1467605127; bh=6E3z8u6Z7kbKywWI0UtR0VnTiX186rxaR1KmZFiwATE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=KvuPUrXF9sAnB8Mc7iPjNJNkONVfpIOrI/ygZlTxTVEBR5WTbvsSCLkDzOdfv/jYI jFTIs8LHs66vq0JMEivP+el5M9OmNd+ml7Dq5AJ3IwBjcoRaliEwAw1j3PnzP+7U+p a1I4sHephjbjB9LX0oophwo+upDxh0zgCmrUD3pDarwVcTuSU8xP8hyoV8xgPOS7Ji 3x9iabsQdtgHPrcjIs4DI4B8WWUK51gXnHwQaeaP7Z4eKWq8C2pKqnb8uW04O/CC2f MofimNy3uYe6MT40F5DE2xj2jwmXD5mIMLXlw434L+lKlfwECEGogvOvZyaJxn6R6V gn6sCef0RKdPQ== Received: from [192.168.0.10] ([76.103.100.237]) by resomta-po-08v.sys.comcast.net with comcast id EU5S1t00457Jnqc01U5S0x; Mon, 04 Jul 2016 04:05:27 +0000 Message-ID: <5779E086.9000506@brainhub.org> Date: Sun, 03 Jul 2016 21:05:26 -0700 From: Andrey Jivsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: openpgp@ietf.org References: <20160701153304.332d2c95@pc1>, <874m86xq04.fsf@alice.fifthhorseman.net> <9A043F3CF02CD34C8E74AC1594475C73F4CB97D2@uxcn10-5.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4CB97D2@uxcn10-5.UoA.auckland.ac.nz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] Can the OpenPGP vs. S/MIME situation be fixed? X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2016 04:05:30 -0000 On 07/03/2016 08:41 PM, Peter Gutmann wrote: > Daniel Kahn Gillmor writes: > >> I think we should be clear about what it would take to do what you're >> proposing; there are two main angles: >> >> * certificate interoperability (OpenPGP certs vs. X.509 certs) > This is easily solved in a technical spec, just define (to use the approach > I've been using in my code, which as worked more or less seamlessy for some > years), the use of sKID for S/MIME and issuerAndSerialNumber for PGP. Commercial PGP products used this type of "same key, two certificates" paradigm for over a decade. Some of this is documented in http://www.ietf.org/mail-archive/web/openpgp/current/msg01742.html (that's what PGP Corp. did; this write-up is incomplete). One issue with storing OpenPGP KeyID in X.509 Subject Key Identifier (SKI) is that over the last decade and earlier popular S/MIME clients were not using SKI to identify a recipient. Instead, they were using the X.509 cert's Issuer and SN. Therefore, one will have to encode OpenPGP keyID into the SN of the X.509 cert to be able to locate the OpenPGP key later from the encrypted S/MIME message. This works if the ecosystem owns an issuing X.509 Sub-CA, so that it's possible to control the SNs. > >> * message interoperability (PGP/MIME vs. S/MIME) > This can't be solved by a technical spec, it's an application issue which you > resolve by e.g. writing a PGP plugin for Outlook. > > Peter. > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp From nobody Sun Jul 3 21:14:47 2016 Return-Path: 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 A3B5D12D1E6 for ; Sun, 3 Jul 2016 21:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 vIFTrcZC7zgt for ; Sun, 3 Jul 2016 21:14:44 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8BBE12B01B for ; Sun, 3 Jul 2016 21:14:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1467605683; x=1499141683; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=bfAwzibSsvMUtQJPJbdSMOSQ0RwOM2u9uNZ2Ih4agoM=; b=svE2wQbY2a7zzx0TWQN3Ha/y/m6uFW45SLEiW6uM7NUhA9t4thTjFa+j wEEaSYcdyLNl1BxHRxhxN/42VoXtB1S4JCvtUlzhFICx4hMf0eFsPw2t1 a0dw32RhmR3KtiVYyPdxHu0mS3XbwK19Ab4vk5Y81G6y/jpVeaTXi4ZZH 01u3LLbg6iPYxk9WOWqSN9pCNY4wiIfV5KWGJakiH9RaTvrKi3pHObCR1 7DjNeTwIsb84g1TiJ1h6LUS0LO113n19MKauX2BMINLLW5YE2Swb0P71R qSAm/COwWTziMPaJXpXJi+FRRnfV/DdT1vctLh8MrnZwRlPaJoAYVvyD1 Q==; X-IronPort-AV: E=Sophos;i="5.26,573,1459771200"; d="scan'208";a="94826677" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 04 Jul 2016 16:14:40 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.93]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0266.001; Mon, 4 Jul 2016 16:14:40 +1200 From: Peter Gutmann To: Andrey Jivsov , "openpgp@ietf.org" Thread-Topic: [openpgp] Can the OpenPGP vs. S/MIME situation be fixed? Thread-Index: AQHR050jpR81NF3KlE2UhFa6MyYJKaAGlDWAgAEQVZj//z2nAIAAy69z Date: Mon, 4 Jul 2016 04:14:39 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4CB9814@uxcn10-5.UoA.auckland.ac.nz> References: <20160701153304.332d2c95@pc1>, <874m86xq04.fsf@alice.fifthhorseman.net> <9A043F3CF02CD34C8E74AC1594475C73F4CB97D2@uxcn10-5.UoA.auckland.ac.nz>, <5779E086.9000506@brainhub.org> In-Reply-To: <5779E086.9000506@brainhub.org> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.6.2.3] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [openpgp] Can the OpenPGP vs. S/MIME situation be fixed? X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2016 04:14:47 -0000 Andrey Jivsov writes:=0A= =0A= >One issue with storing OpenPGP KeyID in X.509 Subject Key Identifier (SKI)= is=0A= >that over the last decade and earlier popular S/MIME clients were not usin= g=0A= >SKI to identify a recipient. Instead, they were using the X.509 cert's Iss= uer=0A= >and SN. Therefore, one will have to encode OpenPGP keyID into the SN of th= e=0A= >X.509 cert to be able to locate the OpenPGP key later from the encrypted= =0A= >S/MIME message. This works if the ecosystem owns an issuing X.509 Sub-CA, = so=0A= >that it's possible to control the SNs.=0A= =0A= We'd really need to get more data on what can handle sKID, since in my case= =0A= the use is all closed environments (banking, embedded, SCADA, etc) it's eas= y=0A= enough to simply specify that the implementation needs to support sKID but= =0A= there's no current data (that I know of) on general support. In any case I= =0A= think getting a small number of implementations to support sKID is going to= be=0A= vastly easier than asking CAs to put PGP IDs into certs.=0A= =0A= In any case it doesn't cost anything to put the sKID/iAndS details into the= =0A= spec, and if you want it you've at least got an interoperable way of doing = it.=0A= =0A= Peter.=0A= From nobody Mon Jul 4 18:59:15 2016 Return-Path: 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 6648712B063 for ; Mon, 4 Jul 2016 18:59:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 2aKfAY5uI7sP for ; Mon, 4 Jul 2016 18:59:12 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D809B12B02B for ; Mon, 4 Jul 2016 18:59:11 -0700 (PDT) X-AuditID: 1209190d-c4fff70000005a55-58-577b146d9af1 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id D9.F1.23125.D641B775; Mon, 4 Jul 2016 21:59:10 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id u651x8wK022815; Mon, 4 Jul 2016 21:59:09 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u651x5Zc004061 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 4 Jul 2016 21:59:08 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id u651x5G7003847; Mon, 4 Jul 2016 21:59:05 -0400 (EDT) Date: Mon, 4 Jul 2016 21:59:05 -0400 (EDT) From: Benjamin Kaduk To: "brian m. carlson" In-Reply-To: <20160703164942.GB327700@vauxhall.crustytoothpaste.net> Message-ID: References: <87d1muyh70.fsf@alice.fifthhorseman.net> <51e9f5c2-fe2a-a699-aa0c-15114cf948f3@sumptuouscapital.com> <20160703164942.GB327700@vauxhall.crustytoothpaste.net> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDIsWRmVeSWpSXmKPExsUixCmqrZsnUh1uMCvJouHfQ3aLtpk/mByY PJbf/MvksWTJT6YApigum5TUnMyy1CJ9uwSujIezNjIV3GSveL7hCWsDYwdbFyMnh4SAiUTn yvmMXYxcHEICbUwSh9bNYIJwNjBK7N+8lRXCOcgksWTdf2aQFiGBeonHxzvYQWwWAS2JNTu2 go1iE1CRmPlmI5gtImAqseT9PiYQm1lAWWLlzetAcQ4OYaD4hm0xIGFOAReJKROWsIDYvAIO EuuP7mSD2PWeUWLtxZdg80UFdCRW758CVSQocXLmExaImVoSy6dvY5nAKDALSWoWktQCRqZV jLIpuVW6uYmZOcWpybrFyYl5ealFukZ6uZkleqkppZsYwQEpybuD8d9dr0OMAhyMSjy8BfOr woVYE8uKK3MPMUpyMCmJ8r76BxTiS8pPqcxILM6ILyrNSS0+xCjBwawkwvtQoDpciDclsbIq tSgfJiXNwaIkzhtz82iYkEB6YklqdmpqQWoRTFaGg0NJgtdAGKhRsCg1PbUiLTOnBCHNxMEJ MpwHaPgekBre4oLE3OLMdIj8KUZdjgU/bq9lEmLJy89LlRLnPS8EVCQAUpRRmgc3B5xIdjOp vmIUB3pLmPcBSBUPMAnBTXoFtIQJaAlrbDnIkpJEhJRUA2OGZpdT7YM/vucPGmxSd8utlZv3 Qs64uaszL3au5bRXcomTRS5kmgrJOeizqB6Za8VqqWbKM3/hyQ3xBat/7ct9KHjzQ8ndhndB ikmeZqY6G0UWm69YIiKz+ZTtofkst7tMv21ifu6pvdF7w438lgkLmr6xKxcInepR1Xl1t3UL N3/M9OnMv5RYijMSDbWYi4oTAUl25w7/AgAA Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] time representation in OpenPGP X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2016 01:59:13 -0000 On Sun, 3 Jul 2016, brian m. carlson wrote: > On Sun, Jul 03, 2016 at 03:57:31PM +0200, Kristian Fiskerstrand wrote: > > On 07/03/2016 03:48 PM, Salz, Rich wrote: > > > I suggest we use ASN1 generalized time (which has only a couple of > > > bytes overhead) or ISO 8601 profiled to be like the ASN1 format: > > > YYYY-MM-DD-HH:MM:SS.sss with fraction optional. > > > > > > > ASN1 sounds complex in this case, some form of ISO8601 variant might be > > helpful. > > > > Alternatively expanding the size of the value from 32 bits to 64 bits > > might be easier to deal with for backwards compatibility reasons. > > I'd strongly recommend simply using a 64-bit (signed?) integer. It's > compact, avoids time zones (which are a source of bugs), and is the > logical extension. I've seen 64-bit integer measuring in quanta of 100ns in a few places, FWIW. The finer granularity doesn't really eat into the usable range, for a couple axes of future-proofing. -Ben From nobody Mon Jul 4 19:29:29 2016 Return-Path: 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 4162D12D09C for ; Mon, 4 Jul 2016 19:29:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.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 k-iXRTI2mWp0 for ; Mon, 4 Jul 2016 19:29:26 -0700 (PDT) Received: from st13p27im-asmtp004.me.com (st13p27im-asmtp004.me.com [17.162.190.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 870A212B04B for ; Mon, 4 Jul 2016 19:29:26 -0700 (PDT) Received: from process-dkim-sign-daemon.st13p27im-asmtp004.me.com by st13p27im-asmtp004.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) id <0O9T00S00L673D00@st13p27im-asmtp004.me.com> for openpgp@ietf.org; Tue, 05 Jul 2016 02:29:25 +0000 (GMT) Received: from [10.0.23.7] (media.merrymeet.com [173.164.244.98]) by st13p27im-asmtp004.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) with ESMTPSA id <0O9T00E2JLKZKL10@st13p27im-asmtp004.me.com> for openpgp@ietf.org; Tue, 05 Jul 2016 02:29:25 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-07-05_01:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1015 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1510270003 definitions=main-1607050022 Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Jon Callas In-reply-to: <5779E086.9000506@brainhub.org> Date: Mon, 04 Jul 2016 19:29:23 -0700 Content-transfer-encoding: quoted-printable Message-id: References: <20160701153304.332d2c95@pc1> <874m86xq04.fsf@alice.fifthhorseman.net> <9A043F3CF02CD34C8E74AC1594475C73F4CB97D2@uxcn10-5.UoA.auckland.ac.nz> <5779E086.9000506@brainhub.org> To: IETF OpenPGP X-Mailer: Apple Mail (2.3124) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=4d515a; t=1467685765; bh=QWw+eXQSWPmgI4X1ntB1U8/gVDq6G7BuREkDaEliKPM=; h=Content-type:MIME-version:Subject:From:Date:Message-id:To; b=UWGFIeUNOOh5yVB8Mw36R2+LOzNawh0Iu6qLTuFwStRZFFO/HNt5C7zGJY75s6sPX AV7lKMzH3SrEri7FLGToU7w8zRRH58iRdtkgIhi5rI2SHqPzjFawizW/8FFCYJK7Db 83dY8a7TdzbGRQzVC+q7VU8obM+TEWbde3kUdRZxQFR83Ziyyt1lZz/oonxojXKDAK ZrFpDoZwEMKTokcDIPfiaGkFGTbTLY87suS/14q3zd/L1kNylh7G6yAIRTNwrCVoFt yt1swimDLSEXZE5FDODhL2j1oecZ86tA6VfHq4mMT57ttaQ1mj8ytosFdVzfkaP4JT NYqbvmqRBCZVw== Archived-At: Subject: Re: [openpgp] Can the OpenPGP vs. S/MIME situation be fixed? X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2016 02:29:28 -0000 To chime in with Peter and Andrey, this is something that can done in = software. Not everything needs to be done in protocol.=20 Whatever the details, one can (and perhaps should) use the same key = material and dress it up in whatever uniform one wants, OpenPGP or = S/MIME.=20 While on the surface, it kinda seems like a good idea to unify the two = in protocol, that's a different task than either group has. A new = protocol would want to be a new protocol. Despite each protocol being = used in much the same way (especially in email), there are a lot of = things that would have to be re-hashed out. There's how you issue certificates (the whole CA/introducer issue(s)), = whether certs contain one key or key sets, how they are transported = (S/MIME puts them in the message, OpenPGP in directories etc.), and even = the role of the internal layering. Note that OpenPGP is a binary (and = UTF-8 is still binary) object protocol with a drizzling of MIME-encoding = frosting over the top. That frosting is subject to its own = interpretations. S/MIME in contrast *starts* with the email and MIME = object and underneath there's CMS, usually almost as an afterthought. = (Did you have a momentary "huh?" in your head when you read CMS? Many = people do, and that's the point.) S/MIME starts at the top, OpenPGP = starts at the bottom. And oh, there are also other things that have to be re-hashed like ASN.1 = all over again and the things it drags along like encoding rules. This = is a good deal why perhaps its better to just push the other things up = into software. The reason that there are the two standards is that they = address different views of the world, technical as well as political.=20 At the end of the day, there are many things you *have* to push up into = software. Consider the case where I am sending an email (which often = happens, but may not even be the primary case in OpenPGP, merely the one = that comes first to mind) to Alice, Bob, and Charlie. It's indeed = irritating that Alice has an OpenPGP key and Bob an S/MIME certificate, = and I am thus going to have to code up two copies of the message. It = is, however, straightforward. I know what to do. The subtlety comes from = the fact that Charlie is being BCCed. It doesn't matter what happens = with Charlie, whatever encoding we use (even plaintext) we have to send = that message separately. You have to handle this at the software level = no matter what. Even with a unified crypto standard, messaging isn't = just crypto. Unless the unifying protocol is so compelling that people of all stripes = can agree that we should drop the old ones and go to this, we merely = have a reification of an XKCD cartoon -- we'll have *three* protocols = that have to exercised at the proper software level in exactly the same = way you'd have to hand it with two. Trying to simplify will almost = certainly just make things more complex. Jon From nobody Mon Jul 4 19:41:11 2016 Return-Path: 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 DB87912D0C1 for ; Mon, 4 Jul 2016 19:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.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 8E_psHpBaFn9 for ; Mon, 4 Jul 2016 19:41:08 -0700 (PDT) Received: from st13p27im-asmtp003.me.com (st13p27im-asmtp003.me.com [17.162.190.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2C8712B02B for ; Mon, 4 Jul 2016 19:41:08 -0700 (PDT) Received: from process-dkim-sign-daemon.st13p27im-asmtp003.me.com by st13p27im-asmtp003.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) id <0O9T01000LVIX700@st13p27im-asmtp003.me.com> for openpgp@ietf.org; Tue, 05 Jul 2016 02:41:08 +0000 (GMT) Received: from [10.0.23.7] (media.merrymeet.com [173.164.244.98]) by st13p27im-asmtp003.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) with ESMTPSA id <0O9T01A0ZM4HRX30@st13p27im-asmtp003.me.com>; Tue, 05 Jul 2016 02:41:07 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-07-05_01:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=69 spamscore=69 clxscore=1011 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1510270003 definitions=main-1607050024 Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Jon Callas In-reply-to: Date: Mon, 04 Jul 2016 19:41:05 -0700 Content-transfer-encoding: quoted-printable Message-id: <96DA2212-53E6-4F6E-AAF5-433921A3429E@icloud.com> References: <87d1muyh70.fsf@alice.fifthhorseman.net> <51e9f5c2-fe2a-a699-aa0c-15114cf948f3@sumptuouscapital.com> <20160703164942.GB327700@vauxhall.crustytoothpaste.net> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3124) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=4d515a; t=1467686467; bh=M+pVF0z/yMqL05jWPFJLXOO0z1K7EhNKoZw6iepPnJc=; h=Content-type:MIME-version:Subject:From:Date:Message-id:To; b=qBP8aNZg2q13vmKiNZBBBp/O49GWgcBLsZStudMx54Et8CF4Qnqu7j8Gc6jXpizy7 FUK3YzzSUaVBtG9WTTiA4z+g5IWaU8V/JluJ+ikDgonwpF9KkjjeFRhy468kk4UskJ TFI0UG4K1nUsIOjZnRelTTiVggYg77nUdBcu7HmMWKVoOaK0TDG7QekaaoUJpr7gK8 FtCX2z3R4KETqXmlc4hyk5rUf62q2qMzM6jpQFtRC/au/9s8pbIcME5Tyj986/nmzj J4yInkDmWDYSyI3e8nk6GHK0Xev0gCtMB2qAIP6WlBipcYwC0NrOjPTFPKp11XBd7O y33TOxb/ZyS3w== Archived-At: Cc: IETF OpenPGP , "brian m. carlson" , Jon Callas Subject: Re: [openpgp] time representation in OpenPGP X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2016 02:41:10 -0000 >>=20 >> I'd strongly recommend simply using a 64-bit (signed?) integer. It's >> compact, avoids time zones (which are a source of bugs), and is the >> logical extension. Signed only if you really want to express negative time in some way. I = think that negative time to express times *before* the zero date is a = great idea. >=20 > I've seen 64-bit integer measuring in quanta of 100ns in a few places, > FWIW. The finer granularity doesn't really eat into the usable range, = for > a couple axes of future-proofing. Yes, that's VMS. It was a 100ns tick, with a zero-time of 17-Nov-1858 = (that's the zero time of the American Ephemeris and more or less Julian = Day One Million) and used negative time to express delta times rather = than absolute. Even with that, it's fine into five-digit years. Jon From nobody Tue Jul 5 01:07:07 2016 Return-Path: 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 3221F12D111 for ; Tue, 5 Jul 2016 01:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.386 X-Spam-Level: X-Spam-Status: No, score=-5.386 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, URIBL_RHS_DOB=1.514] autolearn=ham autolearn_force=no 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 RMH-LwWteOO4 for ; Tue, 5 Jul 2016 01:07:02 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B75A812D0B0 for ; Tue, 5 Jul 2016 01:07:02 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1bKLNk-0001BC-6l for ; Tue, 05 Jul 2016 10:07:00 +0200 Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1bKLHU-0001Qd-T2; Tue, 05 Jul 2016 10:00:32 +0200 From: Werner Koch To: Daniel Kahn Gillmor References: <87d1muyh70.fsf@alice.fifthhorseman.net> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: url=https://k.gnupg.net/80615870F5BAD690333686D0F2AD85AC1E42B367 Mail-Followup-To: Daniel Kahn Gillmor , IETF OpenPGP Date: Tue, 05 Jul 2016 10:00:32 +0200 In-Reply-To: <87d1muyh70.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Sun, 03 Jul 2016 09:38:59 -0400") Message-ID: <87twg45xb3.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] time representation in OpenPGP X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2016 08:07:05 -0000 On Sun, 3 Jul 2016 15:38, dkg@fifthhorseman.net said: > This wraps around in early 2106, if my math is correct. Right, in the morning of February 7, 2106. But only if the same calendar and time notation will be used in 90 years. I do not think we should make assumption for such a long time span. Will computers and protocols be similar how we currently think about them? Who was able to imagine today's technology back in 1926? Nowadays technologies develops even more rapid than we assumed 40 years ago. > Would someone like to propose an alternate representation of time for > RFC 4880bis? Or is there a clear argument for keeping it as-is? I'd say to keep the format as it is now. If in 50 years there is still a need for the OpenPGP protocol, a re-chartered WG could easily introduce a, say, v8 key and signature format with a 40 bit value for seconds since Epoch or whatever format will be en vogue by then (maybe keeping the 32 bits and switching the Epoch to 2063-04-05). If we really want to introduce this now, I would suggest to add an extra zero octet right before any timestamp. This can eventually be used as a 40 bit timestamps with only minor code changes. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ From nobody Tue Jul 5 01:17:04 2016 Return-Path: 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 70F3E12D169 for ; Tue, 5 Jul 2016 01:17:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.386 X-Spam-Level: X-Spam-Status: No, score=-5.386 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, URIBL_RHS_DOB=1.514] autolearn=ham autolearn_force=no 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 SkwO0xLzgaCg for ; Tue, 5 Jul 2016 01:17:02 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C58FF12D149 for ; Tue, 5 Jul 2016 01:17:01 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1bKLXQ-0001GC-5R for ; Tue, 05 Jul 2016 10:17:00 +0200 Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1bKLSi-0001VI-SZ; Tue, 05 Jul 2016 10:12:08 +0200 From: Werner Koch To: "Salz\, Rich" References: <87d1muyh70.fsf@alice.fifthhorseman.net> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: url=https://k.gnupg.net/80615870F5BAD690333686D0F2AD85AC1E42B367 Mail-Followup-To: "Salz\, Rich" , Daniel Kahn Gillmor , IETF OpenPGP Date: Tue, 05 Jul 2016 10:12:08 +0200 In-Reply-To: (Rich Salz's message of "Sun, 3 Jul 2016 13:48:44 +0000") Message-ID: <87poqs5wrr.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: Cc: IETF OpenPGP , Daniel Kahn Gillmor Subject: Re: [openpgp] time representation in OpenPGP X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2016 08:17:03 -0000 On Sun, 3 Jul 2016 15:48, rsalz@akamai.com said: > Isn't that the classic Unix time_t, which expires in 2038? Only with 32 bit signed time_t. The C standard declares time_t as implementation defined and thus it can also be an unsigned 32 bit int or 64 bit. The only requirement is that (time_t)(-1) is used as an error return value. > I suggest we use ASN1 generalized time (which has only a couple of > bytes overhead) or ISO 8601 profiled to be like the ASN1 format: > YYYY-MM-DD-HH:MM:SS.sss with fraction optional. Due to real world problems, I use the compact 8601 representation ot time for GnuPG's X.509 part: "20160704T100951" makes a nice 16 bytes buffer (with the string terminator) and can be easily printed. However, using a buffer is not very convenient compared to a scalar like time_t. And you need to write a lot of code for basic operations (consider a wrong encoded string). That does not mean, I would suggest to use such a string in OpenPGP which has been designed as a compact binary protocol. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ From nobody Tue Jul 5 01:49:47 2016 Return-Path: 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 9C00A12D0AB for ; Tue, 5 Jul 2016 01:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sumptuouscapital-com.20150623.gappssmtp.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 ODYsFiDUuihI for ; Tue, 5 Jul 2016 01:49:44 -0700 (PDT) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA70112B037 for ; Tue, 5 Jul 2016 01:49:43 -0700 (PDT) Received: by mail-lf0-x234.google.com with SMTP id f6so130128559lfg.0 for ; Tue, 05 Jul 2016 01:49:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sumptuouscapital-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=jR7JfJU101hJAPpBhVTZuXrx+V6do9Sm3GtfsSKplJo=; b=lxd5fgQ9IfZTqWWckXXirxdcNnRff6Rk8eteagvl2KA+NmuH3EOsp66/PTD/ilgJCv llaUBBuIXZOVORsLVgYJGx4Sv9DS91Cp/fYP5cKOL+yIyaPVNMkNboqcvYmfH1SL6i74 8M0zh/5ogEk4j0biq36JhkafAKORLY5IPBdc4vOC8jlqdJcFsFugJVlCOob6SjQ8kNKO GLssgVRrIEjMdL5lon3YkG8ucsGcySpQhrpZchKLsu6grSzwXOEcjWSdOK2Y+n5x2NPV BKIPp8Cc5XxGzUYbB2sC3Cdguj2vh1Kl4Lnku8QuU6+YkmyT2nbge4UrZdCgagZYMVIq kGzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=jR7JfJU101hJAPpBhVTZuXrx+V6do9Sm3GtfsSKplJo=; b=UiQfLPVA9YKexfUtvUlEMbTLnHAzq8CUVQ+O3zFUPUtEsP6X+9LT8L1RjU0rWoFzZN BY/P4pk/RNg/81KSnF0WXaZs6Ukwor5IbubUvbln2xlB6jYjInceB/2jRsUKhyt3zU/T WNqe6w3InrpSuSSPtOZ0K7IRjk0TpxUGuUJI7v+OJhp/uOnlPLoAf/GAIxeXXRLFVygD IvVc/s2UIOmZB9ITSBsfroKs3fFpzYqyPYc3CIVFFtDZzDAI86m8BMv0IOQBj0ywYjpN ltsKspxAnvSyxil/DqqxGAXX1a2O2E4h48IxFRe+7lxaqQOC2+tVfvjyP2FkGHE2TkZH 0cWw== X-Gm-Message-State: ALyK8tIVrJmHVYLH5qego4+nFzx4/iEUdc4N7TOvCA5Z8IA4TRPh5+pFjRk7guxfjStFGA== X-Received: by 10.25.16.96 with SMTP id f93mr4190407lfi.114.1467708581539; Tue, 05 Jul 2016 01:49:41 -0700 (PDT) Received: from [10.201.199.36] ([88.151.161.13]) by smtp.googlemail.com with ESMTPSA id g28sm3945307lji.45.2016.07.05.01.49.40 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Jul 2016 01:49:40 -0700 (PDT) To: IETF OpenPGP References: <87d1muyh70.fsf@alice.fifthhorseman.net> <87twg45xb3.fsf@wheatstone.g10code.de> From: Kristian Fiskerstrand Message-ID: Date: Tue, 5 Jul 2016 10:49:36 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <87twg45xb3.fsf@wheatstone.g10code.de> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="e163aMw6WDNQ2VG6qNrOjRCPwRsLuuK6r" Archived-At: Subject: Re: [openpgp] time representation in OpenPGP X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2016 08:49:45 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --e163aMw6WDNQ2VG6qNrOjRCPwRsLuuK6r Content-Type: multipart/mixed; boundary="vs7tqdUo1r1I1ooBrFbmMtuNTtD5Ok0lR" From: Kristian Fiskerstrand To: IETF OpenPGP Message-ID: Subject: Re: [openpgp] time representation in OpenPGP References: <87d1muyh70.fsf@alice.fifthhorseman.net> <87twg45xb3.fsf@wheatstone.g10code.de> In-Reply-To: <87twg45xb3.fsf@wheatstone.g10code.de> --vs7tqdUo1r1I1ooBrFbmMtuNTtD5Ok0lR Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 07/05/2016 10:00 AM, Werner Koch wrote: > I'd say to keep the format as it is now.=20 I agree with keeping the existing format --=20 ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP certificate at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- "If you choose to sail upon the seas of banking, build your bank as you would your boat, with the strength to sail safely through any storm." (Jacob Safra (1891=E2=80=931963)) --vs7tqdUo1r1I1ooBrFbmMtuNTtD5Ok0lR-- --e163aMw6WDNQ2VG6qNrOjRCPwRsLuuK6r Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJXe3SgAAoJECULev7WN52FQcYH/3/hEb7So/f+qvVibkJpDcAr tAmqfe9Ar70ylclLwtbidODpxIbcQmvHWkzecLUky3piKC8ykfT6n2Dz7gZPYoTL o/2R9NxwouCF5G7YD9tpPbdyI+4oSAg2pJwgM/QgOjh4IgOUlxBWxym4ABy2guw4 25/rZb04ae8V+GfuNbCPB4jYIgmvQE/EedWHZePeMdcqE9jw7ylwXCYm935g712W lBM+vsVrYIC45UxQ1LSTBDShptBOJAPajBVdkqJOAcVYfZc8KaqaXDP+Rvb6YJRO Byhhilu2CsUlOVLrCmLCQm7gtNzqOuqXqikej9I5pt4+ZooIK5wJqllMUQ1+5A0= =XxTM -----END PGP SIGNATURE----- --e163aMw6WDNQ2VG6qNrOjRCPwRsLuuK6r-- From nobody Tue Jul 5 16:05:26 2016 Return-Path: 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 BE2C312B032 for ; Tue, 5 Jul 2016 16:05:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 EpZSV0pDEHmL for ; Tue, 5 Jul 2016 16:05:22 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75A0F12B02F for ; Tue, 5 Jul 2016 16:05:22 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id c34so108726711qte.0 for ; Tue, 05 Jul 2016 16:05:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=7937uF2gdQ8YIirFq8gAODe2rBSAah32rX2vwIh+eHM=; b=DnduBmnG3UGu4Q6F2r+E32TyfbB8NkgVNOf3PbI+ePTkFBHMVOuaEP+faTr7M5spuH euXfZ+cTAOC1LWsZfVaraSQ6U+g4vsUKFxnp17b104pZBHeAzChbQkoFRYkU94bWtGJO NX9EarPXYi1pdx7SiQMbMY0qv4TblODaMCDs7Q092lrltpWhpUVjbOs28G9G4Q5kiDPx LSizTZnb8TPnVHJ2pYHuQKxXCCcnfE/ylpKbwUTZzZJEU6/IBr+WAbNO0jl1E0L0WERR IF6Wvc44BGJWwuLUQlgU5DKGj12E5sU9qXYLos2Xk+UXf2dBbHkZsir+lG+rMISv7PSd MB3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=7937uF2gdQ8YIirFq8gAODe2rBSAah32rX2vwIh+eHM=; b=JIn8dtkvrbhWL1USqI1fExYS83Gbpgul73QITVhsEHFptVsdHFjXCQ1wMt9fLhvyVU GJawiBxjoxWTZNcyo3H/k8Rh+4F/glRNqn6QIigIqmlt5JJ8FS23vNMUtQkNWNnG/+BG HSSHSGqkifpo+Kj0nud9pFuv/vV3qrf4v8g3WitAMDjEbnKOc6CL6aQViBdh69KI/4aE HqPGWNh0Y1dtiCtlAA0Pj33BoO4QTsJyO0YkPuAkr3jb+MH1SJcpemgVs1KZOBRXcLz+ DUk58SWq61auYaiIiZO9I9nS//ZOpOxFIUGILZWSxW0Ztzv8bqPRNcoXcKl/x1X6AYA+ iyqw== X-Gm-Message-State: ALyK8tJWm2CXTdoCBERjlQLDTNPwPIDdaUp4ug8olPU9rvSqLBHzVJ4FboUqGnIV7eIfAHNBznMlkPzZQjVTTQ== X-Received: by 10.200.40.181 with SMTP id i50mr31057955qti.89.1467759921498; Tue, 05 Jul 2016 16:05:21 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.55.16.106 with HTTP; Tue, 5 Jul 2016 16:05:20 -0700 (PDT) In-Reply-To: References: <20160701153304.332d2c95@pc1> <874m86xq04.fsf@alice.fifthhorseman.net> <9A043F3CF02CD34C8E74AC1594475C73F4CB97D2@uxcn10-5.UoA.auckland.ac.nz> <5779E086.9000506@brainhub.org> From: Phillip Hallam-Baker Date: Tue, 5 Jul 2016 19:05:20 -0400 X-Google-Sender-Auth: _xDWhmyKSiINpovkhQvHZiOB4j0 Message-ID: To: Jon Callas Content-Type: multipart/alternative; boundary=001a113efaaabc93ed0536eb7cba Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] Can the OpenPGP vs. S/MIME situation be fixed? X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2016 23:05:24 -0000 --001a113efaaabc93ed0536eb7cba Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jul 4, 2016 at 10:29 PM, Jon Callas wrote: > To chime in with Peter and Andrey, this is something that can done in > software. > > Not everything needs to be done in protocol. > > Whatever the details, one can (and perhaps should) use the same key > material and dress it up in whatever uniform one wants, OpenPGP or S/MIME= . > > While on the surface, it kinda seems like a good idea to unify the two in > protocol, that's a different task than either group has. A new protocol > would want to be a new protocol. Despite each protocol being used in much > the same way (especially in email), there are a lot of things that would > have to be re-hashed out. > =E2=80=8B The only reason to introduce a new protocol would be to introduce features that aren't currently supported and would require a substantial re-engineering of the legacy protocols. Now I think I have actually found such a feature and might even write a client to demonstrate it. But that would be in addition to supporting S/MIME and OpenPGP etc. Because the lesson we learned on the Web was that the gateways to legacy systems were what allowed the Web to beat systems like HyperG etc. that most independent observers would have said were 'better' at the time. I think that the idea of OpenPGP Key Server + Linked Timestamp (aka Blockchain) is very powerful. I also think that I don't like ASN.1 or PGP data encoding and a modern protocol should have a really good reason for not using JSON or JSON plus extensions to support binary blobs without Base64 armoring. [OK I lied about saying I don't like ASN.1, I utterly despise it, there are few things I loathe more] > There's how you issue certificates (the whole CA/introducer issue(s)), > whether certs contain one key or key sets, how they are transported (S/MI= ME > puts them in the message, OpenPGP in directories etc.), and even the role > of the internal layering. Note that OpenPGP is a binary (and UTF-8 is sti= ll > binary) object protocol with a drizzling of MIME-encoding frosting over t= he > top. That frosting is subject to its own interpretations. S/MIME in > contrast *starts* with the email and MIME object and underneath there's > CMS, usually almost as an afterthought. (Did you have a momentary "huh?" = in > your head when you read CMS? Many people do, and that's the point.) S/MIM= E > starts at the top, OpenPGP starts at the bottom. > > And oh, there are also other things that have to be re-hashed like ASN.1 > all over again and the things it drags along like encoding rules. This is= a > good deal why perhaps its better to just push the other things up into > software. The reason that there are the two standards is that they addres= s > different views of the world, technical as well as political. > =E2=80=8BTwo views of the world that are rather absolutist and thus wrong. = Some parts of the world are hierarchical, others are not. A trust infrastructure needs to support both. But it isn't clear such infrastructure is best implemented inside a client. =E2=80=8B > At the end of the day, there are many things you *have* to push up into > software. Consider the case where I am sending an email (which often > happens, but may not even be the primary case in OpenPGP, merely the one > that comes first to mind) to Alice, Bob, and Charlie. It's indeed > irritating that Alice has an OpenPGP key and Bob an S/MIME certificate, a= nd > I am thus going to have to code up two copies of the message. It is, > however, straightforward. I know what to do. The subtlety comes from the > fact that Charlie is being BCCed. It doesn't matter what happens with > Charlie, whatever encoding we use (even plaintext) we have to send that > message separately. You have to handle this at the software level no matt= er > what. Even with a unified crypto standard, messaging isn't just crypto. > > Unless the unifying protocol is so compelling that people of all stripes > can agree that we should drop the old ones and go to this, we merely have= a > reification of an XKCD cartoon -- we'll have *three* protocols that have = to > exercised at the proper software level in exactly the same way you'd have > to hand it with two. Trying to simplify will almost certainly just make > things more complex. > =E2=80=8BIf it is only a question of merging S/MIME and OpenPGP functionali= ty, I don't see it. But Proxy Re-Encryption is a lot more powerful. Essentially it is the next logical step in crypto. The trick in crypto is that we introduce a new key for each function. Public key crypto is more powerful because encryption is separate from decryption. With Proxy Re-Encryption we have Lora who is managing a mailing list and she has a key that can add new members to the list, and we have the mailing list encryption key and we have the per-user decryption keys. Going from two key crypto to three key crypto is powerful --001a113efaaabc93ed0536eb7cba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Jul 4, 2016 at 10:29 PM, Jon Callas <joncallas@icloud.com> wrote:
To chime in w= ith Peter and Andrey, this is something that can done in software.

Not everything needs to be done in protocol.

Whatever the details, one can (and perhaps should) use the same key materia= l and dress it up in whatever uniform one wants, OpenPGP or S/MIME.

While on the surface, it kinda seems like a good idea to unify the two in p= rotocol, that's a different task than either group has. A new protocol = would want to be a new protocol. Despite each protocol being used in much t= he same way (especially in email), there are a lot of things that would hav= e to be re-hashed out.

=E2=80=8B
The only reason to introduce a new protocol would be to introdu= ce features that aren't currently supported and would require a substan= tial re-engineering of the legacy protocols.=C2=A0

Now I think I= have actually found such a feature and might even write a client to demons= trate it. But that would be in addition to supporting S/MIME and OpenPGP et= c. Because the lesson we learned on the Web was that the gateways to legacy= systems were what allowed the Web to beat systems like HyperG etc. that mo= st independent observers would have said were 'better' at the time.=

I think that the idea of OpenPGP Key Server + Linked Timestamp = (aka Blockchain) is very powerful. I also think that I don't like ASN.1= or PGP data encoding and a modern protocol should have a really good reaso= n for not using JSON or JSON plus extensions to support binary blobs withou= t Base64 armoring.


[OK I lied about saying I don't like ASN.1, I utterly des= pise it, there are few things I loathe more]

=C2=A0
There's how you issue certificates (the whole CA/introducer issue(s= )), whether certs contain one key or key sets, how they are transported (S/= MIME puts them in the message, OpenPGP in directories etc.), and even the r= ole of the internal layering. Note that OpenPGP is a binary (and UTF-8 is s= till binary) object protocol with a drizzling of MIME-encoding frosting ove= r the top. That frosting is subject to its own interpretations. S/MIME in c= ontrast *starts* with the email and MIME object and underneath there's = CMS, usually almost as an afterthought. (Did you have a momentary "huh= ?" in your head when you read CMS? Many people do, and that's the = point.) S/MIME starts at the top, OpenPGP starts at the bottom.

And oh, there are also other things that have to be re-hashed like ASN.1 al= l over again and the things it drags along like encoding rules. This is a g= ood deal why perhaps its better to just push the other things up into softw= are. The reason that there are the two standards is that they address diffe= rent views of the world, technical as well as political.

=E2=80=8BTwo views of the world that are rather absolutist and t= hus wrong. Some parts of the world are hierarchical, others are not. A trus= t infrastructure needs to support both. But it isn't clear such infrast= ructure is best implemented inside a client.
=E2=80=8B
=C2=A0
At the end of the day, there are many things you *have* to push up into sof= tware. Consider the case where I am sending an email (which often happens, = but may not even be the primary case in OpenPGP, merely the one that comes = first to mind) to Alice, Bob, and Charlie. It's indeed irritating that = Alice has an OpenPGP key and Bob an S/MIME certificate, and I am thus=C2=A0= going to have to code up two copies of the message. It is, however, straig= htforward. I know what to do. The subtlety comes from the fact that Charlie= is being BCCed. It doesn't matter what happens with Charlie, whatever = encoding we use (even plaintext) we have to send that message separately. Y= ou have to handle this at the software level no matter what. Even with a un= ified crypto standard, messaging isn't just crypto.

Unless the unifying protocol is so compelling that people of all stripes ca= n agree that we should drop the old ones and go to this, we merely have a r= eification of an XKCD cartoon -- we'll have *three* protocols that have= to exercised at the proper software level in exactly the same way you'= d have to hand it with two. Trying to simplify will almost certainly just m= ake things more complex.

=E2=80=8BIf it is onl= y a question of merging S/MIME and OpenPGP functionality, I don't see i= t.

But Proxy Re-Encryption is a lot more powerful. Essentially it is the next= logical step in crypto. The trick in crypto is that we introduce a new key= for each function. Public key crypto is more powerful because encryption i= s separate from decryption. With Proxy Re-Encryption we have Lora who is ma= naging a mailing list and she has a key that can add new members to the lis= t, and we have the mailing list encryption key and we have the per-user dec= ryption keys. Going from two key crypto to three key crypto is powerful
=C2=A0
--001a113efaaabc93ed0536eb7cba-- From nobody Wed Jul 6 08:00:33 2016 Return-Path: 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 95DB112D0A4 for ; Wed, 6 Jul 2016 08:00:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) 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 DycpiLte0dNM for ; Wed, 6 Jul 2016 08:00:29 -0700 (PDT) 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 1AD5312B05F for ; Wed, 6 Jul 2016 08:00:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id A9637E203F; Wed, 6 Jul 2016 10:59:57 -0400 (EDT) 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 06418-09; Wed, 6 Jul 2016 10:59:55 -0400 (EDT) Received: from securerf.ihtfp.org (IHTFP-DHCP-159.IHTFP.ORG [192.168.248.159]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id B9B87E2040; Wed, 6 Jul 2016 10:59:54 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1467817194; bh=Wa77qmMVgW8Ghugkr2dxPlAc73UZrTV1z782487W+Og=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=Uj7ykXqBseOptuwAbLCjxl8k0ZUqeGrm/Nu8DPZBfzLRQzwFM9yJZcw5TfHIszYSQ APwUlzdIMXqols9mkMAVfyp416A5CiwHws11oeqTrD6/KvGXF/OqSIu+0YiaVEvFFL wQPieEmkQxI1ESimbOxeVBeDU3feaN4TwTsen69A= Received: (from warlord@localhost) by securerf.ihtfp.org (8.15.2/8.14.8/Submit) id u66Exoe7024818; Wed, 6 Jul 2016 10:59:50 -0400 From: Derek Atkins To: Phillip Hallam-Baker References: <20160701153304.332d2c95@pc1> <874m86xq04.fsf@alice.fifthhorseman.net> <9A043F3CF02CD34C8E74AC1594475C73F4CB97D2@uxcn10-5.UoA.auckland.ac.nz> <5779E086.9000506@brainhub.org> Date: Wed, 06 Jul 2016 10:59:50 -0400 In-Reply-To: (Phillip Hallam-Baker's message of "Tue, 5 Jul 2016 19:05:20 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: IETF OpenPGP , Jon Callas Subject: Re: [openpgp] Can the OpenPGP vs. S/MIME situation be fixed? X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 15:00:31 -0000 Phillip Hallam-Baker writes: > There's how you issue certificates (the whole CA/introducer issue(s)), > whether certs contain one key or key sets, how they are transported (= S/ > MIME puts them in the message, OpenPGP in directories etc.), and even= the > role of the internal layering. Note that OpenPGP is a binary (and UTF= -8 is > still binary) object protocol with a drizzling of MIME-encoding frost= ing > over the top. That frosting is subject to its own interpretations. S/= MIME > in contrast *starts* with the email and MIME object and underneath th= ere's > CMS, usually almost as an afterthought. (Did you have a momentary "hu= h?" > in your head when you read CMS? Many people do, and that's the point.= ) S/ > MIME starts at the top, OpenPGP starts at the bottom. >=20=20=20=20 > And oh, there are also other things that have to be re-hashed like AS= N.1 > all over again and the things it drags along like encoding rules. Thi= s is > a good deal why perhaps its better to just push the other things up i= nto > software. The reason that there are the two standards is that they ad= dress > different views of the world, technical as well as political. > > =E2=80=8BTwo views of the world that are rather absolutist and thus wrong= . Some parts > of the world are hierarchical, others are not. A trust infrastructure nee= ds to > support both. But it isn't clear such infrastructure is best implemented > inside a client. OpenPGP can support hierarchical certificate deployments just fine (my company is building one) as well as the Web of Trust model. X.509 cannot support a Web of Trust deployment, period. So there is a clear winner here. -derek --=20 Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Wed Jul 6 13:26:18 2016 Return-Path: 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 2CC1E12B04E for ; Wed, 6 Jul 2016 13:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 ANpb9pIHfHYW for ; Wed, 6 Jul 2016 13:26:14 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABCC412D123 for ; Wed, 6 Jul 2016 13:26:13 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id j185so84581428ith.0 for ; Wed, 06 Jul 2016 13:26:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=5r0y0mbfxLYE0e+Y24I9jwUEEpZGe3mfscel53ef7bg=; b=YDJhXxe7Uhv3tUmHC/4zUiKRSAGC4zysJkCpefjvFPYCJyhmc612HNZXi5otlL6fs4 3IU1Wz1392MMEjqOTJClfYzjSGrveemhchRX8QJYJ2AkEL6gTH3qIKEjd/6a50r/njd3 0gNY14YHlLp86g+Shr0MNMRk0C4ecIzvZ9FuW7/EGkBWxfgtvg/3NrC59B2jT5/UPNMo KoX72vsK5AqwWwvVzkQp1mhwvb55+Y7aLs2zkMM4MND+Y3bCZwmrJJ6HJwRr7X0QRF17 YFy2GSYHx9bLu3Fa2siV0LENI2BUd6W27kSRFY/BOnt4sEDCzW6xwUqXq7shHoaM1BpH GbWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=5r0y0mbfxLYE0e+Y24I9jwUEEpZGe3mfscel53ef7bg=; b=bOBFLCtfx291mtCjrJ2oGwLprQEuvIW/j/e7dgNfDbObvUb7wdrg+bgxbX/Wnx8o/E dWFL6vIiR3tlOqSMh6kLCIjqytTC/nHarMqiHc8Azq7XkopwGRXtcx9S51r3i8sW5fwX WgHXglDbFYw2EZ9T2fjFxPkU3vYmJxl1G3kLB9+yWheRnCdCGW/rj7/7OS0vI3u5KwfF dgKWW7iKTAk8xgV0UfEDD0xVt5BJAeYNXttqZn1rBnX07zFrKIZCZQTun8WLMiZ4ZpK/ +vNdQxaihsDXx+RixgJ1Yxjx1gSRl9cAOlt71XLcu+IG8wrNXndflXDoO1jn2wZp0eMe Ac7g== X-Gm-Message-State: ALyK8tL2UJeXBGEQWI2u9KqOuttrZ9fBnqreUY8yczyc4YlKDQQgK5ZVeWpXLXxSDTAqdfwb8iGq7d0nO1yHPQ== X-Received: by 10.36.60.80 with SMTP id m77mr20399742ita.96.1467836772825; Wed, 06 Jul 2016 13:26:12 -0700 (PDT) MIME-Version: 1.0 Sender: barryleiba.mailing.lists@gmail.com Received: by 10.107.153.78 with HTTP; Wed, 6 Jul 2016 13:26:12 -0700 (PDT) In-Reply-To: References: <878txtjnf6.fsf@alice.fifthhorseman.net> From: Barry Leiba Date: Wed, 6 Jul 2016 16:26:12 -0400 X-Google-Sender-Auth: K7UuOb4yuzinLAUP04dwh-0bNXY Message-ID: To: IETF OpenPGP Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [openpgp] call for adoption of draft-koch-openpgp-rfc4880bis X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 20:26:16 -0000 And, having heard no objections, I'm going to declare draft-koch-openpgp-rfc4880bis to be adopted. Werner will post draft-ietf-openpgp-rfc4880bis-00 shortly, and active discussion can begin. Barry, as chair On Sun, Jul 3, 2016 at 9:11 AM, Barry Leiba wrote: > Given the responses so far, I think we have enough "yes, adopt" > comments to go forward. So there's no need for more "yes" responses. > Please post any *objections* by Wednesday, 6 July. > > Thanks, > Barry, as chair > > On Sat, Jun 25, 2016 at 11:30 AM, Daniel Kahn Gillmor > wrote: >> hey OpenPGP folks-- >> >> We've had a slow start on 4880bis, but i'm hoping we can get things >> moving again. One of the things we need to do bureaucratically is to >> officially adopt a specific draft as the basis of our ongoing work. >> >> Werner Koch has prepared and submitted the beginnings of the new >> revision of RFC 4880, the current version of which you can see here: >> >> https://tools.ietf.org/html/draft-koch-openpgp-rfc4880bis-02 >> >> This is a call for adoption of this draft by the OpenPGP WG. Please >> speak up soon if you have any concerns, or if you think this document >> should not be adopted by the WG for some reason. Please also speak up >> if you are in favor of adoption. >> >> A brief reminder of what adoption by the WG would mean: >> >> * this draft would become the *starting point* for RFC 4880bis; the >> draft is currently not complete, but it would be the basis upon which >> the group would build the new proposal. >> >> * Werner Koch would be the document editor, but the decisions about the >> draft would be made by the working group. I want to thank Werner for >> his willingness to put in his time as the document editor. >> >> * Since our charter (https://datatracker.ietf.org/wg/openpgp/charter/) >> is aimed primarily at making a revision to RFC 4880, we would >> hopefully focus our efforts on contributing review and amendments to >> this draft, with a goal of driving it to IETF Last Call within the >> year. >> >> Please give feedback on draft adoption! >> >> --dkg >> >> _______________________________________________ >> openpgp mailing list >> openpgp@ietf.org >> https://www.ietf.org/mailman/listinfo/openpgp >> From nobody Wed Jul 6 14:07:04 2016 Return-Path: X-Original-To: openpgp@ietf.org Delivered-To: openpgp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 58EEB12D1C2; Wed, 6 Jul 2016 14:06:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160706210659.26824.8985.idtracker@ietfa.amsl.com> Date: Wed, 06 Jul 2016 14:06:59 -0700 Archived-At: Cc: openpgp@ietf.org Subject: [openpgp] I-D Action: draft-ietf-openpgp-rfc4880bis-00.txt X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 21:06:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Specification for Pretty Good Privacy of the IETF. Title : OpenPGP Message Format Author : Werner Koch Filename : draft-ietf-openpgp-rfc4880bis-00.txt Pages : 107 Date : 2016-07-06 Abstract: { Work in progress to update the OpenPGP specification from RFC4880 } This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OpenPGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network. It does not deal with storage and implementation questions. It does, however, discuss implementation issues necessary to avoid security flaws. OpenPGP software uses a combination of strong public-key and symmetric cryptography to provide security services for electronic communications and data storage. These services include confidentiality, key management, authentication, and digital signatures. This document specifies the message formats used in OpenPGP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-openpgp-rfc4880bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-openpgp-rfc4880bis-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jul 6 14:17:07 2016 Return-Path: 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 09A0012D5A4 for ; Wed, 6 Jul 2016 14:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.386 X-Spam-Level: X-Spam-Status: No, score=-5.386 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, URIBL_RHS_DOB=1.514] autolearn=ham autolearn_force=no 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 GUChO2hW1pKL for ; Wed, 6 Jul 2016 14:17:03 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6BFC12D529 for ; Wed, 6 Jul 2016 14:17:03 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1bKuBp-0001sh-J1 for ; Wed, 06 Jul 2016 23:17:01 +0200 Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1bKu6q-0005yc-I9; Wed, 06 Jul 2016 23:11:52 +0200 From: Werner Koch To: Barry Leiba References: <878txtjnf6.fsf@alice.fifthhorseman.net> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: url=https://k.gnupg.net/80615870F5BAD690333686D0F2AD85AC1E42B367 Mail-Followup-To: Barry Leiba , IETF OpenPGP Date: Wed, 06 Jul 2016 23:11:52 +0200 In-Reply-To: (Barry Leiba's message of "Wed, 6 Jul 2016 16:26:12 -0400") Message-ID: <87furmqxnr.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] call for adoption of draft-koch-openpgp-rfc4880bis X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 21:17:06 -0000 On Wed, 6 Jul 2016 22:26, barryleiba@computer.org said: > draft-koch-openpgp-rfc4880bis to be adopted. Werner will post > draft-ietf-openpgp-rfc4880bis-00 shortly, and active discussion can Just done. See https://tools.ietf.org/html/draft-ietf-openpgp-rfc4880bis-00 Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ From nobody Wed Jul 6 15:12:30 2016 Return-Path: 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 E6A9212D0E9 for ; Wed, 6 Jul 2016 15:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 7JdX6qptjEwY for ; Wed, 6 Jul 2016 15:12:27 -0700 (PDT) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C806D12D0A2 for ; Wed, 6 Jul 2016 15:12:26 -0700 (PDT) Received: by mail-qt0-x233.google.com with SMTP id m2so93083qtd.1 for ; Wed, 06 Jul 2016 15:12:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=yMIZPyJ7rU8JsxGfkeitVC6fT30Nw0rQY3B2djvRdow=; b=tGZYepzpAm/h2Q/WUgEF9Tm/6vT4FH1mgOqql5wUwxSzIbe9vbB4BBDSE/l5dWMRCh 3IPz97UX/FNLbTVJplX1x3lMgoBjv4Vk/rmaAQdrbQWhAZk4dX/PxnECwfqRvMHKbQeD z64sqUTijVgPgEPsOBFdeaDnIp7OtA0UqzJQNbZQC90eheebuUvulywp915zjtcRc8Gw fzzqRwv6zxXm5qjsl+YX+TDAi7/Qsf7j1wbCrYfJkSnojm2UlNle0sTYf7gbNGiQrQEo KHbOt0wpRbYkK4cJBPKpAnAxc6HKgB68IoPB9H9wsdR2pCn2Y3w4JT5b2kxiTOQCQf+i kgIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=yMIZPyJ7rU8JsxGfkeitVC6fT30Nw0rQY3B2djvRdow=; b=j4ZWpbBnMs+/jXkUnp0C/OVvwWEkrYrJTl4Sq+hp8obFq8JHWxIAqzZhPj6TSMzzG6 qLux5CewYNfVkY5CnpTFuit58gjN4lAsfhWMPHVzx+WSO8xdBGIfV1kJUqU+ksvLessy 0oi4zrVaEeqxcwwubZRJyX5JYHalro38hCOvIyutYiAytsnNI9M4zi7DSJuQyDyXZugl E1CnZuqXHOBvKENggZacMPHb6WGwOkhl5plNCl1LmfdPJmNy9k+Ye+91tBujzseqIpMh 4GMXm0C4LLxXCqwpuqbayq/k7PYPyPcft8q+PkHKosUQhN2b+ZPwKEAhzSaMY64U3Ed0 BLXg== X-Gm-Message-State: ALyK8tLfx+soHm8o39Ta5hmnOqswKZLI+F6VjWOhrIJCuTvvIBgG4ef+eAZbNfqbEWyRvwK63tyh6WLWfOx6ww== X-Received: by 10.200.50.237 with SMTP id a42mr39603659qtb.80.1467843145949; Wed, 06 Jul 2016 15:12:25 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.55.16.106 with HTTP; Wed, 6 Jul 2016 15:12:25 -0700 (PDT) In-Reply-To: References: <20160701153304.332d2c95@pc1> <874m86xq04.fsf@alice.fifthhorseman.net> <9A043F3CF02CD34C8E74AC1594475C73F4CB97D2@uxcn10-5.UoA.auckland.ac.nz> <5779E086.9000506@brainhub.org> From: Phillip Hallam-Baker Date: Wed, 6 Jul 2016 18:12:25 -0400 X-Google-Sender-Auth: GO533oduMwkHr0z6K8q_BgMNYyU Message-ID: To: Derek Atkins Content-Type: multipart/alternative; boundary=001a113f4e464cea060536fedd13 Archived-At: Cc: IETF OpenPGP , Jon Callas Subject: Re: [openpgp] Can the OpenPGP vs. S/MIME situation be fixed? X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 22:12:29 -0000 --001a113f4e464cea060536fedd13 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jul 6, 2016 at 10:59 AM, Derek Atkins wrote: > Phillip Hallam-Baker writes: > > > There's how you issue certificates (the whole CA/introducer > issue(s)), > > whether certs contain one key or key sets, how they are transported > (S/ > > MIME puts them in the message, OpenPGP in directories etc.), and > even the > > role of the internal layering. Note that OpenPGP is a binary (and > UTF-8 is > > still binary) object protocol with a drizzling of MIME-encoding > frosting > > over the top. That frosting is subject to its own interpretations. > S/MIME > > in contrast *starts* with the email and MIME object and underneath > there's > > CMS, usually almost as an afterthought. (Did you have a momentary > "huh?" > > in your head when you read CMS? Many people do, and that's the > point.) S/ > > MIME starts at the top, OpenPGP starts at the bottom. > > > > And oh, there are also other things that have to be re-hashed like > ASN.1 > > all over again and the things it drags along like encoding rules. > This is > > a good deal why perhaps its better to just push the other things up > into > > software. The reason that there are the two standards is that they > address > > different views of the world, technical as well as political. > > > > =E2=80=8BTwo views of the world that are rather absolutist and thus wro= ng. Some > parts > > of the world are hierarchical, others are not. A trust infrastructure > needs to > > support both. But it isn't clear such infrastructure is best implemente= d > > inside a client. > > OpenPGP can support hierarchical certificate deployments just fine (my > company is building one) as well as the Web of Trust model. X.509 > cannot support a Web of Trust deployment, period. > > So there is a clear winner here. =E2=80=8B You can in fact make X.509 do Web of trust. You simply give each user their own CA root and cross certify. I was doing that for quite a while till I realized that the legacy stuff was hurting rather than helping. Yes you can get the protocols to do more than the apps let them. But you don't have the advantage of legacy platform support or legacy platform ignoring your stuff in a predictable way. --001a113f4e464cea060536fedd13 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wed, Ju= l 6, 2016 at 10:59 AM, Derek Atkins <derek@ihtfp.com> wrote:
Phillip Hallam-Baker <= phill@hallambaker.com> writ= es:

>=C2=A0 =C2=A0 =C2=A0There's how you issue certificates (the whole C= A/introducer issue(s)),
>=C2=A0 =C2=A0 =C2=A0whether certs contain one key or key sets, how they= are transported (S/
>=C2=A0 =C2=A0 =C2=A0MIME puts them in the message, OpenPGP in directori= es etc.), and even the
>=C2=A0 =C2=A0 =C2=A0role of the internal layering. Note that OpenPGP is= a binary (and UTF-8 is
>=C2=A0 =C2=A0 =C2=A0still binary) object protocol with a drizzling of M= IME-encoding frosting
>=C2=A0 =C2=A0 =C2=A0over the top. That frosting is subject to its own i= nterpretations. S/MIME
>=C2=A0 =C2=A0 =C2=A0in contrast *starts* with the email and MIME object= and underneath there's
>=C2=A0 =C2=A0 =C2=A0CMS, usually almost as an afterthought. (Did you ha= ve a momentary "huh?"
>=C2=A0 =C2=A0 =C2=A0in your head when you read CMS? Many people do, and= that's the point.) S/
>=C2=A0 =C2=A0 =C2=A0MIME starts at the top, OpenPGP starts at the botto= m.
>
>=C2=A0 =C2=A0 =C2=A0And oh, there are also other things that have to be= re-hashed like ASN.1
>=C2=A0 =C2=A0 =C2=A0all over again and the things it drags along like e= ncoding rules. This is
>=C2=A0 =C2=A0 =C2=A0a good deal why perhaps its better to just push the= other things up into
>=C2=A0 =C2=A0 =C2=A0software. The reason that there are the two standar= ds is that they address
>=C2=A0 =C2=A0 =C2=A0different views of the world, technical as well as = political.
>
> =E2=80=8BTwo views of the world that are rather absolutist and thus wr= ong. Some parts
> of the world are hierarchical, others are not. A trust infrastructure = needs to
> support both. But it isn't clear such infrastructure is best imple= mented
> inside a client.

OpenPGP can support hierarchical certificate deployments just fine (= my
company is building one) as well as the Web of Trust model.=C2=A0 X.509
cannot support a Web of Trust deployment, period.

So there is a clear winner here.

=E2=80=8B
You can in fact make X.509 do Web of trust. You simply = give each user their own CA root and cross certify.

I was doing that for quite a= while till I realized that the legacy stuff was hurting rather than helpin= g. Yes you can get the protocols to do more than the apps let them. But you= don't have the advantage of legacy platform support or legacy platform= ignoring your stuff in a predictable way.


=
--001a113f4e464cea060536fedd13-- From nobody Wed Jul 6 16:36:44 2016 Return-Path: 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 D7BE012D5D7 for ; Wed, 6 Jul 2016 16:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) 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 DY42L09_AFX3 for ; Wed, 6 Jul 2016 16:36:37 -0700 (PDT) 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 9957612D145 for ; Wed, 6 Jul 2016 16:36:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 2FFC7E2039; Wed, 6 Jul 2016 19:36:35 -0400 (EDT) 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 09656-05; Wed, 6 Jul 2016 19:36:33 -0400 (EDT) Received: from securerf.ihtfp.org (IHTFP-DHCP-159.IHTFP.ORG [192.168.248.159]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id AB3BEE2030; Wed, 6 Jul 2016 19:36:32 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1467848192; bh=dWC8n8vewvvCyEE57p7W47hg2cdhCHbRfqZAVwyGKVU=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=lFYd14Zi9nPsb5S/NjhNENkApXFy4WwtaTEl84zvx8aP848bOCpoqO8x7vwVFTjo6 v7TL79WALmIP75NBHQf5ymKSI5QlV4B/HzjFOB/sQfrvd7hJssqN9JeGY0iC4ZrYxO +DthllvBzgFSrrrlUcQixzUawSjQCchwNtOkYbiU= Received: (from warlord@localhost) by securerf.ihtfp.org (8.15.2/8.14.8/Submit) id u66NaSqS022439; Wed, 6 Jul 2016 19:36:28 -0400 From: Derek Atkins To: Werner Koch References: Date: Wed, 06 Jul 2016 19:36:28 -0400 In-Reply-To: (Derek Atkins's message of "Thu, 14 Apr 2016 16:12:03 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] Proposed Patch to RFC4880bis to reserve two public key numbers X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 23:36:43 -0000 --=-=-= Content-Type: text/plain Hi, Now that we've accepted the draft, I'd like to re-open this proposal to reserve two public-key algorithm protocol numbers. Note (again) that this is *JUST A RESERVATION* of these numbers, and if you read the patch and still think that you *have* to implement these algorithms then I'd like to hear your wording suggestion for how to fix that misconception. I've re-attached this patch (although I haven't rebased it). My original message is included below. Thanks, -derek > Hi, > > The attached patch to RFC4880bis reserves two public-key parameters. > They are specified as "reserved" and I've added text to 13.8 as well > documenting that they are underspecified. > > Note that these are NOT "MTI" algorithms in any way, shape, or form! > > Thanks, > > -derek --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=rfc4880bis-aedh.diff Content-Description: OpenPGP AE reservation >From b2ffaf54bac27ed59a836e0588cfed8d0097d584 Mon Sep 17 00:00:00 2001 From: Derek Atkins Date: Thu, 14 Apr 2016 16:06:49 -0400 Subject: [PATCH] Add AEDH and AEDSA protocol number reservations --- middle.mkd | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/middle.mkd b/middle.mkd index 033f11f..0fa9efd 100644 --- a/middle.mkd +++ b/middle.mkd @@ -2890,6 +2890,8 @@ algorithms. 21 Reserved for Diffie-Hellman (X9.42, as defined for IETF-S/MIME) 22 EdDSA [](#I-D.irtf-cfrg-eddsa) + 23 Reserved for AEDH + 24 Reserved for AEDSA 100--110 Private/Experimental algorithm Implementations MUST implement DSA and ECDSA for signatures, and @@ -3182,6 +3184,8 @@ This document requests IANA register the following public-key algorithm: ID Algorithm Reference -- -------------------------- --------- 22 EdDSA public key algorithm This doc + 23 Reserved for AEDH This doc + 24 Reserved for AEDSA This doc [Notes to RFC-Editor: Please remove the table above on publication. It is desirable not to reuse old or reserved algorithms because @@ -3950,7 +3954,9 @@ algorithm. These are marked in Section 9.1, "Public-Key Algorithms", as "reserved for". The reserved public-key algorithm X9.42 (21) does not have the -necessary parameters, parameter order, or semantics defined. +necessary parameters, parameter order, or semantics defined. The same +is currently true for reserved public-key algorithms AEDH (23) and +AEDSA (24). Previous versions of OpenPGP permitted Elgamal [](#ELGAMAL) signatures with a public-key identifier of 20. These are no longer permitted. An -- 2.5.0 --=-=-= Content-Type: text/plain -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant --=-=-=-- From nobody Wed Jul 6 23:27:09 2016 Return-Path: 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 9BE9412D0F1 for ; Wed, 6 Jul 2016 23:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no 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 dMU2uVg5qgbs for ; Wed, 6 Jul 2016 23:27:05 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD66212D0E5 for ; Wed, 6 Jul 2016 23:27:04 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1bL2m6-0004zL-Fw for ; Thu, 07 Jul 2016 08:27:02 +0200 Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1bL2jS-0000xd-M1; Thu, 07 Jul 2016 08:24:18 +0200 From: Werner Koch To: Derek Atkins References: Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: url=https://k.gnupg.net/80615870F5BAD690333686D0F2AD85AC1E42B367 Mail-Followup-To: Derek Atkins , openpgp@ietf.org Date: Thu, 07 Jul 2016 08:24:18 +0200 In-Reply-To: (Derek Atkins's message of "Wed, 06 Jul 2016 19:36:28 -0400") Message-ID: <87vb0iotil.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] Proposed Patch to RFC4880bis to reserve two public key numbers X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 06:27:07 -0000 On Thu, 7 Jul 2016 01:36, derek@ihtfp.com said: > Hi, > > Now that we've accepted the draft, I'd like to re-open this proposal to > reserve two public-key algorithm protocol numbers. Note (again) that I opened an issue to track this proposal: https://gitlab.com/openpgp-wg/rfc4880bis/issues/1 Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ From nobody Thu Jul 7 01:17:06 2016 Return-Path: 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 8B76012D115 for ; Thu, 7 Jul 2016 01:17:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no 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 eyoOCAzIXS4v for ; Thu, 7 Jul 2016 01:17:04 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB50F12B044 for ; Thu, 7 Jul 2016 01:17:03 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1bL4UX-0005kk-RF for ; Thu, 07 Jul 2016 10:17:01 +0200 Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1bL4Rt-0001jN-He for ; Thu, 07 Jul 2016 10:14:17 +0200 From: Werner Koch To: openpgp@ietf.org Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: url=https://k.gnupg.net/80615870F5BAD690333686D0F2AD85AC1E42B367 Mail-Followup-To: openpgp@ietf.org Date: Thu, 07 Jul 2016 10:14:17 +0200 Message-ID: <87r3b5q2zq.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: Subject: [openpgp] Tag indicating a MIME content X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 08:17:05 -0000 Hi, I recall that an indication for a MIME content has been proposed many years ago but might have been forgotten. Thus I propose this small change for 4880bis: --8<---------------cut here---------------start------------->8--- diff --git a/middle.mkd b/middle.mkd index 033f11f..5519be3 100644 --- a/middle.mkd +++ b/middle.mkd @@ -2156,7 +2156,8 @@ ## {5.9} Literal Data Packet (Tag 11) may need line ends converted to local form, or other text-mode changes. The tag 'u' (0x75) means the same as 't', but also indicates that implementation believes that the literal data - contains UTF-8 text. + contains UTF-8 text. If it is a 'm' (0x6d), then it contains a + MIME message body part [](#RFC2045). Early versions of PGP also defined a value of 'l' as a 'local' mode for machine-local conversions. RFC 1991 [](#RFC1991) --8<---------------cut here---------------end--------------->8--- MIME has several advantages: Interpretation of the plaintext can be done without considering the context (e.g. part of a PGP/MIME message or standalone). The encoding of the message can be described without resorting to the unprotected armor header. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ From nobody Thu Jul 7 02:23:45 2016 Return-Path: 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 BC18912D50C for ; Thu, 7 Jul 2016 02:23:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.727 X-Spam-Level: X-Spam-Status: No, score=-5.727 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 R-_hHJzuzPAx for ; Thu, 7 Jul 2016 02:23:41 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A811A12D186 for ; Thu, 7 Jul 2016 02:23:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 155C4BDD8; Thu, 7 Jul 2016 10:23:40 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HWPrFz0gNIaq; Thu, 7 Jul 2016 10:23:38 +0100 (IST) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D2BE9BDD0; Thu, 7 Jul 2016 10:23:37 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1467883418; bh=USfC2RdQ6xwg7WSdy0Je29apl/gSfZyyVjRa1tHGx2I=; h=Subject:To:References:From:Date:In-Reply-To:From; b=CqphEu78cZn8//S2DoZa/K6WgGYH5EvsiO3lTJw0onB2EA0MGB/kVY/E4YV5nTsGZ UKwrdnvcL453Ruwy9EaRWFgvANuAxyWcZ0yHnsQGKGRliiBzm+S1Zteg9NADZTFmir W9pc2jJMW095IA9WDVmvCj7zJurtee99dYWSlg0k= To: Derek Atkins , openpgp@ietf.org References: <87vb0iotil.fsf@wheatstone.g10code.de> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <577E1F99.9050000@cs.tcd.ie> Date: Thu, 7 Jul 2016 10:23:37 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <87vb0iotil.fsf@wheatstone.g10code.de> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000303090807030408050408" Archived-At: Subject: Re: [openpgp] Proposed Patch to RFC4880bis to reserve two public key numbers X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 09:23:44 -0000 This is a cryptographically signed message in MIME format. --------------ms000303090807030408050408 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 07/07/16 07:24, Werner Koch wrote: > On Thu, 7 Jul 2016 01:36, derek@ihtfp.com said: >> Hi, >> >> Now that we've accepted the draft, I'd like to re-open this proposal t= o >> reserve two public-key algorithm protocol numbers. Note (again) that >=20 > I opened an issue to track this proposal: > https://gitlab.com/openpgp-wg/rfc4880bis/issues/1 I forget if this cfrg posting [1] on AE was made visible here or not. Apologies if this is repetitive but that posting from Kenny Paterson on 20151113 seems quite relevant as it says: " My colleague Simon Blackburn and his collaborators have just published an attack on the Algebraic Eraser scheme, breaking the scheme at the designers' claimed 128-bit security level. Their attack recovers the shared key using 8 CPU hours and 64MB of memory. Their paper is here: http://arxiv.org/abs/1511.03870 " With no hats, I'd be against adding an algorithm, even as an option, if there are current serious questions about it's real security level. I do get the arguments for and against, but in such cases am against adding codepoints where there is no way to flag the codepoint as "likely dangerous" or some other similarly negative/scary warning. And while it's good to go to the effort to deprecate old codepoints that are now likely dangerous, I don't see that it's a good idea to add new ones "born" in that state. But maybe there's an update on the state of cryptanalysis of AE? If so, I guess posting to cfrg and then reflecting that back here might be best, as the cfrg list has folks who're better qualified to argue those merits. As far as I can see there was no follow-up to [1] on the cfrg list, but I might have missed it. There does seem to have been an update to the paper on arxiv last month, but I didn't check to see what changed - the abstract still claims the break anyway. Putting my AD hat back on: if the WG do reach consensus to add such codepoints, then when it comes time to publish, I'll be looking back to the list to ensure that consensus was very clear on the list. For the AE ones, that's clearly happening via this thread which is fine process-wise, assuming more folks opine and the chairs declare consensus. I'm just noting that so we ensure the same clarify if there are other similarly contentious codepoint requests in order to avoid having to revisit stuff at publication time. S. [1] https://www.ietf.org/mail-archive/web/cfrg/current/msg07609.html >=20 >=20 > Salam-Shalom, >=20 > Werner >=20 --------------ms000303090807030408050408 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA3MDcw OTIzMzdaMC8GCSqGSIb3DQEJBDEiBCCtN0dP9jQ88UeiywoTxUNTrh67je6wvs/aKP47n/wb rzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQBG/htAPwZ0bGCK7f6Oy2FgVDShNBTegu6575kacuAJruWOzk2ZbS0h S+2JJrIgx/Ofkvo6/vmsygTaUxT+dINDnexyY2A9n6FRv80b8O3SLyMN+/4Vr3OuGDC0GtAT ZaWkhtorXQvB1JJkgKgMV0qU5cTawAK2az6IMtwbxTVpMWT3wnROBzyMGWVmZuoBiEPUQwAT Cogq5ZPaSUnrNPq4oJR2D6jwU91UbNeSKbEEwQt1cTC509CLZpB3M7N5ILE+HdHW2t6tatvw RbBrnY0g23vF1K6CZCTqpjoYLDaSWwWe8N0Mv1BwSGijQXbw+HXMV+BDz9S/942dT+fgijwV AAAAAAAA --------------ms000303090807030408050408-- From nobody Thu Jul 7 03:35:14 2016 Return-Path: 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 6D6F512B013 for ; Thu, 7 Jul 2016 03:35:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no 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 MIGpH4zIxEAH for ; Thu, 7 Jul 2016 03:35:11 -0700 (PDT) Received: from mail.mugenguild.com (mugenguild.com [5.135.189.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0816012D73E for ; Thu, 7 Jul 2016 03:35:09 -0700 (PDT) Received: from localhost (dhcp179-219.wlan.rz.tu-bs.de [134.169.179.219]) by mail.mugenguild.com (Postfix) with ESMTPSA id 0117D5FD08 for ; Thu, 7 Jul 2016 12:35:06 +0200 (CEST) Date: Thu, 7 Jul 2016 12:35:06 +0200 From: Vincent Breitmoser To: openpgp@ietf.org Message-ID: <20160707103506.GA29299@littlepip.fritz.box> References: <87r3b5q2zq.fsf@wheatstone.g10code.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lrZ03NoBR/3+SXJZ" Content-Disposition: inline In-Reply-To: <87r3b5q2zq.fsf@wheatstone.g10code.de> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [openpgp] Tag indicating a MIME content X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 10:35:13 -0000 --lrZ03NoBR/3+SXJZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I support this. Nitpick, should this be "an" rather than "a" m? - V Werner Koch(wk@gnupg.org)@Thu, Jul 07, 2016 at 10:14:17AM +0200: > Hi, >=20 > I recall that an indication for a MIME content has been proposed many > years ago but might have been forgotten. Thus I propose this small > change for 4880bis: >=20 > --8<---------------cut here---------------start------------->8--- > diff --git a/middle.mkd b/middle.mkd > index 033f11f..5519be3 100644 > --- a/middle.mkd > +++ b/middle.mkd > @@ -2156,7 +2156,8 @@ ## {5.9} Literal Data Packet (Tag 11) > may need line ends converted to local form, or other text-mode > changes. The tag 'u' (0x75) means the same as 't', but also > indicates that implementation believes that the literal data > - contains UTF-8 text. > + contains UTF-8 text. If it is a 'm' (0x6d), then it contains a > + MIME message body part [](#RFC2045). > =20 > Early versions of PGP also defined a value of 'l' as a 'local' > mode for machine-local conversions. RFC 1991 [](#RFC1991) > --8<---------------cut here---------------end--------------->8--- >=20 >=20 > MIME has several advantages: Interpretation of the plaintext can be done > without considering the context (e.g. part of a PGP/MIME message or > standalone). The encoding of the message can be described without > resorting to the unprotected armor header. >=20 >=20 > Shalom-Salam, >=20 > Werner >=20 > --=20 > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > /* Join us at OpenPGP.conf */ >=20 > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp --lrZ03NoBR/3+SXJZ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJXfjBaAAoJEHvRgyDerfoRF4oP/2m7FIytvJ88DVZyhgv6JBeD IccHOMuDKn5MxBf24yqwreBjGhpf3k8LAx2gQq6o5Xwo+G+1ej2vokoAPDzBdRCK bdP/+mAvJS0m3R7VDomD4+TNQ9Agp8dK7rPLt1uQDLzhnQXC76E2e+H3HLPkyoao F8FVQ+2xyFm4V3pn4XF5U3xUjZzNur5xxbl5IilF3E5BvMliu03AuEBsRe6lMG6z Y1BsB4iZKQ5pzyZV3NyGxLMbSlCO//S8KhR0/AU1XYTZi70QCTQrl1A1SlhaWZdG YwQmYJUSdFtxtOatTQP5aXcjxPVfrUK0+Sw1hynQrcbc5pGkSn00FS6h72Sr2M3o BwTbtmerTMw7iN0BX+Gmgtrz+/O3bGX6i8xXFaig5BF51TporhIAPD8MjaLOrNyB Q/gM5Ks2aWMMyAV1uo3OguqH3pRaCou9QYI7NlGEpHdxi1rOxQ91+GYbHu56KS0x xe0Ufxe4ggiqgIBYl0m0eAo2kXTvcI4ac8kjuCOznGhjG168ML6qkY3tpG3BbweH HWigkaD5Yct1N/twpXplOl1KwNyivvfIX2juof0zrNcaEoiiPxrnQ6SqPstyiS9c RbXjoem/MOJKY70h+AYG8Qg1aYqlNSr3772+N1p4DySGDAP2jRmqYCoxpR8ENvEd ZA2nGs8QYMM4f1kdqCuF =FVfL -----END PGP SIGNATURE----- --lrZ03NoBR/3+SXJZ-- From nobody Thu Jul 7 04:21:50 2016 Return-Path: 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 A1D2D12D74A for ; Thu, 7 Jul 2016 04:21:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) 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 Z4KGAc92nIlt for ; Thu, 7 Jul 2016 04:21:47 -0700 (PDT) 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 CB44D12D73F for ; Thu, 7 Jul 2016 04:21:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id D4437E2043; Thu, 7 Jul 2016 07:21:31 -0400 (EDT) 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 14487-07; Thu, 7 Jul 2016 07:21:28 -0400 (EDT) Received: by mail2.ihtfp.org (Postfix, from userid 48) id 97F65E2042; Thu, 7 Jul 2016 07:21:28 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1467890488; bh=PKXPHxgx3uamK1ygudROFF+veRNnkYoIqC5qaMvVh1Q=; h=In-Reply-To:References:Date:Subject:From:To:Cc; b=NnCjKnh1ixE+WSb5QIxBHLVKU+OnsIMUMQk5JvhX+PCGlZvrrLOWHs2yweaR9iTDA BdUZO4dYk3Oq/P/YLQE56ZWOa38Aey0J7tCO+WuzJt7lJIefJER2Vnuwl2Ryn8D1N7 2Ubmi4GO3pkEq9vScIwLq/cUJwmpS9eswFlrAMBw= Received: from 192.168.248.159 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Thu, 7 Jul 2016 07:21:28 -0400 Message-ID: In-Reply-To: <577E1F99.9050000@cs.tcd.ie> References: <87vb0iotil.fsf@wheatstone.g10code.de> <577E1F99.9050000@cs.tcd.ie> Date: Thu, 7 Jul 2016 07:21:28 -0400 From: "Derek Atkins" To: "Stephen Farrell" 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: Cc: openpgp@ietf.org, Derek Atkins Subject: Re: [openpgp] Proposed Patch to RFC4880bis to reserve two public key numbers X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 11:21:49 -0000 Hi, On Thu, July 7, 2016 5:23 am, Stephen Farrell wrote: [snip] > > I forget if this cfrg posting [1] on AE was made visible here > or not. Apologies if this is repetitive but that posting from > Kenny Paterson on 20151113 seems quite relevant as it says: > > " > My colleague Simon Blackburn and his collaborators have just > published an attack on the Algebraic Eraser scheme, breaking the > scheme at the designers' claimed 128-bit security level. Their > attack recovers the shared key using 8 CPU hours and 64MB of > memory. Their paper is here: > > http://arxiv.org/abs/1511.03870 And there was a paper published in response to this: http://arxiv.org/abs/1601.04780 > With no hats, I'd be against adding an algorithm, even as an > option, if there are current serious questions about it's real > security level. I do get the arguments for and against, but in > such cases am against adding codepoints where there is no way > to flag the codepoint as "likely dangerous" or some other > similarly negative/scary warning. And while it's good to go to > the effort to deprecate old codepoints that are now likely > dangerous, I don't see that it's a good idea to add new ones > "born" in that state. Note again that it's just reserving the number; it's completely underspecified. [snip] > Putting my AD hat back on: if the WG do reach consensus to > add such codepoints, then when it comes time to publish, I'll > be looking back to the list to ensure that consensus was very > clear on the list. For the AE ones, that's clearly happening > via this thread which is fine process-wise, assuming more folks > opine and the chairs declare consensus. I'm just noting that > so we ensure the same clarify if there are other similarly > contentious codepoint requests in order to avoid having to > revisit stuff at publication time. Frankly, we are already using code point 23 in production. I grabbed that point years ago when I wrote the original I-D and posted it here (in coordination with Werner, who grabbed 22 for EdDSA), well before this WG reopened. I doubt there will be a large contingent looking to implement it, which is fine. But I'd like to make sure nobody else uses that code point. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Thu Jul 7 04:33:45 2016 Return-Path: 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 CD87C12D757 for ; Thu, 7 Jul 2016 04:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.727 X-Spam-Level: X-Spam-Status: No, score=-5.727 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 Qy9S1ZTKmOuN for ; Thu, 7 Jul 2016 04:33:40 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68F8B12D74A for ; Thu, 7 Jul 2016 04:33:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8E4E3BE2F; Thu, 7 Jul 2016 12:33:38 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XFTS5yT8iY41; Thu, 7 Jul 2016 12:33:37 +0100 (IST) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E89A0BE59; Thu, 7 Jul 2016 12:33:22 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1467891203; bh=qIKlsSCYXhVkcFdWaecC8NJ1jaP7w7zgCVLFWOzLNcE=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=4LIOYJrXEFSG5aEu0Jb3lxxE0y5Ie5zbIH0uAW9iAvtTKJMHxv8p39w4NCUFKXhhc UYzGjFIQpMY7uDlg1NCSgvMY9zF3alfihBr5Ecp0DTSojCuvNrHnEdwDueAwuvacvc 45Sf4EI013B32+HssB2uDzfOK6hTRO+F9qNS5bn0= To: Derek Atkins References: <87vb0iotil.fsf@wheatstone.g10code.de> <577E1F99.9050000@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <577E3E02.2000408@cs.tcd.ie> Date: Thu, 7 Jul 2016 12:33:22 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030802070003070403010503" Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] Proposed Patch to RFC4880bis to reserve two public key numbers X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 11:33:44 -0000 This is a cryptographically signed message in MIME format. --------------ms030802070003070403010503 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Derek, On 07/07/16 12:21, Derek Atkins wrote: > Hi, >=20 > On Thu, July 7, 2016 5:23 am, Stephen Farrell wrote: > [snip] >> >> I forget if this cfrg posting [1] on AE was made visible here >> or not. Apologies if this is repetitive but that posting from >> Kenny Paterson on 20151113 seems quite relevant as it says: >> >> " >> My colleague Simon Blackburn and his collaborators have just >> published an attack on the Algebraic Eraser scheme, breaking the >> scheme at the designers' claimed 128-bit security level. Their >> attack recovers the shared key using 8 CPU hours and 64MB of >> memory. Their paper is here: >> >> http://arxiv.org/abs/1511.03870 >=20 > And there was a paper published in response to this: >=20 > http://arxiv.org/abs/1601.04780 The discussion of the relative merits of those would be better on cfrg. (I don't recall the latter having been posted there for example, but I do recall hearing about/seeing it before somewhere.) >=20 >> With no hats, I'd be against adding an algorithm, even as an >> option, if there are current serious questions about it's real >> security level. I do get the arguments for and against, but in >> such cases am against adding codepoints where there is no way >> to flag the codepoint as "likely dangerous" or some other >> similarly negative/scary warning. And while it's good to go to >> the effort to deprecate old codepoints that are now likely >> dangerous, I don't see that it's a good idea to add new ones >> "born" in that state. >=20 > Note again that it's just reserving the number; it's completely > underspecified. The patch mentioned AE methods explicitly. Allocating codepoints for underspecified algorithms would seem pretty odd. >=20 > [snip] >=20 >> Putting my AD hat back on: if the WG do reach consensus to >> add such codepoints, then when it comes time to publish, I'll >> be looking back to the list to ensure that consensus was very >> clear on the list. For the AE ones, that's clearly happening >> via this thread which is fine process-wise, assuming more folks >> opine and the chairs declare consensus. I'm just noting that >> so we ensure the same clarify if there are other similarly >> contentious codepoint requests in order to avoid having to >> revisit stuff at publication time. >=20 > Frankly, we are already using code point 23 in production. I grabbed th= at > point years ago when I wrote the original I-D and posted it here (in > coordination with Werner, who grabbed 22 for EdDSA), well before this W= G > reopened. I doubt there will be a large contingent looking to implemen= t > it, which is fine. But I'd like to make sure nobody else uses that cod= e > point. So I've no clue how this WG or the openpgp community regard squatting but if codepoints aren't scarce marking some as reserved could be an option. (FWIW, I'm not fussed about doing such things if codepoints aren't scarce.) Marking some codepoints as being reserved for an undespecified algorithm with an uncertain strength however is not something I'd support. Cheers, S. >=20 > -derek >=20 --------------ms030802070003070403010503 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA3MDcx MTMzMjJaMC8GCSqGSIb3DQEJBDEiBCAmPrvDQkvUkt4j/7vT+5uH5BEFee62ExYCsMzUlLwv xzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQCtzTovK5HCLYWOu9FSrhff1oziupe1n7/f9R3fR03NrkZBADA7lRkq y7nPBcvo5A2GvHJC9sQVpHB0HFWKNIjmQLYTB3+dlpeo9of3tmfI8cERrZyjJYZfmzA1lmI/ IGNfxZTeyk3y0S7PqLLJkZVG6HmhRUN+un6cYq8bK5/Yj9OOtMMKPbL6DHQmzW5paedgWTq6 eWZgfQ7XwtcGi2ZeMyJ3UnovU1KY0S6pwCbNMArWX2HvmjyRuUSpp1Ppn4zH5bpawtz0KFQS 8JSLSwAIxrhhJNFpKNJ2PS4MdAXrGrwvy8utgwtUjBosQ7XkYyNGj61x+tkJo2Oo66JdNGVU AAAAAAAA --------------ms030802070003070403010503-- From nobody Thu Jul 7 04:49:49 2016 Return-Path: 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 4F2D712D74D for ; Thu, 7 Jul 2016 04:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.127 X-Spam-Level: X-Spam-Status: No, score=-4.127 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.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 idve_koHL6LB for ; Thu, 7 Jul 2016 04:49:47 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 076E812D1A9 for ; Thu, 7 Jul 2016 04:49:47 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 5EDDA433461; Thu, 7 Jul 2016 11:49:46 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 359F4433430; Thu, 7 Jul 2016 11:49:46 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1467892186; bh=hxoFdN5NjzHLh2E3INfpIzu46+p9BscwAJxdM31lCp0=; l=108; h=From:To:CC:Date:References:In-Reply-To:From; b=Bu2PKuOoGVakreSda5Vwd/OwD5M7dazpnqrCEgw1wg08m2vpR6z4EL7UMlzEH6t20 wuXsPnjl80m2pW9KEQAzlwE6KvLTsKqPLFafFxN0HLYaWLhdnGUh0T4npV/MLxCtjx zvcTu/b2e1d2GFuRlKMHDcWvPUV1R0ON/soujqCE= Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.33]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 09F0A1FC88; Thu, 7 Jul 2016 11:49:46 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Thu, 7 Jul 2016 07:49:45 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1130.005; Thu, 7 Jul 2016 07:49:45 -0400 From: "Salz, Rich" To: Derek Atkins , Werner Koch Thread-Topic: [openpgp] Proposed Patch to RFC4880bis to reserve two public key numbers Thread-Index: AQHR199GGitn1MZIxk2a4PeoC1qspaAM23uQ Date: Thu, 7 Jul 2016 11:49:45 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.40.86] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "openpgp@ietf.org" Subject: Re: [openpgp] Proposed Patch to RFC4880bis to reserve two public key numbers X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 11:49:48 -0000 I am in favor of the reservation, but would like to see all IANA registry s= tuff in a separate document. From nobody Thu Jul 7 05:34:25 2016 Return-Path: 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 461B812D75D for ; Thu, 7 Jul 2016 05:34:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) 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 4b-lFPg3w9jN for ; Thu, 7 Jul 2016 05:34:20 -0700 (PDT) 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 A1D3912D688 for ; Thu, 7 Jul 2016 05:34:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 4E92EE2030; Thu, 7 Jul 2016 08:33:49 -0400 (EDT) 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 15239-01; Thu, 7 Jul 2016 08:33:46 -0400 (EDT) Received: by mail2.ihtfp.org (Postfix, from userid 48) id C6939E2040; Thu, 7 Jul 2016 08:33:45 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1467894825; bh=OzuhVmS6Ck63kp/7AlHzeAfMnR6VYQpLb5DTkeVEYm8=; h=In-Reply-To:References:Date:Subject:From:To:Cc; b=n6EHMeWzezKjN5RxOgEDlAKqvBMHK1QhKCN1ThzsclhRWPd34IMRO3XgDLxsAAlhz HwmQsh18p5JK5qDQvY2RSgrD3VW+xUzG9yzEkeZ0Mdnuv7II1z7e9ESpGxpTulGedl wtLZ3cey+GLfP26rCMvLl7tVV/T7QyWDG/jkIP2M= Received: from 192.168.248.159 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Thu, 7 Jul 2016 08:33:45 -0400 Message-ID: In-Reply-To: <577E3E02.2000408@cs.tcd.ie> References: <87vb0iotil.fsf@wheatstone.g10code.de> <577E1F99.9050000@cs.tcd.ie> <577E3E02.2000408@cs.tcd.ie> Date: Thu, 7 Jul 2016 08:33:45 -0400 From: "Derek Atkins" To: "Stephen Farrell" 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: Cc: openpgp@ietf.org, Derek Atkins Subject: Re: [openpgp] Proposed Patch to RFC4880bis to reserve two public key numbers X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 12:34:22 -0000 Hi Stephen, On Thu, July 7, 2016 7:33 am, Stephen Farrell wrote: > > Hi Derek, > > On 07/07/16 12:21, Derek Atkins wrote: >> Hi, >> >> On Thu, July 7, 2016 5:23 am, Stephen Farrell wrote: [snip] >> >> http://arxiv.org/abs/1601.04780 > > The discussion of the relative merits of those would be better > on cfrg. (I don't recall the latter having been posted there > for example, but I do recall hearing about/seeing it before > somewhere.) You brought up a paper showing a weak key/keyset and said there was no response, I pointed out a response. I wasn't trying to discuss relative merits and agree this is not the place to do so. But you started it ;) [snip] >> Note again that it's just reserving the number; it's completely >> underspecified. > > The patch mentioned AE methods explicitly. Allocating codepoints > for underspecified algorithms would seem pretty odd. There are other "reserved for.." code points. And there are other "underspecified" code points, too. So there is already precedent. C.f. X9.42 (code point 21). [snip] > So I've no clue how this WG or the openpgp community regard > squatting but if codepoints aren't scarce marking some as > reserved could be an option. (FWIW, I'm not fussed about doing > such things if codepoints aren't scarce.) It's an 8-bit field. There are currently 21 allocated, with #22 in line for EdDSA, and me asking for 23 and 24. So still under 10% utilized. I'm not sure if you consider this scarce or not. I don't; I don't expect there to be a ton of new public key algorithms out there. Even if we expect another two dozen in the *next* 30 years, that would still put us only to 20% utilized. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Thu Jul 7 05:43:32 2016 Return-Path: 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 AE52712B048 for ; Thu, 7 Jul 2016 05:43:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.727 X-Spam-Level: X-Spam-Status: No, score=-5.727 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 nB7OAmz_PsrO for ; Thu, 7 Jul 2016 05:43:28 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D20712B014 for ; Thu, 7 Jul 2016 05:43:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 57004BE50; Thu, 7 Jul 2016 13:43:26 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UjxG_AlwIs1y; Thu, 7 Jul 2016 13:43:25 +0100 (IST) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B7D9BBE4D; Thu, 7 Jul 2016 13:43:24 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1467895405; bh=FS/He9pbO2xHT3PwfoUE/Ox+updiNCCeTG4ns6tVpOc=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=Uu2QRos9VQde73G8fvX0swiRIQZJmvPjSl/3w7XPOJqJf+Egm9kbPnQSRCAZ3EvaY LgpQhRjTH/5OFVGHmScLqqu1GFFYWNz7wgV51zHQgzUZh0oJgEa0kLArIIdxJJshrh BaNHKvGWETg1QttJxjBpNR0288rsT8Cgsrhv3Eck= To: Derek Atkins References: <87vb0iotil.fsf@wheatstone.g10code.de> <577E1F99.9050000@cs.tcd.ie> <577E3E02.2000408@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <577E4E6C.7070604@cs.tcd.ie> Date: Thu, 7 Jul 2016 13:43:24 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000108060800010509010508" Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] Proposed Patch to RFC4880bis to reserve two public key numbers X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 12:43:31 -0000 This is a cryptographically signed message in MIME format. --------------ms000108060800010509010508 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 07/07/16 13:33, Derek Atkins wrote: > You brought up a paper showing a weak key/keyset and said there was no > response, I pointed out a response. I wasn't trying to discuss relativ= e > merits and agree this is not the place to do so. But you started it ;)= Well, no - 'twas you guys started proposing AE I think:-) Seriously though, if you're interested in AE being used in Internet protocols, the cfrg list is the place to do that I'd say, and at present the BBT paper is what's in that archive uncontested. Up to you though of course. S. --------------ms000108060800010509010508 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA3MDcx MjQzMjRaMC8GCSqGSIb3DQEJBDEiBCDzRXMkdvxndQVsSQ9lyBrN0aHo9DmAxDe8/rSAbVPD kDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQBq7rCheiOdWS3Yt5NYe9GuDxfTkz/6u340GtSe2OeSr6K0Kqmhs1pD X71wh3soqkB/nw1yZCGPN1NWbpyxn7TVNq5vTMTjnb8ONmoXUW4N/OWmx/mKObaaBotQQdPE 97JkVuos9hox0rmyDntY0F4O8syjtRbsWyboQcx8pZlxprh7YBzMck7QM9RP1ITii57Rb41L mv4CjRzHe5+pSHdRlISUAZCG2IgAU2ouZ0Fx973aiAose7T0jhx2RFu+KxRBSn+7MTJETR1F uOfuGzp0ivKFq2VKk7ALVjQr7lVkOOO/EOEGvRNYmqBqLMPfmHHzjJMbloT4aWxYGm99MoST AAAAAAAA --------------ms000108060800010509010508-- From nobody Thu Jul 7 06:15:35 2016 Return-Path: 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 F021512D75A for ; Thu, 7 Jul 2016 06:15:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 nxL_wBv4M7Xm for ; Thu, 7 Jul 2016 06:15:30 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AF9012D757 for ; Thu, 7 Jul 2016 06:15:30 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id d67so19436426vkh.1 for ; Thu, 07 Jul 2016 06:15:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=K1Cqz5Mt8mZSEPBZS/wwkBBcmJFg2R9XT85Dxp9+VSA=; b=ZpQ8A/uw96girP8FHutK1VtqcNAg1iKTIdI6wXoc2U8/7IFej+qqQQQ0RXvfJFgA2c FJZRKtO2V7FpMR/nlHtZgLkz/SuiWbLbMJ2JReyCfreqVC/MARNviXEyFqUBtWNnSf/f H3gzbc9kjoAEAxBgWtE1dEJztieLzCuSPXwi9PY+Dl7XOknpBMLXlcmgHOLAZl3+qaO8 vsux8suFaPNTvXkvweqbLLaD2fEmQU2Ji334/9fa4ihSq0/dynU6Vqeyfe+0HqQZOcvh K1pkWQKpeMpmRzmFmtlQLEV+++pQ7vr3iCA/Ib/kfksKxDGyhci6TlZWfq0IE+aG6vmz SSZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=K1Cqz5Mt8mZSEPBZS/wwkBBcmJFg2R9XT85Dxp9+VSA=; b=LqWjZbLYH6D3dcZ57mXCbTR6Lov0antVzgYH73k8helCVJky70DavwJKAPbAt975NZ OT1e2khpbSk8jETwx0xH7s2U8m1qgsAaa2o/eLG9LvGbmDWRfegDFNhxMd4vzVhXSMKd JeCYAI5SWWse+GBYjGIoX3uT7Ewuz05HQ/SlhxKFlZxqxBsgPnN+ZjEkcaYHw4yZtJ6r 8w4ERz+s3dIY1ubrCJ5of+ILezWFjiXLRs2q58AUmbonnIdW+GofZCqK4xDTbC34dQpu mdjIlFo0tU9B85dFTBXpilihQsz8f0OSR79eA3S0UuSYXdD2MwY9kFueWPQbPxW1C6WC B7hg== X-Gm-Message-State: ALyK8tKnWU+N4Dx4KtH+4NjN0FK/wzDCU24ppfdfpoGjqgjfaVmYxc0F9UeAimxOmFgnvh5I81e5eaz5952umQ== X-Received: by 10.31.178.18 with SMTP id b18mr75888vkf.84.1467897329550; Thu, 07 Jul 2016 06:15:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.69.7 with HTTP; Thu, 7 Jul 2016 06:15:29 -0700 (PDT) In-Reply-To: <20160707103506.GA29299@littlepip.fritz.box> References: <87r3b5q2zq.fsf@wheatstone.g10code.de> <20160707103506.GA29299@littlepip.fritz.box> From: Wyllys Ingersoll Date: Thu, 7 Jul 2016 09:15:29 -0400 Message-ID: To: "openpgp@ietf.org" Content-Type: multipart/alternative; boundary=001a1143ebbae50b6a05370b7ad6 Archived-At: Subject: Re: [openpgp] Tag indicating a MIME content X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 13:15:34 -0000 --001a1143ebbae50b6a05370b7ad6 Content-Type: text/plain; charset=UTF-8 +1 on the "m" proposal. -Wyllys Ingersoll On Thu, Jul 7, 2016 at 6:35 AM, Vincent Breitmoser wrote: > I support this. > > Nitpick, should this be "an" rather than "a" m? > > - V > > Werner Koch(wk@gnupg.org)@Thu, Jul 07, 2016 at 10:14:17AM +0200: > > Hi, > > > > I recall that an indication for a MIME content has been proposed many > > years ago but might have been forgotten. Thus I propose this small > > change for 4880bis: > > > > --8<---------------cut here---------------start------------->8--- > > diff --git a/middle.mkd b/middle.mkd > > index 033f11f..5519be3 100644 > > --- a/middle.mkd > > +++ b/middle.mkd > > @@ -2156,7 +2156,8 @@ ## {5.9} Literal Data Packet (Tag 11) > > may need line ends converted to local form, or other text-mode > > changes. The tag 'u' (0x75) means the same as 't', but also > > indicates that implementation believes that the literal data > > - contains UTF-8 text. > > + contains UTF-8 text. If it is a 'm' (0x6d), then it contains a > > + MIME message body part [](#RFC2045). > > > > Early versions of PGP also defined a value of 'l' as a 'local' > > mode for machine-local conversions. RFC 1991 [](#RFC1991) > > --8<---------------cut here---------------end--------------->8--- > > > > > > MIME has several advantages: Interpretation of the plaintext can be done > > without considering the context (e.g. part of a PGP/MIME message or > > standalone). The encoding of the message can be described without > > resorting to the unprotected armor header. > > > > > > Shalom-Salam, > > > > Werner > > > > -- > > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > /* Join us at OpenPGP.conf */ > > > > _______________________________________________ > > openpgp mailing list > > openpgp@ietf.org > > https://www.ietf.org/mailman/listinfo/openpgp > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp > > --001a1143ebbae50b6a05370b7ad6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1 on the "m" proposal.

-Wyll= ys Ingersoll

On Thu, Jul 7, 2016 at 6:35 AM, Vincent Breitmoser = <look@my.amazi= n.horse> wrote:
I support t= his.

Nitpick, should this be "an" rather than "a" m?

=C2=A0- V

Werner Koch(wk@gnupg.org)@Thu, Jul 07, = 2016 at 10:14:17AM +0200:
> Hi,
>
> I recall that an indication for a MIME content has been proposed many<= br> > years ago but might have been forgotten.=C2=A0 Thus I propose this sma= ll
> change for 4880bis:
>
> --8<---------------cut here---------------start------------->8--= -
> diff --git a/middle.mkd b/middle.mkd
> index 033f11f..5519be3 100644
> --- a/middle.mkd
> +++ b/middle.mkd
> @@ -2156,7 +2156,8 @@ ## {5.9} Literal Data Packet (Tag 11)
>=C2=A0 =C2=A0 =C2=A0 may need line ends converted to local form, or oth= er text-mode
>=C2=A0 =C2=A0 =C2=A0 changes.=C2=A0 The tag 'u' (0x75) means th= e same as 't', but also
>=C2=A0 =C2=A0 =C2=A0 indicates that implementation believes that the li= teral data
> -=C2=A0 =C2=A0 contains UTF-8 text.
> +=C2=A0 =C2=A0 contains UTF-8 text.=C2=A0 If it is a 'm' (0x6d= ), then it contains a
> +=C2=A0 =C2=A0 MIME message body part [](#RFC2045).
>
>=C2=A0 =C2=A0 =C2=A0 Early versions of PGP also defined a value of '= ;l' as a 'local'
>=C2=A0 =C2=A0 =C2=A0 mode for machine-local conversions.=C2=A0 RFC 1991= [](#RFC1991)
> --8<---------------cut here---------------end--------------->8--= -
>
>
> MIME has several advantages: Interpretation of the plaintext can be do= ne
> without considering the context (e.g. part of a PGP/MIME message or > standalone).=C2=A0 The encoding of the message can be described withou= t
> resorting to the unprotected armor header.
>
>
> Shalom-Salam,
>
>=C2=A0 =C2=A0 Werner
>
> --
> Die Gedanken sind frei.=C2=A0 Ausnahmen regelt ein Bundesgesetz.
>=C2=A0 /* Join us at OpenPGP.conf=C2=A0 <https://openpgp-conf.org= > */
>
> _______________________________________________
> openpgp mailing list
> openpgp@ietf.org
> https://www.ietf.org/mailman/listinfo/openpgp<= br>

_______________________________________________
openpgp mailing list
openpgp@ietf.org
https://www.ietf.org/mailman/listinfo/openpgp


--001a1143ebbae50b6a05370b7ad6-- From nobody Thu Jul 7 07:09:44 2016 Return-Path: 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 3C69912D56E for ; Thu, 7 Jul 2016 07:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) 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 UHMWp3qcGc7M for ; Thu, 7 Jul 2016 07:09:41 -0700 (PDT) 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 4C55912D531 for ; Thu, 7 Jul 2016 07:09:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 36104E2030; Thu, 7 Jul 2016 10:09:03 -0400 (EDT) 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 15775-05; Thu, 7 Jul 2016 10:09:00 -0400 (EDT) Received: by mail2.ihtfp.org (Postfix, from userid 48) id 73A61E2039; Thu, 7 Jul 2016 10:09:00 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1467900540; bh=l/Qhqwxr0y3mESHGPt2Jk7+zz2t3jQu/6YFlf8utcC4=; h=In-Reply-To:References:Date:Subject:From:To:Cc; b=eHdmavgu1jZgko7rrV1VIP2OLX+hoSP0g6ylTKzpCIVtN5w0I0+rlq3SV1usE4R31 a55dav/DtrQMvl3KrBgqhZKFc/p+HIjRapg/zY7VZVLonTLa41aFjBI2ZDaSRU76D6 5C5Nz7PFQl0qUa/xGmSLIwdwqOV0wJ2liGAP1igA= Received: from 192.168.248.159 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Thu, 7 Jul 2016 10:09:00 -0400 Message-ID: <32a5e6638e90b8cb7a2fc539a6d197d0.squirrel@mail2.ihtfp.org> In-Reply-To: <577E4E6C.7070604@cs.tcd.ie> References: <87vb0iotil.fsf@wheatstone.g10code.de> <577E1F99.9050000@cs.tcd.ie> <577E3E02.2000408@cs.tcd.ie> <577E4E6C.7070604@cs.tcd.ie> Date: Thu, 7 Jul 2016 10:09:00 -0400 From: "Derek Atkins" To: "Stephen Farrell" 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: Cc: openpgp@ietf.org, Derek Atkins Subject: Re: [openpgp] Proposed Patch to RFC4880bis to reserve two public key numbers X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 14:09:43 -0000 On Thu, July 7, 2016 8:43 am, Stephen Farrell wrote: > > > On 07/07/16 13:33, Derek Atkins wrote: >> You brought up a paper showing a weak key/keyset and said there was no >> response, I pointed out a response. I wasn't trying to discuss relative >> merits and agree this is not the place to do so. But you started it ;) > > Well, no - 'twas you guys started proposing AE I think:-) No, I just asked to reserve some code points. I suppose I could have called them "Fred" and "George" if that makes you feel any better? But back to the technical side of things: I chose OpenPGP because I feel it is the better fit for our company use cases. I had a lot of pushback at the time about why not use X.509? Indeed, looking back X.509 would have certainly been an easier route to take; we just need an OID (gee, that was easy to acquire) and plug it in and we're done. But the arguments against X.509 (data size, code size, strictness, etc) outweighed what I believed to be the "battle" of obtaining OpenPGP code points. Frankly, given the history of OpenPGP I thought it would be pretty easy. There's historically been very little pushback -- someone wants to get a code point for their use, okay, let's give it to them. This way everyone else, when they see a message, knows *what* it is (even if they can't actually decode it). So yeah, mea culpa for bringing in the AE baggage. Let's call them Fred and George and move on? Or do you have something against the Fred and George algorithms having code points? ;-) Seriously, though, let me ask you the same question that was posed the other week: what is the *harm* in defining these code points in the registry? There is no harm in thinking someone might use it unknowingly, because that's technically not feasible. There's no harm in someone being able to decipher a packet and know "oh, this is a Fred packet". Now, what is the harm of NOT defining these in the registry? Well, there is the possibility that down the road it might get re-defined and used by some other algorihtm and now there are two different things in the wild. (c.f. historical openness of accepting code point requests). So let's look at this from a protocol/registry standpoint and not a cryptographic standpoint, since that's what this request is really about. Thanks, -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Thu Jul 7 07:35:32 2016 Return-Path: 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 DE15612D759 for ; Thu, 7 Jul 2016 07:35:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no 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 eRoFxxVrdz03 for ; Thu, 7 Jul 2016 07:35:28 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id 937B112D7C1 for ; Thu, 7 Jul 2016 07:35:19 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 87BE4F98B; Thu, 7 Jul 2016 10:35:18 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 675A41FFD5; Thu, 7 Jul 2016 10:35:17 -0400 (EDT) From: Daniel Kahn Gillmor To: Werner Koch , openpgp@ietf.org In-Reply-To: <87r3b5q2zq.fsf@wheatstone.g10code.de> References: <87r3b5q2zq.fsf@wheatstone.g10code.de> User-Agent: Notmuch/0.22+69~gd812194 (https://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Thu, 07 Jul 2016 10:35:17 -0400 Message-ID: <87wpkxfrdm.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [openpgp] Tag indicating a MIME content X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 14:35:30 -0000 On Thu 2016-07-07 04:14:17 -0400, Werner Koch wrote: > I recall that an indication for a MIME content has been proposed many > years ago but might have been forgotten. Thus I propose this small > change for 4880bis: > > --8<---------------cut here---------------start------------->8--- > diff --git a/middle.mkd b/middle.mkd > index 033f11f..5519be3 100644 > --- a/middle.mkd > +++ b/middle.mkd > @@ -2156,7 +2156,8 @@ ## {5.9} Literal Data Packet (Tag 11) > may need line ends converted to local form, or other text-mode > changes. The tag 'u' (0x75) means the same as 't', but also > indicates that implementation believes that the literal data > - contains UTF-8 text. > + contains UTF-8 text. If it is a 'm' (0x6d), then it contains a > + MIME message body part [](#RFC2045). > > Early versions of PGP also defined a value of 'l' as a 'local' > mode for machine-local conversions. RFC 1991 [](#RFC1991) > --8<---------------cut here---------------end--------------->8--- > > > MIME has several advantages: Interpretation of the plaintext can be done > without considering the context (e.g. part of a PGP/MIME message or > standalone). The encoding of the message can be described without > resorting to the unprotected armor header. I support this proposal. Should we also be deprecating 't' in favor of 'u' now that UTF-8 support is ubiquitous, and charset munging can be problematic? --dkg From nobody Thu Jul 7 07:45:59 2016 Return-Path: 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 CF40F12D692 for ; Thu, 7 Jul 2016 07:45:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) 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 LOyyUqPCkQuO for ; Thu, 7 Jul 2016 07:45:51 -0700 (PDT) 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 EDA7B12D7C7 for ; Thu, 7 Jul 2016 07:45:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 9DD8CE2039; Thu, 7 Jul 2016 10:45:19 -0400 (EDT) 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 16041-09; Thu, 7 Jul 2016 10:45:17 -0400 (EDT) Received: from securerf.ihtfp.org (IHTFP-DHCP-159.IHTFP.ORG [192.168.248.159]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 9F5A1E2030; Thu, 7 Jul 2016 10:45:17 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1467902717; bh=a7ZBkM5uXxA68P202P3+5J3RQkctvbCbWlhIqKciFbE=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=ERKVTyMs4PP/Qh1oHXc+IwMB7i86I7gHIXLIUCXR2M/2Gujohy9oodht+BfRL6YCE MOroxbMGwV+dULdo+0VGpScB1N8fEHAUoTe+0w3/qv7vnP0JS3joFoj5fGfXPG2vZT ZhxOWqeJ8KHfvfd7AEw9lOMnAgLSgcWvOusgfNIY= Received: (from warlord@localhost) by securerf.ihtfp.org (8.15.2/8.14.8/Submit) id u67EjHXS009004; Thu, 7 Jul 2016 10:45:17 -0400 From: Derek Atkins To: Phillip Hallam-Baker References: <20160701153304.332d2c95@pc1> <874m86xq04.fsf@alice.fifthhorseman.net> <9A043F3CF02CD34C8E74AC1594475C73F4CB97D2@uxcn10-5.UoA.auckland.ac.nz> <5779E086.9000506@brainhub.org> Date: Thu, 07 Jul 2016 10:45:17 -0400 In-Reply-To: (Phillip Hallam-Baker's message of "Wed, 6 Jul 2016 18:12:25 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: IETF OpenPGP , Jon Callas Subject: Re: [openpgp] Can the OpenPGP vs. S/MIME situation be fixed? X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 14:45:54 -0000 Phillip Hallam-Baker writes: > OpenPGP can support hierarchical certificate deployments just fine (my > company is building one) as well as the Web of Trust model.=C2=A0 X.5= 09 > cannot support a Web of Trust deployment, period. >=20=20=20=20 > So there is a clear winner here. > > =E2=80=8B > You can in fact make X.509 do Web of trust. You simply give each user the= ir > own CA root and cross certify. I guess X.509v3 does, theoretically, allow multiple signatures on a certificate, but I was under the impression that zero implementations actually supported that? > I was doing that for quite a while till I realized that the legacy stuff = was > hurting rather than helping. Yes you can get the protocols to do more tha= n the > apps let them. But you don't have the advantage of legacy platform suppor= t or > legacy platform ignoring your stuff in a predictable way. The nice thing here is that legacy OpenPGP apps DO support hierarchical deployments without any changes. The only thing you need to do for OpenPGP is that you need to tell the program to trust the CA. This does have the benefit (or I suppose if you come from an X.509 world it's a drawback) that each user needs to declare which CAs are trusted. I am curious in what way you found the legacy OpenPGP deployments didn't support hierarchical trust? Or are you saying that legacy X.509 didn't support a Web of Trust model (which, honestly, doesn't surprise me). -derek --=20 Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Thu Jul 7 07:51:10 2016 Return-Path: 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 AFC4A12D7CD for ; Thu, 7 Jul 2016 07:51:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) 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 C89XZqGWPyzz for ; Thu, 7 Jul 2016 07:51:08 -0700 (PDT) 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 400AB12D7CA for ; Thu, 7 Jul 2016 07:51:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 0C540E2039; Thu, 7 Jul 2016 10:50:36 -0400 (EDT) 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 16282-01; Thu, 7 Jul 2016 10:50:33 -0400 (EDT) Received: from securerf.ihtfp.org (IHTFP-DHCP-159.IHTFP.ORG [192.168.248.159]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 52E1DE2030; Thu, 7 Jul 2016 10:50:33 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1467903033; bh=zOpKEa5yPAw4kcVL2o7A1EFCNqrlN9HdeUGtEUDbhgs=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=Wq0Yfo0EVghzx2D9NPk2bsrRhHzfyEYItTNBycbxeBopC1xBeok0gdIXXLM0M3Gp3 gOXGY6YWQUV1HlfgFuXVm3kL2eoZ4PxH77hCnW4ctdHc3nEBpBofgInOvGoS9/iogq h6binmp3fp7kV9PJjw/v4KHC/AVhBbo0IRav6aoQ= Received: (from warlord@localhost) by securerf.ihtfp.org (8.15.2/8.14.8/Submit) id u67EoWKm009294; Thu, 7 Jul 2016 10:50:32 -0400 From: Derek Atkins To: Vincent Breitmoser References: <87r3b5q2zq.fsf@wheatstone.g10code.de> <20160707103506.GA29299@littlepip.fritz.box> Date: Thu, 07 Jul 2016 10:50:32 -0400 In-Reply-To: <20160707103506.GA29299@littlepip.fritz.box> (Vincent Breitmoser's message of "Thu, 7 Jul 2016 12:35:06 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] Tag indicating a MIME content X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 14:51:10 -0000 Hi, +1 on this proposal, but in response to Vincent I would propose that we just remove the article completely, so it reads: ... If it is 'm' (0x6d), then .... -derek Vincent Breitmoser writes: > I support this. > > Nitpick, should this be "an" rather than "a" m? > > - V > > Werner Koch(wk@gnupg.org)@Thu, Jul 07, 2016 at 10:14:17AM +0200: >> Hi, >> >> I recall that an indication for a MIME content has been proposed many >> years ago but might have been forgotten. Thus I propose this small >> change for 4880bis: >> >> --8<---------------cut here---------------start------------->8--- >> diff --git a/middle.mkd b/middle.mkd >> index 033f11f..5519be3 100644 >> --- a/middle.mkd >> +++ b/middle.mkd >> @@ -2156,7 +2156,8 @@ ## {5.9} Literal Data Packet (Tag 11) >> may need line ends converted to local form, or other text-mode >> changes. The tag 'u' (0x75) means the same as 't', but also >> indicates that implementation believes that the literal data >> - contains UTF-8 text. >> + contains UTF-8 text. If it is a 'm' (0x6d), then it contains a >> + MIME message body part [](#RFC2045). >> >> Early versions of PGP also defined a value of 'l' as a 'local' >> mode for machine-local conversions. RFC 1991 [](#RFC1991) >> --8<---------------cut here---------------end--------------->8--- >> >> >> MIME has several advantages: Interpretation of the plaintext can be done >> without considering the context (e.g. part of a PGP/MIME message or >> standalone). The encoding of the message can be described without >> resorting to the unprotected armor header. >> >> >> Shalom-Salam, >> >> Werner >> >> -- >> Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. >> /* Join us at OpenPGP.conf */ >> >> _______________________________________________ >> openpgp mailing list >> openpgp@ietf.org >> https://www.ietf.org/mailman/listinfo/openpgp > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Thu Jul 7 08:32:09 2016 Return-Path: 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 5286C12D0AF for ; Thu, 7 Jul 2016 08:32:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no 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 9IQ1A2z7vRWC for ; Thu, 7 Jul 2016 08:32:06 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDF5712B069 for ; Thu, 7 Jul 2016 08:32:04 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1bLBHW-0000zN-N2 for ; Thu, 07 Jul 2016 17:32:02 +0200 Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1bLBDy-0008SL-5t; Thu, 07 Jul 2016 17:28:22 +0200 From: Werner Koch To: Derek Atkins References: <20160701153304.332d2c95@pc1> <874m86xq04.fsf@alice.fifthhorseman.net> <9A043F3CF02CD34C8E74AC1594475C73F4CB97D2@uxcn10-5.UoA.auckland.ac.nz> <5779E086.9000506@brainhub.org> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: url=https://k.gnupg.net/80615870F5BAD690333686D0F2AD85AC1E42B367 Mail-Followup-To: Derek Atkins , Phillip Hallam-Baker , IETF OpenPGP , Jon Callas Date: Thu, 07 Jul 2016 17:28:22 +0200 In-Reply-To: (Derek Atkins's message of "Thu, 07 Jul 2016 10:45:17 -0400") Message-ID: <87mvltmprd.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: Cc: Phillip Hallam-Baker , Jon Callas , IETF OpenPGP Subject: Re: [openpgp] Can the OpenPGP vs. S/MIME situation be fixed? X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 15:32:08 -0000 On Thu, 7 Jul 2016 16:45, derek@ihtfp.com said: > I guess X.509v3 does, theoretically, allow multiple signatures on a > certificate, but I was under the impression that zero implementations > actually supported that? I can't see how this is possible within an X.509 certificate: Certificate ::= SEQUENCE { tbsCertificate TBSCertificate, signatureAlgorithm AlgorithmIdentifier, signatureValue BIT STRING } There is only one signature for the to-be-signed-Certificate. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ From nobody Thu Jul 7 12:08:35 2016 Return-Path: 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 DDCAA12D0AC for ; Thu, 7 Jul 2016 12:08:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.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 njNPtuNAa4y2 for ; Thu, 7 Jul 2016 12:08:32 -0700 (PDT) Received: from st13p27im-asmtp004.me.com (st13p27im-asmtp004.me.com [17.162.190.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28BC312B059 for ; Thu, 7 Jul 2016 12:08:32 -0700 (PDT) Received: from process-dkim-sign-daemon.st13p27im-asmtp004.me.com by st13p27im-asmtp004.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) id <0O9Y00200KYSB500@st13p27im-asmtp004.me.com> for openpgp@ietf.org; Thu, 07 Jul 2016 19:08:31 +0000 (GMT) Received: from [10.119.8.230] (unknown [209.73.142.2]) by st13p27im-asmtp004.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) with ESMTPSA id <0O9Y00BKKL64UV40@st13p27im-asmtp004.me.com>; Thu, 07 Jul 2016 19:08:30 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-07-07_09:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1011 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1510270003 definitions=main-1607070171 Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Jon Callas In-reply-to: Date: Thu, 07 Jul 2016 12:08:27 -0700 Content-transfer-encoding: quoted-printable Message-id: <7A5B2E4F-B3BC-4BF6-B8C9-8B34FBA4CC15@icloud.com> References: To: "Salz, Rich" X-Mailer: Apple Mail (2.3124) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=4d515a; t=1467918511; bh=YPYVxFuA2nIsmRd0Pf9aLVzOFojrz0lUj8hONm/uMe0=; h=Content-type:MIME-version:Subject:From:Date:Message-id:To; b=Sl3+2k16s4sP+KXkNfKNIJmnm1AAgKoE8RCF/FffPM14ytaAJK3r4DNuITk1vh+rL gC44eHYmjcip5977Y/9eLXiXPlR5QfauSIA/GC7a/h3lWgLemHXi2y+Mviaj7gtEy5 Wt300XnMjSJax6G4E8NLSEIj7VulRUQ9lMRu24ia7OBkYSGaiHbQ1kJADn1gRpMC36 WrQgeBBCtUFYTyPW+niJLevElhATM0AfIIfDXrF4+QmVRla795HcODLZKQn5UdqRqW 2USpkor59ZmR23OhGYoAJd+agxezJt/EBE/3zt2wDfEj0DSPpuo498PtTp9F2qTiPx VZOtosI4ZilCQ== Archived-At: Cc: Werner Koch , "openpgp@ietf.org" , Derek Atkins , Jon Callas Subject: Re: [openpgp] Proposed Patch to RFC4880bis to reserve two public key numbers X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 19:08:34 -0000 > On Jul 7, 2016, at 4:49 AM, Salz, Rich wrote: >=20 > I am in favor of the reservation, but would like to see all IANA = registry stuff in a separate document. I concur with Rich. As most people know, I am an inclusivist in these matters. OpenPGP has = as one of its implicit design goals the ability to support communities = within the user base who have radically different opinions about = algorithms. It's been a key feature of OpenPGP. That the registry is in the document is an artifact of the way that we = did things back in the 1900s. I think it makes sense to allow for more = agility. Jon From nobody Thu Jul 7 12:13:02 2016 Return-Path: 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 E1D0012B068 for ; Thu, 7 Jul 2016 12:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.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 ifRYRtD_-wBW for ; Thu, 7 Jul 2016 12:12:59 -0700 (PDT) Received: from st13p27im-asmtp003.me.com (st13p27im-asmtp003.me.com [17.162.190.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90E9E12B02A for ; Thu, 7 Jul 2016 12:12:59 -0700 (PDT) Received: from process-dkim-sign-daemon.st13p27im-asmtp003.me.com by st13p27im-asmtp003.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) id <0O9Y00400L4CZW00@st13p27im-asmtp003.me.com> for openpgp@ietf.org; Thu, 07 Jul 2016 19:12:58 +0000 (GMT) Received: from [10.119.8.230] (unknown [209.73.142.2]) by st13p27im-asmtp003.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) with ESMTPSA id <0O9Y01A15LDKO440@st13p27im-asmtp003.me.com> for openpgp@ietf.org; Thu, 07 Jul 2016 19:12:58 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-07-07_09:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1015 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1510270003 definitions=main-1607070172 Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Jon Callas In-reply-to: Date: Thu, 07 Jul 2016 12:12:56 -0700 Content-transfer-encoding: quoted-printable Message-id: References: <87r3b5q2zq.fsf@wheatstone.g10code.de> <20160707103506.GA29299@littlepip.fritz.box> To: IETF OpenPGP X-Mailer: Apple Mail (2.3124) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=4d515a; t=1467918778; bh=U5gTvl1E120cbgFVNoro5/1lVZmeiFR39NLKLqdIKgM=; h=Content-type:MIME-version:Subject:From:Date:Message-id:To; b=AThHsD5Hgr4KZyiaVOM+2PVOpkXMeIekW5Jqw+U+VbOeMO65bvtmiKKLMIn/DbhBK WQn1cPq0+3v9eswfc+XrseN6MLEiD2CI5tHQJ9vCEhDGWMsJptEi15zoeW7kY7E17R 3NsBSD4uKUJr9zGHvKnQ/hCIqo5/a4TTTE6eXyzRRJGSVtagHigodyUSaseNom+omp MqS11MooZ8MM/8al/3yWOGgKzhGv9qJQBlR4hadC3YGizwx/XwZstqL95RQ+wZnK2f oJmZ4r+IeBCUM6BPr/NbtyqFA9f5qBVrt3WWa0oFd/hiTrCUHUY46mAjNqqetAAZPK URREsdkQvyYiQ== Archived-At: Cc: Jon Callas Subject: Re: [openpgp] Tag indicating a MIME content X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 19:13:01 -0000 +1 on the proposal. I'd even go further with what I think DKG is saying that "text mode" is = something that OpenPGP carries as baggage back from the FTP days when = you had "text" (that could even be six bit or worse, like RAD50) versus = "binary." Dump as much of that as is reasonable, please. Jon From nobody Thu Jul 7 18:26:47 2016 Return-Path: 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 15A4812D8E7 for ; Thu, 7 Jul 2016 18:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.327 X-Spam-Level: X-Spam-Status: No, score=-2.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_HOME=1, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 eD7zfiyGp8Zy for ; Thu, 7 Jul 2016 18:26:43 -0700 (PDT) Received: from mail.jabberwocky.com (walrus.jabberwocky.com [173.9.29.57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44E4912D861 for ; Thu, 7 Jul 2016 18:26:43 -0700 (PDT) Received: from grover.home.jabberwocky.com (grover.home.jabberwocky.com [172.24.84.28]) (authenticated bits=0) by mail.jabberwocky.com (8.14.4/8.14.4) with ESMTP id u681QYZF016788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Jul 2016 21:26:34 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: David Shaw In-Reply-To: <87r3b5q2zq.fsf@wheatstone.g10code.de> Date: Thu, 7 Jul 2016 21:26:34 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87r3b5q2zq.fsf@wheatstone.g10code.de> To: Werner Koch X-Mailer: Apple Mail (2.3124) Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] Tag indicating a MIME content X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 01:26:45 -0000 > On Jul 7, 2016, at 4:14 AM, Werner Koch wrote: >=20 > Hi, >=20 > I recall that an indication for a MIME content has been proposed many > years ago but might have been forgotten. Thus I propose this small > change for 4880bis: >=20 > --8<---------------cut here---------------start------------->8--- > diff --git a/middle.mkd b/middle.mkd > index 033f11f..5519be3 100644 > --- a/middle.mkd > +++ b/middle.mkd > @@ -2156,7 +2156,8 @@ ## {5.9} Literal Data Packet (Tag 11) > may need line ends converted to local form, or other text-mode > changes. The tag 'u' (0x75) means the same as 't', but also > indicates that implementation believes that the literal data > - contains UTF-8 text. > + contains UTF-8 text. If it is a 'm' (0x6d), then it contains a > + MIME message body part [](#RFC2045). I am in favor of this (I vaguely recall when it was originally = suggested). I do have one suggestion though - this field (like the = literal packet filename and timestamp) isn't covered by a signature, so = can be changed invisibly in transit. That's not news, but I think it = might be worth calling that out explicitly to avoid future surprise. Perhaps something like "Note that the formatting octet, the file name, = and the date field of the literal packet are not included in a signature = hash and thus are not protected against tampering in a signed document." David From nobody Thu Jul 7 18:32:30 2016 Return-Path: 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 3D28412D8EB for ; Thu, 7 Jul 2016 18:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.327 X-Spam-Level: X-Spam-Status: No, score=-2.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_HOME=1, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 cHh_WTHn4nQN for ; Thu, 7 Jul 2016 18:32:28 -0700 (PDT) Received: from mail.jabberwocky.com (walrus.jabberwocky.com [173.9.29.57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8B6612D8EE for ; Thu, 7 Jul 2016 18:32:23 -0700 (PDT) Received: from grover.home.jabberwocky.com (grover.home.jabberwocky.com [172.24.84.28]) (authenticated bits=0) by mail.jabberwocky.com (8.14.4/8.14.4) with ESMTP id u681WMgF016932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Jul 2016 21:32:22 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: David Shaw In-Reply-To: <20160707103506.GA29299@littlepip.fritz.box> Date: Thu, 7 Jul 2016 21:32:22 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4EE4DDA2-C997-43C6-AE44-7ACC5304F9CF@jabberwocky.com> References: <87r3b5q2zq.fsf@wheatstone.g10code.de> <20160707103506.GA29299@littlepip.fritz.box> To: Vincent Breitmoser X-Mailer: Apple Mail (2.3124) Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] Tag indicating a MIME content X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 01:32:29 -0000 >=20 > On Jul 7, 2016, at 6:35 AM, Vincent Breitmoser = wrote: >=20 > I support this. >=20 > Nitpick, should this be "an" rather than "a" m? +1 on the nitpick. It should be "an", as "m" starts with a vowel sound. David From nobody Thu Jul 7 23:52:09 2016 Return-Path: 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 BFBA012D0B5 for ; Thu, 7 Jul 2016 23:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no 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 F5L9I7YYpgEt for ; Thu, 7 Jul 2016 23:52:05 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E32612B056 for ; Thu, 7 Jul 2016 23:52:05 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1bLPdr-0002V3-9y for ; Fri, 08 Jul 2016 08:52:03 +0200 Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1bLPYb-0006x7-TX; Fri, 08 Jul 2016 08:46:37 +0200 From: Werner Koch To: David Shaw References: <87r3b5q2zq.fsf@wheatstone.g10code.de> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: url=https://k.gnupg.net/80615870F5BAD690333686D0F2AD85AC1E42B367 Mail-Followup-To: David Shaw , openpgp@ietf.org Date: Fri, 08 Jul 2016 08:46:37 +0200 In-Reply-To: (David Shaw's message of "Thu, 7 Jul 2016 21:26:34 -0400") Message-ID: <878txck4oi.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] Tag indicating a MIME content X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 06:52:08 -0000 On Fri, 8 Jul 2016 03:26, dshaw@jabberwocky.com said: > Perhaps something like "Note that the formatting octet, the file name, > and the date field of the literal packet are not included in a > signature hash and thus are not protected against tampering in a > signed document." Thanks for the reminder. I'll create a issue for this. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ From nobody Mon Jul 18 11:49:08 2016 Return-Path: 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 3E00612D501 for ; Mon, 18 Jul 2016 11:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 F8mH1ycZyTmF for ; Mon, 18 Jul 2016 11:49:05 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 086DE12B077 for ; Mon, 18 Jul 2016 11:49:04 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id w38so96819364qtb.0 for ; Mon, 18 Jul 2016 11:49:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to; bh=K8/gchRcrjJt5QzvNUgQ69Zx/J3HvNQCehbENsUGyMc=; b=YgyFGE91c74VYGJBPedq5kmTFIQ0QfLSdPYcH3u6x86xxebSAJm7/8SZ+1GiIuCeQ/ 08PtYgO7mTsOVB/wqzSFR9fChWxCtxCyFmIEJR8AhHO5ZAd1ewWpXXL17PgdZAg/eGUp /apbUa89nz0RAYpUDtGQ4UKFHtKY/PSEULB7UGdIBC6gjgmfey4U/zzvDtUFQnLDnQkc urmrWma/GFA81aN8eC981hek1MI96zlPpcKWUI6omxRCsUoo1u+OLovTL/w1J7kKwez4 grzL6GLvkb58gCqemm+T2G5/SGd/CWuuVwICKvToN72rX/6GISxbUTkTCLnCL6/pzv62 1SUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=K8/gchRcrjJt5QzvNUgQ69Zx/J3HvNQCehbENsUGyMc=; b=LpK1tDzcrMKfHw0RxU9N780VrWE+cDbAgR4NO56+65fMHuP+tdTdDe4ZlPwQdz1/5L ixQGppE4cXZUA5Ho1KxpP02ujxdYrHwwlscPXaHTiSwOiTqi8hFHWFysfrl1g2H83gXD 48xhO8t9uG++7MNpeXcNDI0M767XgC+RImnyP+qJGDqAXKg8cnkWB6C4z1dr5ZhAPiG2 GTW357ObBy3rGLgLDeAr2bi3kdykbKWoXubmn9PefwatN5ddV3gVHmisxVAqF+bTi/rh b2da9ajnR/pqDNHLTReUV54VBuuYRJioaoABN1YTcZLxZ+ZAI8hRMojNaMD+rDzhDacm Y2WA== X-Gm-Message-State: ALyK8tKpdIpDfDRkClBPMR4VUUPxHUS/GMSXSpUL6NFd2GTGjZ/NFpljgcxp51fNc3/Eyc5G3dkcM3FjUVEbng== X-Received: by 10.200.55.91 with SMTP id p27mr53050640qtb.48.1468867744093; Mon, 18 Jul 2016 11:49:04 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.55.16.106 with HTTP; Mon, 18 Jul 2016 11:49:03 -0700 (PDT) From: Phillip Hallam-Baker Date: Mon, 18 Jul 2016 20:49:03 +0200 X-Google-Sender-Auth: c_adZ-Fy4Ed7uFQSqBV9b9s9MFw Message-ID: To: IETF OpenPGP , Russ Housley Content-Type: multipart/alternative; boundary=001a113988021bdca40537ed6c69 Archived-At: Subject: [openpgp] Alternative to Base64 X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 18:49:07 -0000 --001a113988021bdca40537ed6c69 Content-Type: text/plain; charset=UTF-8 As we discussed after the meeting, * Yes Base64 sucks * Yes alleged 'binary' transport SMTP also sucketh because dimwits insert CRLFs to wrap lines. There is an alternative that could be used, yenc is widely implemented on USENET. http://www.yenc.org/yenc-draft.1.3.txt : 1. Fetch a character from the input stream. 2. Increment the character's ASCII value by 42, modulo 256 3. If the result is a critical character (as defined in the previous section), write the escape character to the output stream and increment character's ASCII value by 64, modulo 256. 4. Output the character to the output stream. 5. Repeat from start. Critical characters include the following: ASCII 00h (NULL) ASCII 0Ah (LF) ASCII 0Dh (CR) ASCII 3Dh (=) It ain't perfect but it is about 98% efficient and we need not necessarily do that exact scheme. --001a113988021bdca40537ed6c69 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As = we discussed after the meeting,=C2=A0

* Yes Base64 sucks

* Yes alleged 'binary' transport SMTP also sucketh because d= imwits insert CRLFs to wrap lines.

There is an alternative that could be used, yenc is widely imple= mented on USENET.

http://www.yenc.org/yenc-draft.1.3.txt :

 1. Fetch a character from the input stream. =20
 2. Increment the character's ASCII value by 42, modulo 256=20
 3. If the result is a critical character (as defined in the previous
    section), write the escape character to the output stream and increment
    character's ASCII value by 64, modulo 256. =20
 4. Output the character to the output stream. =20
 5. Repeat from start.
Critical characters include the following:

ASCII 00h (NULL)
ASCII 0Ah (LF)
ASCII 0Dh (CR)
ASCII 3Dh (=3D)

It ai=
n't perfect but it is about 98% efficient and we need not necessarily d=
o that exact scheme.

--001a113988021bdca40537ed6c69-- From nobody Mon Jul 18 14:09:45 2016 Return-Path: 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 4441C12B049 for ; Mon, 18 Jul 2016 14:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.355 X-Spam-Level: X-Spam-Status: No, score=-2.355 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=singpolyma.net 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 xULXhwYHp9Cy for ; Mon, 18 Jul 2016 14:09:42 -0700 (PDT) Received: from singpolyma.net (singpolyma.net [192.99.233.116]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1EEA12D504 for ; Mon, 18 Jul 2016 14:09:41 -0700 (PDT) Received: from [127.0.0.1] (unknown [69.171.154.34]) by singpolyma.net (Postfix) with ESMTPSA id 9556748607C1; Mon, 18 Jul 2016 21:09:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=singpolyma.net; s=iweb; t=1468876180; bh=PvHSx/VCRWfXB8uP24rfcXq+LQIr+NgwH/2YTNkHDao=; h=Date:Subject:From:In-Reply-To:References:To:From; b=c7YGLpbI5dzQm06kQlMtmUEUmFGs/d4Dpb/yp+o3s2EkVj5Pk13R7CAli8H4mFBfA qSLOUGALt91LnL7SWLCC4m5CLn2R3aZ5GowwUTHBoizux9DCCVzvpQkQmo5CccsCLY JhXl59xGEP4PHT4+ldnTIPUjWy6xnVqBIWr5tEMA= Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Mailer: BlackBerry Email (10.3.2.2639) Message-ID: <20160718210940.5890131.90844.42664@singpolyma.net> Date: Mon, 18 Jul 2016 16:09:40 -0500 From: Stephen Paul Weber In-Reply-To: References: To: Phillip Hallam-Baker , IETF OpenPGP , Russ Housley Archived-At: Subject: Re: [openpgp] Alternative to Base64 X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 21:09:43 -0000 =
> * Yes alleged 'binary' transport SMTP also sucketh b= ecause dimwits insert CRLFs to wrap lines.

But if using PGP/= MIME there are already transfer encoding mechanisms to solve this outside o= f OpenPGP. No need to worry about anything but binary from an OpenPGP-imple= mentor's perspective.
From nobody Mon Jul 18 16:21:43 2016 Return-Path: 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 A5CAC12DB2D for ; Mon, 18 Jul 2016 16:21:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.287 X-Spam-Level: X-Spam-Status: No, score=-3.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_SORBS_DUL=0.001, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (3072-bit key) header.d=crustytoothpaste.net 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 zFVtel9D5SR9 for ; Mon, 18 Jul 2016 16:21:39 -0700 (PDT) Received: from castro.crustytoothpaste.net (castro.crustytoothpaste.net [75.10.60.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B20B812B044 for ; Mon, 18 Jul 2016 16:21:39 -0700 (PDT) Received: from vauxhall.crustytoothpaste.net (unknown [IPv6:2001:470:b978:101:395:747d:98e1:fc48]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by castro.crustytoothpaste.net (Postfix) with ESMTPSA id 337D2282AF for ; Mon, 18 Jul 2016 23:21:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=crustytoothpaste.net; s=default; t=1468884098; bh=ia3nUkXnv4BbCXANE3Pdyv6a9R/bXx7kBySS396lXZs=; h=Date:From:To:Subject:References:In-Reply-To:From; b=ALpfAPgksdkYrAlV0eItrih6rzF04IkJn6sc7sTR3NL34+R/V8KP1wYlHBUWuwYmv gjz8IiIWGTj/thqJqq1iIEwd1ow9OD5kYFOhBJvU/8sr7Uf/9euPTOPKeaPiZ2PC7M Rv96cy5lDSm0LFcu1pNpjeXlqr3FroEzWa1jrvjlmANCctAhAq4drKl41l0Q43XOf1 1XU3/ULXjvFz+9PQsa1kLl5ctzADqpT/xbUsCokbc8FQTLOtkg0FsjZa13pJJfHKSS 7vSMK+Tx/WMDjiIxnSUkgduv2/05gDUi0eDWWSSPNhPCRM1KL830E60v8yEQFBiUUz 8YKIvzbb1GVOjcL5Poh2KoXVVqCrIKLVKFRbWjIgEbkyPGMKXKM6lA8qVTXve8Ctxn iB7yba1Q2SJOHMYXhFu2byoWqYdbTgt7LIF/z6pyoXhBz5+M3a3L+icpgkvR2jqCH+ jLcCa1H7ul/ghroalXfvl2keYm9P3zHSnUQJMhXhdaCi5D0Pfn7 Date: Mon, 18 Jul 2016 23:21:35 +0000 From: "brian m. carlson" To: openpgp@ietf.org Message-ID: <20160718232134.GH6644@vauxhall.crustytoothpaste.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="pfTAc8Cvt8L6I27a" Content-Disposition: inline In-Reply-To: X-Machine: Running on genre using GNU/Linux on x86_64 (Linux kernel 4.7.0-rc4-amd64) User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [openpgp] Alternative to Base64 X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 23:21:42 -0000 --pfTAc8Cvt8L6I27a Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 18, 2016 at 08:49:03PM +0200, Phillip Hallam-Baker wrote: > As we discussed after the meeting, >=20 > * Yes Base64 sucks >=20 > * Yes alleged 'binary' transport SMTP also sucketh because dimwits insert > CRLFs to wrap lines. >=20 > There is an alternative that could be used, yenc is widely implemented on > USENET. >=20 > http://www.yenc.org/yenc-draft.1.3.txt : >=20 > 1. Fetch a character from the input stream. > 2. Increment the character's ASCII value by 42, modulo 256 > 3. If the result is a critical character (as defined in the previous > section), write the escape character to the output stream and increme= nt > character's ASCII value by 64, modulo 256. > 4. Output the character to the output stream. > 5. Repeat from start. >=20 > Critical characters include the following: >=20 > ASCII 00h (NULL) > ASCII 0Ah (LF) > ASCII 0Dh (CR) > ASCII 3Dh (=3D) >=20 >=20 > It ain't perfect but it is about 98% efficient and we need not > necessarily do that exact scheme. I would like to point out a use case we may not have considered: clearsigned hash files. It's very common for people to create files that are the output of sha256sum or sha512sum and clearsign them, so that everything's in one file. This requires something that is text-friendly and won't send escape sequences to the terminal. yEnc isn't that. People also copy and paste ASCII-armored detached signatures and clearsigned messages. I work in an industry where my sole access to fix customer machines is via an SSH terminal session; no SFTP or SCP is allowed. Anything that isn't text-friendly has to be base64 encoded. I agree, Base64 sucks in a lot of ways, but people already are going to have to implement the Radix-64 format for backwards compatibility. Even if we exclude it from the spec, people are still going to use it because it meets their needs. We might as well accept that and move on. --=20 brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | https://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: https://keybase.io/bk2204 --pfTAc8Cvt8L6I27a Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.1.13 (GNU/Linux) iQIcBAEBCgAGBQJXjWR+AAoJEL9TXYEfUvaL5qQP/R2iOypfklVlcjUupp9NOUw8 2uzI1Rtr9NB9VLN6oswryAq6EqJu107ws7TTQVJrSd0BvXq47Kb8yRSUcHFMEVjt oJqVlV225E1NDxKj4uS3zDJY/B1JF7W21AWajBVsvC1QfrY4gSS8pMmqyrXyDZqM DdnemAfGVM9sKnC0KoQyHCaVRLlXeZiR0ao5Xcg1sW1YxmFvR7i+65m75zi0iV5z LwhCZgDULUAvMUBn44yj95/Q7z/m/7X34hdPC+sJu6Txb3FlSTcrnmv64dqhJ9fl TlHKisWcrs3xjwPLLnA1VjCVanwA2W4wnVKki+Nnhv/R8ZzOXyuSS042kngUp/6/ FzChpnB9mlANnzDmLOvKL53dJttiwyCE5hFOmIxKVSv8Mx2NdzkrgTvpUR9Nqn2t 4GnGDRlVEToi4HAdHlx9jhcbC7LQLC2/ggUn0WjsESMMVy1dt9cl6cvoGZ3BYn5P /q0gJZzmmQLgdFZHcG8y29Qzy/FeoJtf5O7n7iv95jCRND8ewdunRLedvq7/URae DN5GoVvlQjq6qJ8FitLXQfFUgzmL6Kadzv0fQl+WFGaFysXGAWZg6/XY3mOkoAlf IOP99gdpfZnOgmo0y1RFLidPCpqLjy7XB6HoMC6rf+ffTftFXarQJ5Tv8YnN0/A3 2/53FqsqzemCrG1vpilH =25nm -----END PGP SIGNATURE----- --pfTAc8Cvt8L6I27a-- From nobody Tue Jul 19 08:19:59 2016 Return-Path: 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 DB9FE12DE72 for ; Tue, 19 Jul 2016 08:19:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.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 klB9ZMqwCQ_3 for ; Tue, 19 Jul 2016 08:19:53 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0094.outbound.protection.outlook.com [104.47.37.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACDC712DC7F for ; Tue, 19 Jul 2016 07:58:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=RtymsqF0zAHuu+r/zfwrzIqjhtUGF7gBbi9zyn/4mKc=; b=W8msLLh/+sA8D0YS38HCCAGS/fclp5fsF/8HRRKYEFpEqUQnWy9au7/8A2NW9hulnpVIO8+poPqIsdfiG5FvGaNCLgzwixosyBOINHXtGiZZtdRI+X2VXyGj55FieVkWBi3TgttLXSBZF1mTOeUUYVWm6Kx1TYrVIAqj0lbvsJs= Received: from SN1PR0501CA0005.namprd05.prod.outlook.com (10.163.126.143) by SN1PR05MB2304.namprd05.prod.outlook.com (10.169.125.18) with Microsoft SMTP Server (TLS) id 15.1.539.14; Tue, 19 Jul 2016 14:58:56 +0000 Received: from BN1BFFO11FD021.protection.gbl (2a01:111:f400:7c10::1:119) by SN1PR0501CA0005.outlook.office365.com (2a01:111:e400:52fe::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.5 via Frontend Transport; Tue, 19 Jul 2016 14:58:56 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.19) smtp.mailfrom=juniper.net; crustytoothpaste.net; dkim=none (message not signed) header.d=none;crustytoothpaste.net; dmarc=none action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.19 as permitted sender) Received: from P-EMFE01C-SAC.jnpr.net (66.129.239.19) by BN1BFFO11FD021.mail.protection.outlook.com (10.58.144.84) with Microsoft SMTP Server (TLS) id 15.1.523.9 via Frontend Transport; Tue, 19 Jul 2016 14:58:55 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMFE01C-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 19 Jul 2016 07:58:53 -0700 Received: from eng-mail01.juniper.net (eng-mail01.juniper.net [172.17.28.114]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id u6JEwrx96204; Tue, 19 Jul 2016 07:58:53 -0700 (PDT) (envelope-from mdb@juniper.net) Received: from eng-mail01.juniper.net (localhost [127.0.0.1]) by eng-mail01.juniper.net (Postfix) with ESMTP id 88FA11148B; Tue, 19 Jul 2016 07:58:53 -0700 (PDT) To: "brian m. carlson" In-Reply-To: <20160718232134.GH6644@vauxhall.crustytoothpaste.net> References: <20160718232134.GH6644@vauxhall.crustytoothpaste.net> Comments: In-reply-to: "brian m. carlson" message dated "Mon, 18 Jul 2016 23:21:35 -0000." From: "Mark D. Baushke" Date: Tue, 19 Jul 2016 07:58:53 -0700 Message-ID: <18467.1468940333@eng-mail01.juniper.net> Sender: MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.19; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(7916002)(2980300002)(199003)(189002)(586003)(76176999)(7696003)(5003600100003)(117636001)(54356999)(50986999)(4326007)(8936002)(305945005)(68736007)(81166006)(81156014)(69596002)(77096005)(87936001)(356003)(92566002)(2810700001)(2950100001)(5003940100001)(2906002)(8676002)(86362001)(110136002)(50466002)(48376002)(76506005)(47776003)(53416004)(189998001)(105596002)(11100500001)(106466001)(97736004)(6806005)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR05MB2304; H:P-EMFE01C-SAC.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11FD021; 1:bku8k4NRfaiazbnlnXsLcOYgvyhJ8H6MqlyBL/zUtrLgDl618FCmJfTCjh/1hbnIwBqa+PW/fvOCh8pv6ZA3SQY3XvsQFVIct1H5lwvakFBmDzA7PLGCetOm0ULmBj2ijQ2oktktc7i7Dw2XvMu6eltomEy9G9+arzmYlJR6mv++wW2cgumQx70t/+u4py7jCv80BKK01b8bqkZXso7AU3SLRe08S/7LfABzMpR+CYa7ioTldM7u78u9NI2sjtw2wPnmhRWo3hcPXcVt/YB94k7+2td7rQWDhc3UK4Wh1UXKsXjKsoDIRCBm4k1+EC+ZhrdkKP8NQ2Fbrav/jI/pX552SPXgekFLQYrSON9TynHkQUHfAEF2aNbf8USDrUjaBsKRFupTl7n+IkRV+O3Ve3ZnxnovnlQZffTI6UvFLnyvP8pg/hvM6LfWWPpu3mcqQJuMzgkFufzpRVS7J1uh9k73api6MPYriE5Hi4fb5C2fNWO8zS+ti2UvCxwqKiuRii0KDv4vXMJV7GfjJaBbJA5MRgD0rUcr1lNoJNc97q4= X-MS-Office365-Filtering-Correlation-Id: 538b65d9-c399-4721-5e8c-08d3afe53519 X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2304; 2:+H8fFLDy3zuhQmhtOj34Zm/wFX3SjwE0BriztCeWdUkrIW5q2JYQs+SkpyvM55OUoPX13PlKo57rsXPAxa1w6pDB4XlQ75cWpB86nmJNTc4KZCJV7QrhyGWV3xAKhehWPRzFGW4R2vUbTbscdsiHhCJ55J3EccDC0I/L48Yn75RoylaLKz1DAXOfYWmJ68v7; 3:90DLrl4BxWV5xAnJYFi06X8rvfCwebsrPH/OGsuEIvSKPo8FFYkMuNG+Azh8qGcrpqyzb6PaV5FvFCEQbdV8W8F5798rZ1SP6+lIr18PnT1O5XGoUPdjPqUgSoz7SZOjHF2XUyPE3R3pbaY2oG3fok21Yx2vNgn3YhDlz73fO+dV35WU+bxibJLcMHm1ceofMIeLH9OKy64XhMRaaEzbF+G+MEtMJIy87aCiat//GxU=; 25:WJBuxS1+/3Q680z9o0aW3MJ/o+dQM69nNxcAes+0WM99YTbTmV+VQY/OntVyS0cV6zTm+5PsCAqvo2Ll67vFdVJfTnwx+MWUH4erd3eLp33FgHVolmrj21gUd/3JtDk0QPU5QpLC70qAVrJVyt/sVEEIdStkh2tk4DUuT5iGzD/sXnZygL83/TQ6JuehsHIFRl19K8w6V+yPpOmsP8NacKxKmTCM1o8SoVte5Kx5V0f5jLmBDssjtizIUFJPsilFGMp3k6FurGFQTQ4ri3wHlIm8zy9ow3hDwGN2KHIjdSa74MxqqM9+0nI7R98aAQSeRtcGO+xtosklUNxB+1bXTQOd4j63fea2pMDluX40pd/R1Zsx3J+Xd47rSF99HIMPRWlqu9ORIetcKtyH8dMzPbak8c1Fk20i/iklUbbh4JE= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR05MB2304; X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2304; 31:pkRHTDxMVwWn262jkqJ9Lx3OgKCeQJM1sD/EByRJyC3Xrf2qJO24Flgyh3hqn+m3js8lfU45VqbIkaPwzZLns7txxzCOc5IJ8SCX0erJCZWlJwiL1xZKmL1FoS3k+7t44BtJahEMX2H65+lY6LTCj8wr30IxauWzDtdFLgkf8zBctKCvEwauzPnr/y/AHpSu0bu59JCRBtRSIsUqW+O2vw==; 20:RjU81ApS/cBRMx10qj3/8i/ZMvSH5ClvuIRlsDoju6hxj7saUuxp+ScxGy7lUzyRSq4qkdtQCA6EoZCHPInM84kiYP36M44M7B7nSkRGw/dxS7uieUfgTwVVCJX3AH3tucfg/QKLGna+IS53SfgMJ+HdwaFutPr5Jo/vEXPSM2vvxofjtlbLRrVLeqfKhK/fUZ0/xJ3/aNflnLfB6IzSexYjDvT0RjE6Er/TK0OeposlCPygVBUOFeV3IgIi6PW48tSE+AocePEnp3I22O1YWXbITiENL94aIsE11B17d8dLZ0yW1C556Gc+0nayl9D7YgwU8F3OHCOqp9onOwAAlYvAG62JZAtZV1luHIpMktYfJJpKjNa6eJ3SYnK2srmpk2Rx1kOMUdIkr/0IeovMSlAAAK4k/+I7/mgoZmYnvHhh7TX/Ru6Eqe9RyQnoYL+wn62bHj0uad5rx3BZvPO5xbXOsy3HeAgu7DByf76mcdQowx17DiX3hMt66PkW8k3v X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(13018025)(8121501046)(13024025)(13023025)(13015025)(13017025)(5005006)(10201501046)(3002001)(6055026); SRVR:SN1PR05MB2304; BCL:0; PCL:0; RULEID:; SRVR:SN1PR05MB2304; X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2304; 4:VoYVkDdXecEDvUSkdx+zum1uvWx1oLDOZwYFAxAYCXFgz3ayfzNaMZqbjETXWrS15mZO2yHyEi7XNlGJg4vmwR6pofgn80yCzxy/xplq3GiPnFQirgUDYzxvfjmjxsobuY8iZXaYcYo8h8eMwlcuk+nP0JDdFQF7ecXDDejfjwFSpXao8VU6zvTEBQ+TQwFamlfojVck/ijNikQEZmcWIg/8L47LRxHrXucr9m23ntxkpIFANLjW+HUZhcGMXZnnZZGOT9h4X/n/6F9P3e+7U0LC9OcyFboy3Gq/ooC8EFLu6YObbKSkT29HPpLblMYXmNfPPD2as9dUqu+fmz9gEL56XT3LHspNtsxZboHnDI9Y3PtusBLhXH4HuL7ihzJBqB8fKcUZYiZdr58Y4dNJ78Q1iRomGnq2ZxheTU0hc2Fn3jfAjt9OewFudPX+5L8JTjPvzx5ZrY0BGDcduRN7kr6Lj+79loRyNnYtVrz5Ehs= X-Forefront-PRVS: 000800954F X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN1PR05MB2304; 23:OTgvgSmr9I7GWs1MiHxjn9EZzjypS0TSd6B+j0sDZ?= =?us-ascii?Q?PANeaT1djxpnxUWIQeenu8mFGru854SC6UFMCo6iP1bRJtfOg9Isokgus7MM?= =?us-ascii?Q?75UOxHFxGatMiprQvZLn7M9e+0QBIPJpmyp6qG9olQRKL5Q8THtmOEuWIhiq?= =?us-ascii?Q?AfoJtDLncfUwN3wrT7aPk7947/r0xMJSzHJ38pFoOs6g8JEbIhvNwX1YvLIN?= =?us-ascii?Q?01ZmWv5LTawjStyQjWU7mBe/aWYpjEOC2T3TXG0F4bLaobxgdFtN1h1NUmcF?= =?us-ascii?Q?4b3jUMfyZ3DqL7TDIxHG2rPd8N0caEJeebdFCwugFTqB8WxSZxPEVeGFgfC9?= =?us-ascii?Q?RpGbuHAf/52Y8Xvb0rXMRDuRqvotQykRg+NLCz0c9p0I/HrAVHsJXR1S+dve?= =?us-ascii?Q?69XsnFXTtp/Y0xJi4hHAh6aaHAEl33KfO++f/U61Dw3D6saX8j8Hel6Vt+NP?= =?us-ascii?Q?5+a0TbY9NPdWaOforDNHLLuBDu9BapMzL2P76qWk6nOxWNU/+F7RU6bJhHSL?= =?us-ascii?Q?jb/+G+0Dk2IwapWRd/6olXdTIzZEpwxWRWgmwPdD7GNJvwaQ1mg3lET4rkuQ?= =?us-ascii?Q?GbgDp7kuxpxxjQS0SJdkK9NksQD96SqbsDewg5bwZhT0ik+/4lcvG2rouNQU?= =?us-ascii?Q?mdmk8Uy9YCL+Y7Gq3q2mbkixbODH+yGWwmz/PStikNTH3AmFaj1QrhdIHVdp?= =?us-ascii?Q?KyPS0B8T6abvzf5KrC2qw3LzXPAZs/Qb7HLmW8hEpEHU5TJ0xuRa9xlg0qW7?= =?us-ascii?Q?DulUhykKD61krUTZzFsm2fgQLdz2L4vop3PbBF2Spp7ll554P4vgC8qT3bd5?= =?us-ascii?Q?NT15ytgmvGUp1J2CKXrmT3yLcnZTOCF1CXFssP1lAeMPj2XCd/mYnuY0nQ2r?= =?us-ascii?Q?mLhGMKXLc2Pa+Pxw8fWy3xv+S+4ToJVJX1hmN1l9HETys2hESOLwrEQmHsBC?= =?us-ascii?Q?FOmfSLn4UPCKfhm5WpwjmkpzFHQKBKv/I4UD9pnZjr3VW1QiJ6kMHmU+n2aA?= =?us-ascii?Q?U15AJzyarwjPIbRDMm6386Nyrg6bfUUZOIkZxHVXafiJLebnkXLRcTNr2sOK?= =?us-ascii?Q?vDf+aGMc3BlT4cRtG9BsRuzO0Bl?= X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2304; 6:5YJqIXXP3TOPPMpn4gppMelllssEcm5iEvy3T1fluw+YG8l6rIopmRjhiNhTKmFSLEPC/p7wYucprZGoB9o7h077NvaEne2SLz7Od10XX0yj1Kx+ciXsXV03ZMAa2j8fRgd1Ag2iv/sILslTAcmO8bCoHh4yC7oibnLv3SFDdF3FoLPiFX8tDotpHV74r/4KSalfXysZis9coo3CpVktKCVCzSKiyWYnls7XAfVl8/Bw/LySN++tYshFYKoZJ/a57SwpDZ6bwUyMMsJUSq6BuKOZEMrdalynoPnAc7O+KMgVSkK5ZDjKX8VPQ5Fm42uXeZ6vNHLut9XMRnA/aczwUg==; 5:39sm+mmKnKc2wiHxzywiJ4/9m55ayU/T0WaEuPu3gUa+SsbvIZjFXA7uS6G+QcdIjN+DruOYQY1bLvX8OLwQG47K1wsWnSCkVc3s9ID+yA0ZeIA+kiyp/c2DuAW2Dhbyic4AJawuqGwBPUlHken5Pw==; 24:ywWeELcleNm26oWsEFXlPnuOgMd2PwvjhRvXrEjy0aZqye89+h0zyB2Zfy1iXY9iHa9CqICO3FF39SjM+axaZQ+fqcN0PkkxMepRpBdmaP4=; 7:X7cubcquc4N90rfSmi4hPuS6DN2NNPrPHzKh17Znv3Ypx0Zk3AlwPeP1B8lOYY2akQ2QmBNmtlsxUCRp9WcyqUo8CEDxzlYBs/e3uhF/d5YIrwLbJ/GfS3/3pemYRtyTD3Iwv8iZ5TMZu80BZZ/3SZJrR+p7RA7cgspmG/MVGzaIj8g35RuadUt26+anfc70UNo2SCnCCJ4LWT0m1rxX4DL0NV3rXBOlvG91O+cM8QSaY7JEZC1WaC5O1skPN591 SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Jul 2016 14:58:55.4798 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.19]; Helo=[P-EMFE01C-SAC.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR05MB2304 Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] Alternative to Base64 X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 15:19:56 -0000 Cutting and pasting text is not always going to do what you want. I will note that some 'helpful' programs (including some Mail User Agents) may transcode character strings. For example, the two characters '--' UTF-8 (hex) 0x2d 0x2d get transcoded as EM DASH (U+2014) or UTF-8 (hex) 0xe2 0x80 0x94. Or three . (dot) as HORIZONTAL ELLIPSIS (U+2026) UTF-8 (hex) 0xe2 0x80 0xa6. Then there are the smart single and double quotes to consider. So, I tend to agree that base64 is needful. -- Mark From nobody Thu Jul 21 04:47:24 2016 Return-Path: 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 C678D12D5A2 for ; Thu, 21 Jul 2016 04:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 XyEy-KuDG6Ac for ; Thu, 21 Jul 2016 04:47:21 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05E2512DE05 for ; Thu, 21 Jul 2016 04:45:25 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id j12so64696680ywb.2 for ; Thu, 21 Jul 2016 04:45:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to; bh=yHG3+wzHglw3nf832kDVdap4T9uTXrzLe8fwWAOd+cA=; b=K7xzUrWQed/tbGvxHJw+r7i26aKpdpCim+Qp6vcBKtG3vmF3YWAmk59dtOTD3DkweC NaN8+CffhuFl9D36efXLUh7t2NjZ45o4w6TpkU6q4A+KPbvKiQili6jgvXJoUhCxUrqg R10YxmCSI0b0b0G7px6EHqdLSSNt4hICVyUSm3JRwTjC1JCB1Jx7hVzXxgIuqHnqSXVC 02xSaOHfkANMZk9BPF4nT5grOqp+XnCexzdsdPjigjXLx7ok/MHmhaUV9Msbm/odBozc hNlAn5c7Mvs5t1H+fusj/ErA070C1YVM/oBeH24WrQ4Rr+jV35mNv3ciz2owxRtPoIgK 1B+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=yHG3+wzHglw3nf832kDVdap4T9uTXrzLe8fwWAOd+cA=; b=Mxmig5ezs6I+xcUPgcgHjzhmb6FW6T15dqJoow3xFRRI4gwKWpWaj/4D+iy0dWOkGj 9VZZL4sdKgDpdApjTPsPJHXqTcnQ/T+85Lw7tPq9DIyL0Otm8vl0b5b64Eg/kLOwUNMR Nyp+FIbcKdnrMYZPTuVUXQT1u2dUk3mHV3Bhe4f5Kl8f4W/Tv8hIUiuTcxfaNfToPZy3 DgyaBoCLYbdzMif1SW3d5sZSXH0pdBhAh/u+cTK9PVkWRHs1OrsCu6FZ4UsgxZ9t9bYV BZIZQgm/b1fuPlKMNO3kzo9Q1D1atPHmEFuWAE3vqmAP1GSloE3QB2Txjm5ZdwiFj/lD F4zg== X-Gm-Message-State: ALyK8tK7K6tkACCcrNObYFqJBIUXpR6+m5ID2fN2DRLBRIl6Ynj1k5TipBomafXICu5uJMU/+9+uAlNsYAgn9Q== X-Received: by 10.129.104.9 with SMTP id d9mr35785239ywc.110.1469101523952; Thu, 21 Jul 2016 04:45:23 -0700 (PDT) MIME-Version: 1.0 Sender: barryleiba@gmail.com Received: by 10.83.33.137 with HTTP; Thu, 21 Jul 2016 04:45:23 -0700 (PDT) From: Barry Leiba Date: Thu, 21 Jul 2016 13:45:23 +0200 X-Google-Sender-Auth: qUYDSDJ7KfaNfQD3yEEAHxlP9bQ Message-ID: To: openpgp@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [openpgp] Gitlab information now on openpgp charter page X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 11:47:23 -0000 I have put four pointers on the openpgp charter page in the datatracker, here: https://datatracker.ietf.org/wg/openpgp/charter/ Those links are for the 4880bis document, DKG's note about using gitlab, the link to get a gitlab userid, and the gitlab Quickstart guide. If anyone needs more information than is provided in those links, please let us know and we'll try to make that information easier to find also. Barry, co-chair From nobody Thu Jul 21 06:48:12 2016 Return-Path: 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 1F8BF12D0AB for ; Thu, 21 Jul 2016 06:48:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no 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 kUXNf_Sd6s6i for ; Thu, 21 Jul 2016 06:48:09 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id 7715812D19E for ; Thu, 21 Jul 2016 06:48:08 -0700 (PDT) Received: from fifthhorseman.net (dhcp-a07a.meeting.ietf.org [31.133.160.122]) by che.mayfirst.org (Postfix) with ESMTPSA id 529B2F999; Thu, 21 Jul 2016 09:48:07 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id E35CC205A0; Thu, 21 Jul 2016 14:45:06 +0200 (CEST) From: Daniel Kahn Gillmor To: Barry Leiba , IETF OpenPGP In-Reply-To: References: User-Agent: Notmuch/0.22+77~gaba8744 (https://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Thu, 21 Jul 2016 14:45:06 +0200 Message-ID: <871t2nw46l.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [openpgp] Gitlab information now on openpgp charter page X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 13:48:11 -0000 On Thu 2016-07-21 13:45:23 +0200, Barry Leiba wrote: > I have put four pointers on the openpgp charter page in the datatracker, here: > https://datatracker.ietf.org/wg/openpgp/charter/ > > Those links are for the 4880bis document, DKG's note about using > gitlab, the link to get a gitlab userid, and the gitlab Quickstart > guide. > > If anyone needs more information than is provided in those links, > please let us know and we'll try to make that information easier to > find also. thanks for doing this, Barry. I noticed today that https://tools.ietf.org/wg/openpgp/charters still says "concluded WG" and also doesn't have the pointers you just added. I'm not sure how to change that page, though. --dkg From nobody Thu Jul 21 07:17:15 2016 Return-Path: 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 E444712D60D for ; Thu, 21 Jul 2016 07:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 X25Er8DKPvmg for ; Thu, 21 Jul 2016 07:17:10 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0358812D14A for ; Thu, 21 Jul 2016 07:17:09 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id z8so53769447ywa.1 for ; Thu, 21 Jul 2016 07:17:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ZtTc7bj/+nsUfkPSanTWnltdj/DSdxaPOds0pGwYdPA=; b=kFf4xfd2fLKA1zQLUKPejWKgY2SV87EIcY8dYFaIub0EETqjtdi8oycVxfnCZHz5pn uPxLwxJYVCZJlRQQnNSyCCiSZLfIX43qV56nt8y9VhtP6c/CuHb/BFuZm/WWv4FsRJLP Zzse7olHpmFejIIejxMjMuxwgXYDpX7cEF8JTVnrPTh4qWyY2CsjcUVb+F6NuaQTVk29 Ep7CEQmaqHo5Z9M7lNEX8B3sklRg9Nwmoti9py2ue7vK68zHif6qtWmea5Yo2vOzvBi0 PKhqQi+IXdmibkVChNIiJ3gZ+GqSxuDm/tGrWG6oWcSyPj+Js1kIFWt+yKN4P8GHwJIA qdgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=ZtTc7bj/+nsUfkPSanTWnltdj/DSdxaPOds0pGwYdPA=; b=Arn98u/n39Hium2SIwz3dwo08f2S2yS23E0hKO+VqQ3F1VycVT/16a6J6h2jmtqriq QBhuWOm3k53bFrpgvjw3+1KJKVDBdtZoHUg3kLSuD1xwyWb0G1hFllBzSeriKqxoVNIs pyzVYtp/qasKsqAJZbDBP5jMmYCSC4ITrlPVjfq4vdS3rsguT5CDyl87go05bM2jlOrX uCCk6LuGOLJEAZPtau+KnwMTa4dp+9j7atESBguTKNTiE3IKyoTmxKNofZgOkFF2cBsf DH8ZeiQvUHYBFL6AAHIy/MM+gyGbOQnyKKEFG6ttkrUvyk8jDUGCGX+D8TeWZc4QhjcW bGkg== X-Gm-Message-State: ALyK8tIAzwBm3OZqXXaQKNE+nZv6CQHdKKcfUjRUsKZyCHmpgfm5/L1bAQcEhTknl9agdiuaP1Rr5+ZJxxa/wQ== X-Received: by 10.37.92.86 with SMTP id q83mr24190823ybb.129.1469110629227; Thu, 21 Jul 2016 07:17:09 -0700 (PDT) MIME-Version: 1.0 Sender: barryleiba@gmail.com Received: by 10.83.33.137 with HTTP; Thu, 21 Jul 2016 07:17:08 -0700 (PDT) In-Reply-To: <871t2nw46l.fsf@alice.fifthhorseman.net> References: <871t2nw46l.fsf@alice.fifthhorseman.net> From: Barry Leiba Date: Thu, 21 Jul 2016 16:17:08 +0200 X-Google-Sender-Auth: y9YEwlPRSAO_onwACgSW36CKuIk Message-ID: To: Daniel Kahn Gillmor Content-Type: multipart/alternative; boundary=001a1142591c30e811053825f989 Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] Gitlab information now on openpgp charter page X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 14:17:14 -0000 --001a1142591c30e811053825f989 Content-Type: text/plain; charset=UTF-8 I'll check with the tools team on that. Barry On Thursday, July 21, 2016, Daniel Kahn Gillmor wrote: > On Thu 2016-07-21 13:45:23 +0200, Barry Leiba wrote: > > I have put four pointers on the openpgp charter page in the datatracker, > here: > > https://datatracker.ietf.org/wg/openpgp/charter/ > > > > Those links are for the 4880bis document, DKG's note about using > > gitlab, the link to get a gitlab userid, and the gitlab Quickstart > > guide. > > > > If anyone needs more information than is provided in those links, > > please let us know and we'll try to make that information easier to > > find also. > > thanks for doing this, Barry. > > I noticed today that https://tools.ietf.org/wg/openpgp/charters still > says "concluded WG" and also doesn't have the pointers you just added. > I'm not sure how to change that page, though. > > --dkg > --001a1142591c30e811053825f989 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'll check with the tools team=C2=A0on that.

Barry

On Thursday, July 21, 2016, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:
On Thu 2016-07-21 13:45:23 +0200, Barry Le= iba wrote:
> I have put four pointers on the openpgp charter page in the datatracke= r, here:
> https://datatracker.ietf.org/wg/openpgp/charter/
>
> Those links are for the 4880bis document, DKG's note about using > gitlab, the link to get a gitlab userid, and the gitlab Quickstart
> guide.
>
> If anyone needs more information than is provided in those links,
> please let us know and we'll try to make that information easier t= o
> find also.

thanks for doing this, Barry.

I noticed today that https://tools.ietf.org/wg/openpgp/charters still
says "concluded WG" and also doesn't have the pointers you ju= st added.
I'm not sure how to change that page, though.

=C2=A0 =C2=A0 =C2=A0--dkg
--001a1142591c30e811053825f989-- From nobody Thu Jul 21 10:05:24 2016 Return-Path: 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 96B9212D7AA for ; Thu, 21 Jul 2016 10:05:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 iepISVLS5f4t for ; Thu, 21 Jul 2016 10:05:21 -0700 (PDT) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DDFF12D66B for ; Thu, 21 Jul 2016 10:05:18 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id b62so81710956iod.3 for ; Thu, 21 Jul 2016 10:05:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=tom/3oA0LXI3aPWyvMUx61aTsF3Ve99tKjuMF0F5drM=; b=zfVE9VpspHDMwcvhuuB8x6vZwl83Ov1EmilPQmJb7ug2etBScWZx3/2Hh33vL4HE4h 2nv1G2Q4Pu/ikvKpmkcDN5IHMhc+aOt5pfqR8+NoJWnbG4MNkIowzTcIXKv1khuvTVm8 Z2Az5zr5VMfyFHnpGaQ62+IlyMw+G8sNteJF/YijUh6N1wsACgfJo4ff6F+HwpHRydOo TGiyDGP52okCqT++GYqW4J5ZLn96j+y99FRxMnHsemqMUcZuGs2LOsgVGpA58hnPXpLt tgIOmU5I9sIdHZMoDp4Hm3BCJigfkgyHFjxnk3rBbxIx2RQV4nb+kUOt09pScxXeU2pb ziJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=tom/3oA0LXI3aPWyvMUx61aTsF3Ve99tKjuMF0F5drM=; b=b2wX0ukYsTltQKG5qoAqH/rZ8leRw80CNHvY387qw4ZFyo0AsUsc6Ygnm/bdTgBrZL Ws9YIyasxu+v1Y9qDBoglsCXZC8loGOua1H0RWJGiitoRKF+4ygiHm7mGg1xVYdjCPr4 xhK9XWpfBk0zJ5Rf1pUup9s3rPOrrcP6UbNsKq7avUEkOR9tg2U1oPCV03EuDmuL2Ti7 TiAGqy0cpu2W9/ymLciTR5W17Tv8WcQFDbFNE/lbe/wS6/0QW+fUGdJt0qLRQEHX7PpS KKUkjdSkU0dBga03bzgiYZT6BTqglKABzN82VLMbXta7F5VZ5nnDu7Y6pSY3zixvo/ny N/xA== X-Gm-Message-State: ALyK8tJ2Nzej59vLb8y7ECqlOWnjB05bDsPYIDX04UdcgHvgetyq1O2VxcaI1U3Bq5nOXtVQygcMOOHb8GEO4Q== X-Received: by 10.107.55.135 with SMTP id e129mr12958431ioa.129.1469120717425; Thu, 21 Jul 2016 10:05:17 -0700 (PDT) MIME-Version: 1.0 Sender: barryleiba.mailing.lists@gmail.com Received: by 10.107.153.78 with HTTP; Thu, 21 Jul 2016 10:05:16 -0700 (PDT) In-Reply-To: References: <871t2nw46l.fsf@alice.fifthhorseman.net> From: Barry Leiba Date: Thu, 21 Jul 2016 19:05:16 +0200 X-Google-Sender-Auth: 9gVj0LXfTbRnfhYt0TmwrGPryJg Message-ID: To: Daniel Kahn Gillmor Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] Gitlab information now on openpgp charter page X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 17:05:23 -0000 >> I noticed today that https://tools.ietf.org/wg/openpgp/charters still >> says "concluded WG" and also doesn't have the pointers you just added. >> I'm not sure how to change that page, though. > > I'll check with the tools team on that. OK: Henrik has corrected the page so it now shows "Active WG" and has the correct charter dates. But we should all note that the tools versions of these pages are in maintenance mode only now, and we should get used to using the datatracker pages instead. The tools pages were great when the datatracker had less function, but the latter has caught up with the former, and the tools team would like to stop maintaining duplicate pages and concentrate on fixing bugs in and adding function to the datatracker instead. If there's a reason that people prefer the tools version, please let the tools team know why, and they'll look at beefing up the datatracker pages. You can post to if you want to ask about this. From nobody Fri Jul 29 12:24:51 2016 Return-Path: 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 9026E12D833 for ; Fri, 29 Jul 2016 12:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 dpSD2ZMf4o8N for ; Fri, 29 Jul 2016 12:24:48 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF29712D1E6 for ; Fri, 29 Jul 2016 12:24:47 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id x1so99669562qkb.3 for ; Fri, 29 Jul 2016 12:24:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to; bh=hts0xtmSwxyyKoBdvJWwgihcyseyPtYtI229Mtxb23U=; b=GPAuHQEgPswSyporChXBmxCAy57vEdYWtVOmiNtfR2rXoL/qQqNEvlNff5joO/ZB50 w54OLTftK31Xn89GQsKwttbaFiSYcFPz8T6n81qAmNdECPzWh5s5D5ouOgl1w3f4CA8V fTl/zFf7/PA7r9v/5VvbrB7areLM7yhB+wD4Tj9GjsKrNFBZHD3NeKNpKqPRWrz44ihZ EVLE5FMV0T6r7ahoSNpMK975X6lHo1zgdzYEnRXwzB545SJ9jKRN82o/yecv64hFv9xR hmLR/5K8kit1g5aarQ+yMQ14ALAh/HTiJKnS/PcrutrdHlTgqZZFimBSKknzFc55h5Eo d7pQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=hts0xtmSwxyyKoBdvJWwgihcyseyPtYtI229Mtxb23U=; b=N2XUymfauGKweUwtGkViIn1ypDAq8RegmhYxNYK+FfQS5pnXAzdEXOJdwEOqqQ76xj M+w7x3KwS4dYG5qwxl91PHBam59VJc12RupZZgtnFqenXGJl+l0W90q33neulFtDHwrb nlIVYj0TZ881sCmzNLjwWWIpPRYFOUAhOBidcCOvHwUszaCdf6VtwLDL+9WBl9DyKEBl tiIMg6ZTCu3L3nGT+wRdwHfKHr3UuriaNUP+Z/cgkgqqxE0h8wGIAj6WNojNjiPw2Usv SkajTtg+OysGi+PUuWbyZOH5Wh4ycxixqhRr3K2xNBHv53DioOyeKjasTIf95zDhLCyT X38A== X-Gm-Message-State: AEkoous7CNIGPPkWEpY6BIlY91G7AMAJW8OuECaZ3dhBV46Stql8bR3IBPRcLu8PYNVrCXwTpWwocPvKDBpx+A== X-Received: by 10.55.215.152 with SMTP id t24mr4787392qkt.210.1469820286947; Fri, 29 Jul 2016 12:24:46 -0700 (PDT) MIME-Version: 1.0 Sender: barryleiba@gmail.com Received: by 10.140.39.52 with HTTP; Fri, 29 Jul 2016 12:24:46 -0700 (PDT) From: Barry Leiba Date: Fri, 29 Jul 2016 15:24:46 -0400 X-Google-Sender-Auth: iBC5hy0X6SaM0gVUXJSxTLQlet0 Message-ID: To: IETF OpenPGP Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [openpgp] Minutes from the IETF 96 openpgp session posted X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 19:24:49 -0000 They are here: https://www.ietf.org/proceedings/96/minutes/minutes-96-openpgp And many, MANY thanks to Melinda Shore for the most excellent work on the minutes! Comments or corrections here, please. Chairingly, Barry