Re: Certification revocation -- identifying the revoked certificate

["Michael Young" <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----

I came upon a simpler idea: include the original *hash* in a
subpacket.  After noting that neither PGP6.5 nor GnuPG puts the
original creation time in its revocation packets, I looked
for a way to achieve backward-compatibility.  Putting the
whole original packet in the new one would work, but it's
too large.  But the original hash should be sufficiently precise
(much better than just the original creation time).

Specifically, I suggest adding another signature subpacket:

    5.2.3.1. (add:)
       31 = revocation identification 

    5.2.3.25. Revocation identification

 (1 octet hash algorithm)
  (N octets hash)

 In revocation certificate, the hash value computed in the
 original certificate being revoked.  This SHOULD appear
 in the hashed portion of the revocation certificate.

This would appear to solve a variety of problems for v4 certificates.
Existing implementations, which won't have the logic to verify
them, should ignore it (unless a sender chooses to mark it critical,
which seems like a bad choice).  New implementations can identify
the original certificate precisely.  It's a little larger than
just the timestamp, but not that much.

There is no analog for v3 certificates, but then there's nothing
interesting that can be updated in a v3 certificate anyway
(just the certificate creation time).  If anyone *really* wants
to do that, I'm happy to require that they use a v4 revocation
or hope that the receiver applies a "most recent prevails" model.

-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.3

iQEVAwUBO41HHWNDnIII+QUHAQFh8gf8CAcE070mOyHQtqddn0qH68y193Yg/xNj
VZ4Zjxztk/IrXL5TRSrgAMDajHcG8fnctc/tWUDJKG/yXDjJQ6TVhzHfCUb7px8m
guexyYsylBhBRIySJr6x14OkHtK6CTjt9VSIXD33UzbNxDWHIBpVGG/E+BbM5GWp
Mz9kdZOYyIhZHTKqZublVg9zNsNQsKWeqr99iRm6gRWVsqn2kMS08Km81YQpPU5C
6aHJFtffJsfIgbNLAn9qhP2NH2UYSzJ0PXfVGapg9IC560xAjgzQX6I3h4yuD5N2
27CI47CT2VzkuCQbU3m2rDgm2s9t8dD98YdSvNH8Qv7mw2vmSQp2nA==
=SOHN
-----END PGP SIGNATURE-----





Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7TJq8u11738 for ietf-openpgp-bks; Wed, 29 Aug 2001 12:52:08 -0700 (PDT)
Received: from xfw.transarc.ibm.com (xfw.transarc.ibm.com [192.54.226.51]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7TJq6D11734 for <[e-mail]>; Wed, 29 Aug 2001 12:52:06 -0700 (PDT)
Received: from mailhost.transarc.ibm.com (mailhost.transarc.ibm.com [9.38.192.124]) by xfw.transarc.ibm.com (AIX4.3/UCB 8.7/8.7) with ESMTP id PAA23326 for <[e-mail]>; Wed, 29 Aug 2001 15:44:17 -0400 (EDT)
Received: from mwyoung (dhcp-197-83.transarc.ibm.com [9.38.197.83]) by mailhost.transarc.ibm.com (8.8.0/8.8.0) with SMTP id PAA23573 for <[e-mail]>; Wed, 29 Aug 2001 15:52:01 -0400 (EDT)
Message-ID: <024f01c130c3$ba4c40c0$[e-mail]>
From: "Michael Young" <[e-mail]>
To: <[e-mail]>
References: <[e-mail]>
Subject: Re: Certification revocation -- identifying the revoked certificate
Date: Wed, 29 Aug 2001 15:49:33 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

-----BEGIN PGP SIGNED MESSAGE-----

I came upon a simpler idea: include the original *hash* in a
subpacket.  After noting that neither PGP6.5 nor GnuPG puts the
original creation time in its revocation packets, I looked
for a way to achieve backward-compatibility.  Putting the
whole original packet in the new one would work, but it's
too large.  But the original hash should be sufficiently precise
(much better than just the original creation time).

Specifically, I suggest adding another signature subpacket:

    5.2.3.1. (add:)
       31 = revocation identification 

    5.2.3.25. Revocation identification

 (1 octet hash algorithm)
  (N octets hash)

 In revocation certificate, the hash value computed in the
 original certificate being revoked.  This SHOULD appear
 in the hashed portion of the revocation certificate.

This would appear to solve a variety of problems for v4 certificates.
Existing implementations, which won't have the logic to verify
them, should ignore it (unless a sender chooses to mark it critical,
which seems like a bad choice).  New implementations can identify
the original certificate precisely.  It's a little larger than
just the timestamp, but not that much.

There is no analog for v3 certificates, but then there's nothing
interesting that can be updated in a v3 certificate anyway
(just the certificate creation time).  If anyone *really* wants
to do that, I'm happy to require that they use a v4 revocation
or hope that the receiver applies a "most recent prevails" model.

-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.3

iQEVAwUBO41HHWNDnIII+QUHAQFh8gf8CAcE070mOyHQtqddn0qH68y193Yg/xNj
VZ4Zjxztk/IrXL5TRSrgAMDajHcG8fnctc/tWUDJKG/yXDjJQ6TVhzHfCUb7px8m
guexyYsylBhBRIySJr6x14OkHtK6CTjt9VSIXD33UzbNxDWHIBpVGG/E+BbM5GWp
Mz9kdZOYyIhZHTKqZublVg9zNsNQsKWeqr99iRm6gRWVsqn2kMS08Km81YQpPU5C
6aHJFtffJsfIgbNLAn9qhP2NH2UYSzJ0PXfVGapg9IC560xAjgzQX6I3h4yuD5N2
27CI47CT2VzkuCQbU3m2rDgm2s9t8dD98YdSvNH8Qv7mw2vmSQp2nA==
=SOHN
-----END PGP SIGNATURE-----




Received: by above.proper.com (8.11.6/8.11.3) id f7THHM407987 for ietf-openpgp-bks; Wed, 29 Aug 2001 10:17:22 -0700 (PDT)
Received: from mercury.rus.uni-stuttgart.de (mercury.rus.uni-stuttgart.de [129.69.1.226]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7THHKD07982 for <[e-mail]>; Wed, 29 Aug 2001 10:17:21 -0700 (PDT)
Received: from rusfw by mercury.rus.uni-stuttgart.de with local (Exim 3.22 #1) id 15c8xU-0002rK-00 for [e-mail]; Wed, 29 Aug 2001 19:16:56 +0200
To: [e-mail]
Subject: Re: Certification revocation -- identifying the revoked certificate
References: <[e-mail]>
From: Florian Weimer <[e-mail]>
Date: 29 Aug 2001 19:16:56 +0200
In-Reply-To: <[e-mail]> ([e-mail]'s message of "Wed, 29 Aug 2001 12:45:06 +0200")
Message-ID: <[e-mail]>
Lines: 10
User-Agent: Gnus/5.090001 (Oort Gnus v0.01) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

[e-mail] writes:

> I think it's enough to identify the sig by its creation time.

Yes, that seems to be the right thing to do.

-- 
Florian Weimer 	                  [e-mail]
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          [phone]/fax [phone]


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7TAoCD21312 for ietf-openpgp-bks; Wed, 29 Aug 2001 03:50:12 -0700 (PDT)
Received: from HACKSERV.saiknes.lv (hackserv.saiknes.lv [195.2.103.8]) by above.proper.com (8.11.6/8.11.3) with SMTP id f7TAoAD21307 for <[e-mail]>; Wed, 29 Aug 2001 03:50:11 -0700 (PDT)
Received: from saiknes.lv (unverified [127.0.0.1]) by 127.0.0.1 (EMWAC SMTPRS 0.83) with SMTP id <B0000080500@127.0.0.1>; Wed, 29 Aug 2001 11:45:06 +0200
Message-ID: <[e-mail]>
Date: Wed, 29 Aug 2001 12:45:06 +0200
From: [e-mail]
Organization: .NO.SPaM.NET
X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U)
X-Accept-Language: en,lv,ru
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Certification revocation -- identifying the revoked certificate
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thomas Roessler wrote:
> On 2001-08-28 17:54:05 -0400, Michael Young wrote:
> >I'm really not out to be pedantic here.  I think it really is 
> >important to have clear rules for revocation.  If multiple
> >certifications for a key or key/name are to be allowed, or are the 
> >*recommended* way to update preferences/qualities, then it is 
> >essential that a revocation be able to target the proper one.
> 
> Of course, the trivial solution would be to assign a unique serial 
> number to each certificate, and to include that serial number with 
> the revocation.
> -- 
> Thomas Roessler                        http://log.does-not-exist.org/

this will require to change sig format or at least make new subpacket for sernum.
besides it will not solve problem with revoking current sigs because they have
no such number.

I think it's enough to identify the sig by its creation time.
I don't think it's normal to have several sigs created at the same time,
and even if there is several sigs with the same creation time, well, they all
are revoked by single revocation sig that refers to this creation time.

JMHO

== <EOF> ==
Disastry  http://i.am/disastry/
http://disastry.dhs.org/pgp <----PGP plugins for Netscape and MDaemon
 ^--GPG for Win32 (supports loadable modules and IDEA)
 ^---PGP 2.6.3ia-multi04 (supports IDEA, CAST5, BLOWFISH, TWOFISH,
     AES, 3DES ciphers and MD5, SHA1, RIPEMD160 hashes)
-----BEGIN PGP SIGNATURE-----
Version: 553ckt

iQA/AwUBO4yrWDBaTVEuJQxkEQKF0QCgwSGE5TRM0Rkw8RhJaLnY8xYApcYAn1FK
h3zPb45E1OLr2j2RRB6eOvfb
=uhIP
-----END PGP SIGNATURE-----


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7T7aYc04281 for ietf-openpgp-bks; Wed, 29 Aug 2001 00:36:34 -0700 (PDT)
Received: from smtp1.nikoma.de (smtp1.nikoma.de [212.122.128.19]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7T7aWD04272 for <[e-mail]>; Wed, 29 Aug 2001 00:36:32 -0700 (PDT)
Received: from sobolev.does-not-exist.org (dialin160.pg3-nt.dusseldorf.nikoma.de [213.54.98.160]) by smtp1.nikoma.de (8.9.3/8.9.3) with ESMTP id JAA17563; Wed, 29 Aug 2001 09:36:13 +0200 (CEST) (envelope-from [e-mail])
Received: by sobolev.does-not-exist.org (Postfix, from userid 1000) id 335112ED15; Wed, 29 Aug 2001 09:06:33 +0200 (CEST)
Date: Wed, 29 Aug 2001 09:06:33 +0200
From: Thomas Roessler <[e-mail]>
To: Michael Young <[e-mail]>
Cc: [e-mail]
Subject: Re: Certification revocation -- identifying the revoked certificate
Message-ID: <[e-mail]>
Mail-Followup-To: Michael Young <[e-mail]>, [e-mail]
References: <p05100303b7aaf65aff68@[192.168.1.180]> <008601c12c52$1b6181c0$[e-mail]> <p0510031fb7ab945664e5@[192.168.1.180]> <002b01c12d74$b105fb20$[e-mail]> <01c601c1300b$f59d8840$[e-mail]>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="W/nzBZO5zC0uMSeA"
Content-Disposition: inline
In-Reply-To: <01c601c1300b$f59d8840$[e-mail]>
User-Agent: Mutt/1.3.21i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

--W/nzBZO5zC0uMSeA
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2001-08-28 17:54:05 -0400, Michael Young wrote:

>I'm really not out to be pedantic here.  I think it really is=20
>important to have clear rules for revocation.  If multiple
>certifications for a key or key/name are to be allowed, or are the=20
>*recommended* way to update preferences/qualities, then it is=20
>essential that a revocation be able to target the proper one.

Of course, the trivial solution would be to assign a unique serial=20
number to each certificate, and to include that serial number with=20
the revocation.

--=20
Thomas Roessler                        http://log.does-not-exist.org/

--W/nzBZO5zC0uMSeA
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)

iQEVAwUBO4yUedImKUTOasbBAQKiUwgAj/Kuz3DKMG1s1KW9kfPfRqS+2pfckIJb
uSDWVEX6T6Ec7cx/dzr8CBdQBHvj1xHOpeq6zrEU0nyfagLZ2aKy4ZK04b1iKs5S
t74euyu0sVM2CU8sbSodOk1iUDcObWEZZz31CGLsu6hvXVvNITCvKsLW3jwEY28c
lwmIPIL4UDDfDwTBC17o4D0S1kuSTTUyB6c4nhHN6vWZ5TfwZvpiZGR0P9szdKuO
O7EYbHj14MrbVw1ZgW8WPjBavc0LMjbqUlllviukTPRkNpukfd1R8l7/tLFsZ/K0
ZL4dpVOrmTjtnT3aM1aCRRgLfNuGbo/gGHcfWK7Sl7q8Gq7It9O2iQ==
=5MmN
-----END PGP SIGNATURE-----

--W/nzBZO5zC0uMSeA--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7SLvVd08853 for ietf-openpgp-bks; Tue, 28 Aug 2001 14:57:31 -0700 (PDT)
Received: from xfw.transarc.ibm.com (xfw.transarc.ibm.com [192.54.226.51]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7SLvPD08849 for <[e-mail]>; Tue, 28 Aug 2001 14:57:29 -0700 (PDT)
Received: from mailhost.transarc.ibm.com (mailhost.transarc.ibm.com [9.38.192.124]) by xfw.transarc.ibm.com (AIX4.3/UCB 8.7/8.7) with ESMTP id RAA78154 for <[e-mail]>; Tue, 28 Aug 2001 17:49:35 -0400 (EDT)
Received: from mwyoung (dhcp-197-83.transarc.ibm.com [9.38.197.83]) by mailhost.transarc.ibm.com (8.8.0/8.8.0) with SMTP id RAA18468 for <[e-mail]>; Tue, 28 Aug 2001 17:57:19 -0400 (EDT)
Message-ID: <01c601c1300b$f59d8840$[e-mail]>
From: "Michael Young" <[e-mail]>
To: <[e-mail]>
References: <p05100303b7aaf65aff68@[192.168.1.180]> <008601c12c52$1b6181c0$[e-mail]> <p0510031fb7ab945664e5@[192.168.1.180]> <002b01c12d74$b105fb20$[e-mail]>
Subject: Certification revocation -- identifying the revoked certificate
Date: Tue, 28 Aug 2001 17:54:05 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

-----BEGIN PGP SIGNED MESSAGE-----

In the ensuing discussion of self-signature revocations, I didn't see an
answer to a fundamental question: what does one hash in a certification
revocation (type 0x30)?  The specification is explicit for all of the
other types, but not this one.

I skimmed the GnuPG source, and it would appear to hash the target key
and userID, and the usual trailing matter (including the hashed
subpackets from the revocation certificate, (*not* the original).
Is my reading correct, and is that what the specification intends?

I note that this does not identify *which* certification is being revoked,
if there is more than one.  If I created multiple signatures (with
different signature type, timestamp, or subpackets) for the same
key/name pair, I see no way to revoke just one of them.  Are multiple
signatures illegal?  (Clearly, multiple self-signatures are legal,
and the same problem comes up there, as per the recent discussion.)

This seems broken.  A certification revocation should identify the
original certification, and hash the same material as the original
(followed by the revocation certificate material).  The identification
is desirable, but not strictly required -- a receiver could test all
possible certifications.  It would seem that a new subpacket would be
in order.  The original contents are absolutely essential, though.

I suppose one interpretation might be that a revocation should match
an original that has *exactly* the same subpackets (except for the
"revocation reason").  How does this work for these things
[with my guess as to an answer in brackets for each one]?
    v3 signatures, which use an explicit creation time instead of
     subpackets [use v3 revocation with same creation time];
    different signature types (e.g., "persona" vs. "casual")
     [do not permit distinction on this];
    other subpackets that might apply to both the original and the
     revocation (e.g., notation data) [there may not be any]; or,
    revocation of an earlier revocation (as Florian Weimer suggested
     might be valid for "no longer in use" reasons) [disallow this].
In any case, if this was the intention, the specification should say
so (and GnuPG should make it easier to generate an exact match :-).

I'm really not out to be pedantic here.  I think it really is important
to have clear rules for revocation.  If multiple certifications for a
key or key/name are to be allowed, or are the *recommended* way to
update preferences/qualities, then it is essential that a revocation
be able to target the proper one.

-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.3

iQEVAwUBO4wS9WNDnIII+QUHAQEUeQf+KTrpPoU8lviz/C+mn7wN34MGOG3WUqsO
MCfaVlpYAe+8Ga2nEzcOWoOak8hs13clc4dpHHRstdvFBpolYGd1M3z2HD+pjMG5
sVWMRUuJVc9uicjTqjWqzLSqTUVZ0LFP845gj56VVRYosg1iS1XT1APvdJMolTl6
umQqzRoHpVv+hwRhiJeclYBknSShBf05hHmGVBWlyOnRsPa/YjMyeLutqVVAAqT/
QvxWQs1zhE2cvRxrqNbwfXjcEmWY26CUM69XpZJGuemaCGDutmtxRMPgMpyaeLA/
odpwmJ8UG2MyyNWuRbQ62KrqtS2bXGCZPV3L8R6ipwhgs09R2IYCKw==
=hjzN
-----END PGP SIGNATURE-----




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7SFRTv26800 for ietf-openpgp-bks; Tue, 28 Aug 2001 08:27:29 -0700 (PDT)
Received: from claude.kendall.akamai.com (walrus.ne.mediaone.net [65.96.217.45]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7SFRSD26796 for <[e-mail]>; Tue, 28 Aug 2001 08:27:28 -0700 (PDT)
Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.9.3/8.9.3) id LAA11165 for [e-mail]; Tue, 28 Aug 2001 11:27:18 -0400
Date: Tue, 28 Aug 2001 11:27:18 -0400
From: David Shaw <[e-mail]>
To: [e-mail]
Subject: Replacement Key
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
X-PGP-Key: 2048R/3CB3B415/4D 96 83 18 2B AF BE 45 D0 07 C4 07 51 37 B3 18
X-URL: http://www.jabberwocky.com/
X-Phase-Of-Moon: The Moon is Waxing Gibbous (77% of Full)
X-Pointless-Random-Number: 123
X-Silly-Header: It sure is.
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

I welcome any comment on the replacement key draft that just got
posted.  

The point, in case you haven't seen the draft yet, is a way for a user
to specify the key that replaces a revoked or expired key.  General
purpose implementations can use this information to use the new key
(presumably with a warning) if a user requests the old one.  It would
also be useful to automatically fetch the new key from keyservers.

Keyservers could use this to present the proper key (again, with a
warning) if an expired/revoked key is requested.

In particular I'd like to hear opinions on the variable sized
subpacket.  There are other variable sized subpackets in OpenPGP, but
I wonder if this one might not save us much.

David

-- 
David Shaw          |  Technical Lead
<[e-mail]>  |  Enterprise Content Delivery
617-250-3028        |  Akamai Technologies


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7SE7u722963 for ietf-openpgp-bks; Tue, 28 Aug 2001 07:07:56 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7SE7tD22959 for <[e-mail]>; Tue, 28 Aug 2001 07:07:55 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10792; Tue, 28 Aug 2001 10:06:35 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-shaw-openpgp-replacementkey-00.txt
Date: Tue, 28 Aug 2001 10:06:34 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Key Replacement for Revoked Keys in OpenPGP
	Author(s)	: D. Shaw
	Filename	: draft-shaw-openpgp-replacementkey-00.txt
	Pages		: 3
	Date		: 22-Aug-01
	
This document specifies a method in OpenPGP to specify a replacement
for an expired or revoked key.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-shaw-openpgp-replacementkey-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-shaw-openpgp-replacementkey-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-shaw-openpgp-replacementkey-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-shaw-openpgp-replacementkey-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-shaw-openpgp-replacementkey-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: by above.proper.com (8.11.6/8.11.3) id f7SDdHP22031 for ietf-openpgp-bks; Tue, 28 Aug 2001 06:39:17 -0700 (PDT)
Received: from claude.kendall.akamai.com (walrus.ne.mediaone.net [65.96.217.45]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7SDdFD22027 for <[e-mail]>; Tue, 28 Aug 2001 06:39:16 -0700 (PDT)
Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.9.3/8.9.3) id JAA09723 for [e-mail]; Tue, 28 Aug 2001 09:38:49 -0400
Date: Tue, 28 Aug 2001 09:38:49 -0400
From: David Shaw <[e-mail]>
To: [e-mail]
Subject: Keyserver thoughts (was Re: How to update a self-signature?)
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail]
References: <p05100303b7aaf65aff68@[192.168.1.180]> <008601c12c52$1b6181c0$[e-mail]> <p0510031fb7ab945664e5@[192.168.1.180]> <002b01c12d74$b105fb20$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Tue, Aug 28, 2001 at 09:47:24AM +0200
X-PGP-Key: 2048R/3CB3B415/4D 96 83 18 2B AF BE 45 D0 07 C4 07 51 37 B3 18
X-URL: http://www.jabberwocky.com/
X-Phase-Of-Moon: The Moon is Waxing Gibbous (76% of Full)
X-Pointless-Random-Number: 198
X-Silly-Header: It sure is.
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Tue, Aug 28, 2001 at 09:47:24AM +0200, Werner Koch wrote:
> 
> On Mon, 27 Aug 2001 16:59:00 -0400, David Shaw said:
> 
> > sort of sanity checking there.  Either way, I think it's safe to say
> > that incorrect clocks are out of the scope of 2440!
> 
> Keyserver may want to discard signature which are timestamped more
> than a few days in the future.  This should greatly help not to spread
> erroneous signatures.

Yes, indeed.

I've often thought it would be good if keyservers could trim keys on
the way out - leaving off invalid signatures, expired subkeys, expired
signatures, etc.

It would be optional and allow someone to request the complete key if
they want it.  Computer programs that try to be "smart" often raise
unforseen problems.

David

-- 
David Shaw          |  Technical Lead
<[e-mail]>  |  Enterprise Content Delivery
617-250-3028        |  Akamai Technologies


Received: by above.proper.com (8.11.6/8.11.3) id f7S7hAJ19727 for ietf-openpgp-bks; Tue, 28 Aug 2001 00:43:10 -0700 (PDT)
Received: from kasiski.gnupg.de (porta.u64.de [194.77.88.106]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7S7h8D19717 for <[e-mail]>; Tue, 28 Aug 2001 00:43:08 -0700 (PDT)
Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.22 #1 (Debian)) id 15bePa-0001Ob-00; Tue, 28 Aug 2001 10:39:54 +0200
Received: from wk by alberti.gnupg.de with local (Exim 3.22 #1 (Debian)) id 15bdam-0000qN-00; Tue, 28 Aug 2001 09:47:24 +0200
To: [e-mail]
Subject: Re: How to update a self-signature?
References: <p05100303b7aaf65aff68@[192.168.1.180]> <008601c12c52$1b6181c0$[e-mail]> <p0510031fb7ab945664e5@[192.168.1.180]> <002b01c12d74$b105fb20$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: Werner Koch <[e-mail]>
Organisation: g10 Code GmbH
X-PGP-KeyID: 621CC013
X-Request-PGP: finger://[e-mail]
Date: 28 Aug 2001 09:47:24 +0200
In-Reply-To: <[e-mail]> (David Shaw's message of "Mon, 27 Aug 2001 16:59:00 -0400")
Message-ID: <[e-mail]>
Lines: 15
User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Mon, 27 Aug 2001 16:59:00 -0400, David Shaw said:

> sort of sanity checking there.  Either way, I think it's safe to say
> that incorrect clocks are out of the scope of 2440!

Keyserver may want to discard signature which are timestamped more
than a few days in the future.  This should greatly help not to spread
erroneous signatures.

  Werner

-- 
Werner Koch        Omnis enim res, quae dando non deficit, dum habetur
g10 Code GmbH      et non datur, nondum habetur, quomodo habenda est.
Privacy Solutions                                        -- Augustinus



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7RKxAG26618 for ietf-openpgp-bks; Mon, 27 Aug 2001 13:59:10 -0700 (PDT)
Received: from claude.kendall.akamai.com (akafire.akamai.com [65.202.32.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7RKx9D26613 for <[e-mail]>; Mon, 27 Aug 2001 13:59:09 -0700 (PDT)
Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.9.3/8.9.3) id QAA05348 for [e-mail]; Mon, 27 Aug 2001 16:59:00 -0400
Date: Mon, 27 Aug 2001 16:59:00 -0400
From: David Shaw <[e-mail]>
To: [e-mail]
Subject: Re: How to update a self-signature?
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail]
References: <p05100303b7aaf65aff68@[192.168.1.180]> <008601c12c52$1b6181c0$[e-mail]> <p0510031fb7ab945664e5@[192.168.1.180]> <002b01c12d74$b105fb20$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Mon, Aug 27, 2001 at 08:48:32PM +0200
X-PGP-Key: 2048R/3CB3B415/4D 96 83 18 2B AF BE 45 D0 07 C4 07 51 37 B3 18
X-URL: http://www.jabberwocky.com/
X-Phase-Of-Moon: The Moon is Waxing Gibbous (68% of Full)
X-Pointless-Random-Number: 112
X-Silly-Header: It sure is.
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Mon, Aug 27, 2001 at 08:48:32PM +0200, Werner Koch wrote:
> 
> On Mon, 27 Aug 2001 12:35:40 -0400, David Shaw said:
> 
> > to really revoke a revocation.  I assume you mean revoking a user ID
> > revocation by re-signing the user ID?
> 
> Yes. I talked with Florian about this recently.
> 
> > I'm only trying to make a case for what happens if after everything is
> > worked out and the implementation ends up with more than one valid
> 
> There shouldn't be any date conflicts with self-signatures - but it
> may happen.  The way to handle it for a general purpose implemention is
> to ignore all signatures during key import which are older than
> existing one. That you ignore all self-signatures which are invalid
> should be clear.

This is effectively the same thing as the "use the latest" suggestion.
Either way, you are picking the most recent signature.  I like your
idea a bit more as it seems more elegant - resolving the problem once
at key import time rather than each time the key is used.  It also
keeps the key small - no long trail of signatures from each preference
change.

It does share a gotcha with the "use the latest" suggestion - if the
user who makes one of those signatures has a wonky clock that thinks
it is 2010, then they could find themselves with a self-signature that
can't be replaced because the implementations will always favor the
signature from the future.  The implementation will need to do some
sort of sanity checking there.  Either way, I think it's safe to say
that incorrect clocks are out of the scope of 2440!

> So I do not see a problem before the year 2106 and most of us won't see
> it ever.

Around 2090, the OpenPGP WG of the future will have to make a key
packet version 58 or so that has an 8 byte time. :)

David

-- 
David Shaw          |  Technical Lead
<[e-mail]>  |  Enterprise Content Delivery
617-250-3028        |  Akamai Technologies


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7RIjF524155 for ietf-openpgp-bks; Mon, 27 Aug 2001 11:45:15 -0700 (PDT)
Received: from kasiski.gnupg.de (porta.u64.de [194.77.88.106]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7RIjCD24151 for <[e-mail]>; Mon, 27 Aug 2001 11:45:12 -0700 (PDT)
Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.22 #1 (Debian)) id 15bSGg-0000Tn-00; Mon, 27 Aug 2001 21:41:54 +0200
Received: from wk by alberti.gnupg.de with local (Exim 3.22 #1 (Debian)) id 15bRR3-0000ad-00; Mon, 27 Aug 2001 20:48:33 +0200
To: [e-mail]
Subject: Re: How to update a self-signature?
References: <p05100303b7aaf65aff68@[192.168.1.180]> <008601c12c52$1b6181c0$[e-mail]> <p0510031fb7ab945664e5@[192.168.1.180]> <002b01c12d74$b105fb20$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: Werner Koch <[e-mail]>
Organisation: g10 Code GmbH
X-PGP-KeyID: 621CC013
X-Request-PGP: finger://[e-mail]
Date: 27 Aug 2001 20:48:32 +0200
In-Reply-To: <[e-mail]> (David Shaw's message of "Mon, 27 Aug 2001 12:35:40 -0400")
Message-ID: <[e-mail]>
Lines: 27
User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Mon, 27 Aug 2001 12:35:40 -0400, David Shaw said:

> to really revoke a revocation.  I assume you mean revoking a user ID
> revocation by re-signing the user ID?

Yes. I talked with Florian about this recently.

> I'm only trying to make a case for what happens if after everything is
> worked out and the implementation ends up with more than one valid

There shouldn't be any date conflicts with self-signatures - but it
may happen.  The way to handle it for a general purpose implemention is
to ignore all signatures during key import which are older than
existing one. That you ignore all self-signatures which are invalid
should be clear.

So I do not see a problem before the year 2106 and most of us won't see
it ever.

Ciao,

   Werner

-- 
Werner Koch        Omnis enim res, quae dando non deficit, dum habetur
g10 Code GmbH      et non datur, nondum habetur, quomodo habenda est.
Privacy Solutions                                        -- Augustinus



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7RGx5b21880 for ietf-openpgp-bks; Mon, 27 Aug 2001 09:59:05 -0700 (PDT)
Received: from rcn.ihtfp.org ([e-mail] [204.107.200.33]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7RGwwD21873 for <[e-mail]>; Mon, 27 Aug 2001 09:58:59 -0700 (PDT)
Received: (from warlord@localhost) by rcn.ihtfp.org (8.9.3) id MAA11263; Mon, 27 Aug 2001 12:58:54 -0400
To: Florian Weimer <[e-mail]>
Cc: [e-mail]
Subject: Re: How to update a self-signature?
References: <p05100303b7aaf65aff68@[192.168.1.180]> 	<008601c12c52$1b6181c0$[e-mail]> 	<p0510031fb7ab945664e5@[192.168.1.180]> 	<002b01c12d74$b105fb20$[e-mail]> 	<[e-mail]> <[e-mail]> <[e-mail]>
From: Derek Atkins <[e-mail]>
Date: 27 Aug 2001 12:58:54 -0400
In-Reply-To: Florian Weimer's message of "27 Aug 2001 17:45:44 +0200"
Message-ID: <[e-mail]>
Lines: 25
X-Mailer: Gnus v5.5/Emacs 20.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

True.  I was implying a Key Revocation, not a UserID revocation.
My appologies for being ambiguous.

-derek

Florian Weimer <[e-mail]> writes:

> Derek Atkins <[e-mail]> writes:
> 
> > Keep in mind that you DON'T want to over-ride a revocation
> > self-signature.  That would be bad.
> 
> It depends on the revocation reason.  If the revocation says 'user ID
> no longer in use', it makes perfect sense to override it.
> 
> -- 
> Florian Weimer 	                  [e-mail]
> University of Stuttgart           http://cert.uni-stuttgart.de/
> RUS-CERT                          [phone]/fax [phone]

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [e-mail]                        PGP key available


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7RGZpe21534 for ietf-openpgp-bks; Mon, 27 Aug 2001 09:35:51 -0700 (PDT)
Received: from claude.kendall.akamai.com (akafire.akamai.com [65.202.32.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7RGZoD21530 for <[e-mail]>; Mon, 27 Aug 2001 09:35:50 -0700 (PDT)
Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.9.3/8.9.3) id MAA01548 for [e-mail]; Mon, 27 Aug 2001 12:35:40 -0400
Date: Mon, 27 Aug 2001 12:35:40 -0400
From: David Shaw <[e-mail]>
To: [e-mail]
Subject: Re: How to update a self-signature?
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail]
References: <p05100303b7aaf65aff68@[192.168.1.180]> <008601c12c52$1b6181c0$[e-mail]> <p0510031fb7ab945664e5@[192.168.1.180]> <002b01c12d74$b105fb20$[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Mon, Aug 27, 2001 at 04:55:20PM +0200
X-PGP-Key: 2048R/3CB3B415/4D 96 83 18 2B AF BE 45 D0 07 C4 07 51 37 B3 18
X-URL: http://www.jabberwocky.com/
X-Phase-Of-Moon: The Moon is Waxing Gibbous (68% of Full)
X-Pointless-Random-Number: 56
X-Silly-Header: It sure is.
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Mon, Aug 27, 2001 at 04:55:20PM +0200, Werner Koch wrote:
> 
> On Mon, 27 Aug 2001 09:48:50 -0400, David Shaw said:
> 
> > "Most recent prevails" makes a lot of sense.  It can even be a SHOULD,
> 
> Except for key revocation - any valid revocation (which is a
> self-signature) counts.  For subkeys it should be okay to allow
> overriding of subkey revocations but it is practically worthless.
> Revoking user ID revocations should definitely be possible.

The certification revocation signature is applied to the user id,
rather than to the signature that is being revoked, so there is no way
to really revoke a revocation.  I assume you mean revoking a user ID
revocation by re-signing the user ID?

It is an interesting problem how to work out the results when given a
list of certifications and revocations which may have oddball dates.
I'm only trying to make a case for what happens if after everything is
worked out and the implementation ends up with more than one valid
self-signature.

David

-- 
David Shaw          |  Technical Lead
<[e-mail]>  |  Enterprise Content Delivery
617-250-3028        |  Akamai Technologies


Received: by above.proper.com (8.11.6/8.11.3) id f7RFoNR19279 for ietf-openpgp-bks; Mon, 27 Aug 2001 08:50:23 -0700 (PDT)
Received: from claude.kendall.akamai.com (akafire.akamai.com [65.202.32.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7RFoMD19273 for <[e-mail]>; Mon, 27 Aug 2001 08:50:22 -0700 (PDT)
Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.9.3/8.9.3) id LAA00830; Mon, 27 Aug 2001 11:50:17 -0400
Date: Mon, 27 Aug 2001 11:50:17 -0400
From: David Shaw <[e-mail]>
To: Derek Atkins <[e-mail]>
Cc: [e-mail]
Subject: Re: How to update a self-signature?
Message-ID: <[e-mail]>
Mail-Followup-To: Derek Atkins <[e-mail]>, [e-mail]
References: <p05100303b7aaf65aff68@[192.168.1.180]> <008601c12c52$1b6181c0$[e-mail]> <p0510031fb7ab945664e5@[192.168.1.180]> <002b01c12d74$b105fb20$[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Mon, Aug 27, 2001 at 11:01:10AM -0400
X-PGP-Key: 2048R/3CB3B415/4D 96 83 18 2B AF BE 45 D0 07 C4 07 51 37 B3 18
X-URL: http://www.jabberwocky.com/
X-Phase-Of-Moon: The Moon is Waxing Gibbous (68% of Full)
X-Pointless-Random-Number: 183
X-Silly-Header: It sure is.
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Mon, Aug 27, 2001 at 11:01:10AM -0400, Derek Atkins wrote:
> 
> Keep in mind that you DON'T want to over-ride a revocation
> self-signature.  That would be bad.

Absolutely.  I am referring only to self certification signatures.
Revocation signatures should not be overridden.  "Bad", indeed.

David

-- 
   David Shaw  |  [e-mail]  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


Received: by above.proper.com (8.11.6/8.11.3) id f7RFk4j18715 for ietf-openpgp-bks; Mon, 27 Aug 2001 08:46:04 -0700 (PDT)
Received: from mercury.rus.uni-stuttgart.de (mercury.rus.uni-stuttgart.de [129.69.1.226]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7RFk3D18708 for <[e-mail]>; Mon, 27 Aug 2001 08:46:04 -0700 (PDT)
Received: from rusfw by mercury.rus.uni-stuttgart.de with local (Exim 3.22 #1) id 15bOa8-0007F1-00 for [e-mail]; Mon, 27 Aug 2001 17:45:44 +0200
To: [e-mail]
Subject: Re: How to update a self-signature?
References: <p05100303b7aaf65aff68@[192.168.1.180]> <008601c12c52$1b6181c0$[e-mail]> <p0510031fb7ab945664e5@[192.168.1.180]> <002b01c12d74$b105fb20$[e-mail]> <[e-mail]> <[e-mail]>
From: Florian Weimer <[e-mail]>
Date: 27 Aug 2001 17:45:44 +0200
In-Reply-To: <[e-mail]> (Derek Atkins's message of "27 Aug 2001 11:01:10 -0400")
Message-ID: <[e-mail]>
Lines: 12
User-Agent: Gnus/5.090001 (Oort Gnus v0.01) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Derek Atkins <[e-mail]> writes:

> Keep in mind that you DON'T want to over-ride a revocation
> self-signature.  That would be bad.

It depends on the revocation reason.  If the revocation says 'user ID
no longer in use', it makes perfect sense to override it.

-- 
Florian Weimer 	                  [e-mail]
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          [phone]/fax [phone]


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7RF1Uw15478 for ietf-openpgp-bks; Mon, 27 Aug 2001 08:01:30 -0700 (PDT)
Received: from rcn.ihtfp.org ([e-mail] [204.107.200.33]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7RF1RD15474 for <[e-mail]>; Mon, 27 Aug 2001 08:01:27 -0700 (PDT)
Received: (from warlord@localhost) by rcn.ihtfp.org (8.9.3) id LAA11148; Mon, 27 Aug 2001 11:01:10 -0400
To: David Shaw <[e-mail]>
Cc: [e-mail]
Subject: Re: How to update a self-signature?
References: <p05100303b7aaf65aff68@[192.168.1.180]> <008601c12c52$1b6181c0$[e-mail]> <p0510031fb7ab945664e5@[192.168.1.180]> <002b01c12d74$b105fb20$[e-mail]> <[e-mail]>
From: Derek Atkins <[e-mail]>
Date: 27 Aug 2001 11:01:10 -0400
In-Reply-To: David Shaw's message of "Mon, 27 Aug 2001 09:48:50 -0400"
Message-ID: <[e-mail]>
Lines: 82
X-Mailer: Gnus v5.5/Emacs 20.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Keep in mind that you DON'T want to over-ride a revocation
self-signature.  That would be bad.

-derek

David Shaw <[e-mail]> writes:

> On Sat, Aug 25, 2001 at 10:46:14AM -0400, Michael Young wrote:
> 
> > Florian Weimer wrote:
> > > This should probably go into a separate RFC.  Currently, RFC 2440 and
> > > RFC 2440bis deal only with syntactic issues 
> > 
> > and Jon Callas wrote (this and subsequent quotes):
> > > This is my point: I don't see an obvious best answer. Furthermore, 2440 is
> > > a data specification standard, not a user interface guide or software
> > 
> > I understand that the specification primarily covers syntax, but
> > if it doesn't cover at least some interpretation issues, then
> > interoperation is seriously hampered.  Who cares how the bits
> > are ordered if a sender and receiver interpret wildly different things?
> > We need to have a meeting of the minds on more than just formatting.
> > 
> > > Secondarily, one way I look at it is as a receiver. I fetch a key from a
> > > server and it has multiple primaries. How do I resolve this? Yeah, there's
> > 
> > On this specific issue, I want to know what a *sender* must do
> > to change its "primary" marking such that a receiver will
> > understand.  The same applies to any material in the self-signature,
> > and this need may arise several times over a key/userId lifetime.
> 
> The draft does specify have a way to do this - rewriting the
> signature(s) in place ("Since a self-signatures contain important
> information about the key's use, an implementation SHOULD allow the
> user to rewrite the self-signature...").  Both PGP and GnuPG do this.
> 
> The problem arises later, when the key with the new self-signatures is
> added to a keyserver or sent to someone else who already has the key.
> Most current implementations in the field will merge their existing
> copy with the new one, resulting in two self-signatures.  It could be
> argued that they should not do this, but since it's going to happen,
> we should at least make a provision for it.
> 
> Like you, I favor a "most recent prevails" recommendation.  I think
> that revoking and re-making self-signatures is going to result in some
> massive keys if every time someone changes their preferences it means
> a new revocation packet and self-signature.
> 
> I don't think that this is just a syntax issue, and therefore
> inappropriate for 2440bis.  2440bis makes a point of covering syntax
> issues that relate to security.  Since the information in a
> self-signature can affect the security of messages sent to the key,
> I'd say this is an appropriate issue to address in 2440bis.
> 
> "Most recent prevails" makes a lot of sense.  It can even be a SHOULD,
> like the sample wording I sent out a couple of days ago, rather than a
> MUST.  In fact, SHOULD describes it nicely (e.g. "We recommend you do
> it this way, but you can do it any way you like if you think about the
> implications first.").
> 
> > > last, unless of course it's in the future. Perhaps an even better answer is
> > > to have the implementation ask the user which one to use.
> > 
> > That's always an option, regardless what the specification suggests.
> > 
> > But, I don't want to *force* user interface pop-ups (or even receiver
> > policy decisions) when the creator has clear intentions.
> 
> Yes.
> 
> David
> 
> -- 
> David Shaw          |  Technical Lead
> <[e-mail]>  |  Enterprise Content Delivery
> 617-250-3028        |  Akamai Technologies

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [e-mail]                        PGP key available


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7REpMJ15253 for ietf-openpgp-bks; Mon, 27 Aug 2001 07:51:22 -0700 (PDT)
Received: from kasiski.gnupg.de (porta.u64.de [194.77.88.106]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7REpJD15248 for <[e-mail]>; Mon, 27 Aug 2001 07:51:20 -0700 (PDT)
Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.22 #1 (Debian)) id 15bOcD-0008UP-00; Mon, 27 Aug 2001 17:47:53 +0200
Received: from wk by alberti.gnupg.de with local (Exim 3.22 #1 (Debian)) id 15bNnN-0000LA-00; Mon, 27 Aug 2001 16:55:21 +0200
To: [e-mail]
Subject: Re: How to update a self-signature?
References: <p05100303b7aaf65aff68@[192.168.1.180]> <008601c12c52$1b6181c0$[e-mail]> <p0510031fb7ab945664e5@[192.168.1.180]> <002b01c12d74$b105fb20$[e-mail]> <[e-mail]>
From: Werner Koch <[e-mail]>
Organisation: g10 Code GmbH
X-PGP-KeyID: 621CC013
X-Request-PGP: finger://[e-mail]
Date: 27 Aug 2001 16:55:20 +0200
In-Reply-To: <[e-mail]> (David Shaw's message of "Mon, 27 Aug 2001 09:48:50 -0400")
Message-ID: <[e-mail]>
Lines: 19
User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Mon, 27 Aug 2001 09:48:50 -0400, David Shaw said:

> "Most recent prevails" makes a lot of sense.  It can even be a SHOULD,

Except for key revocation - any valid revocation (which is a
self-signature) counts.  For subkeys it should be okay to allow
overriding of subkey revocations but it is practically worthless.
Revoking user ID revocations should definitely be possible.

Well, these rules should be obvious.

Ciao,

   Werner

-- 
Werner Koch        Omnis enim res, quae dando non deficit, dum habetur
g10 Code GmbH      et non datur, nondum habetur, quomodo habenda est.
Privacy Solutions                                        -- Augustinus



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7RETCq14821 for ietf-openpgp-bks; Mon, 27 Aug 2001 07:29:12 -0700 (PDT)
Received: from mercury.rus.uni-stuttgart.de (mercury.rus.uni-stuttgart.de [129.69.1.226]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7RETBD14816 for <[e-mail]>; Mon, 27 Aug 2001 07:29:11 -0700 (PDT)
Received: from rusfw by mercury.rus.uni-stuttgart.de with local (Exim 3.22 #1) id 15bNNj-0002Ng-00 for [e-mail]; Mon, 27 Aug 2001 16:28:51 +0200
To: [e-mail]
Subject: Re: Diffs for next draft
References: <p05100303b7aaf65aff68@[192.168.1.180]> <008601c12c52$1b6181c0$[e-mail]> <p0510031fb7ab945664e5@[192.168.1.180]>
From: Florian Weimer <[e-mail]>
Date: 27 Aug 2001 16:28:51 +0200
In-Reply-To: <p0510031fb7ab945664e5@[192.168.1.180]> (Jon Callas's message of "Fri, 24 Aug 2001 16:42:36 -0700")
Message-ID: <[e-mail]>
Lines: 16
User-Agent: Gnus/5.090001 (Oort Gnus v0.01) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Jon Callas <[e-mail]> writes:

> This is my point: I don't see an obvious best answer. Furthermore, 2440 is
> a data specification standard, not a user interface guide or software
> construction manual.

Yes, and I strongly suggest to keep it that way.  I might have uttered
a different opinion in the past, but after a closer look at the USEFOR
draft and the associated process I came to the conclusion that one
better clearly separates syntax and basic semantics on the one side
and higher level semantics (even layer 8 stuff) on the other side.

-- 
Florian Weimer 	                  [e-mail]
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          [phone]/fax [phone]


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7RDnFj10856 for ietf-openpgp-bks; Mon, 27 Aug 2001 06:49:15 -0700 (PDT)
Received: from claude.kendall.akamai.com (walrus.ne.mediaone.net [65.96.217.45]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7RDnED10849 for <[e-mail]>; Mon, 27 Aug 2001 06:49:14 -0700 (PDT)
Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.9.3/8.9.3) id JAA09650 for [e-mail]; Mon, 27 Aug 2001 09:48:50 -0400
Date: Mon, 27 Aug 2001 09:48:50 -0400
From: David Shaw <[e-mail]>
To: [e-mail]
Subject: Re: How to update a self-signature?
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail]
References: <p05100303b7aaf65aff68@[192.168.1.180]> <008601c12c52$1b6181c0$[e-mail]> <p0510031fb7ab945664e5@[192.168.1.180]> <002b01c12d74$b105fb20$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <002b01c12d74$b105fb20$[e-mail]>; from [e-mail] on Sat, Aug 25, 2001 at 10:46:14AM -0400
X-PGP-Key: 2048R/3CB3B415/4D 96 83 18 2B AF BE 45 D0 07 C4 07 51 37 B3 18
X-URL: http://www.jabberwocky.com/
X-Phase-Of-Moon: The Moon is Waxing Gibbous (58% of Full)
X-Pointless-Random-Number: 154
X-Silly-Header: It sure is.
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Sat, Aug 25, 2001 at 10:46:14AM -0400, Michael Young wrote:

> Florian Weimer wrote:
> > This should probably go into a separate RFC.  Currently, RFC 2440 and
> > RFC 2440bis deal only with syntactic issues 
> 
> and Jon Callas wrote (this and subsequent quotes):
> > This is my point: I don't see an obvious best answer. Furthermore, 2440 is
> > a data specification standard, not a user interface guide or software
> 
> I understand that the specification primarily covers syntax, but
> if it doesn't cover at least some interpretation issues, then
> interoperation is seriously hampered.  Who cares how the bits
> are ordered if a sender and receiver interpret wildly different things?
> We need to have a meeting of the minds on more than just formatting.
> 
> > Secondarily, one way I look at it is as a receiver. I fetch a key from a
> > server and it has multiple primaries. How do I resolve this? Yeah, there's
> 
> On this specific issue, I want to know what a *sender* must do
> to change its "primary" marking such that a receiver will
> understand.  The same applies to any material in the self-signature,
> and this need may arise several times over a key/userId lifetime.

The draft does specify have a way to do this - rewriting the
signature(s) in place ("Since a self-signatures contain important
information about the key's use, an implementation SHOULD allow the
user to rewrite the self-signature...").  Both PGP and GnuPG do this.

The problem arises later, when the key with the new self-signatures is
added to a keyserver or sent to someone else who already has the key.
Most current implementations in the field will merge their existing
copy with the new one, resulting in two self-signatures.  It could be
argued that they should not do this, but since it's going to happen,
we should at least make a provision for it.

Like you, I favor a "most recent prevails" recommendation.  I think
that revoking and re-making self-signatures is going to result in some
massive keys if every time someone changes their preferences it means
a new revocation packet and self-signature.

I don't think that this is just a syntax issue, and therefore
inappropriate for 2440bis.  2440bis makes a point of covering syntax
issues that relate to security.  Since the information in a
self-signature can affect the security of messages sent to the key,
I'd say this is an appropriate issue to address in 2440bis.

"Most recent prevails" makes a lot of sense.  It can even be a SHOULD,
like the sample wording I sent out a couple of days ago, rather than a
MUST.  In fact, SHOULD describes it nicely (e.g. "We recommend you do
it this way, but you can do it any way you like if you think about the
implications first.").

> > last, unless of course it's in the future. Perhaps an even better answer is
> > to have the implementation ask the user which one to use.
> 
> That's always an option, regardless what the specification suggests.
> 
> But, I don't want to *force* user interface pop-ups (or even receiver
> policy decisions) when the creator has clear intentions.

Yes.

David

-- 
David Shaw          |  Technical Lead
<[e-mail]>  |  Enterprise Content Delivery
617-250-3028        |  Akamai Technologies


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7RDbEF07889 for ietf-openpgp-bks; Mon, 27 Aug 2001 06:37:14 -0700 (PDT)
Received: from mercury.rus.uni-stuttgart.de (mercury.rus.uni-stuttgart.de [129.69.1.226]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7RDbCD07883 for <[e-mail]>; Mon, 27 Aug 2001 06:37:13 -0700 (PDT)
Received: from rusfw by mercury.rus.uni-stuttgart.de with local (Exim 3.22 #1) id 15bMZQ-0000Z0-00 for [e-mail]; Mon, 27 Aug 2001 15:36:52 +0200
To: [e-mail]
Subject: Re: Resolving multiple primary user IDs and self-signatures
References: <[e-mail]> <[e-mail]> <[e-mail]>
From: Florian Weimer <[e-mail]>
Date: 27 Aug 2001 15:36:52 +0200
In-Reply-To: <[e-mail]> (David Shaw's message of "Sat, 25 Aug 2001 10:44:36 -0400")
Message-ID: <[e-mail]>
Lines: 35
User-Agent: Gnus/5.090001 (Oort Gnus v0.01) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

David Shaw <[e-mail]> writes:

[RFC 2440 et al. as mere syntax]

> True, and it even says that in the Abstract.  There is an exception
> made for security issues: "It does not deal with storage and
> implementation questions.  It does, however, discuss implementation
> issues necessary to avoid security flaws."

I think it limits itself to security flaws which directly break the
cryptographic algorithms involved.  Flaws at a higher level are not
discussed.

> Offhand, I can't think of a security implication to having multiple
> UIDs marked primary (though I'm sure someone here can).  My concern is
> with the security implications of having multiple conflicting
> self-signatures.  Without some suggested way to resolve the conflict,
> there can be security implications.  If it is truly a security issue,
> then it is appropriate in 2440bis.  (Obviously, I think it's enough of
> a security issue to mention - I'd like to hear what others think.)

Differences in interpretation of expiration times can have security
implications, too. ;-)

> > On the other hand, If such additions are accepted, I've got a long
> > list of them...
> 
> Care to work on a "Implementation Suggestions for OpenPGP" with me?

Yes, details will follow in private mail. 

-- 
Florian Weimer 	                  [e-mail]
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          [phone]/fax [phone]


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7RAnrD25538 for ietf-openpgp-bks; Mon, 27 Aug 2001 03:49:53 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7RAnqD25534 for <[e-mail]>; Mon, 27 Aug 2001 03:49:52 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10029; Mon, 27 Aug 2001 06:48:33 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-openpgp-rfc2440bis-03.txt
Date: Mon, 27 Aug 2001 06:48:32 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the An Open Specification for Pretty Good Privacy Working Group of the IETF.

	Title		: OpenPGP Message Format
	Author(s)	: J. Callas, L. Donnerhacke, H. Finney,
                          R. Thayer
	Filename	: draft-ietf-openpgp-rfc2440bis-03.txt
	Pages		: 68
	Date		: 24-Aug-01
	
This document defines many tag values, yet it doesn't describe a
mechanism for adding new tags (for new features). Traditionally the
Internet Assigned Numbers Authority (IANA) handles the allocation of
new values for future expansion and RFCs usually define the
procedure to be used by the IANA.  However there are subtle (and not
so subtle) interactions that may occur in this protocol between new
features and existing features which result in a significant
reduction in over all security. Therefore this document does not
define an extension procedure. Instead requests to define new tag
values (say for new encryption algorithms for example) should be
forwarded to the IESG Security Area Directors for consideration or
forwarding to the appropriate IETF Working Group for consideration.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-openpgp-rfc2440bis-03.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-openpgp-rfc2440bis-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-openpgp-rfc2440bis-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-openpgp-rfc2440bis-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-openpgp-rfc2440bis-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7PEmJH01848 for ietf-openpgp-bks; Sat, 25 Aug 2001 07:48:19 -0700 (PDT)
Received: from smtprelay2.adelphia.net (smtprelay2.adelphia.net [64.8.25.7]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7PEmHD01844 for <[e-mail]>; Sat, 25 Aug 2001 07:48:18 -0700 (PDT)
Received: from mwyoung ([24.48.51.230]) by smtprelay2.adelphia.net (Netscape Messaging Server 4.15) with SMTP id GIMP5603.2DV for <[e-mail]>; Sat, 25 Aug 2001 10:48:42 -0400 
Message-ID: <002b01c12d74$b105fb20$[e-mail]>
From: "Michael Young" <[e-mail]>
To: <[e-mail]>
References: <p05100303b7aaf65aff68@[192.168.1.180]> <008601c12c52$1b6181c0$[e-mail]> <p0510031fb7ab945664e5@[192.168.1.180]>
Subject: How to update a self-signature?
Date: Sat, 25 Aug 2001 10:46:14 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

-----BEGIN PGP SIGNED MESSAGE-----

Florian Weimer wrote:
> This should probably go into a separate RFC.  Currently, RFC 2440 and
> RFC 2440bis deal only with syntactic issues 

and Jon Callas wrote (this and subsequent quotes):
> This is my point: I don't see an obvious best answer. Furthermore, 2440 is
> a data specification standard, not a user interface guide or software

I understand that the specification primarily covers syntax, but
if it doesn't cover at least some interpretation issues, then
interoperation is seriously hampered.  Who cares how the bits
are ordered if a sender and receiver interpret wildly different things?
We need to have a meeting of the minds on more than just formatting.

> Secondarily, one way I look at it is as a receiver. I fetch a key from a
> server and it has multiple primaries. How do I resolve this? Yeah, there's

On this specific issue, I want to know what a *sender* must do
to change its "primary" marking such that a receiver will
understand.  The same applies to any material in the self-signature,
and this need may arise several times over a key/userId lifetime.

I'd be willing to issue a revocation on the old self-signature.  Which
of the "reason" values should be used?  Neither "key is superceded"
nor "userId information is no longer valid" is quite right.  I want
"signature is superceded".  How do people feel about adding such a reason?

While on the subject: the section on "Computing Signatures"
doesn't say what the "signature data" is for a certification
revocation (0x30).  Can we add a description there?

But I also offered a "most recent prevails" policy as an alternative.
One advantage to this approach is that it works even if the sender
has lost an old self-signature.  Another is that it is more compact --
extra revocation packets aren't necessary.

> been one recommendation in the last 24 hours since I started writing this
> reply that it be the first one that counts. Why? Why the first? Why not the

If I said that, I misspoke.  I strongly believe that "most recent prevails"
is the only sensible recommendation (if we make one at all).  But again,
an agreed revocation scheme would satisfy me.

> last, unless of course it's in the future. Perhaps an even better answer is
> to have the implementation ask the user which one to use.

That's always an option, regardless what the specification suggests.

But, I don't want to *force* user interface pop-ups (or even receiver
policy decisions) when the creator has clear intentions.

-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.3

iQEVAwUBO4e6LmNDnIII+QUHAQEwjgf7Bq+GLsAdyxy7d4Us9aqsZQZiky5PpcCI
Mp6OGvGPpmE4uGTeFEZw9pBrxIXqNTYBnjb4XDskHYYQu+k4Zpx3fTslsZPS5zvh
HZIluAqRvqtbqME5sjA66FJB47wETM6nzkp0ngw6tYppJ5vZK9DuverN6jKuTSmW
BuMEc/RdP4OzT6l+YV+8a42EhamioRI9sn/rnL6PoXSXkc9awuHlDsalyv4XYUG5
VEOhnL4vnmaPGFtf0SZtLgICr/t27ULDYY1X1tH0M65gYJgyeQfIUbhHCabcN+tY
11fLh2USW9CXnWtuGRzDv7LRq121EKbf3FqnahaWXk/eOJIkeWEyXg==
=tL9g
-----END PGP SIGNATURE-----




Received: by above.proper.com (8.11.6/8.11.3) id f7PEikI01690 for ietf-openpgp-bks; Sat, 25 Aug 2001 07:44:46 -0700 (PDT)
Received: from claude.kendall.akamai.com (walrus.ne.mediaone.net [65.96.217.45]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7PEijD01686 for <[e-mail]>; Sat, 25 Aug 2001 07:44:45 -0700 (PDT)
Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.9.3/8.9.3) id KAA09099; Sat, 25 Aug 2001 10:44:36 -0400
Date: Sat, 25 Aug 2001 10:44:36 -0400
From: David Shaw <[e-mail]>
To: Florian Weimer <[e-mail]>
Cc: [e-mail]
Subject: Re: Resolving multiple primary user IDs and self-signatures
Message-ID: <[e-mail]>
Mail-Followup-To: Florian Weimer <[e-mail]>, [e-mail]
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Sat, Aug 25, 2001 at 01:11:52PM +0200
X-PGP-Key: 2048R/3CB3B415/4D 96 83 18 2B AF BE 45 D0 07 C4 07 51 37 B3 18
X-URL: http://www.jabberwocky.com/
X-Phase-Of-Moon: The Moon is Waxing Crescent (47% of Full)
X-Pointless-Random-Number: 46
X-Silly-Header: It sure is.
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Sat, Aug 25, 2001 at 01:11:52PM +0200, Florian Weimer wrote:
> 
> David Shaw <[e-mail]> writes:
> 
> > Here are two suggestions to help with resolving multiple user IDs
> > marked primary, as well as resolving multiple self-signatures with
> > different subpackets:
> 
> This should probably go into a separate RFC.  Currently, RFC 2440 and
> RFC 2440bis deal only with syntactic issues (apart from a minor glitch
> in RFC 2440bis, 'A revoked certification no longer is a part of
> validity calculations.').

True, and it even says that in the Abstract.  There is an exception
made for security issues: "It does not deal with storage and
implementation questions.  It does, however, discuss implementation
issues necessary to avoid security flaws."

Offhand, I can't think of a security implication to having multiple
UIDs marked primary (though I'm sure someone here can).  My concern is
with the security implications of having multiple conflicting
self-signatures.  Without some suggested way to resolve the conflict,
there can be security implications.  If it is truly a security issue,
then it is appropriate in 2440bis.  (Obviously, I think it's enough of
a security issue to mention - I'd like to hear what others think.)

Self-signatures can carry subpackets that definitely affect the
actions that may be taken with a key.  To use one of my examples from
last night, if/when a symmetric cipher or hash is broken, the user can
simply announce that cipher or hash is not accepted (via a "preferred
symmetric algorithms" or "preferred hash algorithms" subpacket).
Without a way to resolve which self-signature is the one to follow,
the broken cipher or hash may be used, which could compromise the
security of the message.

> On the other hand, If such additions are accepted, I've got a long
> list of them...

Care to work on a "Implementation Suggestions for OpenPGP" with me?

David

-- 
David Shaw          |  Technical Lead
<[e-mail]>  |  Enterprise Content Delivery
617-250-3028        |  Akamai Technologies


Received: by above.proper.com (8.11.6/8.11.3) id f7PBC9i22043 for ietf-openpgp-bks; Sat, 25 Aug 2001 04:12:09 -0700 (PDT)
Received: from mercury.rus.uni-stuttgart.de (mercury.rus.uni-stuttgart.de [129.69.1.226]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7PBC7D22039 for <[e-mail]>; Sat, 25 Aug 2001 04:12:08 -0700 (PDT)
Received: from rusfw by mercury.rus.uni-stuttgart.de with local (Exim 3.22 #1) id 15abM0-0002Km-00 for [e-mail]; Sat, 25 Aug 2001 13:11:52 +0200
To: [e-mail]
Subject: Re: Resolving multiple primary user IDs and self-signatures
References: <[e-mail]>
From: Florian Weimer <[e-mail]>
Date: 25 Aug 2001 13:11:52 +0200
In-Reply-To: <[e-mail]> (David Shaw's message of "Fri, 24 Aug 2001 13:56:32 -0400")
Message-ID: <[e-mail]>
Lines: 18
User-Agent: Gnus/5.090001 (Oort Gnus v0.01) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

David Shaw <[e-mail]> writes:

> Here are two suggestions to help with resolving multiple user IDs
> marked primary, as well as resolving multiple self-signatures with
> different subpackets:

This should probably go into a separate RFC.  Currently, RFC 2440 and
RFC 2440bis deal only with syntactic issues (apart from a minor glitch
in RFC 2440bis, 'A revoked certification no longer is a part of
validity calculations.').

On the other hand, If such additions are accepted, I've got a long
list of them...

-- 
Florian Weimer 	                  [e-mail]
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          [phone]/fax [phone]


Received: by above.proper.com (8.11.6/8.11.3) id f7PAxmk21132 for ietf-openpgp-bks; Sat, 25 Aug 2001 03:59:48 -0700 (PDT)
Received: from kasiski.gnupg.de (porta.u64.de [194.77.88.106]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7PAxiD21112 for <[e-mail]>; Sat, 25 Aug 2001 03:59:45 -0700 (PDT)
Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.22 #1 (Debian)) id 15ac2b-0004kd-00; Sat, 25 Aug 2001 13:55:53 +0200
Received: from wk by alberti.gnupg.de with local (Exim 3.22 #1 (Debian)) id 15abE4-0007Ae-00; Sat, 25 Aug 2001 13:03:40 +0200
To: <[e-mail]>
Subject: Re: Diffs for next draft
References: <p05100303b7aaf65aff68@[192.168.1.180]> <008601c12c52$1b6181c0$[e-mail]> <p0510031fb7ab945664e5@[192.168.1.180]>
From: Werner Koch <[e-mail]>
Organisation: g10 Code GmbH
X-PGP-KeyID: 621CC013
X-Request-PGP: finger://[e-mail]
Date: 25 Aug 2001 13:03:40 +0200
In-Reply-To: <p0510031fb7ab945664e5@[192.168.1.180]> (Jon Callas's message of "Fri, 24 Aug 2001 16:42:36 -0700")
Message-ID: <[e-mail]>
Lines: 26
User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Fri, 24 Aug 2001 16:42:36 -0700, Jon Callas said:

> This is my point: I don't see an obvious best answer. Furthermore, 2440 is
> a data specification standard, not a user interface guide or software
> construction manual. It tells implementers the things they have to do to be

I really agree with you here.  There are already so many
implementation details in OpenPGP which frankly don't belong there but
can be justified due to the fact that OpenPGP is the specification of
a long standing de-facto standard.

Adding more of these implementation stuff will eventually make OpenPGP
as complicated and bloated as SET.  There are already a lot of concerns
on the complexity of OpenPGP saying that this won't increase security.

The secret key protection is a flaw in the standard and has to be
addressed. Well, the most simple way of addressing it is to say: an
implementation should never send a secret key packet without and
additonal layer of encryption. OTOH, we have the protection and we
should make sure that it this gives us a real protection.


-- 
Werner Koch        Omnis enim res, quae dando non deficit, dum habetur
g10 Code GmbH      et non datur, nondum habetur, quomodo habenda est.
Privacy Solutions                                        -- Augustinus



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7P3Q2B13435 for ietf-openpgp-bks; Fri, 24 Aug 2001 20:26:02 -0700 (PDT)
Received: from claude.kendall.akamai.com (walrus.ne.mediaone.net [65.96.217.45]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7P3Q0D13431 for <[e-mail]>; Fri, 24 Aug 2001 20:26:01 -0700 (PDT)
Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.9.3/8.9.3) id XAA01656; Fri, 24 Aug 2001 23:23:58 -0400
Date: Fri, 24 Aug 2001 23:23:58 -0400
From: David Shaw <[e-mail]>
To: Jon Callas <[e-mail]>
Cc: Michael Young <[e-mail]>, [e-mail]
Subject: Re: Diffs for next draft
Message-ID: <[e-mail]>
Mail-Followup-To: Jon Callas <[e-mail]>, Michael Young <[e-mail]>, [e-mail]
References: <p05100303b7aaf65aff68@[192.168.1.180]> <008601c12c52$1b6181c0$[e-mail]> <p0510031fb7ab945664e5@[192.168.1.180]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <p0510031fb7ab945664e5@[192.168.1.180]>; from [e-mail] on Fri, Aug 24, 2001 at 04:42:36PM -0700
X-PGP-Key: 2048R/3CB3B415/4D 96 83 18 2B AF BE 45 D0 07 C4 07 51 37 B3 18
X-URL: http://www.jabberwocky.com/
X-Phase-Of-Moon: The Moon is Waxing Crescent (42% of Full)
X-Pointless-Random-Number: 109
X-Silly-Header: It sure is.
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Fri, Aug 24, 2001 at 04:42:36PM -0700, Jon Callas wrote:

> Secondarily, one way I look at it is as a receiver. I fetch a key from a
> server and it has multiple primaries. How do I resolve this? Yeah, there's
> been one recommendation in the last 24 hours since I started writing this
> reply that it be the first one that counts. Why? Why the first? Why not the
> last? I can make a convincing argument that it should be the last one, too.
> But why the last. Why not the one with the latest date? I think I can argue
> that the latest date is even more correct than either the first or the
> last, unless of course it's in the future. Perhaps an even better answer is
> to have the implementation ask the user which one to use.
> 
> This is my point: I don't see an obvious best answer. Furthermore, 2440 is
> a data specification standard, not a user interface guide or software
> construction manual. It tells implementers the things they have to do to be
> compliant. What this really says that if you ever see a key with multiple
> primary user names, then your guess is as good as mine, and I'm not going
> to wag my finger at you for whatever rationale makes sense for you.

What do you think about adding some text to help resolve multiple
self-signatures?  Multiple primary user names are one thing, but
self-signatures can carry subpackets with serious implications.

For example: take a key with two self-signatures, one with a
revocation key set and one without.  Which is right?  Granted, it is
very hard to tell for all the reasons you gave above, but the penalty
for guessing wrong here is much worse.  If I add a revocation key to
my key and the revocation key is later compromised, I would want to
ensure the compromised key could not revoke mine.  Without even a
recommendation on how to resolve two self-signatures, the result could
be that my key would be revocable on some implementations, but not
others.  It's a great denial of service attack against the key owner.

Similarly, let's say that a few years down the road someone manages to
break one of the symmetric ciphers.  The solution is for the user to
not accept that cipher via the "preferred algorithms" packet.  With
two self-signatures and no way to disambiguate them, the broken cipher
may be used, which can compromise the secrecy of the message.

I strongly favor a recommendation to use the most recent
self-signature.  Picking the first or last doesn't make much sense to
me, as the signature packets could be placed in any order or
rearranged at any time.  It may not be a perfect way to resolve
conflicts, but it should be able to resolve a large majority of them.

If recommending to use the most recent isn't possible, even a line or
two to mention that this is not a casual question and that there are
security implications to picking the wrong self-signature would be
good.  At least it would remind people of the issue.

David

-- 
David Shaw          |  Technical Lead
<[e-mail]>  |  Enterprise Content Delivery
617-250-3028        |  Akamai Technologies


Received: by above.proper.com (8.11.6/8.11.3) id f7ONhJx09651 for ietf-openpgp-bks; Fri, 24 Aug 2001 16:43:19 -0700 (PDT)
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7ONhID09647 for <[e-mail]>; Fri, 24 Aug 2001 16:43:18 -0700 (PDT)
Received: from [192.168.1.180] (63.73.97.165) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.0.3); Fri, 24 Aug 2001 16:43:16 -0700
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0510031fb7ab945664e5@[192.168.1.180]>
In-Reply-To: <008601c12c52$1b6181c0$[e-mail]>
References: <p05100303b7aaf65aff68@[192.168.1.180]> <008601c12c52$1b6181c0$[e-mail]>
Date: Fri, 24 Aug 2001 16:42:36 -0700
To: "Michael Young" <[e-mail]>, <[e-mail]>
From: Jon Callas <[e-mail]>
Subject: Re: Diffs for next draft
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

At 12:06 AM -0400 8/24/01, Michael Young wrote:

>It seems that the most likely reason for a second "primary"
>is that it has been updated.  If so, it seems that one should
>defer to the most recent valid signature.  Can we say
>that an implementation "SHOULD" do that, rather than leaving
>it open?

As I remember it, when we introduced this, there were people who thought it
should be a MUST that there be exactly one of them. I thought this was a
bit fussy, myself -- as it requires the implementations to verify that
there's only one.

I came up with the present wording as a way to subtly admonish the practice
without presuming to know the answer. The simple and obvious way to deal
with the problem of multiple primaries is don't do that. This is the Henny
Youngman Solution (from the old joke: HY goes into the doctor and says,
"Doc, it hurts when I do this," waving an arm. The doctor replies, "Then
don't do that"). The penalty for writing multiple primaries is that the
receiver may do something perverse, and you can't use the standard as a
stick. Don't do that.

Secondarily, one way I look at it is as a receiver. I fetch a key from a
server and it has multiple primaries. How do I resolve this? Yeah, there's
been one recommendation in the last 24 hours since I started writing this
reply that it be the first one that counts. Why? Why the first? Why not the
last? I can make a convincing argument that it should be the last one, too.
But why the last. Why not the one with the latest date? I think I can argue
that the latest date is even more correct than either the first or the
last, unless of course it's in the future. Perhaps an even better answer is
to have the implementation ask the user which one to use.

This is my point: I don't see an obvious best answer. Furthermore, 2440 is
a data specification standard, not a user interface guide or software
construction manual. It tells implementers the things they have to do to be
compliant. What this really says that if you ever see a key with multiple
primary user names, then your guess is as good as mine, and I'm not going
to wag my finger at you for whatever rationale makes sense for you.

	Jon



Received: by above.proper.com (8.11.6/8.11.3) id f7OINe328694 for ietf-openpgp-bks; Fri, 24 Aug 2001 11:23:40 -0700 (PDT)
Received: from claude.kendall.akamai.com (akafire.akamai.com [65.202.32.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7OINdD28690 for <[e-mail]>; Fri, 24 Aug 2001 11:23:39 -0700 (PDT)
Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.9.3/8.9.3) id OAA02867 for [e-mail]; Fri, 24 Aug 2001 14:23:31 -0400
Date: Fri, 24 Aug 2001 13:56:32 -0400
From: David Shaw <[e-mail]>
To: [e-mail]
Subject: Resolving multiple primary user IDs and self-signatures
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
X-PGP-Key: 2048R/3CB3B415/4D 96 83 18 2B AF BE 45 D0 07 C4 07 51 37 B3 18
X-URL: http://www.jabberwocky.com/
X-Phase-Of-Moon: The Moon is Waxing Crescent (38% of Full)
X-Pointless-Random-Number: 62
X-Silly-Header: It sure is.
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Here are two suggestions to help with resolving multiple user IDs
marked primary, as well as resolving multiple self-signatures with
different subpackets:

>From 5.2.3.19. Primary user id:

   This is a flag in a user id's self signature that states whether
   this user id is the main user id for this key. It is reasonable for
   an implementation to resolve ambiguities in preferences, etc. by
   referring to the primary user id. If this flag is absent, its value
   is zero. If more than one user id in a key is marked as primary, the
   implementation may resolve the ambiguity in any way it sees fit,
|  but it is RECOMMENDED that priority be given to the user ID with
|  the most recent self signature.

>From 5.2.3.3. Notes on Self-Signatures:

   Since a self-signatures contain important information about the
   key's use, an implementation SHOULD allow the user to rewrite the
   self-signature, and important information in it, such as preferences
   and key expiration.
|  An implementation that encounters multiple self-signatures on the
|  same object may resolve the ambiguity in any way it sees fit, but
|  it is RECOMMENDED that priority be given to the most recent
|  self-signature.

David

-- 
   David Shaw  |  [e-mail]  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7OHkbT27300 for ietf-openpgp-bks; Fri, 24 Aug 2001 10:46:37 -0700 (PDT)
Received: from xfw.transarc.ibm.com (xfw.transarc.ibm.com [192.54.226.51]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7OHkZD27289 for <[e-mail]>; Fri, 24 Aug 2001 10:46:35 -0700 (PDT)
Received: from mailhost.transarc.ibm.com (mailhost.transarc.ibm.com [9.38.192.124]) by xfw.transarc.ibm.com (AIX4.3/UCB 8.7/8.7) with ESMTP id NAA80162 for <[e-mail]>; Fri, 24 Aug 2001 13:38:54 -0400 (EDT)
Received: from mwyoung (dhcp-197-83.transarc.ibm.com [9.38.197.83]) by mailhost.transarc.ibm.com (8.8.0/8.8.0) with SMTP id NAA28536 for <[e-mail]>; Fri, 24 Aug 2001 13:46:32 -0400 (EDT)
Message-ID: <013901c12cc4$76cf6500$[e-mail]>
From: "Michael Young" <[e-mail]>
To: <[e-mail]>
References: <00cd01c12c9d$aa0f46a0$[e-mail]> <345889033.998671014@[10.235.121.12]> <00f201c12cae$c9a12f40$[e-mail]> <[e-mail]>
Subject: Re: Encoding "secret key is hashed"
Date: Fri, 24 Aug 2001 13:44:45 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

-----BEGIN PGP SIGNED MESSAGE-----

Ingo Luetkebohle replied:
> Well, associating all sorts of special meanings to the pre-S2K byte is
> somewhat of a mess, too, isn't it?
>
> IMHO, it would have been a lot cleaner to *always* use an S2K
> specifier and then have a 0 symmetric algorithm value for "no

Of course.  But we already have a pre-S2K byte, for compatibility
with PGP2, which won't go away.

> encryption". Then, I would have liked a length byte to precede the
> public key data so that you can just skip it entirely without having

If you plan to do any consistency checking on the parameters,
you'll need parse it anyway.  If you include them in the hash,
then you might be willing to skip the checks sometimes, but
then you'd at least need to digest the material (but admittedly
not interpret it).

Rather than put in a length, I'd just put in the whole public
key packet.  That would also allow the secret key packet to have
its own (independent) version number.

> to parse all of the MPI's. Additionally, the differences between the
> different session key packets could have been reduced and aligned to
> be similiar to the encrypted data packet so that the same header
> fields are aligned at the same offsets for all packet types and only
> thes differing fields are at different offsets.

Sure, a clean-slate design might do all of these things.  But our
slate is well-used.  On the whole, that's a good thing ;-).

Most implementations will want to support older formats anyway.
Adding a substantially new format, even if it alone is easier to
parse, means more code than an isolated tweak on the old one.
I wouldn't open the door to any old hack, but this one feels good.

-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.3

iQEVAwUBO4aSh2NDnIII+QUHAQFxggf/eiZznGnba1Vd89DpHZVCJ4QZcmASjCaG
8wH0UTm6bS55lHKtH+1EqMRfOJd/qYgV6Z7750V862CPyLhID604aXAvJyr6d7Uy
FTgW0Odec25BWpPJNu5jST+aDXPPDDPoYD1Q9iDvnP7Tv04eAw2gnaY1D12y/ewF
WHtlBVDTo21JtJzXG3+49d+ANcUP3MirPunpc/eD2Bdv1XKUpwaFIqLiexrqA0EV
B7O/ueRM7m3tVefXrRAJ4LIfArt72A60I1EGNDP+kqvIL0qD+U05BlQ9+lXOA3R4
wau6ziv6ghYWQ253O1Bys9O0o0mRV3zQHoGASPDcYyD09W0ecJuodg==
=Ke+E
-----END PGP SIGNATURE-----




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7OHaUZ27016 for ietf-openpgp-bks; Fri, 24 Aug 2001 10:36:30 -0700 (PDT)
Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7OHaTD27012 for <[e-mail]>; Fri, 24 Aug 2001 10:36:29 -0700 (PDT)
Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id KAA05518 for [e-mail]; Fri, 24 Aug 2001 10:36:14 -0700
Date: Fri, 24 Aug 2001 10:36:14 -0700
From: [e-mail]
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: Encoding "secret key is hashed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Fri, 24 Aug 2001 11:58:38 -0400, Michael Young said:

> I strongly recommend hashing the entire contents, including the public
> key material.  If you wanted to leave out the material between the

I agree as well with this concept.  The fingerprint calculation also
hashes the creation date and key algorithm; the former is not needed and
was an unfortunate decision, but it is a good idea to protect the latter
(conceivably we could have a case in the future where changing the PK
algorithm and tweaking some MPI values could cause harm).

The question is whether we should include the intervening material between
the public and private key portions.  In some ways that could simplify
the implementor's task, but depending on the order in which parsing and
hashing is done, the data might not be quite as handy as it sounds.

As for the packet algorithm, from implementation experience it is
inconvenient to have public and private parts for the same key with
different versions.  An earlier version of PGP, I think 2.6.0 or .1,
had a bug where if you changed your passphrase your secret key version
would get bumped from 2 to 3 but the public key version stayed the same.
This leads to situations where you import just the secret key packet
and synthesize a public key packet for it, which will also have V3.
Maybe it gets signed and the sig calculated on the version byte of 3.
Then later you see the original public key packet with V2, and signatures
on it calculated on that basis.  It was a real mess and we still have
kludges in our code to deal with this.

So I would recommend that we stick with V4 on the secret key packet.

Hal


Received: by above.proper.com (8.11.6/8.11.3) id f7OHS9p26599 for ietf-openpgp-bks; Fri, 24 Aug 2001 10:28:09 -0700 (PDT)
Received: from HACKSERV.saiknes.lv (hackserv.saiknes.lv [195.2.103.8]) by above.proper.com (8.11.6/8.11.3) with SMTP id f7OHS7D26595 for <[e-mail]>; Fri, 24 Aug 2001 10:28:08 -0700 (PDT)
Received: from saiknes.lv (unverified [127.0.0.1]) by 127.0.0.1 (EMWAC SMTPRS 0.83) with SMTP id <B0000079169@127.0.0.1>; Fri, 24 Aug 2001 18:27:40 +0200
Message-ID: <[e-mail]>
Date: Fri, 24 Aug 2001 19:27:40 +0200
From: [e-mail]
Organization: .NO.SPaM.NET
X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U)
X-Accept-Language: en,lv,ru
MIME-Version: 1.0
To: Edwin Woudt <[e-mail]>
CC: [e-mail]
Subject: Re: Klima/Rosa attack (was: Re: Diffs for next draft)
References: <[e-mail]> <355915176.998681039@[10.235.121.12]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Edwin Woudt wrote:
> [e-mail] wrote:
> > v5 seckey packet will broke seckey exchange with older versions,
> > while new s2k not - it will still be possible to import seckey in older
> > ver with aged workaround - unprotect them, export, import into older ver,
> > protect again.
> 
> Uhm... this approach will also work for v5 secret key packets: just
> unprotect and convert the packet to v4 before exporting.

it's easy to unprotect (just set passphrase to nothing) but not to convert to v4....

== <EOF> ==
Disastry
http://i.am/disastry/
-----BEGIN PGP SIGNATURE-----
Version: Netscape PGP half-Plugin 0.14 by Disastry / PGPsdk v1.7.1

iQA/AwUBO4ZyZTBaTVEuJQxkEQNR2gCfRZXieVoCUhO2dFegGLMUu41q6QUAnRTl
p4WlvNmSH0C3rueevHVRflqB
=2Mk8
-----END PGP SIGNATURE-----


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7OHNre26424 for ietf-openpgp-bks; Fri, 24 Aug 2001 10:23:53 -0700 (PDT)
Received: from wit387304.student.utwente.nl (wit387304.student.utwente.nl [130.89.234.74]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7OHNqD26420 for <[e-mail]>; Fri, 24 Aug 2001 10:23:52 -0700 (PDT)
Received: from druif.local ([10.235.121.12]) by wit387304.student.utwente.nl with esmtp (Exim 2.05 #1) id 15aKgR-0001Qv-00; Fri, 24 Aug 2001 19:23:51 +0200
Date: Fri, 24 Aug 2001 19:23:59 +0200
From: Edwin Woudt <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Klima/Rosa attack (was: Re: Diffs for next draft)
Message-ID: <355915176.998681039@[10.235.121.12]>
In-Reply-To: <[e-mail]>
References:  <[e-mail]>
X-Mailer: Mulberry/2.1.0b3 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

[e-mail] wrote:

> v5 seckey packet will broke seckey exchange with older versions,
> while new s2k not - it will still be possible to import seckey in older
> ver with aged workaround - unprotect them, export, import into older ver,
> protect again.

Uhm... this approach will also work for v5 secret key packets: just 
unprotect and convert the packet to v4 before exporting.


Edwin



Received: by above.proper.com (8.11.6/8.11.3) id f7OGmJc24677 for ietf-openpgp-bks; Fri, 24 Aug 2001 09:48:19 -0700 (PDT)
Received: from HACKSERV.saiknes.lv (hackserv.saiknes.lv [195.2.103.8]) by above.proper.com (8.11.6/8.11.3) with SMTP id f7OGmHD24673 for <[e-mail]>; Fri, 24 Aug 2001 09:48:17 -0700 (PDT)
Received: from saiknes.lv (unverified [127.0.0.1]) by 127.0.0.1 (EMWAC SMTPRS 0.83) with SMTP id <B0000079168@127.0.0.1>; Fri, 24 Aug 2001 17:43:14 +0200
Message-ID: <[e-mail]>
Date: Fri, 24 Aug 2001 18:43:14 +0200
From: [e-mail]
Organization: .NO.SPaM.NET
X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U)
X-Accept-Language: en,lv,ru
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Klima/Rosa attack (was: Re: Diffs for next draft)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Edwin Woudt wrote:

> Jon Callas <[e-mail]> replied:
> >
> > I think an S2K that includes a hash is only mildly hackish, myself. I'd
> > support this. I'd even support an additional one that is merely salted
> > with a hash.
> 
> 
> I disagree. As Werner Koch already pointed out, the 'correct' solution is 
> to introduce version 5 of the secret key packet. I however do not think 
> that there is any real reason for introducing a v5 public key packet, given 
> that nothing changed for public key packets.
> 
> Keeping v4 public key packets will make sure nothing is broken with regard 
> to exchanging public keys. Exchanging secret keys with older 
> implementations will be broken in both cases anyway, because of the new s2k 
> type.
> 
> Edwin

v5 seckey packet will broke seckey exchange with older versions,
while new s2k not - it will still be possible to import seckey in older ver
with aged workaround - unprotect them, export, import into older ver, protect again.

== <EOF> ==
Disastry  http://i.am/disastry/
http://disastry.dhs.org/pgp <----PGP plugins for Netscape and MDaemon
 ^--GPG for Win32 (supports loadable modules and IDEA)
 ^---PGP 2.6.3ia-multi04 (supports IDEA, CAST5, BLOWFISH, TWOFISH,
     AES, 3DES ciphers and MD5, SHA1, RIPEMD160 hashes)
-----BEGIN PGP SIGNATURE-----
Version: Netscape PGP half-Plugin 0.14 by Disastry / PGPsdk v1.7.1

iQA/AwUBO4ZntDBaTVEuJQxkEQMjSACg7AnKTW18uAAmrmiAqwysCU4WKkoAoNHq
Cl75N3ysOGDYGqp5In6YJpbZ
=/i+s
-----END PGP SIGNATURE-----


Received: by above.proper.com (8.11.6/8.11.3) id f7OGluY24659 for ietf-openpgp-bks; Fri, 24 Aug 2001 09:47:56 -0700 (PDT)
Received: from kasiski.gnupg.de (porta.u64.de [194.77.88.106]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7OGlsD24655 for <[e-mail]>; Fri, 24 Aug 2001 09:47:54 -0700 (PDT)
Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.22 #1 (Debian)) id 15aKzp-000389-00; Fri, 24 Aug 2001 19:43:53 +0200
Received: from wk by alberti.gnupg.de with local (Exim 3.22 #1 (Debian)) id 15aKB7-0006fj-00; Fri, 24 Aug 2001 18:51:29 +0200
To: <[e-mail]>
Subject: Re: Encoding "secret key is hashed"
References: <p0510031eb7ab8e4df9e4@[192.168.1.180]> <00cd01c12c9d$aa0f46a0$[e-mail]> <[e-mail]> <012a01c12cb5$a358e7e0$[e-mail]>
From: Werner Koch <[e-mail]>
Organisation: g10 Code GmbH
X-PGP-KeyID: 621CC013
X-Request-PGP: finger://[e-mail]
Date: 24 Aug 2001 18:51:28 +0200
In-Reply-To: <012a01c12cb5$a358e7e0$[e-mail]> ("Michael Young"'s message of "Fri, 24 Aug 2001 11:58:38 -0400")
Message-ID: <[e-mail]>
Lines: 13
User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Fri, 24 Aug 2001 11:58:38 -0400, Michael Young said:

> I strongly recommend hashing the entire contents, including the public
> key material.  If you wanted to leave out the material between the

I agree with your proposal.

  Werner

-- 
Werner Koch        Omnis enim res, quae dando non deficit, dum habetur
g10 Code GmbH      et non datur, nondum habetur, quomodo habenda est.
Privacy Solutions                                        -- Augustinus



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7OGlaS24647 for ietf-openpgp-bks; Fri, 24 Aug 2001 09:47:36 -0700 (PDT)
Received: from mail.arcor-ip.de (mail.arcor-ip.de [145.253.2.10] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7OGlYD24643 for <[e-mail]>; Fri, 24 Aug 2001 09:47:35 -0700 (PDT)
Received: from localhost (145.254.160.214) by mail.arcor-ip.de (5.5.034) id 3B8353990005D62D; Fri, 24 Aug 2001 18:47:26 +0200
Received: by localhost (Postfix, from userid 500) id 087F64C; Fri, 24 Aug 2001 18:42:18 +0200 (CEST)
Date: Fri, 24 Aug 2001 18:42:17 +0200
From: Ingo Luetkebohle <[e-mail]>
To: Michael Young <[e-mail]>
Cc: [e-mail]
Subject: Re: Encoding "secret key is hashed"
Message-ID: <[e-mail]>
References: <00cd01c12c9d$aa0f46a0$[e-mail]> <345889033.998671014@[10.235.121.12]> <00f201c12cae$c9a12f40$[e-mail]>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="0ntfKIWw70PvrIHh"
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <00f201c12cae$c9a12f40$[e-mail]>; from [e-mail] on Fri, Aug 24, 2001 at 11:09:35AM -0400
Organization: Maybe when I grow up
X-URL: http://blank.pages.de/
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

--0ntfKIWw70PvrIHh
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Aug 24, 2001 at 11:09:35AM -0400, Michael Young wrote:
> No, I don't want both changes.  Originally, I liked a version
> change, but I've been convinced that its implications are a mess.

Well, associating all sorts of special meanings to the pre-S2K byte is
somewhat of a mess, too, isn't it?

IMHO, it would have been a lot cleaner to *always* use an S2K
specifier and then have a 0 symmetric algorithm value for "no
encryption". Then, I would have liked a length byte to precede the
public key data so that you can just skip it entirely without having
to parse all of the MPI's. Additionally, the differences between the
different session key packets could have been reduced and aligned to
be similiar to the encrypted data packet so that the same header
fields are aligned at the same offsets for all packet types and only
thes differing fields are at different offsets.

*phew*. Excuse the rant. I have just been through implementation of a
key parser and will calm down any minute now.

Regards

--=20
	Ingo Luetkebohle / [e-mail] / Student of Bioinformatics
/
| Cross-Platform OpenPGP: http://xpg.sourceforge.net/
|
| Fargonauten.DE sysadmin; Gimp Registry maintainer;
| FP: 3187 4DEC 47E6 1B1E 6F4F  57D4 CD90 C164 34AD CE5B

--0ntfKIWw70PvrIHh
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Weitere Infos: siehe http://www.gnupg.org

iD8DBQE7hoPpzZDBZDStzlsRAdKtAKCgX0u6PKUb1cRHe04MwI4h/vur4QCglfIW
8qq7RXaT345RHqgAFF3i+SE=
=qnwR
-----END PGP SIGNATURE-----

--0ntfKIWw70PvrIHh--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7OG0Vm22952 for ietf-openpgp-bks; Fri, 24 Aug 2001 09:00:31 -0700 (PDT)
Received: from xfw.transarc.ibm.com (xfw.transarc.ibm.com [192.54.226.51]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7OG0TD22944 for <[e-mail]>; Fri, 24 Aug 2001 09:00:29 -0700 (PDT)
Received: from mailhost.transarc.ibm.com (mailhost.transarc.ibm.com [9.38.192.124]) by xfw.transarc.ibm.com (AIX4.3/UCB 8.7/8.7) with ESMTP id LAA80312 for <[e-mail]>; Fri, 24 Aug 2001 11:52:46 -0400 (EDT)
Received: from mwyoung (dhcp-197-83.transarc.ibm.com [9.38.197.83]) by mailhost.transarc.ibm.com (8.8.0/8.8.0) with SMTP id MAA28047 for <[e-mail]>; Fri, 24 Aug 2001 12:00:26 -0400 (EDT)
Message-ID: <012a01c12cb5$a358e7e0$[e-mail]>
From: "Michael Young" <[e-mail]>
To: <[e-mail]>
References: <p0510031eb7ab8e4df9e4@[192.168.1.180]><00cd01c12c9d$aa0f46a0$[e-mail]> <[e-mail]>
Subject: Re: Encoding "secret key is hashed"
Date: Fri, 24 Aug 2001 11:58:38 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

-----BEGIN PGP SIGNED MESSAGE-----

I like most of Werner Koch's edits.

One section that concerned me was:

> |  The 20 byte SHA-1 digest that follows the algorithm-specific
> |  portion is computed by hashing the plaintext of all the
> |  algorithm-specific octets (including MPI prefix and data). It is
> |  always encrypted like the algorithm-specific data. The deprecated 

I strongly recommend hashing the entire contents, including the public
key material.  If you wanted to leave out the material between the
public-key and secret-key parameters (that is, the pre-S2K byte,
the S2K, and the IV), I could accept that, but I think it would
be more convenient and consistent to include them.

Here's my stab at a description, based on Werner's draft:

| The 20 byte SHA-1 digest that follows the algorithm-specific portion
| is computed by hashing:
|     the public key contents (exactly as for fingerprints,
|       see "KeyIDs and Fingerprints");
|     followed by the secret key packet contents,
|       including the plaintext of the algorithm-specific data
|       (including any MPI prefixes and data).
| The digest is appended to the secret-key parameters, and is
| encrypted along with them, without any CFB resynchronization.

-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.3

iQEVAwUBO4Z5pWNDnIII+QUHAQHFtAgAlxkBDwdYiGX6vCLbrglSWNRgtOdZxdXV
M33fryePmhjYpOIGeVOO73nXwGH0DLKwCIczOERT0w7bqCJNadjSLUoCvQ9yoz6g
E1ndo9XLd6/OB/ybS24qOJzbmaANDDDDWuDT2N/Qe+U1VnmUn0Yx8B9CSh7O6b+x
gBN/R6wwbyEGnNdaMIwP+1phzjqfFAARTfTOeiyPUUYSrWOJtpfxg0csnxFK1PWu
IVY/UI+2MqwayxEoITwEqigS/13OtvCKuHBC9GcznNVS/6lOycUjj541VJnCp25h
4BmP79k2RyW0WYxqI4FU4WPDiKPhRSCthIQvTIYONm10dkbZynZV7A==
=a/wP
-----END PGP SIGNATURE-----




Received: by above.proper.com (8.11.6/8.11.3) id f7OFBUF16797 for ietf-openpgp-bks; Fri, 24 Aug 2001 08:11:30 -0700 (PDT)
Received: from xfw.transarc.ibm.com (xfw.transarc.ibm.com [192.54.226.51]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7OFBSD16792 for <[e-mail]>; Fri, 24 Aug 2001 08:11:28 -0700 (PDT)
Received: from mailhost.transarc.ibm.com (mailhost.transarc.ibm.com [9.38.192.124]) by xfw.transarc.ibm.com (AIX4.3/UCB 8.7/8.7) with ESMTP id LAA47822 for <[e-mail]>; Fri, 24 Aug 2001 11:03:44 -0400 (EDT)
Received: from mwyoung (dhcp-197-83.transarc.ibm.com [9.38.197.83]) by mailhost.transarc.ibm.com (8.8.0/8.8.0) with SMTP id LAA27793 for <[e-mail]>; Fri, 24 Aug 2001 11:11:24 -0400 (EDT)
Message-ID: <00f201c12cae$c9a12f40$[e-mail]>
From: "Michael Young" <[e-mail]>
To: <[e-mail]>
References:  <00cd01c12c9d$aa0f46a0$[e-mail]> <345889033.998671014@[10.235.121.12]>
Subject: Re: Encoding "secret key is hashed"
Date: Fri, 24 Aug 2001 11:09:35 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

-----BEGIN PGP SIGNED MESSAGE-----

"Edwin Woudt" <[e-mail]> wrote:
> I assume that you still want to change the version number to 5 as in your 
> March posting?

No, I don't want both changes.  Originally, I liked a version
change, but I've been convinced that its implications are a mess.

It seemed that others were uncomfortable with having the the public
and secret key versions out of sync, and I can appreciate that.  The
version number is included in the hashes for fingerprints and for
signatures, so one would either have to map "secret version 5" to
"public version 4", or include the public-key version number in the
secret-key packet.  The latter is cleaner, but it still may be
a little disruptive.

So, Hal Finney's suggestion (change the pre-S2K byte) sounded like
a fair alternative, as it wouldn't require changing the version number,
but it also doesn't disrupt the S2K (which is used elsewhere).

...

By the way, this hash would include *all* the key material, including
the public part, right?

-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.3

iQEVAwUBO4Zt/WNDnIII+QUHAQGzQwf+JHOc+RsBUiHdCAxmJjuw/WbjJ+353TTL
V0QhTy1kMqddFOfLW93k2tH0A6dZkRlOZuOLccH0+NU3xOLG+w9N502Nz2dXxbiZ
rWgQJJxl7veoJJ/+ObAUwA0E5jN4qR2AG38rwqqD69In+j2sFiuPwlX+gKA/ibZd
B7j4QzbifnDmu/M0o8s/WnA+Bsw7l2UEhxaK43a5WCY+PG/V+MllUuZDfLwGptLS
VC1yZJTFeVznN6l2Qs4cXIF0D/hytjNPyiEsZjWWfwinvSGECR/mb77iys9V91wb
iNmjj6TaODI/LpL9oRHeFyydGG+MUr9V/qy75Kd9gVP92/isfv/nyA==
=2mFV
-----END PGP SIGNATURE-----




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7OEjuL13987 for ietf-openpgp-bks; Fri, 24 Aug 2001 07:45:56 -0700 (PDT)
Received: from kasiski.gnupg.de (porta.u64.de [194.77.88.106]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7OEjsD13975 for <[e-mail]>; Fri, 24 Aug 2001 07:45:54 -0700 (PDT)
Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.22 #1 (Debian)) id 15aJ5j-0002qC-00; Fri, 24 Aug 2001 17:41:51 +0200
Received: from wk by alberti.gnupg.de with local (Exim 3.22 #1 (Debian)) id 15aIGw-0006SP-00; Fri, 24 Aug 2001 16:49:22 +0200
To: <[e-mail]>
Subject: Re: Encoding "secret key is hashed"
References: <p0510031eb7ab8e4df9e4@[192.168.1.180]> <00cd01c12c9d$aa0f46a0$[e-mail]>
From: Werner Koch <[e-mail]>
Organisation: g10 Code GmbH
X-PGP-KeyID: 621CC013
X-Request-PGP: finger://[e-mail]
Date: 24 Aug 2001 16:49:21 +0200
In-Reply-To: <00cd01c12c9d$aa0f46a0$[e-mail]> ("Michael Young"'s message of "Fri, 24 Aug 2001 09:07:01 -0400")
Message-ID: <[e-mail]>
Lines: 60
User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Fri, 24 Aug 2001 09:07:01 -0400, Michael Young said:

> Hal Finney offered the following alternative, which I like
> much better than tweaking the S2K itself:

>> Another place we could represent the alternative format is the byte
>> which comes shortly before the S2K in the secret key packet.  This
>> byte is fixed at a value of 255 to flag that an S2K is in use.  We
>> could perhaps use some alternate value for this byte to flag that the
>> private key is using a different form of checksum protection.

> Perhaps a value of 254?

I certainly support this. So what about this:

     - One octet indicating string-to-key usage conventions.  0
|      indicates that the secret key data is not encrypted.  Values 1
|      to 127 are symmetric-key encryption algorithm specifiers.
|      Values 128 to 253 are reserved. A value of 254 indicates that
|      that a string-to-key specifier is being given, 255 indicates
|      the same but makes use of the deprecated two-octet checksum.

|    - [Optional] If string-to-key usage octet was 254 or 255, a
       one-octet symmetric encryption algorithm.

|    - [Optional] If string-to-key usage octet was 254 or 255, a
       string-to-key specifier.  The length of the string-to-key
       specifier is implied by its type, as described above.

|    - [Optional] If secret data is encrypted, eight-octet Initial
       Vector (IV).

     - Encrypted multi-precision integers comprising the secret key
       data. These algorithm-specific fields are as described below.

|    - If the string-to-key usage octet was 254 a 20 byte SHA-1 digest
|      of the algorithm-specific portion.  Otherwise a two-octet
       checksum of the plaintext of the algorithm-specific portion
       (sum of all octets, mod 65536).

   [....]

|  The 20 byte SHA-1 digest that follows the algorithm-specific
|  portion is computed by hashing the plaintext of all the
|  algorithm-specific octets (including MPI prefix and data). It is
|  always encrypted like the algorithm-specific data. The deprecated 
   16-bit checksum that follows the algorithm-specific portion is
   the algebraic sum, mod 65536, of the plaintext of all the algorithm-
   specific octets (including MPI prefix and data).  With V3 keys, the
   checksum is stored in the clear.  With V4 keys, the checksum is
   encrypted like the algorithm-specific data.  This value is used to
|  check that the passphrase was correct.  Implementations SHOULD only
|  use the 20 byte SHA-1 digest.



-- 
Werner Koch        Omnis enim res, quae dando non deficit, dum habetur
g10 Code GmbH      et non datur, nondum habetur, quomodo habenda est.
Privacy Solutions                                        -- Augustinus



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7OEcKX13483 for ietf-openpgp-bks; Fri, 24 Aug 2001 07:38:20 -0700 (PDT)
Received: from wit387304.student.utwente.nl (wit387304.student.utwente.nl [130.89.234.74]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7OEcJD13479 for <[e-mail]>; Fri, 24 Aug 2001 07:38:19 -0700 (PDT)
Received: from druif.local ([10.235.121.12]) by wit387304.student.utwente.nl with esmtp (Exim 2.05 #1) id 15aI4l-00012o-00; Fri, 24 Aug 2001 16:36:47 +0200
Date: Fri, 24 Aug 2001 16:36:54 +0200
From: Edwin Woudt <[e-mail]>
To: Michael Young <[e-mail]>, [e-mail]
Subject: Re: Encoding "secret key is hashed"
Message-ID: <345889033.998671014@[10.235.121.12]>
In-Reply-To: <00cd01c12c9d$aa0f46a0$[e-mail]>
References:  <00cd01c12c9d$aa0f46a0$[e-mail]>
X-Mailer: Mulberry/2.1.0b3 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Michael Young <[e-mail]> wrote:

> Back in March, I opined that an S2K bit was out of place,
> noting that the S2K itself isn't broken, and that it is
> used in other contexts.

I agree.


> Hal Finney offered the following alternative, which I like
> much better than tweaking the S2K itself:
>
>> Another place we could represent the alternative format is the byte
>> which comes shortly before the S2K in the secret key packet.  This
>> byte is fixed at a value of 255 to flag that an S2K is in use.  We
>> could perhaps use some alternate value for this byte to flag that the
>> private key is using a different form of checksum protection.
>
> Perhaps a value of 254?

I assume that you still want to change the version number to 5 as in your 
March posting?

In that case, I do not really see a reason to bother with changing this 
value at all, because there is no real reason to support the old checksum 
protection for version 5 keys anyway.


> On a slightly related note, could we also add placeholders
> to the spec for the NAI-specific things that have come into
> practice?  One example is the S2K bits for raw and split keys,
> which is why it came to mind now.  Hal mentioned an X.509
> certificate signature subpacket, and a CRL packet type.  The
> PhotoID packet is yet another that was discussed recently.

This would indeed be helpful.


Edwin



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7OE9T611931 for ietf-openpgp-bks; Fri, 24 Aug 2001 07:09:29 -0700 (PDT)
Received: from rcn.ihtfp.org ([e-mail] [204.107.200.33]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7OE9RD11922 for <[e-mail]>; Fri, 24 Aug 2001 07:09:27 -0700 (PDT)
Received: (from warlord@localhost) by rcn.ihtfp.org (8.9.3) id KAA03306; Fri, 24 Aug 2001 10:09:25 -0400
To: Florian Weimer <[e-mail]>
Cc: [e-mail]
Subject: Re: Preparing a new draft...
References: <p05100311b7a70e684cea@[63.73.97.181]> 	<[e-mail]> 	<[e-mail]> 	<00b001c12bdf$26c48800$[e-mail]> 	<[e-mail]> 	<[e-mail]> 	<[e-mail]> 	<006401c12c4d$5293b3c0$[e-mail]> <[e-mail]>
From: Derek Atkins <[e-mail]>
Date: 24 Aug 2001 10:09:25 -0400
In-Reply-To: Florian Weimer's message of "24 Aug 2001 15:45:27 +0200"
Message-ID: <[e-mail]>
Lines: 37
X-Mailer: Gnus v5.5/Emacs 20.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Florian Weimer <[e-mail]> writes:

> "Michael Young" <[e-mail]> writes:
> 
> > Derek Atkins asked:
> > > Have you looked into why it is faster?
> > 
> > A partial-body encoding requires a power-of-two sized buffer be
> > repeatedly filled (completely, or until end-of-input), and then copied
> > to the output stream.  An indeterminate encoding has no length
> > information whatsoever, and so requires no buffering or copying.
> 
> In conjunction with compression, the claim that this affects
> performance is a bit peculiar because compression itself typically
> requires such buffering, and adds much more overhead anyway.

That was my impression as well.  Considering that most modern Unix
systems have some amount of buffering ANYWAYS in the I/O system, I
can't see how doing extra buffering really affects anything.  It's not
like you can really do a copy-in-place because you need to prepend
PGP-packet headers before the transformed data.  And, as you say,
compression has to buffer data anyways.

When Colin and I were first working on this back in '95, we _did_
buffer the data, and quite honestly it seemed to work just fine; much
better than writing to a file like PGP 2.x did.  And yes, we'd
definitely try to reduce the number of memcpy() functions that had to
happen.  But it's just as easy to encrypt-in-place as it is to
encrypt-to-a-different-buffer.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [e-mail]                        PGP key available


Received: by above.proper.com (8.11.6/8.11.3) id f7ODjfA10700 for ietf-openpgp-bks; Fri, 24 Aug 2001 06:45:41 -0700 (PDT)
Received: from mercury.rus.uni-stuttgart.de (mercury.rus.uni-stuttgart.de [129.69.1.226]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7ODjeD10695 for <[e-mail]>; Fri, 24 Aug 2001 06:45:41 -0700 (PDT)
Received: from rusfw by mercury.rus.uni-stuttgart.de with local (Exim 3.22 #1) id 15aHH5-0006rL-00 for [e-mail]; Fri, 24 Aug 2001 15:45:27 +0200
To: [e-mail]
Subject: Re: Preparing a new draft...
References: <p05100311b7a70e684cea@[63.73.97.181]> <[e-mail]> <[e-mail]> <00b001c12bdf$26c48800$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <006401c12c4d$5293b3c0$[e-mail]>
From: Florian Weimer <[e-mail]>
Date: 24 Aug 2001 15:45:27 +0200
In-Reply-To: <006401c12c4d$5293b3c0$[e-mail]> ("Michael Young"'s message of "Thu, 23 Aug 2001 23:31:40 -0400")
Message-ID: <[e-mail]>
Lines: 18
User-Agent: Gnus/5.090001 (Oort Gnus v0.01) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

"Michael Young" <[e-mail]> writes:

> Derek Atkins asked:
> > Have you looked into why it is faster?
> 
> A partial-body encoding requires a power-of-two sized buffer be
> repeatedly filled (completely, or until end-of-input), and then copied
> to the output stream.  An indeterminate encoding has no length
> information whatsoever, and so requires no buffering or copying.

In conjunction with compression, the claim that this affects
performance is a bit peculiar because compression itself typically
requires such buffering, and adds much more overhead anyway.

-- 
Florian Weimer 	                  [e-mail]
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          [phone]/fax [phone]


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7ODfQM10566 for ietf-openpgp-bks; Fri, 24 Aug 2001 06:41:26 -0700 (PDT)
Received: from fargonauten.de (fargonauten.de [212.8.198.132]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7ODfOD10561 for <[e-mail]>; Fri, 24 Aug 2001 06:41:25 -0700 (PDT)
Received: by fargonauten.de (Postfix, from userid 500) id 80E03EDA8A; Fri, 24 Aug 2001 15:41:12 +0200 (CEST)
Date: Fri, 24 Aug 2001 15:41:12 +0200
From: Ingo Luetkebohle <[e-mail]>
To: Edwin Woudt <[e-mail]>
Cc: Jon Callas <[e-mail]>, [e-mail]
Subject: Re: Klima/Rosa attack (was: Re: Diffs for next draft)
Message-ID: <[e-mail]>
References: <p0510031eb7ab8e4df9e4@[192.168.1.180]> <338574315.998663701@[10.235.121.12]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <338574315.998663701@[10.235.121.12]>; from [e-mail] on Fri, Aug 24, 2001 at 02:35:01PM +0200
Organization: Maybe when I grow up
X-URL: http://blank.pages.de/
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Fri, Aug 24, 2001 at 02:35:01PM +0200, Edwin Woudt wrote:
> Keeping v4 public key packets will make sure nothing is broken with regard 
> to exchanging public keys. Exchanging secret keys with older 
> implementations will be broken in both cases anyway, because of the new s2k 
> type.

I second Edwins opinion and would be in favor of a v5 secret key
format to solve the issue.

Ingo


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7OD91N07666 for ietf-openpgp-bks; Fri, 24 Aug 2001 06:09:01 -0700 (PDT)
Received: from smtprelay2.adelphia.net (smtprelay2.adelphia.net [64.8.25.7]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7OD8xD07659 for <[e-mail]>; Fri, 24 Aug 2001 06:08:59 -0700 (PDT)
Received: from mwyoung ([24.48.51.230]) by smtprelay2.adelphia.net (Netscape Messaging Server 4.15) with SMTP id GIKPVR03.C12 for <[e-mail]>; Fri, 24 Aug 2001 09:09:27 -0400 
Message-ID: <00cd01c12c9d$aa0f46a0$[e-mail]>
From: "Michael Young" <[e-mail]>
To: <[e-mail]>
References: <p0510031eb7ab8e4df9e4@[192.168.1.180]>
Subject: Encoding "secret key is hashed"
Date: Fri, 24 Aug 2001 09:07:01 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

-----BEGIN PGP SIGNED MESSAGE-----

Back in March, I opined that an S2K bit was out of place,
noting that the S2K itself isn't broken, and that it is
used in other contexts.

Hal Finney offered the following alternative, which I like
much better than tweaking the S2K itself:

> Another place we could represent the alternative format is the byte
> which comes shortly before the S2K in the secret key packet.  This
> byte is fixed at a value of 255 to flag that an S2K is in use.  We
> could perhaps use some alternate value for this byte to flag that the
> private key is using a different form of checksum protection.

Perhaps a value of 254?

...

On a slightly related note, could we also add placeholders
to the spec for the NAI-specific things that have come into
practice?  One example is the S2K bits for raw and split keys,
which is why it came to mind now.  Hal mentioned an X.509
certificate signature subpacket, and a CRL packet type.  The
PhotoID packet is yet another that was discussed recently.

-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.3

iQEVAwUBO4ZRYmNDnIII+QUHAQHivQf8CjCBd3aGY8hCctwNzHIriuW6NcUk/NuT
Npo2+zdF7v0qACvMJpZGOVrrJi9R2RIEUz3xvzuiFvqnXatGbn8iP69fg13wxPLt
W8MA/9Cor9HR+hTZVs1bERRCP0w1OeBM4dy4yEuEo1No05Mfimb68xB0Y1tQc56y
XcK0J1BAES3i0AHKrMqnCxKd1pGeKdAR9srQvsUWqVJQj2Zd19uePoOX92dl7aOD
tcDjgr3UDPWNyik9FyG0EmRarR8E2KXCJZG5wOh0r26gVCMUfPrqEQyQsCJqBJvb
2Uc1dC7fgf77ToTno3dMH6X1Pk33c5mKrufuuMk62kjOSlae+iPpNg==
=t3t/
-----END PGP SIGNATURE-----




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7OCZ5n05030 for ietf-openpgp-bks; Fri, 24 Aug 2001 05:35:05 -0700 (PDT)
Received: from wit387304.student.utwente.nl (wit387304.student.utwente.nl [130.89.234.74]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7OCZ3D05026 for <[e-mail]>; Fri, 24 Aug 2001 05:35:03 -0700 (PDT)
Received: from druif.local ([10.235.121.12]) by wit387304.student.utwente.nl with esmtp (Exim 2.05 #1) id 15aGAn-0000dY-00; Fri, 24 Aug 2001 14:34:53 +0200
Date: Fri, 24 Aug 2001 14:35:01 +0200
From: Edwin Woudt <[e-mail]>
To: Jon Callas <[e-mail]>, [e-mail]
Subject: Klima/Rosa attack (was: Re: Diffs for next draft)
Message-ID: <338574315.998663701@[10.235.121.12]>
In-Reply-To: <p0510031eb7ab8e4df9e4@[192.168.1.180]>
References:  <p0510031eb7ab8e4df9e4@[192.168.1.180]>
X-Mailer: Mulberry/2.1.0b3 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Werner Koch <[e-mail]> wrote>
>> The correct solution would be to introduce a version 5 of the secret
>> key packet - this is a major change as we may also want to also
>> introduce a v5 public key packet for symmetry reasons.  I guess this
>> will break a lot of code.
>>
>> The hackish solution is to define a new S2K type identical to type 3
>> (iterated and salted) which would then trigger the use of the new
>> SHA-1 checksum.  It should be made clear that this S2K type is only to
>> be used for the protection of the secret key and not for conventional
>> encryption.
>>
>> I don't like any of these solutions but the latter one is easier to
>> implement. Any other ideas?

Jon Callas <[e-mail]> replied:
>
> I think an S2K that includes a hash is only mildly hackish, myself. I'd
> support this. I'd even support an additional one that is merely salted
> with a hash.


I disagree. As Werner Koch already pointed out, the 'correct' solution is 
to introduce version 5 of the secret key packet. I however do not think 
that there is any real reason for introducing a v5 public key packet, given 
that nothing changed for public key packets.

Keeping v4 public key packets will make sure nothing is broken with regard 
to exchanging public keys. Exchanging secret keys with older 
implementations will be broken in both cases anyway, because of the new s2k 
type.


Edwin



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7O53p817753 for ietf-openpgp-bks; Thu, 23 Aug 2001 22:03:51 -0700 (PDT)
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7O53oD17744 for <[e-mail]>; Thu, 23 Aug 2001 22:03:50 -0700 (PDT)
Received: from [192.168.1.180] (63.73.97.165) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.0.3) for <[e-mail]>; Thu, 23 Aug 2001 22:03:48 -0700
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0510031eb7ab8e4df9e4@[192.168.1.180]>
Date: Thu, 23 Aug 2001 21:53:55 -0700
To: [e-mail]
From: Jon Callas <[e-mail]>
Subject: Re: Diffs for next draft
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

>>The correct solution would be to introduce a version 5 of the secret
>>key packet - this is a major change as we may also want to also
>>introduce a v5 public key packet for symmetry reasons.  I guess this
>>will break a lot of code.
>>
>>The hackish solution is to define a new S2K type identical to type 3
>>(iterated and salted) which would then trigger the use of the new
>>SHA-1 checksum.  It should be made clear that this S2K type is only to
>>be used for the protection of the secret key and not for conventional
>>encryption.
>>
>>I don't like any of these solutions but the latter one is easier to
>>implement. Any other ideas?

I think an S2K that includes a hash is only mildly hackish, myself. I'd
support this. I'd even support an additional one that is merely salted with
a hash.

	Jon



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7O4xbf17309 for ietf-openpgp-bks; Thu, 23 Aug 2001 21:59:37 -0700 (PDT)
Received: from claude.kendall.akamai.com (walrus.ne.mediaone.net [65.96.217.45]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7O4xaD17301 for <[e-mail]>; Thu, 23 Aug 2001 21:59:36 -0700 (PDT)
Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.9.3/8.9.3) id AAA26455 for [e-mail]; Fri, 24 Aug 2001 00:59:06 -0400
Date: Fri, 24 Aug 2001 00:59:06 -0400
From: David Shaw <[e-mail]>
To: [e-mail]
Subject: Re: Diffs for next draft
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail]
References: <p05100303b7aaf65aff68@[192.168.1.180]> <008601c12c52$1b6181c0$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <008601c12c52$1b6181c0$[e-mail]>; from [e-mail] on Fri, Aug 24, 2001 at 12:06:09AM -0400
X-PGP-Key: 2048R/3CB3B415/4D 96 83 18 2B AF BE 45 D0 07 C4 07 51 37 B3 18
X-URL: http://www.jabberwocky.com/
X-Phase-Of-Moon: The Moon is Waxing Crescent (31% of Full)
X-Pointless-Random-Number: 141
X-Silly-Header: It sure is.
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Fri, Aug 24, 2001 at 12:06:09AM -0400, Michael Young wrote:

> The description of the "Primary User ID" subpacket says:
> 
> >    If more than one user id in a key is marked as primary, the
> >    implementation may resolve the ambiguity in any way it sees fit.
> 
> It seems that the most likely reason for a second "primary"
> is that it has been updated.  If so, it seems that one should
> defer to the most recent valid signature.  Can we say
> that an implementation "SHOULD" do that, rather than leaving
> it open?

The draft does say "...an implementation SHOULD allow the user to
rewrite the self-signature, and important information in it, such as
preferences and key expiration", which implies that the implementation
should be able to rewrite the self-signatures to remove the primary
subpacket from one and place it onto the other.

That said, there is certainly going to be an implementation that just
merges things together so there is more than one self-signature on a
given user ID.  The keyservers do this now, I believe.

Perhaps (in addition to what you suggest), it would be good to include
language that suggests that in cases of multiple self-signatures on a
single user ID, the most recent should be followed.

David

-- 
   David Shaw  |  [e-mail]  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7O4i2m15476 for ietf-openpgp-bks; Thu, 23 Aug 2001 21:44:02 -0700 (PDT)
Received: from claude.kendall.akamai.com (walrus.ne.mediaone.net [65.96.217.45]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7O4i0D15458 for <[e-mail]>; Thu, 23 Aug 2001 21:44:00 -0700 (PDT)
Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.9.3/8.9.3) id AAA26265 for [e-mail]; Fri, 24 Aug 2001 00:43:24 -0400
Date: Fri, 24 Aug 2001 00:43:24 -0400
From: David Shaw <[e-mail]>
To: [e-mail]
Subject: Re: Diffs for next draft
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail]
References: <p05100303b7aaf65aff68@[192.168.1.180]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <p05100303b7aaf65aff68@[192.168.1.180]>; from [e-mail] on Thu, Aug 23, 2001 at 11:42:53AM -0700
X-PGP-Key: 2048R/3CB3B415/4D 96 83 18 2B AF BE 45 D0 07 C4 07 51 37 B3 18
X-URL: http://www.jabberwocky.com/
X-Phase-Of-Moon: The Moon is Waxing Crescent (31% of Full)
X-Pointless-Random-Number: 103
X-Silly-Header: It sure is.
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Thu, Aug 23, 2001 at 11:42:53AM -0700, Jon Callas wrote:

> >I am a little bit curious, can you give a rational why the feature
> >flags are not bit encoded?
> >
> 
> No. A byte vector seemed like a reasonable thing. I suppose we can do a bit
> vector. Does anyone else have an opinion.

I think this would be better as a bit vector.  Most everything else
that is of this type of list-of-something data (key server prefs, key
flags) uses bits.  Also, many years down the road we could have a lot
of feature flags, and bits are neater.

Incidentally, in 2440bis-02, the key server subpacket is defined as "N
octets of flags" and the key flags subpacket is defined as "Octet
string".  These should probably be the same. :)

David

-- 
   David Shaw  |  [e-mail]  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7O4E0H11694 for ietf-openpgp-bks; Thu, 23 Aug 2001 21:14:00 -0700 (PDT)
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7O4DxD11690 for <[e-mail]>; Thu, 23 Aug 2001 21:13:59 -0700 (PDT)
Received: from [192.168.1.180] (63.73.97.165) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.0.3); Thu, 23 Aug 2001 21:13:57 -0700
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0510031cb7ab83947514@[192.168.1.180]>
In-Reply-To: <008201c12c4f$fe9c9e00$[e-mail]>
References: <p05100303b7aaf65aff68@[192.168.1.180]> <008201c12c4f$fe9c9e00$[e-mail]>
Date: Thu, 23 Aug 2001 21:08:30 -0700
To: "Michael Young" <[e-mail]>, <[e-mail]>
From: Jon Callas <[e-mail]>
Subject: Re: Encoding of "features" subpacket
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

At 11:51 PM -0400 8/23/01, Michael Young wrote:
>At first, I accepted the explanation in the current draft, that this act like
>other "preferences".  But the only preferences encoded that way are
>algorithms lists; but algorithms are already encoded as bytes, and in
>the lists, order matters.  Features feel more like the keyserver or key
>flags, which are bit-encoded.
>

Good point. Anyone else want to weigh in? I'm now leaning to changing it.

	Jon


Received: by above.proper.com (8.11.6/8.11.3) id f7O480S10825 for ietf-openpgp-bks; Thu, 23 Aug 2001 21:08:00 -0700 (PDT)
Received: from smtprelay3.adelphia.net (smtprelay3.adelphia.net [64.8.25.8]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7O47xD10817 for <[e-mail]>; Thu, 23 Aug 2001 21:07:59 -0700 (PDT)
Received: from mwyoung ([24.48.51.230]) by smtprelay3.adelphia.net (Netscape Messaging Server 4.15) with SMTP id GIK0U403.VDS for <[e-mail]>; Fri, 24 Aug 2001 00:08:28 -0400 
Message-ID: <008601c12c52$1b6181c0$[e-mail]>
From: "Michael Young" <[e-mail]>
To: <[e-mail]>
References: <p05100303b7aaf65aff68@[192.168.1.180]>
Subject: Re: Diffs for next draft
Date: Fri, 24 Aug 2001 00:06:09 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

-----BEGIN PGP SIGNED MESSAGE-----

The description of the "Primary User ID" subpacket says:

>    If more than one user id in a key is marked as primary, the
>    implementation may resolve the ambiguity in any way it sees fit.

It seems that the most likely reason for a second "primary"
is that it has been updated.  If so, it seems that one should
defer to the most recent valid signature.  Can we say
that an implementation "SHOULD" do that, rather than leaving
it open?

I suppose it would be possible to revoke the old signature with a
"primary" subpacket, and then issue a new signature for both the old
and new name.  (The "Reason for Revocation" values include one to
indicate the *key* being superceded, and one to indicate that the user
ID information is no longer valid, but not one to indicate that the
signature has been superceded.)  This seems like a long way to
go to deal with a lack of a firm disambiguation policy.

-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.3

iQEVAwUBO4XSr2NDnIII+QUHAQEd8QgAqB+WD9AtiJTfxnl331fYryxllmhUEpdg
x/BH4usS5iOSWv9Bx7Ry3NUY535zmnKfeU4p7Y5SlVRF9OtnboeWbNoBz++3ik8X
rzuGN/ZvKq0bf8qvoEsGbKGxyRNU4G5h0YbqWZmr82VDHafxVfpp8m9oJ1Pz7+Ya
8WVJbpTU1fNneXxWnWHpf8r0iMokVku1QAZq2xvsvKXUFGb3qp7ae6YSsuualY7W
aVVX5AyPEjBFYyfVb+QNvx1PNX73YpYv5Uh5ZgIvCOxQCGlRqNeJsSvzd+eS2t5D
K2fYNAq598hJOYv3Rl+sOHLNC1QwOXfJA4dqJEdOS+Nycx1rk50q3w==
=aa+1
-----END PGP SIGNATURE-----




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7O3qsh08849 for ietf-openpgp-bks; Thu, 23 Aug 2001 20:52:54 -0700 (PDT)
Received: from smtprelay3.adelphia.net (smtprelay3.adelphia.net [64.8.25.8]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7O3qqD08827 for <[e-mail]>; Thu, 23 Aug 2001 20:52:52 -0700 (PDT)
Received: from mwyoung ([24.48.51.230]) by smtprelay3.adelphia.net (Netscape Messaging Server 4.15) with SMTP id GIK04X03.OFA for <[e-mail]>; Thu, 23 Aug 2001 23:53:21 -0400 
Message-ID: <008201c12c4f$fe9c9e00$[e-mail]>
From: "Michael Young" <[e-mail]>
To: <[e-mail]>
References: <p05100303b7aaf65aff68@[192.168.1.180]>
Subject: Encoding of "features" subpacket
Date: Thu, 23 Aug 2001 23:51:01 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

-----BEGIN PGP SIGNED MESSAGE-----

>I am a little bit curious, can you give a rational why the feature
> >> >flags are not bit encoded?
> >
> 
> No. A byte vector seemed like a reasonable thing. I suppose we can do a bit
> vector. Does anyone else have an opinion.

At first, I accepted the explanation in the current draft, that this act like
other "preferences".  But the only preferences encoded that way are
algorithms lists; but algorithms are already encoded as bytes, and in
the lists, order matters.  Features feel more like the keyserver or key
flags, which are bit-encoded.

-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.3

iQEVAwUBO4XO72NDnIII+QUHAQH6VwgAr9IXyDWOmmZY7Vs+FSFfy9YkAIK1NsgM
ywboDlubSuF+O75kmr1CUEitE92/F6dgAaFIWWRTcURt3dkHCDwaq0fA0Rpmdv1r
WVcQT1NrHJR+yNvQa2Q4D/Gys9qez867pR79Vb8UYx2gqYI4J6s2DL/w2TuGN2Li
+QtDcAiR4OEJFJSsq6gQX6CjED9HYy5FNzyrML3so0yBa5XVpIvvUOhgHUKXSYog
SZJsfXCqId9fPGoxm4qDeKL7e6+ilzXFl9d8PwKckA+uXJyBW5Rk822NYwg4fzzX
+GDAwQrHz//wYdEZTeSyH4YokPTiWWwgo273O5raHFjTQQc3YegVDQ==
=nuhD
-----END PGP SIGNATURE-----




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7O3Xp607025 for ietf-openpgp-bks; Thu, 23 Aug 2001 20:33:51 -0700 (PDT)
Received: from smtprelay1.adelphia.net (smtprelay1.adelphia.net [64.8.25.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7O3XnD07018 for <[e-mail]>; Thu, 23 Aug 2001 20:33:49 -0700 (PDT)
Received: from mwyoung ([24.48.51.230]) by smtprelay1.adelphia.net (Netscape Messaging Server 4.15) with SMTP id GIJZ4H02.SX4 for <[e-mail]>; Thu, 23 Aug 2001 23:31:29 -0400 
Message-ID: <006401c12c4d$5293b3c0$[e-mail]>
From: "Michael Young" <[e-mail]>
To: <[e-mail]>
References: <p05100311b7a70e684cea@[63.73.97.181]><[e-mail]><[e-mail]><00b001c12bdf$26c48800$[e-mail]><[e-mail]><[e-mail]> <[e-mail]>
Subject: Re: Preparing a new draft...
Date: Thu, 23 Aug 2001 23:31:40 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

-----BEGIN PGP SIGNED MESSAGE-----

From: "Werner Koch" <[e-mail]>
> On 23 Aug 2001 19:39:39 +0200, Florian Weimer said:
> 
> > You could use new packet lengths to create a stream of packets...
> 
> Well, this is actually done except when the packet is a compressed
> one.  Then we use the old PGP 2.6 method which is a little bit
> faster.  The RFC allows for this.

It's not clear to me what the RFC really allows.  (It is clear that
indeterminate encodings are not *recommended* at any time.)

The RFC first says:
    "If the packet is in a file, this means that the packet
     extends until the end of the file."

It then goes on to say "where the end of the data will be
clear from the context", which is a little more liberal.
I suppose you could interpret "in a file" as "is an
entire file".

In this context, the end is only clear because an *outer*
packet had a hard length.  Using a hard length there seems
inconsistent -- if you're generating output as you go,
you wouldn't know the outer size either.

Werner said earlier:
> Sure, there is no other way to do this when you don't know the length of
> the text in advanced.  This is very common for Unix tools and that
> feature is one of the great advantages of OpenPGP.

I agree that the ability to structure as a "filter" is an advantage.
The partial-body packet encoding achieves this, without having to rely
on some external container (file, or an outer packet) bounding the
length.

If anything, having a truly indeterminate packet inside another packet
makes it harder to use a filter-like implementation for parsing.

Derek Atkins asked:
> Have you looked into why it is faster?

A partial-body encoding requires a power-of-two sized buffer be
repeatedly filled (completely, or until end-of-input), and then copied
to the output stream.  An indeterminate encoding has no length
information whatsoever, and so requires no buffering or copying.

-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.3

iQEVAwUBO4XKkGNDnIII+QUHAQGvTgf9F9RR/IcEu9BrTt4gsnVnlnaMYhJlMj3u
GlzZrm8B1+RqcBo2hoRMIbE7MSxWP8sR2wotDjbMXTx9MJ99gbaZv5O18C5xCgNb
Q6Sv0dUPtR+qN9LGS7gJrIo5rxEAY2pEg35H0wYM3HbekqXH7+9hR5iGlAnHXD2r
MBkhSw6Vn4rfDSPb+L9LyVaSptfeniIH2Ahk5aZPGJAOWCgm8HRKgRMcihHbIe2V
xqnu+0xQjkj3qy7im07s2d7tSNuhhYuwKF20sHsF+uqosX5u8o0r/m45j2pUKqxU
1oW4Cd3RjLsb877tvS1jLNxsiXBwDcqc/Ir5HFjkInL1HxAqyo7BxQ==
=0LAZ
-----END PGP SIGNATURE-----




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7O2p4p02480 for ietf-openpgp-bks; Thu, 23 Aug 2001 19:51:04 -0700 (PDT)
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7O2p3D02467 for <[e-mail]>; Thu, 23 Aug 2001 19:51:03 -0700 (PDT)
Received: from [192.168.1.180] (63.73.97.165) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.0.3) for <[e-mail]>; Thu, 23 Aug 2001 19:51:00 -0700
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100318b7ab5c34ed84@[192.168.1.180]>
Date: Thu, 23 Aug 2001 18:20:32 -0700
To: [e-mail]
From: Jon Callas <[e-mail]>
Subject: New draft sent out.
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

You'll see it when it pops out the other end. I fixed a couple of typos I
found in a last scan, too.

	Jon


Received: by above.proper.com (8.11.6/8.11.3) id f7O18wW26286 for ietf-openpgp-bks; Thu, 23 Aug 2001 18:08:58 -0700 (PDT)
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7O18uD26280 for <[e-mail]>; Thu, 23 Aug 2001 18:08:56 -0700 (PDT)
Received: from [192.168.1.180] (63.73.97.165) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.0.3); Thu, 23 Aug 2001 18:08:52 -0700
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100316b7ab5968453b@[192.168.1.180]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Thu, 23 Aug 2001 18:08:02 -0700
To: Edwin Woudt <[e-mail]>, [e-mail]
From: Jon Callas <[e-mail]>
Subject: Re: Diffs for next draft
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Thanks. I put those in.

	Jon


Received: by above.proper.com (8.11.6/8.11.3) id f7NM9Yd18674 for ietf-openpgp-bks; Thu, 23 Aug 2001 15:09:34 -0700 (PDT)
Received: from wit387304.student.utwente.nl (wit387304.student.utwente.nl [130.89.234.74]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7NM9WD18670 for <[e-mail]>; Thu, 23 Aug 2001 15:09:33 -0700 (PDT)
Received: from dhcp2.local ([10.235.121.22] helo=fangmix.cryptohill.net) by wit387304.student.utwente.nl with esmtp (Exim 2.05 #1) id 15a2fF-00023y-00; Fri, 24 Aug 2001 00:09:25 +0200
Date: Fri, 24 Aug 2001 00:09:33 +0200
From: Edwin Woudt <[e-mail]>
To: Jon Callas <[e-mail]>, [e-mail]
Subject: Re: Diffs for next draft
Message-ID: <[e-mail]>
X-Mailer: Mulberry/2.1.0b3 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Jon Callas <[e-mail]> wrote:

> Here's everything I have. If there's something you want me to do and I've
> been obtuse, let me know again, and it'll get in. I'm planning on
> submitting the draft in about 24 hours. I can always do another one when
> something's omitted, so don't panic.

Here is another clarification of something that was unclear to me at first 
sight (again I needed interoperability testing to figure this out):


--- draft-ietf-openpgp-rfc2440bis-02.txt.orig   Thu Aug 23 21:40:19 2001
+++ draft-ietf-openpgp-rfc2440bis-02.txt        Fri Aug 24 00:02:20 2001
@@ -904,7 +904,9 @@
        which is equivalent to V3 in all other respects.

      - An eight-octet number that gives the key ID of the public key
-       that the session key is encrypted to.
+       that the session key is encrypted to. If the session key is
+       encrypted to a subkey then the key ID of this subkey is used
+       here instead of the key ID of the primary key.

      - A one-octet number giving the public key algorithm used.

@@ -3100,6 +3102,10 @@
    Also note that if V3 and V4 format keys share the same RSA key
    material, they will have different key ids as well as different
    fingerprints.
+
+   Finally, the key ID and fingerprint of a subkey are calculated in the
+   same way as for a primary key, including the 0x99 as the first byte
+   (even though this is not a valid packet ID for a public subkey).

 12. Notes on Algorithms

 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7NLHYr05102 for ietf-openpgp-bks; Thu, 23 Aug 2001 14:17:34 -0700 (PDT)
Received: from rcn.ihtfp.org ([e-mail] [204.107.200.33]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7NLHVD05098 for <[e-mail]>; Thu, 23 Aug 2001 14:17:31 -0700 (PDT)
Received: (from warlord@localhost) by rcn.ihtfp.org (8.9.3) id RAA02346; Thu, 23 Aug 2001 17:17:13 -0400
To: Werner Koch <[e-mail]>
Cc: [e-mail]
Subject: Re: Preparing a new draft...
References: <p05100311b7a70e684cea@[63.73.97.181]> 	<[e-mail]> 	<[e-mail]> 	<00b001c12bdf$26c48800$[e-mail]> 	<[e-mail]> 	<[e-mail]> <[e-mail]>
From: Derek Atkins <[e-mail]>
Date: 23 Aug 2001 17:17:12 -0400
In-Reply-To: Werner Koch's message of "23 Aug 2001 22:00:21 +0200"
Message-ID: <[e-mail]>
Lines: 25
X-Mailer: Gnus v5.5/Emacs 20.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Have you looked into why it is faster?

-derek

Werner Koch <[e-mail]> writes:

> On 23 Aug 2001 19:39:39 +0200, Florian Weimer said:
> 
> > You could use new packet lengths to create a stream of packets...
> 
> Well, this is actually done except when the packet is a compressed
> one.  Then we use the old PGP 2.6 method which is a little bit
> faster.  The RFC allows for this.
> 
> -- 
> Werner Koch        Omnis enim res, quae dando non deficit, dum habetur
> g10 Code GmbH      et non datur, nondum habetur, quomodo habenda est.
> Privacy Solutions                                        -- Augustinus
> 

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [e-mail]                        PGP key available


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7NJw1F03862 for ietf-openpgp-bks; Thu, 23 Aug 2001 12:58:01 -0700 (PDT)
Received: from kasiski.gnupg.de (porta.u64.de [194.77.88.106]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7NJvwD03858 for <[e-mail]>; Thu, 23 Aug 2001 12:57:58 -0700 (PDT)
Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.22 #1 (Debian)) id 15a1U2-0001Hd-00; Thu, 23 Aug 2001 22:53:46 +0200
Received: from wk by alberti.gnupg.de with local (Exim 3.22 #1 (Debian)) id 15a0eL-0004Po-00; Thu, 23 Aug 2001 22:00:21 +0200
To: [e-mail]
Subject: Re: Preparing a new draft...
References: <p05100311b7a70e684cea@[63.73.97.181]> <[e-mail]> <[e-mail]> <00b001c12bdf$26c48800$[e-mail]> <[e-mail]> <[e-mail]>
From: Werner Koch <[e-mail]>
Organisation: g10 Code GmbH
X-PGP-KeyID: 621CC013
X-Request-PGP: finger://[e-mail]
Date: 23 Aug 2001 22:00:21 +0200
In-Reply-To: <[e-mail]> (Florian Weimer's message of "23 Aug 2001 19:39:39 +0200")
Message-ID: <[e-mail]>
Lines: 12
User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On 23 Aug 2001 19:39:39 +0200, Florian Weimer said:

> You could use new packet lengths to create a stream of packets...

Well, this is actually done except when the packet is a compressed
one.  Then we use the old PGP 2.6 method which is a little bit
faster.  The RFC allows for this.

-- 
Werner Koch        Omnis enim res, quae dando non deficit, dum habetur
g10 Code GmbH      et non datur, nondum habetur, quomodo habenda est.
Privacy Solutions                                        -- Augustinus



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7NIh3P02497 for ietf-openpgp-bks; Thu, 23 Aug 2001 11:43:03 -0700 (PDT)
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7NIh2D02492 for <[e-mail]>; Thu, 23 Aug 2001 11:43:02 -0700 (PDT)
Received: from [192.168.1.180] (64.69.113.115) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.0.3) for <[e-mail]>; Thu, 23 Aug 2001 11:43:00 -0700
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100303b7aaf65aff68@[192.168.1.180]>
Date: Thu, 23 Aug 2001 11:42:53 -0700
To: [e-mail]
From: Jon Callas <[e-mail]>
Subject: Re: Diffs for next draft
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Late last night, I replied to Werner, not to the list. Here's my reply to
him, and his reply to me (with permission).

	Jon

To: Werner Koch <[e-mail]>
From: Jon Callas <[e-mail]>
Subject: Re: Diffs for next draft

In our last episode ("Re: Diffs for next draft", shown on 8/23/01), Werner
Koch said:

>On Wed, 22 Aug 2001 15:52:12 -0700, Jon Callas said:
>
>> Here's everything I have. If there's something you want me to do and I've
>> been obtuse, let me know again, and it'll get in. I'm planning on
>
>Did someone else also checked that the OIDs for SHA-xxx are correct?
>

I haven't, myself. I'll put that on my list.

>I am a little bit curious, can you give a rational why the feature
>flags are not bit encoded?
>

No. A byte vector seemed like a reasonable thing. I suppose we can do a bit
vector. Does anyone else have an opinion.

>What about the Klima/Rosa attack?  If this draft is going to be the
>next RFC we should do something about it.  IIRC, we had not much
>discussion about it. The obvious fix would be use a hash instead of
>the simple checksum.  The problem is how to indicate the use of this
>new format.
>
>The correct solution would be to introduce a version 5 of the secret
>key packet - this is a major change as we may also want to also
>introduce a v5 public key packet for symmetry reasons.  I guess this
>will break a lot of code.
>
>The hackish solution is to define a new S2K type identical to type 3
>(iterated and salted) which would then trigger the use of the new
>SHA-1 checksum.  It should be made clear that this S2K type is only to
>be used for the protection of the secret key and not for conventional
>encryption.
>
>I don't like any of these solutions but the latter one is easier to
>implement. Any other ideas?

Let's put this on the list of things to do after this draft for the next one.

John wants to push to a new RFC. Here are three open issues.

	Jon

To: Jon Callas <[e-mail]>
Subject: Re: Diffs for next draft
From: Werner Koch <[e-mail]>
Organisation: g10 Code GmbH
X-PGP-KeyID: 621CC013
X-Request-PGP: finger://[e-mail]
Date: 23 Aug 2001 10:00:48 +0200
Lines: 25

Jon,

[It seems that you didn't post to the list.]

On Thu, 23 Aug 2001 00:26:17 -0700, Jon Callas said:

> No. A byte vector seemed like a reasonable thing. I suppose we can do a bit
> vector. Does anyone else have an opinion.

I have no problem with that, it is just that other attributes use bit
vectors.  Let's keep it as it is.  Can we start to use it and change
our keys to include feature flags?

> Let's put this on the list of things to do after this draft for the next one.

> John wants to push to a new RFC. Here are three open issues.

Okay.

  Werner

-- 
Werner Koch        Omnis enim res, quae dando non deficit, dum habetur
g10 Code GmbH      et non datur, nondum habetur, quomodo habenda est.
Privacy Solutions                                        -- Augustinus



Received: by above.proper.com (8.11.6/8.11.3) id f7NIeE602426 for ietf-openpgp-bks; Thu, 23 Aug 2001 11:40:14 -0700 (PDT)
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7NIeDD02422 for <[e-mail]>; Thu, 23 Aug 2001 11:40:13 -0700 (PDT)
Received: from [192.168.1.180] (64.69.113.115) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.0.3) for <[e-mail]>; Thu, 23 Aug 2001 11:40:06 -0700
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100303b7aaf65aff68@[192.168.1.180]>
Date: Thu, 23 Aug 2001 11:39:59 -0700
To: [e-mail]
From: Jon Callas <[e-mail]>
Subject: This draft or next?
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Late last night, I replied to Werner, not to the list. Here's his reply to
me, from which you can figure out my reply.

	Jon


To: Jon Callas <[e-mail]>
Subject: Re: Diffs for next draft
From: Werner Koch <[e-mail]>
Organisation: g10 Code GmbH
X-PGP-KeyID: 621CC013
X-Request-PGP: finger://[e-mail]
Date: 23 Aug 2001 10:00:48 +0200
Lines: 25

Jon,

[It seems that you didn't post to the list.]

On Thu, 23 Aug 2001 00:26:17 -0700, Jon Callas said:

> No. A byte vector seemed like a reasonable thing. I suppose we can do a bit
> vector. Does anyone else have an opinion.

I have no problem with that, it is just that other attributes use bit
vectors.  Let's keep it as it is.  Can we start to use it and change
our keys to include feature flags?

> Let's put this on the list of things to do after this draft for the next one.

> John wants to push to a new RFC. Here are three open issues.

Okay.

  Werner

-- 
Werner Koch        Omnis enim res, quae dando non deficit, dum habetur
g10 Code GmbH      et non datur, nondum habetur, quomodo habenda est.
Privacy Solutions                                        -- Augustinus



Received: by above.proper.com (8.11.6/8.11.3) id f7NHdqC01458 for ietf-openpgp-bks; Thu, 23 Aug 2001 10:39:52 -0700 (PDT)
Received: from mercury.rus.uni-stuttgart.de (mercury.rus.uni-stuttgart.de [129.69.1.226]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7NHdoD01454 for <[e-mail]>; Thu, 23 Aug 2001 10:39:51 -0700 (PDT)
Received: from rusfw by mercury.rus.uni-stuttgart.de with local (Exim 3.22 #1) id 15ZySB-00031C-00 for [e-mail]; Thu, 23 Aug 2001 19:39:39 +0200
To: [e-mail]
Subject: Re: Preparing a new draft...
References: <p05100311b7a70e684cea@[63.73.97.181]> <[e-mail]> <[e-mail]> <00b001c12bdf$26c48800$[e-mail]> <[e-mail]>
From: Florian Weimer <[e-mail]>
Date: 23 Aug 2001 19:39:39 +0200
In-Reply-To: <[e-mail]> (Werner Koch's message of "23 Aug 2001 17:39:10 +0200")
Message-ID: <[e-mail]>
Lines: 14
User-Agent: Gnus/5.090001 (Oort Gnus v0.01) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Werner Koch <[e-mail]> writes:

> > GnuPG encodes the <plaintext> using an old-style indeterminate
> > length packet.  This requires a parser to carve off the
> 
> Sure, there is no other way to do this when you don't know the length of
> the text in advanced.

You could use new packet lengths to create a stream of packets...

-- 
Florian Weimer 	                  [e-mail]
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          [phone]/fax [phone]


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7NFa1C25009 for ietf-openpgp-bks; Thu, 23 Aug 2001 08:36:01 -0700 (PDT)
Received: from kasiski.gnupg.de (porta.u64.de [194.77.88.106]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7NFZwD24999 for <[e-mail]>; Thu, 23 Aug 2001 08:35:58 -0700 (PDT)
Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.22 #1 (Debian)) id 15ZxOR-0000hF-00; Thu, 23 Aug 2001 18:31:43 +0200
Received: from wk by alberti.gnupg.de with local (Exim 3.22 #1 (Debian)) id 15ZwZa-0003zf-00; Thu, 23 Aug 2001 17:39:10 +0200
To: "Michael Young" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Preparing a new draft...
References: <p05100311b7a70e684cea@[63.73.97.181]> <[e-mail]> <[e-mail]> <00b001c12bdf$26c48800$[e-mail]>
From: Werner Koch <[e-mail]>
Organisation: g10 Code GmbH
X-PGP-KeyID: 621CC013
X-Request-PGP: finger://[e-mail]
Date: 23 Aug 2001 17:39:10 +0200
In-Reply-To: <00b001c12bdf$26c48800$[e-mail]> ("Michael Young"'s message of "Thu, 23 Aug 2001 10:23:16 -0400")
Message-ID: <[e-mail]>
Lines: 46
User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Thu, 23 Aug 2001 10:23:16 -0400, Michael Young said:

> Here (my perception of) the structure of a integrity-protected
> packet sequence:

>     SEIP-data packet {
>         <version=1>
>         encrypt-CFBn[key](
>             <plaintext>
>             MDC packet { SHA-1 hash }
>         )
>     }

Correct, however the plaintyext is usually a compressed packet but can
be any other packet as allowed by the OpenPGP grammar.  That the MDC
has a form of a packet is probably due to my request because it can
make things easier.  However an implementation can ignore the fact
that this is a packet and handle it just like a checksum with a fixed
header.

> GnuPG encodes the <plaintext> using an old-style indeterminate
> length packet.  This requires a parser to carve off the

Sure, there is no other way to do this when you don't know the length of
the text in advanced.  This is very common for Unix tools and that
feature is one of the great advantages of OpenPGP.

>     Is the <plaintext> *required* to be an "OpenPGP message"?

Yes.

>     Are indeterminate packets legal inside other indeterminate
>     packets?  If not, are they legal inside strictly bounded

Yes. 

There are only a few places where such packets are not allowed.  I
think this is the case for key packets but I am not sure what the
specs do say; GnuPG handles this automagically.

  Werner

-- 
Werner Koch        Omnis enim res, quae dando non deficit, dum habetur
g10 Code GmbH      et non datur, nondum habetur, quomodo habenda est.
Privacy Solutions                                        -- Augustinus



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7NEPBc20888 for ietf-openpgp-bks; Thu, 23 Aug 2001 07:25:11 -0700 (PDT)
Received: from xfw.transarc.ibm.com (xfw.transarc.ibm.com [192.54.226.51]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7NEP9D20882 for <[e-mail]>; Thu, 23 Aug 2001 07:25:10 -0700 (PDT)
Received: from mailhost.transarc.ibm.com (mailhost.transarc.ibm.com [9.38.192.124]) by xfw.transarc.ibm.com (AIX4.3/UCB 8.7/8.7) with ESMTP id KAA07756 for <[e-mail]>; Thu, 23 Aug 2001 10:17:26 -0400 (EDT)
Received: from mwyoung (dhcp-197-83.transarc.ibm.com [9.38.197.83]) by mailhost.transarc.ibm.com (8.8.0/8.8.0) with SMTP id KAA21156 for <[e-mail]>; Thu, 23 Aug 2001 10:25:03 -0400 (EDT)
Message-ID: <00b001c12bdf$26c48800$[e-mail]>
From: "Michael Young" <[e-mail]>
To: <[e-mail]>
References: <p05100311b7a70e684cea@[63.73.97.181]> <[e-mail]> <[e-mail]>
Subject: Re: Preparing a new draft...
Date: Thu, 23 Aug 2001 10:23:16 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

-----BEGIN PGP SIGNED MESSAGE-----

On the subject of MDC packets, I'd like to note a peculiarity
in the GnuPG implementation, and ask whether others consider
it reasonable, in accordance with the specification.

Here (my perception of) the structure of a integrity-protected
packet sequence:

    SEIP-data packet {
        <version=1>
        encrypt-CFBn[key](
            <plaintext>
            MDC packet { SHA-1 hash }
        )
    }

The discussion of the SEIP-data packet doesn't say so explicitly,
but the <plaintext> would be an "OpenPGP message" in the
packet sequence grammar.  Is that required, or simply
a convention?

GnuPG encodes the <plaintext> using an old-style indeterminate
length packet.  This requires a parser to carve off the
MDC packet *from the end* in order to properly bound the
interpretation of that packet.  I can think of at least two
approaches to doing so, but neither is very satisfying:

    Use the bounds provided by the outer packet to limit the
    size of the <plaintext> region.  In a recursive filter-style
    parser, this is unnatural -- rather than consuming a generic
    input stream, the parser must also be given the bounds of
    that stream (and that bound must be carried through any
    layers that might reach another parsing step).  Moreover,
    there is no requirement that the outer packet be bounded;
    it could very reasonably use an old-style indeterminate or
    new-style partial-body encoding itself.

    Maintain a 22-byte lookahead buffer.  If the outer packet
    has indeterminate (*or partial-body*) length, and the
    <plaintext> has indeterminate length, this seems to be the
    only viable option.  (If the <plaintext> could be something
    other than a "OpenPGP message", then it is effectively
    indeterminate.  Partial-body encodings present no problem.)

So, my questions are:

    Is the <plaintext> *required* to be an "OpenPGP message"?

    Are indeterminate packets legal inside other indeterminate
    packets?  If not, are they legal inside strictly bounded
    packets?

Thanks in advance for your thoughts.

-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.3

iQEVAwUBO4URw2NDnIII+QUHAQFqiQf6A5a7tVyhv5vou7FJQl/P/xCuzI0wX24C
H5fjlW1wYVJ1xapLd6D2RF8xzrQV+cSG3dY56wboy3QeOFTP9+YMTNfZBmr2sqhG
piZHfL94bt2CvO5L+NoJgBcLvEDXcGEED0PyMnCAa8AkmFSTZuUbYY4Fz71EDG6N
jGyix3Bbg2mbYRHQdqiG7Ljml15Zl0xAaEthu3zyzsf5FIM75Oa0SUDLrO5AYI1v
SlzG7W11jqWN+jUiafgiawRxdyY39XvSaAHfIy8kks42yzaDZlhOrNmshzdH1ejM
/7CItr+7GL06hGBjsQggIEb6X4J16QcYEEL74Fymdr4ocb0CapEWwQ==
=CpgF
-----END PGP SIGNATURE-----




Received: by above.proper.com (8.11.6/8.11.3) id f7N7E7B23192 for ietf-openpgp-bks; Thu, 23 Aug 2001 00:14:07 -0700 (PDT)
Received: from kasiski.gnupg.de (porta.u64.de [194.77.88.106]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7N7E5D23182 for <[e-mail]>; Thu, 23 Aug 2001 00:14:05 -0700 (PDT)
Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.22 #1 (Debian)) id 15ZpYY-0008C4-00; Thu, 23 Aug 2001 10:09:38 +0200
Received: from wk by alberti.gnupg.de with local (Exim 3.22 #1 (Debian)) id 15Zoio-0003DN-00; Thu, 23 Aug 2001 09:16:10 +0200
To: Jon Callas <[e-mail]>
Cc: [e-mail]
Subject: Re: Diffs for next draft
References: <p0510033eb7a9e75acb61@[63.73.97.181]>
From: Werner Koch <[e-mail]>
Organisation: g10 Code GmbH
X-PGP-KeyID: 621CC013
X-Request-PGP: finger://[e-mail]
Date: 23 Aug 2001 09:16:10 +0200
In-Reply-To: <p0510033eb7a9e75acb61@[63.73.97.181]> (Jon Callas's message of "Wed, 22 Aug 2001 15:52:12 -0700")
Message-ID: <[e-mail]>
Lines: 37
User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Wed, 22 Aug 2001 15:52:12 -0700, Jon Callas said:

> Here's everything I have. If there's something you want me to do and I've
> been obtuse, let me know again, and it'll get in. I'm planning on

Did someone else also checked that the OIDs for SHA-xxx are correct?

I am a little bit curious, can you give a rational why the feature
flags are not bit encoded? 

What about the Klima/Rosa attack?  If this draft is going to be the
next RFC we should do something about it.  IIRC, we had not much
discussion about it. The obvious fix would be use a hash instead of
the simple checksum.  The problem is how to indicate the use of this
new format.

The correct solution would be to introduce a version 5 of the secret
key packet - this is a major change as we may also want to also
introduce a v5 public key packet for symmetry reasons.  I guess this
will break a lot of code.

The hackish solution is to define a new S2K type identical to type 3
(iterated and salted) which would then trigger the use of the new
SHA-1 checksum.  It should be made clear that this S2K type is only to
be used for the protection of the secret key and not for conventional
encryption.

I don't like any of these solutions but the latter one is easier to
implement. Any other ideas?


  Werner

-- 
Werner Koch        Omnis enim res, quae dando non deficit, dum habetur
g10 Code GmbH      et non datur, nondum habetur, quomodo habenda est.
Privacy Solutions                                        -- Augustinus



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7MN2L828657 for ietf-openpgp-bks; Wed, 22 Aug 2001 16:02:21 -0700 (PDT)
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7MN2JN28653 for <[e-mail]>; Wed, 22 Aug 2001 16:02:19 -0700 (PDT)
Received: from [63.73.97.181] (64.69.113.115) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.0.3) for <[e-mail]>; Wed, 22 Aug 2001 16:02:17 -0700
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0510033eb7a9e75acb61@[63.73.97.181]>
Date: Wed, 22 Aug 2001 15:52:12 -0700
To: [e-mail]
From: Jon Callas <[e-mail]>
Subject: Diffs for next draft
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Here's everything I have. If there's something you want me to do and I've
been obtuse, let me know again, and it'll get in. I'm planning on
submitting the draft in about 24 hours. I can always do another one when
something's omitted, so don't panic.

	Jon

3,6c3,6
< Category: INTERNET-DRAFT                  Counterpane Internet Security
< draft-ietf-openpgp-rfc2440bis-02.txt
< Expires Apr 2001                                       Lutz Donnerhacke
< October 2000                         IN-Root-CA Individual Network e.V.
---
> Category: INTERNET-DRAFT                       Wave Systems Corporation
> draft-ietf-openpgp-rfc2440bis-03.txt
> Expires Feb 2002                                       Lutz Donnerhacke
> August 2001                          IN-Root-CA Individual Network e.V.
15c15
<                  draft-ietf-openpgp-rfc2440bis-02.txt
---
>                  draft-ietf-openpgp-rfc2440bis-03.txt
18c18
< Copyright 2000 by The Internet Society. All Rights Reserved.
---
> Copyright 2001 by The Internet Society. All Rights Reserved.
400,401c400,401
< 15       -- Symmetrically Encrypted and Integrity Protected Data Packet
< 16       -- Modification Detection Code Packet
---
> 18       -- Symmetrically Encrypted and Integrity Protected Data Packet
> 19       -- Modification Detection Code Packet
530a531,540
> Algorithm Specific Fields for ElGamal signatures:
> .block on -
> MPI of ElGamal value a = g**k mod p.
> MPI of ElGamal value b = (h-a*x)/k mod p-1.
> .block off
>
> The hash h is PKCS-1 padded exactly the same way as for the above
> described RSA signatures.
>
>
537a548,550
> SHA256:     0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x01
> SHA384:     0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x02
> SHA512:     0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x03
545a559,561
> SHA256:     2.16.840.1.101.3.4.2.1
> SHA384:     2.16.840.1.101.3.4.2.2
> SHA512:     2.16.840.1.101.3.4.2.3
567a584,598
> .block blank
> SHA256:     0x30, 0x31, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86,
>             0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x01, 0x05,
>             0x00, 0x04, 0x20
>
> .block blank
> SHA384:     0x30, 0x41, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86,
>             0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x02, 0x05,
>             0x00, 0x04, 0x30
>
> .block blank
> SHA512:     0x30, 0x51, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86,
>             0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x03, 0x05,
>             0x00, 0x04, 0x40
>
765a797,799
> Since the user name space is in the form of an email address,
>implementors MAY wish to arrange for that address to reach a person who
>can be consulted about the use of the named tag.  Note that due to UTF-8
>encoding, not all valid user space name tags are valid email addresses.
>
>
852c886
< 1 - Modification Detection (packets 15 and 16)
---
> 1 - Modification Detection (packets 18 and 19)
863c897
< When a signature is made over a key, the hash data starts with the octet
0x99, followed by a two-octet length of the key, and then body of the key
packet. (Note that this is an old-style packet header for a key packet with
two-octet length.) A subkey signature (type 0x18) then hashes the subkey,
using the same format as the main key. Key revocation signatures (types
0x20 and 0x28) hash only the key being revoked.
---
> When a signature is made over a key, the hash data starts with the octet
>0x99, followed by a two-octet length of the key, and then body of the key
>packet. (Note that this is an old-style packet header for a key packet
>with two-octet length.) A subkey signature (type 0x18) then hashes the
>subkey, using the same format as the main key (also using 0x99 as the
>first octet). Key revocation signatures (types 0x20 and 0x28) hash only
>the key being revoked.
1071c1105,1106
< Two-octet checksum of the plaintext of the algorithm-specific portion
(sum of all octets, mod 65536).
---
> Two-octet checksum of the plaintext of the algorithm-specific portion
>(sum of all octets, mod 65536). This checksum is encrypted together with
>the algorithm- specific fields.
>
1172c1207
< .head 2 Sym. Encrypted Integrity Protected Data Packet (Tag 15)
---
> .head 2 Sym. Encrypted Integrity Protected Data Packet (Tag 18)
1204c1239
< .head 2 Modification Detection Code Packet (Tag 16)
---
> .head 2 Modification Detection Code Packet (Tag 19)
1523c1558
< Implementations MUST implement Triple-DES. Implementations SHOULD
implement IDEA and CAST5.Implementations MAY implement any other algorithm.
---
> Implementations MUST implement Triple-DES. Implementations SHOULD
>implement AES-128 and CAST5. Implementations that interoperate with PGP
>2.6 or earlier need to support IDEA, as that is the only symmetric cipher
>those versions use. Implementations MAY implement any other algorithm.
1545c1580
< 4          - Reserved for double-width SHA (experimental)
---
> 4          - Reserved for double-width SHA (experimental, obviated)
1548a1584,1586
> 8          - SHA256                                "SHA256"
> 9          - SHA384                                "SHA384"
> 10         - SHA512                                "SHA512"
1754c1792
< If an Elgamal key is to be used for both signing and encryption, extra
care must be taken in creating the key.
---
> If an Elgamal key [ELGAMAL] is to be used for both signing and
>encryption, extra care must be taken in creating the key.
1756c1794
< An ElGamal key consists of a generator g, a prime modulus p, a secret
exponent x, and a public value y = g^x mod p.
---
> An Elgamal key consists of a generator g, a prime modulus p, a secret
>exponent x, and a public value y = g^x mod p.
1764c1802
< Details on safe use of Elgamal signatures may be found in [MENEZES],
which discusses all the weaknesses described above.
---
> Details on safe use of Elgamal signatures may be found in [MENEZES],
>which discusses all the weaknesses described above. Please note that
>Elgamal signatures are controversial; because of the care that must be
>taken with Elgamal keys, many implementations forego them.
1915,1917c1953,1955
< Counterpane Internet Security, Inc.
< 3031 Tisch Way, suite 100 East Plaza
< San Jose, CA 95128, USA
---
> Wave Systems Corp.
> 1601 S. DeAnza Blvd, Suite 200
> Cupertino, CA 95014, USA
1920,1921c1958,1959
< Email: [e-mail], [e-mail]
< Tel: [phone]
---
> Email: [e-mail], [e-mail]
> Tel: [phone]
2059c2097
< Copyright 2000 by The Internet Society. All Rights Reserved.
---
> Copyright 2001 by The Internet Society. All Rights Reserved.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7MKfwE25681 for ietf-openpgp-bks; Wed, 22 Aug 2001 13:41:58 -0700 (PDT)
Received: from m11.jersey.juno.com (m11.jersey.juno.com [64.136.16.74]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7MKfuN25677 for <[e-mail]>; Wed, 22 Aug 2001 13:41:56 -0700 (PDT)
Received: from cookie.juno.com by cookie.juno.com for <"xS5dSbQuAOKnbKF9wbUrHCqlPsmm2A28qjg9yMlY1J5lhlkI6p24nQ==">
Received: (from [e-mail]) by m11.jersey.juno.com (queuemail) id GDGN48GD; Wed, 22 Aug 2001 16:40:48 EDT
To: [e-mail]
Cc: [e-mail], [e-mail]
Date: Wed, 22 Aug 2001 16:46:44 -0400
Subject: Re: PGP versions 5 and later / ciphertext-format query...../ ON_BREAK / No_rush_to_answer..........
Message-ID: <[e-mail]>
X-Mailer: Juno 5.0.33
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Juno-Line-Breaks: 0-2,4,6-8,10-11,13,15-17,19,21,23-32,34-76
From: Joe Tag <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Thank you for teaching me about the different versions of PGP, and about 
the Internet Draft process.  
As an adult student at Kean University, who has attended the 
U.S. National Colloquiem for Information Systems Security Education, as
well as
New York City-Information Systems Security Association meetings, I
apprecciate
the advice and tutoring this list offers. 

I am a "poor-man" ( LOL ), and I have a 386/25MHz machine, and a
486/33MHz computers
at home, with modems.  I only have 8MB RAM max, in each machine. 
At home, I have installed PGP5.0i for DOS.  I am aware I have to be
careful in the setup, and
the paths/subdirectories things are.  I have NO web/WWW access from home;
only dial-up to 
Juno. 

I can research (with some Computer Science professors tutelage) "internet
archives" 
(i.e.: alt.pgp.**x lists), and I have no problems browsing the web;
accessing while
at the Kean University campus (see http://www.kean.edu/~jtag and
http://www.kean.edu ) . 

I look forward to the replacement of TripleDES with Rijndael. 

Best regards, and thanks again! 

     Joe Tag,Jr. 

--- end --- 

On Wed, 22 Aug 2001 11:39:06 -0700 John  W Noerenberg II
<[e-mail]> writes:
> 
> At 7:53 PM +0200 8/21/01, Werner Koch wrote:
> >  > BTW: Why was Radix-64 developed; and what are the problems of 
> having
> >>  ciphertext
> >>  output as a hexadecimal file?
> >
> >Because it produces only an 33% overhead compared to the 100% 
> overhead
> >of plain hexdigits.
> >
> >We need to save some bandwidth so that we can use more funny mail
> >headers :-)
> 
> In addition to being more compact than hex digits, it uses a 
> character symbol set that is considered "safe" across all systems. 
> It 
> wouldn't do if the encoding method included characters that aren't 
> representable or whose numeric equivalent is ambiguous.
> 
> Bandwidth does matter -- even when the email headers are longer than 
> 
> the message....which is goofy, I know...which is why a message 
> saying 
> only "ok" or "thanks" may be polite, but not necessarily the most 
> efficient thing to do.
> 
> best,
> -- 
> 
> john noerenberg
> [e-mail]
>    
> ----------------------------------------------------------------------
>    If you don't even own your own name, how can you have
>    a sense of self-worth?
>      -- Simson Garfinkel, "Database Nation", 2000
>    
> ----------------------------------------------------------------------
> 


-----/signed/ Joe Tag,Jr.; Elizabeth, New Jersey, USA -----
________________________________________________________________
GET INTERNET ACCESS FROM JUNO!
Juno offers FREE or PREMIUM Internet access for less!
Join Juno today!  For your FREE software, visit:
http://dl.www.juno.com/get/tagj.


Received: by above.proper.com (8.11.3/8.11.3) id f7MIm3923501 for ietf-openpgp-bks; Wed, 22 Aug 2001 11:48:03 -0700 (PDT)
Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.65.64]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7MIm2N23497 for <[e-mail]>; Wed, 22 Aug 2001 11:48:02 -0700 (PDT)
Received: from [129.46.77.28] (dhcp236.qualcomm.com [129.46.77.28]) by mage.qualcomm.com (8.11.3/8.11.3/1.0) with ESMTP id f7MIm0C22459; Wed, 22 Aug 2001 11:48:00 -0700 (PDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100106b7a9aa01254e@[129.46.77.28]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-Mailer: eudora51-ffc10713011434
X-PGP-RSA-Fingerprint: EA53 01A6 C076 F9C2  09E8 9480 645A 8857
X-PGP-DH-Fingerprint: 4F5E 56C9 BD4D 0227 331F 6AEE 9590 24F9 6FD7 04F8
Date: Wed, 22 Aug 2001 11:39:06 -0700
To: Werner Koch <[e-mail]>
From: John  W Noerenberg II <[e-mail]>
Subject: Re: Preparing a new draft.../ PGP versions 5 and later / ciphertext-format query.....
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

At 7:53 PM +0200 8/21/01, Werner Koch wrote:
>  > BTW: Why was Radix-64 developed; and what are the problems of having
>>  ciphertext
>>  output as a hexadecimal file?
>
>Because it produces only an 33% overhead compared to the 100% overhead
>of plain hexdigits.
>
>We need to save some bandwidth so that we can use more funny mail
>headers :-)

In addition to being more compact than hex digits, it uses a 
character symbol set that is considered "safe" across all systems. It 
wouldn't do if the encoding method included characters that aren't 
representable or whose numeric equivalent is ambiguous.

Bandwidth does matter -- even when the email headers are longer than 
the message....which is goofy, I know...which is why a message saying 
only "ok" or "thanks" may be polite, but not necessarily the most 
efficient thing to do.

best,
-- 

john noerenberg
[e-mail]
   ----------------------------------------------------------------------
   If you don't even own your own name, how can you have
   a sense of self-worth?
     -- Simson Garfinkel, "Database Nation", 2000
   ----------------------------------------------------------------------


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7MIi6p23412 for ietf-openpgp-bks; Wed, 22 Aug 2001 11:44:06 -0700 (PDT)
Received: from kasiski.gnupg.de (porta.u64.de [194.77.88.106]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7MIi3N23407 for <[e-mail]>; Wed, 22 Aug 2001 11:44:03 -0700 (PDT)
Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.22 #1 (Debian)) id 15Zdqj-0007K6-00; Wed, 22 Aug 2001 21:39:37 +0200
Received: from wk by alberti.gnupg.de with local (Exim 3.22 #1 (Debian)) id 15Zd2F-0001yV-00; Wed, 22 Aug 2001 20:47:27 +0200
To: <[e-mail]>
Subject: Re: question on Self-Decrypting Messages !!!
References: <[e-mail]> <[e-mail]> <p05100337b7a9a64e832a@[63.73.97.181]>
From: Werner Koch <[e-mail]>
Organisation: g10 Code GmbH
X-PGP-KeyID: 621CC013
X-Request-PGP: finger://[e-mail]
Date: 22 Aug 2001 20:47:27 +0200
In-Reply-To: <p05100337b7a9a64e832a@[63.73.97.181]> (Jon Callas's message of "Wed, 22 Aug 2001 11:17:15 -0700")
Message-ID: <[e-mail]>
Lines: 18
User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Wed, 22 Aug 2001 11:17:15 -0700, Jon Callas said:

> -- it's probably simpler and easier to just drive over there. So you bundle
> the thing up in a Windows SDA, and email it to your accountant. Then you
> phone the accountant up, tell them the passphrase, and it unpacks your

Nice feature.  So I hope that my competitor uses such a scheme, I am
in the lucky position to have control over a part of the network used
to send the mail, I catch the message add a new feature to the
decrypting code and pass it on.  Some hours laters the trojan
installed on the tax accountant's box starts to send all the
confidential files to an anonymous account somewhere....


-- 
Werner Koch        Omnis enim res, quae dando non deficit, dum habetur
g10 Code GmbH      et non datur, nondum habetur, quomodo habenda est.
Privacy Solutions                                        -- Augustinus



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7MIIxO22877 for ietf-openpgp-bks; Wed, 22 Aug 2001 11:18:59 -0700 (PDT)
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7MIIvN22873 for <[e-mail]>; Wed, 22 Aug 2001 11:18:57 -0700 (PDT)
Received: from [63.73.97.181] (64.69.113.115) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.0.3); Wed, 22 Aug 2001 11:18:49 -0700
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100337b7a9a64e832a@[63.73.97.181]>
In-Reply-To: <[e-mail]>
References:  <[e-mail]> <[e-mail]>
Date: Wed, 22 Aug 2001 11:17:15 -0700
To: Werner Koch <[e-mail]>, <[e-mail]>
From: Jon Callas <[e-mail]>
Subject: Re: question on Self-Decrypting Messages !!!
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

At 8:46 AM +0200 8/22/01, Werner Koch wrote:
>
>Don't know what SDA is, but self-decrypting messages are a *very
>stupid* idea.  You receive such a message from soneone you don't know,
>you are not able to check the identity of the sender, otherwise you
>would have installed an OpenPGP implemnentation.  So what you do is to
>allow anyone who is able to send you a message to run arbitrary code
>on your box.  It may decrypt the message but you don't know what the
>code does on the side.
>

Well, the uses are limited, but they exist. The once or twice a year you
want them, they're nice. Here's a scenario:

Your tax accountant wants the records you have from your consulting
business do they can properly get your deductions done. Said accountant
can't spell PGP. You're not in the mood to drive an hour to get there, and
you're not in the mood to teach the accountant how to do it over the phone
-- it's probably simpler and easier to just drive over there. So you bundle
the thing up in a Windows SDA, and email it to your accountant. Then you
phone the accountant up, tell them the passphrase, and it unpacks your
files for them.

The general scenario is that you want to send a message to someone who
doesn't use crypto, and isn't going to regularly use it.

	Jon



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7MGTXf20455 for ietf-openpgp-bks; Wed, 22 Aug 2001 09:29:33 -0700 (PDT)
Received: from mercury.rus.uni-stuttgart.de (mercury.rus.uni-stuttgart.de [129.69.1.226]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7MGTWN20450 for <[e-mail]>; Wed, 22 Aug 2001 09:29:32 -0700 (PDT)
Received: from rusfw by mercury.rus.uni-stuttgart.de with local (Exim 3.22 #1) id 15Zasd-0004Zu-00; Wed, 22 Aug 2001 18:29:23 +0200
To: Joe Tag <[e-mail]>
Cc: [e-mail]
Subject: Re: Preparing a new draft.../ PGP versions 5 and later / ciphertext-format query.....
References: <[e-mail]>
From: Florian Weimer <[e-mail]>
Date: 22 Aug 2001 18:29:23 +0200
In-Reply-To: <[e-mail]> (Joe Tag's message of "Tue, 21 Aug 2001 13:23:44 -0400")
Message-ID: <[e-mail]>
Lines: 16
User-Agent: Gnus/5.090001 (Oort Gnus v0.01) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Joe Tag <[e-mail]> writes:

> I believe that PGP 5.0/5.0i is the MINIMUM BASIC version of the
> software that end-users should use.  That version is available for
> IBM PC-DOS/MS-DOS, and supports CAST/Diffie-Hellman, as well as
> IDEA/RSA algorithms and protocols.

PGP 5 has security-related problems and is not compatible with OpenPGP
either.

> BTW: Why was Radix-64 developed; and what are the problems of having
> ciphertext output as a hexadecimal file?

Hexadecimal streams encode 4 bits per character, while Radix-64
streams encode 6 bits per character, so a Radix-64 is somewhat shorter
than a hexadecimal stream.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7M6i7D07929 for ietf-openpgp-bks; Tue, 21 Aug 2001 23:44:07 -0700 (PDT)
Received: from kasiski.gnupg.de (porta.u64.de [194.77.88.106]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7M6i4N07918 for <[e-mail]>; Tue, 21 Aug 2001 23:44:05 -0700 (PDT)
Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.22 #1 (Debian)) id 15ZSbp-0006EX-00; Wed, 22 Aug 2001 09:39:29 +0200
Received: from wk by alberti.gnupg.de with local (Exim 3.22 #1 (Debian)) id 15ZRmF-0007C2-00; Wed, 22 Aug 2001 08:46:11 +0200
To: <[e-mail]>
Subject: Re: question on Self-Decrypting Messages !!!
References: <[e-mail]>
From: Werner Koch <[e-mail]>
Organisation: g10 Code GmbH
X-PGP-KeyID: 621CC013
X-Request-PGP: finger://[e-mail]
Date: 22 Aug 2001 08:46:11 +0200
In-Reply-To: <[e-mail]> ("Rezaul H. Safiuddin"'s message of "Tue, 21 Aug 2001 22:50:58 -0500 (CDT)")
Message-ID: <[e-mail]>
Lines: 38
User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Tue, 21 Aug 2001 22:50:58 -0500 (CDT), Rezaul H Safiuddin said:

>  If I encrypt a message and send it to someone who doesn't use PGP, I have
>  to use SDA, and somehow give them the password to it, right ?

Don't know what SDA is, but self-decrypting messages are a *very
stupid* idea.  You receive such a message from soneone you don't know,
you are not able to check the identity of the sender, otherwise you
would have installed an OpenPGP implemnentation.  So what you do is to
allow anyone who is able to send you a message to run arbitrary code
on your box.  It may decrypt the message but you don't know what the
code does on the side.

Okay, you can check that the executable part of that message is
identical to a trusted copy you have - but so why don't use your copy
right away.  You need a shared passphrase, this indicates that you
have established a communication link to the sender by another way -
why not also installing regular software.

You can have some software installed on your box which analyzes the
self-decrypting message and compares the executable part with a known
checksum.  I can see no advantages for such a program because it will
have about the same complexity as a normal decrypting software.

And a self-decrypting thing will never be able to check a signature.

All these self-foo things have another major drawback:  They are only
able to do their job on one platform (i.e. CPU and OS).

Ciao,

  Werner


-- 
Werner Koch        Omnis enim res, quae dando non deficit, dum habetur
g10 Code GmbH      et non datur, nondum habetur, quomodo habenda est.
Privacy Solutions                                        -- Augustinus



Received: by above.proper.com (8.11.3/8.11.3) id f7M3ovV24192 for ietf-openpgp-bks; Tue, 21 Aug 2001 20:50:57 -0700 (PDT)
Received: from cs.utexas.edu ([e-mail] [128.83.139.9]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7M3otN24187 for <[e-mail]>; Tue, 21 Aug 2001 20:50:55 -0700 (PDT)
Received: from cottonmouth.cs.utexas.edu ([e-mail] [128.83.144.146]) by cs.utexas.edu (8.11.2/8.11.2) with ESMTP id f7M3owN05697 for <[e-mail]>; Tue, 21 Aug 2001 22:50:59 -0500 (CDT)
Received: (from kashif@localhost) by cottonmouth.cs.utexas.edu (8.9.3/8.9.3) id WAA14507; Tue, 21 Aug 2001 22:50:58 -0500
Date: Tue, 21 Aug 2001 22:50:58 -0500 (CDT)
From: "Rezaul H. Safiuddin" <[e-mail]>
To: <[e-mail]>
Subject: question on Self-Decrypting Messages !!!
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

 If I encrypt a message and send it to someone who doesn't use PGP, I have
 to use SDA, and somehow give them the password to it, right ?

 Is this secured and protected the same way  as Digitally signed and
 encrypted messages that someone who has PGP would receive ?

 I am a newbie in this thing, any help and explanation will be appreciated.
 Also, what's the best way to encrypt mails if I am using 'hotmail' or
 'yahoo' ?

 Thanks  a lot.





Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7LHo3U09409 for ietf-openpgp-bks; Tue, 21 Aug 2001 10:50:03 -0700 (PDT)
Received: from kasiski.gnupg.de (porta.u64.de [194.77.88.106]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7LHo0N09405 for <[e-mail]>; Tue, 21 Aug 2001 10:50:00 -0700 (PDT)
Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.22 #1 (Debian)) id 15ZGWf-00057d-00; Tue, 21 Aug 2001 20:45:21 +0200
Received: from wk by alberti.gnupg.de with local (Exim 3.22 #1 (Debian)) id 15ZFis-00065o-00; Tue, 21 Aug 2001 19:53:54 +0200
To: [e-mail]
Subject: Re: Preparing a new draft.../ PGP versions 5 and later / ciphertext-format query.....
References: <[e-mail]>
From: Werner Koch <[e-mail]>
Organisation: g10 Code GmbH
X-PGP-KeyID: 621CC013
X-Request-PGP: finger://[e-mail]
Date: 21 Aug 2001 19:53:54 +0200
In-Reply-To: <[e-mail]> (Joe Tag's message of "Tue, 21 Aug 2001 13:23:44 -0400")
Message-ID: <[e-mail]>
Lines: 26
User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Tue, 21 Aug 2001 13:23:44 -0400, Joe Tag said:

> I believe that PGP 5.0/5.0i is the MINIMUM BASIC version of the software
> that

With the drawback that it far away from OpenPGP compliant and has a
lot of security issues.

> BTW: Why was Radix-64 developed; and what are the problems of having
> ciphertext
> output as a hexadecimal file? 

Because it produces only an 33% overhead compared to the 100% overhead
of plain hexdigits.

We need to save some bandwidth so that we can use more funny mail
headers :-)

Ciao,

  Werner

-- 
Werner Koch        Omnis enim res, quae dando non deficit, dum habetur
g10 Code GmbH      et non datur, nondum habetur, quomodo habenda est.
Privacy Solutions                                        -- Augustinus



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7LHk3c09300 for ietf-openpgp-bks; Tue, 21 Aug 2001 10:46:03 -0700 (PDT)
Received: from kasiski.gnupg.de (porta.u64.de [194.77.88.106]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7LHk1N09296 for <[e-mail]>; Tue, 21 Aug 2001 10:46:01 -0700 (PDT)
Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.22 #1 (Debian)) id 15ZGSn-00057I-00; Tue, 21 Aug 2001 20:41:21 +0200
Received: from wk by alberti.gnupg.de with local (Exim 3.22 #1 (Debian)) id 15ZFeW-00065I-00; Tue, 21 Aug 2001 19:49:24 +0200
To: <[e-mail]>
Subject: Re: mdc
References: <[e-mail]>
From: Werner Koch <[e-mail]>
Organisation: g10 Code GmbH
X-PGP-KeyID: 621CC013
X-Request-PGP: finger://[e-mail]
Date: 21 Aug 2001 19:49:24 +0200
In-Reply-To: <[e-mail]> ("vedaal"'s message of "Tue, 21 Aug 2001 13:13:56 -0400")
Message-ID: <[e-mail]>
Lines: 19
User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Tue, 21 Aug 2001 13:13:56 -0400, vedaal  said:

> how does using MDC protect the sender/recipient more than the signing and
> encrypting of the message?

Many users don't bother to check the signature, there are a lot of
situations where you do not wnat to sign a message: think Mixmaster.

And an MDC is the cleaner and correct solution to fix a flaw in the
encryption layer.

Ciao,

  Werner

-- 
Werner Koch        Omnis enim res, quae dando non deficit, dum habetur
g10 Code GmbH      et non datur, nondum habetur, quomodo habenda est.
Privacy Solutions                                        -- Augustinus



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7LHI0F08652 for ietf-openpgp-bks; Tue, 21 Aug 2001 10:18:00 -0700 (PDT)
Received: from m11.jersey.juno.com (m11.jersey.juno.com [64.136.16.74]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7LHHxN08648 for <[e-mail]>; Tue, 21 Aug 2001 10:17:59 -0700 (PDT)
Received: from cookie.juno.com by cookie.juno.com for <"xS5dSbQuAOKnbKF9wbUrHOpHJaldcuo0WkT/2Kl94BAze7EFYEPgaQ==">
Received: (from [e-mail]) by m11.jersey.juno.com (queuemail) id GDDQ4SFU; Tue, 21 Aug 2001 13:17:47 EDT
To: [e-mail]
Cc: [e-mail]
Date: Tue, 21 Aug 2001 13:23:44 -0400
Subject: Re: Preparing a new draft.../ PGP versions 5 and later / ciphertext-format query.....
Message-ID: <[e-mail]>
X-Mailer: Juno 5.0.33
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Juno-Line-Breaks: 1,3,5-7,9-13,15-37
From: Joe Tag <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

I believe that PGP 5.0/5.0i is the MINIMUM BASIC version of the software
that
end-users should use.  That version is available for IBM PC-DOS/MS-DOS,
and 
supports CAST/Diffie-Hellman, as well as IDEA/RSA algorithms and
protocols. 


BTW: Why was Radix-64 developed; and what are the problems of having
ciphertext
output as a hexadecimal file? 

/signed/ Joe Tag,Jr. 

On 21 Aug 2001 17:54:28 +0200 Florian Weimer
<[e-mail]> writes:
> 
> Jon Callas <[e-mail]> writes:
> 
> > I agree with you that in a perfect world we'd make it mandatory, 
> but people
> > would howl if we did. If we want to move to that as a goal, step 
> one is to
> > deprecate 2.6.
> 
> You could at least mark it 'obsolescent'. ;-)
> 
> -- 
> Florian Weimer                           
> [e-mail]
> University of Stuttgart           http://cert.uni-stuttgart.de/
> RUS-CERT                          [phone]/fax 
> [phone]
> 

http://www.kean.edu/~jtag


-----/signed/ Joe Tag,Jr.; Elizabeth, New Jersey, USA -----
________________________________________________________________
GET INTERNET ACCESS FROM JUNO!
Juno offers FREE or PREMIUM Internet access for less!
Join Juno today!  For your FREE software, visit:
http://dl.www.juno.com/get/tagj.


Received: by above.proper.com (8.11.3/8.11.3) id f7LHFRb08613 for ietf-openpgp-bks; Tue, 21 Aug 2001 10:15:27 -0700 (PDT)
Received: from hotmail.com (oe34.law3.hotmail.com [209.185.240.202]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7LHFPN08608 for <[e-mail]>; Tue, 21 Aug 2001 10:15:25 -0700 (PDT)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 21 Aug 2001 10:15:22 -0700
X-Originating-IP: [207.127.12.210]
From: "vedaal" <[e-mail]>
To: <[e-mail]>
Subject: mdc
Date: Tue, 21 Aug 2001 13:13:56 -0400
MIME-Version: 1.0
Content-Type: text/plain;	charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 21 Aug 2001 17:15:22.0914 (UTC) FILETIME=[DC982820:01C12A64]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

assuming that a sender has signed and encrypted a message,

how does using MDC protect the sender/recipient more than the signing and
encrypting of the message?

what tampering can be done with the message that the recipient would not
detect unless mdc were used?

{have read rfc-2440 bis, sections 5.12 and 5.13, but did not understand the
practical security advantages
over signing and encrypting}

tia for any clarifications,

vedaal


Received: by above.proper.com (8.11.3/8.11.3) id f7LFsZF05800 for ietf-openpgp-bks; Tue, 21 Aug 2001 08:54:35 -0700 (PDT)
Received: from mercury.rus.uni-stuttgart.de (mercury.rus.uni-stuttgart.de [129.69.1.226]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7LFsYN05793 for <[e-mail]>; Tue, 21 Aug 2001 08:54:34 -0700 (PDT)
Received: from rusfw by mercury.rus.uni-stuttgart.de with local (Exim 3.22 #1) id 15ZDrI-0005qu-00 for [e-mail]; Tue, 21 Aug 2001 17:54:28 +0200
To: [e-mail]
Subject: Re: Preparing a new draft...
References: <p05100311b7a70e684cea@[63.73.97.181]> <[e-mail]> <p05100312b7a72af401ee@[63.73.97.181]>
From: Florian Weimer <[e-mail]>
Date: 21 Aug 2001 17:54:28 +0200
In-Reply-To: <p05100312b7a72af401ee@[63.73.97.181]> (Jon Callas's message of "Mon, 20 Aug 2001 14:15:13 -0700")
Message-ID: <[e-mail]>
Lines: 12
User-Agent: Gnus/5.090001 (Oort Gnus v0.01) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Jon Callas <[e-mail]> writes:

> I agree with you that in a perfect world we'd make it mandatory, but people
> would howl if we did. If we want to move to that as a goal, step one is to
> deprecate 2.6.

You could at least mark it 'obsolescent'. ;-)

-- 
Florian Weimer 	                  [e-mail]
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          [phone]/fax [phone]


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7LAc4J16125 for ietf-openpgp-bks; Tue, 21 Aug 2001 03:38:04 -0700 (PDT)
Received: from kasiski.gnupg.de (porta.u64.de [194.77.88.106]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7LAc2N16121 for <[e-mail]>; Tue, 21 Aug 2001 03:38:02 -0700 (PDT)
Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.22 #1 (Debian)) id 15Z9mW-0004MT-00; Tue, 21 Aug 2001 13:33:16 +0200
Received: from wk by alberti.gnupg.de with local (Exim 3.22 #1 (Debian)) id 15Z8xp-0005QR-00; Tue, 21 Aug 2001 12:40:53 +0200
To: Jon Callas <[e-mail]>
Cc: [e-mail]
Subject: Re: Preparing a new draft...
References: <p05100311b7a70e684cea@[63.73.97.181]> <[e-mail]> <p05100312b7a72af401ee@[63.73.97.181]>
From: Werner Koch <[e-mail]>
Organisation: g10 Code GmbH
X-PGP-KeyID: 621CC013
X-Request-PGP: finger:[e-mail]
Date: 21 Aug 2001 12:40:53 +0200
In-Reply-To: <p05100312b7a72af401ee@[63.73.97.181]> (Jon Callas's message of "Mon, 20 Aug 2001 14:15:13 -0700")
Message-ID: <[e-mail]>
Lines: 39
User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Mon, 20 Aug 2001 14:15:13 -0700, Jon Callas said:

> Oh, yes, yes, yes. They are optional. The mandatory algorithms will not
> change from 2440. They are, however, needed to balance with the newer
> ciphers, or public keys bigger than 1024 bits.

Can you check that we don't have 1024 bit limit for DSA keys in
OpenPGP.

> Yeah, I know you did, and I still think it's a hack. A clever hack, but a
> hack. But hey, that's the difference between a standard and an
> implementation. You're perfectly free to do that.

Yeah.  And it is good that it is just a SHOULD rule ;-)

> I don't know, though, that will ever make the use of MDC mandatory. That
> would break backwards compatibility with anything that's gone before you.

Okay.  An implemenation can print a warning if a non MDC is used.

> I'm still incredulous that there are people who steadfastly cling to 2.6!
> At HAL2001, there were people who *still* adamantly insist that 2.6 is the
> only trustworthy PGP version. I don't get it, but I respect it. And hey,

I know and can't count the mails I wrote on the interoperability
problems due to no IDEA in GnuPG and to explain the advantages of
OpenPGP :-(

> would howl if we did. If we want to move to that as a goal, step one is to
> deprecate 2.6.

And of equal importance is to use PGP/MIME.

  Werner

-- 
Werner Koch        Omnis enim res, quae dando non deficit, dum habetur
g10 Code GmbH      et non datur, nondum habetur, quomodo habenda est.
Privacy Solutions                                        -- Augustinus



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7L4G2210140 for ietf-openpgp-bks; Mon, 20 Aug 2001 21:16:02 -0700 (PDT)
Received: from sand.cyberia.net.lb (sand.cyberia.net.lb [195.112.195.68]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7L4FjN10133 for <[e-mail]>; Mon, 20 Aug 2001 21:16:00 -0700 (PDT)
Received: from irfc ([195.112.205.183]) by sand.cyberia.net.lb with SMTP id <20010821041218.SFQH507.sand@irfc> for <[e-mail]>; Tue, 21 Aug 2001 07:12:18 +0300
From: "Imad R. Faiad" <[e-mail]>
To: [e-mail]
Subject: Re: Preparing a new draft...
Date: Tue, 21 Aug 2001 07:16:54 +0200
Message-ID: <[e-mail]>
References: <p05100311b7a70e684cea@[63.73.97.181]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Mailer: Forte Agent 1.8/32.548
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id f7L4G1N10137
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On 20 Aug 2001 22:07:29 +0200, you wrote:

>
>On Mon, 20 Aug 2001 12:09:04 -0700, Jon Callas said:
>
<snip>
>Regarding MDC: PGP and GnuPG both implement MDC but without the use of
>the features flag.  A long time ago I agreed with Hal to use MDC with
>all algorithms having a blocksizes > 64 (i.e. Twofish and AES).  From
>our knowledge no other application did use one of those algorithms at
>that time.   IMHO, it would be good to stress it even more that the
>MDC packets should be used and that it can be expected that future
>revisions of OpenPGP will make the use of MDC mandatory.
>
PGP does not generate MDC packets, it will however interpret them.

Since MDC's are too new, not mandatory, and may cause an application which
does not implement them to fail to decode, a responsible implementor
should not generate such packets unless otherwise instructed by the user.

Remember, the User Is King, the Implementor is not!

my 2c

>Ciao,
>
>  Werner



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7KLLP301688 for ietf-openpgp-bks; Mon, 20 Aug 2001 14:21:25 -0700 (PDT)
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7KLLNN01684 for <[e-mail]>; Mon, 20 Aug 2001 14:21:23 -0700 (PDT)
Received: from [63.73.97.181] (64.69.113.115) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.0.3); Mon, 20 Aug 2001 14:21:16 -0700
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100312b7a72af401ee@[63.73.97.181]>
In-Reply-To: <[e-mail]>
References: <p05100311b7a70e684cea@[63.73.97.181]> <[e-mail]>
Date: Mon, 20 Aug 2001 14:15:13 -0700
To: Werner Koch <[e-mail]>
From: Jon Callas <[e-mail]>
Subject: Re: Preparing a new draft...
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

At 10:07 PM +0200 8/20/01, Werner Koch wrote:
>On Mon, 20 Aug 2001 12:09:04 -0700, Jon Callas said:
>
>> I think we agreed that we should add in SHA256, SHA384, and SHA512. Does
>> anyone disagree?
>
>Please mark them as optional.  We should also figure out the new DSA
>parameters to be used with those hashes.  Ist there anything available
>from NIST?  I didn't follow the development very closely.
>

Oh, yes, yes, yes. They are optional. The mandatory algorithms will not
change from 2440. They are, however, needed to balance with the newer
ciphers, or public keys bigger than 1024 bits.

>> Do people here want to see diffs of my source before I submit the draft? (I
>
>Pretty please.
>

Will do, then.

>Regarding MDC: PGP and GnuPG both implement MDC but without the use of
>the features flag.  A long time ago I agreed with Hal to use MDC with
>all algorithms having a blocksizes > 64 (i.e. Twofish and AES).  From
>our knowledge no other application did use one of those algorithms at
>that time.   IMHO, it would be good to stress it even more that the
>MDC packets should be used and that it can be expected that future
>revisions of OpenPGP will make the use of MDC mandatory.
>

Yeah, I know you did, and I still think it's a hack. A clever hack, but a
hack. But hey, that's the difference between a standard and an
implementation. You're perfectly free to do that.

I don't know, though, that will ever make the use of MDC mandatory. That
would break backwards compatibility with anything that's gone before you.
I'm still incredulous that there are people who steadfastly cling to 2.6!
At HAL2001, there were people who *still* adamantly insist that 2.6 is the
only trustworthy PGP version. I don't get it, but I respect it. And hey,
I'll admit that I'm still using PGP 6.5 when I'm on OS9, but GPG 1.0.6 on
OSX.

I agree with you that in a perfect world we'd make it mandatory, but people
would howl if we did. If we want to move to that as a goal, step one is to
deprecate 2.6.

	Jon


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7KKduO00608 for ietf-openpgp-bks; Mon, 20 Aug 2001 13:39:56 -0700 (PDT)
Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.65.64]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7KKdtN00603 for <[e-mail]>; Mon, 20 Aug 2001 13:39:55 -0700 (PDT)
Received: from [129.46.77.28] (dhcp236.qualcomm.com [129.46.77.28]) by mage.qualcomm.com (8.11.3/8.11.3/1.0) with ESMTP id f7KKdtC09700; Mon, 20 Aug 2001 13:39:55 -0700 (PDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100108b7a7238f6d80@[129.46.77.28]>
In-Reply-To: <p05100311b7a70e684cea@[63.73.97.181]>
References: <p05100311b7a70e684cea@[63.73.97.181]>
X-Mailer: eudora51-ffc10713011434
X-PGP-RSA-Fingerprint: EA53 01A6 C076 F9C2  09E8 9480 645A 8857
X-PGP-DH-Fingerprint: 4F5E 56C9 BD4D 0227 331F 6AEE 9590 24F9 6FD7 04F8
Date: Mon, 20 Aug 2001 13:29:51 -0700
To: Jon Callas <[e-mail]>
From: John  W Noerenberg II <[e-mail]>
Subject: Re: Preparing a new draft...
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

At 12:09 PM -0700 8/20/01, Jon Callas wrote:
>
>I'm going through things needed to put in a new draft, and looking at the
>last few months of comments to see what I should add.

Let's start thinking in terms of this draft as the one that will be 
submitted for DRAFT status of 2440.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7KKa8100553 for ietf-openpgp-bks; Mon, 20 Aug 2001 13:36:08 -0700 (PDT)
Received: from dolk.extundo.com (dolk.extundo.com [195.42.214.242]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7KKa5N00548 for <[e-mail]>; Mon, 20 Aug 2001 13:36:06 -0700 (PDT)
Received: from barbar.josefsson.org (slipsten.extundo.com [195.42.214.241]) (authenticated) by dolk.extundo.com (8.11.3/8.11.3) with ESMTP id f7KKaDw26820; Mon, 20 Aug 2001 22:36:13 +0200
To: Derek Atkins <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: About User-ID's
References: <[e-mail]> <[e-mail]>
From: Simon Josefsson <[e-mail]>
In-Reply-To: <[e-mail]> (Derek Atkins's message of "20 Aug 2001 13:43:17 -0400")
Date: Mon, 20 Aug 2001 22:35:57 +0200
Message-ID: <[e-mail]>
Lines: 36
User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.0.104
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

You can publish PGP keys in DNS right now if you like, see RFC 2538.

Since not every PGP user is trusted with maintaining the DNS
information for the zone where she lives in, I've been thinking about
PGP key "hosting" in DNS.  E.g., it would be possible to publish PGP
keys in DNS on behalf of others as "simon.josefsson.org.dnskeys.pgp.net".

One problem with publishing my PGP key under simon.josefsson.org is
that I already store my S/MIME cert there....  To save bandwidth, it
has been suggested that you could use e.g. "simon._pgp.josefsson.org"
(the dummy _pgp domain is inserted where the `@' is).

Derek Atkins <[e-mail]> writes:

> Who said it was necessary.  I was only suggesting it as one approach.
> One of the benefits we can get by leveraging DNS is that key service
> can be distributed.
>
> -derek
>
> Michael Helm <[e-mail]> writes:
>
>> Derek Atkins writes:
>> > One solution would be to put PGP Keys (Certificates) into DNS.  Then
>> > you could easily lookup a key based on the userID, but you have to
>> > already KNOW the userID.  Unfortunately this doesn't help you lookup
>> > a key by KeyID.
>> 
>> Why is it necessary to put certs into dns in order to accomplish
>> this end?
>
> -- 
>        Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
>        Member, MIT Student Information Processing Board  (SIPB)
>        URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
>        [e-mail]                        PGP key available



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7KK47x29888 for ietf-openpgp-bks; Mon, 20 Aug 2001 13:04:07 -0700 (PDT)
Received: from kasiski.gnupg.de (porta.u64.de [194.77.88.106]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7KK45N29881 for <[e-mail]>; Mon, 20 Aug 2001 13:04:05 -0700 (PDT)
Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.22 #1 (Debian)) id 15Yw8a-0002wQ-00; Mon, 20 Aug 2001 22:59:08 +0200
Received: from wk by alberti.gnupg.de with local (Exim 3.22 #1 (Debian)) id 15YvKc-00047I-00; Mon, 20 Aug 2001 22:07:30 +0200
To: Jon Callas <[e-mail]>
Cc: [e-mail]
Subject: Re: Preparing a new draft...
References: <p05100311b7a70e684cea@[63.73.97.181]>
From: Werner Koch <[e-mail]>
Organisation: g10 Code GmbH
X-PGP-KeyID: 621CC013
X-Request-PGP: finger:[e-mail]
Date: 20 Aug 2001 22:07:29 +0200
In-Reply-To: <p05100311b7a70e684cea@[63.73.97.181]> (Jon Callas's message of "Mon, 20 Aug 2001 12:09:04 -0700")
Message-ID: <[e-mail]>
Lines: 32
User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Mon, 20 Aug 2001 12:09:04 -0700, Jon Callas said:

> I think we agreed that we should add in SHA256, SHA384, and SHA512. Does
> anyone disagree?

Please mark them as optional.  We should also figure out the new DSA
parameters to be used with those hashes.  Ist there anything available
from NIST?  I didn't follow the development very closely.

> Do people here want to see diffs of my source before I submit the draft? (I

Pretty please.

> I'd like to get this one out ASAP, because I stupidly didn't get it out a
> long time ago with the correct packet numbers for MDC, and I feel badly

Regarding MDC: PGP and GnuPG both implement MDC but without the use of
the features flag.  A long time ago I agreed with Hal to use MDC with
all algorithms having a blocksizes > 64 (i.e. Twofish and AES).  From
our knowledge no other application did use one of those algorithms at
that time.   IMHO, it would be good to stress it even more that the
MDC packets should be used and that it can be expected that future
revisions of OpenPGP will make the use of MDC mandatory.

Ciao,

  Werner

-- 
Werner Koch        Omnis enim res, quae dando non deficit, dum habetur
g10 Code GmbH      et non datur, nondum habetur, quomodo habenda est.
Privacy Solutions                                        -- Augustinus



Received: by above.proper.com (8.11.3/8.11.3) id f7KJCCu28518 for ietf-openpgp-bks; Mon, 20 Aug 2001 12:12:12 -0700 (PDT)
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7KJC9N28509 for <[e-mail]>; Mon, 20 Aug 2001 12:12:09 -0700 (PDT)
Received: from [63.73.97.181] (64.69.113.115) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.0.3) for <[e-mail]>; Mon, 20 Aug 2001 12:11:34 -0700
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100311b7a70e684cea@[63.73.97.181]>
Date: Mon, 20 Aug 2001 12:09:04 -0700
To: [e-mail]
From: Jon Callas <[e-mail]>
Subject: Preparing a new draft...
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

I'm going through things needed to put in a new draft, and looking at the
last few months of comments to see what I should add.

I think we agreed that we should add in SHA256, SHA384, and SHA512. Does
anyone disagree?

Do people here want to see diffs of my source before I submit the draft? (I
use a Perl formatting program that uses a RUNOFF/roff-like markup language
to produce the actual copy. Sending diffs of the final output is less fun
than it could be, but the source doesn't know page numbers or even section
numbers. On the other hand, it's pretty easy to see the actual changes.)

I'd like to get this one out ASAP, because I stupidly didn't get it out a
long time ago with the correct packet numbers for MDC, and I feel badly
about that. Producing actual drafts if a new one is needed is easy. It's
the figuring out what should go in it that's trouble.

	Jon


Received: by above.proper.com (8.11.3/8.11.3) id f7KITvB27499 for ietf-openpgp-bks; Mon, 20 Aug 2001 11:29:57 -0700 (PDT)
Received: from rcn.ihtfp.org ([e-mail] [204.107.200.33]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7KITtN27494 for <[e-mail]>; Mon, 20 Aug 2001 11:29:56 -0700 (PDT)
Received: (from warlord@localhost) by rcn.ihtfp.org (8.9.3) id OAA29532; Mon, 20 Aug 2001 14:29:44 -0400
To: [e-mail]
Cc: [e-mail]
Subject: Re: About User-ID's
References: <[e-mail]>
From: Derek Atkins <[e-mail]>
Date: 20 Aug 2001 14:29:43 -0400
In-Reply-To: Michael Helm's message of "Mon, 20 Aug 2001 10:57:59 -0700"
Message-ID: <[e-mail]>
Lines: 44
X-Mailer: Gnus v5.5/Emacs 20.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Michael Helm <[e-mail]> writes:

> > > > One solution would be to put PGP Keys (Certificates) into DNS.  Then
> 
> makes the linkage look  like a mandatory requirement.

No, it's not a requirement.  The phrase "one solution" means "this is
one approach" implying there are others.

> Am I right that that anything that accomplishes this is ok

Well, yes, but I would still like to see a distributed solution come
sooner rather than later.

> What kinds of uses would cause someone to look up keys w/o knowing
> the user id, or other handle on the key, first? 

Well, I was recently looking for a friend's key because I knew he
changed jobs and his old email address didn't work.  So I searched on
last name to try to find him.  However, I probably could have used
other search methods to do that as well.

Most of the time mailcrypt will just fetch the key using the full
email address.

Perhaps searches should be limited to full-word, lhs queries (so you
can't query on 'mit.edu' but you could query on 'warlord', 'derek',
and 'atkins').  I will note that using DNS loses the ability to do
partial searches; you could only 'search' by full email.

> > One of the benefits we can get by leveraging DNS is that key service
> > can be distributed.
> 
> Let 's not worry about distributability for the  moment.

True, distributability is a separable problem.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [e-mail]                        PGP key available


Received: by above.proper.com (8.11.3/8.11.3) id f7KHvwu26659 for ietf-openpgp-bks; Mon, 20 Aug 2001 10:57:58 -0700 (PDT)
Received: from fionn.es.net (fionn.es.net [198.128.1.30]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7KHvvN26655 for <[e-mail]>; Mon, 20 Aug 2001 10:57:57 -0700 (PDT)
Received: from fionn.es.net (localhost.es.net [127.0.0.1]) by fionn.es.net (LBNLMWH19/LBNLMWH11/ESOCF2) with ESMTP id KAA06833 for <[e-mail]>; Mon, 20 Aug 2001 10:57:59 -0700 (PDT)
Message-Id: <[e-mail]>
X-Authentication-Warning: fionn.es.net: Host localhost.es.net [127.0.0.1] claimed to be fionn.es.net
To: [e-mail]
Reply-to: [e-mail]
Subject: Re: About User-ID's 
In-reply-to: Your message of "20 Aug 2001 13:43:17 EDT." <[e-mail]> 
Date: Mon, 20 Aug 2001 10:57:59 -0700
From: Michael Helm <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Derek Atkins writes:
> Who said it was necessary.  I was only suggesting it as one approach.

This statement

> > > One solution would be to put PGP Keys (Certificates) into DNS.  Then

makes the linkage look  like a mandatory requirement.

Am I right that that anything that accomplishes this is ok

> > > you could easily lookup a key based on the userID, but you have to
> > > already KNOW the userID.  Unfortunately this doesn't help you lookup

(ie this is the  real requirement?)  We could do this by changing the
query rules on the http and ldap servers I would think.
[How] Does this render the servers unusable? What about the distributions
of pre-built databases (I am one of those).

What kinds of uses would cause someone to look up keys w/o knowing
the user id, or other handle on the key, first? 

> One of the benefits we can get by leveraging DNS is that key service
> can be distributed.

Let 's not worry about distributability for the  moment.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7KHhKk26352 for ietf-openpgp-bks; Mon, 20 Aug 2001 10:43:20 -0700 (PDT)
Received: from rcn.ihtfp.org ([e-mail] [204.107.200.33]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7KHhIN26346 for <[e-mail]>; Mon, 20 Aug 2001 10:43:19 -0700 (PDT)
Received: (from warlord@localhost) by rcn.ihtfp.org (8.9.3) id NAA29471; Mon, 20 Aug 2001 13:43:17 -0400
To: [e-mail]
Cc: [e-mail]
Subject: Re: About User-ID's
References: <[e-mail]>
From: Derek Atkins <[e-mail]>
Date: 20 Aug 2001 13:43:17 -0400
In-Reply-To: Michael Helm's message of "Mon, 20 Aug 2001 10:20:22 -0700"
Message-ID: <[e-mail]>
Lines: 22
X-Mailer: Gnus v5.5/Emacs 20.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Who said it was necessary.  I was only suggesting it as one approach.
One of the benefits we can get by leveraging DNS is that key service
can be distributed.

-derek

Michael Helm <[e-mail]> writes:

> Derek Atkins writes:
> > One solution would be to put PGP Keys (Certificates) into DNS.  Then
> > you could easily lookup a key based on the userID, but you have to
> > already KNOW the userID.  Unfortunately this doesn't help you lookup
> > a key by KeyID.
> 
> Why is it necessary to put certs into dns in order to accomplish
> this end?

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [e-mail]                        PGP key available


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7KHUM726081 for ietf-openpgp-bks; Mon, 20 Aug 2001 10:30:22 -0700 (PDT)
Received: from mail.arcor-ip.de (mail.arcor-ip.de [145.253.2.10] (may be forged)) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7KHUJN26076 for <[e-mail]>; Mon, 20 Aug 2001 10:30:20 -0700 (PDT)
Received: from localhost (145.254.154.195) by mail.arcor-ip.de (5.5.034) id 3B80DF0F0000F29B; Mon, 20 Aug 2001 19:29:31 +0200
Received: by localhost (Postfix, from userid 500) id 57ECD49; Mon, 20 Aug 2001 19:33:41 +0200 (CEST)
Date: Mon, 20 Aug 2001 19:33:41 +0200
From: Ingo Luetkebohle <[e-mail]>
To: Michael Young <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: About User-ID's
Message-ID: <[e-mail]>
References: <[e-mail]> <001c01c12989$e3050560$[e-mail]>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="rwEMma7ioTxnRzrJ"
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <001c01c12989$e3050560$[e-mail]>; from [e-mail] on Mon, Aug 20, 2001 at 11:07:53AM -0400
Organization: Maybe when I grow up
X-URL: http://blank.pages.de/
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

--rwEMma7ioTxnRzrJ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Aug 20, 2001 at 11:07:53AM -0400, Michael Young wrote:
> If you remove or irreversibly alter the UserID material,

Altering the *real* UserID material is probably not a good
idea. However, you can do a lot on the presentation layer. A keyserver
could allow searching for e-mail addresses (even with substring
search) but not *display* them (or display them in a mangled way).

This helps prevent "tree walking" because knowledge of the content
would be required to retrieve it.

Regards

--=20
	Ingo Luetkebohle / [e-mail] / Student of Bioinformatics
/
| Cross-Platform OpenPGP: http://xpg.sourceforge.net/
|
| Fargonauten.DE sysadmin; Gimp Registry maintainer;
| FP: 3187 4DEC 47E6 1B1E 6F4F  57D4 CD90 C164 34AD CE5B

--rwEMma7ioTxnRzrJ
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Weitere Infos: siehe http://www.gnupg.org

iEYEAREBAAYFAjuBSfUACgkQzZDBZDStzls/2gCeNHpJDYFLK1SCBit0cONVypK6
t6UAnAgYBEmhGQFqI0EedP1iRs65XB+9
=tcxT
-----END PGP SIGNATURE-----

--rwEMma7ioTxnRzrJ--


Received: by above.proper.com (8.11.3/8.11.3) id f7KHKLG25832 for ietf-openpgp-bks; Mon, 20 Aug 2001 10:20:21 -0700 (PDT)
Received: from fionn.es.net (fionn.es.net [198.128.1.30]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7KHKKN25824 for <[e-mail]>; Mon, 20 Aug 2001 10:20:20 -0700 (PDT)
Received: from fionn.es.net (localhost.es.net [127.0.0.1]) by fionn.es.net (LBNLMWH19/LBNLMWH11/ESOCF2) with ESMTP id KAA05399 for <[e-mail]>; Mon, 20 Aug 2001 10:20:22 -0700 (PDT)
Message-Id: <[e-mail]>
X-Authentication-Warning: fionn.es.net: Host localhost.es.net [127.0.0.1] claimed to be fionn.es.net
cc: [e-mail]
Reply-to: [e-mail]
Subject: Re: About User-ID's 
In-reply-to: Your message of "20 Aug 2001 12:06:00 EDT." <[e-mail]> 
Date: Mon, 20 Aug 2001 10:20:22 -0700
From: Michael Helm <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Derek Atkins writes:
> One solution would be to put PGP Keys (Certificates) into DNS.  Then
> you could easily lookup a key based on the userID, but you have to
> already KNOW the userID.  Unfortunately this doesn't help you lookup
> a key by KeyID.

Why is it necessary to put certs into dns in order to accomplish
this end?


Received: by above.proper.com (8.11.3/8.11.3) id f7KH2sg25388 for ietf-openpgp-bks; Mon, 20 Aug 2001 10:02:54 -0700 (PDT)
Received: from xfw.transarc.ibm.com (xfw.transarc.ibm.com [192.54.226.51]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7KH2qN25384 for <[e-mail]>; Mon, 20 Aug 2001 10:02:52 -0700 (PDT)
Received: from mailhost.transarc.ibm.com (mailhost.transarc.ibm.com [9.38.192.124]) by xfw.transarc.ibm.com (AIX4.3/UCB 8.7/8.7) with ESMTP id MAA62030 for <[e-mail]>; Mon, 20 Aug 2001 12:55:12 -0400 (EDT)
Received: from mwyoung (dhcp-197-83.transarc.ibm.com [9.38.197.83]) by mailhost.transarc.ibm.com (8.8.0/8.8.0) with SMTP id NAA03909 for <[e-mail]>; Mon, 20 Aug 2001 13:02:47 -0400 (EDT)
Message-ID: <009401c12999$afd9b4a0$[e-mail]>
From: "Michael Young" <[e-mail]>
To: "openPGP e-Mail \(E-Mail\)" <[e-mail]>
References: <[e-mail]>
Subject: Re: About User-ID's 
Date: Mon, 20 Aug 2001 13:00:59 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

-----BEGIN PGP SIGNED MESSAGE-----

>I think he meant: is it realy nessessay that the keyserver
> > present that much id's matching (including all signing id's), or
...
> Additionaly I would add: Is it realy nessessary to allow
> three-letter search-patterns? If I search for a key, I should

Agreed.  It is hardly necessary that any keyserver provide a "verbose"
lookup; some keyservers don't, and some only provide limited
information.  Many keyservers only match on full "words", not
arbitrary substrings.  Many limit the number of hits returned in
one query.  These are all fine restrictions.

That said, it wouldn't be hard for a determined harvester to
get most of the meaningful addresses out of a keyserver.
All the names within a (less-than-huge) domain can be
retrieved by querying on that name.

Yes, I suppose you could require complete, exact matches for
the material within angle-brackets.  I wouldn't find such
a keyserver very useful.

If I really wanted to harvest the keyserver contents, I wouldn't use
the query interface at all.  A couple of keyserver operators make
snapshots of their keyrings available for synchronization.  Even if
they weren't, I could pose as a keyserver operator and ask for someone
to give me a snapshot to get started.  Or, I could use the e-mail
interface that many provide to get recent updates.

Whatever your solution, you'd have to convince all of the synchronized
keyserver operators out there to adopt it if you want to protect the
existing "public" keyring.  To do that, I expect you'd have to
demonstrate a greater threat.  As Len pointed out, it doesn't look
like one has materialized yet.

But if anyone wants to build a "safe" keyserver that doesn't
synchronize (outbound) to the "unsafe" servers, they're welcome to
do it.

-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.3

iQEVAwUBO4FCHmNDnIII+QUHAQHjgwf6Ap14fpaTA36kcbd00SNX6cuEo21+vGJM
9wXKn7qt7tq7rhdZOP9EZYpB+3ce6BcoQmJv7kspJhIF+z9ym6NeF4GHl8JqLPEQ
0bJf8PyaU2bU/WtRmvzMVH+dBaf2DPAioW6fPDPLRREx3hgvxiPz2LV5wMJeKUz8
fMAhn52yfzc1Y33wgiX1TDEDNfDOWQD8893cKmvck1sYMCFd0BuLdgM8+XWLqhCE
g2p/kbtKqUK9ZQmKVXpWYssJEME/dJCaphCYWXE0rwhuBwxpPLKAnL8XLIwelx/Q
85JMvVFmNxqtViLj4wzK0PbBPdmDVUila0T6cK2xdM5w7ICj7cMDqA==
=dnnq
-----END PGP SIGNATURE-----




Received: by above.proper.com (8.11.3/8.11.3) id f7KFp3Q22652 for ietf-openpgp-bks; Mon, 20 Aug 2001 08:51:03 -0700 (PDT)
Received: from mail1.biodata.com ([62.159.113.2]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7KFp2N22644 for <[e-mail]>; Mon, 20 Aug 2001 08:51:02 -0700 (PDT)
Received: from fra1d001.biodata.org ([10.10.1.51]) by mail1.biodata.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 20 Aug 2001 17:50:47 +0200
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: AW: About User-ID's 
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
Date: Mon, 20 Aug 2001 17:50:46 +0200
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: About User-ID's 
Thread-Index: AcEpjNanD3hNZ+ZeQ8m0iX+j5j6VjQAADXYQ
From: "Dominikus Scherkl" <[e-mail]>
To: "Michael Young" <[e-mail]>
Cc: "openPGP e-Mail (E-Mail)" <[e-mail]>
X-OriginalArrivalTime: 20 Aug 2001 15:50:47.0100 (UTC) FILETIME=[E0C2A7C0:01C1298F]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id f7KFp2N22647
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

> From: "Michael Helm" <[e-mail]>
> > Could keys and keyservers be configured [optionally] not to
> > present email-like id's?
> 
> Not without almost completely impairing their use.  Yes, it
> would be easy to turn off name-based lookups, and/or discard or
> alter UserId packets.  But...
?
I think he meant: is it realy nessessay that the keyserver
present that much id's matching (including all signing id's), or
wouldn't it be sufficient to only present the hits (where the
the addresses of those signing the key are only revealed by
dowloading that whole key)?

Additionaly I would add: Is it realy nessessary to allow
three-letter search-patterns? If I search for a key, I should
know the full name (or email address) of the owner (else I
couldn't communicate with that person even without signatures).
Only if NO hit is found, a search for similar key-IDs should
be performed and only the nearest should be revealed.

With such a configuration a keyserver could not be abused as an
address data base.
-- 
Dominikus Scherkl
Biodata Application Security AG
mail: [e-mail]


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7KF9kW19114 for ietf-openpgp-bks; Mon, 20 Aug 2001 08:09:46 -0700 (PDT)
Received: from xfw.transarc.ibm.com (xfw.transarc.ibm.com [192.54.226.51]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7KF9hN19108 for <[e-mail]>; Mon, 20 Aug 2001 08:09:44 -0700 (PDT)
Received: from mailhost.transarc.ibm.com (mailhost.transarc.ibm.com [9.38.192.124]) by xfw.transarc.ibm.com (AIX4.3/UCB 8.7/8.7) with ESMTP id LAA61956; Mon, 20 Aug 2001 11:02:03 -0400 (EDT)
Received: from mwyoung (dhcp-197-83.transarc.ibm.com [9.38.197.83]) by mailhost.transarc.ibm.com (8.8.0/8.8.0) with SMTP id LAA03380; Mon, 20 Aug 2001 11:09:38 -0400 (EDT)
Message-ID: <001c01c12989$e3050560$[e-mail]>
From: "Michael Young" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Re: About User-ID's 
Date: Mon, 20 Aug 2001 11:07:53 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

-----BEGIN PGP SIGNED MESSAGE-----

From: "Michael Helm" <[e-mail]>
> Could keys and keyservers be configured [optionally] not to
> present email-like id's?

Not without almost completely impairing their use.  Yes, it
would be easy to turn off name-based lookups, and/or discard or
alter UserId packets.  But...

If you remove or irreversibly alter the UserID material, then:
(1) associated signatures will fail to verify; and, (2) e-mail system
plug-ins will be unable to do matching.  If you alter them in a way
that is automatically reversible, then any harvester could undo the
alteration just as easily.  You would also have to teach all the
existing tools to undo the alteration(s).

Note that many people use altered addresses in their posts, with the
expectation that they'll be fixed *manually*.  A few people (myself
included) do that for keys they upload.  If the alteration doesn't
affect "words" in the name, then name-based lookups will work against
all?) current keyservers.  Plug-ins may require a more exact
match... since I don't use any, I wouldn't know for sure.  Again,
a smart harvester might use some heuristic de-mangling that would
generate a valid address, but that's a risk I'm willing to live with.
Any "mangling standard" might make it more worth trying.

-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.3

iQEVAwUBO4Enm2NDnIII+QUHAQH+DQf/YXZWWbWCMl3Fpa/m9ersiRpRITcUCw70
P5HkHQHVo/mniynfDyxPuu44LMIYKbMkZyeYs2gfZNBZAhiKIB7pYYSK1fx87Q1o
DjSQkOZ+xCITiqb2a/BhJ3900+gVVul7iYKLTaDp3rnyUlsB2oz1A/qOPm2FOfdv
g2+5SJ+Zkwy5PkJtuXWqgQbMqKqm/AExV6mvi2LyPWeN2gJXarA3D+KD+4n4NmDF
gwbbOxrpcjJgTGE6Hd/57okN0gj6Hv8op3SnmFbU8OyN+FRipx93QG/L5aqrV8Zr
iAFd4RnXzn/XXzC9TZfkMJs0O6k7dTRR9ba7C4Kwhjhe2obtFGEbBA==
=WdpU
-----END PGP SIGNATURE-----




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7K2Tcs04557 for ietf-openpgp-bks; Sun, 19 Aug 2001 19:29:38 -0700 (PDT)
Received: from fionn.es.net (fionn.es.net [198.128.1.30]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7K2TRN04551 for <[e-mail]>; Sun, 19 Aug 2001 19:29:27 -0700 (PDT)
Received: from fionn.es.net (localhost.es.net [127.0.0.1]) by fionn.es.net (LBNLMWH19/LBNLMWH11/ESOCF2) with ESMTP id TAA12377; Sun, 19 Aug 2001 19:29:28 -0700 (PDT)
Message-Id: <[e-mail]>
X-Authentication-Warning: fionn.es.net: Host localhost.es.net [127.0.0.1] claimed to be fionn.es.net
To: Werner Koch <[e-mail]>
cc: [e-mail]
Reply-to: [e-mail]
Subject: Re: About User-ID's 
In-reply-to: Your message of "19 Aug 2001 19:00:57 +0200." <[e-mail]> 
Date: Sun, 19 Aug 2001 19:29:27 -0700
From: Michael Helm <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Werner Koch writes:
> People who are currently using PGP keys are not a valuable audience
> for spammers. 

I suspect it's more a matter of ignorance about mining the data
than anything else.

Could keys and keyservers be configured [optionally] not to
present email-like id's?


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7JGw8Y25335 for ietf-openpgp-bks; Sun, 19 Aug 2001 09:58:08 -0700 (PDT)
Received: from kasiski.gnupg.de (porta.u64.de [194.77.88.106]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7JGw6N25331 for <[e-mail]>; Sun, 19 Aug 2001 09:58:06 -0700 (PDT)
Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.22 #1 (Debian)) id 15YWkr-0000LC-00; Sun, 19 Aug 2001 19:52:57 +0200
Received: from wk by alberti.gnupg.de with local (Exim 3.22 #1 (Debian)) id 15YVwX-00048v-00; Sun, 19 Aug 2001 19:00:57 +0200
To: [e-mail]
Subject: Re: About User-ID's
References: <[e-mail]>
From: Werner Koch <[e-mail]>
Organisation: g10 Code GmbH
X-PGP-KeyID: 621CC013
X-Request-PGP: finger:[e-mail]
Date: 19 Aug 2001 19:00:57 +0200
In-Reply-To: <[e-mail]> (Len Sassaman's message of "Sat, 18 Aug 2001 17:08:29 -0700 (PDT)")
Message-ID: <[e-mail]>
Lines: 23
User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Sat, 18 Aug 2001 17:08:29 -0700 (PDT), Len Sassaman said:

> So, not to say that this won't happen, but I haven't seen any evidence
> that is does currently.

People who are currently using PGP keys are not a valuable audience
for spammers. 

If in the future it is common to use encryption, spammer will have a
serious problem: They can't use an open relais to send their trash and
save on their on bandwidth - they would have to get the key of each
recipient, encrypt to this key and send them utilizing there own
resourses.  This will be far too expensive for the common mass spam
attacks.  Yes, I assume that every MTA will at that time drop non
encrypted mail ;-)


  Werner

-- 
Werner Koch        Omnis enim res, quae dando non deficit, dum habetur
g10 Code GmbH      et non datur, nondum habetur, quomodo habenda est.
Privacy Solutions                                        -- Augustinus



Received: by above.proper.com (8.11.3/8.11.3) id f7JDZ7x17223 for ietf-openpgp-bks; Sun, 19 Aug 2001 06:35:07 -0700 (PDT)
Received: from hotmail.com (f69.law4.hotmail.com [216.33.149.69]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7JDZ6N17219 for <[e-mail]>; Sun, 19 Aug 2001 06:35:06 -0700 (PDT)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 19 Aug 2001 06:35:02 -0700
Received: from 216.254.127.192 by lw4fd.law4.hotmail.msn.com with HTTP;	Sun, 19 Aug 2001 13:35:02 GMT
X-Originating-IP: [216.254.127.192]
From: "Bryan Morris" <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: How do I extract my PRIVATE key in PGP CL 6.5???
Date: Sun, 19 Aug 2001 13:35:02 
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 19 Aug 2001 13:35:02.0510 (UTC) FILETIME=[BFCB18E0:01C128B3]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

>This is a GNUpg list, not a PGP list...


thanks!

But do you have an answer nonetheless?

thanks so much!

Bryan

>From: Ralf Hildebrandt <[e-mail]>
>To: Bryan Morris <[e-mail]>
>CC: [e-mail], [e-mail], [e-mail], 
>[e-mail], [e-mail]
>Subject: Re: How do I extract my PRIVATE key in PGP CL 6.5???
>Date: Sun, 19 Aug 2001 10:26:05 +0200
>
> > I am using PGP command line v6.5.
>
>This is a GNUpg list, not a PGP list...
>
>--
>[e-mail]                           innominate AG
>+49.(0)30.308806-62  fax: -77                         networking people
>Remember: if brute force doesn't work, you're just not using enough.
>
>


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7JAtvW11425 for ietf-openpgp-bks; Sun, 19 Aug 2001 03:55:57 -0700 (PDT)
Received: from mail.arcor-ip.de (mail.arcor-ip.de [145.253.2.10] (may be forged)) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7JAtsN11412 for <[e-mail]>; Sun, 19 Aug 2001 03:55:55 -0700 (PDT)
Received: from localhost (145.254.153.80) by mail.arcor-ip.de (5.5.034) id 3B794DFE00094B43; Sun, 19 Aug 2001 12:55:31 +0200
Received: by localhost (Postfix, from userid 500) id C78B749; Sun, 19 Aug 2001 12:59:37 +0200 (CEST)
Date: Sun, 19 Aug 2001 12:59:37 +0200
From: Ingo Luetkebohle <[e-mail]>
To: Jon Callas <[e-mail]>
Cc: [e-mail]
Subject: Re: About User-ID's
Message-ID: <[e-mail]>
References: <[e-mail]> <p05100301b7a4a9adbef5@[63.73.97.181]>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="VbJkn9YxBvnuCH5J"
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <p05100301b7a4a9adbef5@[63.73.97.181]>; from [e-mail] on Sat, Aug 18, 2001 at 04:27:12PM -0700
Organization: Maybe when I grow up
X-URL: http://blank.pages.de/
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

--VbJkn9YxBvnuCH5J
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Sat, Aug 18, 2001 at 04:27:12PM -0700, Jon Callas wrote:
> I don't know about irrelevant -- but I don't know what do do about them. If
> user ids didn't have email addresses on them (which they don't have to), it
> would be hard to find the right key when you want to encrypt mail to
> someone.

Oh, I didn't mean to suggest that. Sorry for not making that clear.

I think "best practices" can be divided in two: 1) best practices on
what to put into a User-ID (obvious and well-established for e-mail,
could be different for SSL keys and so on) and 2) best practices on
how software treats the information.

For an example of the latter, I think current key-server software
makes it exceptionally easy to harvest e-mail address, should someone
desire to do so. I can search for three random letters to get all keys
with those three letters in and the HTML page I get conveniently lists
not just the matching keys but also all the e-mail addresses, *and* --
with the right options -- all e-mail addresses of all signers. This
allows a smart crawler to easily walk the whole server and gather
addresses -- *just* addresses.  Now just consider how much more
difficult it would be if the crawler would have to download the key,
interpret it, go back to the keyserver to fetch all keys referenced in
the signers section and so on. This could be forced by a slight change
in the amount and nature of information revealed by the key-server
(e.g., it could just display the key-id, and the number of
signatures). For legitimate users, who have to download the whole key
anyway, it wouldn't make a difference.

This could be summed up in a suggestion of a best practices document
that software should expect keys to contain sensitive information and
be careful in what it exposes.

There are obviously more open questions, some of which have
traditionally been in FAQ's. Maybe it would help if I draft a small
document with all of them and we can then decide of whether to make an
information RFC from it or just leave it to application developers
documentation?

Regards

--
	Ingo Luetkebohle / [e-mail] / Student of Bioinformatics
/
| Cross-Platform OpenPGP: http://xpg.sourceforge.net/
|
| Fargonauten.DE sysadmin; Gimp Registry maintainer;
| FP: 3187 4DEC 47E6 1B1E 6F4F  57D4 CD90 C164 34AD CE5B

--VbJkn9YxBvnuCH5J
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Weitere Infos: siehe http://www.gnupg.org

iEYEAREBAAYFAjt/nBkACgkQzZDBZDStzlsDtwCgmHHvtpPjtFRSd9h/hieLTtlE
z2gAn2tbxBKkdoKdeg8RdF6TNx9IAsHW
=cgFW
-----END PGP SIGNATURE-----

--VbJkn9YxBvnuCH5J--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7J2wR907005 for ietf-openpgp-bks; Sat, 18 Aug 2001 19:58:27 -0700 (PDT)
Received: from hotmail.com (f68.law4.hotmail.com [216.33.149.68]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7J2wQN07000 for <[e-mail]>; Sat, 18 Aug 2001 19:58:26 -0700 (PDT)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 18 Aug 2001 19:46:26 -0700
Received: from 216.254.127.192 by lw4fd.law4.hotmail.msn.com with HTTP;	Sun, 19 Aug 2001 02:46:26 GMT
X-Originating-IP: [216.254.127.192]
From: "Bryan Morris" <[e-mail]>
To: [e-mail], [e-mail]
Cc: [e-mail], [e-mail], [e-mail]
Subject: How do I extract my PRIVATE key in PGP CL 6.5??? 
Date: Sun, 19 Aug 2001 02:46:26 
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 19 Aug 2001 02:46:26.0980 (UTC) FILETIME=[24547640:01C12859]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Hi,

I am using PGP command line v6.5.

How do I extract my PRIVATE key?

The documentation only lists extracting the public key.

Thanks for the help.

Brian

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7J08YS04462 for ietf-openpgp-bks; Sat, 18 Aug 2001 17:08:34 -0700 (PDT)
Received: from thetis.deor.org (thetis.deor.org [207.106.86.210]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7J08WN04458 for <[e-mail]>; Sat, 18 Aug 2001 17:08:33 -0700 (PDT)
Received: from localhost (rabbi@localhost) by thetis.deor.org (8.9.3/8.9.3) with ESMTP id RAA20110; Sat, 18 Aug 2001 17:08:30 -0700
Date: Sat, 18 Aug 2001 17:08:29 -0700 (PDT)
From: Len Sassaman <[e-mail]>
X-Sender:  <[e-mail]>
To: Jon Callas <[e-mail]>
cc: Ingo Luetkebohle <[e-mail]>, <[e-mail]>
Subject: Re: About User-ID's
In-Reply-To: <p05100301b7a4a9adbef5@[63.73.97.181]>
Message-ID: <[e-mail]>
X-AIM: Elom777
X-icq: 10735603
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Sat, 18 Aug 2001, Jon Callas wrote:

> I don't know about irrelevant -- but I don't know what do do about them. If
> user ids didn't have email addresses on them (which they don't have to), it
> would be hard to find the right key when you want to encrypt mail to
> someone.

People have talked about the possibility of spammers harvesting names from
the keyservers for quite some time now. Out of curiousity, last May I
created a key with a unique email address and submitted the keyserver
network as bait. It's been over a year now, and I have yet to receive a
piece of spam to that address.

So, not to say that this won't happen, but I haven't seen any evidence
that is does currently.


Len


--

Len Sassaman

Security Architect            |
Technology Consultant         |  "Let be be finale of seem."
                              |
http://sion.quickie.net       |           --Wallace Stevens











Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7INVq204165 for ietf-openpgp-bks; Sat, 18 Aug 2001 16:31:52 -0700 (PDT)
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7INVpN04161 for <[e-mail]>; Sat, 18 Aug 2001 16:31:51 -0700 (PDT)
Received: from [63.73.97.181] (63.73.97.181) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.0.3); Sat, 18 Aug 2001 16:31:52 -0700
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100301b7a4a9adbef5@[63.73.97.181]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Sat, 18 Aug 2001 16:27:12 -0700
To: Ingo Luetkebohle <[e-mail]>, [e-mail]
From: Jon Callas <[e-mail]>
Subject: Re: About User-ID's
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

At 3:32 PM +0200 8/5/01, Ingo Luetkebohle wrote:
>Hello,
>
>I would like to suggest an RFC or other document about best current
>practices regarding User-ID's.
>
>In that, a thorough re-evaluation of the current situation should be
>done, possibly based upon previous works, if there are any (I'm not
>aware of that, if anyone is, I'd be happy about a pointer).
>
>The reason for all this is that I see several problems with the way
>User-ID's are used on OpenPGP implementations right now. Immediately
>obvious is the spam problem because User-ID's contain e-mail addresses
>and people are encouraged to upload their keys to keyservers, which
>are searchable by all but also the uniqueness problem (people have
>multiple addresses and I'm not of the opinion that listing them all is
>the solution) and the problem of anonymity.
>
>What does the working group think? Are the abovementioned problems
>irrelevant in your opinion or, if not, would you agree that a document
>about User-ID's would be a good start at solving them?
>
>Looking forward to your input!
>

I don't know about irrelevant -- but I don't know what do do about them. If
user ids didn't have email addresses on them (which they don't have to), it
would be hard to find the right key when you want to encrypt mail to
someone.

What do you think the solution is?

	Jon


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7IGKG729251 for ietf-openpgp-bks; Sat, 18 Aug 2001 09:20:16 -0700 (PDT)
Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.65.64]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7IGKEN29247 for <[e-mail]>; Sat, 18 Aug 2001 09:20:14 -0700 (PDT)
Received: from [199.106.106.137] (vpnap-g1-012062.qualcomm.com [10.13.12.62]) by mage.qualcomm.com (8.11.3/8.11.3/1.0) with ESMTP id f7IGK9C00829; Sat, 18 Aug 2001 09:20:09 -0700 (PDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100101b7a43a5504f0@[129.46.77.28]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-Mailer: eudora51-ffc10713011434
X-PGP-RSA-Fingerprint: EA53 01A6 C076 F9C2  09E8 9480 645A 8857
X-PGP-DH-Fingerprint: 4F5E 56C9 BD4D 0227 331F 6AEE 9590 24F9 6FD7 04F8
Date: Sat, 18 Aug 2001 09:18:54 -0700
To: OpenPGP mailing list <[e-mail]>
From: John  W Noerenberg II <[e-mail]>
Subject: Re: AW: Reasons to include ECC to our charter
Cc: "Ben Laurie" <[e-mail]>, "Dominikus Scherkl" <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

At 3:33 PM +0200 8/15/01, Dominikus Scherkl wrote:
>Hi.
>
>>  > IIRC, not all ECC stuff is patented, only curves over GF(q), q even,
>>  > which can be implemented efficiently using two-valued logic.
>>
>>  As I read it, this I-D includes these.
>But it also includes Curves over GF(q), q prime or a power of some
>odd prime. I wouldn't appreciate it much to exclude some stuff,
>now that we have a definition including simply every finite field.

I agree with Dominkus on this point.  As long as what he has defined 
gives a means for any ECC curve deemed useful, I believe that 
finesses the IPR issues raised by Certicom's patents.

However, At 1:42 AM +1200 8/11/01, Peter Gutmann wrote:
>The rule of thumb for ECC is something like "ECC curves are divided into three
>groups, weak curves, inefficient curves, and curves patented by Certicom".

If Peter is accurate, then Certicom's IPR poses a significant 
obstacle to ECC utility.  Do others wish to comment on this?

It may be possible to pursue an agreement along the lines of RFC1790. 
Certicom would have to be agreeable, and  we would have to persuade 
the IETF as a whole such an agreement is in the IETF's interest.  To 
my knowledge, the RFCs covered by agreement documented in 1790 did 
not achieve STD status, but that doesn't mean we would not succeed. 
It is still a useful model.

Assuming we do proceed, it would be appropriate to be warn people 
about classes of curves which are either inefficient to compute, or 
may require licensing from a third party.  Both considerations limit 
utility of some ECC designs.

However, I would like to see more analysis of ECC curves (not to 
slight Peter's assessment), before I consider this matter resolved. 
Further, if someone could point me towards the appropriate person at 
Certicom to discuss the 1790 approach, please do so.

best,
-- 

john noerenberg
[e-mail]
   --------------------------------------------------------------------------
   Peace of mind isn't at all superficial, really.  It's the whole thing.
   That which produces it is good maintenance; that which disturbs it
   is poor maintenance.
   -- Zen and the Art of Motorcycle Maintenance, Robert M. Pirsig, 1974
   --------------------------------------------------------------------------


Received: by above.proper.com (8.11.3/8.11.3) id f7ICOXC21506 for ietf-openpgp-bks; Sat, 18 Aug 2001 05:24:33 -0700 (PDT)
Received: from kasiski.gnupg.de (porta.u64.de [194.77.88.106]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7ICOUN21502 for <[e-mail]>; Sat, 18 Aug 2001 05:24:31 -0700 (PDT)
Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.22 #1 (Debian)) id 15Y60D-0006Iq-00; Sat, 18 Aug 2001 15:19:01 +0200
Received: from wk by alberti.gnupg.de with local (Exim 3.22 #1 (Debian)) id 15Y5Cq-00030P-00; Sat, 18 Aug 2001 14:28:00 +0200
To: Jon Callas <[e-mail]>
Cc: Ingo Luetkebohle <[e-mail]>, [e-mail], [e-mail]
Subject: Re: ElGamal signature values?
References: <[e-mail]> <p05101005b799bb31f246@[169.254.245.48]> <[e-mail]> <p05100305b7a343388caa@[63.73.97.186]>
From: Werner Koch <[e-mail]>
Organisation: g10 Code GmbH
X-PGP-KeyID: 621CC013
X-Request-PGP: finger:[e-mail]
Date: 18 Aug 2001 14:27:59 +0200
In-Reply-To: <p05100305b7a343388caa@[63.73.97.186]> (Jon Callas's message of "Fri, 17 Aug 2001 15:03:56 -0700")
Message-ID: <[e-mail]>
Lines: 31
User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Fri, 17 Aug 2001 15:03:56 -0700, Jon Callas said:

> I'm a little uncomfortable over proper wording here; if they're so bad,
> should they be there at all? I thought the present 12.5 wording was stern

Well, we had so many discussions and I guess that there are still some
folks who have concerns about DSA so that they use ElGamal
signatures. Of course, it is there good right to do this.  OTOH this
often triggers long discussions whether there is a bug in PGP or GnuPG
when one can't check the signature.

Removing that optional algorithm is neither good because we willfor
sure start a long discussion again ;-)

>  Details on safe use of Elgamal signatures may be found in [MENEZES], which
>  discusses all the weaknesses described above. Please note that Elgamal
>  signatures are controversial; because of the care that must be taken with
>  Elgamal keys, many implementations forego them.

> How's that?

That's really nice.

Thanks,

   Werner

-- 
Werner Koch        Omnis enim res, quae dando non deficit, dum habetur
g10 Code GmbH      et non datur, nondum habetur, quomodo habenda est.
Privacy Solutions                                        -- Augustinus



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7HMBtS07711 for ietf-openpgp-bks; Fri, 17 Aug 2001 15:11:55 -0700 (PDT)
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7HMBsN07706 for <[e-mail]>; Fri, 17 Aug 2001 15:11:54 -0700 (PDT)
Received: from [63.73.97.186] (64.69.113.115) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.0.3); Fri, 17 Aug 2001 15:11:38 -0700
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100305b7a343388caa@[63.73.97.186]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <p05101005b799bb31f246@[169.254.245.48]> <[e-mail]>
Date: Fri, 17 Aug 2001 15:03:56 -0700
To: Werner Koch <[e-mail]>
From: Jon Callas <[e-mail]>
Subject: Re: ElGamal signature values?
Cc: Ingo Luetkebohle <[e-mail]>, [e-mail], [e-mail]
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

At 3:41 PM +0200 8/13/01, Werner Koch wrote:

>Please add a reference to section 12.5 [ElGamal] and make clear that
>the use of ElGamal signatures is not suggested.
>

I'm a little uncomfortable over proper wording here; if they're so bad,
should they be there at all? I thought the present 12.5 wording was stern
enough to give anyone pause. Nonetheless, I added another wording. Here's
the complete paragraph:

 Details on safe use of Elgamal signatures may be found in [MENEZES], which
 discusses all the weaknesses described above. Please note that Elgamal
 signatures are controversial; because of the care that must be taken with
 Elgamal keys, many implementations forego them.

How's that?

	Jon


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7HKjMk06185 for ietf-openpgp-bks; Fri, 17 Aug 2001 13:45:22 -0700 (PDT)
Received: from sentry.gw.tislabs.com ([e-mail] [192.94.214.100]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7HKjLN06181 for <[e-mail]>; Fri, 17 Aug 2001 13:45:21 -0700 (PDT)
Received: by sentry.gw.tislabs.com; id QAA01162; Fri, 17 Aug 2001 16:49:48 -0400 (EDT)
Received: from clipper.gw.tislabs.com(10.33.1.2) by sentry.gw.tislabs.com via smap (V5.5) id xma001118; Fri, 17 Aug 01 16:49:27 -0400
Received: (from balenson@localhost) by clipper.gw.tislabs.com (8.9.3/8.9.1) id QAA09513 for [e-mail]; Fri, 17 Aug 2001 16:45:02 -0400 (EDT)
Date: Fri, 17 Aug 2001 16:45:02 -0400 (EDT)
From: "David M. Balenson" <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: CFP: Submission deadline for NDSS'02 extended to Aug 29th
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Due to the unusually large number of requests for an extension,
the submissions deadline for NDSS'02 has been extended to 
Wednesday August 29, 9:00am EST (U.S. east coast time).
 
Paul Van Oorschot  and Virgil Gligor
Co-Chairs, NDSS'02


                             C A L L   F O R   P A P E R S

Internet Society's 2002 Network and Distributed System Security Symposium  (NDSS'02)

Catamaran Resort - San Diego, California
February 6-8, 2002

IMPORTANT DATES
Paper and panel submissions due August 22, 2001
Author notification October 17, 2001
Final version of papers and panels due November 20, 2001

GOAL: The symposium fosters information exchange among research scientists and practitioners of network and distributed system security services. The target audience includes those interested in practical aspects of network and distributed system security, with a focus on actual system design and implementation (rather than theory). A major goal is to encourage and enable the Internet community to apply, deploy, and advance the state of available security technology. The proceedings are published by the Internet Society.

GENERAL CHAIR: 
Clifford Neuman, USC Information Sciences Institute

PROGRAM CO-CHAIRS:
Paul Van Oorschot, Entrust Technologies
Virgil Gligor, University of Maryland

TUTORIAL CHAIR:
Eric Harder, National Security Agency

LOCAL ARRANGEMENTS CHAIR:
Thomas Hutton, San Diego Supercomputer Center

PUBLICATIONS CHAIR:
Mahesh Tripunitara, Purdue University

PUBLICITY CHAIR:
David Balenson, NAI Labs, Network Associates

LOGISTICS CHAIR:
Terry Weigler, Internet Society

PROGRAM COMMITTEE:
Steve Bellovin, AT&T Labs Research
Dan Boneh, Stanford University
Bill Cheswick, Lumeta Corporation
Li Gong, Sun Microsystems
Peter Gutmann, Univ. of Auckland, N.Z.
Charlie Kaufman, Iris Associates
Steve Kent, BBN Technologies
Markus Kuhn, Univ. of Cambridge, U.K.
Douglas Maughan, DARPA
Kevin McCurley, IBM Almaden Research
Gary McGraw, Cigital
Fabian Monrose, Bell Labs
Sandra Murphy, Network Associates
Radha Poovendran, Univ. of Washington 
Michael Roe, Microsoft Research, U.K. 
Christoph Schuba, Sun Microsystems
Clay Shields, Purdue University
Jonathan Trostle, Cisco Systems
Dan Wallach, Rice University

OUTSTANDING PAPER AWARD: There will be an Outstanding Paper award. The award will be presented at the symposium to the authors of an outstanding paper, as selected by the Program Committee.

SUBMISSIONS: Both technical papers and panel proposals are solicited. Technical papers must include a main body of at most 12 pages, with any additional details in clearly marked appendices for a combined total of at most 20 pages. Technical papers will appear in the proceedings. Panel proposals should be one page and must describe the topic, identify the panel chair, explain the panel format, and list three to four potential panelists. A description of each panel will appear in the proceedings, and may, at the discretion of the panel chair, include written position statements from the panelists.

Submissions are solicited in, but not limited to, the following areas:
* Integrating security in Internet protocols: routing, naming, TCP/IP, multicast, network management, and the Web.
* Intrusion avoidance, detection, and response: systems, experiences and architectures.
* Attack-resistant protocols and services.
* Network perimeter controls: firewalls, packet filters, application gateways.
* Virtual private networks.
* Public key infrastructure, key management, certification, and revocation.
* Secure electronic commerce: e.g., payment, barter, EDI, notarization, timestamping, endorsement, and licensing.
* Supporting security mechanisms and APIs; audit trails; accountability.
* Implementation, deployment and management of network security policies.
* Intellectual property protection: protocols, schemas, implementations, metering, watermarking, digital rights management.
* Fundamental services on network and distributed systems: authentication, data integrity, confidentiality, authorization, non-repudiation, and availability.
* Integrating security services with system and application security facilities and protocols: e.g., message handling, file transport/access, directories, time synchronization, data base management, boot services, mobile computing.
* Security for emerging technologies: sensor networks, specialized testbeds, wireless/mobile (and ad hoc) networks, personal communication systems, and large heterogeneous distributed systems.
* Special problems and case studies: e.g., interplay and tradeoffs between security and efficiency, usability, reliability and cost.
* Security for collaborative applications and services: teleconferencing and video-conferencing, groupwork, etc.

Each submission must contain a separate Submission Overview specifying the submission type (paper or panel), the title or topic, author names with organizational affiliations, and must specify a contact author along with corresponding phone number, FAX number, postal address and email address.

Submissions must be received by August 22, 2001, and must be made electronically in either printable PostScript or PDF. Each submission will be acknowledged by e-mail; if acknowledgment is not received within seven days, contact a program co-chair (see above). Authors and panelists will be notified of acceptance by October 17, 2001, and given instructions for preparing the camera-ready copy. The camera-ready copy must be received by November 20, 2001. 

FURTHER INFORMATION: Official dates, the final call for papers, the advance program, and registration information will be available shortly at http://www.isoc.org/ndss2002. For official submission information, visit http://www.isoc.org/ndss2002/cfp.

Internet Society 

11150 Sunset Hills Road, Suite 100
Reston, VA  20191  USA
Tel:  [phone]
Fax:  [phone]
www.isoc.org

4, rue des Falaises
CH-1205 Geneva
Switzerland
Tel:  [phone]
Fax:  [phone]
www.isoc.org


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7HKHYE05721 for ietf-openpgp-bks; Fri, 17 Aug 2001 13:17:34 -0700 (PDT)
Received: from hotmail.com (f63.law4.hotmail.com [216.33.149.63]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7HKHXN05717 for <[e-mail]>; Fri, 17 Aug 2001 13:17:33 -0700 (PDT)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 17 Aug 2001 13:05:42 -0700
Received: from 63.106.27.66 by lw4fd.law4.hotmail.msn.com with HTTP;	Fri, 17 Aug 2001 20:05:42 GMT
X-Originating-IP: [63.106.27.66]
From: "Bryan Morris" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: How do I extract my PRIVATE key in PGP CL 6.5???
Date: Fri, 17 Aug 2001 20:05:42 
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 17 Aug 2001 20:05:42.0893 (UTC) FILETIME=[FE8631D0:01C12757]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

How do I extract my PRIVATE key in PGP CL 6.5???


Hi,

I am using PGP command line v6.5.

How do I extract my PRIVATE key?

The documentation only lists extracting the public key.

Thanks for the help.

Brian


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7HGCO901314 for ietf-openpgp-bks; Fri, 17 Aug 2001 09:12:24 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7HGCNN01310 for <[e-mail]>; Fri, 17 Aug 2001 09:12:23 -0700 (PDT)
Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by boreas.isi.edu (8.11.2/8.11.2) with ESMTP id f7HGCMv15866; Fri, 17 Aug 2001 09:12:22 -0700 (PDT)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Subject: RFC 3156 on MIME Security with OpenPGP
Cc: [e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 17 Aug 2001 09:12:22 -0700
From: RFC Editor <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

--NextPart


A new Request for Comments is now available in online RFC libraries.


        RFC 3156

        Title:	    MIME Security with OpenPGP
        Author(s):  M. Elkins, D. Del Torto, R. Levien, T. Roessler 
        Status:     Standards Track
	Date:       August 2001
        Mailbox:    [e-mail], [e-mail],
                    [e-mail] 
        Pages:      15
        Characters: 26809
        Updates:    RFC 2015

        I-D Tag:    draft-ietf-openpgp-mime-08.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3156.txt


This document describes how the OpenPGP Message Format can be
used to provide privacy and authentication using the Multipurpose
Internet Mail Extensions (MIME) security content types described in
RFC 1847.

This document is a product of the An Open Specification for Pretty
Good Privacy Working Group of the IETF.

This is now a Proposed Standard Protocol.

This document specifies an Internet standards track protocol for
the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the
"Internet Official Protocol Standards" (STD 1) for the
standardization state and status of this protocol.  Distribution
of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="[e-mail]"

Content-Type: text/plain
Content-ID: <[e-mail]>

RETRIEVE: rfc
DOC-ID: rfc3156

--OtherAccess
Content-Type:   Message/External-body;
        name="rfc3156.txt";
        site="ftp.isi.edu";
        access-type="anon-ftp";
        directory="in-notes"

Content-Type: text/plain
Content-ID: <[e-mail]>

--OtherAccess--
--NextPart--


Received: by above.proper.com (8.11.3/8.11.3) id f7FDYgb20188 for ietf-openpgp-bks; Wed, 15 Aug 2001 06:34:42 -0700 (PDT)
Received: from mail1.biodata.com ([62.159.113.2]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7FDYeN20184 for <[e-mail]>; Wed, 15 Aug 2001 06:34:41 -0700 (PDT)
Received: from fra1d001.biodata.org ([10.10.1.51]) by mail1.biodata.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 15 Aug 2001 15:33:24 +0200
Subject: AW: Reasons to include ECC to our charter
Date: Wed, 15 Aug 2001 15:33:24 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
content-class: urn:content-classes:message
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
X-MS-TNEF-Correlator: 
Thread-Topic: Reasons to include ECC to our charter
Thread-Index: AcEhsbuvGZnJ9QwpSu2blA5ocaHvZQD2p2Bg
From: "Dominikus Scherkl" <[e-mail]>
To: "Ben Laurie" <[e-mail]>
Cc: "openPGP e-Mail (E-Mail)" <[e-mail]>
X-OriginalArrivalTime: 15 Aug 2001 13:33:24.0396 (UTC) FILETIME=[DBA916C0:01C1258E]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id f7FDYfN20185
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Hi.

> > IIRC, not all ECC stuff is patented, only curves over GF(q), q even,
> > which can be implemented efficiently using two-valued logic.
> 
> As I read it, this I-D includes these.
But it also includes Curves over GF(q), q prime or a power of some
odd prime. I wouldn't appreciate it much to exclude some stuff,
now that we have a definition including simply every finite field.
But my suggestion doesn't require an application to use binary
fields, and other curves are also given (and own for which noone
could claim any rights could be generated), so licence problems are
easy to avoid.

As I already mentioned to some people, I think it is the main topic
for an internet standard to enhance interoperability. So im still
convinced it is a good idea to provide a common way to store data
for ECC algorithms even if a particular implementation decide not to
use ECC (or not all suggested curves) for licence reasons.

I see the point that we shouldn't do the work for those who claimed
rights that should not be granted to anyone (like patenting a number).

But 1. most of the work is done, 2. a patent won't last forever and
if a standard is available before it's most likely that future
applications will conform to it.
-- 
Dominikus Scherkl
Biodata Application Security AG
mail: [e-mail]


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7DE0r520717 for ietf-openpgp-bks; Mon, 13 Aug 2001 07:00:53 -0700 (PDT)
Received: from kasiski.gnupg.de (porta.u64.de [194.77.88.106]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7DE0pN20713 for <[e-mail]>; Mon, 13 Aug 2001 07:00:51 -0700 (PDT)
Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.22 #1 (Debian)) id 15WJ6j-0005Q4-00; Mon, 13 Aug 2001 16:54:21 +0200
Received: from wk by alberti.gnupg.de with local (Exim 3.22 #1 (Debian)) id 15WIK0-0005KA-00; Mon, 13 Aug 2001 16:04:00 +0200
To: [e-mail]
Cc: [e-mail]
Subject: Key flags and Feature packet
From: Werner Koch <[e-mail]>
Organisation: g10 Code GmbH
X-PGP-KeyID: 621CC013
X-Request-PGP: finger:[e-mail]
Date: 13 Aug 2001 16:04:00 +0200
Message-ID: <[e-mail]>
Lines: 62
User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Hi,

there used to be a draft (Brown, Back, Laurie: Forward Secrecy
Extensions for OpenPGP) on how to add PFS to OpenPGP.  I recently
looked again at the now expired draft to decide whether it can be
implemented.  It does need a little bit of work but 2 things could be
very helpful if we can put them into OpenPGP now:

  1. A key flag "one time key". I suggest to use the next
     octet for this:
 
       Second octet:

       0x01 - This key should be used only once. 

  2. A feature flag "one time key support", with value 2:  It
     indicates that the implementation is able to handle one time
     keys; i.e. it will never use this key twice for encryption and
     delete the secret key after successful decryption.

Because all details of such a feature can't go right now in 2440bis,
we might just want to mark these values as "reserved for one time key
keys".

BTW, why is the 5.2.3.24. Features defined as just an array of
one-octet values and not similar to the key flags?  I think it would
be much more consistent if we stick to the general OpenPGP bit-saving
technique.  Can we change it to:

5.2.3.24. Features

   (octet string)

   The features subpacket denotes which advanced OpenPGP features a
   user's implementation supports. This is so that as features are
   added to OpenPGP that cannot be backwards-compatible, a user can
   state that they can use that feature. 

   This subpacket is similar to a preferences subpacket, and only
   appears in a self-signature.

   An implementation SHOULD NOT use a feature listed when sending to a
   user who does not state that they can use it.

   Defined features are:

       First octet:    

       Bit 0 - Modification Detection (packets 15 and 16)

   If an implementation implements any of the defined features, it
   SHOULD implement the features subpacket, too.


Ciao,

  Werner

-- 
Werner Koch        Omnis enim res, quae dando non deficit, dum habetur
g10 Code GmbH      et non datur, nondum habetur, quomodo habenda est.
Privacy Solutions                                        -- Augustinus



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7DDd0D20206 for ietf-openpgp-bks; Mon, 13 Aug 2001 06:39:00 -0700 (PDT)
Received: from kasiski.gnupg.de (porta.u64.de [194.77.88.106]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7DDcvN20202 for <[e-mail]>; Mon, 13 Aug 2001 06:38:57 -0700 (PDT)
Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.22 #1 (Debian)) id 15WIlR-0005NL-00; Mon, 13 Aug 2001 16:32:21 +0200
Received: from wk by alberti.gnupg.de with local (Exim 3.22 #1 (Debian)) id 15WHxw-0005I4-00; Mon, 13 Aug 2001 15:41:12 +0200
To: Jon Callas <[e-mail]>
Cc: Ingo Luetkebohle <[e-mail]>, [e-mail], [e-mail]
Subject: Re: ElGamal signature values?
References: <[e-mail]> <p05101005b799bb31f246@[169.254.245.48]>
From: Werner Koch <[e-mail]>
Organisation: g10 Code GmbH
X-PGP-KeyID: 621CC013
X-Request-PGP: finger:[e-mail]
Date: 13 Aug 2001 15:41:12 +0200
In-Reply-To: <p05101005b799bb31f246@[169.254.245.48]> (Jon Callas's message of "Fri, 10 Aug 2001 09:25:36 -0700")
Message-ID: <[e-mail]>
Lines: 27
User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Fri, 10 Aug 2001 09:25:36 -0700, Jon Callas said:

> Can someone who is an implementer answer this? What do I need to do to put
> in the next draft? I'm going to put out another draft in the next couple of

Algorithm Specific Fields for ElGamal signatures:

  - MPI of ElGamal value a = g**k mod p.

  - MPI of ElGamal value b = (h-a*x)/k mod p-1.

The hash h is PKCS-1 padded exactly the same way as for the above
described RSA signatures.

Please add a reference to section 12.5 [ElGamal] and make clear that
the use of ElGamal signatures is not suggested.

> days -- there's time here at HAL -- and if I can clarify, I will.

Hope you had a nice time.

  Werner

-- 
Werner Koch        Omnis enim res, quae dando non deficit, dum habetur
g10 Code GmbH      et non datur, nondum habetur, quomodo habenda est.
Privacy Solutions                                        -- Augustinus



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7DB6AY14196 for ietf-openpgp-bks; Mon, 13 Aug 2001 04:06:10 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7DB68N14191 for <[e-mail]>; Mon, 13 Aug 2001 04:06:09 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13522; Mon, 13 Aug 2001 07:04:58 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-scherkl-openpgp-ecc-00.txt
Date: Mon, 13 Aug 2001 07:04:57 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: OpenPGP Elliptic Curve Algorithm Formats
	Author(s)	: D. Scherkl
	Filename	: draft-scherkl-openpgp-ecc-00.txt
	Pages		: 20
	Date		: 09-Aug-01
	
This document defines which algorithm specific parameters are needed
for elliptic curve cipher (ECC) and elliptic curve digital signature
algorithm (ECDSA) and how they have to be stored in openPGP packets.
Therefore it is an supplement to the openPGP message format [1].
It also defines which checks are needed to validate ECC and ECDSA
keys and which 'top-level' operations must be performed for
encryption/decryption and signing/signature verification. But it
gives no advices how to implement these checks and operations, nor
the underlying mathematics. To do this, look for example at IEEE
P1363 [2].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-scherkl-openpgp-ecc-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-scherkl-openpgp-ecc-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-scherkl-openpgp-ecc-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-scherkl-openpgp-ecc-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-scherkl-openpgp-ecc-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: by above.proper.com (8.11.3/8.11.3) id f7BHCem24313 for ietf-openpgp-bks; Sat, 11 Aug 2001 10:12:40 -0700 (PDT)
Received: from smtprelay2.adelphia.net (smtprelay2.adelphia.net [64.8.25.7]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7BHCRN24308 for <[e-mail]>; Sat, 11 Aug 2001 10:12:28 -0700 (PDT)
Received: from mwyoung ([24.48.51.230]) by smtprelay2.adelphia.net (Netscape Messaging Server 4.15) with SMTP id GHWYHF01.UAV; Sat, 11 Aug 2001 13:12:51 -0400 
Message-ID: <006601c12288$8e34b4c0$[e-mail]>
From: "Michael Young" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
References: <[e-mail]> <p05101005b799bb31f246@[169.254.245.48]>
Subject: Re: ElGamal signature values?
Date: Sat, 11 Aug 2001 13:10:30 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

-----BEGIN PGP SIGNED MESSAGE-----

From: "Jon Callas" <[e-mail]>
> Can someone who is an implementer answer this? What do I need to do to put
> in the next draft? I'm going to put out another draft in the next couple of
> days -- there's time here at HAL -- and if I can clarify, I will.

I haven't implemented it yet, but I've asked a few times, and for
lack of an answer, I've looked over the GnuPG code.

GnuPG computes:
    a=g^k mod p); and,
    b=(h-a*x)/k mod (p-1))
 where k is random and h is the (padded) message hash.

It seems to apply the same PKCS padding as for RSA signatures.
The two MPIs are encoded in that order (a,b).

The computation matches that found in the Handbook of Applied
Cryptography, among others.  I can't comment on whether the PKCS
padding is the usual treatment for ElGamal signatures, though.

-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.3

iQEVAwUBO3Vm6WNDnIII+QUHAQEUMwgArXuSzEwh/5JrUyfb824IvMwW1nT6nj0X
+RWMVWhDhij63kT95qo0yf/zNgSJ0qIuz0SSCwsTq2R8C6wknL//iIIU4IWDbNrf
S1q6128GA9blwyJ4bWdfxnFABUSpPiUl7g5A+LBWPe5o1Q2wSAYKBLDiVJtL9AHG
Db3R3++gnUo4ligmGCbzcU0dNepn0BEmAWAXmR3zH8xC2mNOPtIWBjm2JIUojZzX
99cB4hLjhw06I8H563eCo9avmc/2CTti+R9RNFWbu/CnKfSDL+++KhsgbkKIv7+M
NdzpdJoKM6EmwPVbt8f9ZEZBRyMzotw9my9YiqVQaeybX4ZJFQ9O7g==
=5/KR
-----END PGP SIGNATURE-----




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7AGZrg17964 for ietf-openpgp-bks; Fri, 10 Aug 2001 09:35:53 -0700 (PDT)
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7AGZpN17960 for <[e-mail]>; Fri, 10 Aug 2001 09:35:51 -0700 (PDT)
Received: from [169.254.245.48] (217.155.18.84) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.0.3); Fri, 10 Aug 2001 09:35:40 -0700
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05101005b799bb31f246@[169.254.245.48]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Fri, 10 Aug 2001 09:25:36 -0700
To: Ingo Luetkebohle <[e-mail]>, [e-mail]
From: Jon Callas <[e-mail]>
Subject: Re: ElGamal signature values?
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

At 10:19 PM +0200 8/3/01, Ingo Luetkebohle wrote:

>I couldn't find a specification for ElGamal signature values in the
>RFC or the current (bis-02) draft, even though the current draft
>mentions the possibility of such signatures in section 12.5 and gpg
>seems to support them.
>
>It would seem logical to use the same values as for public-key
>encrypted session keys. Is that correct? Is that what gpg does or is
>there something else I need to know?
>

Can someone who is an implementer answer this? What do I need to do to put
in the next draft? I'm going to put out another draft in the next couple of
days -- there's time here at HAL -- and if I can clarify, I will.

	Jon


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7AFG4a03183 for ietf-openpgp-bks; Fri, 10 Aug 2001 08:16:04 -0700 (PDT)
Received: from scuzzy.ben.algroup.co.uk (sockittome.aldigital.co.uk [194.128.162.252]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7AFG2N03170 for <[e-mail]>; Fri, 10 Aug 2001 08:16:03 -0700 (PDT)
Received: from algroup.co.uk (wiese.ben.algroup.co.uk [193.133.15.150]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id 83B1F2E90E; Fri, 10 Aug 2001 15:18:45 +0000 (GMT)
Message-ID: <[e-mail]>
Date: Fri, 10 Aug 2001 16:15:35 +0100
From: Ben Laurie <[e-mail]>
X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Florian Weimer <[e-mail]>
Cc: [e-mail]
Subject: Re: Reasons to include ECC to our charter
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Florian Weimer wrote:
> 
> Ben Laurie <[e-mail]> writes:
> 
> > You can't add it to the _standard_ because of restrictive licensing. I
> > guess Informational RFCs are possible, but they don't make me happy -
> > essentially the WG is doing free work, both technical and marketing, for
> > the owner(s) of the patents.
> 
> IIRC, not all ECC stuff is patented, only curves over GF(q), q even,
> which can be implemented efficiently using two-valued logic.

As I read it, this I-D includes these.

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff


Received: by above.proper.com (8.11.3/8.11.3) id f7ADglG20399 for ietf-openpgp-bks; Fri, 10 Aug 2001 06:42:47 -0700 (PDT)
Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7ADgjN20391 for <[e-mail]>; Fri, 10 Aug 2001 06:42:45 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id BAA24755; Sat, 11 Aug 2001 01:42:40 +1200 (NZST) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id BAA232398; Sat, 11 Aug 2001 01:42:40 +1200 (NZST) (sender [e-mail])
Date: Sat, 11 Aug 2001 01:42:40 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Reasons to include ECC to our charter
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Florian Weimer <[e-mail]> writes:

>Ben Laurie <[e-mail]> writes:
>>You can't add it to the _standard_ because of restrictive licensing. I
>>guess Informational RFCs are possible, but they don't make me happy -
>>essentially the WG is doing free work, both technical and marketing, for
>>the owner(s) of the patents.
>
>IIRC, not all ECC stuff is patented, only curves over GF(q), q even, which can
>be implemented efficiently using two-valued logic.

The rule of thumb for ECC is something like "ECC curves are divided into three
groups, weak curves, inefficient curves, and curves patented by Certicom".

Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f79FlBB24005 for ietf-openpgp-bks; Thu, 9 Aug 2001 08:47:11 -0700 (PDT)
Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.65.64]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f79FlAN23998 for <[e-mail]>; Thu, 9 Aug 2001 08:47:10 -0700 (PDT)
Received: from [217.33.140.52] (vpnap-g1-012084.qualcomm.com [10.13.12.84]) by mage.qualcomm.com (8.11.3/8.11.3/1.0) with ESMTP id f79Fl5T00400; Thu, 9 Aug 2001 08:47:05 -0700 (PDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100108b7985a23c68b@[217.33.140.52]>
In-Reply-To: <5.1.0.14.2.20010809113314.00ac0dc0@127.0.01>
References: <[e-mail]> <[e-mail]> <5.1.0.14.2.20010809113314.00ac0dc0@127.0.01>
X-Mailer: eudora51-ffc10713011434
X-PGP-RSA-Fingerprint: EA53 01A6 C076 F9C2  09E8 9480 645A 8857
X-PGP-DH-Fingerprint: 4F5E 56C9 BD4D 0227 331F 6AEE 9590 24F9 6FD7 04F8
Date: Thu, 9 Aug 2001 16:39:18 +0100
To: Rodney Thayer <[e-mail]>
From: John  W Noerenberg II <[e-mail]>
Subject: Re: Draft openPGP ECC formats
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

At 11:34 AM -0700 8/9/01, Rodney Thayer wrote:
>This implies severe process failure -- the draft editor isn't
>supposed to let drafts get in without permission from the WG chair.

There is no restriction on personal submissions.  Dominikus was 
unaware of IETF procedures.  We have discussed it, and he has agreed 
to resubmit it as a personal draft.

To reassure you, the rfc-editor did not accept the document w/o 
consulting with me, and I explained to Dominikus why it could not be 
submitted as a WG document.

-- 

john noerenberg
[e-mail]
   --------------------------------------------------------------------------
   Peace of mind isn't at all superficial, really.  It's the whole thing.
   That which produces it is good maintenance; that which disturbs it
   is poor maintenance.
   -- Zen and the Art of Motorcycle Maintenance, Robert M. Pirsig, 1974
   --------------------------------------------------------------------------


Received: by above.proper.com (8.11.3/8.11.3) id f79FP6G21094 for ietf-openpgp-bks; Thu, 9 Aug 2001 08:25:06 -0700 (PDT)
Received: from mercury.rus.uni-stuttgart.de (mercury.rus.uni-stuttgart.de [129.69.1.226]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f79FP5N21090 for <[e-mail]>; Thu, 9 Aug 2001 08:25:06 -0700 (PDT)
Received: from rusfw by mercury.rus.uni-stuttgart.de with local (Exim 3.22 #1) id 15Urfv-0001Bf-00 for [e-mail]; Thu, 09 Aug 2001 17:24:43 +0200
To: [e-mail]
Subject: Re: Reasons to include ECC to our charter
References: <[e-mail]> <[e-mail]>
From: Florian Weimer <[e-mail]>
Date: 09 Aug 2001 17:24:43 +0200
In-Reply-To: <[e-mail]> (Ben Laurie's message of "Thu, 09 Aug 2001 15:40:31 +0100")
Message-ID: <[e-mail]>
Lines: 14
User-Agent: Gnus/5.090001 (Oort Gnus v0.01) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Ben Laurie <[e-mail]> writes:

> You can't add it to the _standard_ because of restrictive licensing. I
> guess Informational RFCs are possible, but they don't make me happy -
> essentially the WG is doing free work, both technical and marketing, for
> the owner(s) of the patents.

IIRC, not all ECC stuff is patented, only curves over GF(q), q even,
which can be implemented efficiently using two-valued logic.

-- 
Florian Weimer [e-mail] University of
Stuttgart http://cert.uni-stuttgart.de/ RUS-CERT [phone]/fax
[phone]


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f79F4Wj20302 for ietf-openpgp-bks; Thu, 9 Aug 2001 08:04:32 -0700 (PDT)
Received: from smtp1.nikoma.de (smtp1.nikoma.de [212.122.128.19]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f79F4UN20298 for <[e-mail]>; Thu, 9 Aug 2001 08:04:30 -0700 (PDT)
Received: from sobolev.does-not-exist.org (dialin156.pg2-nt.dusseldorf.nikoma.de [213.54.97.156]) by smtp1.nikoma.de (8.9.3/8.9.3) with ESMTP id RAA03872; Thu, 9 Aug 2001 17:04:07 +0200 (CEST) (envelope-from [e-mail])
Received: by sobolev.does-not-exist.org (Postfix, from userid 1000) id D89B22ED15; Thu,  9 Aug 2001 17:04:05 +0200 (CEST)
Date: Thu, 9 Aug 2001 17:04:05 +0200
From: Thomas Roessler <[e-mail]>
To: Dominikus Scherkl <[e-mail]>
Cc: Ben Laurie <[e-mail]>, "openPGP e-Mail (E-Mail)" <[e-mail]>
Subject: Re: Reasons to include ECC to our charter
Message-ID: <[e-mail]>
Mail-Followup-To: Dominikus Scherkl <[e-mail]>, Ben Laurie <[e-mail]>, "openPGP e-Mail (E-Mail)" <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.3.20i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On 2001-08-09 16:49:49 +0200, Dominikus Scherkl wrote:

>The openPGP standard is exactly this - "open". So of course we can 
>add ECC (it is still reserved). Or do you mean patents on ECC? 
>That is also no Problem, because patents only apply to the 
>applications that implement the standard - they need to licence 
>the algorithms. If not licenced, the application may not support 
>ECC (but is still conform to the standard - same as for elgamal).

That is, ECC can't be a mandatory part of the standard.

-- 
Thomas Roessler                        http://log.does-not-exist.org/




Received: by above.proper.com (8.11.3/8.11.3) id f79Eo2b18879 for ietf-openpgp-bks; Thu, 9 Aug 2001 07:50:02 -0700 (PDT)
Received: from mail1.biodata.com ([62.159.113.2]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f79Eo0N18867 for <[e-mail]>; Thu, 9 Aug 2001 07:50:00 -0700 (PDT)
Received: from fra1d001.biodata.org ([10.10.1.51]) by mail1.biodata.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 9 Aug 2001 16:49:49 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: AW: Reasons to include ECC to our charter
Date: Thu, 9 Aug 2001 16:49:49 +0200
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Reasons to include ECC to our charter
Thread-Index: AcEg4WalieDgznX9R+O3lfinU+xmXAAAGDzw
From: "Dominikus Scherkl" <[e-mail]>
To: "Ben Laurie" <[e-mail]>
Cc: "openPGP e-Mail (E-Mail)" <[e-mail]>
X-OriginalArrivalTime: 09 Aug 2001 14:49:49.0825 (UTC) FILETIME=[8A4F8710:01C120E2]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id f79Eo1N18873
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

> You can't add [ECC] to the _standard_ because of restrictive
licensing.
?!?
The openPGP standard is exactly this - "open". So of course we can add
ECC (it is still reserved). Or do you mean patents on ECC?
That is also no Problem, because patents only apply to the applications
that implement the standard - they need to licence the algorithms.
If not licenced, the application may not support ECC (but is still
conform to the standard - same as for elgamal).
-- 
Dominikus Scherkl
Biodata Application Security AG
mail: [e-mail]


Received: by above.proper.com (8.11.3/8.11.3) id f79Eeva17820 for ietf-openpgp-bks; Thu, 9 Aug 2001 07:40:57 -0700 (PDT)
Received: from top.ben.algroup.co.uk (host217-33-142-49.ietf.ignite.net [217.33.142.49]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f79EesN17815 for <[e-mail]>; Thu, 9 Aug 2001 07:40:55 -0700 (PDT)
Received: from algroup.co.uk (localhost [127.0.0.1]) by top.ben.algroup.co.uk (8.11.1/8.11.1) with ESMTP id f79EeVT05778; Thu, 9 Aug 2001 15:40:31 +0100 (BST) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Thu, 09 Aug 2001 15:40:31 +0100
From: Ben Laurie <[e-mail]>
X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.1.1-STABLE-20001015 i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Dominikus Scherkl <[e-mail]>
CC: "openPGP e-Mail (E-Mail)" <[e-mail]>
Subject: Re: Reasons to include ECC to our charter
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Dominikus Scherkl wrote:
> 
> Dear openPGP Working Group,
> 
> Sorry, that I supposed my suggestions for an ECC-extension
> to the openPGP message format to be property of this WG while
> it is only a personal draft.
> 
> Now for my reasons, why this WG should include
> <draft-scherkl-openpgp-ecc-00.txt> to its charter:
> 
> I think it is time to fulfill the promise this WG made by
> reserving space for ECC and ECDSA, if we want to keep this
> standard as wide used as it is.
> 
> Long time has gone since we reserved IDs for ECC algorithms
> and many applications now support ECC but can't provide it in
> an openPGP context. So they uses other standards like S/MIME
> or proprietary protocols to provide these algorithms to those
> who want to enjoy their advantages.
> 
> Different sets of ECC parameters have now been tested long
> enough to outsource all trivialy (and many not so trivial)
> cases that won't provide sufficient security, so ECC becomes
> a "well known" algortithm.
> In this light the somewhat slightly advantages "short keys"
> and "high performance" gain weight due to the lack of
> disadvantages.
> 
> Therefore I'm convinced we can include it in the standard
> without high probability to compromise our security goals.
> 
> The attached draft is thought to be fully conform with the
> openPGP format and even some other standards, and it defines
> all elliptic curves so that no greater changes in the
> future are expected (it keeps no further gaps in the ECC
> definiton as some older suggestions have done).
> If it isn't, I'm sure we can make it with small efford.
> 
> At all, the openPGP standard can only gain by adding this
> draft to the charter.

You can't add it to the _standard_ because of restrictive licensing. I
guess Informational RFCs are possible, but they don't make me happy -
essentially the WG is doing free work, both technical and marketing, for
the owner(s) of the patents.

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html


Received: by above.proper.com (8.11.3/8.11.3) id f79BdSH06644 for ietf-openpgp-bks; Thu, 9 Aug 2001 04:39:28 -0700 (PDT)
Received: from mail1.biodata.com ([62.159.113.2]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f79BdRN06640 for <[e-mail]>; Thu, 9 Aug 2001 04:39:28 -0700 (PDT)
Received: from fra1d001.biodata.org ([10.10.1.51]) by mail1.biodata.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 9 Aug 2001 13:38:26 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: AW: Draft openPGP ECC formats
Date: Thu, 9 Aug 2001 13:38:26 +0200
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Draft openPGP ECC formats
Thread-Index: AcEgwau6MR5HAOMiTt+B1yiXqqY7mQABcLqQ
From: "Dominikus Scherkl" <[e-mail]>
To: "openPGP e-Mail (E-Mail)" <[e-mail]>
X-OriginalArrivalTime: 09 Aug 2001 11:38:26.0287 (UTC) FILETIME=[CD96AFF0:01C120C7]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id f79BdSN06641
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Hi!

> This implies severe process failure
>
I would enjoy _real_ critics on the content of the
draft very much more than riging on "process failures".

Best regards.
-- 
Dominikus Scherkl
Biodata Application Security AG
mail: [e-mail]



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f79BXgJ06560 for ietf-openpgp-bks; Thu, 9 Aug 2001 04:33:42 -0700 (PDT)
Received: from mail1.biodata.com ([62.159.113.2]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f79BXeN06556 for <[e-mail]>; Thu, 9 Aug 2001 04:33:40 -0700 (PDT)
Received: from fra1d001.biodata.org ([10.10.1.51]) by mail1.biodata.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 9 Aug 2001 13:33:28 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C120C7.1C1701C3"
Subject: Reasons to include ECC to our charter
Date: Thu, 9 Aug 2001 13:33:28 +0200
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Draft openPGP ECC formats
Thread-Index: AcEgMu8kU9jpylGORk6/IlomTWd8cwAjN0+w
From: "Dominikus Scherkl" <[e-mail]>
To: "openPGP e-Mail (E-Mail)" <[e-mail]>
X-OriginalArrivalTime: 09 Aug 2001 11:33:28.0565 (UTC) FILETIME=[1C21EA50:01C120C7]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C120C7.1C1701C3
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Dear openPGP Working Group,

Sorry, that I supposed my suggestions for an ECC-extension
to the openPGP message format to be property of this WG while
it is only a personal draft.


Now for my reasons, why this WG should include
<draft-scherkl-openpgp-ecc-00.txt> to its charter:

I think it is time to fulfill the promise this WG made by
reserving space for ECC and ECDSA, if we want to keep this
standard as wide used as it is.

Long time has gone since we reserved IDs for ECC algorithms
and many applications now support ECC but can't provide it in
an openPGP context. So they uses other standards like S/MIME
or proprietary protocols to provide these algorithms to those
who want to enjoy their advantages.

Different sets of ECC parameters have now been tested long
enough to outsource all trivialy (and many not so trivial)
cases that won't provide sufficient security, so ECC becomes
a "well known" algortithm.
In this light the somewhat slightly advantages "short keys"
and "high performance" gain weight due to the lack of
disadvantages.

Therefore I'm convinced we can include it in the standard
without high probability to compromise our security goals.

The attached draft is thought to be fully conform with the
openPGP format and even some other standards, and it defines
all elliptic curves so that no greater changes in the
future are expected (it keeps no further gaps in the ECC
definiton as some older suggestions have done).
If it isn't, I'm sure we can make it with small efford.

At all, the openPGP standard can only gain by adding this
draft to the charter.

Best Regards
--=20
Dominikus Scherkl
Biodata Application Security AG
mail: [e-mail]

------_=_NextPart_001_01C120C7.1C1701C3
Content-Type: text/plain;
	name="draft-scherkl-openpgp-ecc-00.txt"
Content-Transfer-Encoding: base64
Content-Description: draft-scherkl-openpgp-ecc-00.txt
Content-Disposition: attachment;
	filename="draft-scherkl-openpgp-ecc-00.txt"

DQpOZXR3b3JrIFdvcmtpbmcgR3JvdXAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIEQuIFNjaGVya2wNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAg
ICAgQmlvZGF0YSBBcHBsaWNhdGlvbiBTZWN1cml0eSBBRw0KRXhwaXJlcyBGZWJydWFyeSAyMDAy
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDAxDQpVcGRh
dGVzOiBSRkMgMjQ0MA0KDQogICAgICAgICAgICAgICBPcGVuUEdQIEVsbGlwdGljIEN1cnZlIEFs
Z29yaXRobSBGb3JtYXRzDQogICAgICAgICAgICAgICAgICA8ZHJhZnQtc2NoZXJrbC1vcGVucGdw
LWVjYy0wMC50eHQ+DQoNClN0YXR1cyBvZiB0aGlzIE1lbW8NCg0KICAgVGhpcyBkb2N1bWVudCBp
cyBhbiBJbnRlcm5ldC1EcmFmdCBhbmQgaXMgc3ViamVjdCB0byBhbGwgcHJvdmlzaW9ucw0KICAg
b2YgU2VjdGlvbiAxMCBvZiBSRkMyMDI2IFs4XS4NCiANCiAgIEludGVybmV0LURyYWZ0cyBhcmUg
d29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nDQogICBUYXNrIEZv
cmNlIChJRVRGKSwgaXRzIGFyZWFzLCBhbmQgaXRzIHdvcmtpbmcgZ3JvdXBzLiBOb3RlIHRoYXQg
b3RoZXINCiAgIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlIHdvcmtpbmcgZG9jdW1lbnRzIGFz
IEludGVybmV0LURyYWZ0cy4NCg0KICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVu
dHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzDQogICBhbmQgbWF5IGJlIHVwZGF0
ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueQ0KICAg
dGltZS4gSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVy
ZW5jZQ0KICAgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndvcmsgaW4g
cHJvZ3Jlc3MuIg0KDQogICBZb3UgY2FuIGdldCB0aGlzIGRvY3VtZW50IGF0IGh0dHA6Ly9kb3du
bG9hZC5iaW9kYXRhLmNvbS9kb2N1bWVudHMvDQogICBkcmFmdC1zY2hlcmtsLW9wZW5wZ3AtZWNj
LTAwLnR4dA0KDQogICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LURyYWZ0cyBjYW4gYmUg
YWNjZXNzZWQgYXQNCiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvMWlkLWFic3RyYWN0cy5odG1sDQoN
CiAgIFRoZSBsaXN0IG9mIEludGVybmV0LURyYWZ0IFNoYWRvdyBEaXJlY3RvcmllcyBjYW4gYmUg
YWNjZXNzZWQgYXQNCiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwNCg0KQWJzdHJh
Y3QNCg0KICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIHdoaWNoIGFsZ29yaXRobSBzcGVjaWZpYyBw
YXJhbWV0ZXJzIGFyZSBuZWVkZWQNCiAgIGZvciBlbGxpcHRpYyBjdXJ2ZSBjaXBoZXIgKEVDQykg
YW5kIGVsbGlwdGljIGN1cnZlIGRpZ2l0YWwgc2lnbmF0dXJlDQogICBhbGdvcml0aG0gKEVDRFNB
KSBhbmQgaG93IHRoZXkgaGF2ZSB0byBiZSBzdG9yZWQgaW4gb3BlblBHUCBwYWNrZXRzLg0KICAg
VGhlcmVmb3JlIGl0IGlzIGFuIHN1cHBsZW1lbnQgdG8gdGhlIG9wZW5QR1AgbWVzc2FnZSBmb3Jt
YXQgWzFdLg0KICAgSXQgYWxzbyBkZWZpbmVzIHdoaWNoIGNoZWNrcyBhcmUgbmVlZGVkIHRvIHZh
bGlkYXRlIEVDQyBhbmQgRUNEU0ENCiAgIGtleXMgYW5kIHdoaWNoICJ0b3AtbGV2ZWwiIG9wZXJh
dGlvbnMgbXVzdCBiZSBwZXJmb3JtZWQgZm9yDQogICBlbmNyeXB0aW9uL2RlY3J5cHRpb24gYW5k
IHNpZ25pbmcvc2lnbmF0dXJlIHZlcmlmaWNhdGlvbi4gQnV0IGl0DQogICBnaXZlcyBubyBhZHZp
Y2VzIGhvdyB0byBpbXBsZW1lbnQgdGhlc2UgY2hlY2tzIGFuZCBvcGVyYXRpb25zLCBub3INCiAg
IHRoZSB1bmRlcmx5aW5nIG1hdGhlbWF0aWNzLiBUbyBkbyB0aGlzLCBsb29rIGZvciBleGFtcGxl
IGF0IElFRUUNCiAgIFAxMzYzIFsyXS4NCiAgIA0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNClNjaGVy
a2wgICAgICAgICAgICAgICAgICAgICBTdGFuZGFyZHMgVHJhY2sgICAgICAgICAgICAgICAgICAg
ICBbUGFnZSAxXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICBPcGVuUEdQIEVDQyBGb3Jt
YXRzICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDAxDQoNClRhYmxlIG9mIENvbnRlbnRzDQoNCiAg
ICAgICAgIFN0YXR1cyBvZiB0aGlzIE1lbW8gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIDENCiAgICAgICAgIEFic3RyYWN0ICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIDENCiAgICAgICAgIFRhYmxlIG9mIENvbnRlbnRzICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDINCiAgIDEuICAgIEludHJv
ZHVjdGlvbiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDMN
CiAgIDEuMS4gIFRlcm1zICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIDMNCiAgIDIuICAgIEVsbGlwdGljIEN1cnZlIERvbWFpbiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDMNCiAgIDMuICAgIEJhc2lzIFJlcHJlc2VudGF0
aW9ucyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDQNCiAgIDMuMS4gIFBy
aW1lIEZpZWxkcyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IDUNCiAgIDMuMi4gIFBvbHlub21pYWwgQmFzZXMgb2YgQ2hhci0yIEZpZWxkcyAgICAgICAgICAg
ICAgICAgICAgICAgICAgIDUNCiAgIDMuMy4gIEdhdXNzaWFuIE5vcm1hbCBCYXNlcyBvZiBDaGFy
LTIgRmllbGRzICAgICAgICAgICAgICAgICAgICAgIDUNCiAgIDMuNC4gIE9kZCBFeHRlbnNpb24g
RmllbGRzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDYNCiAgIDQuICAg
IFBhcmFtZXRlciBGb3JtYXQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIDYNCiAgIDQuMS4gIFplcm8gTVBJICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIDYNCiAgIDQuMi4gIE5hbWVzICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDYNCiAgIDQuMy4gIEN1cnZlIFBvaW50
cyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDYNCiAgIDQu
NC4gIEZpZWxkIERlc2NyaXB0b3IgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIDcNCiAgIDUuICAgIEFsZ29yaXRobSBTcGVjaWZpYyBGaWVsZHMgZm9yIEVDQyBhbmQg
RUNEU0EgUHVibGljIEtleXMgICAgIDgNCiAgIDYuICAgIEFsZ29yaXRobSBTcGVjaWZpYyBGaWVs
ZHMgZm9yIEVDQyBhbmQgRUNEU0EgU2VjcmV0IEtleXMgICAgIDgNCiAgIDcuICAgIEVDQyAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDgNCiAg
IDcuMS4gIEVDQyBFbmNyeXB0aW9uICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIDgNCiAgIDcuMi4gIEVDQyBEZWNyeXB0aW9uICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIDgNCiAgIDcuMy4gIEFsZ29yaXRobSBTcGVjaWZpYyBG
aWVsZHMgZm9yIEVDQyBFbmNyeXB0aW9uICAgICAgICAgICAgICAgIDkNCiAgIDguICAgIEVDRFNB
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDkN
CiAgIDguMS4gIEVDRFNBIFNpZ25hdHVyZSBHZW5lcmF0aW9uICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIDkNCiAgIDguMi4gIEVDRFNBIFNpZ25hdHVyZSBWZXJpZmljYXRpb24gICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDkNCiAgIDguMy4gIEFsZ29yaXRobSBTcGVjaWZp
YyBGaWVsZHMgZm9yIEVDRFNBIFNpZ25hdHVyZXMgICAgICAgICAgICAgIDkNCiAgIDkuICAgIE5h
bWVkIEN1cnZlcyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IDkNCiAgIDkuMS4gIEN1cnZlcyBvdmVyIENoYXItMiBGaWVsZHMgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIDkNCiAgIDkuMi4gIEN1cnZlcyBvdmVyIFByaW1lIEZpZWxkcyAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMTUNCiAgIDkuMy4gIEN1cnZlcyBvdmVyIE9k
ZCBFeHRlbnNpb24gRmllbGRzICAgICAgICAgICAgICAgICAgICAgICAgICAgMTgNCiAgIDkuNC4g
IEFkZGluZyBPd24gTmFtZWQgQ3VydmVzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgMTkNCiAgIDkuNS4gIFJldm9jZWQgQ3VydmVzICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgMTkNCiAgIDEwLiAgIFNlY3V0aXR5IENvbnNpZGVyYXRpb25zICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMTkNCiAgIDExLiAgIFJlZmVyZW5jZXMg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMjANCiAgIDEy
LiAgIEF1dGhvcnMgQWRkcmVzc2VzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgMjANCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KU2NoZXJrbCAgICAgICAg
ICAgICAgICAgICAgIFN0YW5kYXJkcyBUcmFjayAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDJd
DQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgIE9wZW5QR1AgRUNDIEZvcm1hdHMgICAgICAg
ICAgICAgICAgQXVndXN0IDIwMDENCg0KMS4gSW50cm9kdWN0aW9uDQoNCiAgIFRoZSBvcGVuUEdQ
IG1lc3NhZ2UgZm9ybWF0IFsxXSByZXNlcnZlZCBJRHMgZm9yIGVsbGlwdGljIGN1cnZlDQogICBh
bGdvcml0aG1zLiBUaGlzIGRvY3VtZW50IG5vdyBkZWZpbmVzIHRoZWlyIHN0b3JhZ2UgZm9ybWF0
Lg0KICAgDQogICBFbGxpcHRpYyBjdXJ2ZXMgY2FuIGJlIGRlZmluZWQgb3ZlciBhbnkgbnVtYmVy
ZmllbGQgKGZpbml0ZSBvcg0KICAgaW5maW5pdGUpLCBhbmQgdGhlIG1vcmUgY29tcGxpY2F0ZWQg
dGhlIGZpZWxkIGlzLCB0aGUgbW9yZSBkaWZmZXJlbnQNCiAgICJoYW5keSIgYmFzaXMgcmVwcmVz
ZW50YXRpb25zIG9mIGl0IGNhbiBiZSBkZWZpbmVkLCBmb3IgY2FzZXMgb2YNCiAgIHNwZWNpYWwg
aW50ZXJlc3QuDQogICBUaGlzIGRyYWZ0IGRlZmluZXMgcmVwcmVzZW50YXRpb25zIGZvciBhbGwg
ZmluaXRlIGZpZWxkcyBwbHVzDQogICBvcHRpbWl6ZWQgZm9ybXMgZm9yIHNvbWUgc3BlY2lhbCBj
YXNlcyB0aGF0IHByb3ZpZGUgZmFzdCBhcml0aG1ldGljLg0KDQogICBPbiBlbGxpcHRpYyBjdXJ2
ZXMgYSBzY2FsYXItbXVsdGlwbGljYXRpb24gY2FuIGJlIGRlZmluZWQgKHRoYXQgaXM6DQogICBt
dWx0aXBsZXMgb2YgcG9pbnRzKSwgYW5kIGl0J3MgYmVoYXZpb3Igb3ZlciBmaW5pdGUgZmllbGRz
IGlzDQogICBlcnJhdGljIGVub3VnaCB0byB0YWtlIGl0IGFzIHB1YmxpYyBrZXkgZW5jcnlwdGlv
bjogeW91IGNhbiBtdWx0aXBseQ0KICAgcG9pbnRzLCBidXQgeW91IGNhbid0IHNheSB0aGUgbXVs
dGlwbGUgb2Ygd2hpY2ggcG9pbnQgeW91IGdvdA0KICAgd2l0aG91dCBjaGVja2luZyBlYWNoIHBv
aW50ICh0aGlzIGlzIGNhbGxlZCB0aGUgImVsbGlwdGljIGN1cnZlDQogICBkaXNjcmV0ZSBsb2dh
cml0aG0gcHJvYmxlbSIgb3IgRUMvREwtcHJvYmxlbSkuDQoNCiAgIFRoZSBhZHZlbnRhZ2Ugb2Yg
dGhpcyBtdWx0aXBsaWNhdGlvbiBpcywgdGhhdCBpdCdzIG11Y2ggbW9yZSBlcnJhdGljDQogICB0
aGFuIFJTQSBleHBvbmVudGlhdGlvbiwgd2hpY2ggYWxsb3dlcyB0byB0YWtlIHNob3J0ZXIga2V5
cyB3aXRob3V0DQogICBsb3NzIG9mIHNlY3VyaXR5LiBBbm90aGVyIGFkdmVudGFnZSBpcyB0aGUg
aGlnaCBwZXJmb3JtYW5jZSBpZg0KICAgc3BlY2lhbCBmaWVsZHMgYXJlIHVzZWQuDQogICBBIGtp
bmQgb2YgZGlzYWR2ZW50YWdlIGlzIHRoZSBtdWNoIG1vcmUgY29tcGxleCBtYXRoZW1hdGljcyBu
ZWVkZWQsDQogICBlc3BlY2lhbHkgZm9yIGdlbmVyYXRpbmcgRUMgZG9tYWlucy4gQWxzbyB0aGUg
aGlnaCBwZXJmb3JtYW5jZSBpcw0KICAgbG9zdCBpZiBhbiBpbXBsZW1lbnRhdGlvbiBpcyBub3Qg
b3B0aW1pemVkIGZvciB0aGUgZmllbGQgdXNlZCBieSBhDQogICBjb21tdW5pY2F0aW9uIHBhcnRu
ZXIuDQoNCjEuMS4gVGVybXMNCg0KICAgVGhpcyBkb2N1bWVudCB1c2VzIHRoZSB0ZXJtcyAiTVVT
VCIsICJTSE9VTEQiIGFuZCAiTUFZIiBhcyBkZWZpbmVkIGluDQogICBSRkMgMjExOSBbOV0sIGFs
b25nIHdpdGggdGhlIG5lZ2F0ZWQgZm9ybXMgb2YgdGhvc2UgdGVybXMuDQoNCiAgIEluIHRoZSB3
aG9sZSBkb2N1bWVudCB0aGUgc3ltYm9sIF4gaXMgdXNlZCBhcyB0aGUgZXhwb25lbnRpYXRpb24N
CiAgIG9wZXJhdG9yLiBFLmcuIDJeNy0xIG1lYW5zIDEyNyAob25lIGJlbG93IHRoZSBzZXZlbnRo
IHBvd2VyIG9mIHR3bykuDQoNCjIuIEVsbGlwdGljIEN1cnZlIERvbWFpbg0KICAgDQogICBUaGVy
ZSBpcyBhIHNldCBvZiBwYXJhbWV0ZXJzIHRoYXQgbWF5IGJlIGNvbW1vbiBub3Qgb25seSB0byBv
bmUgYnV0DQogICBmb3IgbWFueSAob3IgZXZlbiBhbGwpIGtleXMsIHdoaWNoIHdlIGNhbGwgdGhl
IEVDIGRvbWFpbi4NCiAgIEl0IGNvbnNpc3RzIG9mDQogICAtIHNvbWUgZmluaXRlIGZpZWxkIEYg
KGRlZmluZWQgYnkgaXQncyBvcmRlciBwXm0gYW5kIGl0J3MgYXJpdGhtZXRpYw0KICAgICBlLmcu
IHJlZHVjdGlvbiBwb2x5bm9taWFsIG9yIG11bHRpcGxpY2F0aW9uIHR5cGUgLSBzZWUgYmVsb3cp
LA0KICAgLSBhbiBlbGxpcHRpYyBjdXJ2ZSBFIGRlZmluZWQgYnkgdHdvIGVsZW1lbnRzIGEsIGIg
b2YgRiwNCiAgIC0gYSBwb2ludCBHIG9uIEUgZGVmaW5lZCBieSBpdCdzIGNvb3JkaW5hdGVzIHgs
IHkgZWxlbWVudHMgb2YgRiwNCiAgIC0gYSBwcmltZSBudW1iZXIgbiB3aXRoIG4qRyA9IDAgKHRo
ZSBvcmRlciBvZiBHKSBhbmQNCiAgIC0gYSBjb2ZhY3RvciBoIHdpdGggb25seSBzbWFsbCBwcmlt
ZSBmYWN0b3JzIGFuZCBoKm4gaXMgdGhlIG51bWJlcg0KICAgICBvZiBwb2ludHMgb24gRSAodGhl
IG9yZGVyIG9mIEUpLg0KICAgICANCiAgIEFsbCBtZW50aW9uZWQgY29uZGl0aW9ucyBNVVNUIGJl
IHRlc3RlZCwgdGhhdCBpczoNCiAgIC0gdGhlIGdyb3VuZGZpZWxkIG9yZGVyIHAgaXMgcHJpbWUg
YW5kIHRoZSBwb2x5bm9taWFsIGlzIGlycmVkdWNpYmxlLA0KICAgLSBhIGFuZCBiIGRlZmluaW5n
IGEgY3VydmUgb3ZlciBGLA0KDQpTY2hlcmtsICAgICAgICAgICAgICAgICAgICAgU3RhbmRhcmRz
IFRyYWNrICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgM10NCgwNCkludGVybmV0LURyYWZ0ICAg
ICAgICAgICAgT3BlblBHUCBFQ0MgRm9ybWF0cyAgICAgICAgICAgICAgICBBdWd1c3QgMjAwMQ0K
DQogICAtIEcgbGllcyBvbiB0aGUgY3VydmUgYW5kIGlzIG5vdCAwICh0aGUgcG9pbnQgYXQgaW5m
aW5pdHkpLA0KICAgLSBuIGlzIHByaW1lIGFuZCBuKkcgaXMgMCAodGhhdCB0YWtlcyB0aW1lISkg
YW5kDQogICAtIG4qaCBpcyB0aGUgY3VydmUgb3JkZXIuDQogICANCiAgIEFkZGl0aW9uYWwgdGhl
cmUgYXJlIHNvbWUgc2VjdXJpdHkgY29uZGl0aW9ucyB0aGUgZG9tYWluIE1VU1QNCiAgIHNhdGlz
Znk6DQoNCiAgIC0gVGhlIGN1cnZlIG9yZGVyIE1VU1QgTk9UIGVxdWFsIHRoZSBmaWVsZCBvcmRl
ciwNCiAgIC0gVGhlIGV4cG9uZW50IG0gKGV4dGVuc2lvbiBkZWdyZWUpIFNIT1VMRCBiZSBwcmlt
ZSBbN10gKG9yIG09MSksDQogICAtIHRoZSBwb2ludCBvcmRlciBNVVNUIGJlIGdyZWF0ZXIgdGhh
biAyXjE2MCBhbmQgaXQncyBzcXVhcmUgTVVTVA0KICAgICBiZSBncmVhdGVyIHRoYW4gZm91ciB0
aW1lcyB0aGUgZmllbGQgb3JkZXIgKGl0J3MgYml0bGVuIG11c3QgYmUNCiAgICAgYXQgbGVhc3Qg
dHdvIGJpdCBsb25nZXIgdGhhbiBoYWxmIHRoZSBmaWVsZCBiaXRsZW4pLA0KICAgLSBUaGUgTU9W
IGNvbmRpdGlvbiBbM10gTVVTVCBiZSB0cnVlICh0aGF0IGlzOiBzbWFsbCBwb3dlcnMgb2YgdGhl
DQogICAgIGZpZWxkIG9yZGVyIE1VU1QgTk9UIGJlIGVxdWl2YWxlbnQgdG8gMSBtb2R1bG8gdGhl
IHBvaW50IG9yZGVyKSwNCiAgIC0gRnVydGhlciBjb25kaXRpb25zIG1heSBiZSBhZGRlZCBoZXJl
IGlmIG1vcmUgd2VhayBjdXJ2ZXMgYXJlDQogICAgIGRpc2NvdmVyZWQuDQogICAgIA0KICAgQW4g
RUMgZG9tYWluIHRoYXQgaXMgdmVyaWZpZWQgY2FuIGJlIGdpdmVuIGEgbmFtZS4gQSBuYW1lZCBj
dXJ2ZSBpcw0KICAgc2ltcGx5IHRoZSBFQyBkb21haW4gYXNzaWduZWQgdG8gdGhhdCBuYW1lLiBJ
bXBsZW1lbnRhdGlvbnMgU0hPVUxEDQogICBwcm92aWRlIHRoZSBuYW1lZCBjdXJ2ZXMgbWVudGlv
bmVkIGluIHNlY3Rpb24gOS4NCg0KMy4gQmFzaXMgUmVwcmVzZW50YXRpb25zDQoNCiAgIEFueSBm
aW5pdGUgZmllbGQgY2FuIGJlIHJlcHJlc2VudGVkIGJ5IHRocmVlIHZhbHVlczogYSBwcmltZSBw
LA0KICAgYW4gZXhwb25lbnQgbSAoY2FsbGVkIHRoZSBleHRlbnNpb24gZGVncmVlKSBhbmQgYSBt
b25pYyBpcnJlZHVjaWJsZQ0KICAgcG9seW5vbWlhbCBmIG9mIGRlZ3JlZSBtLiBCdXQgc3BlY2lh
bCByZXByZXNlbnRhdGlvbnMgYWxsb3cgdXMgdG8NCiAgIHNocmluayB0aGUgc3RvcmFnZSBuZWVk
Og0KICAgRm9yIGNoYXItMiBmaWVsZHMgRigyXm0pIHA9Miwgc28gd2UgY2FuIG9tbWl0IGl0LiBG
b3IgcHJpbWUgZmllbGRzDQogICBGKHApIG09MSBhbmQgd2UgbmVlZCBubyBwb2x5bm9taWFsICh1
c2luZyB4IGFzIHJlZHVjdGlvbiBwb2x5bm9taWFsDQogICBpcyB3aGF0IHdlIGNhbGwgdGhlIG9y
ZGluYXJ5ICJtb2R1bG8gYXJpdGhtZXRpYyIgLSB1c2luZyB4KzEgd291bGQNCiAgIGxlYWQgdG8g
YSBkaWZmZXJlbnQgYXJpdGhtZXRpYykuIEFsc28gdGhlcmUgYXJlIG1vcmUgbm90IGFzIG9idmlv
dXMNCiAgIHNwZWNpYWwgY2FzZXM6DQogICANCiAgIC0gSWYgcCBpcyBuZWFyIHNvbWUgdHdvcG93
ZXIgaXQgY2FuIGJlIHN0b3JlZCBhcyAyXnIgKyBjIHdpdGggc21hbGwNCiAgICAgaW50ZWdlcnMg
ciBhbmQgYyAoYyBjYW4gYmUgbmVnYXRpdmUhISkuDQogICAtIEZvciBwPTIgZXhpc3RzIGlycmVk
dWNpYmxlIHBvbHlub21pYWxzIHdpdGggb25seSB0aHJlZSAodHJpbm9taWFsDQogICAgIGJhc2Vz
IC0gbm90IGFsd2F5cykgb3IgZml2ZSBzZXQgYml0cyAocGVudGFub21pYWwgYmFzZXMpLg0KICAg
LSBGb3Igc29tZSAyXm0gdGhlIGFsbC1vbmUgcG9seW5vbWlhbCBpcyBpcnJlZHVjaWJlIChjaXJj
dWxhciBkdWFsDQogICAgIGJhc2lzKS4NCiAgIC0gRm9yIG1hbnkgcF5tIGV4aXN0cyBpcnJlZHVj
aWJsZSBiaW5vbWlhbHMgZih0KSA9IHRebSAtIHcgd2l0aCBzbWFsbA0KICAgICB3IChvcHRpbWFs
IGV4dGVuc2lvbiBmaWVsZHMpLg0KICAgDQogICBBbGwgb2YgdGhlc2UgcmVwcmVzZW50YXRpb25z
IG5vdCBvbmx5IHJlcXVpcmUgbGVzcyBzcGFjZSB0byBzdG9yZSBidXQNCiAgIG1haW5seSBwcm92
aWRlIChtdWNoKSBmYXN0ZXIgYXJpdGhtZXRpYyBhcyB0aGUgZ2VuZXJhbCBjYXNlLg0KDQogICBG
b3IgRigyXm0pIGFsc28gb25lIGNvbXBsZXRlbHkgZGlmZmVyZW50IGFwcHJvYWNoIGlzIGNvbW1v
bjogVGFrZSBtDQogICBhcyB0aGUgZGltZW5zaW9uIG9mIGEgdmVjdG9yIHNwYWNlLCBzbyB0aGF0
IGVhY2ggZWxlbWVudCBjYW4gYmUNCiAgIHJlcHJlc2VudGVkIGFzIGxpbmVhciBjb21iaW5hdGlv
biBvZiBtICJpbmRlcGVuZGVudCIgYmFzaXMgZWxlbWVudHMuDQogICBJZiBlYWNoIGJhc2lzIGVs
ZW1lbnQgaXMgdGhlIHNxdWFyZSBvZiBzb21lIG90aGVyIGJhc2lzIGVsZW1lbnQgdGhpcw0KICAg
aXMgY2FsbGVkIGEgIm5vcm1hbCIgYmFzaXMuIElmIGFkZGl0aW9uYWx5IHRoaXMgYmFzaXMgcHJv
dmlkZXMgYQ0KICAgc3BlY2lhbCBtdWx0aXBsaWNhdGlvbiBmb3JtdWxhIG9mIHR5cGUgVCwgaXQg
aXMgY2FsbGVkIGEgImdhdXNzaWFuIg0KICAgbm9ybWFsIGJhc2lzLiBUaGlzIGlzIHN1cHBvcnRl
ZCwgYmVjYXVzZSBpdCBpcyB2ZXJ5IGZhc3QgaW4gaGFyZHdhcmUNCg0KU2NoZXJrbCAgICAgICAg
ICAgICAgICAgICAgIFN0YW5kYXJkcyBUcmFjayAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDRd
DQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgIE9wZW5QR1AgRUNDIEZvcm1hdHMgICAgICAg
ICAgICAgICAgQXVndXN0IDIwMDENCg0KICAgYW5kIHRoZXJlZm9yZSBtYW55IGltcGxlbWVudGF0
aW9ucyBlc3BlY2lhbHkgb24gc21hcnRjYXJkcyB1c2UgdGhpcw0KICAgcmVwcmVzZW50YXRpb24u
IChUaGVzZSBiYXNlcyByZWx5IGFsc28gb24gYW4gaXJyZWR1Y2libGUgcG9seW5vbWlhbA0KICAg
ZiwgYnV0IGl0IGlzIG5vdCBuZWVkZWQgZm9yIG1vc3QgYXJpdGhtZXRpYyBhbmQgZm9yIFQ+MiBp
dCBpcw0KICAgY29tcGxpY2F0ZWQgdG8gY2FsY3VsYXRlIGYpLg0KICAgDQogICBJbiB0aGUgZm9s
bG93aW5nIHRleHQgYWxsIHBhcmFtZXRlcnMgYXJlIHNob3J0ZW5lZCBieSB0aGUgc2FtZQ0KICAg
bGV0dGVycyBhcyBtZW50aW9uZWQgYWJvdmUuDQoNCjMuMS4gUHJpbWUgRmllbGRzDQoNCiAgIE5v
IHBhcmFtZXRlcnMgZXhjZXB0IHRoZSBwcmltZSBpdHNlbGYgYXJlIHJlcXVpcmVkIGZvciBwcmlt
ZSBmaWVsZHMuDQogICBTdGFuZGFyZCBtb2R1bG8gYXJpdGhtZXRpYyBpcyB1c2VkLg0KICAgDQog
ICBJZiBwIGlzIG5lYXIgc29tZSB0d29wb3dlciBwID0gMl5yICsgYywgdGhlIGludGVnZXJzIHIg
YW5kIGMgYXJlDQogICBzdG9yZWQgaW5zdGVhZCBvZiBwIChwc2V1ZG8gbWVyc2VubmUgcHJpbWUg
ZmllbGQpLiBUaGUgc2lnbiBvZiBjIGlzDQogICBpbmRpY2F0ZWQgYnkgZGlmZmVyZW50IGZpZWxk
IGRlc2NyaXB0b3JzIChzZWUgc2VjdGlvbiA0LjQpLiBUaGlzIGlzDQogICBuZXNzZXNzYXJ5IGJl
Y2F1c2UgdGhlIE1QSSBmb3JtYXQgY2FuJ3Qgc3RvcmUgbmVnYXRpdmUgbnVtYmVycy4NCg0KMy4y
LiBQb2x5bm9taWFsIEJhc2VzIG9mIENoYXItMiBGaWVsZHMNCg0KICAgRm9yIGFueSByZXByZXNl
bnRhdGlvbiBvZiBGKDJebSkgdGhlIHBhcmFtZXRlciBtIGlzIG5lZWRlZC4gRWFjaA0KICAgaXJy
ZWR1Y2libGUgcG9seW5vbWlhbCBoYXMgdGhlIGhpZ2hlc3QgYW5kIGxvd2VzdCBiaXQgc2V0IGFu
ZCB0aGUNCiAgIG51bWJlciBvZiBzZXQgYml0cyBpcyBhbHdheXMgb2RkLg0KDQogICBVc2luZyB0
aGUgYWxsLW9uZSBwb2x5bm9taWFsIGlzIGNhbGxlZCB0aGUgImNpcmN1bGFyIGR1YWwgYmFzaXMi
IG9yDQogICAiQ0RCIi4gSXQgcmVxdWlyZXMgbm8gZnVydGhlciBwYXJhbWV0ZXJzLg0KDQogICBV
c2luZyBhIHRyaW5vbWlhbCBpcyBjYWxsZWQgInRyaW5vbWlhbCBiYXNpcyIgb3IgIlRQQiIuIFdl
IG5lZWQgdG8NCiAgIGtub3cgdGhlIHBvc2l0aW9ucyBvZiB0aGUgdGhyZWUgYml0cy4gVGhhdCBh
cmUgMCwgbSBhbmQgc29tZSBvdGhlcg0KICAgYml0IGsuIFRoZXJlZm9yZSB0aGUgYml0LXBvc2l0
aW9uIGsgaXMgcmVxdWlyZWQgYXMgcGFyYW1ldGVyLg0KDQogICBVc2luZyBhIHBlbnRhbm9taWFs
ICgicGVudGFub21pYWwgYmFzaXMiIG9yICJQUEIiKSByZXF1aXJlcyB0aHJlZQ0KICAgcGFyYW1l
dGVycyBrMSwgazIsIGszLg0KDQogICBVc2luZyBhbiBhcmJpdHJhcnkgaXJyZWR1Y2libGUgcG9s
eW5vbWlhbCAoInBvbHlub21pYWwgYmFzaXMiIG9yDQogICAiUEIiKSByZXF1aXJlcyB0aGF0IGNv
bXBsZXRlIHBvbHlub21pYWwgZiBhcyBwYXJhbWV0ZXIgKHRoZSBoaWdoZXN0DQogICBjb2VmZmlj
aWVudCB0Xm0gd2hpY2ggaXMgYWx3YXlzIDEgbWF5IGJlIG9tbWl0ZWQpLg0KICAgSW1wbGVtZW50
YXRpb25zIFNIT1VMRCBhdm9pZCBhcmJpdHJhcnkgcG9seW5vbWlhbCBiYXNlcy4NCg0KMy4zLiBH
YXVzc2lhbiBOb3JtYWwgQmFzZXMgb2YgQ2hhci0yIEZpZWxkcw0KDQogICBHYXVzc2lhbiBiYXNl
cyBhcmUgY29tcGxldGVseSBkZWZpbmVkIGJ5IHRoZSBleHRlbnNpb24gZGVncmVlIG0gYW5kDQog
ICB0aGUgdHlwZSBUIG9mIHRoZWlyIG11bHRpcGxpY2F0aW9uLiBCYXNlcyB3aXRoIFQ9MSBvciBU
PTIgYXJlIGNhbGxlZA0KICAgIm9wdGltYWwgbm9ybWFsIGJhc2VzIiwgb3IgInR5cGUtSSBPTkIi
IGFuZCAidHlwZS1JSSBPTkIiLg0KICAgVGhlIG9wdGltYWwgY2FzZXMgYXJlIGNvZGVkIGluIHRo
ZSBmaWVsZCBkZXNjcmlwdG9yIChzZWUgc2VjdGlvbg0KICAgNC40KSwgZm9yIFQ+MiB0aGlzIHR5
cGUgaXMgbmVlZGVkIGFzIGFkZGl0aW9uYWwgcGFyYW1ldGVyLg0KICAgDQogICBUaGlzIHN0YW5k
YXJkIGRvZXMgbm90IHN1cHBvcnQgYXJiaXRyYXJ5IChub24tZ2F1c3NpYW4pIG5vcm1hbCBiYXNl
cy4NCiAgIEltcGxlbWVudGF0aW9ucyBTSE9VTEQgYXZvaWQgbm9uLW9wdGltYWwgbm9ybWFsIGJh
c2VzLg0KDQoNCg0KDQpTY2hlcmtsICAgICAgICAgICAgICAgICAgICAgU3RhbmRhcmRzIFRyYWNr
ICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgNV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAg
ICAgT3BlblBHUCBFQ0MgRm9ybWF0cyAgICAgICAgICAgICAgICBBdWd1c3QgMjAwMQ0KDQozLjQu
IE9kZCBFeHRlbnNpb24gRmllbGRzDQoNCiAgIE9kZCBleHRlbnNpb24gZmllbGRzIEYocF5tKSB3
aXRoIHA+MiBhbmQgbT4xIHJlcXVpcmVzIHRoZSBwYXJhbWV0ZXJzDQogICBwLCBtIGFuZCBmLiBU
aGVpciBlbGVtZW50cyBhcmUgYmVzdCByZXByZXNlbnRlZCBhcyBwb2x5bm9taWFscyBvZg0KICAg
ZGVncmVlIDwgbSB3aXRoIGNvZWZmaWNpZW50cyBpbiBGKHApLiBIb3dldmVyLCB0aGV5IGFyZSBz
dG9yZWQgYXMNCiAgIGludGVnZXJzIGkgPSBjMCArIGMxKnAgKyBjMipwXjIgKyAuLi4gKyBjKG0t
MSkqcF4obS0xKSAocC1hZGljKS4NCiAgIFRoZSBoaWdoZXN0IGNvZWZmaWNpZW50IG9mIGYgaXMg
YWx3YXlzIDEgYW5kIG1heSBiZSBvbW1pdGVkLiBUaGF0IGlzDQogICB2ZXJ5IHN0b3JhZ2UgZWZm
aWNpZW50IGlmIHRoZSBuZXh0IGZldyBjb2VmZmljaWVudHMgYXJlIHplcm8uDQoNCiAgIElmIHAg
aXMgbmVhciBzb21lIHR3b3Bvd2VyIHAgPSAyXnIgKyBjLCB0aGUgaW50ZWdlcnMgciBhbmQgYyBh
cmUNCiAgIHN0b3JlZCBpbnN0ZWFkIG9mIHAgKHR5cGUtSSBleHRlbnNpb24gZmllbGQpLiBJZiBj
IGlzIDEgb3IgLTEsIEYgaXMNCiAgIGNhbGxlZCBhIHR5cGUtSSAib3B0aW1hbCBleHRlbnNpb24g
ZmllbGQiIG9yICJPRUYiLiBUaGUgc2lnbiBvZiBjIGlzDQogICBpbmRpY2F0ZWQgYnkgZGlmZmVy
ZW50IGZpZWxkIGRlc2NyaXB0b3JzIChzZWUgc2VjdGlvbiA0LjQpLg0KICAgDQogICBJZiBGKHBe
bSkgaGFzIGFuIGlycmVkdWNpYmxlIGJpbm9taWFsIGYodCkgPSB0Xm0gLSB3LCBvbmx5IHcgaXMN
CiAgIHN0b3JlZCBpbnN0ZWFkIG9mIGYgKHR5cGUtSUkgZXh0ZW5zaW9uIGZpZWxkKS4gSWYgdyA9
IDIsIEYgaXMgY2FsbGVkDQogICBhIHR5cGUtSUkgIm9wdGltYWwgZXh0ZW5zaW9uIGZpZWxkIiBv
ciAiT0VGIi4NCiAgIEEgZmllbGQgY2FuIGJlIHR5cGUtSSBhbmQgdHlwZS1JSSBvcHRpbWFsIGF0
IHRoZSBzYW1lIHRpbWUuDQoNCjQuIFBhcmFtZXRlciBGb3JtYXQNCg0KICAgVGhlIGFsZ29yaXRo
bS1zcGVjaWZpYyBmaWVsZHMgYWxsIG91Z2h0IHRvIGJlIE1QSSdzLiBCdXQgc29tZSBvZg0KICAg
dGhlbSBhcmUgZGF0YSBjb250YWluZXJzIGluc3RlYWQgb2YgbnVtYmVycy4gVGhlIGZvbGxvd2lu
ZyBzZWN0aW9ucw0KICAgZGVmaW5lcyBob3cgdGhleSBtdXN0IGJlIGludGVycHJldGVkOg0KDQo0
LjEuIFplcm8gTVBJDQoNCiAgIFNvbWV0aW1lcyBpdCBpcyBuZWNlc3NhcnkgdG8gc3RvcmUgdGhl
IHZhbHVlIDAsIHdoaWNoIG1heSBsZWdhbHkNCiAgIG9jY3VyZSAoUkZDIDI0NDAgYWxsb3dlcyB0
aGlzIG9ubHkgaW1wbGljaXQgWzFdKS4gVGhlIHZhbHVlIDAgaXMNCiAgIGZvcm1lZCBieSB0aGUg
c3RyaW5nIG9mIG9jdGV0cyBbMDAgMDBdLiBObyBhZGRpdGlvbmFsIHplcm9zIG1heSBiZQ0KICAg
aW5zZXJ0ZWQuDQogICANCiAgIFJhdGlvbmFsOiB0aGVyZSBpcyBubyBvdGhlciB3YXkgdG8gZGV0
ZXJtaW5lIHdoZXJlIHRoZSBNUEkgc2hvdWxkDQogICBlbmQgYmVjYXVzZSBubyBub24temVybyBv
Y3RldCBpcyByZXF1aXJlZCB0byBvY2N1cmUuDQoNCjQuMi4gTmFtZXMNCg0KICAgVG8gc3RvcmUg
YSBzdHJpbmcgaW4gYW4gTVBJIGl0IGlzIHNpbXBseSBwcmVmaXhlZCBieSBpdCdzIGJpdGxlbmd0
aA0KICAgKHdpdGhvdXQgdGVybWluYXRpbmcgemVyby1vY3RldCkuIFRoYXQgaXM6IG9jdGV0cyo4
IG1pbnVzIGxlYWRpbmcNCiAgIHplcm8gYml0cyBpbiB0aGUgZmlyc3Qgb2N0ZXQgKGZvciBhc2Np
aSBuYW1lcyB0aGF0IHdpbGwgYmUgMSBvciAyKS4NCiAgIA0KICAgUmF0aW9uYWw6IFRoZXJlIGlz
IG5vIG5lZWQgdG8gYWxsb3cgb3RoZXIgZGF0YSB0eXBlcyBsaWtlIHN0cmluZ3MgaW4NCiAgIHRo
ZSBhbGdvcml0aG0gc3BlY2lmaWMgZmllbGRzLCBvbmx5IHRvIGdldCBhbiBvY3RldCBsZW5ndGgg
aW5zdGVhZA0KICAgb2YgYSBiaXRsZWd0aC4gDQoNCjQuMy4gQ3VydmUgUG9pbnRzDQoNCiAgIFBv
aW50cyBvbiBhbiBlbGxpcHRpYyBjdXJ2ZSBjb25zaXN0cyBvZiB0d28gY29vcmRpbmF0ZXMuIEJ1
dCB0byBhbnkNCiAgIGdpdmVuIHgtY29vcmRpbmF0ZSB0aGVyZSBhcmUgbWF4aW1hbCB0d28gcG9z
c2libGUgeS1jb29yZGluYXRlcy4gU28NCiAgIGl0IHN1ZmZpY2VzIHRvIHN0b3JlIG9ubHkgb25l
IHNpZ25pZmljYW50IGJpdCB2IG9mIHkgdG8gbWFrZSB0aGUNCiAgIGRlY2lzaW9uLiBUaGlzIGlz
IGNhbGxlZCB0aGUgY29tcHJlc3NlZCBmb3JtLg0KDQoNClNjaGVya2wgICAgICAgICAgICAgICAg
ICAgICBTdGFuZGFyZHMgVHJhY2sgICAgICAgICAgICAgICAgICAgICBbUGFnZSA2XQ0KDA0KSW50
ZXJuZXQtRHJhZnQgICAgICAgICAgICBPcGVuUEdQIEVDQyBGb3JtYXRzICAgICAgICAgICAgICAg
IEF1Z3VzdCAyMDAxDQoNCiAgIFRoZXJlZm9yZSBQb2ludHMgYXJlIHN0b3JlZCBhcyBhIHNpbmds
ZSBNUEkuIFRoZSBjb250YWluZWQgbnVtYmVyDQogICBpcyBpbnRlcnByZXRlZCBpbiB0aGUgZm9s
bG93aW5nIHdheToNCiAgIEl0J3MgaGlnaGVzdCBvY3RldCBpcyBhIGJpdCBmbGFnOiAwMDAwMHVj
dg0KICAgSWYgYz0xLCB2IGlzIHRoZSBjb21wcmVzc2VkIHksIGVsc2UgdiBNVVNUIGJlIDAuDQog
ICBJZiB1PTEsIGJvdGggeCBhbmQgeSBhcmUgY29udGFpbmVkIHVuY29tcHJlc3NlZCwgZWxzZSBv
bmx5IHguDQoNCiAgIElmIGJvdGggY29vcmRpbmF0ZXMgYXJlIGNvbnRhaW5lZCwgdGhleSBNVVNU
IGhhdmUgdGhlIHNhbWUgbnVtYmVyIG9mDQogICBvY3RldHMgKHBhZCB3aXRoIGxlYWRpbmcgemVy
b3MgaWYgdGhleSBkb24ndCkuIHkgaXMgc3RvcmVkIGJlaGluZCB4Lg0KICAgSXQncyBhbGxvd2Vk
IHRoYXQgYm90aCBjIGFuZCB1IGFyZSBzZXQgKGluIHRoYXQgY2FzZSB2IE1VU1QgZml0IHkpLg0K
ICAgSWYgbmVpdGhlciBjIG5vciB1IGlzIHNldCwgdGhlIGVudGlyZSB2YWx1ZSBNVVNUIGJlIDAg
KHRoZSBwb2ludCBhdA0KICAgaW5maW5pdHkpLiBJbXBsZW1lbnRhdGlvbnMgU0hPVUxEIHN0b3Jl
IHBvaW50cyBjb21wcmVzc2VkLg0KDQogICBSYXRpb25hbDogVGhpcyBmb3JtYXQgaXMgY2hvb3Nl
biBmb3IgY29tcGF0aWJpbGl0eSB3aXRoIG90aGVyIGFjdHVhbA0KICAgc3RhbmRhcmRzIGxpa2Ug
WDkuNjIgWzRdLCBYOS42MyBbNV0gYW5kIFNFQyAyIFs2XS4NCg0KNC40LiBGaWVsZCBEZXNjcmlw
dG9yDQoNCiAgIFdlIGRpc3Rpbmd1aXNoIGJldHdlZW4gc2V2ZXJhbCBraW5kcyBvZiBmaWVsZCBy
ZXByZXNlbnRhdGlvbnMgdGhhdA0KICAgcmVxdWlyZSBkaWZmZXJlbnQgcGFyYW1ldGVycy4gVGhp
cyBpcyBkZXRlcm1pbmVkIGJ5IGEgZmllbGQNCiAgIGRlc2NyaXB0b3IgRC4gSW1wbGVtZW50YXRp
b25zIFNIT1VMRCBzdG9yZSB0aGUgaW5mb3JtYXRpb24gYWx3YXlzIGluDQogICB0aGUgYmVzdCBm
aXR0aW5nIGZvcm0sIGJlY2F1c2UgRCBpcyBhbHNvIGFuIG9wdGltaXphdGlvbiBoaW50Lg0KICAg
RCBtYXkgdGFrZSB0aGUgZm9sbG93aW5nIHZhbHVlczoNCg0KICAgIDA6IE5hbWVkIGN1cnZlIChm
b2xsb3dlZCBieSBjdXJ2ZV9uYW1lKQ0KICAgIDE6IFBzZXVkbyBtZXJzZW5uZSBwcmltZSBmaWVs
ZCBGKHApIChmb2xsb3dlZCBieSByIGFuZCBjLg0KICAgICAgIHAgPSAyXnIgLSBjLCAiYmVsb3cg
c29tZSB0d29wb3dlciIpDQogICAgMjogUHNldWRvIG1lcnNlbm5lIHByaW1lIGZpZWxkIEYocCkg
KGZvbGxvd2VkIGJ5IHIgYW5kIGMuDQogICAgICAgcCA9IDJeciArIGMsICJhYm92ZSBzb21lIHR3
b3Bvd2VyIikNCiAgICAzOiBQcmltZSBmaWVsZCBGKHApIChmb2xsb3dlZCBieSBwKQ0KDQogICAg
NDogVHlwZS1JJklJIGV4dGVuc2lvbiBmaWVsZCBGKHBebSkgKGZvbGxvd2VkIGJ5IHIsIGMsIG0g
YW5kIHcuDQogICAgICAgcCA9IDJeciAtIGMsICJiZWxvdyBzb21lIHR3b3Bvd2VyIiwgZih0KSA9
IHRebSAtIHcpDQogICAgNTogVHlwZS1JJklJIGV4dGVuc2lvbiBmaWVsZCBGKHBebSkgKGZvbGxv
d2VkIGJ5IHIsIGMsIG0gYW5kIHcuDQogICAgICAgcCA9IDJeciArIGMsICJhYm92ZSBzb21lIHR3
b3Bvd2VyIiwgZih0KSA9IHRebSAtIHcpDQogICAgNjogVHlwZS1JSSBleHRlbnNpb24gZmllbGQg
RihwXm0pIChmb2xsb3dlZCBieSBwLCBtIGFuZCB3Lg0KICAgICAgIGYodCkgPSB0Xm0gLSB3KQ0K
ICAgIDc6IFR5cGUtSSBleHRlbnNpb24gZmllbGQgRihwXm0pIChmb2xsb3dlZCBieSByLCBjLCBt
IGFuZCBmLg0KICAgICAgIHAgPSAyXnIgLSBjLCAiYmVsb3cgc29tZSB0d29wb3dlciIpDQogICAg
ODogVHlwZS1JIGV4dGVuc2lvbiBmaWVsZCBGKHBebSkgKGZvbGxvd2VkIGJ5IHIsIGMsIG0gYW5k
IGYuDQogICAgICAgcCA9IDJeciArIGMsICJhYm92ZSBzb21lIHR3b3Bvd2VyIikNCiAgICA5OiBP
ZGQgZXh0ZW5zaW9uIGZpZWxkIEYocF5tKSAoZm9sbG93ZWQgYnkgcCwgbSBhbmQgZikNCg0KICAg
MTA6IENpcmN1bGFyIGR1YWwgYmFzaXMgb2YgRigyXm0pIChmb2xsb3dlZCBieSBtKQ0KICAgMTE6
IFRyaW5vbWlhbCBiYXNpcyBvZiBGKDJebSkgKGZvbGxvd2VkIGJ5IG0gYW5kIGspDQogICAxMjog
UGVudGFub21pYWwgYmFzaXMgb2YgRigyXm0pIChmb2xsb3dlZCBieSBtLCBrMSwgazIgYW5kIGsz
KQ0KICAgMTM6IFBvbHlub21pYWwgYmFzaXMgb2YgRigyXm0pIChmb2xsb3dlZCBieSBtIGFuZCBm
KQ0KICAgMTQ6IFR5cGUtSS1PTkIgb2YgRigyXm0pIChmb2xsb3dlZCBieSBtKQ0KICAgMTU6IFR5
cGUtSUktT05CIG9mIEYoMl5tKSAoZm9sbG93ZWQgYnkgbSkNCiAgIDE2OiBHYXVzc2lhbiBub3Jt
YWwgYmFzaXMgb2YgRigyXm0pIChmb2xsb3dlZCBieSBtIGFuZCBUKQ0KDQogICBPdGhlciB2YWx1
ZXMgb2YgRCBhcmUgcmVzZXJ2ZWQuIFRvIGNvbXBseSB3aXRoIHRoZSBzdGFuZGFyZCBEIGlzDQog
ICBzdG9yZWQgYXMgYW4gTVBJLCBhbHRob3VnaCBhIHNpbmdsZSBieXRlIHdvdWxkIGJlIGVub3Vn
aC4gDQoNClNjaGVya2wgICAgICAgICAgICAgICAgICAgICBTdGFuZGFyZHMgVHJhY2sgICAgICAg
ICAgICAgICAgICAgICBbUGFnZSA3XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICBPcGVu
UEdQIEVDQyBGb3JtYXRzICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDAxDQoNCjUuIEFsZ29yaXRo
bSBTcGVjaWZpYyBGaWVsZHMgZm9yIEVDQyBhbmQgRUNEU0EgUHVibGljIEtleXMNCg0KICAgLSBG
aWVsZCBkZXNjcmlwdG9yIEQgKGFsbG93ZWQgdmFsdWVzIGFyZSAwIHRvIDE2KQ0KICAgLSBOYW1l
IGN1cnZlX25hbWUgKGZvciBEID0gMCkNCiAgIC0gTVBJIHIsIC1jIChmb3IgRCA9IDEsIDQgb3Ig
NykNCiAgIC0gTVBJIHIsICtjIChmb3IgRCA9IDIsIDUgb3IgOCkNCiAgIC0gTVBJIHAgKGZvciBE
ID0gMywgNiBvciA5KQ0KICAgLSBNUEkgbSAoZm9yIEQgPiAzKQ0KICAgLSBNUEkgdyAoZm9yIEQg
PSA0LCA1IG9yIDYpDQogICAtIE1QSSBrIChmb3IgRCA9IDExKQ0KICAgLSBNUEkgazEsIGsyLCBr
MyAoZm9yIEQgPSAxMikNCiAgIC0gTVBJIGYgKGZvciBEID0gNywgOCwgOSBvciAxMykNCiAgIC0g
TVBJIFQgKGZvciBEID0gMTYpDQogICAtIE1QSSBhLCBiIChmb3IgRCBub3QgMCkNCiAgIC0gQ3Vy
dmUgUG9pbnQgRyAoZm9yIEQgbm90IDApICAgDQogICAtIE1QSSBuLCBoIChmb3IgRCBub3QgMCkN
CiAgIA0KICAgLSBDdXJ2ZSBQb2ludCBRLCB0aGUgZXNzZW50aWFsIG9mIHRoZSBwdWJsaWMga2V5
LiBRIGlzIHRoZSByZXN1bHQgb2YNCiAgICAgbXVsdGlwbHlpbmcgdGhlIGJhc2UgcG9pbnQgRyB3
aXRoIHRoZSBzZWNyZXQgbnVtYmVyIGQuIA0KDQo2LiBBbGdvcml0aG0gU3BlY2lmaWMgRmllbGRz
IGZvciBFQ0MgYW5kIEVDRFNBIFNlY3JldCBLZXlzDQoNCiAgIC0gTVBJIGQsIHRoZSBlc3NlbnRp
YWwgb2YgdGhlIHNlY3JldCBrZXkuIGQgaXMgYSByYW5kb20gbnVtYmVyDQogICAgIDEgPCBkIDwg
biwgd2hpY2ggcHJvZHVjZXMgdGhlIHB1YmxpYyBjdXJ2ZSBwb2ludCBRID0gZCpHLg0KDQo3LiBF
Q0MNCg0KICAgVGhlIGVsbGlwdGljIGN1cnZlIGNpcGhlciBhbGdvcml0aG0gKElEIDE4KSByZXF1
aXJlcyBhIGhhc2gtYWxnb3JpdGhtDQogICBhcyBmb3Igc2lnbmF0dXJlcyB0byBjYWxjdWxhdGUg
c29tZSBtYXNrLiBUaGlzIG1hc2sgaXMgY2FsY3VsYXRlZCB0aGUNCiAgIGZvbGxvd2luZyB3YXk6
DQogICBTb21lIGRhdGEgREggcGx1cyBhIGZvdXIgb2N0ZXQgY291bnRlciAoYmlnIGVuZGlhbikg
aXMgaGFzaGVkDQogICByZXBlYXRlZGx5LiBUaGUgY291bnRlciBzdGFydHMgd2l0aCB0aGUgdmFs
dWUgMCBhbmQgaXMgaW5jcmVtZW50ZWQNCiAgIGluIGVhY2ggc3RlcC4gVGhlIHJlc3VsdGluZyBo
YXNoIHZhbHVlcyBhcmUgY29uY2F0ZW5hdGVkIHVudGlsIHRoZWlyDQogICBsZW5ndGggZXF1YWxz
IHRoYXQgb2YgdGhlIG1lc3NhZ2UgLSBpZiBpdCdzIHRvbyBsb25nIHRoZSBsYXN0IG9jdGV0cw0K
ICAgYXJlIGN1dC4gVGhpcyBjb25jYXRlbmF0ZWQgc3RyaW5nIGlzIHRoZSBtYXNrLg0KICAgRm9y
IHN5bW1ldHJpYyBzZXNzaW9uIGtleXMgdHlwaWNhbHkgdXNlZCB0b2RheSBvbmx5IG9uZSBvciB0
d28gaGFzaGVzDQogICBhcmUgbmVlZGVkIChzZWUgSUVFRSBQMTM2MyBbMl0gZm9yIGRldGFpbHMp
Lg0KDQogICBUaGUgY29tcGxldGUgY2lwaGVyIHJlcXVpcmVzIHRoZSBmb2xsb3dpbmcgc3RlcHM6
DQoNCjcuMS4gRUNDIEVuY3J5cHRpb24NCg0KICAgMS4gR2VuZXJhdGUgYSB0ZW1wb3JhcnkgcmFu
ZG9tIGtleXBhaXIgKHRkLCB0USkgdG8gdGhlIHNhbWUgRUMgZG9tYWluDQogICAgICBhcyB0aGUg
cmVjZWl2ZXJzIHB1YmxpYyBrZXkgcGFyYW1ldGVyIFEsDQogICAyLiBjYWxjdWxhdGUgYSBzaGFy
ZWQgc2VjcmV0IERIID0geC1jb29yZGluYXRlIG9mIHRoZSBjdXJ2ZSBwb2ludA0KICAgICAgaCp0
ZCpRLA0KICAgMy4gY2FsY3VsYXRlIGEgTWFzayBNIHRvIHRoZSBzZXNzaW9uIGtleSBlIG91dCBv
ZiBESCwNCiAgIDQuIHN0b3JlICh0USwgZSB4b3IgTSkgaW4gdGhlIGVuY3J5cHRlZCBzZXNzaW9u
IGtleSBwYWNrZXQuDQoNCjcuMi4gRUNDIERlY3J5cHRpb24NCg0KICAgMS4gR2V0ICh0UScsIGUn
KSBmcm9tIHRoZSBlbmNyeXB0ZWQgc2Vzc2lvbiBrZXkgcGFja2V0LA0KDQpTY2hlcmtsICAgICAg
ICAgICAgICAgICAgICAgU3RhbmRhcmRzIFRyYWNrICAgICAgICAgICAgICAgICAgICAgW1BhZ2Ug
OF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgT3BlblBHUCBFQ0MgRm9ybWF0cyAgICAg
ICAgICAgICAgICBBdWd1c3QgMjAwMQ0KDQogICAyLiBjYWxjdWxhdGUgREgnID0geC1jb29yZGlu
YXRlIG9mIHRoZSBjdXJ2ZSBwb2ludCBoKmQqdFEnLCB1c2luZyB0aGUNCiAgICAgIHJlY2VpdmVy
cyBzZWNyZXQga2V5IHBhcmFtZXRlciBkLA0KICAgMy4gY2FsY3VsYXRlIHRoZSBNYXNrIE0nIHRv
IGUnIG91dCBvZiBESCcsDQogICA0LiB1c2UgKGUnIHhvciBNJykgYXMgZGVjcnlwdGVkIHNlc3Np
b24ga2V5Lg0KDQo3LjMuIEFsZ29yaXRobSBTcGVjaWZpYyBGaWVsZHMgZm9yIEVDQyBFbmNyeXB0
aW9uDQoNCiAgIC0gT25lLW9jdGV0IGhhc2gtYWxnb3JpdGhtLA0KICAgLSBNUEkgb2YgdFEgKGEg
dGVtcG9yYXJ5IHB1YmxpYyBjdXJ2ZSBwb2ludCksDQogICAtIE1QSSBvZiAoZSB4b3IgTSkgKHRo
ZSBlbmNyeXB0ZWQgc2Vzc2lvbiBrZXkgbWF0ZXJpYWwpDQoNCjguIEVDRFNBDQoNCiAgIFRoZSBl
bGxpcHRpYyBjdXJ2ZSBkaWdpdGFsIHNpZ25hdHVyZSBhbGdvcml0aG0gKElEIDE5KSByZXF1aXJl
cyB0aGUNCiAgIGZvbGxvd2luZyBzdGVwcyB0byBiZSBkb25lOg0KDQo4LjEuIFNpZ24gd2l0aCBF
Q0RTQQ0KDQogICAxLiBDaG9vc2UgYSByYW5kb20gbnVtYmVyIGkgPCBuLA0KICAgMi4gY2FsY3Vs
YXRlIHQgPSB4LWNvb3JkaW5hdGUgb2YgaSpHIG1vZCBuLA0KICAgMy4gY2FsY3VsYXRlIHMgPSAo
ZSArIGQqdCkvaSBtb2Qgbiwgd2hlcmUgZSBpcyB0aGUgbWVzc2FnZSBoYXNoLA0KICAgNC4gc3Rv
cmUgKHQsIHMpIGluIHRoZSBzaWduYXR1cmUgcGFja2V0Lg0KDQo4LjIuIEVDRFNBIFNpZ25hdHVy
ZSBWZXJpZmljYXRpb24NCg0KICAgMS4gR2V0ICh0JywgcycpIGZyb20gdGhlIHNpZ25hdHVyZSBw
YWNrZWQgYW5kIGNhbGN1bGF0ZSB0aGUgaGFzaCBlJw0KICAgICAgb2YgdGhlIHJlY2VpdmVkIG1l
c3NhZ2UsDQogICAyLiBjYWxjdWxhdGUgdTEgPSBlJy9zJyBtb2QgbiBhbmQgdTIgPSB0Jy9zJyBt
b2QgbiwNCiAgIDMuIGNhbGN1bGF0ZSB0ID0geC1jb29yZGlhbnRlIG9mICh1MSpHICsgdTIqUSkg
bW9kIG4sDQogICA0LiBpZiB0ID0gdCcsIHRoYW4gdGFrZSB0aGUgbWVzc2FnZSB0byBiZSBhdXRo
ZW50aWMuDQoNCjguMy4gQWxnb3JpdGhtIFNwZWNpZmljIEZpZWxkcyBmb3IgRUNEU0EgU2lnbmF0
dXJlcw0KDQogICAtIE1QSSB0IChyZWR1Y2VkIHgtY29vcmRpYW50ZSBvZiBzb21lIGN1cnZlIHBv
aW50KQ0KICAgLSBNUEkgcyAoZ2VuZXJhdGVkIGZyb20gc2VjcmV0IGFuZCBtZXNzYWdlIHNwZWNp
ZmljIGluZm9ybWF0aW9uKQ0KDQo5LiBOYW1lZCBDdXJ2ZXMNCg0KICAgS25vd24gY3VydmUgbmFt
ZXMgYXJlIHRoZSBmb2xsb3dpbmcgKGFzIGRlZmluZWQgaW4gWDkuNjItMTk5OCBbNF0NCiAgIGFu
ZCBTRUMgMiBbNl0gLSBjdXJ2ZXMgb3ZlciBmaWVsZHMgd2hpY2ggYXJlIHRvbyBzbWFsbCBvciBo
YXZpbmcNCiAgIHNtYWxsIHN1YmZpZWxkcyBhcmUgb21taXRlZCBmb3IgZW5oYW5jZWQgc2VjdXJp
dHkpLCB0aGUgY3VydmUNCiAgIHBvaW50IEcgaXMgYWx3YXlzIHByZXNlbnRlZCBpbiBjb21wcmVz
c2VkIGZvcm06DQoNCjkuMS4gQ3VydmVzIG92ZXIgQ2hhci0yLUZpZWxkcw0KDQogICBjMnBuYjE2
M3YxOg0KICAgIEYoMl4xNjMpIHdpdGggcGVudGFub21pYWwgYmFzaXMgKGsgPSAxLCAyLCA4KSwN
CiAgICBhID0gMHgwNyAyNTQ2QjU0MyA1MjM0QTQyMiBFMDc4OTY3NSBGNDMyQzg5NCAzNURFNTI0
MiwNCiAgICBiID0gMHhDOTUxN0QwNiBENTI0MEQzQyBGRjM4Qzc0QiAyMEI2Q0Q0RCA2RjlERDRE
OSwNCiAgICBHID0gMHgwMzA3IEFGNjk5ODk1IDQ2MTAzRDc5IDMyOUZDQzNEIDc0ODgwRjMzIEJC
RTgwM0NCLA0KICAgIG4gPSAweDA0IDAwMDAwMDAwIDAwMDAwMDAwIDAwMDFFNjBGIEM4ODIxQ0M3
IDREQUVBRkMxLA0KICAgIGggPSAyLg0KDQpTY2hlcmtsICAgICAgICAgICAgICAgICAgICAgU3Rh
bmRhcmRzIFRyYWNrICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgOV0NCgwNCkludGVybmV0LURy
YWZ0ICAgICAgICAgICAgT3BlblBHUCBFQ0MgRm9ybWF0cyAgICAgICAgICAgICAgICBBdWd1c3Qg
MjAwMQ0KDQogICBjMnBuYjE2M3YyOg0KICAgIEYoMl4xNjMpIHdpdGggcGVudGFub21pYWwgYmFz
aXMgKGsgPSAxLCAyLCA4KSwNCiAgICBhID0gMHgwMSAwOEIzOUU3NyBDNEIxMDhCRSBEOTgxRUQw
RSA4OTBFMTE3QyA1MTFDRjA3MiwNCiAgICBiID0gMHgwNiA2N0FDRUIzOCBBRjRFNDg4QyA0MDc0
MzNGRiBBRTRGMUM4MSAxNjM4REYyMCwNCiAgICBHID0gMHgwMzAwIDI0MjY2RTRFIEI1MTA2RDBB
IDk2NEQ5MkM0IDg2MEUyNjcxIERCOUI2Q0M1LA0KICAgIG4gPSAweDAzIEZGRkZGRkZGIEZGRkZG
RkZGIEZGRkRGNjREIEUxMTUxQURCIEI3OEYxMEE3LA0KICAgIGggPSAyLg0KDQogICBjMnBuYjE2
M3YzOg0KICAgIEYoMl4xNjMpIHdpdGggcGVudGFub21pYWwgYmFzaXMgKGsgPSAxLCAyLCA4KSwN
CiAgICBhID0gMHgwNyBBNTI2QzYzRCAzRTI1QTI1NiBBMDA3Njk5RiA1NDQ3RTMyQSBFNDU2QjUw
RSwNCiAgICBiID0gMHgwMyBGNzA2MTc5OCBFQjk5RTIzOCBGRDZGMUJGOSA1QjQ4RkVFQiA0ODU0
MjUyQiwNCiAgICBHID0gMHgwMjAyIEY5Rjg3QjdDIDU3NEQwQkRFIENGOEEyMkU2IDUyNDc3NUY5
IDhDREVCRENCLA0KICAgIG4gPSAweDAzIEZGRkZGRkZGIEZGRkZGRkZGIEZGRkUxQUVFIDE0MEYx
MTBBIEZGOTYxMzA5LA0KICAgIGggPSAyLg0KDQogICBzZWN0MTYzazE6DQogICAgRigyXjE2Mykg
d2l0aCBwZW50YW5vbWlhbCBiYXNpcyAoayA9IDMsIDYsIDcpLA0KICAgIGEgPSAxLA0KICAgIGIg
PSAxLA0KICAgIEcgPSAweDAzMDIgRkUxM0MwNTMgN0JCQzExQUMgQUEwN0Q3OTMgREU0RTZENUUg
NUM5NEVFRTgsDQogICAgbiA9IDB4MDQgMDAwMDAwMDAgMDAwMDAwMDAgMDAwMjAxMDggQTJFMEND
MEQgOTlGOEE1RUYsDQogICAgaCA9IDIuDQoNCiAgIHNlY3QxNjNyMToNCiAgICBGKDJeMTYzKSB3
aXRoIHBlbnRhbm9taWFsIGJhc2lzIChrID0gMywgNiwgNyksDQogICAgYSA9IDA3IEI2ODgyQ0FB
IEVGQTg0Rjk1IDU0RkY4NDI4IEJEODhFMjQ2IEQyNzgyQUUyLA0KICAgIGIgPSAwNyAxMzYxMkRD
RCBEQ0I0MEFBQiA5NDZCREEyOSBDQTkxRjczQSBGOTU4QUZEOSwNCiAgICBHID0gMDMwMyA2OTk3
OTY5NyBBQjQzODk3NyA4OTU2Njc4OSA1NjdGNzg3QSA3ODc2QTY1NCwNCiAgICBuID0gMDMgRkZG
RkZGRkYgRkZGRkZGRkYgRkZGRjQ4QUEgQjY4OUMyOUMgQTcxMDI3OUIsDQogICAgaCA9IDIuDQoN
CiAgIHNlY3QxNjNyMjoNCiAgICBGKDJeMTYzKSB3aXRoIHBlbnRhbm9taWFsIGJhc2lzIChrID0g
MywgNiwgNyksDQogICAgYSA9IDEsDQogICAgYiA9IDB4MDIgMEE2MDE5MDcgQjhDOTUzQ0EgMTQ4
MUVCMTAgNTEyRjc4NzQgNEEzMjA1RkQsDQogICAgRyA9IDB4MDMwMyBGMEVCQTE2MiA4NkEyRDU3
RSBBMDk5MTE2OCBENDk5NDYzNyBFODM0M0UzNiwNCiAgICBuID0gMHgwNCAwMDAwMDAwMCAwMDAw
MDAwMCAwMDAyOTJGRSA3N0U3MEMxMiBBNDIzNEMzMywNCiAgICBoID0gMi4NCg0KICAgYzJ0bmIx
OTF2MToNCiAgICBGKDJeMTkxKSB3aXRoIHRyaW5vbWlhbCBiYXNpcyAoayA9IDkpLA0KICAgIGEg
PSAweDI4NjY1MzdCIDY3Njc1MjYzIDZBNjhGNTY1IDU0RTEyNjQwIDI3NkI2NDlFIEY3NTI2MjY3
LA0KICAgIGIgPSAweDJFNDVFRjU3IDFGMDA3ODZGIDY3QjAwODFCIDk0OTVBM0Q5IDU0NjJGNURF
IDBBQTE4NUVDLA0KICAgIEcgPSAweDAyIDM2QjNEQUY4IEEyMzIwNkY5IEM0RjI5OUQ3IEIyMUE5
QzM2IDkxMzdGMkM4IDRBRTFBQTBELA0KICAgIG4gPSAweDQwMDAwMDAwIDAwMDAwMDAwIDAwMDAw
MDAwIDA0QTIwRTkwIEMzOTA2N0M4IDkzQkJCOUE1LA0KICAgIGggPSAyLg0KDQogICBjMnRuYjE5
MXYyOg0KICAgIEYoMl4xOTEpIHdpdGggdHJpbm9taWFsIGJhc2lzIChrID0gOSksDQogICAgYSA9
IDB4NDAxMDI4NzcgNEQ3Nzc3QzcgQjc2NjZEMTMgNjZFQTQzMjAgNzEyNzRGODkgRkYwMUU3MTgs
DQogICAgYiA9IDB4MDYyMDA0OEQgMjhCQ0JEMDMgQjYyNDlDOTkgMTgyQjdDOEMgRDE5NzAwQzMg
NjJDNDZBMDEsDQoNClNjaGVya2wgICAgICAgICAgICAgICAgICAgICBTdGFuZGFyZHMgVHJhY2sg
ICAgICAgICAgICAgICAgICAgIFtQYWdlIDEwXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAg
ICBPcGVuUEdQIEVDQyBGb3JtYXRzICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDAxDQoNCiAgICBH
ID0gMHgwMiAzODA5QjJCNyBDQzFCMjhDQyA1QTg3OTI2QSBBRDgzRkQyOCA3ODlFODFFMiBDOUUz
QkYxMCwNCiAgICBuID0gMHgyMDAwMDAwMCAwMDAwMDAwMCAwMDAwMDAwMCA1MDUwOENCOCA5RjY1
MjgyNCBFMDZCODE3MywNCiAgICBoID0gNC4NCg0KICAgYzJ0bmIxOTF2MzoNCiAgICBGKDJeMTkx
KSB3aXRoIHRyaW5vbWlhbCBiYXNpcyAoayA9IDkpLA0KICAgIGEgPSAweDZDMDEwNzQ3IDU2MDk5
MTIyIDIyMTA1NjkxIDFDNzdENzdFIDc3QTc3N0U3IEU3RTc3RkNCLA0KICAgIGIgPSAweDcxRkUx
QUY5IDI2Q0Y4NDc5IDg5RUZFRjhEIEI0NTlGNjYzIDk0RDkwRjMyIEFEM0YxNUU4LA0KICAgIEcg
PSAweDAzIDM3NUQ0Q0UyIDRGREU0MzQ0IDg5REU4NzQ2IEU3MTc4NjAxIDUwMDlFNjZFIDM4QTky
NkRELA0KICAgIG4gPSAweDE1NTU1NTU1IDU1NTU1NTU1IDU1NTU1NTU1IDYxMEMwQjE5IDY4MTJC
RkI2IDI4OEEzRUEzLA0KICAgIGggPSA2Lg0KDQogICBjMm9uYjE5MXY0Og0KICAgIEYoMl4xOTEp
IHdpdGggdHlwZS1JSSBvcHRpbWFsIG5vcm1hbCBiYXNpcywNCiAgICBhID0gMHg2NTkwM0UwNCBF
MUU0OTI0MiA1M0UyNkEzQyA5QUMyOEM3NSA4QkQ4MTg0QSAzRkI2ODBFOCwNCiAgICBiID0gMHg1
NDY3ODYyMSBCMTkwQ0ZDRSAyODJBREUyMSA5RDVCM0EwNiA1RTNGNEIzRiBGREVCQjI5QiwNCiAg
ICBHID0gMHgwMiA1QTJDNjlBMyAyRTg2MzhFNSAxQ0NFRkFBRCAwNTM1MEE5NyA4NDU3Q0I1RiBC
NkRGOTk0QSwNCiAgICBuID0gMHg0MDAwMDAwMCAwMDAwMDAwMCAwMDAwMDAwMCA5Q0YyRDZFMyA5
MDFEQUM0QyAzMkVFQzY1RCwNCiAgICBoID0gMi4NCg0KICAgYzJvbmIxOTF2NToNCiAgICBGKDJe
MTkxKSB3aXRoIHR5cGUtSUkgb3B0aW1hbCBub3JtYWwgYmFzaXMsDQogICAgYSA9IDB4MjVGOEQw
NkMgOTdDODIyNTMgNkQ0NjlDRDUgMTcwQ0REN0IgQjlGNTAwQkQgNkRCMTEwRkIsDQogICAgYiA9
IDB4NzVGRjU3MEUgMzVDQTk0RkIgMzc4MEMyNjEgOUQwODFDMTcgQUE1OUZCRDUgRTU5MUMxQzQs
DQogICAgRyA9IDB4MDMgMkExNjkxMEUgOEY2QzRCMTkgOUJFMjQyMTMgODU3QUJDOUMgOTkyRURG
QjIgNDcxRjNDNjgsDQogICAgbiA9IDB4MEZGRkZGRkYgRkZGRkZGRkYgRkZGRkZGRkYgRUVCMzU0
QjcgMjcwQjI5OTIgQjc4MTg2MjcsDQogICAgaCA9IDguDQoNCiAgIHNlY3QxOTNyMToNCiAgICBG
KDJeMTkzKSB3aXRoIHRyaW5vbWlhbCBiYXNpcyAoayA9IDE1KSwNCiAgICBhID0gMHgwMCAxNzg1
OEZFQiA3QTk4OTc1MSA2OUUxNzFGNyA3QjQwODdERSAwOThBQzhBOSAxMURGN0IwMSwNCiAgICBi
ID0gMHgwMCBGREZCNDlCRiBFNkMzQTg5RiBBQ0FEQUE3QSAxRTVCQkM3QyBDMUMyRTVEOCAzMTQ3
ODgxNCwNCiAgICBHID0gMHgwMzAxIEY0ODFCQzVGIDBGRjg0QTc0IEFENkNERjZGIERFRjRCRjYx
IDc5NjI1MzcyIEQ4QzBDNUUxLA0KICAgIG4gPSAweDAxIDAwMDAwMDAwIDAwMDAwMDAwIDAwMDAw
MDAwIEM3RjM0QTc3IDhGNDQzQUNDIDkyMEVCQTQ5LA0KICAgIGggPSAyLg0KDQogICBzZWN0MTkz
cjI6DQogICAgRigyXjE5Mykgd2l0aCB0cmlub21pYWwgYmFzaXMgKGsgPSAxNSksDQogICAgYSA9
IDB4MDEgNjNGMzVBNTEgMzdDMkNFM0UgQTZFRDg2NjcgMTkwQjBCQzQgM0VDRDY5OTcgNzcwMjcw
OUIsDQogICAgYiA9IDB4MDAgQzlCQjlFODkgMjdENEQ2NEMgMzc3RTJBQjIgODU2QTVCMTYgRTNF
RkI3RjYgMUQ0MzE2QUUsDQogICAgRyA9IDB4MDMwMCBEOUI2N0QxOSAyRTAzNjdDOCAwM0YzOUUx
QSA3RTgyQ0ExNCBBNjUxMzUwQSBBRTYxN0U4RiwNCiAgICBuID0gMHgwMSAwMDAwMDAwMCAwMDAw
MDAwMCAwMDAwMDAwMSA1QUFCNTYxQiAwMDU0MTNDQyBENEVFOTlENSwNCiAgICBoID0gMi4NCg0K
ICAgc2VjdDIzM2sxOg0KICAgIEYoMl4yMzMpIHdpdGggdHJpbm9taWFsIGJhc2lzIChrID0gNzQp
LA0KICAgIGEgPSAwLA0KICAgIGIgPSAxLA0KICAgIEcgPSAweDAyMDE3MiAzMkJBODUzQSA3RTcz
MUFGMSAyOUYyMkZGNA0KICAgICAgICAxNDk1NjNBNCAxOUMyNkJGNSAwQTRDOUQ2RSBFRkFENjEy
NiwNCiAgICBuID0gMHg4MCAwMDAwMDAwMCAwMDAwMDAwMCAwMDAwMDAwMA0KICAgICAgICAwMDA2
OUQ1QiBCOTE1QkNENCA2RUZCMUFENSBGMTczQUJERiwNCg0KU2NoZXJrbCAgICAgICAgICAgICAg
ICAgICAgIFN0YW5kYXJkcyBUcmFjayAgICAgICAgICAgICAgICAgICAgW1BhZ2UgMTFdDQoMDQpJ
bnRlcm5ldC1EcmFmdCAgICAgICAgICAgIE9wZW5QR1AgRUNDIEZvcm1hdHMgICAgICAgICAgICAg
ICAgQXVndXN0IDIwMDENCg0KICAgIGggPSA0Lg0KDQogICBzZWN0MjMzcjE6DQogICAgRigyXjIz
Mykgd2l0aCB0cmlub21pYWwgYmFzaXMgKGsgPSA3NCksDQogICAgYSA9IDEsDQogICAgYiA9IDB4
MDA2NiA2NDdFREU2QyAzMzJDN0Y4QyAwOTIzQkI1OA0KICAgICAgICAyMTNCMzMzQiAyMEU5Q0U0
MiA4MUZFMTE1RiA3RDhGOTBBRCwNCiAgICBHID0gMHgwMzAwRkEgQzlERkNCQUMgODMxM0JCMjEg
MzlGMUJCNzUNCiAgICAgICAgNUZFRjY1QkMgMzkxRjhCMzYgRjhGOEVCNzMgNzFGRDU1OEIsDQog
ICAgbiA9IDB4MDEwMCAwMDAwMDAwMCAwMDAwMDAwMCAwMDAwMDAwMA0KICAgICAgICAwMDEzRTk3
NCBFNzJGOEE2OSAyMjAzMUQyNiAwM0NGRTBENywNCiAgICBoID0gMi4NCg0KICAgc2VjdDIzOWsx
Og0KICAgIEYoMl4yMzkpIHdpdGggdHJpbm9taWFsIGJhc2lzIChrID0gMTU4KSwNCiAgICBhID0g
MCwNCiAgICBiID0gMSwNCiAgICBHID0gMHgwMzI5QTAgQjZBODg3QTkgODNFOTczMDkgODhBNjg3
MjcNCiAgICAgICAgQThCMkQxMjYgQzQ0Q0MyQ0MgN0IyQTY1NTUgMTkzMDM1REMsDQogICAgbiA9
IDB4MjAwMCAwMDAwMDAwMCAwMDAwMDAwMCAwMDAwMDAwMA0KICAgICAgICAwMDVBNzlGRSBDNjdD
QjZFOSAxRjFDMURBOCAwMEU0NzhBNSwNCiAgICBoID0gNC4NCg0KICAgYzJ0bmIyMzl2MToNCiAg
ICBGKDJeMjM5KSB3aXRoIHRyaW5vbWlhbCBiYXNpcyAoayA9IDM2KSwNCiAgICBhID0gMHgzMjAx
IDA4NTcwNzdDIDU0MzExMjNBIDQ2QjgwODkwDQogICAgICAgIDY3NTZGNTQzIDQyM0U4RDI3IDg3
NzU3ODEyIDU3NzhBQzc2LA0KICAgIGIgPSAweDc5MDQgMDhGMkVFREEgRjM5MkIwMTIgRURFRkIz
MzkNCiAgICAgICAgMkYzMEY0MzIgN0MwQ0EzRjMgMUZDMzgzQzQgMjJBQThDMTYsDQogICAgRyA9
IDB4MDI1NzkyIDcwOThGQTkzIDJFN0MwQTk2IEQzRkQ1QjcwDQogICAgICAgIDZFRjdFNUY1IEMx
NTZFMTZCIDdFN0M4NjAzIDg1NTJFOTFELA0KICAgIG4gPSAweDIwMDAgMDAwMDAwMDAgMDAwMDAw
MDAgMDAwMDAwMDANCiAgICAgICAgMDAwRjRENDIgRkZFMTQ5MkEgNDk5M0YxQ0EgRDY2NkU0NDcs
DQogICAgaCA9IDQuDQoNCiAgIGMydG5iMjM5djI6DQogICAgRigyXjIzOSkgd2l0aCB0cmlub21p
YWwgYmFzaXMgKGsgPSAzNiksDQogICAgYSA9IDB4NDIzMCAwMTc3NTdBNyA2N0ZBRTQyMyA5ODU2
OUI3NA0KICAgICAgICA2MzI1RDQ1MyAxM0FGMDc2NiAyNjY0NzlCNyA1NjU0RTY1RiwNCiAgICBi
ID0gMHg1MDM3IEVBNjU0MTk2IENGRjBDRDgyIEIyQzE0QTJGDQogICAgICAgIENGMkUzRkY4IDc3
NTI4NUI1IDQ1NzIyRjAzIEVBQ0RCNzRCLA0KICAgIEcgPSAweDAyMjhGOSBEMDRFOTAwMCA2OUM4
REM0NyBBMDg1MzRGRQ0KICAgICAgICA3NkQyQjkwMCBCN0Q3RUYzMSBGNTcwOUYyMCAwQzRDQTIw
NSwNCiAgICBuID0gMHgxNTU1IDU1NTU1NTU1IDU1NTU1NTU1IDU1NTU1NTU1DQogICAgICAgIDU1
M0M2RjI4IDg1MjU5QzMxIEUzRkNERjE1IDQ2MjQ1MjJELA0KICAgIGggPSA2Lg0KDQogICBjMnRu
YjIzOXYzOg0KICAgIEYoMl4yMzkpIHdpdGggdHJpbm9taWFsIGJhc2lzIChrID0gMzYpLA0KICAg
IGEgPSAweDAxMjMgODc3NDY2NkEgNjc3NjZENjYgNzZGNzc4RTYNCiAgICAgICAgNzZCNjY5OTkg
MTc2NjY2RTYgODc2NjZEODcgNjZDNjZBOUYsDQogICAgYiA9IDB4NkE5NCAxOTc3QkE5RiA2QTQz
NTE5OSBBQ0ZDNTEwNg0KDQpTY2hlcmtsICAgICAgICAgICAgICAgICAgICAgU3RhbmRhcmRzIFRy
YWNrICAgICAgICAgICAgICAgICAgICBbUGFnZSAxMl0NCgwNCkludGVybmV0LURyYWZ0ICAgICAg
ICAgICAgT3BlblBHUCBFQ0MgRm9ybWF0cyAgICAgICAgICAgICAgICBBdWd1c3QgMjAwMQ0KDQog
ICAgICAgIDdFRDU4N0Y1IDE5QzVFQ0I1IDQxQjhFNDQxIDExREUxRDQwLA0KICAgIEcgPSAweDAz
NzBGNiBFOUQwNEQyOCA5QzRFODk5MSAzQ0UzNTMwQg0KICAgICAgICBGREU5MDM5NyA3RDQyQjE0
NiBENTM5QkYxQiBERTRFOUM5MiwNCiAgICBuID0gMHgwQ0NDIENDQ0NDQ0NDIENDQ0NDQ0NDIEND
Q0NDQ0NDDQogICAgICAgIENDQUM0OTEyIEQyRDlERjkwIDNFRjk4ODhCIDhBMEU0Q0ZGLA0KICAg
IGggPSAxMC4NCg0KICAgYzJvbmIyMzl2NDoNCiAgICBGKDJeMjM5KSB3aXRoIHR5cGUtSUkgb3B0
aW1hbCBub3JtYWwgYmFzaXMsDQogICAgYSA9IDB4MTgyRCBENDVGNUQ0NyAwMjM5Qjg5OCAzRkVB
NDdCOA0KICAgICAgICBCMjkyNjQxQyA1N0Y5QkY4NCBCQUVDREU4QiBCM0FEQ0UzMCwNCiAgICBi
ID0gMHgxNDdBIDlDMUQ0QzJDIEU5QkU1RDM0IEVDMDI3OTdGDQogICAgICAgIDc2NjY3RUJBIEQ1
QTNGOTNGIEEyQTUyNEJGIERFOTFFRjI4LA0KICAgIEcgPSAweDAzNDkxMiBBRDY1N0YxRCAxQzZC
MzJFRCBCOTk0MkM5NQ0KICAgICAgICBFMjI2QjA2RiBCMDEyQ0Q0MCBGREVBMEQ3MiAxOTdDODEw
NCwNCiAgICBuID0gMHgyMDAwIDAwMDAwMDAwIDAwMDAwMDAwIDAwMDAwMDAwDQogICAgICAgIDAw
NDc0RjdFIDY5RjQyRkU0IDMwOTMxRDBCIDQ1NUFBRThCLA0KICAgIGggPSA0Lg0KDQogICBjMm9u
YjIzOXY1Og0KICAgIEYoMl4yMzkpIHdpdGggdHlwZS1JSSBvcHRpbWFsIG5vcm1hbCBiYXNpcywN
CiAgICBhID0gMHgxRUNGIDFCOUQyOEQ4IDAxNzUwNUUxIDc0NzVEM0RGDQogICAgICAgIDI5ODJF
MjQzIENBNUNCNUU5IEY5NEEzRjM2IDEyNEE0ODZFLA0KICAgIGIgPSAweDNFRTIgNTcyNTBEMUEg
MkU2NkNFRjIgM0FBMEYyNUINCiAgICAgICAgMTIzODhERTggQTEwRkY5NTUgNEY5MEFGQkEgQTlB
MDhCNkQsDQogICAgRyA9IDB4MDIxOTMyIDc5RkM1NDNFIDlGNUY3MTE5IDE4OTc4NUI5DQogICAg
ICAgIEM2MEIyNDlCIEU0ODIwQkFGIDZDMjRCREZBIDI4MTNGOEI4LA0KICAgIG4gPSAweDE1NTUg
NTU1NTU1NTUgNTU1NTU1NTUgNTU1NTU1NTUNCiAgICAgICAgNTU4Q0Y3N0EgNUQwNTg5RDIgQTkz
NDBEOTYgM0I3QUQ3MDMsDQogICAgaCA9IDYuDQoNCiAgIHNlY3QyODNrMToNCiAgICBGKDJeMjgz
KSB3aXRoIHBlbnRhbm9taWFsIGJhc2lzIChrID0gNSwgNywgMTIpLA0KICAgIGEgPSAwLA0KICAg
IGIgPSAxLA0KICAgIEcgPSAweDAyIDA1MDMyMTNGIDc4Q0E0NDg4IDNGMUEzQjgxIDYyRjE4OEU1
DQogICAgICAgIDUzQ0QyNjVGIDIzQzE1NjdBIDE2ODc2OTEzIEIwQzJBQzI0IDU4NDkyODM2LA0K
ICAgIG4gPSAweDAxRkZGRkZGIEZGRkZGRkZGIEZGRkZGRkZGIEZGRkZGRkZGDQogICAgICAgIEZG
RkZFOUFFIDJFRDA3NTc3IDI2NURGRjdGIDk0NDUxRTA2IDFFMTYzQzYxLA0KICAgIGggPSA0Lg0K
DQogICBzZWN0MjgzcjE6DQogICAgRigyXjI4Mykgd2l0aCBwZW50YW5vbWlhbCBiYXNpcyAoayA9
IDUsIDcsIDEyKSwNCiAgICBhID0gMSwNCiAgICBiID0gMHgwMjdCNjgwQSBDOEI4NTk2RCBBNUE0
QUY4QSAxOUEwMzAzRg0KICAgICAgICBDQTk3RkQ3NiA0NTMwOUZBMiBBNTgxNDg1QSBGNjI2M0Uz
MSAzQjc5QTJGNSwNCiAgICBHID0gMHgwMyAwNUY5MzkyNSA4REI3REQ5MCBFMTkzNEY4QyA3MEIw
REZFQw0KICAgICAgICAyRUVEMjVCOCA1NTdFQUM5QyA4MEUyRTE5OCBGOENEQkVDRCA4NkIxMjA1
MywNCiAgICBuID0gMHgwM0ZGRkZGRiBGRkZGRkZGRiBGRkZGRkZGRiBGRkZGRkZGRg0KICAgICAg
ICBGRkZGRUY5MCAzOTk2NjBGQyA5MzhBOTAxNiA1QjA0MkE3QyBFRkFEQjMwNywNCiAgICBoID0g
Mi4NCg0KDQpTY2hlcmtsICAgICAgICAgICAgICAgICAgICAgU3RhbmRhcmRzIFRyYWNrICAgICAg
ICAgICAgICAgICAgICBbUGFnZSAxM10NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgT3Bl
blBHUCBFQ0MgRm9ybWF0cyAgICAgICAgICAgICAgICBBdWd1c3QgMjAwMQ0KDQogICBjMnRuYjM1
OXYxOg0KICAgIEYoMl4zNTkpIHdpdGggdHJpbm9taWFsIGJhc2lzIChrPTY4KSwNCiAgICBhID0g
MHg1NiA2NzY3NkE2NSA0QjIwNzU0RiAzNTZFQTkyMCAxN0Q5NDY1NiA3QzQ2Njc1NQ0KICAgICAg
ICA1NkYxOTU1NiBBMDQ2MTZCNSA2N0QyMjNBNSBFMDU2NTZGQiA1NDkwMTZBOSA2NjU2QTU1NywN
CiAgICBiID0gMHgyNCA3MkUyRDAxOSA3QzQ5MzYzRiAxRkU3RjVCNiBEQjA3NUQ1MiBCNjk0N0Qx
Mw0KICAgICAgICA1RDhDQTQ0NSA4MDVEMzlCQyAzNDU2MjYwOCA5Njg3NzQyQiA2MzI5RTcwNiA4
MDIzMTk4OCwNCiAgICBHID0gMHgwMzNDIDI1OEVGMzA0IDc3NjdFN0VEIEUwRjFGREFBIDc5REFF
RTM4IDQxMzY2QTEzDQogICAgICAgIDJFMTYzQUNFIEQ0RUQyNDAxIERGOUM2QkRDIERFOThFOEU3
IDA3QzA3QTIyIDM5QjFCMDk3LA0KICAgIG4gPSAweDAxIEFGMjg2QkNBIDFBRjI4NkJDIEExQUYy
ODZCIENBMUFGMjg2IEJDQTFBRjI4DQogICAgICAgIDZCQzlGQjhGIDZCODVDNTU2IDg5MkMyMEE3
IEVCOTY0RkU3IDcxOUU3NEY0IDkwNzU4RDNCLA0KICAgIGggPSAweDRDLg0KDQogICBzZWN0NDA5
azE6DQogICAgRigyXjQwOSkgd2l0aCB0cmlub21pYWwgYmFzaXMgKGsgPSA4NyksDQogICAgYSA9
IDAsDQogICAgYiA9IDEsDQogICAgRyA9IDB4MDMgMDA2MEYwNUYgNjU4RjQ5QzEgQUQzQUIxODkg
MEY3MTg0MjEgMEVGRDA5ODcgRTMwN0M4NEMNCiAgICAgICAgMjdBQ0NGQjggRjlGNjdDQzIgQzQ2
MDE4OUUgQjVBQUFBNjIgRUUyMjJFQjEgQjM1NTQwQ0YgRTkwMjM3NDYsDQogICAgbiA9IDB4N0ZG
RkZGIEZGRkZGRkZGIEZGRkZGRkZGIEZGRkZGRkZGIEZGRkZGRkZGIEZGRkZGRkZGDQogICAgICAg
IEZGRkZGRTVGIDgzQjJENEVBIDIwNDAwRUM0IDU1N0Q1RUQzIEUzRTdDQTVCIDRCNUM4M0I4IEUw
MUU1RkNGLA0KICAgIGggPSA0Lg0KDQogICBzZWN0NDA5cjE6DQogICAgRigyXjQwOSkgd2l0aCB0
cmlub21pYWwgYmFzaXMgKGsgPSA4NyksDQogICAgYSA9IDEsDQogICAgYiA9IDB4MDAyMUE1QzIg
QzhFRTlGRUIgNUM0QjlBNzUgM0I3QjQ3NkIgN0ZENjQyMkUgRjFGM0RENjcNCiAgICAgICAgNDc2
MUZBOTkgRDZBQzI3QzggQTlBMTk3QjIgNzI4MjJGNkMgRDU3QTU1QUEgNEY1MEFFMzEgN0IxMzU0
NUYsDQogICAgRyA9IDB4MDMgMDE1RDQ4NjAgRDA4OEREQjMgNDk2QjBDNjAgNjQ3NTYyNjAgNDQx
Q0RFNEEgRjE3NzFENEQNCiAgICAgICAgQjAxRkZFNUIgMzRFNTk3MDMgREMyNTVBODYgOEExMTgw
NTEgNTYwM0FFQUIgNjA3OTRFNTQgQkI3OTk2QTcsDQogICAgbiA9IDB4MDEwMDAwMDAgMDAwMDAw
MDAgMDAwMDAwMDAgMDAwMDAwMDAgMDAwMDAwMDAgMDAwMDAwMDANCiAgICAgICAgMDAwMDAxRTIg
QUFENkE2MTIgRjMzMzA3QkUgNUZBNDdDM0MgOUUwNTJGODMgODE2NENEMzcgRDlBMjExNzMsDQog
ICAgaCA9IDIuDQoNCiAgIGMydG5iNDMxcjE6DQogICAgRigyXjQzMSkgd2l0aCB0cmlub21pYWwg
YmFzaXMgKGs9MTIwKSwNCiAgICBhID0gMHgxQTgyN0VGMDBERDZGQzBFMjM0Q0FGMDQ2QzZBNUQ4
QTg1Mzk1QjIzNkNDNEFEMkNGMzJBMEMNCiAgICAgICAgICBBREJEQzlEREY2MjBCMEVCOTkwNkQw
OTU3RjZDNkZFQUNENjE1NDY4REYxMDRERTI5NkNEOEYsDQogICAgYiA9IDB4MTBEOUI0QTNEOTA0
N0Q4QjE1NDM1OUFCRkIxQjdGNTQ4NUIwNENFQjg2ODIzN0REQzlERURBDQogICAgICAgICAgOTgy
QTY3OUE1QTkxOUI2MjZENEU1MEE4REQ3MzFCMTA3QTk5NjIzODFGQjVEODA3QkYyNjE4LA0KICAg
IEcgPSAweDIxMjBGQzA1RDNDNjdBOTlERTE2MUQyRjQwOTI2MjJGRUNBNzAxQkU0RjUwRjQ3NTg3
MTRFOEENCiAgICAgICAgICA4N0JCRjJBNjU4RUY4QzIxRTdDNUVGRTk2NTM2MUY2QzI5OTlDMEMy
NDdCMERCRDcwQ0U2QjcsDQogICAgbiA9IDB4MDM0MDM0MDM0MDM0MDM0MDM0MDM0MDM0MDM0MDM0
MDM0MDM0MDM0MDM0MDM0MDM0MDM0MDMNCiAgICAgICAgICA0MDMyM0MzMTNGQUI1MDU4OTcwM0I1
RUM2OEQzNTg3RkVDNjBEMTYxQ0MxNDlDMUFENEE5MSwNCiAgICBoID0gMHgyNzYwLg0KDQogIHNl
Y3Q1NzFrMToNCiAgICBGKDJeNTcxKSB3aXRoIHBlbnRhbm9taWFsIGJhc2lzIChrID0gMiwgNSwg
MTApLA0KICAgIGEgPSAwLA0KICAgIGIgPSAxLA0KICAgIEcgPSAweDAyIDAyNkVCN0E4IDU5OTIz
RkJDIDgyMTg5NjMxIEY4MTAzRkU0IEFDOUNBMjk3IDAwMTJENUQ0DQogICAgICAgIDYwMjQ4MDQ4
IDAxODQxQ0E0IDQzNzA5NTg0IDkzQjIwNUU2IDQ3REEzMDREIEI0Q0VCMDhDDQogICAgICAgIEJC
RDFCQTM5IDQ5NDc3NkZCIDk4OEI0NzE3IDREQ0E4OEM3IEUyOTQ1MjgzIEEwMUM4OTcyLA0KIA0K
U2NoZXJrbCAgICAgICAgICAgICAgICAgICAgIFN0YW5kYXJkcyBUcmFjayAgICAgICAgICAgICAg
ICAgICAgW1BhZ2UgMTRdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgIE9wZW5QR1AgRUND
IEZvcm1hdHMgICAgICAgICAgICAgICAgQXVndXN0IDIwMDENCg0KICAgIG4gPSAweDAyMDAwMDAw
IDAwMDAwMDAwIDAwMDAwMDAwIDAwMDAwMDAwIDAwMDAwMDAwIDAwMDAwMDAwDQogICAgICAgIDAw
MDAwMDAwIDAwMDAwMDAwIDAwMDAwMDAwIDEzMTg1MEUxIEYxOUE2M0U0IEIzOTFBOERCDQogICAg
ICAgIDkxN0Y0MTM4IEI2MzBEODRCIEU1RDYzOTM4IDFFOTFERUI0IDVDRkU3NzhGIDYzN0MxMDAx
LA0KICAgIGggPSA0Lg0KDQogICBzZWN0NTcxcjE6DQogICAgRigyXjU3MSkgd2l0aCBwZW50YW5v
bWlhbCBiYXNpcyAoayA9IDIsIDUsIDEwKSwNCiAgICBhID0gMSwNCiAgICBiID0gMHgwMkY0MEU3
RSAyMjIxRjI5NSBERTI5NzExNyBCN0YzRDYyRiA1QzZBOTdGRiBDQjhDRUZGMQ0KICAgICAgICBD
RDZCQThDRSA0QTlBMThBRCA4NEZGQUJCRCA4RUZBNTkzMyAyQkU3QUQ2NyA1NkE2NkUyOQ0KICAg
ICAgICA0QUZEMTg1QSA3OEZGMTJBQSA1MjBFNERFNyAzOUJBQ0EwQyA3RkZFRkY3RiAyOTU1NzI3
QSwNCiAgICBHID0gMHgwMyAwMzAzMDAxRCAzNEI4NTYyOSA2QzE2QzBENCAwRDNDRDc3NSAwQTkz
RDFEMiA5NTVGQTgwQQ0KICAgICAgICBBNUY0MEZDOCBEQjdCMkFCRCBCREU1Mzk1MCBGNEMwRDI5
MyBDREQ3MTFBMyA1QjY3RkIxNA0KICAgICAgICA5OUFFNjAwMyA4NjE0RjEzOSA0QUJGQTNCNCBD
ODUwRDkyNyBFMUU3NzY5QyA4RUVDMkQxOSwNCiAgICBuID0gMHgwM0ZGRkZGRiBGRkZGRkZGRiBG
RkZGRkZGRiBGRkZGRkZGRiBGRkZGRkZGRiBGRkZGRkZGRg0KICAgICAgICBGRkZGRkZGRiBGRkZG
RkZGRiBGRkZGRkZGRiBFNjYxQ0UxOCBGRjU1OTg3MyAwODA1OUIxOA0KICAgICAgICA2ODIzODUx
RSBDN0REOUNBMSAxNjFERTkzRCA1MTc0RDY2RSA4MzgyRTlCQiAyRkU4NEU0NywNCiAgICBoID0g
Mi4NCg0KOS4yLiBDdXJ2ZXMgb3ZlciBQcmltZS1GaWVsZHMNCg0KICAgc2VjcDE2MGsxDQogICAg
RihwKSB3aXRoDQogICAgcCA9IEZGRkZGRkZGIEZGRkZGRkZGIEZGRkZGRkZGIEZGRkZGRkZFIEZG
RkZBQzczLA0KICAgIGEgPSAwLA0KICAgIGIgPSA3LA0KICAgIEcgPSAwMiAzQjRDMzgyQyBFMzdB
QTE5MiBBNDAxOUU3NiAzMDM2RjRGNSBERDREN0VCQiwNCiAgICBuID0gMDEgMDAwMDAwMDAgMDAw
MDAwMDAgMDAwMUI4RkEgMTZERkFCOUEgQ0ExNkI2QjMsDQogICAgaCA9IDAxLg0KDQogICBzZWNw
MTYwcjENCiAgICBGKHApIHdpdGgNCiAgICBwID0gRkZGRkZGRkYgRkZGRkZGRkYgRkZGRkZGRkYg
RkZGRkZGRkYgN0ZGRkZGRkYsDQogICAgYSA9IHAtMywNCiAgICBiID0gMUM5N0JFRkMgNTRCRDdB
OEIgNjVBQ0Y4OUYgODFENEQ0QUQgQzU2NUZBNDUsDQogICAgRyA9IDAyIDRBOTZCNTY4IDhFRjU3
MzI4IDQ2NjQ2OTg5IDY4QzM4QkI5IDEzQ0JGQzgyLA0KICAgIG4gPSAwMSAwMDAwMDAwMCAwMDAw
MDAwMCAwMDAxRjRDOCBGOTI3QUVEMyBDQTc1MjI1NywNCiAgICBoID0gMDEuDQoNCiAgIHNlY3Ax
NjByMg0KICAgIEYocCkgd2l0aA0KICAgIHAgPSBGRkZGRkZGRiBGRkZGRkZGRiBGRkZGRkZGRiBG
RkZGRkZGRSBGRkZGQUM3MywNCiAgICBhID0gcC0zLA0KICAgIGIgPSBCNEUxMzREMyBGQjU5RUI4
QiBBQjU3Mjc0OSAwNDY2NEQ1QSBGNTAzODhCQSwNCiAgICBHID0gMDIgNTJEQ0IwMzQgMjkzQTEx
N0UgMUY0RkYxMUIgMzBGNzE5OUQgMzE0NENFNkQsDQogICAgbiA9IDAxIDAwMDAwMDAwIDAwMDAw
MDAwIDAwMDAzNTFFIEU3ODZBODE4IEYzQTFBMTZCLA0KICAgIGggPSAwMS4NCg0KICAgc2VjcDE5
MmsxOg0KICAgIEYocCkgd2l0aA0KICAgIHAgPSAweEZGRkZGRkZGIEZGRkZGRkZGIEZGRkZGRkZG
IEZGRkZGRkZGIEZGRkZGRkZFIEZGRkZFRTM3LA0KICAgIGEgPSAwLA0KDQpTY2hlcmtsICAgICAg
ICAgICAgICAgICAgICAgU3RhbmRhcmRzIFRyYWNrICAgICAgICAgICAgICAgICAgICBbUGFnZSAx
NV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgT3BlblBHUCBFQ0MgRm9ybWF0cyAgICAg
ICAgICAgICAgICBBdWd1c3QgMjAwMQ0KDQogICAgYiA9IDMsDQogICAgRyA9IDB4MDMgREI0RkYx
MEUgQzA1N0U5QUUgMjZCMDdEMDIgODBCN0Y0MzQgMURBNUQxQjEgRUFFMDZDN0QsDQogICAgbiA9
IDB4RkZGRkZGRkYgRkZGRkZGRkYgRkZGRkZGRkUgMjZGMkZDMTcgMEY2OTQ2NkEgNzRERUZEOEQs
DQogICAgaCA9IDEuDQoNCiAgIHByaW1lMTkydjEgLyBzZWNwMTkycjE6DQogICAgRihwKSB3aXRo
DQogICAgcCA9IDB4RkZGRkZGRkYgRkZGRkZGRkYgRkZGRkZGRkYgRkZGRkZGRkUgRkZGRkZGRkYg
RkZGRkZGRkYsDQogICAgYSA9IHAtMywNCiAgICBiID0gMHg2NDIxMDUxOSBFNTlDODBFNyAwRkE3
RTlBQiA3MjI0MzA0OSBGRUI4REVFQyBDMTQ2QjlCMSwNCiAgICBHID0gMHgwMyAxODhEQTgwRSBC
MDMwOTBGNiA3Q0JGMjBFQiA0M0ExODgwMCBGNEZGMEFGRCA4MkZGMTAxMiwNCiAgICBuID0gMHhG
RkZGRkZGRiBGRkZGRkZGRiBGRkZGRkZGRiA5OURFRjgzNiAxNDZCQzlCMSBCNEQyMjgzMSwNCiAg
ICBoID0gMS4NCg0KICAgcHJpbWUxOTJ2MjoNCiAgICBGKHApIHdpdGgNCiAgICBwID0gMHhGRkZG
RkZGRiBGRkZGRkZGRiBGRkZGRkZGRiBGRkZGRkZGRSBGRkZGRkZGRiBGRkZGRkZGRiwNCiAgICBh
ID0gcC0zLA0KICAgIGIgPSAweENDMjJENkRGIEI5NUM2QjI1IEU0OUMwRDYzIDY0QTRFNTk4IDBD
MzkzQUEyIDE2NjhEOTUzLA0KICAgIEcgPSAweDAzIEVFQTJCQUU3IEUxNDk3ODQyIEYyREU3NzY5
IENGRTlDOTg5IEMwNzJBRDY5IDZGNDgwMzRBLA0KICAgIG4gPSAweEZGRkZGRkZGIEZGRkZGRkZG
IEZGRkZGRkZFIDVGQjFBNzI0IERDODA0MTg2IDQ4RDhERDMxLA0KICAgIGggPSAxLg0KDQogICBw
cmltZTE5MnYzOg0KICAgIEYocCkgd2l0aA0KICAgIHAgPSAweEZGRkZGRkZGIEZGRkZGRkZGIEZG
RkZGRkZGIEZGRkZGRkZFIEZGRkZGRkZGIEZGRkZGRkZGLA0KICAgIGEgPSBwLTMsDQogICAgYiA9
IDB4MjIxMjNEQzIgMzk1QTA1Q0EgQTc0MjNEQUUgQ0NDOTQ3NjAgQTdENDYyMjUgNkJENTY5MTYs
DQogICAgRyA9IDB4MDIgN0QyOTc3ODEgMDBDNjVBMUQgQTE3ODM3MTYgNTg4RENFMkIgOEI0QUVF
OEUgMjI4RjE4OTYsDQogICAgbiA9IDB4RkZGRkZGRkYgRkZGRkZGRkYgRkZGRkZGRkYgN0E2MkQw
MzEgQzgzRjQyOTQgRjY0MEVDMTMsDQogICAgaCA9IDEuDQoNCiAgIHNlY3AyMjRrMToNCiAgICBG
KHApIHdpdGgNCiAgICBwID0gMHhGRkZGRkZGRiBGRkZGRkZGRiBGRkZGRkZGRg0KICAgICAgICBG
RkZGRkZGRiBGRkZGRkZGRiBGRkZGRkZGRSBGRkZGRTU2RCwNCiAgICBhID0gMCwNCiAgICBiID0g
NSwNCiAgICBHID0gMHgwMyBBMTQ1NUIzMyA0REYwOTlERiAzMEZDMjhBMQ0KICAgICAgICA2OUE0
NjdFOSBFNDcwNzVBOSAwRjdFNjUwRSBCNkI3QTQ1QywNCiAgICBuID0gMHgwMSAwMDAwMDAwMCAw
MDAwMDAwMCAwMDAwMDAwMA0KICAgICAgICAwMDAxRENFOCBEMkVDNjE4NCBDQUYwQTk3MSA3NjlG
QjFGNywNCiAgICBoID0gMS4NCg0KICAgc2VjcDIyNHIxOg0KICAgIEYocCkgd2l0aA0KICAgIHAg
PSAweEZGRkZGRkZGIEZGRkZGRkZGIEZGRkZGRkZGDQogICAgICAgIEZGRkZGRkZGIDAwMDAwMDAw
IDAwMDAwMDAwIDAwMDAwMDAxLA0KICAgIGEgPSBwLTMsDQogICAgYiA9IDB4QjQwNTBBODUgMEMw
NEIzQUIgRjU0MTMyNTYNCiAgICAgICAgNTA0NEIwQjcgRDdCRkQ4QkEgMjcwQjM5NDMgMjM1NUZG
QjQsDQogICAgRyA9IDB4MDIgQjcwRTBDQkQgNkJCNEJGN0YgMzIxMzkwQjkNCg0KU2NoZXJrbCAg
ICAgICAgICAgICAgICAgICAgIFN0YW5kYXJkcyBUcmFjayAgICAgICAgICAgICAgICAgICAgW1Bh
Z2UgMTZdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgIE9wZW5QR1AgRUNDIEZvcm1hdHMg
ICAgICAgICAgICAgICAgQXVndXN0IDIwMDENCg0KICAgICAgICA0QTAzQzFEMyA1NkMyMTEyMiAz
NDMyODBENiAxMTVDMUQyMSwNCiAgICBuID0gMHhGRkZGRkZGRiBGRkZGRkZGRiBGRkZGRkZGRg0K
ICAgICAgICBGRkZGMTZBMiBFMEI4RjAzRSAxM0REMjk0NSA1QzVDMkEzRCwNCiAgICBoID0gMS4N
Cg0KICAgcHJpbWUyMzl2MToNCiAgICBGKHApIHdpdGgNCiAgICBwID0gMHg3RkZGIEZGRkZGRkZG
IEZGRkZGRkZGIEZGRkY3RkZGDQogICAgICAgIEZGRkZGRkZGIDgwMDAwMDAwIDAwMDA3RkZGIEZG
RkZGRkZGLA0KICAgIGEgPSBwLTMsDQogICAgYiA9IDB4NkIwMSA2QzNCRENGMSA4OTQxRDBENiA1
NDkyMTQ3NQ0KICAgICAgICBDQTcxQTlEQiAyRkIyN0QxRCAzNzc5NjE4NSBDMjk0MkMwQSwNCiAg
ICBHID0gMHgwMjBGRkEgOTYzQ0RDQTggODE2Q0NDMzMgQjg2NDJCRUQNCiAgICAgICAgRjkwNUMz
RDMgNTg1NzNEM0YgMjdGQkJEM0IgM0NCOUFBQUYsDQogICAgbiA9IDB4N0ZGRiBGRkZGRkZGRiBG
RkZGRkZGRiBGRkZGN0ZGRg0KICAgICAgICBGRjlFNUU5QSA5RjVEOTA3MSBGQkQxNTIyNiA4ODkw
OUQwQiwNCiAgICBoID0gMS4NCg0KICAgcHJpbWUyMzl2MjoNCiAgICBGKHApIHdpdGgNCiAgICBw
ID0gMHg3RkZGIEZGRkZGRkZGIEZGRkZGRkZGIEZGRkY3RkZGDQogICAgICAgIEZGRkZGRkZGIDgw
MDAwMDAwIDAwMDA3RkZGIEZGRkZGRkZGLA0KICAgIGEgPSBwLTMsDQogICAgYiA9IDB4NjE3RiBB
QjY4MzI1NyA2Q0JCRkVENSAwRDk5RjAyNA0KICAgICAgICA5QzNGRUU1OCBCOTRCQTAwMyA4QzdB
RTg0QyA4QzgzMkYyQywNCiAgICBHID0gMHgwMjM4QUYgMDlEOTg3MjcgNzA1MTIwQzkgMjFCQjVF
OUUNCiAgICAgICAgMjYyOTZBM0MgRENGMkYzNTcgNTdBMEVBRkQgODdCODMwRTcsDQogICAgbiA9
IDB4N0ZGRiBGRkZGRkZGRiBGRkZGRkZGRiBGRkZGODAwMA0KICAgICAgICAwMENGQTdFOCA1OTQz
NzdENCAxNEMwMzgyMSBCQzU4MjA2MywNCiAgICBoID0gMS4NCg0KICAgcHJpbWUyMzl2MzoNCiAg
ICBGKHApIHdpdGgNCiAgICBwID0gMHg3RkZGIEZGRkZGRkZGIEZGRkZGRkZGIEZGRkY3RkZGDQog
ICAgICAgIEZGRkZGRkZGIDgwMDAwMDAwIDAwMDA3RkZGIEZGRkZGRkZGLA0KICAgIGEgPSBwLTMs
DQogICAgYiA9IDB4MjU1NyAwNUZBMkEzMCA2NjU0QjFGNCBDQjAzRDZBNw0KICAgICAgICA1MEEz
MEMyNSAwMTAyRDQ5OCA4NzE3RDlCQSAxNUFCNkQzRSwNCiAgICBHID0gMHgwMzY3NjggQUU4RTE4
QkIgOTJDRkNGMDAgNUM5NDlBQTINCiAgICAgICAgQzZEOTQ4NTMgRDBFNjYwQkIgRjg1NEIxQzkg
NTA1RkU5NUEsDQogICAgbiA9IDB4N0ZGRiBGRkZGRkZGRiBGRkZGRkZGRiBGRkZGN0ZGRg0KICAg
ICAgICBGRjk3NURFQiA0MUIzQTYwNSA3QzNDNDMyMSA0NjUyNjU1MSwNCiAgICBoID0gMTsNCg0K
ICAgc2VjcDI1NmsxDQogICAgRihwKSB3aXRoDQogICAgcCA9IDB4RkZGRkZGRkYgRkZGRkZGRkYg
RkZGRkZGRkYgRkZGRkZGRkYNCiAgICAgICAgRkZGRkZGRkYgRkZGRkZGRkYgRkZGRkZGRkUgRkZG
RkZDMkYsDQogICAgYSA9IDAsDQogICAgYiA9IDcsDQogICAgRyA9IDB4MDIgNzlCRTY2N0UgRjlE
Q0JCQUMgNTVBMDYyOTUgQ0U4NzBCMDcNCiAgICAgICAgMDI5QkZDREIgMkRDRTI4RDkgNTlGMjgx
NUIgMTZGODE3OTgsDQoNClNjaGVya2wgICAgICAgICAgICAgICAgICAgICBTdGFuZGFyZHMgVHJh
Y2sgICAgICAgICAgICAgICAgICAgIFtQYWdlIDE3XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAg
ICAgICBPcGVuUEdQIEVDQyBGb3JtYXRzICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDAxDQoNCiAg
ICBuID0gMHhGRkZGRkZGRiBGRkZGRkZGRiBGRkZGRkZGRiBGRkZGRkZGRQ0KICAgICAgICBCQUFF
RENFNiBBRjQ4QTAzQiBCRkQyNUU4QyBEMDM2NDE0MSwNCiAgICBoID0gMS4NCg0KICAgcHJpbWUy
NTZ2MSAvIHNlY3AyNTZyMToNCiAgICBGKHApIHdpdGgNCiAgICBwID0gMHhGRkZGRkZGRiAwMDAw
MDAwMSAwMDAwMDAwMCAwMDAwMDAwMA0KICAgICAgICAwMDAwMDAwMCBGRkZGRkZGRiBGRkZGRkZG
RiBGRkZGRkZGRiwNCiAgICBhID0gcC0zLA0KICAgIGIgPSAweDVBQzYzNUQ4IEFBM0E5M0U3IEIz
RUJCRDU1IDc2OTg4NkJDDQogICAgICAgIDY1MUQwNkIwIENDNTNCMEY2IDNCQ0UzQzNFIDI3RDI2
MDRCLA0KICAgIEcgPSAweDAzIDZCMTdEMUYyIEUxMkM0MjQ3RiA4QkNFNkU1IDYzQTQ0MEYyDQog
ICAgICAgIDc3MDM3RDgxIDJERUIzM0EwRiA0QTEzOTQ1IEQ4OThDMjk2LA0KICAgIG4gPSAweEZG
RkZGRkZGIDAwMDAwMDAwIEZGRkZGRkZGIEZGRkZGRkZGDQogICAgICAgIEJDRTZGQUFEIEE3MTc5
RTg0IEYzQjlDQUMyIEZDNjMyNTUxLA0KICAgIGggPSAxLg0KDQogICBzZWNwMzg0cjE6DQogICAg
RihwKSB3aXRoDQogICAgcCA9IDB4RkZGRkZGRkYgRkZGRkZGRkYgRkZGRkZGRkYgRkZGRkZGRkYg
RkZGRkZGRkYgRkZGRkZGRkYNCiAgICAgICAgRkZGRkZGRkYgRkZGRkZGRkUgRkZGRkZGRkYgMDAw
MDAwMDAgMDAwMDAwMDAgRkZGRkZGRkYsDQogICAgYSA9IHAtMywNCiAgICBiID0gMHhCMzMxMkZB
NyBFMjNFRTdFNCA5ODhFMDU2QiBFM0Y4MkQxOSAxODFEOUM2RSBGRTgxNDExMg0KICAgICAgICAw
MzE0MDg4RiA1MDEzODc1QSBDNjU2Mzk4RCA4QTJFRDE5RCAyQTg1QzhFRCBEM0VDMkFFRiwNCiAg
ICBHID0gMHgwMyBBQTg3Q0EyMiBCRThCMDUzNyA4RUIxQzcxRSBGMzIwQUQ3NCA2RTFEM0I2MiA4
QkE3OUI5OA0KICAgICAgICA1OUY3NDFFMCA4MjU0MkEzOCA1NTAyRjI1RCBCRjU1Mjk2QyAzQTU0
NUUzOCA3Mjc2MEFCNywNCiAgICBuID0gMHhGRkZGRkZGRiBGRkZGRkZGRiBGRkZGRkZGRiBGRkZG
RkZGRiBGRkZGRkZGRiBGRkZGRkZGRg0KICAgICAgICBDNzYzNEQ4MSBGNDM3MkRERiA1ODFBMERC
MiA0OEIwQTc3QSBFQ0VDMTk2QSBDQ0M1Mjk3MywNCiAgICBoID0gMS4NCg0KICAgc2VjcDUyMXIx
Og0KICAgIEYocCkgd2l0aA0KICAgIHAgPSAweDAxRkYgRkZGRkZGRkYgRkZGRkZGRkYgRkZGRkZG
RkYgRkZGRkZGRkYgRkZGRkZGRkYNCiAgICAgICAgRkZGRkZGRkYgRkZGRkZGRkYgRkZGRkZGRkYg
RkZGRkZGRkYgRkZGRkZGRkYgRkZGRkZGRkYNCiAgICAgICAgRkZGRkZGRkYgRkZGRkZGRkYgRkZG
RkZGRkYgRkZGRkZGRkYgRkZGRkZGRkYgPSAyXjUyMS0xLA0KICAgIGEgPSBwLTMsDQogICAgYiA9
IDB4MDA1MSA5NTNFQjk2MSA4RTFDOUExRiA5MjlBMjFBMCBCNjg1NDBFRSBBMkRBNzI1Qg0KICAg
ICAgICA5OUIzMTVGMyBCOEI0ODk5MSA4RUYxMDlFMSA1NjE5Mzk1MSBFQzdFOTM3QiAxNjUyQzBC
RA0KICAgICAgICAzQkIxQkYwNyAzNTczREY4OCAzRDJDMzRGMSBFRjQ1MUZENCA2QjUwM0YwMCwN
CiAgICBHID0gMHgwMjAwQzYgODU4RTA2QjcgMDQwNEU5Q0QgOUUzRUNCNjYgMjM5NUI0NDIgOUM2
NDgxMzkNCiAgICAgICAgMDUzRkI1MjEgRjgyOEFGNjAgNkI0RDNEQkEgQTE0QjVFNzcgRUZFNzU5
MjggRkUxREMxMjcNCiAgICAgICAgQTJGRkE4REUgMzM0OEIzQzEgODU2QTQyOUIgRjk3RTdFMzEg
QzJFNUJENjYsDQogICAgbiA9IDB4MDFGRiBGRkZGRkZGRiBGRkZGRkZGRiBGRkZGRkZGRiBGRkZG
RkZGRiBGRkZGRkZGRg0KICAgICAgICBGRkZGRkZGRiBGRkZGRkZGRiBGRkZGRkZGQSA1MTg2ODc4
MyBCRjJGOTY2QiA3RkNDMDE0OA0KICAgICAgICBGNzA5QTVEMCAzQkI1QzlCOCA4OTlDNDdBRSBC
QjZGQjcxRSA5MTM4NjQwOSwNCiAgICBoID0gMS4NCg0KOS4zLiBDdXJ2ZXMgb3ZlciBPZGQgRXh0
ZW5zaW9uIEZpZWxkcw0KDQogICBDdXJ2ZXMgb2YgdGhpcyB0eXBlIHdpbGwgYmUgYWRkZWQgaW4g
dGhlIGZ1dHVyZS4NCg0KDQoNClNjaGVya2wgICAgICAgICAgICAgICAgICAgICBTdGFuZGFyZHMg
VHJhY2sgICAgICAgICAgICAgICAgICAgIFtQYWdlIDE4XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAg
ICAgICAgICBPcGVuUEdQIEVDQyBGb3JtYXRzICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDAxDQoN
CjkuNC4gQWRkaW5nIE93biBOYW1lZCBDdXJ2ZXMNCg0KICAgVG8gc3RvcmUgc2VsZiBjcmVhdGVk
IG5hbWVkIGN1cnZlcywgaW1wbGVtZW50YXRpb25zIFNIT1VMRCB1c2UgdGhlDQogICBzYW1lIGZv
cm1hdCBhcyBmb3IgcHVibGljIGtleXMsIHdpdGggdGhlIGZvbGxvd2luZyBjaGFuZ2VzOg0KICAg
LSB0aGUgZmllbGQgZGVzY3JpcHRvciBEIE1VU1QgTk9UIGhhdmUgdGhlIHZhbHVlIDAsDQogICAt
IG5vIHB1YmxpYyBwb2ludCBRIGlzIGNvbnRhaW5lZC4NCiAgIA0KICAgT3duIG5hbWVkIGN1cnZl
cyBTSE9VTEQgYmUgc2lnbmVkIGxpa2UgcHVibGljIGtleXMgdG8gZW5zdXJlIHRoZWlyDQogICB2
YWxpZGl0eS4gSW1wbGVtZW50YXRpb25zIE1BWSBhZGRpdGlvbmFseSB2YWxpZGF0ZSB0aGVtIG9u
Y2UgdGhleQ0KICAgcmVjZWl2ZSB0aGVtLg0KDQo5LjUuIFJldm9jZWQgQ3VydmVzDQoNCiAgIEl0
IG1heSBvY2N1cmUgdGhhdCBmb3Igc29tZSBuYW1lZCBjdXJ2ZXMgYWxyZWFkeSBpbiB1c2Ugd2Vh
a25lc3Nlcw0KICAgd2lsbCBiZSBkaXNjb3ZlcmVkLiBUaGVzZSBjdXJ2ZXMgYXJlIG1lbnRpb25l
ZCBpbiB0aGlzIHNlY3Rpb24gYW5kDQogICB0aGV5IFNIT1VMRCBub3QgYmUgdXNlZCBmb3Iga2V5
IGdlbmVyYXRpb24gYW55IGZ1cnRoZXIhDQogICANCiAgIChUaGlzIGZpcnN0IGRyYWZ0IGluY2x1
ZGVzIG5vIGN1cnZlcyBmb3Igd2hpY2ggd2Vha25lc3NlcyBhcmUga25vd24uKSANCg0KMTAuIFNl
Y3V0aXR5IENvbnNpZGVyYXRpb25zDQoNCiAgIFVzaW5nIEVDQyBwcm92aWRlcyBzaG9ydGVyIGtl
eXMgYXQgdGhlIHNhbWUgc2VjdXJpdHkgbGV2ZWwgYXMgUlNBLA0KICAgYnV0IGl0J3Mgc3RpbGwg
bm90IHN1cmUgdGhhdCB0aGVyZSB3aWxsIGJlIG5vIGZhc3QgcG9pbnQtZGl2aXNpb24NCiAgIGFs
Z29yaXRobSBpbiB0aGUgZnV0dXJlLiBIb3dldmVyLCB0aGlzIGlzIGEgcHJvYmxlbSBpbmRlcGVu
ZGVudA0KICAgdG8gZmFjdG9yaXppbmcgbnVtYmVycywgc28gaWYgZWl0aGVyIG9mIHRoZSB0d28g
YWxnb3JpdGhtcyBpcyBicm9rZW4sDQogICB0aGUgb3RoZXIgbWF5IHN0aWxsIGJlIGNvbnNpZGVy
ZWQgc2VjdXJlLiBUaGlzIGluZGVlZCBJUyBhbg0KICAgaW1wcm92ZW1lbnQgaW4gc2VjdXJpdHku
DQogICANCiAgIFNvbWUgb2YgdGhlIG51bWJlciBmaWVsZHMgdXNlZCBmb3IgZWxsaXB0aWMgY3Vy
dmUgY3J5cHRvZ3JhcGh5IGhhdmUNCiAgIGJlZW4gYW5hbHl6ZWQgbGVzcyB0aGFuIG90aGVycy4g
RXNwZWNpYWx5IG9kZCBleHRlbnNpb24gZmllbGRzIGJlIGENCiAgIHZlcnkgbmV3IHJlc2VhcmNo
IHRvcGljLCBhbHRob3VnaCB0aGV5IGFyZSBwcmVzZW50bHkgY29uc2lkZXJlZA0KICAgc3Ryb25n
Lg0KICAgDQogICBBbm90aGVyIHByb2JsZW0gb2YgZWxsaXB0aWMgY3VydmVzIGlzLCB0aGF0IGlu
IHRoZSBwYXN0IHdlYWsgY3VydmVzDQogICBoYXZlIGJlZW4gZGV2ZWxvcGVkIChsZWFkaW5nIHRv
IGNvbmRpdGlvbnMgbGlrZSBNT1YpIGFuZCBpdCBpcyBub3QNCiAgIHN1cmUgdGhhdCBlLmcuIHRo
ZSBoZXJlIGdpdmVuIG5hbWVkIGN1cnZlcyB3aWxsIGJlIHN0cm9uZyBlbm91Z2gNCiAgIGluIHRo
ZSBmdXR1cmUuDQogICANCiAgIE9mIGNvdXJzZSwgYXMgYW4gdXBkYXRlIG9mIFJGQyAyNDQwIFsx
XSwgbW9zdCBzZWN1cml0eSBjb25zaWRlcmF0aW9ucw0KICAgbWVudGlvbmVkIHRoZXJlIGFsc28g
YXBwbHkgdG8gdGhpcyBkb2N1bWVudC4gVGhhdCBpczogY2hlY2sgdGhlDQogICBsYXRlc3QgbGl0
YXJhdHVyZSBmb3IgbmV3bHkgZm91bmQgYXR0YWNrczsgYWx3YXlzIGtlZXAgaW4gbWluZCB0aGF0
DQogICBhIHNlY3JldCBrZXkgbWF5IG5vdCBiZSBjb250cm9sbGVkIGJ5IHRoZSBwcm9wZXIgcGF0
cnk7IHNlY3VyaXR5DQogICBkZXBlbmRzIGhpZ2hseSBvbiB0aGUgcmFuZG9tbmVzcyBvZiBjZXJ0
YWluIHBhcmFtZXRlcnMuDQogICAgIA0KICAgQWxzbyBpdCBpcyBwb3NzaWJsZSB0aGF0IHVzZXJz
IGdlbmVyYXRlIHRoZWlyIG93biBjdXJ2ZXMgd2l0aG91dA0KICAgdmVyaWZ5aW5nIHRoZW0gYWdh
aW5zdCBhbGwga25vd24gYXR0YWNrcy4gVGhlcmVmb3JlIGltcGxlbWVudGF0aW9ucw0KICAgbmVl
ZCB0byB2ZXJpZnkgdGhlbSBvbiB0aGVpciBvd24sIHdoaWNoIHRha2VzIHRpbWUgKGFuZCBsaWtl
IGFueXRoaW5nDQogICB0aGF0IHNlZW1zIHRvIGJlIG9ic29sZXRlIG1hbnkgaW1wbGVtZW50YXRp
b25zIHdvbid0IGRvIGl0IC0gYXMgc2Vlbg0KICAgd2l0aCBvdGhlciBhbGdvcml0aG1zIHRvbyku
DQoNCg0KDQoNClNjaGVya2wgICAgICAgICAgICAgICAgICAgICBTdGFuZGFyZHMgVHJhY2sgICAg
ICAgICAgICAgICAgICAgIFtQYWdlIDE5XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICBP
cGVuUEdQIEVDQyBGb3JtYXRzICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDAxDQoNCjExLiBSZWZl
cmVuY2VzDQogICANCiAgIFsxXSAgSi4gQ2FsbGFzLCBMLiBEb25uZXJoYWNrZSwgSC4gRmlubmV5
IGFuZCBSLiBUaGF5ZXI6ICJPcGVuUEdQDQogICAgICAgIE1lc3NhZ2UgRm9ybWF0IiwgTmV0d29y
ayBXb3JraW5nIEdyb3VwIFJlcXVlc3QgZm9yIENvbW1lbnRzDQogICAgICAgIDI0NDAsIE5vdmVt
YmVyIDE5OTguDQoNCiAgIFsyXSAgSUVFRSBQMTM2My9EMTMsICJTdGFuZGFyZCBTcGVjaWZpY2F0
aW9ucyBmb3IgUHVibGljIEtleQ0KICAgICAgICBDcnlwdG9ncmFwaHkiLCBJbnN0aXR1dGUgb2Yg
RWxlY3RyaWNhbCBhbmQgRWxlY3Ryb25pY3MNCiAgICAgICAgRW5naW5lZXJzLCBOb3ZlbWJlciAx
OTk5Lg0KICAgICAgICANCiAgIFszXSAgQS4gTWVuZXplcywgVC4gT2thbW90byBhbmQgUy4gVmFu
c3RvbmU6ICJSZWR1Y2luZyBlbGxpcHRpYyBjdXJ2ZQ0KICAgICAgICBsb2dhcml0aG1zIHRvIGxv
Z2FyaXRobXMgaW4gYSBmaW5pdGUgZmllbGQiLCBJRUVFIFRyYW5zYWN0aW9ucw0KICAgICAgICBv
biBJbmZvcm1hdGlvbiBUaGVvcnkgMzkgcHAuIDE2MzktMTY0NiwgMTk5My4NCg0KICAgWzRdICBB
TlNJIFg5LjYyLTE5OTksICJQdWJsaWMgS2V5IENyeXB0b2dyYXBoeSBGb3IgVGhlIEZpbmFuY2lh
bA0KICAgICAgICBTZXJ2aWNlcyBJbmR1c3RyeTogVGhlIEVsbGlwdGljIEN1cnZlIERpZ2l0YWwg
U2lnbmF0dXJlIA0KICAgICAgICBBbGdvcml0aG0gKEVDRFNBKSIsIEFtZXJpY2FuIE5hdGlvbmFs
IFN0YW5kYXJkcyBJbnN0aXR1dGUsIDE5OTguDQoNCiAgIFs1XSAgV29ya2luZyBEcmFmdCBBTlNJ
IFg5LjYzLCAiUHVibGljIEtleSBDcnlwdG9ncmFwaHkgRm9yIFRoZQ0KICAgICAgICBGaW5hbmNp
YWwgU2VydmljZXMgSW5kdXN0cnk6IEtleSBBZ3JlZW1lbnQgYW5kIEtleSBUcmFuc3BvcnQNCiAg
ICAgICAgdXNpbmcgRWxsaXB0aWMgQ3VydmUgQ3J5cHRvZ3JhcHkgKEVDQykiLCBBTlNJLCBKYW51
YXJ5IDE5OTkuDQoNCiAgIFs2XSAgU0VDIDIsICJSZWNvbW1lbmRlZCBFbGxpcHRpYyBDdXJ2ZSBE
b21haW4gUGFyYW1ldGVycyIsDQogICAgICAgIFN0YW5kYXJkcyBmb3IgRWZmaWNpZW50IENyeXB0
b2dyYXBoeSBHcm91cCwgMjAwMC4NCg0KICAgWzddICBOaWdlbCBTbWFydCwgRmxvcmlhbiBIZXNz
LCBQaWVycmljayBHYXVkcnk6ICJDb25zdHJ1Y3RpdmUgYW5kDQogICAgICAgIERlc3RydWN0aXZl
IEZhY2V0cyBvZiBXZWlsIERlc2NlbnQgb24gRWxsaXB0aWMgQ3VydmVzIiwgVHJ1c3RlZA0KICAg
ICAgICBlLVNlcnZpY2VzIGF0IEhQIExhYm9yYXRvcmllcyBCcmlzdG9sLCBKYW51YXJ5IDIwMDAu
DQogICAgICAgIA0KICAgWzhdICBTLiBCcmFkbmVyOiAiVGhlIEludGVybmV0IFN0YW5kYXJkcyBQ
cm9jZXNzIC0gUmV2aXNpb24gMyIsDQogICAgICAgIE5ldHdvcmsgV29ya2luZyBHcm91cCBSRkMg
MjAyNiwgT2N0b2JlciAxOTk2Lg0KDQogICBbOV0gIFMuIEJyYWRuZXI6ICJLZXkgd29yZHMgZm9y
IHVzZSBpbiBSRkNzIHRvIEluZGljYXRlIFJlcXVpcmVtZW50DQogICAgICAgIExldmVscyIsIE5l
dHdvcmsgV29ya2luZyBHcm91cCBSRkMgMjExOSwgTWFyY2ggMTk5Ny4NCg0KMTIuIEF1dGhvcnMN
Cg0KICAgRG9taW5pa3VzIFNjaGVya2wNCiAgIEJpb2RhdGEgQXBwbGljYXRpb24gU2VjdXJpdHkg
QUcNCiAgIENocmlzdGlhbi1QbGVzcy1TdHIuIDExLTEzDQogICA2MzA2OSBPZmZlbmJhY2gsIEdl
cm1hbnkNCiAgIEVNYWlsOiBkb21pbmlrdXMuc2NoZXJrbEBiaW9kYXRhLmNvbQ0KICAgUGhvbmU6
ICs0OSAoMCkgNjkgLyA4MDAgNzA2IC0gMA0KDQogICBDby1BdXRob3I6DQoNCiAgIENocmlzdG9w
aCBGYXVzYWsNCiAgIEJpb2RhdGEgQXBwbGljYXRpb24gU2VjdXJpdHkgQUcNCiAgIEVNYWlsOiBj
aHJpc3RvcGguZmF1c2FrQGJpb2RhdGEuY29tDQoNCg0KDQoNClNjaGVya2wgICAgICAgICAgICAg
ICAgICAgICBTdGFuZGFyZHMgVHJhY2sgICAgICAgICAgICAgICAgICAgIFtQYWdlIDIwXQ0K

------_=_NextPart_001_01C120C7.1C1701C3--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f79AZqv04612 for ietf-openpgp-bks; Thu, 9 Aug 2001 03:35:52 -0700 (PDT)
Received: from xena.pkiclue.com (IDENT:[e-mail] [216.218.196.15]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f79AZoN04606 for <[e-mail]>; Thu, 9 Aug 2001 03:35:50 -0700 (PDT)
Received: from lygoth.tillerman.to (IDENT:root@localhost [127.0.0.1]) by xena.pkiclue.com (8.9.3/8.9.3) with ESMTP id DAA12295; Thu, 9 Aug 2001 03:35:24 -0700
Message-Id: <5.1.0.14.2.20010809113314.00ac0dc0@127.0.01>
X-Sender: rodney@127.0.01
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 09 Aug 2001 11:34:45 -0700
To: [e-mail]
From: Rodney Thayer <[e-mail]>
Subject: Re: Draft openPGP ECC formats
Cc: [e-mail]
In-Reply-To: <p05100103b796e505fde9@[62.188.15.244]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

This implies severe process failure -- the draft editor isn't
supposed to let drafts get in without permission from the WG chair.

(A hard lesson we learned in IPsec...)

At 01:47 PM 8/8/01 +0100, John  W Noerenberg II wrote:

>At 3:17 PM +0200 8/7/01, Dominikus Scherkl wrote:
>>We consider a new document (attached) about how to store elliptic
>>curve cipher keys and signatures in openPGP messages and how to
>>encrypt/decrypt with ECC vs. sign and verify with ECDSA.
>>
>>You can find it also under
>>http://download.biodata.com/documents/draft-ietf-openpgp-ecc-formats.txt
>
>Please submit this as a personal draft.  This is not a working group item 
>at present.
>--
>
>john noerenberg
>[e-mail]
>   --------------------------------------------------------------------------
>   Peace of mind isn't at all superficial, really.  It's the whole thing.
>   That which produces it is good maintenance; that which disturbs it
>   is poor maintenance.
>   -- Zen and the Art of Motorcycle Maintenance, Robert M. Pirsig, 1974
>   --------------------------------------------------------------------------



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f797pDN22618 for ietf-openpgp-bks; Thu, 9 Aug 2001 00:51:13 -0700 (PDT)
Received: from enigma.cyphers.net (enigma.cyphers.net [64.220.173.136]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f797pBN22613 for <[e-mail]>; Thu, 9 Aug 2001 00:51:11 -0700 (PDT)
Message-Id: <[e-mail]>
Received: from localhost (bassomatic.cyphers.net [64.220.173.155]) by enigma.cyphers.net (Netscape Messaging Server 4.15) with ESMTP id GHSIPE00.VO8; Thu, 9 Aug 2001 00:41:38 -0700 
Date: Thu, 9 Aug 2001 00:51:14 -0700
From: Will Price <[e-mail]>
Content-Type: text/plain; format=flowed; charset=us-ascii
Subject: Re: Draft openPGP ECC formats
Cc: OpenPGP mailing list <[e-mail]>
To: John  W Noerenberg II <[e-mail]>
X-Mailer: Apple Mail (2.388)
In-Reply-To: <p05100101b79728abcbde@[62.188.15.244]>
Mime-Version: 1.0 (Apple Message framework v388)
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

John:

PGP would be strongly supportive of including an ECC draft 
within the charter of the WG. While we do not support ECC now, 
the lack of a draft certainly does not help any potential for 
supporting it in the future.



On Wednesday, August 8, 2001, at 10:49 AM, John W Noerenberg II wrote:

> I've requested Dominikus edit his draft to conform to IETF 
> guidelines, and resubmit it as a personal draft.  Currently,  
> further specification of ECC is not part of our charter, 
> although it might be necessary in order for elliptic curves to 
> be useful within OpenPGP.
>
> Once his draft has been accepted as I-D, I would like your 
> opinions on whether is should be included as a WG item.  Are 
> implementers utilizing ECC in their implementations?
>
> I've asked Dominikus to elaborate his reasons to the WG for 
> including his draft within our charter, once his draft has been 
> accepted as an I-D.  Please give his note and his draft careful 
> consideration.


--

Will Price, Director of Engineering
PGP Security, Inc.
a division of Network Associates, Inc.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f78HnTH24610 for ietf-openpgp-bks; Wed, 8 Aug 2001 10:49:29 -0700 (PDT)
Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.65.64]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f78HnRN24606 for <[e-mail]>; Wed, 8 Aug 2001 10:49:27 -0700 (PDT)
Received: from [217.33.140.52] (vpnap-g1-012072.qualcomm.com [10.13.12.72]) by mage.qualcomm.com (8.11.3/8.11.3/1.0) with ESMTP id f78HnQT23803; Wed, 8 Aug 2001 10:49:27 -0700 (PDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100101b79728abcbde@[62.188.15.244]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-Mailer: eudora51-ffc10713011434
X-PGP-RSA-Fingerprint: EA53 01A6 C076 F9C2  09E8 9480 645A 8857
X-PGP-DH-Fingerprint: 4F5E 56C9 BD4D 0227 331F 6AEE 9590 24F9 6FD7 04F8
Date: Wed, 8 Aug 2001 18:49:07 +0100
To: OpenPGP mailing list <[e-mail]>
From: John  W Noerenberg II <[e-mail]>
Subject: Re: Draft openPGP ECC formats
Cc: "Dominikus Scherkl" <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

I've requested Dominikus edit his draft to conform to IETF 
guidelines, and resubmit it as a personal draft.  Currently,  further 
specification of ECC is not part of our charter, although it might be 
necessary in order for elliptic curves to be useful within OpenPGP.

Once his draft has been accepted as I-D, I would like your opinions 
on whether is should be included as a WG item.  Are implementers 
utilizing ECC in their implementations?

I've asked Dominikus to elaborate his reasons to the WG for including 
his draft within our charter, once his draft has been accepted as an 
I-D.  Please give his note and his draft careful consideration.

Thanks!
-- 

john noerenberg
[e-mail]
   --------------------------------------------------------------------------
   Peace of mind isn't at all superficial, really.  It's the whole thing.
   That which produces it is good maintenance; that which disturbs it
   is poor maintenance.
   -- Zen and the Art of Motorcycle Maintenance, Robert M. Pirsig, 1974
   --------------------------------------------------------------------------


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f78Clvs13430 for ietf-openpgp-bks; Wed, 8 Aug 2001 05:47:57 -0700 (PDT)
Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.65.64]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f78ClqN13424 for <[e-mail]>; Wed, 8 Aug 2001 05:47:56 -0700 (PDT)
Received: from [62.188.15.244] (vpnap-g1-012016.qualcomm.com [10.13.12.16]) by mage.qualcomm.com (8.11.3/8.11.3/1.0) with ESMTP id f78ClbT16617; Wed, 8 Aug 2001 05:47:38 -0700 (PDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100103b796e505fde9@[62.188.15.244]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-Mailer: eudora51-ffc10713011434
X-PGP-RSA-Fingerprint: EA53 01A6 C076 F9C2  09E8 9480 645A 8857
X-PGP-DH-Fingerprint: 4F5E 56C9 BD4D 0227 331F 6AEE 9590 24F9 6FD7 04F8
Date: Wed, 8 Aug 2001 13:47:11 +0100
To: "Dominikus Scherkl" <[e-mail]>
From: John  W Noerenberg II <[e-mail]>
Subject: Re: Draft openPGP ECC formats
Cc: <[e-mail]>, "openPGP e-Mail (E-Mail)" <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

At 3:17 PM +0200 8/7/01, Dominikus Scherkl wrote:
>We consider a new document (attached) about how to store elliptic
>curve cipher keys and signatures in openPGP messages and how to
>encrypt/decrypt with ECC vs. sign and verify with ECDSA.
>
>You can find it also under
>http://download.biodata.com/documents/draft-ietf-openpgp-ecc-formats.txt

Please submit this as a personal draft.  This is not a working group 
item at present.
-- 

john noerenberg
[e-mail]
   --------------------------------------------------------------------------
   Peace of mind isn't at all superficial, really.  It's the whole thing.
   That which produces it is good maintenance; that which disturbs it
   is poor maintenance.
   -- Zen and the Art of Motorcycle Maintenance, Robert M. Pirsig, 1974
   --------------------------------------------------------------------------


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f77Itva07548 for ietf-openpgp-bks; Tue, 7 Aug 2001 11:55:57 -0700 (PDT)
Received: from kasiski.gnupg.de (porta.u64.de [194.77.88.106]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f77ItsN07544 for <[e-mail]>; Tue, 7 Aug 2001 11:55:54 -0700 (PDT)
Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.22 #1 (Debian)) id 15UCpe-0002eN-00; Tue, 07 Aug 2001 21:48:02 +0200
Received: from wk by alberti.gnupg.de with local (Exim 3.22 #1 (Debian)) id 15UC3E-0002Ub-00; Tue, 07 Aug 2001 20:58:00 +0200
To: John W Noerenberg II <[e-mail]>
Cc: OpenPGP mailing list <[e-mail]>
Subject: Re: interop testing
References: <p05100101b7949ae9540e@[217.33.140.52]>
From: Werner Koch <[e-mail]>
Organisation: g10 Code GmbH
X-PGP-KeyID: 621CC013
X-Request-PGP: finger:[e-mail]
Date: 07 Aug 2001 20:57:57 +0200
In-Reply-To: <p05100101b7949ae9540e@[217.33.140.52]> (John  W Noerenberg II's message of "Tue, 7 Aug 2001 12:34:48 +0100")
Message-ID: <[e-mail]>
Lines: 19
User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Tue, 7 Aug 2001 12:34:48 +0100, John W Noerenberg said:

> If you have particular thoughts about interop testing, please don't
> hesitate to post them to the list.  If you are in London, and would
> like to discuss this in person, please let me know!

I have no particular thoughts.  Beeing able to attend on IRC is
hopefully sufficient.  The important thing is that we have to make
this happen and advance to draft status asap.

The last draft has expired, so we should release a new one.  Jon?


  Werner

-- 
Werner Koch        Omnis enim res, quae dando non deficit, dum habetur
g10 Code GmbH      et non datur, nondum habetur, quomodo habenda est.
Privacy Solutions                                        -- Augustinus



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f77DICa02382 for ietf-openpgp-bks; Tue, 7 Aug 2001 06:18:12 -0700 (PDT)
Received: from mail1.biodata.com ([62.159.113.2]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f77DIAN02376 for <[e-mail]>; Tue, 7 Aug 2001 06:18:10 -0700 (PDT)
Received: from fra1d001.biodata.org ([10.10.1.51]) by mail1.biodata.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 7 Aug 2001 15:17:54 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C11F43.5DDB79E8"
Subject: Draft openPGP ECC formats
Date: Tue, 7 Aug 2001 15:17:54 +0200
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Draft openPGP ECC formats
Thread-Index: AcEfQ2FXwiLQs5HASb29cbyk1ijYzw==
From: "Dominikus Scherkl" <[e-mail]>
To: <[e-mail]>
Cc: "openPGP e-Mail (E-Mail)" <[e-mail]>
X-OriginalArrivalTime: 07 Aug 2001 13:17:54.0323 (UTC) FILETIME=[5DFD3630:01C11F43]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C11F43.5DDB79E8
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello.

We consider a new document (attached) about how to store elliptic
curve cipher keys and signatures in openPGP messages and how to
encrypt/decrypt with ECC vs. sign and verify with ECDSA.

You can find it also under
http://download.biodata.com/documents/draft-ietf-openpgp-ecc-formats.txt

Best Regards.
--=20
Dominikus Scherkl
Biodata Application Security AG
mail: [e-mail]

------_=_NextPart_001_01C11F43.5DDB79E8
Content-Type: text/plain;
	name="draft-ietf-openpgp-ecc-formats.txt"
Content-Transfer-Encoding: base64
Content-Description: draft-ietf-openpgp-ecc-formats.txt
Content-Disposition: attachment;
	filename="draft-ietf-openpgp-ecc-formats.txt"

DQpOZXR3b3JrIFdvcmtpbmcgR3JvdXAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIEQuIFNjaGVya2wNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAg
ICAgQmlvZGF0YSBBcHBsaWNhdGlvbiBTZWN1cml0eSBBRw0KRXhwaXJlcyBGZWJydWFyeSAyMDAy
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDAxDQpVcGRh
dGVzOiBSRkMgMjQ0MA0KDQogICAgICAgICAgICAgICBPcGVuUEdQIEVsbGlwdGljIEN1cnZlIEFs
Z29yaXRobSBGb3JtYXRzDQoNClN0YXR1cyBvZiB0aGlzIE1lbW8NCg0KICAgVGhpcyBkb2N1bWVu
dCBpcyBhbiBJbnRlcm5ldC1EcmFmdC4gSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nDQogICBk
b2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nIFRhc2sgRm9yY2UgKElFVEYpLCBp
dHMgYXJlYXMsDQogICBhbmQgaXRzIHdvcmtpbmcgZ3JvdXBzLiAgTm90ZSB0aGF0IG90aGVyIGdy
b3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlDQogICB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5l
dC1EcmFmdHMuDQoNCiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlk
IGZvciBhIG1heGltdW0gb2Ygc2l4DQogICBtb250aHMgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBs
YWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cw0KICAgYXQgYW55IHRpbWUuIEl0
IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2UNCiAg
IG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNz
Ii4NCg0KICAgVG8gdmlldyB0aGUgZW50aXJlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC1EcmFm
dHMsIHBsZWFzZSBjaGVjayB0aGUNCiAgICIxaWQtYWJzdHJhY3RzLnR4dCIgbGlzdGluZyBjb250
YWluZWQgaW4gdGhlIEludGVybmV0LURyYWZ0cyBTaGFkb3cNCiAgIERpcmVjdG9yaWVzIG9uIGZ0
cC5pcy5jby56YSAoQWZyaWNhKSwgZnRwLm5vcmR1Lm5ldCAoTm9ydGhlcm4NCiAgIEV1cm9wZSks
IGZ0cC5uaXMuZ2Fyci5pdCAoU291dGhlcm4gRXVyb3BlKSwgbXVubmFyaS5vei5hdSAoUGFjaWZp
Yw0KICAgUmltKSwgZnRwLmlldGYub3JnIChVUyBFYXN0IENvYXN0KSwgb3IgZnRwLmlzaS5lZHUg
KFVTIFdlc3QgQ29hc3QpLg0KDQpBYnN0cmFjdA0KDQogICBUaGlzIGRvY3VtZW50IGRlZmluZXMg
d2hpY2ggYWxnb3JpdGhtIHNwZWNpZmljIHBhcmFtZXRlcnMgYXJlIG5lZWRlZA0KICAgZm9yIGVs
bGlwdGljIGN1cnZlIGNpcGhlciAoRUNDKSBhbmQgZWxsaXB0aWMgY3VydmUgZGlnaXRhbCBzaWdu
YXR1cmUNCiAgIGFsZ29yaXRobSAoRUNEU0EpIGFuZCBob3cgdGhleSBoYXZlIHRvIGJlIHN0b3Jl
ZCBpbiBvcGVuUEdQIHBhY2tldHMuDQogICBUaGVyZWZvcmUgaXQgaXMgYW4gc3VwcGxlbWVudCB0
byB0aGUgb3BlblBHUCBtZXNzYWdlIGZvcm1hdCBbMV0uDQogICBJdCBhbHNvIGRlZmluZXMgd2hp
Y2ggY2hlY2tzIGFyZSBuZWVkZWQgdG8gdmFsaWRhdGUgRUNDIGFuZCBFQ0RTQQ0KICAga2V5cyBh
bmQgd2hpY2ggInRvcC1sZXZlbCIgb3BlcmF0aW9ucyBtdXN0IGJlIHBlcmZvcm1lZCBmb3INCiAg
IGVuY3J5cHRpb24vZGVjcnlwdGlvbiBhbmQgc2lnbmluZy9zaWduYXR1cmUgdmVyaWZpY2F0aW9u
LiBCdXQgaXQNCiAgIGdpdmVzIG5vIGFkdmljZXMgaG93IHRvIGltcGxlbWVudCB0aGVzZSBjaGVj
a3MgYW5kIG9wZXJhdGlvbnMsIG5vcg0KICAgdGhlIHVuZGVybHlpbmcgbWF0aGVtYXRpY3MuIFRv
IGRvIHRoaXMsIGxvb2sgZm9yIGV4YW1wbGUgYXQgSUVFRQ0KICAgUDEzNjMgWzJdLg0KDQoNCg0K
DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KU2NoZXJrbCAgICAgICAgICAgICAgICAgICAg
IFN0YW5kYXJkcyBUcmFjayAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDFdDQoMDQpJbnRlcm5l
dC1EcmFmdCAgICAgICAgICAgIE9wZW5QR1AgRUNDIEZvcm1hdHMgICAgICAgICAgICAgICAgQXVn
dXN0IDIwMDENCg0KVGFibGUgb2YgQ29udGVudHMNCg0KICAgICAgICAgU3RhdHVzIG9mIHRoaXMg
TWVtbyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMQ0KICAgICAgICAg
QWJzdHJhY3QgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgMQ0KICAgICAgICAgVGFibGUgb2YgQ29udGVudHMgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgMg0KICAgMS4gICAgSW50cm9kdWN0aW9uICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMw0KICAgMS4xLiAgVGVybXMgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMw0KICAgMi4g
ICAgRWxsaXB0aWMgQ3VydmUgRG9tYWluICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgMw0KICAgMy4gICAgQmFzaXMgUmVwcmVzZW50YXRpb25zICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgNA0KICAgMy4xLiAgUHJpbWUgRmllbGRzICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgNQ0KICAgMy4yLiAgUG9seW5vbWlh
bCBCYXNlcyBvZiBDaGFyLTIgRmllbGRzICAgICAgICAgICAgICAgICAgICAgICAgICAgNQ0KICAg
My4zLiAgR2F1c3NpYW4gTm9ybWFsIEJhc2VzIG9mIENoYXItMiBGaWVsZHMgICAgICAgICAgICAg
ICAgICAgICAgNQ0KICAgMy40LiAgT2RkIEV4dGVuc2lvbiBGaWVsZHMgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgNg0KICAgNC4gICAgUGFyYW1ldGVyIEZvcm1hdCAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgNg0KICAgNC4xLiAgWmVybyBN
UEkgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgNg0K
ICAgNC4yLiAgTmFtZXMgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgNg0KICAgNC4zLiAgQ3VydmUgUG9pbnRzICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgNg0KICAgNC40LiAgRmllbGQgRGVzY3JpcHRvciAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgNw0KICAgNS4gICAgQWxn
b3JpdGhtIFNwZWNpZmljIEZpZWxkcyBmb3IgRUNDIGFuZCBFQ0RTQSBQdWJsaWMgS2V5cyAgICAg
OA0KICAgNi4gICAgQWxnb3JpdGhtIFNwZWNpZmljIEZpZWxkcyBmb3IgRUNDIGFuZCBFQ0RTQSBT
ZWNyZXQgS2V5cyAgICAgOA0KICAgNy4gICAgRUNDICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgOA0KICAgNy4xLiAgRUNDIEVuY3J5cHRpb24g
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgOA0KICAgNy4yLiAg
RUNDIERlY3J5cHRpb24gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgOA0KICAgNy4zLiAgQWxnb3JpdGhtIFNwZWNpZmljIEZpZWxkcyBmb3IgRUNDIEVuY3J5cHRp
b24gICAgICAgICAgICAgICAgOQ0KICAgOC4gICAgRUNEU0EgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgOQ0KICAgOC4xLiAgRUNEU0EgU2lnbmF0
dXJlIEdlbmVyYXRpb24gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgOQ0KICAgOC4y
LiAgRUNEU0EgU2lnbmF0dXJlIFZlcmlmaWNhdGlvbiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgOQ0KICAgOC4zLiAgQWxnb3JpdGhtIFNwZWNpZmljIEZpZWxkcyBmb3IgRUNEU0EgU2ln
bmF0dXJlcyAgICAgICAgICAgICAgOQ0KICAgOS4gICAgTmFtZWQgQ3VydmVzICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgOQ0KICAgOS4xLiAgQ3VydmVzIG92
ZXIgQ2hhci0yIEZpZWxkcyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgOQ0KICAg
OS4yLiAgQ3VydmVzIG92ZXIgUHJpbWUgRmllbGRzICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAxNQ0KICAgOS4zLiAgQ3VydmVzIG92ZXIgT2RkIEV4dGVuc2lvbiBGaWVsZHMgICAg
ICAgICAgICAgICAgICAgICAgICAgICAxOA0KICAgOS40LiAgQWRkaW5nIE93biBOYW1lZCBDdXJ2
ZXMgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAxOQ0KICAgOS41LiAgUmV2b2Nl
ZCBDdXJ2ZXMgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAxOQ0K
ICAgMTAuICAgU2VjdXRpdHkgQ29uc2lkZXJhdGlvbnMgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAxOQ0KICAgMTEuICAgUmVmZXJlbmNlcyAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAyMA0KICAgMTIuICAgQXV0aG9ycyAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAyMA0KDQoNCg0KDQoNCg0K
DQoNCg0KDQoNCg0KDQoNCg0KDQpTY2hlcmtsICAgICAgICAgICAgICAgICAgICAgU3RhbmRhcmRz
IFRyYWNrICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgMl0NCgwNCkludGVybmV0LURyYWZ0ICAg
ICAgICAgICAgT3BlblBHUCBFQ0MgRm9ybWF0cyAgICAgICAgICAgICAgICBBdWd1c3QgMjAwMQ0K
DQoxLiBJbnRyb2R1Y3Rpb24NCg0KICAgVGhlIG9wZW5QR1AgbWVzc2FnZSBmb3JtYXQgWzFdIHJl
c2VydmVkIElEcyBmb3IgZWxsaXB0aWMgY3VydmUNCiAgIGFsZ29yaXRobXMuIFRoaXMgZG9jdW1l
bnQgbm93IGRlZmluZXMgdGhlaXIgc3RvcmFnZSBmb3JtYXQuDQogICANCiAgIEVsbGlwdGljIGN1
cnZlcyBjYW4gYmUgZGVmaW5lZCBvdmVyIGFueSBudW1iZXJmaWVsZCAoZmluaXRlIG9yDQogICBp
bmZpbml0ZSksIGFuZCB0aGUgbW9yZSBjb21wbGljYXRlZCB0aGUgZmllbGQgaXMsIHRoZSBtb3Jl
IGRpZmZlcmVudA0KICAgImhhbmR5IiBiYXNpcyByZXByZXNlbnRhdGlvbnMgb2YgaXQgY2FuIGJl
IGRlZmluZWQsIGZvciBjYXNlcyBvZg0KICAgc3BlY2lhbCBpbnRlcmVzdC4NCiAgIFRoaXMgZHJh
ZnQgZGVmaW5lcyByZXByZXNlbnRhdGlvbnMgZm9yIGFsbCBmaW5pdGUgZmllbGRzIGFuZCBzb21l
DQogICBzcGVjaWFsIGNhc2VzIHRoYXQgcHJvdmlkZSBmYXN0IGFyaXRobWV0aWMuDQoNCiAgIE9u
IGVsbGlwdGljIGN1cnZlcyBhIHNjYWxhci1tdWx0aXBsaWNhdGlvbiBjYW4gYmUgZGVmaW5lZCAo
dGhhdCBpczoNCiAgIG11bHRpcGxlcyBvZiBwb2ludHMpLCBhbmQgaXQncyBiZWhhdmlvciBvdmVy
IGZpbml0ZSBmaWVsZHMgaXMNCiAgIGVycmF0aWMgZW5vdWdoIHRvIHRha2UgaXQgYXMgcHVibGlj
IGtleSBlbmNyeXB0aW9uOiB5b3UgY2FuIG11bHRpcGx5DQogICBwb2ludHMsIGJ1dCB5b3UgY2Fu
J3Qgc2F5IHRoZSBtdWx0aXBsZSBvZiB3aGljaCBwb2ludCB5b3UgZ290DQogICB3aXRob3V0IGNo
ZWNraW5nIGVhY2ggcG9pbnQgKHRoaXMgaXMgY2FsbGVkIHRoZSAiZWxsaXB0aWMgY3VydmUNCiAg
IGRpc2NyZXRlIGxvZ2FyaXRobSBwcm9ibGVtIiBvciBFQy9ETC1wcm9ibGVtKS4NCg0KICAgVGhl
IGFkdmVudGFnZSBvZiB0aGlzIG11bHRpcGxpY2F0aW9uIGlzLCB0aGF0IGl0J3MgbXVjaCBtb3Jl
IGVycmF0aWMNCiAgIHRoYW4gUlNBIGV4cG9uZW50aWF0aW9uLCB3aGljaCBhbGxvd2VzIHRvIHRh
a2Ugc2hvcnRlciBrZXlzIHdpdGhvdXQNCiAgIGxvc3Mgb2Ygc2VjdXJpdHkuIEFub3RoZXIgYWR2
ZW50YWdlIGlzIHRoZSBoaWdoIHBlcmZvcm1hbmNlIGlmDQogICBzcGVjaWFsIGZpZWxkcyBhcmUg
dXNlZC4NCiAgIEEga2luZCBvZiBkaXNhZHZlbnRhZ2UgaXMgdGhlIG11Y2ggbW9yZSBjb21wbGV4
IG1hdGhlbWF0aWNzIG5lZWRlZCwNCiAgIGVzcGVjaWFseSBmb3IgZ2VuZXJhdGluZyBFQyBkb21h
aW5zLiBBbHNvIHRoZSBoaWdoIHBlcmZvcm1hbmNlIGlzDQogICBsb3N0IGlmIGFuIGltcGxlbWVu
dGF0aW9uIGlzIG5vdCBvcHRpbWl6ZWQgZm9yIHRoZSBmaWVsZCB1c2VkIGJ5IGENCiAgIGNvbW11
bmljYXRpb24gcGFydG5lci4NCg0KMS4xLiBUZXJtcw0KDQogICBUaGlzIGRvY3VtZW50IHVzZXMg
dGhlIHRlcm1zICJNVVNUIiwgIlNIT1VMRCIgYW5kICJNQVkiIGFzIGRlZmluZWQgaW4NCiAgIFJG
QyAyMTE5LCBhbG9uZyB3aXRoIHRoZSBuZWdhdGVkIGZvcm1zIG9mIHRob3NlIHRlcm1zLg0KDQog
ICBJbiB0aGUgd2hvbGUgZG9jdW1lbnQgdGhlIHN5bWJvbCBeIGlzIHVzZWQgYXMgdGhlIGV4cG9u
ZW50aWF0aW9uDQogICBvcGVyYXRvci4gRS5nLiAyXjctMSBtZWFucyAxMjcgKG9uZSBiZWxvdyB0
aGUgc2V2ZW50aCBwb3dlciBvZiB0d28pLg0KDQoyLiBFbGxpcHRpYyBDdXJ2ZSBEb21haW4NCiAg
IA0KICAgVGhlcmUgaXMgYSBzZXQgb2YgcGFyYW1ldGVycyB0aGF0IG1heSBiZSBjb21tb24gbm90
IG9ubHkgdG8gb25lIGJ1dA0KICAgZm9yIG1hbnkgKG9yIGV2ZW4gYWxsKSBrZXlzLCB3aGljaCB3
ZSBjYWxsIHRoZSBFQyBkb21haW4uDQogICBJdCBjb25zaXN0cyBvZg0KICAgLSBzb21lIGZpbml0
ZSBmaWVsZCBGIChkZWZpbmVkIGJ5IGl0J3Mgb3JkZXIgcF5tIGFuZCBpdCdzIGFyaXRobWV0aWMN
CiAgICAgZS5nLiByZWR1Y3Rpb24gcG9seW5vbWlhbCBvciBtdWx0aXBsaWNhdGlvbiB0eXBlIC0g
c2VlIGJlbG93KSwNCiAgIC0gYW4gZWxsaXB0aWMgY3VydmUgRSBkZWZpbmVkIGJ5IHR3byBlbGVt
ZW50cyBhLCBiIG9mIEYsDQogICAtIGEgcG9pbnQgRyBvbiBFIGRlZmluZWQgYnkgaXQncyBjb29y
ZGluYXRlcyB4LCB5IGVsZW1lbnRzIG9mIEYsDQogICAtIGEgcHJpbWUgbnVtYmVyIG4gd2l0aCBu
KkcgPSAwICh0aGUgb3JkZXIgb2YgRykgYW5kDQogICAtIGEgY29mYWN0b3IgaCB3aXRoIG9ubHkg
c21hbGwgcHJpbWUgZmFjdG9ycyBhbmQgaCpuIGlzIHRoZSBudW1iZXINCiAgICAgb2YgcG9pbnRz
IG9uIEUgKHRoZSBvcmRlciBvZiBFKS4NCiAgICAgDQogICBBbGwgbWVudGlvbmVkIGNvbmRpdGlv
bnMgTVVTVCBiZSB0ZXN0ZWQsIHRoYXQgaXM6DQogICAtIHRoZSBncm91bmRmaWVsZCBvcmRlciBw
IGlzIHByaW1lIGFuZCB0aGUgcG9seW5vbWlhbCBpcyBpcnJlZHVjaWJsZSwNCiAgIC0gYSBhbmQg
YiBkZWZpbmluZyBhIGN1cnZlIG92ZXIgRiwNCg0KU2NoZXJrbCAgICAgICAgICAgICAgICAgICAg
IFN0YW5kYXJkcyBUcmFjayAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDNdDQoMDQpJbnRlcm5l
dC1EcmFmdCAgICAgICAgICAgIE9wZW5QR1AgRUNDIEZvcm1hdHMgICAgICAgICAgICAgICAgQXVn
dXN0IDIwMDENCg0KICAgLSBHIGxpZXMgb24gdGhlIGN1cnZlIGFuZCBpcyBub3QgMCAodGhlIHBv
aW50IGF0IGluZmluaXR5KSwNCiAgIC0gbiBpcyBwcmltZSBhbmQgbipHIGlzIDAgKHRoYXQgdGFr
ZXMgdGltZSEpIGFuZA0KICAgLSBuKmggaXMgdGhlIGN1cnZlIG9yZGVyLg0KICAgDQogICBBZGRp
dGlvbmFsIHRoZXJlIGFyZSBzb21lIHNlY3VyaXR5IGNvbmRpdGlvbnMgdGhlIGRvbWFpbiBNVVNU
DQogICBzYXRpc2Z5Og0KDQogICAtIFRoZSBjdXJ2ZSBvcmRlciBNVVNUIE5PVCBlcXVhbCB0aGUg
ZmllbGQgb3JkZXIsDQogICAtIFRoZSBleHBvbmVudCBtIChleHRlbnNpb24gZGVncmVlKSBTSE9V
TEQgYmUgcHJpbWUgWzddIChvciBtPTEpLA0KICAgLSB0aGUgcG9pbnQgb3JkZXIgTVVTVCBiZSBn
cmVhdGVyIHRoYW4gMl4xNjAgYW5kIGl0J3Mgc3F1YXJlIE1VU1QNCiAgICAgYmUgZ3JlYXRlciB0
aGFuIGZvdXIgdGltZXMgdGhlIGZpZWxkIG9yZGVyIChpdCdzIGJpdGxlbiBtdXN0IGJlDQogICAg
IGF0IGxlYXN0IHR3byBiaXQgbG9uZ2VyIHRoYW4gaGFsZiB0aGUgZmllbGQgYml0bGVuKSwNCiAg
IC0gVGhlIE1PViBjb25kaXRpb24gWzNdIE1VU1QgYmUgdHJ1ZSAodGhhdCBpczogc21hbGwgcG93
ZXJzIG9mIHRoZQ0KICAgICBmaWVsZCBvcmRlciBNVVNUIE5PVCBiZSBlcXVpdmFsZW50IHRvIDEg
bW9kdWxvIHRoZSBwb2ludCBvcmRlciksDQogICAtIEZ1cnRoZXIgY29uZGl0aW9ucyBtYXkgYmUg
YWRkZWQgaGVyZSBpZiBtb3JlIHdlYWsgY3VydmVzIGFyZQ0KICAgICBkaXNjb3ZlcmVkLg0KICAg
ICANCiAgIEFuIEVDIGRvbWFpbiB0aGF0IGlzIHZlcmlmaWVkIGNhbiBiZSBnaXZlbiBhIG5hbWUu
IEEgbmFtZWQgY3VydmUgaXMNCiAgIHNpbXBseSB0aGUgRUMgZG9tYWluIGFzc2lnbmVkIHRvIHRo
YXQgbmFtZS4gSW1wbGVtZW50YXRpb25zIFNIT1VMRA0KICAgcHJvdmlkZSB0aGUgbmFtZWQgY3Vy
dmVzIG1lbnRpb25lZCBpbiBzZWN0aW9uIDcuDQoNCjMuIEJhc2lzIFJlcHJlc2VudGF0aW9ucw0K
DQogICBBbnkgZmluaXRlIGZpZWxkIGNhbiBiZSByZXByZXNlbnRlZCBieSB0aHJlZSB2YWx1ZXM6
IGEgcHJpbWUgcCwNCiAgIGFuIGV4cG9uZW50IG0gKGNhbGxlZCB0aGUgZXh0ZW5zaW9uIGRlZ3Jl
ZSkgYW5kIGEgbW9uaWMgaXJyZWR1Y2libGUNCiAgIHBvbHlub21pYWwgZiBvZiBkZWdyZWUgbS4g
QnV0IHNwZWNpYWwgcmVwcmVzZW50YXRpb25zIGFsbG93IHVzIHRvDQogICBzaHJpbmsgdGhlIHN0
b3JhZ2UgbmVlZDoNCiAgIEZvciBjaGFyLTIgZmllbGRzIEYoMl5tKSBwPTIsIHNvIHdlIGNhbiBv
bW1pdCBpdC4gRm9yIHByaW1lIGZpZWxkcw0KICAgRihwKSBtPTEgYW5kIHdlIG5lZWQgbm8gcG9s
eW5vbWlhbCAodXNpbmcgeCBhcyByZWR1Y3Rpb24gcG9seW5vbWlhbA0KICAgaXMgd2hhdCB3ZSBj
YWxsIHRoZSBvcmRpbmFyeSAibW9kdWxvIGFyaXRobWV0aWMiIC0gdXNpbmcgeCsxIHdvdWxkDQog
ICBsZWFkIHRvIGEgZGlmZmVyZW50IGFyaXRobWV0aWMpLiBBbHNvIHRoZXJlIGFyZSBtb3JlIG5v
dCBhcyBvYnZpb3VzDQogICBzcGVjaWFsIGNhc2VzOg0KICAgDQogICAtIElmIHAgaXMgbmVhciBz
b21lIHR3b3Bvd2VyIGl0IGNhbiBiZSBzdG9yZWQgYXMgMl5yICsgYyB3aXRoIHNtYWxsDQogICAg
IGludGVnZXJzIHIgYW5kIGMgKGMgY2FuIGJlIG5lZ2F0aXZlISEpLg0KICAgLSBGb3IgcD0yIGV4
aXN0cyBpcnJlZHVjaWJsZSBwb2x5bm9taWFscyB3aXRoIG9ubHkgdGhyZWUgKHRyaW5vbWlhbA0K
ICAgICBiYXNlcyAtIG5vdCBhbHdheXMpIG9yIGZpdmUgc2V0IGJpdHMgKHBlbnRhbm9taWFsIGJh
c2VzKS4NCiAgIC0gRm9yIHNvbWUgMl5tIHRoZSBhbGwtb25lIHBvbHlub21pYWwgaXMgaXJyZWR1
Y2liZSAoY2lyY3VsYXIgZHVhbA0KICAgICBiYXNpcykuDQogICAtIEZvciBtYW55IHBebSBleGlz
dHMgaXJyZWR1Y2libGUgYmlub21pYWxzIGYodCkgPSB0Xm0gLSB3IHdpdGggc21hbGwNCiAgICAg
dyAob3B0aW1hbCBleHRlbnNpb24gZmllbGRzKS4NCiAgIA0KICAgQWxsIG9mIHRoZXNlIHJlcHJl
c2VudGF0aW9ucyBub3Qgb25seSByZXF1aXJlIGxlc3Mgc3BhY2UgdG8gc3RvcmUgYnV0DQogICBt
YWlubHkgcHJvdmlkZSAobXVjaCkgZmFzdGVyIGFyaXRobWV0aWMgYXMgdGhlIGdlbmVyYWwgY2Fz
ZS4NCg0KICAgRm9yIEYoMl5tKSBhbHNvIG9uZSBjb21wbGV0ZWx5IGRpZmZlcmVudCBhcHByb2Fj
aCBpcyBjb21tb246IFRha2UgbQ0KICAgYXMgdGhlIGRpbWVuc2lvbiBvZiBhIHZlY3RvciBzcGFj
ZSwgc28gdGhhdCBlYWNoIGVsZW1lbnQgY2FuIGJlDQogICByZXByZXNlbnRlZCBhcyBsaW5lYXIg
Y29tYmluYXRpb24gb2YgbSAiaW5kZXBlbmRlbnQiIGJhc2lzIGVsZW1lbnRzLg0KICAgSWYgZWFj
aCBiYXNpcyBlbGVtZW50IGlzIHRoZSBzcXVhcmUgb2Ygc29tZSBvdGhlciBiYXNpcyBlbGVtZW50
IHRoaXMNCiAgIGlzIGNhbGxlZCBhICJub3JtYWwiIGJhc2lzLiBJZiBhZGRpdGlvbmFseSB0aGlz
IGJhc2lzIHByb3ZpZGVzIGENCiAgIHNwZWNpYWwgbXVsdGlwbGljYXRpb24gZm9ybXVsYSBvZiB0
eXBlIFQsIGl0IGlzIGNhbGxlZCBhICJnYXVzc2lhbiINCiAgIG5vcm1hbCBiYXNpcy4gVGhpcyBp
cyBzdXBwb3J0ZWQsIGJlY2F1c2UgaXQgaXMgdmVyeSBmYXN0IGluIGhhcmR3YXJlDQoNClNjaGVy
a2wgICAgICAgICAgICAgICAgICAgICBTdGFuZGFyZHMgVHJhY2sgICAgICAgICAgICAgICAgICAg
ICBbUGFnZSA0XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICBPcGVuUEdQIEVDQyBGb3Jt
YXRzICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDAxDQoNCiAgIGFuZCB0aGVyZWZvcmUgbWFueSBp
bXBsZW1lbnRhdGlvbnMgZXNwZWNpYWx5IG9uIHNtYXJ0Y2FyZHMgdXNlIHRoaXMNCiAgIHJlcHJl
c2VudGF0aW9uLiAoVGhlc2UgYmFzZXMgcmVseSBhbHNvIG9uIGFuIGlycmVkdWNpYmxlIHBvbHlu
b21pYWwNCiAgIGYsIGJ1dCBpdCBpcyBub3QgbmVlZGVkIGZvciBtb3N0IGFyaXRobWV0aWMgYW5k
IGZvciBUPjIgaXQgaXMNCiAgIGNvbXBsaWNhdGVkIHRvIGNhbGN1bGF0ZSBmKS4NCiAgIA0KICAg
SW4gdGhlIGZvbGxvd2luZyB0ZXh0IGFsbCBwYXJhbWV0ZXJzIGFyZSBzaG9ydGVuZWQgYnkgdGhl
IHNhbWUNCiAgIGxldHRlcnMgYXMgbWVudGlvbmVkIGFib3ZlLg0KDQozLjEuIFByaW1lIEZpZWxk
cw0KDQogICBObyBwYXJhbWV0ZXJzIGV4Y2VwdCB0aGUgcHJpbWUgaXRzZWxmIGFyZSByZXF1aXJl
ZCBmb3IgcHJpbWUgZmllbGRzLg0KICAgU3RhbmRhcmQgbW9kdWxvIGFyaXRobWV0aWMgaXMgdXNl
ZC4NCiAgIA0KICAgSWYgcCBpcyBuZWFyIHNvbWUgdHdvcG93ZXIgcCA9IDJeciArIGMsIHRoZSBp
bnRlZ2VycyByIGFuZCBjIGFyZQ0KICAgc3RvcmVkIGluc3RlYWQgb2YgcCAocHNldWRvIG1lcnNl
bm5lIHByaW1lIGZpZWxkKS4gVGhlIHNpZ24gb2YgYyBpcw0KICAgaW5kaWNhdGVkIGJ5IGRpZmZl
cmVudCBmaWVsZCBkZXNjcmlwdG9ycyAoc2VlIHNlY3Rpb24gNC40KS4gVGhpcyBpcw0KICAgbmVz
c2Vzc2FyeSBiZWNhdXNlIHRoZSBNUEkgZm9ybWF0IGNhbid0IHN0b3JlIG5lZ2F0aXZlIG51bWJl
cnMuDQoNCjMuMi4gUG9seW5vbWlhbCBCYXNlcyBvZiBDaGFyLTIgRmllbGRzDQoNCiAgIEZvciBh
bnkgcmVwcmVzZW50YXRpb24gb2YgRigyXm0pIHRoZSBwYXJhbWV0ZXIgbSBpcyBuZWVkZWQuIEVh
Y2gNCiAgIGlycmVkdWNpYmxlIHBvbHlub21pYWwgaGFzIHRoZSBoaWdoZXN0IGFuZCBsb3dlc3Qg
Yml0IHNldCBhbmQgdGhlDQogICBudW1iZXIgb2Ygc2V0IGJpdHMgaXMgYWx3YXlzIG9kZC4NCg0K
ICAgVXNpbmcgdGhlIGFsbC1vbmUgcG9seW5vbWlhbCBpcyBjYWxsZWQgdGhlICJjaXJjdWxhciBk
dWFsIGJhc2lzIiBvcg0KICAgIkNEQiIuIEl0IHJlcXVpcmVzIG5vIGZ1cnRoZXIgcGFyYW1ldGVy
cy4NCg0KICAgVXNpbmcgYSB0cmlub21pYWwgaXMgY2FsbGVkICJ0cmlub21pYWwgYmFzaXMiIG9y
ICJUUEIiLiBXZSBuZWVkIHRvDQogICBrbm93IHRoZSBwb3NpdGlvbnMgb2YgdGhlIHRocmVlIGJp
dHMuIFRoYXQgYXJlIDAsIG0gYW5kIHNvbWUgb3RoZXINCiAgIGJpdCBrLiBUaGVyZWZvcmUgdGhl
IGJpdC1wb3NpdGlvbiBrIGlzIHJlcXVpcmVkIGFzIHBhcmFtZXRlci4NCg0KICAgVXNpbmcgYSBw
ZW50YW5vbWlhbCAoInBlbnRhbm9taWFsIGJhc2lzIiBvciAiUFBCIikgcmVxdWlyZXMgdGhyZWUN
CiAgIHBhcmFtZXRlcnMgazEsIGsyLCBrMy4NCg0KICAgVXNpbmcgYW4gYXJiaXRyYXJ5IGlycmVk
dWNpYmxlIHBvbHlub21pYWwgKCJwb2x5bm9taWFsIGJhc2lzIiBvcg0KICAgIlBCIikgcmVxdWly
ZXMgdGhhdCBjb21wbGV0ZSBwb2x5bm9taWFsIGYgYXMgcGFyYW1ldGVyICh0aGUgaGlnaGVzdA0K
ICAgY29lZmZpY2llbnQgdF5tIHdoaWNoIGlzIGFsd2F5cyAxIG1heSBiZSBvbW1pdGVkKS4NCiAg
IEltcGxlbWVudGF0aW9ucyBTSE9VTEQgYXZvaWQgYXJiaXRyYXJ5IHBvbHlub21pYWwgYmFzZXMu
DQoNCjMuMy4gR2F1c3NpYW4gTm9ybWFsIEJhc2VzIG9mIENoYXItMiBGaWVsZHMNCg0KICAgR2F1
c3NpYW4gYmFzZXMgYXJlIGNvbXBsZXRlbHkgZGVmaW5lZCBieSB0aGUgZXh0ZW5zaW9uIGRlZ3Jl
ZSBtIGFuZA0KICAgdGhlIHR5cGUgVCBvZiB0aGVpciBtdWx0aXBsaWNhdGlvbi4gQmFzZXMgd2l0
aCBUPTEgb3IgVD0yIGFyZSBjYWxsZWQNCiAgICJvcHRpbWFsIG5vcm1hbCBiYXNlcyIsIG9yICJ0
eXBlLUkgT05CIiBhbmQgInR5cGUtSUkgT05CIi4NCiAgIFRoZSBvcHRpbWFsIGNhc2VzIGFyZSBj
b2RlZCBpbiB0aGUgZmllbGQgZGVzY3JpcHRvciAoc2VlIHNlY3Rpb24NCiAgIDQuNCksIGZvciBU
PjIgdGhpcyB0eXBlIGlzIG5lZWRlZCBhcyBhZGRpdGlvbmFsIHBhcmFtZXRlci4NCiAgIA0KICAg
VGhpcyBzdGFuZGFyZCBkb2VzIG5vdCBzdXBwb3J0IGFyYml0cmFyeSAobm9uLWdhdXNzaWFuKSBu
b3JtYWwgYmFzZXMuDQogICBJbXBsZW1lbnRhdGlvbnMgU0hPVUxEIGF2b2lkIG5vbi1vcHRpbWFs
IG5vcm1hbCBiYXNlcy4NCg0KDQoNCg0KU2NoZXJrbCAgICAgICAgICAgICAgICAgICAgIFN0YW5k
YXJkcyBUcmFjayAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDVdDQoMDQpJbnRlcm5ldC1EcmFm
dCAgICAgICAgICAgIE9wZW5QR1AgRUNDIEZvcm1hdHMgICAgICAgICAgICAgICAgQXVndXN0IDIw
MDENCg0KMy40LiBPZGQgRXh0ZW5zaW9uIEZpZWxkcw0KDQogICBPZGQgZXh0ZW5zaW9uIGZpZWxk
cyBGKHBebSkgd2l0aCBwPjIgYW5kIG0+MSByZXF1aXJlcyB0aGUgcGFyYW1ldGVycw0KICAgcCwg
bSBhbmQgZi4gVGhlaXIgZWxlbWVudHMgYXJlIGJlc3QgcmVwcmVzZW50ZWQgYXMgcG9seW5vbWlh
bHMgb2YNCiAgIGRlZ3JlZSA8IG0gd2l0aCBjb2VmZmljaWVudHMgaW4gRihwKS4gSG93ZXZlciwg
dGhleSBhcmUgc3RvcmVkIGFzDQogICBpbnRlZ2VycyBpID0gYzAgKyBjMSpwICsgYzIqcF4yICsg
Li4uICsgYyhtLTEpKnBeKG0tMSkgKHAtYWRpYykuDQogICBUaGUgaGlnaGVzdCBjb2VmZmljaWVu
dCBvZiBmIGlzIGFsd2F5cyAxIGFuZCBtYXkgYmUgb21taXRlZC4gVGhhdCBpcw0KICAgdmVyeSBz
dG9yYWdlIGVmZmljaWVudCBpZiB0aGUgbmV4dCBmZXcgY29lZmZpY2llbnRzIGFyZSB6ZXJvLg0K
DQogICBJZiBwIGlzIG5lYXIgc29tZSB0d29wb3dlciBwID0gMl5yICsgYywgdGhlIGludGVnZXJz
IHIgYW5kIGMgYXJlDQogICBzdG9yZWQgaW5zdGVhZCBvZiBwICh0eXBlLUkgZXh0ZW5zaW9uIGZp
ZWxkKS4gSWYgYyBpcyAxIG9yIC0xLCBGIGlzDQogICBjYWxsZWQgYSB0eXBlLUkgIm9wdGltYWwg
ZXh0ZW5zaW9uIGZpZWxkIiBvciAiT0VGIi4gVGhlIHNpZ24gb2YgYyBpcw0KICAgaW5kaWNhdGVk
IGJ5IGRpZmZlcmVudCBmaWVsZCBkZXNjcmlwdG9ycyAoc2VlIHNlY3Rpb24gNC40KS4NCiAgIA0K
ICAgSWYgRihwXm0pIGhhcyBhbiBpcnJlZHVjaWJsZSBiaW5vbWlhbCBmKHQpID0gdF5tIC0gdywg
b25seSB3IGlzDQogICBzdG9yZWQgaW5zdGVhZCBvZiBmICh0eXBlLUlJIGV4dGVuc2lvbiBmaWVs
ZCkuIElmIHcgPSAyLCBGIGlzIGNhbGxlZA0KICAgYSB0eXBlLUlJICJvcHRpbWFsIGV4dGVuc2lv
biBmaWVsZCIgb3IgIk9FRiIuDQogICBBIGZpZWxkIGNhbiBiZSB0eXBlLUkgYW5kIHR5cGUtSUkg
b3B0aW1hbCBhdCB0aGUgc2FtZSB0aW1lLg0KDQo0LiBQYXJhbWV0ZXIgRm9ybWF0DQoNCiAgIFRo
ZSBhbGdvcml0aG0tc3BlY2lmaWMgZmllbGRzIGFsbCBvdWdodCB0byBiZSBNUEkncy4gQnV0IHNv
bWUgb2YNCiAgIHRoZW0gYXJlIGRhdGEgY29udGFpbmVycyBpbnN0ZWFkIG9mIG51bWJlcnMuIFRo
ZSBmb2xsb3dpbmcgc2VjdGlvbnMNCiAgIGRlZmluZXMgaG93IHRoZXkgbXVzdCBiZSBpbnRlcnBy
ZXRlZDoNCg0KNC4xLiBaZXJvIE1QSQ0KDQogICBTb21ldGltZXMgaXQgaXMgbmVjZXNzYXJ5IHRv
IHN0b3JlIHRoZSB2YWx1ZSAwLCB3aGljaCBtYXkgbGVnYWx5DQogICBvY2N1cmUgKFJGQyAyNDQw
IGFsbG93ZXMgdGhpcyBvbmx5IGltcGxpY2l0IFsxXSkuIFRoZSB2YWx1ZSAwIGlzDQogICBmb3Jt
ZWQgYnkgdGhlIHN0cmluZyBvZiBvY3RldHMgWzAwIDAwXS4gTm8gYWRkaXRpb25hbCB6ZXJvcyBt
YXkgYmUNCiAgIGluc2VydGVkLg0KICAgDQogICBSYXRpb25hbDogdGhlcmUgaXMgbm8gb3RoZXIg
d2F5IHRvIGRldGVybWluZSB3aGVyZSB0aGUgTVBJIHNob3VsZA0KICAgZW5kIGJlY2F1c2Ugbm8g
bm9uLXplcm8gb2N0ZXQgaXMgcmVxdWlyZWQgdG8gb2NjdXJlLg0KDQo0LjIuIE5hbWVzDQoNCiAg
IFRvIHN0b3JlIGEgc3RyaW5nIGluIGFuIE1QSSBpdCBpcyBzaW1wbHkgcHJlZml4ZWQgYnkgaXQn
cyBiaXRsZW5ndGgNCiAgICh3aXRob3V0IHRlcm1pbmF0aW5nIHplcm8tb2N0ZXQpLiBUaGF0IGlz
OiBvY3RldHMqOCBtaW51cyBsZWFkaW5nDQogICB6ZXJvIGJpdHMgaW4gdGhlIGZpcnN0IG9jdGV0
IChmb3IgYXNjaWkgbmFtZXMgdGhhdCB3aWxsIGJlIDEgb3IgMikuDQogICANCiAgIFJhdGlvbmFs
OiBUaGVyZSBpcyBubyBuZWVkIHRvIGFsbG93IG90aGVyIGRhdGEgdHlwZXMgbGlrZSBzdHJpbmdz
IGluDQogICB0aGUgYWxnb3JpdGhtIHNwZWNpZmljIGZpZWxkcywgb25seSB0byBnZXQgYW4gb2N0
ZXQgbGVuZ3RoIGluc3RlYWQNCiAgIG9mIGEgYml0bGVndGguIA0KDQo0LjMuIEN1cnZlIFBvaW50
cw0KDQogICBQb2ludHMgb24gYW4gZWxsaXB0aWMgY3VydmUgY29uc2lzdHMgb2YgdHdvIGNvb3Jk
aW5hdGVzLiBCdXQgdG8gYW55DQogICBnaXZlbiB4LWNvb3JkaW5hdGUgdGhlcmUgYXJlIG1heGlt
YWwgdHdvIHBvc3NpYmxlIHktY29vcmRpbmF0ZXMuIFNvDQogICBpdCBzdWZmaWNlcyB0byBzdG9y
ZSBvbmx5IG9uZSBzaWduaWZpY2FudCBiaXQgdiBvZiB5IHRvIG1ha2UgdGhlDQogICBkZWNpc2lv
bi4gVGhpcyBpcyBjYWxsZWQgdGhlIGNvbXByZXNzZWQgZm9ybS4NCg0KDQpTY2hlcmtsICAgICAg
ICAgICAgICAgICAgICAgU3RhbmRhcmRzIFRyYWNrICAgICAgICAgICAgICAgICAgICAgW1BhZ2Ug
Nl0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgT3BlblBHUCBFQ0MgRm9ybWF0cyAgICAg
ICAgICAgICAgICBBdWd1c3QgMjAwMQ0KDQogICBUaGVyZWZvcmUgUG9pbnRzIGFyZSBzdG9yZWQg
YXMgYSBzaW5nbGUgTVBJLiBUaGUgY29udGFpbmVkIG51bWJlcg0KICAgaXMgaW50ZXJwcmV0ZWQg
aW4gdGhlIGZvbGxvd2luZyB3YXk6DQogICBJdCdzIGhpZ2hlc3Qgb2N0ZXQgaXMgYSBiaXQgZmxh
ZzogMDAwMDB1Y3YNCiAgIElmIGM9MSwgdiBpcyB0aGUgY29tcHJlc3NlZCB5LCBlbHNlIHYgTVVT
VCBiZSAwLg0KICAgSWYgdT0xLCBib3RoIHggYW5kIHkgYXJlIGNvbnRhaW5lZCB1bmNvbXByZXNz
ZWQsIGVsc2Ugb25seSB4Lg0KDQogICBJZiBib3RoIGNvb3JkaW5hdGVzIGFyZSBjb250YWluZWQs
IHRoZXkgTVVTVCBoYXZlIHRoZSBzYW1lIG51bWJlciBvZg0KICAgb2N0ZXRzIChwYWQgd2l0aCBs
ZWFkaW5nIHplcm9zIGlmIHRoZXkgZG9uJ3QpLiB5IGlzIHN0b3JlZCBiZWhpbmQgeC4NCiAgIEl0
J3MgYWxsb3dlZCB0aGF0IGJvdGggYyBhbmQgdSBhcmUgc2V0IChpbiB0aGF0IGNhc2UgdiBNVVNU
IGZpdCB5KS4NCiAgIElmIG5laXRoZXIgYyBub3IgdSBpcyBzZXQsIHRoZSBlbnRpcmUgdmFsdWUg
TVVTVCBiZSAwICh0aGUgcG9pbnQgYXQNCiAgIGluZmluaXR5KS4gSW1wbGVtZW50YXRpb25zIFNI
T1VMRCBzdG9yZSBwb2ludHMgY29tcHJlc3NlZC4NCg0KICAgUmF0aW9uYWw6IFRoaXMgZm9ybWF0
IGlzIGNob29zZW4gZm9yIGNvbXBhdGliaWxpdHkgd2l0aCBvdGhlciBhY3R1YWwNCiAgIHN0YW5k
YXJkcyBsaWtlIFg5LjYyIFs0XSwgWDkuNjMgWzVdIGFuZCBTRUMgMiBbNl0uDQoNCjQuNC4gRmll
bGQgRGVzY3JpcHRvcg0KDQogICBXZSBkaXN0aW5ndWlzaCBiZXR3ZWVuIHNldmVyYWwga2luZHMg
b2YgZmllbGQgcmVwcmVzZW50YXRpb25zIHRoYXQNCiAgIHJlcXVpcmUgZGlmZmVyZW50IHBhcmFt
ZXRlcnMuIFRoaXMgaXMgZGV0ZXJtaW5lZCBieSBhIGZpZWxkDQogICBkZXNjcmlwdG9yIEQuIElt
cGxlbWVudGF0aW9ucyBTSE9VTEQgc3RvcmUgdGhlIGluZm9ybWF0aW9uIGFsd2F5cyBpbg0KICAg
dGhlIGJlc3QgZml0dGluZyBmb3JtLCBiZWNhdXNlIEQgaXMgYWxzbyBhbiBvcHRpbWl6YXRpb24g
aGludC4NCiAgIEQgbWF5IHRha2UgdGhlIGZvbGxvd2luZyB2YWx1ZXM6DQoNCiAgICAwOiBOYW1l
ZCBjdXJ2ZSAoZm9sbG93ZWQgYnkgY3VydmVfbmFtZSkNCiAgICAxOiBQc2V1ZG8gbWVyc2VubmUg
cHJpbWUgZmllbGQgRihwKSAoZm9sbG93ZWQgYnkgciBhbmQgYy4NCiAgICAgICBwID0gMl5yIC0g
YywgImJlbG93IHNvbWUgdHdvcG93ZXIiKQ0KICAgIDI6IFBzZXVkbyBtZXJzZW5uZSBwcmltZSBm
aWVsZCBGKHApIChmb2xsb3dlZCBieSByIGFuZCBjLg0KICAgICAgIHAgPSAyXnIgKyBjLCAiYWJv
dmUgc29tZSB0d29wb3dlciIpDQogICAgMzogUHJpbWUgZmllbGQgRihwKSAoZm9sbG93ZWQgYnkg
cCkNCg0KICAgIDQ6IFR5cGUtSSZJSSBleHRlbnNpb24gZmllbGQgRihwXm0pIChmb2xsb3dlZCBi
eSByLCBjLCBtIGFuZCB3Lg0KICAgICAgIHAgPSAyXnIgLSBjLCAiYmVsb3cgc29tZSB0d29wb3dl
ciIsIGYodCkgPSB0Xm0gLSB3KQ0KICAgIDU6IFR5cGUtSSZJSSBleHRlbnNpb24gZmllbGQgRihw
Xm0pIChmb2xsb3dlZCBieSByLCBjLCBtIGFuZCB3Lg0KICAgICAgIHAgPSAyXnIgKyBjLCAiYWJv
dmUgc29tZSB0d29wb3dlciIsIGYodCkgPSB0Xm0gLSB3KQ0KICAgIDY6IFR5cGUtSUkgZXh0ZW5z
aW9uIGZpZWxkIEYocF5tKSAoZm9sbG93ZWQgYnkgcCwgbSBhbmQgdy4NCiAgICAgICBmKHQpID0g
dF5tIC0gdykNCiAgICA3OiBUeXBlLUkgZXh0ZW5zaW9uIGZpZWxkIEYocF5tKSAoZm9sbG93ZWQg
YnkgciwgYywgbSBhbmQgZi4NCiAgICAgICBwID0gMl5yIC0gYywgImJlbG93IHNvbWUgdHdvcG93
ZXIiKQ0KICAgIDg6IFR5cGUtSSBleHRlbnNpb24gZmllbGQgRihwXm0pIChmb2xsb3dlZCBieSBy
LCBjLCBtIGFuZCBmLg0KICAgICAgIHAgPSAyXnIgKyBjLCAiYWJvdmUgc29tZSB0d29wb3dlciIp
DQogICAgOTogT2RkIGV4dGVuc2lvbiBmaWVsZCBGKHBebSkgKGZvbGxvd2VkIGJ5IHAsIG0gYW5k
IGYpDQoNCiAgIDEwOiBDaXJjdWxhciBkdWFsIGJhc2lzIG9mIEYoMl5tKSAoZm9sbG93ZWQgYnkg
bSkNCiAgIDExOiBUcmlub21pYWwgYmFzaXMgb2YgRigyXm0pIChmb2xsb3dlZCBieSBtIGFuZCBr
KQ0KICAgMTI6IFBlbnRhbm9taWFsIGJhc2lzIG9mIEYoMl5tKSAoZm9sbG93ZWQgYnkgbSwgazEs
IGsyIGFuZCBrMykNCiAgIDEzOiBQb2x5bm9taWFsIGJhc2lzIG9mIEYoMl5tKSAoZm9sbG93ZWQg
YnkgbSBhbmQgZikNCiAgIDE0OiBUeXBlLUktT05CIG9mIEYoMl5tKSAoZm9sbG93ZWQgYnkgbSkN
CiAgIDE1OiBUeXBlLUlJLU9OQiBvZiBGKDJebSkgKGZvbGxvd2VkIGJ5IG0pDQogICAxNjogR2F1
c3NpYW4gbm9ybWFsIGJhc2lzIG9mIEYoMl5tKSAoZm9sbG93ZWQgYnkgbSBhbmQgVCkNCg0KICAg
T3RoZXIgdmFsdWVzIG9mIEQgYXJlIHJlc2VydmVkLiBUbyBjb21wbHkgd2l0aCB0aGUgc3RhbmRh
cmQgRCBpcw0KICAgc3RvcmVkIGFzIGFuIE1QSSwgYWx0aG91Z2ggYSBzaW5nbGUgYnl0ZSB3b3Vs
ZCBiZSBlbm91Z2guIA0KDQpTY2hlcmtsICAgICAgICAgICAgICAgICAgICAgU3RhbmRhcmRzIFRy
YWNrICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgN10NCgwNCkludGVybmV0LURyYWZ0ICAgICAg
ICAgICAgT3BlblBHUCBFQ0MgRm9ybWF0cyAgICAgICAgICAgICAgICBBdWd1c3QgMjAwMQ0KDQo1
LiBBbGdvcml0aG0gU3BlY2lmaWMgRmllbGRzIGZvciBFQ0MgYW5kIEVDRFNBIFB1YmxpYyBLZXlz
DQoNCiAgIC0gRmllbGQgZGVzY3JpcHRvciBEIChhbGxvd2VkIHZhbHVlcyBhcmUgMCB0byAxNikN
CiAgIC0gTmFtZSBjdXJ2ZV9uYW1lIChmb3IgRCA9IDApDQogICAtIE1QSSByLCAtYyAoZm9yIEQg
PSAxLCA0IG9yIDcpDQogICAtIE1QSSByLCArYyAoZm9yIEQgPSAyLCA1IG9yIDgpDQogICAtIE1Q
SSBwIChmb3IgRCA9IDMsIDYgb3IgOSkNCiAgIC0gTVBJIG0gKGZvciBEID4gMykNCiAgIC0gTVBJ
IHcgKGZvciBEID0gNCwgNSBvciA2KQ0KICAgLSBNUEkgayAoZm9yIEQgPSAxMSkNCiAgIC0gTVBJ
IGsxLCBrMiwgazMgKGZvciBEID0gMTIpDQogICAtIE1QSSBmIChmb3IgRCA9IDcsIDgsIDkgb3Ig
MTMpDQogICAtIE1QSSBUIChmb3IgRCA9IDE2KQ0KICAgLSBNUEkgYSwgYiAoZm9yIEQgbm90IDAp
DQogICAtIEN1cnZlIFBvaW50IEcgKGZvciBEIG5vdCAwKSAgIA0KICAgLSBNUEkgbiwgaCAoZm9y
IEQgbm90IDApDQogICANCiAgIC0gQ3VydmUgUG9pbnQgUSwgdGhlIGVzc2VudGlhbCBvZiB0aGUg
cHVibGljIGtleS4gUSBpcyB0aGUgcmVzdWx0IG9mDQogICAgIG11bHRpcGx5aW5nIHRoZSBiYXNl
IHBvaW50IEcgd2l0aCB0aGUgc2VjcmV0IG51bWJlciBkLiANCg0KNi4gQWxnb3JpdGhtIFNwZWNp
ZmljIEZpZWxkcyBmb3IgRUNDIGFuZCBFQ0RTQSBTZWNyZXQgS2V5cw0KDQogICAtIE1QSSBkLCB0
aGUgZXNzZW50aWFsIG9mIHRoZSBzZWNyZXQga2V5LiBkIGlzIGEgcmFuZG9tIG51bWJlcg0KICAg
ICAxIDwgZCA8IG4sIHdoaWNoIHByb2R1Y2VzIHRoZSBwdWJsaWMgY3VydmUgcG9pbnQgUSA9IGQq
Ry4NCg0KNy4gRUNDDQoNCiAgIFRoZSBlbGxpcHRpYyBjdXJ2ZSBjaXBoZXIgYWxnb3JpdGhtIChJ
RCAxOCkgcmVxdWlyZXMgYSBoYXNoLWFsZ29yaXRobQ0KICAgYXMgZm9yIHNpZ25hdHVyZXMgdG8g
Y2FsY3VsYXRlIHNvbWUgbWFzay4gVGhpcyBtYXNrIGlzIGNhbGN1bGF0ZWQgdGhlDQogICBmb2xs
b3dpbmcgd2F5Og0KICAgU29tZSBkYXRhIERIIHBsdXMgYSBmb3VyIG9jdGV0IGNvdW50ZXIgKGJp
ZyBlbmRpYW4pIGlzIGhhc2hlZA0KICAgcmVwZWF0ZWRseS4gVGhlIGNvdW50ZXIgc3RhcnRzIHdp
dGggdGhlIHZhbHVlIDAgYW5kIGlzIGluY3JlbWVudGVkDQogICBpbiBlYWNoIHN0ZXAuIFRoZSBy
ZXN1bHRpbmcgaGFzaCB2YWx1ZXMgYXJlIGNvbmNhdGVuYXRlZCB1bnRpbCB0aGVpcg0KICAgbGVu
Z3RoIGVxdWFscyB0aGF0IG9mIHRoZSBtZXNzYWdlIC0gaWYgaXQncyB0b28gbG9uZyB0aGUgbGFz
dCBvY3RldHMNCiAgIGFyZSBjdXQuIFRoaXMgY29uY2F0ZW5hdGVkIHN0cmluZyBpcyB0aGUgbWFz
ay4NCiAgIEZvciBzeW1tZXRyaWMgc2Vzc2lvbiBrZXlzIHR5cGljYWx5IHVzZWQgdG9kYXkgb25s
eSBvbmUgb3IgdHdvIGhhc2hlcw0KICAgYXJlIG5lZWRlZCAoc2VlIElFRUUgUDEzNjMgWzJdIGZv
ciBkZXRhaWxzKS4NCg0KICAgVGhlIGNvbXBsZXRlIGNpcGhlciByZXF1aXJlcyB0aGUgZm9sbG93
aW5nIHN0ZXBzOg0KDQo3LjEuIEVDQyBFbmNyeXB0aW9uDQoNCiAgIDEuIEdlbmVyYXRlIGEgdGVt
cG9yYXJ5IHJhbmRvbSBrZXlwYWlyICh0ZCwgdFEpIHRvIHRoZSBzYW1lIEVDIGRvbWFpbg0KICAg
ICAgYXMgdGhlIHJlY2VpdmVycyBwdWJsaWMga2V5IHBhcmFtZXRlciBRLA0KICAgMi4gY2FsY3Vs
YXRlIGEgc2hhcmVkIHNlY3JldCBESCA9IHgtY29vcmRpbmF0ZSBvZiB0aGUgY3VydmUgcG9pbnQN
CiAgICAgIGgqdGQqUSwNCiAgIDMuIGNhbGN1bGF0ZSBhIE1hc2sgTSB0byB0aGUgc2Vzc2lvbiBr
ZXkgZSBvdXQgb2YgREgsDQogICA0LiBzdG9yZSAodFEsIGUgeG9yIE0pIGluIHRoZSBlbmNyeXB0
ZWQgc2Vzc2lvbiBrZXkgcGFja2V0Lg0KDQo3LjIuIEVDQyBEZWNyeXB0aW9uDQoNCiAgIDEuIEdl
dCAodFEnLCBlJykgZnJvbSB0aGUgZW5jcnlwdGVkIHNlc3Npb24ga2V5IHBhY2tldCwNCg0KU2No
ZXJrbCAgICAgICAgICAgICAgICAgICAgIFN0YW5kYXJkcyBUcmFjayAgICAgICAgICAgICAgICAg
ICAgIFtQYWdlIDhdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgIE9wZW5QR1AgRUNDIEZv
cm1hdHMgICAgICAgICAgICAgICAgQXVndXN0IDIwMDENCg0KICAgMi4gY2FsY3VsYXRlIERIJyA9
IHgtY29vcmRpbmF0ZSBvZiB0aGUgY3VydmUgcG9pbnQgaCpkKnRRJywgdXNpbmcgdGhlDQogICAg
ICByZWNlaXZlcnMgc2VjcmV0IGtleSBwYXJhbWV0ZXIgZCwNCiAgIDMuIGNhbGN1bGF0ZSB0aGUg
TWFzayBNJyB0byBlJyBvdXQgb2YgREgnLA0KICAgNC4gdXNlIChlJyB4b3IgTScpIGFzIGRlY3J5
cHRlZCBzZXNzaW9uIGtleS4NCg0KNy4zLiBBbGdvcml0aG0gU3BlY2lmaWMgRmllbGRzIGZvciBF
Q0MgRW5jcnlwdGlvbg0KDQogICAtIE9uZS1vY3RldCBoYXNoLWFsZ29yaXRobSwNCiAgIC0gTVBJ
IG9mIHRRIChhIHRlbXBvcmFyeSBwdWJsaWMgY3VydmUgcG9pbnQpLA0KICAgLSBNUEkgb2YgKGUg
eG9yIE0pICh0aGUgZW5jcnlwdGVkIHNlc3Npb24ga2V5IG1hdGVyaWFsKQ0KDQo4LiBFQ0RTQQ0K
DQogICBUaGUgZWxsaXB0aWMgY3VydmUgZGlnaXRhbCBzaWduYXR1cmUgYWxnb3JpdGhtIChJRCAx
OSkgcmVxdWlyZXMgdGhlDQogICBmb2xsb3dpbmcgc3RlcHMgdG8gYmUgZG9uZToNCg0KOC4xLiBT
aWduIHdpdGggRUNEU0ENCg0KICAgMS4gQ2hvb3NlIGEgcmFuZG9tIG51bWJlciBpIDwgbiwNCiAg
IDIuIGNhbGN1bGF0ZSB0ID0geC1jb29yZGluYXRlIG9mIGkqRyBtb2QgbiwNCiAgIDMuIGNhbGN1
bGF0ZSBzID0gKGUgKyBkKnQpL2kgbW9kIG4sIHdoZXJlIGUgaXMgdGhlIG1lc3NhZ2UgaGFzaCwN
CiAgIDQuIHN0b3JlICh0LCBzKSBpbiB0aGUgc2lnbmF0dXJlIHBhY2tldC4NCg0KOC4yLiBFQ0RT
QSBTaWduYXR1cmUgVmVyaWZpY2F0aW9uDQoNCiAgIDEuIEdldCAodCcsIHMnKSBmcm9tIHRoZSBz
aWduYXR1cmUgcGFja2VkIGFuZCBjYWxjdWxhdGUgdGhlIGhhc2ggZScNCiAgICAgIG9mIHRoZSBy
ZWNlaXZlZCBtZXNzYWdlLA0KICAgMi4gY2FsY3VsYXRlIHUxID0gZScvcycgbW9kIG4gYW5kIHUy
ID0gdCcvcycgbW9kIG4sDQogICAzLiBjYWxjdWxhdGUgdCA9IHgtY29vcmRpYW50ZSBvZiAodTEq
RyArIHUyKlEpIG1vZCBuLA0KICAgNC4gaWYgdCA9IHQnLCB0aGFuIHRha2UgdGhlIG1lc3NhZ2Ug
dG8gYmUgYXV0aGVudGljLg0KDQo4LjMuIEFsZ29yaXRobSBTcGVjaWZpYyBGaWVsZHMgZm9yIEVD
RFNBIFNpZ25hdHVyZXMNCg0KICAgLSBNUEkgdCAocmVkdWNlZCB4LWNvb3JkaWFudGUgb2Ygc29t
ZSBjdXJ2ZSBwb2ludCkNCiAgIC0gTVBJIHMgKGdlbmVyYXRlZCBmcm9tIHNlY3JldCBhbmQgbWVz
c2FnZSBzcGVjaWZpYyBpbmZvcm1hdGlvbikNCg0KOS4gTmFtZWQgQ3VydmVzDQoNCiAgIEtub3du
IGN1cnZlIG5hbWVzIGFyZSB0aGUgZm9sbG93aW5nIChhcyBkZWZpbmVkIGluIFg5LjYyLTE5OTgg
WzRdDQogICBhbmQgU0VDIDIgWzZdIC0gY3VydmVzIG92ZXIgZmllbGRzIHdoaWNoIGFyZSB0b28g
c21hbGwgb3IgaGF2aW5nDQogICBzbWFsbCBzdWJmaWVsZHMgYXJlIG9tbWl0ZWQgZm9yIGVuaGFu
Y2VkIHNlY3VyaXR5KSwgdGhlIGN1cnZlDQogICBwb2ludCBHIGlzIGFsd2F5cyBwcmVzZW50ZWQg
aW4gY29tcHJlc3NlZCBmb3JtOg0KDQo5LjEuIEN1cnZlcyBvdmVyIENoYXItMi1GaWVsZHMNCg0K
ICAgYzJwbmIxNjN2MToNCiAgICBGKDJeMTYzKSB3aXRoIHBlbnRhbm9taWFsIGJhc2lzIChrID0g
MSwgMiwgOCksDQogICAgYSA9IDB4MDcgMjU0NkI1NDMgNTIzNEE0MjIgRTA3ODk2NzUgRjQzMkM4
OTQgMzVERTUyNDIsDQogICAgYiA9IDB4Qzk1MTdEMDYgRDUyNDBEM0MgRkYzOEM3NEIgMjBCNkNE
NEQgNkY5REQ0RDksDQogICAgRyA9IDB4MDMwNyBBRjY5OTg5NSA0NjEwM0Q3OSAzMjlGQ0MzRCA3
NDg4MEYzMyBCQkU4MDNDQiwNCiAgICBuID0gMHgwNCAwMDAwMDAwMCAwMDAwMDAwMCAwMDAxRTYw
RiBDODgyMUNDNyA0REFFQUZDMSwNCiAgICBoID0gMi4NCg0KU2NoZXJrbCAgICAgICAgICAgICAg
ICAgICAgIFN0YW5kYXJkcyBUcmFjayAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDldDQoMDQpJ
bnRlcm5ldC1EcmFmdCAgICAgICAgICAgIE9wZW5QR1AgRUNDIEZvcm1hdHMgICAgICAgICAgICAg
ICAgQXVndXN0IDIwMDENCg0KICAgYzJwbmIxNjN2MjoNCiAgICBGKDJeMTYzKSB3aXRoIHBlbnRh
bm9taWFsIGJhc2lzIChrID0gMSwgMiwgOCksDQogICAgYSA9IDB4MDEgMDhCMzlFNzcgQzRCMTA4
QkUgRDk4MUVEMEUgODkwRTExN0MgNTExQ0YwNzIsDQogICAgYiA9IDB4MDYgNjdBQ0VCMzggQUY0
RTQ4OEMgNDA3NDMzRkYgQUU0RjFDODEgMTYzOERGMjAsDQogICAgRyA9IDB4MDMwMCAyNDI2NkU0
RSBCNTEwNkQwQSA5NjREOTJDNCA4NjBFMjY3MSBEQjlCNkNDNSwNCiAgICBuID0gMHgwMyBGRkZG
RkZGRiBGRkZGRkZGRiBGRkZERjY0RCBFMTE1MUFEQiBCNzhGMTBBNywNCiAgICBoID0gMi4NCg0K
ICAgYzJwbmIxNjN2MzoNCiAgICBGKDJeMTYzKSB3aXRoIHBlbnRhbm9taWFsIGJhc2lzIChrID0g
MSwgMiwgOCksDQogICAgYSA9IDB4MDcgQTUyNkM2M0QgM0UyNUEyNTYgQTAwNzY5OUYgNTQ0N0Uz
MkEgRTQ1NkI1MEUsDQogICAgYiA9IDB4MDMgRjcwNjE3OTggRUI5OUUyMzggRkQ2RjFCRjkgNUI0
OEZFRUIgNDg1NDI1MkIsDQogICAgRyA9IDB4MDIwMiBGOUY4N0I3QyA1NzREMEJERSBDRjhBMjJF
NiA1MjQ3NzVGOSA4Q0RFQkRDQiwNCiAgICBuID0gMHgwMyBGRkZGRkZGRiBGRkZGRkZGRiBGRkZF
MUFFRSAxNDBGMTEwQSBGRjk2MTMwOSwNCiAgICBoID0gMi4NCg0KICAgc2VjdDE2M2sxOg0KICAg
IEYoMl4xNjMpIHdpdGggcGVudGFub21pYWwgYmFzaXMgKGsgPSAzLCA2LCA3KSwNCiAgICBhID0g
MSwNCiAgICBiID0gMSwNCiAgICBHID0gMHgwMzAyIEZFMTNDMDUzIDdCQkMxMUFDIEFBMDdENzkz
IERFNEU2RDVFIDVDOTRFRUU4LA0KICAgIG4gPSAweDA0IDAwMDAwMDAwIDAwMDAwMDAwIDAwMDIw
MTA4IEEyRTBDQzBEIDk5RjhBNUVGLA0KICAgIGggPSAyLg0KDQogICBzZWN0MTYzcjE6DQogICAg
RigyXjE2Mykgd2l0aCBwZW50YW5vbWlhbCBiYXNpcyAoayA9IDMsIDYsIDcpLA0KICAgIGEgPSAw
NyBCNjg4MkNBQSBFRkE4NEY5NSA1NEZGODQyOCBCRDg4RTI0NiBEMjc4MkFFMiwNCiAgICBiID0g
MDcgMTM2MTJEQ0QgRENCNDBBQUIgOTQ2QkRBMjkgQ0E5MUY3M0EgRjk1OEFGRDksDQogICAgRyA9
IDAzMDMgNjk5Nzk2OTcgQUI0Mzg5NzcgODk1NjY3ODkgNTY3Rjc4N0EgNzg3NkE2NTQsDQogICAg
biA9IDAzIEZGRkZGRkZGIEZGRkZGRkZGIEZGRkY0OEFBIEI2ODlDMjlDIEE3MTAyNzlCLA0KICAg
IGggPSAyLg0KDQogICBzZWN0MTYzcjI6DQogICAgRigyXjE2Mykgd2l0aCBwZW50YW5vbWlhbCBi
YXNpcyAoayA9IDMsIDYsIDcpLA0KICAgIGEgPSAxLA0KICAgIGIgPSAweDAyIDBBNjAxOTA3IEI4
Qzk1M0NBIDE0ODFFQjEwIDUxMkY3ODc0IDRBMzIwNUZELA0KICAgIEcgPSAweDAzMDMgRjBFQkEx
NjIgODZBMkQ1N0UgQTA5OTExNjggRDQ5OTQ2MzcgRTgzNDNFMzYsDQogICAgbiA9IDB4MDQgMDAw
MDAwMDAgMDAwMDAwMDAgMDAwMjkyRkUgNzdFNzBDMTIgQTQyMzRDMzMsDQogICAgaCA9IDIuDQoN
CiAgIGMydG5iMTkxdjE6DQogICAgRigyXjE5MSkgd2l0aCB0cmlub21pYWwgYmFzaXMgKGsgPSA5
KSwNCiAgICBhID0gMHgyODY2NTM3QiA2NzY3NTI2MyA2QTY4RjU2NSA1NEUxMjY0MCAyNzZCNjQ5
RSBGNzUyNjI2NywNCiAgICBiID0gMHgyRTQ1RUY1NyAxRjAwNzg2RiA2N0IwMDgxQiA5NDk1QTNE
OSA1NDYyRjVERSAwQUExODVFQywNCiAgICBHID0gMHgwMiAzNkIzREFGOCBBMjMyMDZGOSBDNEYy
OTlENyBCMjFBOUMzNiA5MTM3RjJDOCA0QUUxQUEwRCwNCiAgICBuID0gMHg0MDAwMDAwMCAwMDAw
MDAwMCAwMDAwMDAwMCAwNEEyMEU5MCBDMzkwNjdDOCA5M0JCQjlBNSwNCiAgICBoID0gMi4NCg0K
ICAgYzJ0bmIxOTF2MjoNCiAgICBGKDJeMTkxKSB3aXRoIHRyaW5vbWlhbCBiYXNpcyAoayA9IDkp
LA0KICAgIGEgPSAweDQwMTAyODc3IDRENzc3N0M3IEI3NjY2RDEzIDY2RUE0MzIwIDcxMjc0Rjg5
IEZGMDFFNzE4LA0KICAgIGIgPSAweDA2MjAwNDhEIDI4QkNCRDAzIEI2MjQ5Qzk5IDE4MkI3QzhD
IEQxOTcwMEMzIDYyQzQ2QTAxLA0KDQpTY2hlcmtsICAgICAgICAgICAgICAgICAgICAgU3RhbmRh
cmRzIFRyYWNrICAgICAgICAgICAgICAgICAgICBbUGFnZSAxMF0NCgwNCkludGVybmV0LURyYWZ0
ICAgICAgICAgICAgT3BlblBHUCBFQ0MgRm9ybWF0cyAgICAgICAgICAgICAgICBBdWd1c3QgMjAw
MQ0KDQogICAgRyA9IDB4MDIgMzgwOUIyQjcgQ0MxQjI4Q0MgNUE4NzkyNkEgQUQ4M0ZEMjggNzg5
RTgxRTIgQzlFM0JGMTAsDQogICAgbiA9IDB4MjAwMDAwMDAgMDAwMDAwMDAgMDAwMDAwMDAgNTA1
MDhDQjggOUY2NTI4MjQgRTA2QjgxNzMsDQogICAgaCA9IDQuDQoNCiAgIGMydG5iMTkxdjM6DQog
ICAgRigyXjE5MSkgd2l0aCB0cmlub21pYWwgYmFzaXMgKGsgPSA5KSwNCiAgICBhID0gMHg2QzAx
MDc0NyA1NjA5OTEyMiAyMjEwNTY5MSAxQzc3RDc3RSA3N0E3NzdFNyBFN0U3N0ZDQiwNCiAgICBi
ID0gMHg3MUZFMUFGOSAyNkNGODQ3OSA4OUVGRUY4RCBCNDU5RjY2MyA5NEQ5MEYzMiBBRDNGMTVF
OCwNCiAgICBHID0gMHgwMyAzNzVENENFMiA0RkRFNDM0NCA4OURFODc0NiBFNzE3ODYwMSA1MDA5
RTY2RSAzOEE5MjZERCwNCiAgICBuID0gMHgxNTU1NTU1NSA1NTU1NTU1NSA1NTU1NTU1NSA2MTBD
MEIxOSA2ODEyQkZCNiAyODhBM0VBMywNCiAgICBoID0gNi4NCg0KICAgYzJvbmIxOTF2NDoNCiAg
ICBGKDJeMTkxKSB3aXRoIHR5cGUtSUkgb3B0aW1hbCBub3JtYWwgYmFzaXMsDQogICAgYSA9IDB4
NjU5MDNFMDQgRTFFNDkyNDIgNTNFMjZBM0MgOUFDMjhDNzUgOEJEODE4NEEgM0ZCNjgwRTgsDQog
ICAgYiA9IDB4NTQ2Nzg2MjEgQjE5MENGQ0UgMjgyQURFMjEgOUQ1QjNBMDYgNUUzRjRCM0YgRkRF
QkIyOUIsDQogICAgRyA9IDB4MDIgNUEyQzY5QTMgMkU4NjM4RTUgMUNDRUZBQUQgMDUzNTBBOTcg
ODQ1N0NCNUYgQjZERjk5NEEsDQogICAgbiA9IDB4NDAwMDAwMDAgMDAwMDAwMDAgMDAwMDAwMDAg
OUNGMkQ2RTMgOTAxREFDNEMgMzJFRUM2NUQsDQogICAgaCA9IDIuDQoNCiAgIGMyb25iMTkxdjU6
DQogICAgRigyXjE5MSkgd2l0aCB0eXBlLUlJIG9wdGltYWwgbm9ybWFsIGJhc2lzLA0KICAgIGEg
PSAweDI1RjhEMDZDIDk3QzgyMjUzIDZENDY5Q0Q1IDE3MENERDdCIEI5RjUwMEJEIDZEQjExMEZC
LA0KICAgIGIgPSAweDc1RkY1NzBFIDM1Q0E5NEZCIDM3ODBDMjYxIDlEMDgxQzE3IEFBNTlGQkQ1
IEU1OTFDMUM0LA0KICAgIEcgPSAweDAzIDJBMTY5MTBFIDhGNkM0QjE5IDlCRTI0MjEzIDg1N0FC
QzlDIDk5MkVERkIyIDQ3MUYzQzY4LA0KICAgIG4gPSAweDBGRkZGRkZGIEZGRkZGRkZGIEZGRkZG
RkZGIEVFQjM1NEI3IDI3MEIyOTkyIEI3ODE4NjI3LA0KICAgIGggPSA4Lg0KDQogICBzZWN0MTkz
cjE6DQogICAgRigyXjE5Mykgd2l0aCB0cmlub21pYWwgYmFzaXMgKGsgPSAxNSksDQogICAgYSA9
IDB4MDAgMTc4NThGRUIgN0E5ODk3NTEgNjlFMTcxRjcgN0I0MDg3REUgMDk4QUM4QTkgMTFERjdC
MDEsDQogICAgYiA9IDB4MDAgRkRGQjQ5QkYgRTZDM0E4OUYgQUNBREFBN0EgMUU1QkJDN0MgQzFD
MkU1RDggMzE0Nzg4MTQsDQogICAgRyA9IDB4MDMwMSBGNDgxQkM1RiAwRkY4NEE3NCBBRDZDREY2
RiBERUY0QkY2MSA3OTYyNTM3MiBEOEMwQzVFMSwNCiAgICBuID0gMHgwMSAwMDAwMDAwMCAwMDAw
MDAwMCAwMDAwMDAwMCBDN0YzNEE3NyA4RjQ0M0FDQyA5MjBFQkE0OSwNCiAgICBoID0gMi4NCg0K
ICAgc2VjdDE5M3IyOg0KICAgIEYoMl4xOTMpIHdpdGggdHJpbm9taWFsIGJhc2lzIChrID0gMTUp
LA0KICAgIGEgPSAweDAxIDYzRjM1QTUxIDM3QzJDRTNFIEE2RUQ4NjY3IDE5MEIwQkM0IDNFQ0Q2
OTk3IDc3MDI3MDlCLA0KICAgIGIgPSAweDAwIEM5QkI5RTg5IDI3RDRENjRDIDM3N0UyQUIyIDg1
NkE1QjE2IEUzRUZCN0Y2IDFENDMxNkFFLA0KICAgIEcgPSAweDAzMDAgRDlCNjdEMTkgMkUwMzY3
QzggMDNGMzlFMUEgN0U4MkNBMTQgQTY1MTM1MEEgQUU2MTdFOEYsDQogICAgbiA9IDB4MDEgMDAw
MDAwMDAgMDAwMDAwMDAgMDAwMDAwMDEgNUFBQjU2MUIgMDA1NDEzQ0MgRDRFRTk5RDUsDQogICAg
aCA9IDIuDQoNCiAgIHNlY3QyMzNrMToNCiAgICBGKDJeMjMzKSB3aXRoIHRyaW5vbWlhbCBiYXNp
cyAoayA9IDc0KSwNCiAgICBhID0gMCwNCiAgICBiID0gMSwNCiAgICBHID0gMHgwMjAxNzIgMzJC
QTg1M0EgN0U3MzFBRjEgMjlGMjJGRjQNCiAgICAgICAgMTQ5NTYzQTQgMTlDMjZCRjUgMEE0QzlE
NkUgRUZBRDYxMjYsDQogICAgbiA9IDB4ODAgMDAwMDAwMDAgMDAwMDAwMDAgMDAwMDAwMDANCiAg
ICAgICAgMDAwNjlENUIgQjkxNUJDRDQgNkVGQjFBRDUgRjE3M0FCREYsDQoNClNjaGVya2wgICAg
ICAgICAgICAgICAgICAgICBTdGFuZGFyZHMgVHJhY2sgICAgICAgICAgICAgICAgICAgIFtQYWdl
IDExXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICBPcGVuUEdQIEVDQyBGb3JtYXRzICAg
ICAgICAgICAgICAgIEF1Z3VzdCAyMDAxDQoNCiAgICBoID0gNC4NCg0KICAgc2VjdDIzM3IxOg0K
ICAgIEYoMl4yMzMpIHdpdGggdHJpbm9taWFsIGJhc2lzIChrID0gNzQpLA0KICAgIGEgPSAxLA0K
ICAgIGIgPSAweDAwNjYgNjQ3RURFNkMgMzMyQzdGOEMgMDkyM0JCNTgNCiAgICAgICAgMjEzQjMz
M0IgMjBFOUNFNDIgODFGRTExNUYgN0Q4RjkwQUQsDQogICAgRyA9IDB4MDMwMEZBIEM5REZDQkFD
IDgzMTNCQjIxIDM5RjFCQjc1DQogICAgICAgIDVGRUY2NUJDIDM5MUY4QjM2IEY4RjhFQjczIDcx
RkQ1NThCLA0KICAgIG4gPSAweDAxMDAgMDAwMDAwMDAgMDAwMDAwMDAgMDAwMDAwMDANCiAgICAg
ICAgMDAxM0U5NzQgRTcyRjhBNjkgMjIwMzFEMjYgMDNDRkUwRDcsDQogICAgaCA9IDIuDQoNCiAg
IHNlY3QyMzlrMToNCiAgICBGKDJeMjM5KSB3aXRoIHRyaW5vbWlhbCBiYXNpcyAoayA9IDE1OCks
DQogICAgYSA9IDAsDQogICAgYiA9IDEsDQogICAgRyA9IDB4MDMyOUEwIEI2QTg4N0E5IDgzRTk3
MzA5IDg4QTY4NzI3DQogICAgICAgIEE4QjJEMTI2IEM0NENDMkNDIDdCMkE2NTU1IDE5MzAzNURD
LA0KICAgIG4gPSAweDIwMDAgMDAwMDAwMDAgMDAwMDAwMDAgMDAwMDAwMDANCiAgICAgICAgMDA1
QTc5RkUgQzY3Q0I2RTkgMUYxQzFEQTggMDBFNDc4QTUsDQogICAgaCA9IDQuDQoNCiAgIGMydG5i
MjM5djE6DQogICAgRigyXjIzOSkgd2l0aCB0cmlub21pYWwgYmFzaXMgKGsgPSAzNiksDQogICAg
YSA9IDB4MzIwMSAwODU3MDc3QyA1NDMxMTIzQSA0NkI4MDg5MA0KICAgICAgICA2NzU2RjU0MyA0
MjNFOEQyNyA4Nzc1NzgxMiA1Nzc4QUM3NiwNCiAgICBiID0gMHg3OTA0IDA4RjJFRURBIEYzOTJC
MDEyIEVERUZCMzM5DQogICAgICAgIDJGMzBGNDMyIDdDMENBM0YzIDFGQzM4M0M0IDIyQUE4QzE2
LA0KICAgIEcgPSAweDAyNTc5MiA3MDk4RkE5MyAyRTdDMEE5NiBEM0ZENUI3MA0KICAgICAgICA2
RUY3RTVGNSBDMTU2RTE2QiA3RTdDODYwMyA4NTUyRTkxRCwNCiAgICBuID0gMHgyMDAwIDAwMDAw
MDAwIDAwMDAwMDAwIDAwMDAwMDAwDQogICAgICAgIDAwMEY0RDQyIEZGRTE0OTJBIDQ5OTNGMUNB
IEQ2NjZFNDQ3LA0KICAgIGggPSA0Lg0KDQogICBjMnRuYjIzOXYyOg0KICAgIEYoMl4yMzkpIHdp
dGggdHJpbm9taWFsIGJhc2lzIChrID0gMzYpLA0KICAgIGEgPSAweDQyMzAgMDE3NzU3QTcgNjdG
QUU0MjMgOTg1NjlCNzQNCiAgICAgICAgNjMyNUQ0NTMgMTNBRjA3NjYgMjY2NDc5QjcgNTY1NEU2
NUYsDQogICAgYiA9IDB4NTAzNyBFQTY1NDE5NiBDRkYwQ0Q4MiBCMkMxNEEyRg0KICAgICAgICBD
RjJFM0ZGOCA3NzUyODVCNSA0NTcyMkYwMyBFQUNEQjc0QiwNCiAgICBHID0gMHgwMjI4RjkgRDA0
RTkwMDAgNjlDOERDNDcgQTA4NTM0RkUNCiAgICAgICAgNzZEMkI5MDAgQjdEN0VGMzEgRjU3MDlG
MjAgMEM0Q0EyMDUsDQogICAgbiA9IDB4MTU1NSA1NTU1NTU1NSA1NTU1NTU1NSA1NTU1NTU1NQ0K
ICAgICAgICA1NTNDNkYyOCA4NTI1OUMzMSBFM0ZDREYxNSA0NjI0NTIyRCwNCiAgICBoID0gNi4N
Cg0KICAgYzJ0bmIyMzl2MzoNCiAgICBGKDJeMjM5KSB3aXRoIHRyaW5vbWlhbCBiYXNpcyAoayA9
IDM2KSwNCiAgICBhID0gMHgwMTIzIDg3NzQ2NjZBIDY3NzY2RDY2IDc2Rjc3OEU2DQogICAgICAg
IDc2QjY2OTk5IDE3NjY2NkU2IDg3NjY2RDg3IDY2QzY2QTlGLA0KICAgIGIgPSAweDZBOTQgMTk3
N0JBOUYgNkE0MzUxOTkgQUNGQzUxMDYNCg0KU2NoZXJrbCAgICAgICAgICAgICAgICAgICAgIFN0
YW5kYXJkcyBUcmFjayAgICAgICAgICAgICAgICAgICAgW1BhZ2UgMTJdDQoMDQpJbnRlcm5ldC1E
cmFmdCAgICAgICAgICAgIE9wZW5QR1AgRUNDIEZvcm1hdHMgICAgICAgICAgICAgICAgQXVndXN0
IDIwMDENCg0KICAgICAgICA3RUQ1ODdGNSAxOUM1RUNCNSA0MUI4RTQ0MSAxMURFMUQ0MCwNCiAg
ICBHID0gMHgwMzcwRjYgRTlEMDREMjggOUM0RTg5OTEgM0NFMzUzMEINCiAgICAgICAgRkRFOTAz
OTcgN0Q0MkIxNDYgRDUzOUJGMUIgREU0RTlDOTIsDQogICAgbiA9IDB4MENDQyBDQ0NDQ0NDQyBD
Q0NDQ0NDQyBDQ0NDQ0NDQw0KICAgICAgICBDQ0FDNDkxMiBEMkQ5REY5MCAzRUY5ODg4QiA4QTBF
NENGRiwNCiAgICBoID0gMTAuDQoNCiAgIGMyb25iMjM5djQ6DQogICAgRigyXjIzOSkgd2l0aCB0
eXBlLUlJIG9wdGltYWwgbm9ybWFsIGJhc2lzLA0KICAgIGEgPSAweDE4MkQgRDQ1RjVENDcgMDIz
OUI4OTggM0ZFQTQ3QjgNCiAgICAgICAgQjI5MjY0MUMgNTdGOUJGODQgQkFFQ0RFOEIgQjNBRENF
MzAsDQogICAgYiA9IDB4MTQ3QSA5QzFENEMyQyBFOUJFNUQzNCBFQzAyNzk3Rg0KICAgICAgICA3
NjY2N0VCQSBENUEzRjkzRiBBMkE1MjRCRiBERTkxRUYyOCwNCiAgICBHID0gMHgwMzQ5MTIgQUQ2
NTdGMUQgMUM2QjMyRUQgQjk5NDJDOTUNCiAgICAgICAgRTIyNkIwNkYgQjAxMkNENDAgRkRFQTBE
NzIgMTk3QzgxMDQsDQogICAgbiA9IDB4MjAwMCAwMDAwMDAwMCAwMDAwMDAwMCAwMDAwMDAwMA0K
ICAgICAgICAwMDQ3NEY3RSA2OUY0MkZFNCAzMDkzMUQwQiA0NTVBQUU4QiwNCiAgICBoID0gNC4N
Cg0KICAgYzJvbmIyMzl2NToNCiAgICBGKDJeMjM5KSB3aXRoIHR5cGUtSUkgb3B0aW1hbCBub3Jt
YWwgYmFzaXMsDQogICAgYSA9IDB4MUVDRiAxQjlEMjhEOCAwMTc1MDVFMSA3NDc1RDNERg0KICAg
ICAgICAyOTgyRTI0MyBDQTVDQjVFOSBGOTRBM0YzNiAxMjRBNDg2RSwNCiAgICBiID0gMHgzRUUy
IDU3MjUwRDFBIDJFNjZDRUYyIDNBQTBGMjVCDQogICAgICAgIDEyMzg4REU4IEExMEZGOTU1IDRG
OTBBRkJBIEE5QTA4QjZELA0KICAgIEcgPSAweDAyMTkzMiA3OUZDNTQzRSA5RjVGNzExOSAxODk3
ODVCOQ0KICAgICAgICBDNjBCMjQ5QiBFNDgyMEJBRiA2QzI0QkRGQSAyODEzRjhCOCwNCiAgICBu
ID0gMHgxNTU1IDU1NTU1NTU1IDU1NTU1NTU1IDU1NTU1NTU1DQogICAgICAgIDU1OENGNzdBIDVE
MDU4OUQyIEE5MzQwRDk2IDNCN0FENzAzLA0KICAgIGggPSA2Lg0KDQogICBzZWN0MjgzazE6DQog
ICAgRigyXjI4Mykgd2l0aCBwZW50YW5vbWlhbCBiYXNpcyAoayA9IDUsIDcsIDEyKSwNCiAgICBh
ID0gMCwNCiAgICBiID0gMSwNCiAgICBHID0gMHgwMiAwNTAzMjEzRiA3OENBNDQ4OCAzRjFBM0I4
MSA2MkYxODhFNQ0KICAgICAgICA1M0NEMjY1RiAyM0MxNTY3QSAxNjg3NjkxMyBCMEMyQUMyNCA1
ODQ5MjgzNiwNCiAgICBuID0gMHgwMUZGRkZGRiBGRkZGRkZGRiBGRkZGRkZGRiBGRkZGRkZGRg0K
ICAgICAgICBGRkZGRTlBRSAyRUQwNzU3NyAyNjVERkY3RiA5NDQ1MUUwNiAxRTE2M0M2MSwNCiAg
ICBoID0gNC4NCg0KICAgc2VjdDI4M3IxOg0KICAgIEYoMl4yODMpIHdpdGggcGVudGFub21pYWwg
YmFzaXMgKGsgPSA1LCA3LCAxMiksDQogICAgYSA9IDEsDQogICAgYiA9IDB4MDI3QjY4MEEgQzhC
ODU5NkQgQTVBNEFGOEEgMTlBMDMwM0YNCiAgICAgICAgQ0E5N0ZENzYgNDUzMDlGQTIgQTU4MTQ4
NUEgRjYyNjNFMzEgM0I3OUEyRjUsDQogICAgRyA9IDB4MDMgMDVGOTM5MjUgOERCN0REOTAgRTE5
MzRGOEMgNzBCMERGRUMNCiAgICAgICAgMkVFRDI1QjggNTU3RUFDOUMgODBFMkUxOTggRjhDREJF
Q0QgODZCMTIwNTMsDQogICAgbiA9IDB4MDNGRkZGRkYgRkZGRkZGRkYgRkZGRkZGRkYgRkZGRkZG
RkYNCiAgICAgICAgRkZGRkVGOTAgMzk5NjYwRkMgOTM4QTkwMTYgNUIwNDJBN0MgRUZBREIzMDcs
DQogICAgaCA9IDIuDQoNCg0KU2NoZXJrbCAgICAgICAgICAgICAgICAgICAgIFN0YW5kYXJkcyBU
cmFjayAgICAgICAgICAgICAgICAgICAgW1BhZ2UgMTNdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAg
ICAgICAgIE9wZW5QR1AgRUNDIEZvcm1hdHMgICAgICAgICAgICAgICAgQXVndXN0IDIwMDENCg0K
ICAgYzJ0bmIzNTl2MToNCiAgICBGKDJeMzU5KSB3aXRoIHRyaW5vbWlhbCBiYXNpcyAoaz02OCks
DQogICAgYSA9IDB4NTYgNjc2NzZBNjUgNEIyMDc1NEYgMzU2RUE5MjAgMTdEOTQ2NTYgN0M0NjY3
NTUNCiAgICAgICAgNTZGMTk1NTYgQTA0NjE2QjUgNjdEMjIzQTUgRTA1NjU2RkIgNTQ5MDE2QTkg
NjY1NkE1NTcsDQogICAgYiA9IDB4MjQgNzJFMkQwMTkgN0M0OTM2M0YgMUZFN0Y1QjYgREIwNzVE
NTIgQjY5NDdEMTMNCiAgICAgICAgNUQ4Q0E0NDUgODA1RDM5QkMgMzQ1NjI2MDggOTY4Nzc0MkIg
NjMyOUU3MDYgODAyMzE5ODgsDQogICAgRyA9IDB4MDMzQyAyNThFRjMwNCA3NzY3RTdFRCBFMEYx
RkRBQSA3OURBRUUzOCA0MTM2NkExMw0KICAgICAgICAyRTE2M0FDRSBENEVEMjQwMSBERjlDNkJE
QyBERTk4RThFNyAwN0MwN0EyMiAzOUIxQjA5NywNCiAgICBuID0gMHgwMSBBRjI4NkJDQSAxQUYy
ODZCQyBBMUFGMjg2QiBDQTFBRjI4NiBCQ0ExQUYyOA0KICAgICAgICA2QkM5RkI4RiA2Qjg1QzU1
NiA4OTJDMjBBNyBFQjk2NEZFNyA3MTlFNzRGNCA5MDc1OEQzQiwNCiAgICBoID0gMHg0Qy4NCg0K
ICAgc2VjdDQwOWsxOg0KICAgIEYoMl40MDkpIHdpdGggdHJpbm9taWFsIGJhc2lzIChrID0gODcp
LA0KICAgIGEgPSAwLA0KICAgIGIgPSAxLA0KICAgIEcgPSAweDAzIDAwNjBGMDVGIDY1OEY0OUMx
IEFEM0FCMTg5IDBGNzE4NDIxIDBFRkQwOTg3IEUzMDdDODRDDQogICAgICAgIDI3QUNDRkI4IEY5
RjY3Q0MyIEM0NjAxODlFIEI1QUFBQTYyIEVFMjIyRUIxIEIzNTU0MENGIEU5MDIzNzQ2LA0KICAg
IG4gPSAweDdGRkZGRiBGRkZGRkZGRiBGRkZGRkZGRiBGRkZGRkZGRiBGRkZGRkZGRiBGRkZGRkZG
Rg0KICAgICAgICBGRkZGRkU1RiA4M0IyRDRFQSAyMDQwMEVDNCA1NTdENUVEMyBFM0U3Q0E1QiA0
QjVDODNCOCBFMDFFNUZDRiwNCiAgICBoID0gNC4NCg0KICAgc2VjdDQwOXIxOg0KICAgIEYoMl40
MDkpIHdpdGggdHJpbm9taWFsIGJhc2lzIChrID0gODcpLA0KICAgIGEgPSAxLA0KICAgIGIgPSAw
eDAwMjFBNUMyIEM4RUU5RkVCIDVDNEI5QTc1IDNCN0I0NzZCIDdGRDY0MjJFIEYxRjNERDY3DQog
ICAgICAgIDQ3NjFGQTk5IEQ2QUMyN0M4IEE5QTE5N0IyIDcyODIyRjZDIEQ1N0E1NUFBIDRGNTBB
RTMxIDdCMTM1NDVGLA0KICAgIEcgPSAweDAzIDAxNUQ0ODYwIEQwODhEREIzIDQ5NkIwQzYwIDY0
NzU2MjYwIDQ0MUNERTRBIEYxNzcxRDREDQogICAgICAgIEIwMUZGRTVCIDM0RTU5NzAzIERDMjU1
QTg2IDhBMTE4MDUxIDU2MDNBRUFCIDYwNzk0RTU0IEJCNzk5NkE3LA0KICAgIG4gPSAweDAxMDAw
MDAwIDAwMDAwMDAwIDAwMDAwMDAwIDAwMDAwMDAwIDAwMDAwMDAwIDAwMDAwMDAwDQogICAgICAg
IDAwMDAwMUUyIEFBRDZBNjEyIEYzMzMwN0JFIDVGQTQ3QzNDIDlFMDUyRjgzIDgxNjRDRDM3IEQ5
QTIxMTczLA0KICAgIGggPSAyLg0KDQogICBjMnRuYjQzMXIxOg0KICAgIEYoMl40MzEpIHdpdGgg
dHJpbm9taWFsIGJhc2lzIChrPTEyMCksDQogICAgYSA9IDB4MUE4MjdFRjAwREQ2RkMwRTIzNENB
RjA0NkM2QTVEOEE4NTM5NUIyMzZDQzRBRDJDRjMyQTBDDQogICAgICAgICAgQURCREM5RERGNjIw
QjBFQjk5MDZEMDk1N0Y2QzZGRUFDRDYxNTQ2OERGMTA0REUyOTZDRDhGLA0KICAgIGIgPSAweDEw
RDlCNEEzRDkwNDdEOEIxNTQzNTlBQkZCMUI3RjU0ODVCMDRDRUI4NjgyMzdEREM5REVEQQ0KICAg
ICAgICAgIDk4MkE2NzlBNUE5MTlCNjI2RDRFNTBBOERENzMxQjEwN0E5OTYyMzgxRkI1RDgwN0JG
MjYxOCwNCiAgICBHID0gMHgyMTIwRkMwNUQzQzY3QTk5REUxNjFEMkY0MDkyNjIyRkVDQTcwMUJF
NEY1MEY0NzU4NzE0RThBDQogICAgICAgICAgODdCQkYyQTY1OEVGOEMyMUU3QzVFRkU5NjUzNjFG
NkMyOTk5QzBDMjQ3QjBEQkQ3MENFNkI3LA0KICAgIG4gPSAweDAzNDAzNDAzNDAzNDAzNDAzNDAz
NDAzNDAzNDAzNDAzNDAzNDAzNDAzNDAzNDAzNDAzNDAzDQogICAgICAgICAgNDAzMjNDMzEzRkFC
NTA1ODk3MDNCNUVDNjhEMzU4N0ZFQzYwRDE2MUNDMTQ5QzFBRDRBOTEsDQogICAgaCA9IDB4Mjc2
MC4NCg0KICBzZWN0NTcxazE6DQogICAgRigyXjU3MSkgd2l0aCBwZW50YW5vbWlhbCBiYXNpcyAo
ayA9IDIsIDUsIDEwKSwNCiAgICBhID0gMCwNCiAgICBiID0gMSwNCiAgICBHID0gMHgwMiAwMjZF
QjdBOCA1OTkyM0ZCQyA4MjE4OTYzMSBGODEwM0ZFNCBBQzlDQTI5NyAwMDEyRDVENA0KICAgICAg
ICA2MDI0ODA0OCAwMTg0MUNBNCA0MzcwOTU4NCA5M0IyMDVFNiA0N0RBMzA0RCBCNENFQjA4Qw0K
ICAgICAgICBCQkQxQkEzOSA0OTQ3NzZGQiA5ODhCNDcxNyA0RENBODhDNyBFMjk0NTI4MyBBMDFD
ODk3MiwNCiANClNjaGVya2wgICAgICAgICAgICAgICAgICAgICBTdGFuZGFyZHMgVHJhY2sgICAg
ICAgICAgICAgICAgICAgIFtQYWdlIDE0XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICBP
cGVuUEdQIEVDQyBGb3JtYXRzICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDAxDQoNCiAgICBuID0g
MHgwMjAwMDAwMCAwMDAwMDAwMCAwMDAwMDAwMCAwMDAwMDAwMCAwMDAwMDAwMCAwMDAwMDAwMA0K
ICAgICAgICAwMDAwMDAwMCAwMDAwMDAwMCAwMDAwMDAwMCAxMzE4NTBFMSBGMTlBNjNFNCBCMzkx
QThEQg0KICAgICAgICA5MTdGNDEzOCBCNjMwRDg0QiBFNUQ2MzkzOCAxRTkxREVCNCA1Q0ZFNzc4
RiA2MzdDMTAwMSwNCiAgICBoID0gNC4NCg0KICAgc2VjdDU3MXIxOg0KICAgIEYoMl41NzEpIHdp
dGggcGVudGFub21pYWwgYmFzaXMgKGsgPSAyLCA1LCAxMCksDQogICAgYSA9IDEsDQogICAgYiA9
IDB4MDJGNDBFN0UgMjIyMUYyOTUgREUyOTcxMTcgQjdGM0Q2MkYgNUM2QTk3RkYgQ0I4Q0VGRjEN
CiAgICAgICAgQ0Q2QkE4Q0UgNEE5QTE4QUQgODRGRkFCQkQgOEVGQTU5MzMgMkJFN0FENjcgNTZB
NjZFMjkNCiAgICAgICAgNEFGRDE4NUEgNzhGRjEyQUEgNTIwRTRERTcgMzlCQUNBMEMgN0ZGRUZG
N0YgMjk1NTcyN0EsDQogICAgRyA9IDB4MDMgMDMwMzAwMUQgMzRCODU2MjkgNkMxNkMwRDQgMEQz
Q0Q3NzUgMEE5M0QxRDIgOTU1RkE4MEENCiAgICAgICAgQTVGNDBGQzggREI3QjJBQkQgQkRFNTM5
NTAgRjRDMEQyOTMgQ0RENzExQTMgNUI2N0ZCMTQNCiAgICAgICAgOTlBRTYwMDMgODYxNEYxMzkg
NEFCRkEzQjQgQzg1MEQ5MjcgRTFFNzc2OUMgOEVFQzJEMTksDQogICAgbiA9IDB4MDNGRkZGRkYg
RkZGRkZGRkYgRkZGRkZGRkYgRkZGRkZGRkYgRkZGRkZGRkYgRkZGRkZGRkYNCiAgICAgICAgRkZG
RkZGRkYgRkZGRkZGRkYgRkZGRkZGRkYgRTY2MUNFMTggRkY1NTk4NzMgMDgwNTlCMTgNCiAgICAg
ICAgNjgyMzg1MUUgQzdERDlDQTEgMTYxREU5M0QgNTE3NEQ2NkUgODM4MkU5QkIgMkZFODRFNDcs
DQogICAgaCA9IDIuDQoNCjkuMi4gQ3VydmVzIG92ZXIgUHJpbWUtRmllbGRzDQoNCiAgIHNlY3Ax
NjBrMQ0KICAgIEYocCkgd2l0aA0KICAgIHAgPSBGRkZGRkZGRiBGRkZGRkZGRiBGRkZGRkZGRiBG
RkZGRkZGRSBGRkZGQUM3MywNCiAgICBhID0gMCwNCiAgICBiID0gNywNCiAgICBHID0gMDIgM0I0
QzM4MkMgRTM3QUExOTIgQTQwMTlFNzYgMzAzNkY0RjUgREQ0RDdFQkIsDQogICAgbiA9IDAxIDAw
MDAwMDAwIDAwMDAwMDAwIDAwMDFCOEZBIDE2REZBQjlBIENBMTZCNkIzLA0KICAgIGggPSAwMS4N
Cg0KICAgc2VjcDE2MHIxDQogICAgRihwKSB3aXRoDQogICAgcCA9IEZGRkZGRkZGIEZGRkZGRkZG
IEZGRkZGRkZGIEZGRkZGRkZGIDdGRkZGRkZGLA0KICAgIGEgPSBwLTMsDQogICAgYiA9IDFDOTdC
RUZDIDU0QkQ3QThCIDY1QUNGODlGIDgxRDRENEFEIEM1NjVGQTQ1LA0KICAgIEcgPSAwMiA0QTk2
QjU2OCA4RUY1NzMyOCA0NjY0Njk4OSA2OEMzOEJCOSAxM0NCRkM4MiwNCiAgICBuID0gMDEgMDAw
MDAwMDAgMDAwMDAwMDAgMDAwMUY0QzggRjkyN0FFRDMgQ0E3NTIyNTcsDQogICAgaCA9IDAxLg0K
DQogICBzZWNwMTYwcjINCiAgICBGKHApIHdpdGgNCiAgICBwID0gRkZGRkZGRkYgRkZGRkZGRkYg
RkZGRkZGRkYgRkZGRkZGRkUgRkZGRkFDNzMsDQogICAgYSA9IHAtMywNCiAgICBiID0gQjRFMTM0
RDMgRkI1OUVCOEIgQUI1NzI3NDkgMDQ2NjRENUEgRjUwMzg4QkEsDQogICAgRyA9IDAyIDUyRENC
MDM0IDI5M0ExMTdFIDFGNEZGMTFCIDMwRjcxOTlEIDMxNDRDRTZELA0KICAgIG4gPSAwMSAwMDAw
MDAwMCAwMDAwMDAwMCAwMDAwMzUxRSBFNzg2QTgxOCBGM0ExQTE2QiwNCiAgICBoID0gMDEuDQoN
CiAgIHNlY3AxOTJrMToNCiAgICBGKHApIHdpdGgNCiAgICBwID0gMHhGRkZGRkZGRiBGRkZGRkZG
RiBGRkZGRkZGRiBGRkZGRkZGRiBGRkZGRkZGRSBGRkZGRUUzNywNCiAgICBhID0gMCwNCg0KU2No
ZXJrbCAgICAgICAgICAgICAgICAgICAgIFN0YW5kYXJkcyBUcmFjayAgICAgICAgICAgICAgICAg
ICAgW1BhZ2UgMTVdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgIE9wZW5QR1AgRUNDIEZv
cm1hdHMgICAgICAgICAgICAgICAgQXVndXN0IDIwMDENCg0KICAgIGIgPSAzLA0KICAgIEcgPSAw
eDAzIERCNEZGMTBFIEMwNTdFOUFFIDI2QjA3RDAyIDgwQjdGNDM0IDFEQTVEMUIxIEVBRTA2QzdE
LA0KICAgIG4gPSAweEZGRkZGRkZGIEZGRkZGRkZGIEZGRkZGRkZFIDI2RjJGQzE3IDBGNjk0NjZB
IDc0REVGRDhELA0KICAgIGggPSAxLg0KDQogICBwcmltZTE5MnYxIC8gc2VjcDE5MnIxOg0KICAg
IEYocCkgd2l0aA0KICAgIHAgPSAweEZGRkZGRkZGIEZGRkZGRkZGIEZGRkZGRkZGIEZGRkZGRkZF
IEZGRkZGRkZGIEZGRkZGRkZGLA0KICAgIGEgPSBwLTMsDQogICAgYiA9IDB4NjQyMTA1MTkgRTU5
QzgwRTcgMEZBN0U5QUIgNzIyNDMwNDkgRkVCOERFRUMgQzE0NkI5QjEsDQogICAgRyA9IDB4MDMg
MTg4REE4MEUgQjAzMDkwRjYgN0NCRjIwRUIgNDNBMTg4MDAgRjRGRjBBRkQgODJGRjEwMTIsDQog
ICAgbiA9IDB4RkZGRkZGRkYgRkZGRkZGRkYgRkZGRkZGRkYgOTlERUY4MzYgMTQ2QkM5QjEgQjRE
MjI4MzEsDQogICAgaCA9IDEuDQoNCiAgIHByaW1lMTkydjI6DQogICAgRihwKSB3aXRoDQogICAg
cCA9IDB4RkZGRkZGRkYgRkZGRkZGRkYgRkZGRkZGRkYgRkZGRkZGRkUgRkZGRkZGRkYgRkZGRkZG
RkYsDQogICAgYSA9IHAtMywNCiAgICBiID0gMHhDQzIyRDZERiBCOTVDNkIyNSBFNDlDMEQ2MyA2
NEE0RTU5OCAwQzM5M0FBMiAxNjY4RDk1MywNCiAgICBHID0gMHgwMyBFRUEyQkFFNyBFMTQ5Nzg0
MiBGMkRFNzc2OSBDRkU5Qzk4OSBDMDcyQUQ2OSA2RjQ4MDM0QSwNCiAgICBuID0gMHhGRkZGRkZG
RiBGRkZGRkZGRiBGRkZGRkZGRSA1RkIxQTcyNCBEQzgwNDE4NiA0OEQ4REQzMSwNCiAgICBoID0g
MS4NCg0KICAgcHJpbWUxOTJ2MzoNCiAgICBGKHApIHdpdGgNCiAgICBwID0gMHhGRkZGRkZGRiBG
RkZGRkZGRiBGRkZGRkZGRiBGRkZGRkZGRSBGRkZGRkZGRiBGRkZGRkZGRiwNCiAgICBhID0gcC0z
LA0KICAgIGIgPSAweDIyMTIzREMyIDM5NUEwNUNBIEE3NDIzREFFIENDQzk0NzYwIEE3RDQ2MjI1
IDZCRDU2OTE2LA0KICAgIEcgPSAweDAyIDdEMjk3NzgxIDAwQzY1QTFEIEExNzgzNzE2IDU4OERD
RTJCIDhCNEFFRThFIDIyOEYxODk2LA0KICAgIG4gPSAweEZGRkZGRkZGIEZGRkZGRkZGIEZGRkZG
RkZGIDdBNjJEMDMxIEM4M0Y0Mjk0IEY2NDBFQzEzLA0KICAgIGggPSAxLg0KDQogICBzZWNwMjI0
azE6DQogICAgRihwKSB3aXRoDQogICAgcCA9IDB4RkZGRkZGRkYgRkZGRkZGRkYgRkZGRkZGRkYN
CiAgICAgICAgRkZGRkZGRkYgRkZGRkZGRkYgRkZGRkZGRkUgRkZGRkU1NkQsDQogICAgYSA9IDAs
DQogICAgYiA9IDUsDQogICAgRyA9IDB4MDMgQTE0NTVCMzMgNERGMDk5REYgMzBGQzI4QTENCiAg
ICAgICAgNjlBNDY3RTkgRTQ3MDc1QTkgMEY3RTY1MEUgQjZCN0E0NUMsDQogICAgbiA9IDB4MDEg
MDAwMDAwMDAgMDAwMDAwMDAgMDAwMDAwMDANCiAgICAgICAgMDAwMURDRTggRDJFQzYxODQgQ0FG
MEE5NzEgNzY5RkIxRjcsDQogICAgaCA9IDEuDQoNCiAgIHNlY3AyMjRyMToNCiAgICBGKHApIHdp
dGgNCiAgICBwID0gMHhGRkZGRkZGRiBGRkZGRkZGRiBGRkZGRkZGRg0KICAgICAgICBGRkZGRkZG
RiAwMDAwMDAwMCAwMDAwMDAwMCAwMDAwMDAwMSwNCiAgICBhID0gcC0zLA0KICAgIGIgPSAweEI0
MDUwQTg1IDBDMDRCM0FCIEY1NDEzMjU2DQogICAgICAgIDUwNDRCMEI3IEQ3QkZEOEJBIDI3MEIz
OTQzIDIzNTVGRkI0LA0KICAgIEcgPSAweDAyIEI3MEUwQ0JEIDZCQjRCRjdGIDMyMTM5MEI5DQoN
ClNjaGVya2wgICAgICAgICAgICAgICAgICAgICBTdGFuZGFyZHMgVHJhY2sgICAgICAgICAgICAg
ICAgICAgIFtQYWdlIDE2XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICBPcGVuUEdQIEVD
QyBGb3JtYXRzICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDAxDQoNCiAgICAgICAgNEEwM0MxRDMg
NTZDMjExMjIgMzQzMjgwRDYgMTE1QzFEMjEsDQogICAgbiA9IDB4RkZGRkZGRkYgRkZGRkZGRkYg
RkZGRkZGRkYNCiAgICAgICAgRkZGRjE2QTIgRTBCOEYwM0UgMTNERDI5NDUgNUM1QzJBM0QsDQog
ICAgaCA9IDEuDQoNCiAgIHByaW1lMjM5djE6DQogICAgRihwKSB3aXRoDQogICAgcCA9IDB4N0ZG
RiBGRkZGRkZGRiBGRkZGRkZGRiBGRkZGN0ZGRg0KICAgICAgICBGRkZGRkZGRiA4MDAwMDAwMCAw
MDAwN0ZGRiBGRkZGRkZGRiwNCiAgICBhID0gcC0zLA0KICAgIGIgPSAweDZCMDEgNkMzQkRDRjEg
ODk0MUQwRDYgNTQ5MjE0NzUNCiAgICAgICAgQ0E3MUE5REIgMkZCMjdEMUQgMzc3OTYxODUgQzI5
NDJDMEEsDQogICAgRyA9IDB4MDIwRkZBIDk2M0NEQ0E4IDgxNkNDQzMzIEI4NjQyQkVEDQogICAg
ICAgIEY5MDVDM0QzIDU4NTczRDNGIDI3RkJCRDNCIDNDQjlBQUFGLA0KICAgIG4gPSAweDdGRkYg
RkZGRkZGRkYgRkZGRkZGRkYgRkZGRjdGRkYNCiAgICAgICAgRkY5RTVFOUEgOUY1RDkwNzEgRkJE
MTUyMjYgODg5MDlEMEIsDQogICAgaCA9IDEuDQoNCiAgIHByaW1lMjM5djI6DQogICAgRihwKSB3
aXRoDQogICAgcCA9IDB4N0ZGRiBGRkZGRkZGRiBGRkZGRkZGRiBGRkZGN0ZGRg0KICAgICAgICBG
RkZGRkZGRiA4MDAwMDAwMCAwMDAwN0ZGRiBGRkZGRkZGRiwNCiAgICBhID0gcC0zLA0KICAgIGIg
PSAweDYxN0YgQUI2ODMyNTcgNkNCQkZFRDUgMEQ5OUYwMjQNCiAgICAgICAgOUMzRkVFNTggQjk0
QkEwMDMgOEM3QUU4NEMgOEM4MzJGMkMsDQogICAgRyA9IDB4MDIzOEFGIDA5RDk4NzI3IDcwNTEy
MEM5IDIxQkI1RTlFDQogICAgICAgIDI2Mjk2QTNDIERDRjJGMzU3IDU3QTBFQUZEIDg3QjgzMEU3
LA0KICAgIG4gPSAweDdGRkYgRkZGRkZGRkYgRkZGRkZGRkYgRkZGRjgwMDANCiAgICAgICAgMDBD
RkE3RTggNTk0Mzc3RDQgMTRDMDM4MjEgQkM1ODIwNjMsDQogICAgaCA9IDEuDQoNCiAgIHByaW1l
MjM5djM6DQogICAgRihwKSB3aXRoDQogICAgcCA9IDB4N0ZGRiBGRkZGRkZGRiBGRkZGRkZGRiBG
RkZGN0ZGRg0KICAgICAgICBGRkZGRkZGRiA4MDAwMDAwMCAwMDAwN0ZGRiBGRkZGRkZGRiwNCiAg
ICBhID0gcC0zLA0KICAgIGIgPSAweDI1NTcgMDVGQTJBMzAgNjY1NEIxRjQgQ0IwM0Q2QTcNCiAg
ICAgICAgNTBBMzBDMjUgMDEwMkQ0OTggODcxN0Q5QkEgMTVBQjZEM0UsDQogICAgRyA9IDB4MDM2
NzY4IEFFOEUxOEJCIDkyQ0ZDRjAwIDVDOTQ5QUEyDQogICAgICAgIEM2RDk0ODUzIEQwRTY2MEJC
IEY4NTRCMUM5IDUwNUZFOTVBLA0KICAgIG4gPSAweDdGRkYgRkZGRkZGRkYgRkZGRkZGRkYgRkZG
RjdGRkYNCiAgICAgICAgRkY5NzVERUIgNDFCM0E2MDUgN0MzQzQzMjEgNDY1MjY1NTEsDQogICAg
aCA9IDE7DQoNCiAgIHNlY3AyNTZrMQ0KICAgIEYocCkgd2l0aA0KICAgIHAgPSAweEZGRkZGRkZG
IEZGRkZGRkZGIEZGRkZGRkZGIEZGRkZGRkZGDQogICAgICAgIEZGRkZGRkZGIEZGRkZGRkZGIEZG
RkZGRkZFIEZGRkZGQzJGLA0KICAgIGEgPSAwLA0KICAgIGIgPSA3LA0KICAgIEcgPSAweDAyIDc5
QkU2NjdFIEY5RENCQkFDIDU1QTA2Mjk1IENFODcwQjA3DQogICAgICAgIDAyOUJGQ0RCIDJEQ0Uy
OEQ5IDU5RjI4MTVCIDE2RjgxNzk4LA0KDQpTY2hlcmtsICAgICAgICAgICAgICAgICAgICAgU3Rh
bmRhcmRzIFRyYWNrICAgICAgICAgICAgICAgICAgICBbUGFnZSAxN10NCgwNCkludGVybmV0LURy
YWZ0ICAgICAgICAgICAgT3BlblBHUCBFQ0MgRm9ybWF0cyAgICAgICAgICAgICAgICBBdWd1c3Qg
MjAwMQ0KDQogICAgbiA9IDB4RkZGRkZGRkYgRkZGRkZGRkYgRkZGRkZGRkYgRkZGRkZGRkUNCiAg
ICAgICAgQkFBRURDRTYgQUY0OEEwM0IgQkZEMjVFOEMgRDAzNjQxNDEsDQogICAgaCA9IDEuDQoN
CiAgIHByaW1lMjU2djEgLyBzZWNwMjU2cjE6DQogICAgRihwKSB3aXRoDQogICAgcCA9IDB4RkZG
RkZGRkYgMDAwMDAwMDEgMDAwMDAwMDAgMDAwMDAwMDANCiAgICAgICAgMDAwMDAwMDAgRkZGRkZG
RkYgRkZGRkZGRkYgRkZGRkZGRkYsDQogICAgYSA9IHAtMywNCiAgICBiID0gMHg1QUM2MzVEOCBB
QTNBOTNFNyBCM0VCQkQ1NSA3Njk4ODZCQw0KICAgICAgICA2NTFEMDZCMCBDQzUzQjBGNiAzQkNF
M0MzRSAyN0QyNjA0QiwNCiAgICBHID0gMHgwMyA2QjE3RDFGMiBFMTJDNDI0N0YgOEJDRTZFNSA2
M0E0NDBGMg0KICAgICAgICA3NzAzN0Q4MSAyREVCMzNBMEYgNEExMzk0NSBEODk4QzI5NiwNCiAg
ICBuID0gMHhGRkZGRkZGRiAwMDAwMDAwMCBGRkZGRkZGRiBGRkZGRkZGRg0KICAgICAgICBCQ0U2
RkFBRCBBNzE3OUU4NCBGM0I5Q0FDMiBGQzYzMjU1MSwNCiAgICBoID0gMS4NCg0KICAgc2VjcDM4
NHIxOg0KICAgIEYocCkgd2l0aA0KICAgIHAgPSAweEZGRkZGRkZGIEZGRkZGRkZGIEZGRkZGRkZG
IEZGRkZGRkZGIEZGRkZGRkZGIEZGRkZGRkZGDQogICAgICAgIEZGRkZGRkZGIEZGRkZGRkZFIEZG
RkZGRkZGIDAwMDAwMDAwIDAwMDAwMDAwIEZGRkZGRkZGLA0KICAgIGEgPSBwLTMsDQogICAgYiA9
IDB4QjMzMTJGQTcgRTIzRUU3RTQgOTg4RTA1NkIgRTNGODJEMTkgMTgxRDlDNkUgRkU4MTQxMTIN
CiAgICAgICAgMDMxNDA4OEYgNTAxMzg3NUEgQzY1NjM5OEQgOEEyRUQxOUQgMkE4NUM4RUQgRDNF
QzJBRUYsDQogICAgRyA9IDB4MDMgQUE4N0NBMjIgQkU4QjA1MzcgOEVCMUM3MUUgRjMyMEFENzQg
NkUxRDNCNjIgOEJBNzlCOTgNCiAgICAgICAgNTlGNzQxRTAgODI1NDJBMzggNTUwMkYyNUQgQkY1
NTI5NkMgM0E1NDVFMzggNzI3NjBBQjcsDQogICAgbiA9IDB4RkZGRkZGRkYgRkZGRkZGRkYgRkZG
RkZGRkYgRkZGRkZGRkYgRkZGRkZGRkYgRkZGRkZGRkYNCiAgICAgICAgQzc2MzREODEgRjQzNzJE
REYgNTgxQTBEQjIgNDhCMEE3N0EgRUNFQzE5NkEgQ0NDNTI5NzMsDQogICAgaCA9IDEuDQoNCiAg
IHNlY3A1MjFyMToNCiAgICBGKHApIHdpdGgNCiAgICBwID0gMHgwMUZGIEZGRkZGRkZGIEZGRkZG
RkZGIEZGRkZGRkZGIEZGRkZGRkZGIEZGRkZGRkZGDQogICAgICAgIEZGRkZGRkZGIEZGRkZGRkZG
IEZGRkZGRkZGIEZGRkZGRkZGIEZGRkZGRkZGIEZGRkZGRkZGDQogICAgICAgIEZGRkZGRkZGIEZG
RkZGRkZGIEZGRkZGRkZGIEZGRkZGRkZGIEZGRkZGRkZGID0gMl41MjEtMSwNCiAgICBhID0gcC0z
LA0KICAgIGIgPSAweDAwNTEgOTUzRUI5NjEgOEUxQzlBMUYgOTI5QTIxQTAgQjY4NTQwRUUgQTJE
QTcyNUINCiAgICAgICAgOTlCMzE1RjMgQjhCNDg5OTEgOEVGMTA5RTEgNTYxOTM5NTEgRUM3RTkz
N0IgMTY1MkMwQkQNCiAgICAgICAgM0JCMUJGMDcgMzU3M0RGODggM0QyQzM0RjEgRUY0NTFGRDQg
NkI1MDNGMDAsDQogICAgRyA9IDB4MDIwMEM2IDg1OEUwNkI3IDA0MDRFOUNEIDlFM0VDQjY2IDIz
OTVCNDQyIDlDNjQ4MTM5DQogICAgICAgIDA1M0ZCNTIxIEY4MjhBRjYwIDZCNEQzREJBIEExNEI1
RTc3IEVGRTc1OTI4IEZFMURDMTI3DQogICAgICAgIEEyRkZBOERFIDMzNDhCM0MxIDg1NkE0MjlC
IEY5N0U3RTMxIEMyRTVCRDY2LA0KICAgIG4gPSAweDAxRkYgRkZGRkZGRkYgRkZGRkZGRkYgRkZG
RkZGRkYgRkZGRkZGRkYgRkZGRkZGRkYNCiAgICAgICAgRkZGRkZGRkYgRkZGRkZGRkYgRkZGRkZG
RkEgNTE4Njg3ODMgQkYyRjk2NkIgN0ZDQzAxNDgNCiAgICAgICAgRjcwOUE1RDAgM0JCNUM5Qjgg
ODk5QzQ3QUUgQkI2RkI3MUUgOTEzODY0MDksDQogICAgaCA9IDEuDQoNCjkuMy4gQ3VydmVzIG92
ZXIgT2RkIEV4dGVuc2lvbiBGaWVsZHMNCg0KICAgQ3VydmVzIG9mIHRoaXMgdHlwZSB3aWxsIGJl
IGFkZGVkIGluIHRoZSBmdXR1cmUuDQoNCg0KDQpTY2hlcmtsICAgICAgICAgICAgICAgICAgICAg
U3RhbmRhcmRzIFRyYWNrICAgICAgICAgICAgICAgICAgICBbUGFnZSAxOF0NCgwNCkludGVybmV0
LURyYWZ0ICAgICAgICAgICAgT3BlblBHUCBFQ0MgRm9ybWF0cyAgICAgICAgICAgICAgICBBdWd1
c3QgMjAwMQ0KDQo5LjQuIEFkZGluZyBPd24gTmFtZWQgQ3VydmVzDQoNCiAgIFRvIHN0b3JlIHNl
bGYgY3JlYXRlZCBuYW1lZCBjdXJ2ZXMsIGltcGxlbWVudGF0aW9ucyBTSE9VTEQgdXNlIHRoZQ0K
ICAgc2FtZSBmb3JtYXQgYXMgZm9yIHB1YmxpYyBrZXlzLCB3aXRoIHRoZSBmb2xsb3dpbmcgY2hh
bmdlczoNCiAgIC0gdGhlIGZpZWxkIGRlc2NyaXB0b3IgRCBNVVNUIE5PVCBoYXZlIHRoZSB2YWx1
ZSAwLA0KICAgLSBubyBwdWJsaWMgcG9pbnQgUSBpcyBjb250YWluZWQuDQogICANCiAgIE93biBu
YW1lZCBjdXJ2ZXMgU0hPVUxEIGJlIHNpZ25lZCBsaWtlIHB1YmxpYyBrZXlzIHRvIGVuc3VyZSB0
aGVpcg0KICAgdmFsaWRpdHkuIEltcGxlbWVudGF0aW9ucyBNQVkgYWRkaXRpb25hbHkgdmFsaWRh
dGUgdGhlbSBvbmNlIHRoZXkNCiAgIHJlY2VpdmUgdGhlbS4NCg0KOS41LiBSZXZvY2VkIEN1cnZl
cw0KDQogICBJdCBtYXkgb2NjdXJlIHRoYXQgZm9yIHNvbWUgbmFtZWQgY3VydmVzIGFscmVhZHkg
aW4gdXNlIHdlYWtuZXNzZXMNCiAgIHdpbGwgYmUgZGlzY292ZXJlZC4gVGhlc2UgY3VydmVzIGFy
ZSBtZW50aW9uZWQgaW4gdGhpcyBzZWN0aW9uIGFuZA0KICAgdGhleSBTSE9VTEQgbm90IGJlIHVz
ZWQgZm9yIGtleSBnZW5lcmF0aW9uIGFueSBmdXJ0aGVyIQ0KICAgDQogICAoVGhpcyBmaXJzdCBk
cmFmdCBpbmNsdWRlcyBubyBjdXJ2ZXMgZm9yIHdoaWNoIHdlYWtuZXNzZXMgYXJlIGtub3duLikg
DQoNCjEwLiBTZWN1dGl0eSBDb25zaWRlcmF0aW9ucw0KDQogICBVc2luZyBFQ0MgcHJvdmlkZXMg
c2hvcnRlciBrZXlzIGF0IHRoZSBzYW1lIHNlY3VyaXR5IGxldmVsIGFzIFJTQSwNCiAgIGJ1dCBp
dCdzIHN0aWxsIG5vdCBzdXJlIHRoYXQgdGhlcmUgd2lsbCBiZSBubyBmYXN0IHBvaW50LWRpdmlz
aW9uDQogICBhbGdvcml0aG0gaW4gdGhlIGZ1dHVyZS4gSG93ZXZlciwgdGhpcyBpcyBhIHByb2Js
ZW0gaW5kZXBlbmRlbnQNCiAgIHRvIGZhY3Rvcml6aW5nIG51bWJlcnMsIHNvIGlmIGVpdGhlciBv
ZiB0aGUgdHdvIGFsZ29yaXRobXMgaXMgYnJva2VuLA0KICAgdGhlIG90aGVyIG1heSBzdGlsbCBi
ZSBjb25zaWRlcmVkIHNlY3VyZS4gVGhpcyBpbmRlZWQgSVMgYW4NCiAgIGltcHJvdmVtZW50IGlu
IHNlY3VyaXR5Lg0KICAgDQogICBTb21lIG9mIHRoZSBudW1iZXIgZmllbGRzIHVzZWQgZm9yIGVs
bGlwdGljIGN1cnZlIGNyeXB0b2dyYXBoeSBoYXZlDQogICBiZWVuIGFuYWx5emVkIGxlc3MgdGhh
biBvdGhlcnMuIEVzcGVjaWFseSBvZGQgZXh0ZW5zaW9uIGZpZWxkcyBiZSBhDQogICB2ZXJ5IG5l
dyByZXNlYXJjaCB0b3BpYywgYWx0aG91Z2ggdGhleSBhcmUgcHJlc2VudGx5IGNvbnNpZGVyZWQN
CiAgIHN0cm9uZy4NCiAgIA0KICAgQW5vdGhlciBwcm9ibGVtIG9mIGVsbGlwdGljIGN1cnZlcyBp
cywgdGhhdCBpbiB0aGUgcGFzdCB3ZWFrIGN1cnZlcw0KICAgaGF2ZSBiZWVuIGRldmVsb3BlZCAo
bGVhZGluZyB0byBjb25kaXRpb25zIGxpa2UgTU9WKSBhbmQgaXQgaXMgbm90DQogICBzdXJlIHRo
YXQgZS5nLiB0aGUgaGVyZSBnaXZlbiBuYW1lZCBjdXJ2ZXMgd2lsbCBiZSBzdHJvbmcgZW5vdWdo
DQogICBpbiB0aGUgZnV0dXJlLg0KICAgDQogICBPZiBjb3Vyc2UsIGFzIGFuIHVwZGF0ZSBvZiBS
RkMgMjQ0MCwgbW9zdCBzZWN1cml0eSBjb25zaWRlcmF0aW9ucw0KICAgbWVudGlvbmVkIHRoZXJl
IGFsc28gYXBwbHkgdG8gdGhpcyBkb2N1bWVudC4gVGhhdCBpczogY2hlY2sgdGhlDQogICBsYXRl
c3QgbGl0YXJhdHVyZSBmb3IgbmV3bHkgZm91bmQgYXR0YWNrczsgYWx3YXlzIGtlZXAgaW4gbWlu
ZCB0aGF0DQogICBhIHNlY3JldCBrZXkgbWF5IG5vdCBiZSBjb250cm9sbGVkIGJ5IHRoZSBwcm9w
ZXIgcGF0cnk7IHNlY3VyaXR5DQogICBkZXBlbmRzIGhpZ2hseSBvbiB0aGUgcmFuZG9tbmVzcyBv
ZiBjZXJ0YWluIHBhcmFtZXRlcnMuDQogICAgIA0KICAgQWxzbyBpdCBpcyBwb3NzaWJsZSB0aGF0
IHVzZXJzIGdlbmVyYXRlIHRoZWlyIG93biBjdXJ2ZXMgd2l0aG91dA0KICAgdmVyaWZ5aW5nIHRo
ZW0gYWdhaW5zdCBhbGwga25vd24gYXR0YWNrcy4gVGhlcmVmb3JlIGltcGxlbWVudGF0aW9ucw0K
ICAgbmVlZCB0byB2ZXJpZnkgdGhlbSBvbiB0aGVpciBvd24sIHdoaWNoIHRha2VzIHRpbWUgKGFu
ZCBsaWtlIGFueXRoaW5nDQogICB0aGF0IHNlZW1zIHRvIGJlIG9ic29sZXRlIG1hbnkgaW1wbGVt
ZW50YXRpb25zIHdvbid0IGRvIGl0IC0gYXMgc2Vlbg0KICAgd2l0aCBvdGhlciBhbGdvcml0aG1z
IHRvbykuDQoNCg0KDQoNClNjaGVya2wgICAgICAgICAgICAgICAgICAgICBTdGFuZGFyZHMgVHJh
Y2sgICAgICAgICAgICAgICAgICAgIFtQYWdlIDE5XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAg
ICAgICBPcGVuUEdQIEVDQyBGb3JtYXRzICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDAxDQoNCjEx
LiBSZWZlcmVuY2VzDQogICANCiAgIFsxXSAgSi4gQ2FsbGFzLCBMLiBEb25uZXJoYWNrZSwgSC4g
RmlubmV5IGFuZCBSLiBUaGF5ZXI6ICJPcGVuUEdQDQogICAgICAgIE1lc3NhZ2UgRm9ybWF0Iiwg
TmV0d29yayBXb3JraW5nIEdyb3VwIFJlcXVlc3QgZm9yIENvbW1lbnRzDQogICAgICAgIDI0NDAs
IE5vdmVtYmVyIDE5OTguDQoNCiAgIFsyXSAgSUVFRSBQMTM2My9EMTMsICJTdGFuZGFyZCBTcGVj
aWZpY2F0aW9ucyBmb3IgUHVibGljIEtleQ0KICAgICAgICBDcnlwdG9ncmFwaHkiLCBJbnN0aXR1
dGUgb2YgRWxlY3RyaWNhbCBhbmQgRWxlY3Ryb25pY3MNCiAgICAgICAgRW5naW5lZXJzLCBOb3Zl
bWJlciAxOTk5Lg0KICAgICAgICANCiAgIFszXSAgQS4gTWVuZXplcywgVC4gT2thbW90byBhbmQg
Uy4gVmFuc3RvbmU6ICJSZWR1Y2luZyBlbGxpcHRpYyBjdXJ2ZQ0KICAgICAgICBsb2dhcml0aG1z
IHRvIGxvZ2FyaXRobXMgaW4gYSBmaW5pdGUgZmllbGQiLCBJRUVFIFRyYW5zYWN0aW9ucw0KICAg
ICAgICBvbiBJbmZvcm1hdGlvbiBUaGVvcnkgMzkgcHAuIDE2MzktMTY0NiwgMTk5My4NCg0KICAg
WzRdICBBTlNJIFg5LjYyLTE5OTksICJQdWJsaWMgS2V5IENyeXB0b2dyYXBoeSBGb3IgVGhlIEZp
bmFuY2lhbA0KICAgICAgICBTZXJ2aWNlcyBJbmR1c3RyeTogVGhlIEVsbGlwdGljIEN1cnZlIERp
Z2l0YWwgU2lnbmF0dXJlIA0KICAgICAgICBBbGdvcml0aG0gKEVDRFNBKSIsIEFtZXJpY2FuIE5h
dGlvbmFsIFN0YW5kYXJkcyBJbnN0aXR1dGUsIDE5OTguDQoNCiAgIFs1XSAgV29ya2luZyBEcmFm
dCBBTlNJIFg5LjYzLCAiUHVibGljIEtleSBDcnlwdG9ncmFwaHkgRm9yIFRoZQ0KICAgICAgICBG
aW5hbmNpYWwgU2VydmljZXMgSW5kdXN0cnk6IEtleSBBZ3JlZW1lbnQgYW5kIEtleSBUcmFuc3Bv
cnQNCiAgICAgICAgdXNpbmcgRWxsaXB0aWMgQ3VydmUgQ3J5cHRvZ3JhcHkgKEVDQykiLCBBTlNJ
LCBKYW51YXJ5IDE5OTkuDQoNCiAgIFs2XSAgU0VDIDIsICJSZWNvbW1lbmRlZCBFbGxpcHRpYyBD
dXJ2ZSBEb21haW4gUGFyYW1ldGVycyIsDQogICAgICAgIFN0YW5kYXJkcyBmb3IgRWZmaWNpZW50
IENyeXB0b2dyYXBoeSBHcm91cCwgMjAwMC4NCg0KICAgWzddICBOaWdlbCBTbWFydCwgRmxvcmlh
biBIZXNzLCBQaWVycmljayBHYXVkcnk6ICJDb25zdHJ1Y3RpdmUgYW5kDQogICAgICAgIERlc3Ry
dWN0aXZlIEZhY2V0cyBvZiBXZWlsIERlc2NlbnQgb24gRWxsaXB0aWMgQ3VydmVzIiwgVHJ1c3Rl
ZA0KICAgICAgICBlLVNlcnZpY2VzIGF0IEhQIExhYm9yYXRvcmllcyBCcmlzdG9sLCBKYW51YXJ5
IDIwMDAuDQogICAgICAgIA0KICAgWzhdICBTLiBCcmFkbmVyOiAiS2V5IHdvcmRzIGZvciB1c2Ug
aW4gUkZDcyB0byBJbmRpY2F0ZSBSZXF1aXJlbWVudA0KICAgICAgICBMZXZlbHMiLCBOZXR3b3Jr
IFdvcmtpbmcgR3JvdXAgUkZDIDIxMTksIE1hcmNoIDE5OTcuDQoNCjEyLiBBdXRob3JzDQoNCiAg
IERvbWluaWt1cyBTY2hlcmtsDQogICBCaW9kYXRhIEFwcGxpY2F0aW9uIFNlY3VyaXR5IEFHDQog
ICBDaHJpc3RpYW4tUGxlc3MtU3RyLiAxMS0xMw0KICAgNjMwNjkgT2ZmZW5iYWNoLCBHZXJtYW55
DQogICBFTWFpbDogZG9taW5pa3VzLnNjaGVya2xAYmlvZGF0YS5jb20NCiAgIFBob25lOiArNDkg
KDApIDY5IC8gODAwIDcwNiAtIDANCg0KICAgQ28tQXV0aG9yOg0KDQogICBDaHJpc3RvcGggRmF1
c2FrDQogICBCaW9kYXRhIEFwcGxpY2F0aW9uIFNlY3VyaXR5IEFHDQogICBFTWFpbDogY2hyaXN0
b3BoLmZhdXNha0BiaW9kYXRhLmNvbQ0KDQoNCg0KDQoNCg0KDQpTY2hlcmtsICAgICAgICAgICAg
ICAgICAgICAgU3RhbmRhcmRzIFRyYWNrICAgICAgICAgICAgICAgICAgICBbUGFnZSAyMF0NCg==

------_=_NextPart_001_01C11F43.5DDB79E8--


Received: by above.proper.com (8.11.3/8.11.3) id f77BYv100351 for ietf-openpgp-bks; Tue, 7 Aug 2001 04:34:57 -0700 (PDT)
Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.65.64]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f77BYtN00347 for <[e-mail]>; Tue, 7 Aug 2001 04:34:55 -0700 (PDT)
Received: from [62.188.13.106] (vpnap-g1-012013.qualcomm.com [10.13.12.13]) by mage.qualcomm.com (8.11.3/8.11.3/1.0) with ESMTP id f77BYrT17557 for <[e-mail]>; Tue, 7 Aug 2001 04:34:54 -0700 (PDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100101b7949ae9540e@[217.33.140.52]>
X-Mailer: eudora51-ffc10713011434
X-PGP-RSA-Fingerprint: EA53 01A6 C076 F9C2  09E8 9480 645A 8857
X-PGP-DH-Fingerprint: 4F5E 56C9 BD4D 0227 331F 6AEE 9590 24F9 6FD7 04F8
Date: Tue, 7 Aug 2001 12:34:48 +0100
To: OpenPGP mailing list <[e-mail]>
From: John  W Noerenberg II <[e-mail]>
Subject: interop testing
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Rod Thayer, Ben Laurie, Ian Brown, Fearghas Mckay and I had the 
opportunity yesterday for a brief bar BOF at the IETF meeting this 
week in London to discuss interoperability testing.

We discussed what's necessary for testing to take place, and how to 
get ready for the tests.  I still plan to host the testing at 
Qualcomm, however, it will certainly be a virtual meeting, as I don't 
expect everyone who wants to participate to be able to come to San 
Diego.

If you have particular thoughts about interop testing, please don't 
hesitate to post them to the list.  If you are in London, and would 
like to discuss this in person, please let me know!

As a plan solidifies, I'll make sure the plan is published on the the 
list before we proceed.



-- 

john noerenberg
[e-mail]
   --------------------------------------------------------------------------
   Peace of mind isn't at all superficial, really.  It's the whole thing.
   That which produces it is good maintenance; that which disturbs it
   is poor maintenance.
   -- Zen and the Art of Motorcycle Maintenance, Robert M. Pirsig, 1974
   --------------------------------------------------------------------------


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f75DTPh07058 for ietf-openpgp-bks; Sun, 5 Aug 2001 06:29:25 -0700 (PDT)
Received: from mail.arcor-ip.de (mail.arcor-ip.de [145.253.2.10] (may be forged)) by above.proper.com (8.11.3/8.11.3) with ESMTP id f75DTNs07054 for <[e-mail]>; Sun, 5 Aug 2001 06:29:23 -0700 (PDT)
Received: from localhost (145.254.156.152) by mail.arcor-ip.de (5.5.034) id 3B6C54370000EC98 for [e-mail]; Sun, 5 Aug 2001 15:28:54 +0200
Received: by localhost (Postfix, from userid 500) id 57B2749; Sun,  5 Aug 2001 15:32:39 +0200 (CEST)
Date: Sun, 5 Aug 2001 15:32:39 +0200
From: Ingo Luetkebohle <[e-mail]>
To: [e-mail]
Subject: About User-ID's
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="Nq2Wo0NMKNjxTN9z"
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Organization: Maybe when I grow up
X-URL: http://blank.pages.de/
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

--Nq2Wo0NMKNjxTN9z
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hello,

I would like to suggest an RFC or other document about best current
practices regarding User-ID's.

In that, a thorough re-evaluation of the current situation should be
done, possibly based upon previous works, if there are any (I'm not
aware of that, if anyone is, I'd be happy about a pointer).=20

The reason for all this is that I see several problems with the way
User-ID's are used on OpenPGP implementations right now. Immediately
obvious is the spam problem because User-ID's contain e-mail addresses
and people are encouraged to upload their keys to keyservers, which
are searchable by all but also the uniqueness problem (people have
multiple addresses and I'm not of the opinion that listing them all is
the solution) and the problem of anonymity.

What does the working group think? Are the abovementioned problems
irrelevant in your opinion or, if not, would you agree that a document
about User-ID's would be a good start at solving them?

Looking forward to your input!

--=20
	Ingo Luetkebohle / [e-mail] / 95428014
/
| Student of Computational Linguistics & Computer Science;
| Fargonauten.DE sysadmin; Gimp Registry maintainer;
| FP: 3187 4DEC 47E6 1B1E 6F4F  57D4 CD90 C164 34AD CE5B

--Nq2Wo0NMKNjxTN9z
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Weitere Infos: siehe http://www.gnupg.org

iEYEAREBAAYFAjttSvcACgkQzZDBZDStzlsjiACeMJdcMSu/qpMZvkVmxwS2czKy
GkcAn0moFZzGXwIKDbyxR88S2yoEN3gB
=w++6
-----END PGP SIGNATURE-----

--Nq2Wo0NMKNjxTN9z--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f73KFiA01828 for ietf-openpgp-bks; Fri, 3 Aug 2001 13:15:44 -0700 (PDT)
Received: from mail.arcor-ip.de (mail.arcor-ip.de [145.253.2.10] (may be forged)) by above.proper.com (8.11.3/8.11.3) with ESMTP id f73KFgs01821 for <[e-mail]>; Fri, 3 Aug 2001 13:15:42 -0700 (PDT)
Received: from localhost (145.254.158.85) by mail.arcor-ip.de (5.5.034) id 3B6A7BF100012C15; Fri, 3 Aug 2001 22:15:36 +0200
Received: by localhost (Postfix, from userid 500) id C855B49; Fri,  3 Aug 2001 22:19:04 +0200 (CEST)
Date: Fri, 3 Aug 2001 22:19:04 +0200
From: Ingo Luetkebohle <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: ElGamal signature values?
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="5mCyUwZo2JvN/JJP"
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Organization: Maybe when I grow up
X-URL: http://blank.pages.de/
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

--5mCyUwZo2JvN/JJP
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hello,

I couldn't find a specification for ElGamal signature values in the
RFC or the current (bis-02) draft, even though the current draft
mentions the possibility of such signatures in section 12.5 and gpg
seems to support them.

It would seem logical to use the same values as for public-key
encrypted session keys. Is that correct? Is that what gpg does or is
there something else I need to know?

If its just that I've been too dumb to find the right section in the
spec, pointers are very appreciated :)

Regards

--=20
	Ingo Luetkebohle / [e-mail] / 95428014
/
| Student of Computational Linguistics & Computer Science;
| Fargonauten.DE sysadmin; Gimp Registry maintainer;
| FP: 3187 4DEC 47E6 1B1E 6F4F  57D4 CD90 C164 34AD CE5B

--5mCyUwZo2JvN/JJP
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Weitere Infos: siehe http://www.gnupg.org

iEYEAREBAAYFAjtrBzgACgkQzZDBZDStzlvQmwCffiJ7pfIkTr8BmcSK2DKJpSid
Gd0AoKq2oSapvCqMI1g9iK2Chz5NKN4U
=gLDI
-----END PGP SIGNATURE-----

--5mCyUwZo2JvN/JJP--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f737CDJ22481 for ietf-openpgp-bks; Fri, 3 Aug 2001 00:12:13 -0700 (PDT)
Received: from kasiski.gnupg.de (porta.u64.de [194.77.88.106]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f737C6s22461 for <[e-mail]>; Fri, 3 Aug 2001 00:12:07 -0700 (PDT)
Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.22 #1 (Debian)) id 15SZvQ-00026i-00; Fri, 03 Aug 2001 10:03:16 +0200
Received: from wk by alberti.gnupg.de with local (Exim 3.22 #1 (Debian)) id 15SZ8a-0000N9-00; Fri, 03 Aug 2001 09:12:48 +0200
To: Jon Callas <[e-mail]>
Cc: John Kane <[e-mail]>, [e-mail]
Subject: Re: Forbidding 8bit text in Armor comments
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <p0510030eb78baa852bef@[63.73.97.189]> <[e-mail]> <p05100300b78bd8b700ac@[63.73.97.189]> <[e-mail]> <[e-mail]> <[e-mail]>
From: Werner Koch <[e-mail]>
Organisation: g10 Code GmbH
X-PGP-KeyID: 621CC013
X-Request-PGP: finger:[e-mail]
Date: 03 Aug 2001 09:12:47 +0200
In-Reply-To: <[e-mail]> (Thomas Roessler's message of "Fri, 3 Aug 2001 00:58:34 +0200")
Message-ID: <[e-mail]>
Lines: 14
User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Fri, 3 Aug 2001 00:58:34 +0200, Thomas Roessler said:

> Correction:  I mis-remembered this from the last time I looked at that
> code.  Thanks to John Kane for telling me that I was wrong about this,
> and apologies to Werner.

Anyway, I removed the default comment string, I don't think it does
make sense anymore.  --comment '' still works of course.


-- 
Werner Koch        Omnis enim res, quae dando non deficit, dum habetur
g10 Code GmbH      et non datur, nondum habetur, quomodo habenda est.
Privacy Solutions                                        -- Augustinus



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f72Mwqg01324 for ietf-openpgp-bks; Thu, 2 Aug 2001 15:58:52 -0700 (PDT)
Received: from smtp1.nikoma.de (smtp1.nikoma.de [212.122.128.19]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f72Mwos01318 for <[e-mail]>; Thu, 2 Aug 2001 15:58:50 -0700 (PDT)
Received: from sobolev.does-not-exist.org (dialin82.pg2-nt.dusseldorf.nikoma.de [213.54.97.82]) by smtp1.nikoma.de (8.9.3/8.9.3) with ESMTP id AAA25087; Fri, 3 Aug 2001 00:58:35 +0200 (CEST) (envelope-from [e-mail])
Received: by sobolev.does-not-exist.org (Postfix, from userid 1000) id 932B32ED15; Fri,  3 Aug 2001 00:58:34 +0200 (CEST)
Date: Fri, 3 Aug 2001 00:58:34 +0200
From: Thomas Roessler <[e-mail]>
To: Werner Koch <[e-mail]>, Jon Callas <[e-mail]>, John Kane <[e-mail]>, [e-mail]
Subject: Re: Forbidding 8bit text in Armor comments
Message-ID: <[e-mail]>
Mail-Followup-To: Werner Koch <[e-mail]>, Jon Callas <[e-mail]>, John Kane <[e-mail]>, [e-mail]
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <p0510030eb78baa852bef@[63.73.97.189]> <[e-mail]> <p05100300b78bd8b700ac@[63.73.97.189]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.3.20i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On 2001-08-02 19:41:52 +0200, Thomas Roessler wrote:

>BTW, it would be nice if it was possible to entirely disable that 
>header with gnupg, which doesn't seem to be the case.

Correction:  I mis-remembered this from the last time I looked at 
that code.  Thanks to John Kane for telling me that I was wrong 
about this, and apologies to Werner.

-- 
Thomas Roessler                        http://log.does-not-exist.org/




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f72It4v25237 for ietf-openpgp-bks; Thu, 2 Aug 2001 11:55:04 -0700 (PDT)
Received: from mail.vi-internet.de (proxy2.vi-internet.de [195.182.114.6]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f72It2s25232 for <[e-mail]>; Thu, 2 Aug 2001 11:55:02 -0700 (PDT)
Received: from sobolev.does-not-exist.org ([62.180.209.3]) by mail.vi-internet.de  with Microsoft SMTPSVC(5.5.1877.537.53); Thu, 2 Aug 2001 19:45:15 +0200
Received: by sobolev.does-not-exist.org (Postfix, from userid 1000) id 8B0DC2ED15; Thu,  2 Aug 2001 19:41:52 +0200 (CEST)
Date: Thu, 2 Aug 2001 19:41:52 +0200
From: Thomas Roessler <[e-mail]>
To: Werner Koch <[e-mail]>
Cc: Jon Callas <[e-mail]>, John Kane <[e-mail]>, [e-mail]
Subject: Re: Forbidding 8bit text in Armor comments
Message-ID: <[e-mail]>
Mail-Followup-To: Werner Koch <[e-mail]>, Jon Callas <[e-mail]>, John Kane <[e-mail]>, [e-mail]
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <p0510030eb78baa852bef@[63.73.97.189]> <[e-mail]> <p05100300b78bd8b700ac@[63.73.97.189]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.3.20i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On 2001-07-31 09:39:15 +0200, Werner Koch wrote:

>The solution is to use "gpg --comment '' ..." to disable the armor 
>commentline or use sed to cut it out later.

That's of course what I have added to mutt's default gnupg
configuration now.  BTW, it would be nice if it was possible to 
entirely disable that header with gnupg, which doesn't seem to be 
the case.

>So it is definitely not a standard problem.

I disagree.

It should be possible to rely upon the ASCII-armored text OpenPGP 
applications generate when creating e-mail messages or anything else 
which is supposed to cross system boundaries.  Armor should for that 
reason be invariant and robust under the usual kinds of character 
set conversions and corruptions.

After all, that's the entire point of ASCII-armor...

-- 
Thomas Roessler                        http://log.does-not-exist.org/


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f72IU9N24700 for ietf-openpgp-bks; Thu, 2 Aug 2001 11:30:09 -0700 (PDT)
Received: from mail.vi-internet.de (proxy2.vi-internet.de [195.182.114.6]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f72IU7s24696 for <[e-mail]>; Thu, 2 Aug 2001 11:30:07 -0700 (PDT)
Received: from sobolev.does-not-exist.org ([62.180.210.92]) by mail.vi-internet.de  with Microsoft SMTPSVC(5.5.1877.537.53); Thu, 2 Aug 2001 19:26:15 +0200
Received: by sobolev.does-not-exist.org (Postfix, from userid 1000) id 4A23D2ED15; Thu,  2 Aug 2001 19:26:03 +0200 (CEST)
Date: Thu, 2 Aug 2001 19:26:03 +0200
From: Thomas Roessler <[e-mail]>
To: Ian Bell <[e-mail]>
Cc: [e-mail]
Subject: Re: Forbidding 8bit text in Armor comments
Message-ID: <[e-mail]>
Mail-Followup-To: Ian Bell <[e-mail]>, [e-mail]
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <p0510030eb78baa852bef@[63.73.97.189]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.3.20i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On 2001-08-02 17:25:49 +0100, Ian Bell wrote:

>If utf-8 is allowed in Comments then RFC2015bis will need to be 
>amended (if it hasn't got through last call yet) to tell clients 
>what to do with it before sending.

It has gone through last call.

>Double encoding is not a sensible option

No, of course not.

>- either say RFC2015bis clients MUST NOT include comments lines 
>with utf-8 characters, or say that RFC2015bis clients MAY drop 
>utf-8 comments lines, but if they don't they MUST RFC2047 encode 
>them.

This is plain silliness - just like double encoding. We are talking 
about a comment which is:

- hardly ever read by users, because it's not even on the 
   application layer
- mostly used to advertise the program which is used for generating 
   it to those who wonder what kind of "data junk" they are 
   receiving
- is not cryptographically protected
- and, when using utf-8 text, breaks assumptions which have been 
   made for years now, and, in fact, breaks the whole point ASCII 
   armor was designed for

The discussion we are having here is basically equivalent to 
discussing internationalization of SMTP greetings or User-Agent 
headers.

If you ask me, I'd just suggest to drop the Comment armor header. 
Since that's probably not an option, castrate it to 7bit characters.

-- 
Thomas Roessler                        http://log.does-not-exist.org/


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f727uOB19757 for ietf-openpgp-bks; Thu, 2 Aug 2001 00:56:24 -0700 (PDT)
Received: from kasiski.gnupg.de (porta.u64.de [194.77.88.106]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f727uLs19752 for <[e-mail]>; Thu, 2 Aug 2001 00:56:21 -0700 (PDT)
Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.22 #1 (Debian)) id 15SE8M-0007r4-00; Thu, 02 Aug 2001 10:47:10 +0200
Received: from wk by alberti.gnupg.de with local (Exim 3.22 #1 (Debian)) id 15SDL6-0007Xx-00; Thu, 02 Aug 2001 09:56:16 +0200
To: [e-mail]
Cc: [e-mail]
Subject: Re: Setting default UID
References: <[e-mail]>
From: Werner Koch <[e-mail]>
Organisation: g10 Code GmbH
X-PGP-KeyID: 621CC013
X-Request-PGP: finger:[e-mail]
Date: 02 Aug 2001 09:56:16 +0200
In-Reply-To: <[e-mail]> (Len Sassaman's message of "Wed, 1 Aug 2001 11:42:52 -0700 (PDT)")
Message-ID: <[e-mail]>
Lines: 27
User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Wed, 1 Aug 2001 11:42:52 -0700 (PDT), Len Sassaman said:

> www.ietf.org.
> It's the current internet draft.

BTW, it has expired:

Network Working Group                                        Jon Callas
Category: INTERNET-DRAFT                  Counterpane Internet Security
draft-ietf-openpgp-rfc2440bis-02.txt
Expires Apr 2001                                       Lutz Donnerhacke
October 2000                         IN-Root-CA Individual Network e.V.

and I am eagerly waiting for the schedule of the interoperability test
which have been announced for "early summer".  Given the 30 Celsius we
have for a week now here in Gemrany, I am pretty sure that early
summer already passed by - well maybe it was a statement from down
under ;-)

Ciao,

  Werner

-- 
Werner Koch        Omnis enim res, quae dando non deficit, dum habetur
g10 Code GmbH      et non datur, nondum habetur, quomodo habenda est.
Privacy Solutions                                        -- Augustinus