From nobody Thu Oct 6 11:18:57 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 9878712974F for ; Thu, 6 Oct 2016 11:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.596 X-Spam-Level: X-Spam-Status: No, score=-2.596 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, LOTS_OF_MONEY=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 YxiwJ9kTm655 for ; Thu, 6 Oct 2016 11:18:53 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c: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 87CEE129717 for ; Thu, 6 Oct 2016 11:18:53 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id f193so305705930wmg.0 for ; Thu, 06 Oct 2016 11:18:53 -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=kLh9j2MEVi8iX3RjyzT7ZshAwl0l2/uQimILnTPS6UE=; b=jJr1eOe/XqV9Jfnq2cOrUOiO7UjyK+lb4+4gQ3YxRSga3ur1CwiOCfEATdPOw/X9Tg JIt0o0Wm3Kv3Qx9eOc/0wlVbR+hWRrIjbi/HFZqC0pqZ+RhCY50CYfdv/dJIlqw7TkAh u8uf0NuV7ERE2lbPs9ZFWnJprvHzzlJfZN6dtgJo8JW3aUlmmQXqOphhQvrUMavi6L16 iO3iy8Jo5xVUnBFhqgnKla55wdYP/1GZvXEDA6pyzzHBgXB2K5JXPaXsUXuixMSqAU4/ QcIU0G1oUkvPF/CQB5W2bmBeQSMkHTTChiAZYfkxA9rrLYotzOIm8KE261+Xk2sCTppt P1cg== 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=kLh9j2MEVi8iX3RjyzT7ZshAwl0l2/uQimILnTPS6UE=; b=G4b9Op6yutQxbHKCqlC+rkjoW+ZjjstKtmlHMsEEUM9eNS0OSem+v5T0Ww5Oi7m4OP lHmpyidAw1OAOEgHKbXRP6nZ23L7rfE9Db0YNMjwiM84DarhMx7RthBdCanCeXKJces2 g8OR3YXY8G/dBLAT9HZeHrNsDkuc0QUr6hVnhkT7KL0afkj//Yt1cWI4jzSSQHX483IV rnT4h8GCfHBzO8mEmNpjrk46TqOBUUIgr7clC976Z9I7dmosGFqPx7n3vB1rXQLImXIX 31Oo0SxM/nvR+MryNZJhpacylRnXst5wDo1QbF6mLmGDMT8nyQoPQsrXu5tgQU8dEMv3 dfpg== X-Gm-Message-State: AA6/9Rkld+VFAz1jtxwH7OuBBgjhAggGXC00Tk+FOsY/UHvqcyOR3/aq5cKZXazalNUGxBcIMMrzSn0iUbK16Q== X-Received: by 10.194.95.69 with SMTP id di5mr16851691wjb.54.1475777931818; Thu, 06 Oct 2016 11:18:51 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.194.167.69 with HTTP; Thu, 6 Oct 2016 11:18:51 -0700 (PDT) From: Phillip Hallam-Baker Date: Thu, 6 Oct 2016 14:18:51 -0400 X-Google-Sender-Auth: Mj2TBtunl-xdnIm0adVqv1bEgg8 Message-ID: To: IETF OpenPGP Content-Type: multipart/alternative; boundary=047d7bdc8f6e64bf64053e36537e Archived-At: Subject: [openpgp] Fingerprint Workfactor Hardening. 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, 06 Oct 2016 18:18:55 -0000 --047d7bdc8f6e64bf64053e36537e Content-Type: text/plain; charset=UTF-8 I had been somewhat concerned that this might be affected by https://www.google.com/patents/US7929689 However looking through the patent, it appears that the inventive step Microsoft is claiming is the use of a salt to make this process more efficient rather than the process itself. This does not put the mechanism in the clear, we still need to go through the Microsoft lawyers to be safe. But it is a lot easier to get a company to agree that a scheme doesn't infringe than permit open use of a valid claim. I am working on the doc right now. Note this is an update of the UDF doc that has the purpose of pinging the MSFT lawyers. Compressed Presentation Fingerprint compression permits the use of shorter fingerprint presentation without a reduction in the attacker work factor by requiring the fingerprint value to match a particular pattern. UDF fingerprints MUST use compression if possible. A compressed fingerprint uses a version identifier that specifies the form of compression used as follows: 96 No compression 97 First 25 bits are zeros 98 First 40 bits are zeros 99 First 50 bits are zeros 100 First 55 bits are zeros Thus the fingerprint that would be represented in uncompressed form as MAAAA-AAWIY-LTMFTG-CZTRO is instead represented as MBWIY-LTMFTG-CZTRO. --047d7bdc8f6e64bf64053e36537e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I had been somewhat concerned= that this might be affected by

https://www.google.com/patents/US7929689

However looking thro= ugh the patent, it appears that the inventive step Microsoft is claiming is= the use of a salt to make this process more efficient rather than the proc= ess itself.=C2=A0

This does not put the mechanism in the clear, we still need= to go through the Microsoft lawyers to be safe. But it is a lot easier to = get a company to agree that a scheme doesn't infringe than permit open = use of a valid claim.


I am working on = the doc right now. Note this is an update of the UDF doc that has the purpo= se of pinging the MSFT lawyers.

Compressed Presentation

=

Fingerprint compr= ession permits the use of shorter fingerprint presentation without a reduction in the attacker work factor by requiring the fingerprint value to match a particular pattern.=


UDF fingerprints MUST use compression if possible. A compressed fingerprint uses a version identifier that specifies the form of compression used as follows:


96 No compression

97 First 25 bits are zeros

98 First 40 bits are zeros

99 First 50 bits are zeros

100 First 55 bits are zeros


Thus the fingerprint = that would be represented in uncompressed form as MAAAA-AAWIY-LTMFTG-CZTRO is instead represented as MBWIY-LTMFTG-CZT= RO.


--047d7bdc8f6e64bf64053e36537e-- From nobody Mon Oct 10 11:38: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 AB561129739 for ; Mon, 10 Oct 2016 11:38:58 -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 dHU_G3LbSzeX for ; Mon, 10 Oct 2016 11:38:43 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (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 5DAA7129750 for ; Mon, 10 Oct 2016 11:38:43 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id s49so62615561qta.0 for ; Mon, 10 Oct 2016 11:38:43 -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=ctJAEA+VJaPkATPJPGDq2LUk5OvubO2vzc9pJm5dJcA=; b=wHiar77Mn7p+ashP+MZTpWkX6hwjRdNuILirwJwSW8sbr7iRssWsqAg6ruiOLAfrX2 iko2XzZ3YnNR1Oc9K3cOEgO7kHjf9L1J9l302IRaK1WRzLjxcJT3JgUmQzIfW6pC3yuE 19ZZWBsNajA7bI29zOyHzVrSp5K0rdAJjMyxLDyKsXyAVPN/WVMu9ENvIrXqa8bXGQ0c eNX8Tqna9zULbf8S2JfAP7xvsqIak9mDu41kLg723bgK1HHs4YMJ9HA5mJT4bpzwYN7s uHEH9kzyi6oxrzVEdYzu4wHYYjHq5/e59UruCUqgZdN6AkD8yiRHkT5GW/sxswi/3E+o Xk9Q== 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=ctJAEA+VJaPkATPJPGDq2LUk5OvubO2vzc9pJm5dJcA=; b=HGEFa7Geq/EGUoX76XTvGQ2YuJs2w9JPO4FPGT8vBOrsU/8dkcDEP/C8Pv2q04iQkE KDbEc1/nsa03CtkcHruRo51YC8/NOBaXh3ilPt3sq/vnQFUeVkvRw4TMMmQylY9tBkkV aXdtyyGjhakPcZv6accrvitABVykCpW2AEEJ2CCweSfSZqyrEcmU3wSqNJM8WO8bVWsC jY+wTA4hZLFjLPqfLCjKKNNPeGSDV+PU69riWIHnlVZfHog7YDYcwHf6Sed1wzUG5cxM RYT4bgwuvUUdcqdPbnt5XIX3F+wTIjaLeekbHc6Ag8ecClgeqlUiFhfN5h2umWlKGAoJ hUqQ== X-Gm-Message-State: AA6/9RmrpTZ+CYUHcNIUxtOtSPuDj47DfPeShaTWjzb2+adhtquQu49zlhdgK1iBm7Uxj//LClIy75cnb/uAsA== X-Received: by 10.194.191.162 with SMTP id gz2mr31754323wjc.182.1476124722215; Mon, 10 Oct 2016 11:38:42 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.194.227.170 with HTTP; Mon, 10 Oct 2016 11:38:41 -0700 (PDT) From: Phillip Hallam-Baker Date: Mon, 10 Oct 2016 14:38:41 -0400 X-Google-Sender-Auth: WRmhrNWafKfX9IOaj0iFCLA7VIU Message-ID: To: IETF OpenPGP Content-Type: multipart/alternative; boundary=047d7bb70adcb642a3053e87119e Archived-At: Subject: [openpgp] Fingerprint length and application 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, 10 Oct 2016 18:38:59 -0000 --047d7bb70adcb642a3053e87119e Content-Type: text/plain; charset=UTF-8 At the last couple of WG F2F meetings DKG asserted that we should make sure that a given public key MUST have exactly one fingerprint representation. This troubled me because while I don't necessarily disagree with the statement, I can't come up for a justification for it. I now think I have a solid justification. The main use for fingerprints in OpenPGP is to establish direct trust. The shortest fingerprint that is safe to use has a work factor of 96 bits and has 20 characters: MB2GK-6DUF5-YGYYL-JNY5E With the compression scheme I have developed (and I am working on the IPR implications of) we can generate a 15 character fingerprint with the same 96 bit work factor: MIWIY-LTMFTG-CZTRO Which requires us to generate 2^25 keypairs Now that 96 bits gives us a work factor of 2^96 against a second pre-image attack but only 2^48 against a collision attack. So consider two common uses of fingerprints: Case 1: OpenPGP key Case 2: PKIX trust root These appear to be similar but they are totally different in the first case it is quite possible for Alice to generate two OpenPGP keys that both have the same fingerprint. And this does allow her to do some mischief. She can sign a document such that it will be accepted by some parties and rejected by others depending on which public key she presents to a party that trusts the fingerprint. This is a concern but it is not one that creates a large opportunity for malice. The second is a much bigger concern as PKIX certificates contain use constraints. And so the risk of collision is much greater. Let us say that example.com has a self signed private root that has a name constraint so that it is only trusted to sign certs for *.example.com. A malicious party might create a pair of root certs such that one has the constraint and the other does not. They then present the certificate with the constraint in and the user accepts it for the limited purpose of trusting certs for example.com. Then the attacker sends out trust paths with the second root for bank.com etc. So extraneous data does make a difference. It provides a salt that reduces the cost of performing any collision type attack. But that isn't actually an advantage for ECC keys as they are quite cheap to make and require only an addition operation to modify. If the key is e^p, it is easy to generate e^(p+1), e^(p+2)... till the desired criteria is met. This can be used for work factor hardening as well. But it makes a much bigger difference in applications like PKIX where the fingerprint is being taken not of just a public key but a public key and associated policy statement. In short, don't do that. Only use short fingerprints for actual public keys, not policy statements or data. --047d7bb70adcb642a3053e87119e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
At = the last couple of WG F2F meetings DKG asserted that we should make sure th= at a given public key MUST have exactly one fingerprint representation.=C2= =A0

<= div class=3D"gmail_default" style=3D"font-size:small">This troubled me beca= use while I don't necessarily disagree with the statement, I can't = come up for a justification for it. I now think I have a solid justificatio= n.

The main use for finge= rprints in OpenPGP is to establish direct trust. The shortest fingerprint t= hat is safe to use has a work factor of 96 bits and has 20 characters:

MB2GK-6DUF5-YGYYL-JNY5E
<= br>
= With the compression scheme I have developed (and I am working on the IPR i= mplications of) we can generate a 15 character fingerprint with the same 96= bit work factor:

MIWIY-LTMFTG-CZTRO

Which requires us = to generate 2^25 keypairs=C2=A0

Now that 96 bits gives us a work factor of 2^9= 6 against a second pre-image attack but only 2^48 against a collision attac= k.=C2=A0

So consider two common uses of fingerprints:

Case 1: OpenPGP key
Case 2: PKIX trust root
=

T= hese appear to be similar but they are totally different in the first case = it is quite possible for Alice to generate two OpenPGP keys that both have = the same fingerprint. And this does allow her to do some mischief. She can = sign a document such that it will be accepted by some parties and rejected = by others depending on which public key she presents to a party that trusts= the fingerprint. This is a concern but it is not one that creates a large = opportunity for malice.

The second is a much bigger conce= rn as PKIX certificates contain use constraints. And so the risk of collisi= on is much greater. Let us say that example.= com has a self signed private root that has a name constraint so that i= t is only trusted to sign certs for *.exampl= e.com. A malicious party might create a pair of root certs such that on= e has the constraint and the other does not. They then present the certific= ate with the constraint in and the user accepts it for the limited purpose = of trusting certs for example.com. Then = the attacker sends out trust paths with the second root for bank.com etc.
=

So extraneous data does make a difference. It prov= ides a salt that reduces the cost of performing any collision type attack. = But that isn't actually an advantage for ECC keys as they are quite che= ap to make and require only an addition operation to modify. If the key is = e^p, it is easy to generate e^(p+1), e^(p+2)... till the desired criteria i= s met. This can be used for work factor hardening as well.=C2=A0

But it makes a much bigger difference in applications like PKIX where the= fingerprint is being taken not of just a public key but a public key and a= ssociated policy statement.=C2=A0

In short, don't do that. Only use short= fingerprints for actual public keys, not policy statements or data.=C2=A0<= /div>
--047d7bb70adcb642a3053e87119e-- From nobody Mon Oct 24 10:03:37 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 083C4129444 for ; Mon, 24 Oct 2016 10:03:36 -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 DvuZn1diC7zF for ; Mon, 24 Oct 2016 10:03:31 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (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 32C1612986B for ; Mon, 24 Oct 2016 10:03:24 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.84_2 #1 (Debian)) id 1byieg-00065H-2l for ; Mon, 24 Oct 2016 19:03:22 +0200 Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1byiX0-0001eW-LV; Mon, 24 Oct 2016 18:55:26 +0200 From: Werner Koch To: openpgp@ietf.org References: <87mvmp5rmi.fsf@wheatstone.g10code.de> <87y46720pc.fsf@alice.fifthhorseman.net> <87r3bztzxi.fsf@wheatstone.g10code.de> Organisation: The GnuPG Project 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, Daniel Kahn Gillmor Date: Mon, 24 Oct 2016 18:55:21 +0200 In-Reply-To: <87r3bztzxi.fsf@wheatstone.g10code.de> (Werner Koch's message of "Tue, 14 Jun 2016 19:58:49 +0200") Message-ID: <87lgxdelfq.fsf_-_@wheatstone.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=Israel_tempest_radar_Firewalls_corporate_security_Abbas_Baranyi_pass"; micalg=pgp-sha1; protocol="application/pgp-signature" Archived-At: Cc: Daniel Kahn Gillmor Subject: Re: [openpgp] Issuer Fingerprint (issue#3) 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, 24 Oct 2016 17:03:36 -0000 --=Israel_tempest_radar_Firewalls_corporate_security_Abbas_Baranyi_pass Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi! I have seen no more comments on the second version of an Issuer Fingerprint signature sub packet. Thus unless I hear a strong opinion against it by Thursday, I will push that to the repo so that it gets included in the next draft version. For convenience I copy the diff below. Salam-Shalom, Werner [https://gitlab.com/openpgp-wg/rfc4880bis/issues/3] =2D-8<---------------cut here---------------start------------->8--- @@ -1055,6 +1055,7 @@ #### {5.2.3.1} Signature Subpacket Specification 30 Features 31 Signature Target 32 Embedded Signature + 33 Issuer Fingerprint 100 to 110 Private or experimental =20 An implementation SHOULD ignore any subpacket of a type that it does @@ -1155,7 +1156,9 @@ #### {5.2.3.5} Issuer =20 (8-octet Key ID) =20 =2DThe OpenPGP Key ID of the key issuing the signature. +The OpenPGP Key ID of the key issuing the signature. If the version +of that key is greater than 4, this subpacket MUST NOT be included in +the signature. =20 #### {5.2.3.6} Key Expiration Time =20 @@ -1615,6 +1618,19 @@ #### {5.2.3.26} Embedded Signature in Section 5.2 above. It is useful when one signature needs to refer to, or be incorporated in, another signature. =20 +#### Issuer Fingerprint + +(1 octet key version number, N octets of fingerprint) + +The OpenPGP Key fingerprint of the key issuing the signature. This +subpacket SHOULD be included in all signatures. If the version of the +issuing key is 4 and an Issuer subpacket is also included in the +signature, the key ID of the Issuer subpacket MUST match the low +64 bits of the fingerprint. + +Note that the length N of the fingerprint for a version 4 key is 20 +octets. + ### {5.2.4} Computing Signatures =20 All signatures are formed by producing a hash over the signature data, =2D-8<---------------cut here---------------end--------------->8--- =2D-=20 Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. --=Israel_tempest_radar_Firewalls_corporate_security_Abbas_Baranyi_pass Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAlgOPPkACgkQTwVA1Xf5X5VxmwCeK+d9y7e1WK7rgV3oeIBJM/ww wNEAn1BqbR3wYd5nEDJrESvhch/ktfZt =DeZR -----END PGP SIGNATURE----- --=Israel_tempest_radar_Firewalls_corporate_security_Abbas_Baranyi_pass-- From nobody Fri Oct 28 11:58: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 050B11294A1 for ; Fri, 28 Oct 2016 11:58:32 -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 dFpsLBsRTVSk for ; Fri, 28 Oct 2016 11:58:30 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (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 E9B0F1293FE for ; Fri, 28 Oct 2016 11:58:29 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.84_2 #1 (Debian)) id 1c0CMG-0001eq-0z for ; Fri, 28 Oct 2016 20:58:28 +0200 Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1c0CIH-00034w-9y; Fri, 28 Oct 2016 20:54:21 +0200 From: Werner Koch To: openpgp@ietf.org References: <87mvmp5rmi.fsf@wheatstone.g10code.de> <87y46720pc.fsf@alice.fifthhorseman.net> <87r3bztzxi.fsf@wheatstone.g10code.de> <87lgxdelfq.fsf_-_@wheatstone.g10code.de> Organisation: The GnuPG Project 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, Daniel Kahn Gillmor Date: Fri, 28 Oct 2016 20:54:21 +0200 In-Reply-To: <87lgxdelfq.fsf_-_@wheatstone.g10code.de> (Werner Koch's message of "Mon, 24 Oct 2016 18:55:21 +0200") Message-ID: <87twbw484i.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=Dateline_argus_Europol_Maple_Treasury_Steve_Case_blackjack_computer="; micalg=pgp-sha1; protocol="application/pgp-signature" Archived-At: Cc: Daniel Kahn Gillmor Subject: Re: [openpgp] Issuer Fingerprint (issue#3) 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, 28 Oct 2016 18:58:32 -0000 --=Dateline_argus_Europol_Maple_Treasury_Steve_Case_blackjack_computer= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 24 Oct 2016 18:55, wk@gnupg.org said: > I have seen no more comments on the second version of an Issuer > Fingerprint signature sub packet. Thus unless I hear a strong opinion > against it by Thursday, I will push that to the repo so that it gets I just pushed it to the repo and closed issue 3. Shalom-Salam, Werner [https://gitlab.com/openpgp-wg/rfc4880bis/issues/3] =2D-=20 Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. --=Dateline_argus_Europol_Maple_Treasury_Steve_Case_blackjack_computer= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAlgTnt0ACgkQTwVA1Xf5X5UKSQCfadKNd2HUVLp9m9c93JRrJrkf /CAAn2kuE7ouJue5aRaaCWBpQpMjNBqt =4Shx -----END PGP SIGNATURE----- --=Dateline_argus_Europol_Maple_Treasury_Steve_Case_blackjack_computer=--