From nobody Thu Sep 5 08:19:31 2019 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48AD81200F9 for ; Thu, 5 Sep 2019 08:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=infineon.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oD3JNBHIgkIY for ; Thu, 5 Sep 2019 08:19:28 -0700 (PDT) Received: from smtp2.infineon.com (smtp2.infineon.com [IPv6:2a00:18f0:1e00:4::4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 396A8120046 for ; Thu, 5 Sep 2019 08:19:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=infineon.com; i=@infineon.com; q=dns/txt; s=IFXMAIL; t=1567696768; x=1599232768; h=from:to:cc:subject:date:message-id:mime-version; bh=wLaBZgxcMPuopkpf+tuSOsy58+1m7pLfwo4RtqYNNdM=; b=QajgCAgq6NPzsX0M346XuYJMHcNxowKROAtl9zfhITSkAhlhk2W2Rtqn P6mBR6MInzWVzBLiau4vsF5HGiGPOqhkGo6htL4c3PFlJx7grm9rl1rQs 4xx6WuVHxrWbDcuZoEKj+tKpIhVWn7lvYg0PGLvPKnI3WCHi+G7YQTkD+ w=; IronPort-SDR: kh+ktmcR75usQr/Msn9UMzWN3sRCZwqCZ03dU/rvMGFayQ1hKjIBvndOYlkVDUvUcE7s1qSiag VXnT0upAlH7A== X-SBRS: None X-IronPort-AV: E=McAfee;i="6000,8403,9370"; a="11855122" X-IronPort-AV: E=Sophos; i="5.64,470,1559512800"; d="scan'208,217"; a="11855122" Received: from unknown (HELO mucxv002.muc.infineon.com) ([172.23.11.17]) by smtp2.infineon.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Sep 2019 17:19:25 +0200 Received: from MUCSE708.infineon.com (MUCSE708.infineon.com [172.23.7.82]) by mucxv002.muc.infineon.com (Postfix) with ESMTPS; Thu, 5 Sep 2019 17:19:25 +0200 (CEST) Received: from MUCSE701.infineon.com (172.23.7.90) by MUCSE708.infineon.com (172.23.7.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1713.5; Thu, 5 Sep 2019 17:19:25 +0200 Received: from MUCSE707.infineon.com (172.23.7.81) by MUCSE701.infineon.com (172.23.7.90) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1713.5; Thu, 5 Sep 2019 17:19:25 +0200 Received: from MUCSE707.infineon.com ([fe80::e599:a749:53f5:64a1]) by MUCSE707.infineon.com ([fe80::e599:a749:53f5:64a1%17]) with mapi id 15.01.1713.008; Thu, 5 Sep 2019 17:19:24 +0200 From: To: CC: Thread-Topic: Certificate Encoding Questions Thread-Index: AdVj/No4WD0mhQIeRjm/+bbI1YgSBA== Date: Thu, 5 Sep 2019 15:19:24 +0000 Message-ID: <5eec7483c95247cb8968752588ff09f2@infineon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.23.8.247] Content-Type: multipart/alternative; boundary="_000_5eec7483c95247cb8968752588ff09f2infineoncom_" MIME-Version: 1.0 Archived-At: Subject: [pkix] Certificate Encoding Questions X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2019 15:19:30 -0000 --_000_5eec7483c95247cb8968752588ff09f2infineoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have a few simple questions about ASN.1 encoding for X.509 certificates. = Can you help? 1) The KeyUsage extension includes a BIT STRING. Is this encoded so th= at the most significant bit in the DER encoded value is bit 0 (digitalSigna= ture)? After looking at a few certificates, that seems to be true but I wan= t to verify. 2) RFC 5754 says that when the algorithm OID in an AlgorithmIdentifier= structure is sha256WithRSAEncryption, the parameters MUST be NULL. Would t= hat NULL value encode to an additional 05 00 at the end of the SEQUENCE? Ag= ain, I observe this to be true but I want to verify it. Please keep Ken Goldman on the cc list for responses, if possible. Thanks, Steve --_000_5eec7483c95247cb8968752588ff09f2infineoncom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have a few simple questions about ASN.1 encoding f= or X.509 certificates. Can you help?

 

1)      The KeyUsage extension includes a BIT STRING. Is th= is encoded so that the most significant bit in the DER encoded value is bit= 0 (digitalSignature)? After looking at a few certificates, that seems to b= e true but I want to verify.

2)      RFC 5754 says that when the algorithm OID in an Alg= orithmIdentifier structure is sha256WithRSAEncryption, the parameters MUST = be NULL. Would that NULL value encode to an additional 05 00 at the end of = the SEQUENCE? Again, I observe this to be true but I want to verify it.

 

Please keep Ken Goldman on the cc list for responses= , if possible.

 

Thanks,

 

Steve

 

--_000_5eec7483c95247cb8968752588ff09f2infineoncom_-- From nobody Thu Sep 5 09:10:01 2019 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34C1A12096F for ; Thu, 5 Sep 2019 09:10:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ns-4f92McuTq for ; Thu, 5 Sep 2019 09:09:59 -0700 (PDT) Received: from mail-ed1-f47.google.com (mail-ed1-f47.google.com [209.85.208.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A623012097C for ; Thu, 5 Sep 2019 09:09:58 -0700 (PDT) Received: by mail-ed1-f47.google.com with SMTP id p2so2054793edx.11 for ; Thu, 05 Sep 2019 09:09:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6s87+fcewJdyna6F7HmjjmZCqaplwpv8txG+eSbFFkg=; b=COsmKF+DmZ37Egef/9AlXl8w9bc2VbqOI9o3dKhhj9rtjTtm0K2MAfvGvB/h+yWMaE PcwjDkFe2UJo1lA3fPP2xbIWf46uImSrXU9TSK8zwBhpj7AtrUuQgBW2p35HhISynmWE gkqdY2wlncMJjatz0PuwtkVkOBdaj5Sl9MwywV6CXTk8ULoRB4QOWtB75tK2MaGzCc69 EIZcK01uqysAAR/4ZTMl+Oy0uhMt8YB4zUjb3xanS/0fh+yRuZZVr7KNlR9IUmVQfSOY lOfPu7EOesL0ei05DYOaOLNEt/dV4XwSc1xUo2BPAv/LRjGFP7zBc+Jkn9zsEfa7cOss Yr/w== X-Gm-Message-State: APjAAAU5Q91Z6yAK5i4O6jNQalrCRptxu11suLHHzNrB11jrMJ5Cjh9/ LfPkvjroRJ0y4gZ26mvfj7KRdeZU X-Google-Smtp-Source: APXvYqw8O6al5TJQaic+TSqzcanqVM69NiezrtONrtFh68jXh2civr525O+Rx1BpOTGe7txCDqxG2g== X-Received: by 2002:a17:906:b211:: with SMTP id p17mr3463518ejz.11.1567699796747; Thu, 05 Sep 2019 09:09:56 -0700 (PDT) Received: from mail-wm1-f45.google.com (mail-wm1-f45.google.com. [209.85.128.45]) by smtp.gmail.com with ESMTPSA id j2sm279979ejj.34.2019.09.05.09.09.55 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 05 Sep 2019 09:09:56 -0700 (PDT) Received: by mail-wm1-f45.google.com with SMTP id r195so3775504wme.2 for ; Thu, 05 Sep 2019 09:09:55 -0700 (PDT) X-Received: by 2002:a1c:a8cb:: with SMTP id r194mr3574868wme.156.1567699795703; Thu, 05 Sep 2019 09:09:55 -0700 (PDT) MIME-Version: 1.0 References: <5eec7483c95247cb8968752588ff09f2@infineon.com> In-Reply-To: <5eec7483c95247cb8968752588ff09f2@infineon.com> From: Ryan Sleevi Date: Thu, 5 Sep 2019 12:09:44 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Steve.Hanna@infineon.com Cc: IETF PKIX , kgoldman@us.ibm.com Content-Type: multipart/alternative; boundary="0000000000007001c60591d08dcb" Archived-At: Subject: Re: [pkix] Certificate Encoding Questions X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2019 16:10:00 -0000 --0000000000007001c60591d08dcb Content-Type: text/plain; charset="UTF-8" On Thu, Sep 5, 2019 at 11:19 AM wrote: > I have a few simple questions about ASN.1 encoding for X.509 certificates. > Can you help? > > > > 1) The KeyUsage extension includes a BIT STRING. Is this encoded so > that the most significant bit in the DER encoded value is bit 0 > (digitalSignature)? After looking at a few certificates, that seems to be > true but I want to verify. > X.690 addresses this, as that describes how DER encoding (and BER encoding) work on the wire. In X.690 (08/15), the relevant clause will be 8.6.2.1 (for the general BER encoding) and 11.2 for the further DER modifications. > 2) RFC 5754 says that when the algorithm OID in an > AlgorithmIdentifier structure is sha256WithRSAEncryption, the parameters > MUST be NULL. Would that NULL value encode to an additional 05 00 at the > end of the SEQUENCE? Again, I observe this to be true but I want to verify > it. > Yes. Omission would have been specified by "MUST be absent.". This is perhaps more obvious in RFC 5912, which provides an explicit ASN.1 module that captures these encoding requirements (specifically, see Section 8, ASN.1 Module for RFC 4055) --0000000000007001c60591d08dcb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Sep 5, 2019 at 11:19 AM <<= a href=3D"mailto:Steve.Hanna@infineon.com">Steve.Hanna@infineon.com>= wrote:

I have a few simple questions about ASN.1 encoding f= or X.509 certificates. Can you help?

=C2=A0

1)=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 The KeyUsage extension includes a BIT STRING. Is this = encoded so that the most significant bit in the DER encoded value is bit 0 = (digitalSignature)? After looking at a few certificates, that seems to be t= rue but I want to verify.


X= .690 addresses this, as that describes how DER encoding (and BER encoding) = work on the wire.

In X.690 (08/15), the relevant c= lause will be 8.6.2.1 (for the general BER encoding) and 11.2 for the furth= er DER modifications.
=C2=A0

2)=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 RFC 5754 says that when the algorithm OID in an Algori= thmIdentifier structure is sha256WithRSAEncryption, the parameters MUST be = NULL. Would that NULL value encode to an additional 05 00 at the end of the= SEQUENCE? Again, I observe this to be true but I want to verify it.

Yes. = Omission would have been specified by "MUST be absent.".

This is perhaps more obvious in RFC 5912, which provides a= n explicit ASN.1 module that captures these encoding requirements (specific= ally, see Section 8, ASN.1 Module for RFC 4055)
=C2=A0
--0000000000007001c60591d08dcb-- From nobody Thu Sep 5 10:45:49 2019 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 816C01200E5 for ; Thu, 5 Sep 2019 10:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.298 X-Spam-Level: X-Spam-Status: No, score=-4.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=infineon.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uH38QAQJ5Rai for ; Thu, 5 Sep 2019 10:45:45 -0700 (PDT) Received: from smtp2.infineon.com (smtp2.infineon.com [IPv6:2a00:18f0:1e00:4::4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A1AF1200D6 for ; Thu, 5 Sep 2019 10:45:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=infineon.com; i=@infineon.com; q=dns/txt; s=IFXMAIL; t=1567705545; x=1599241545; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=DUP6w+Nzkx9FjE6OeXHLdut/eXEFeZUB8+LW9e7pq2c=; b=J1XbzoN6+RsyWT+PQubqvn38cJWiYCBVGXnaurgYNVTYZITLL5yzmmqw sQrgJ6gdMu1QvZFQYug0be4L4nywoQScCDk8FyPL+bKDOVy98nO/VmiR+ Bq7l6oeSjpIx1bb8P92SCHv1F8dxQDREaQXf8WdoQbqGS01PoMsxDxjZw M=; IronPort-SDR: VYhZ6n1obFy45056RWDeAj25Ha0naUibzhywLzsb9yFJby8ZA18grgmtCteaHHW2Yu/q3QI9ho IZ259ZUPfy8A== X-SBRS: None X-IronPort-AV: E=McAfee;i="6000,8403,9371"; a="11867060" X-IronPort-AV: E=Sophos; i="5.64,470,1559512800"; d="scan'208,217"; a="11867060" Received: from unknown (HELO mucxv002.muc.infineon.com) ([172.23.11.17]) by smtp2.infineon.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Sep 2019 19:45:41 +0200 Received: from MUCSE707.infineon.com (MUCSE707.infineon.com [172.23.7.81]) by mucxv002.muc.infineon.com (Postfix) with ESMTPS; Thu, 5 Sep 2019 19:45:41 +0200 (CEST) Received: from MUCSE702.infineon.com (172.23.7.91) by MUCSE707.infineon.com (172.23.7.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1713.5; Thu, 5 Sep 2019 19:45:41 +0200 Received: from MUCSE707.infineon.com (172.23.7.81) by MUCSE702.infineon.com (172.23.7.91) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1713.5; Thu, 5 Sep 2019 19:45:41 +0200 Received: from MUCSE707.infineon.com ([fe80::e599:a749:53f5:64a1]) by MUCSE707.infineon.com ([fe80::e599:a749:53f5:64a1%17]) with mapi id 15.01.1713.008; Thu, 5 Sep 2019 19:45:40 +0200 From: To: CC: , Thread-Topic: [pkix] Certificate Encoding Questions Thread-Index: AdVj/No4WD0mhQIeRjm/+bbI1YgSBP//7W0A///G0cA= Date: Thu, 5 Sep 2019 17:45:40 +0000 Message-ID: References: <5eec7483c95247cb8968752588ff09f2@infineon.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.23.8.247] Content-Type: multipart/alternative; boundary="_000_f0ae2bd5921d40a68cbae00730a5b04einfineoncom_" MIME-Version: 1.0 Archived-At: Subject: Re: [pkix] Certificate Encoding Questions X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2019 17:45:48 -0000 --_000_f0ae2bd5921d40a68cbae00730a5b04einfineoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UnlhbiwNCg0KVGhhbmtzIGZvciB5b3VyIHF1aWNrIHJlc3BvbnNlLg0KDQpJIGp1c3QgZG93bmxv YWRlZCBYLjY5MCBhbmQgYWxzbyBYLjY4MCBiZWNhdXNlIHRoYXQgc2VlbXMgdG8gYmUgYWxzbyBu ZWNlc3NhcnkgdG8gYW5zd2VyIG15IHF1ZXN0aW9uIDEpLiBNeSBjb25jbHVzaW9uIGlzIHRoYXQg dGhlIGFuc3dlciB0byBxdWVzdGlvbiAxKSBpcyDigJxZZXPigJ0uIFJpZ2h0Pw0KDQpUaGFua3Ms DQoNClN0ZXZlDQoNCkZyb206IFJ5YW4gU2xlZXZpIDxyeWFuLWlldGZAc2xlZXZpLmNvbT4NClNl bnQ6IFRodXJzZGF5LCBTZXB0ZW1iZXIgNSwgMjAxOSAxMjoxMCBQTQ0KVG86IEhhbm5hIFN0ZXZl IChJRkFNIERTUyBTTUQgQU1SKSA8U3RldmUuSGFubmFAaW5maW5lb24uY29tPg0KQ2M6IElFVEYg UEtJWCA8cGtpeEBpZXRmLm9yZz47IGtnb2xkbWFuQHVzLmlibS5jb20NClN1YmplY3Q6IFJlOiBb cGtpeF0gQ2VydGlmaWNhdGUgRW5jb2RpbmcgUXVlc3Rpb25zDQoNCg0KDQpPbiBUaHUsIFNlcCA1 LCAyMDE5IGF0IDExOjE5IEFNIDxTdGV2ZS5IYW5uYUBpbmZpbmVvbi5jb208bWFpbHRvOlN0ZXZl Lkhhbm5hQGluZmluZW9uLmNvbT4+IHdyb3RlOg0KSSBoYXZlIGEgZmV3IHNpbXBsZSBxdWVzdGlv bnMgYWJvdXQgQVNOLjEgZW5jb2RpbmcgZm9yIFguNTA5IGNlcnRpZmljYXRlcy4gQ2FuIHlvdSBo ZWxwPw0KDQoNCjEpICAgICAgVGhlIEtleVVzYWdlIGV4dGVuc2lvbiBpbmNsdWRlcyBhIEJJVCBT VFJJTkcuIElzIHRoaXMgZW5jb2RlZCBzbyB0aGF0IHRoZSBtb3N0IHNpZ25pZmljYW50IGJpdCBp biB0aGUgREVSIGVuY29kZWQgdmFsdWUgaXMgYml0IDAgKGRpZ2l0YWxTaWduYXR1cmUpPyBBZnRl ciBsb29raW5nIGF0IGEgZmV3IGNlcnRpZmljYXRlcywgdGhhdCBzZWVtcyB0byBiZSB0cnVlIGJ1 dCBJIHdhbnQgdG8gdmVyaWZ5Lg0KDQpYLjY5MCBhZGRyZXNzZXMgdGhpcywgYXMgdGhhdCBkZXNj cmliZXMgaG93IERFUiBlbmNvZGluZyAoYW5kIEJFUiBlbmNvZGluZykgd29yayBvbiB0aGUgd2ly ZS4NCg0KSW4gWC42OTAgKDA4LzE1KSwgdGhlIHJlbGV2YW50IGNsYXVzZSB3aWxsIGJlIDguNi4y LjEgKGZvciB0aGUgZ2VuZXJhbCBCRVIgZW5jb2RpbmcpIGFuZCAxMS4yIGZvciB0aGUgZnVydGhl ciBERVIgbW9kaWZpY2F0aW9ucy4NCg0KDQoyKSAgICAgIFJGQyA1NzU0IHNheXMgdGhhdCB3aGVu IHRoZSBhbGdvcml0aG0gT0lEIGluIGFuIEFsZ29yaXRobUlkZW50aWZpZXIgc3RydWN0dXJlIGlz IHNoYTI1NldpdGhSU0FFbmNyeXB0aW9uLCB0aGUgcGFyYW1ldGVycyBNVVNUIGJlIE5VTEwuIFdv dWxkIHRoYXQgTlVMTCB2YWx1ZSBlbmNvZGUgdG8gYW4gYWRkaXRpb25hbCAwNSAwMCBhdCB0aGUg ZW5kIG9mIHRoZSBTRVFVRU5DRT8gQWdhaW4sIEkgb2JzZXJ2ZSB0aGlzIHRvIGJlIHRydWUgYnV0 IEkgd2FudCB0byB2ZXJpZnkgaXQuDQpZZXMuIE9taXNzaW9uIHdvdWxkIGhhdmUgYmVlbiBzcGVj aWZpZWQgYnkgIk1VU1QgYmUgYWJzZW50LiIuDQoNClRoaXMgaXMgcGVyaGFwcyBtb3JlIG9idmlv dXMgaW4gUkZDIDU5MTIsIHdoaWNoIHByb3ZpZGVzIGFuIGV4cGxpY2l0IEFTTi4xIG1vZHVsZSB0 aGF0IGNhcHR1cmVzIHRoZXNlIGVuY29kaW5nIHJlcXVpcmVtZW50cyAoc3BlY2lmaWNhbGx5LCBz ZWUgU2VjdGlvbiA4LCBBU04uMSBNb2R1bGUgZm9yIFJGQyA0MDU1KQ0KDQo= --_000_f0ae2bd5921d40a68cbae00730a5b04einfineoncom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnAuZ21haWwtbTYyODQ3MTUx Nzg0NjUwNjI0ODBtc29saXN0cGFyYWdyYXBoLCBsaS5nbWFpbC1tNjI4NDcxNTE3ODQ2NTA2MjQ4 MG1zb2xpc3RwYXJhZ3JhcGgsIGRpdi5nbWFpbC1tNjI4NDcxNTE3ODQ2NTA2MjQ4MG1zb2xpc3Rw YXJhZ3JhcGgNCgl7bXNvLXN0eWxlLW5hbWU6Z21haWwtbV82Mjg0NzE1MTc4NDY1MDYyNDgwbXNv bGlzdHBhcmFncmFwaDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6 MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglm b250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30N CnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEw LjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2lu OjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl ZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0t LT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4N CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1s PjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZs aW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Unlhbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VGhhbmtzIGZvciB5 b3VyIHF1aWNrIHJlc3BvbnNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5JIGp1c3QgZG93bmxvYWRlZCBYLjY5 MCBhbmQgYWxzbyBYLjY4MCBiZWNhdXNlIHRoYXQgc2VlbXMgdG8gYmUgYWxzbyBuZWNlc3Nhcnkg dG8gYW5zd2VyIG15IHF1ZXN0aW9uIDEpLiBNeSBjb25jbHVzaW9uIGlzIHRoYXQgdGhlIGFuc3dl ciB0byBxdWVzdGlvbiAxKSBpcyDigJw8Yj5ZZXM8L2I+4oCdLiBSaWdodD88bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5TdGV2ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gUnlhbiBTbGVldmkgJmx0O3J5YW4taWV0ZkBzbGVl dmkuY29tJmd0Ow0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBTZXB0ZW1iZXIgNSwgMjAx OSAxMjoxMCBQTTxicj4NCjxiPlRvOjwvYj4gSGFubmEgU3RldmUgKElGQU0gRFNTIFNNRCBBTVIp ICZsdDtTdGV2ZS5IYW5uYUBpbmZpbmVvbi5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBJRVRGIFBL SVggJmx0O3BraXhAaWV0Zi5vcmcmZ3Q7OyBrZ29sZG1hbkB1cy5pYm0uY29tPGJyPg0KPGI+U3Vi amVjdDo8L2I+IFJlOiBbcGtpeF0gQ2VydGlmaWNhdGUgRW5jb2RpbmcgUXVlc3Rpb25zPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBTZXAgNSwgMjAxOSBh dCAxMToxOSBBTSAmbHQ7PGEgaHJlZj0ibWFpbHRvOlN0ZXZlLkhhbm5hQGluZmluZW9uLmNvbSI+ U3RldmUuSGFubmFAaW5maW5lb24uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgaGF2ZSBhIGZldyBzaW1wbGUg cXVlc3Rpb25zIGFib3V0IEFTTi4xIGVuY29kaW5nIGZvciBYLjUwOSBjZXJ0aWZpY2F0ZXMuIENh biB5b3UgaGVscD88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iZ21haWwtbTYyODQ3MTUxNzg0NjUwNjI0ODBtc29s aXN0cGFyYWdyYXBoIj4xKTxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPlRoZSBLZXlVc2FnZSBleHRlbnNpb24gaW5jbHVk ZXMgYSBCSVQgU1RSSU5HLiBJcyB0aGlzIGVuY29kZWQgc28gdGhhdCB0aGUgbW9zdCBzaWduaWZp Y2FudCBiaXQgaW4gdGhlIERFUiBlbmNvZGVkIHZhbHVlIGlzIGJpdCAwIChkaWdpdGFsU2lnbmF0 dXJlKT8gQWZ0ZXIgbG9va2luZyBhdCBhIGZldyBjZXJ0aWZpY2F0ZXMsIHRoYXQgc2VlbXMgdG8g YmUgdHJ1ZSBidXQgSSB3YW50IHRvIHZlcmlmeS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5YLjY5MCBh ZGRyZXNzZXMgdGhpcywgYXMgdGhhdCBkZXNjcmliZXMgaG93IERFUiBlbmNvZGluZyAoYW5kIEJF UiBlbmNvZGluZykgd29yayBvbiB0aGUgd2lyZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gWC42OTAgKDA4LzE1KSwgdGhlIHJlbGV2YW50 IGNsYXVzZSB3aWxsIGJlIDguNi4yLjEgKGZvciB0aGUgZ2VuZXJhbCBCRVIgZW5jb2RpbmcpIGFu ZCAxMS4yIGZvciB0aGUgZnVydGhlciBERVIgbW9kaWZpY2F0aW9ucy48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9ImdtYWlsLW02Mjg0NzE1MTc4NDY1MDYyNDgwbXNv bGlzdHBhcmFncmFwaCI+Mik8c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj5SRkMgNTc1NCBzYXlzIHRoYXQgd2hlbiB0aGUg YWxnb3JpdGhtIE9JRCBpbiBhbiBBbGdvcml0aG1JZGVudGlmaWVyIHN0cnVjdHVyZSBpcyBzaGEy NTZXaXRoUlNBRW5jcnlwdGlvbiwgdGhlIHBhcmFtZXRlcnMgTVVTVCBiZSBOVUxMLiBXb3VsZCB0 aGF0IE5VTEwgdmFsdWUgZW5jb2RlIHRvIGFuIGFkZGl0aW9uYWwgMDUgMDAgYXQgdGhlIGVuZCBv ZiB0aGUgU0VRVUVOQ0U/IEFnYWluLCBJIG9ic2VydmUgdGhpcyB0byBiZSB0cnVlIGJ1dA0KIEkg d2FudCB0byB2ZXJpZnkgaXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlllcy4gT21pc3Npb24gd291bGQg aGF2ZSBiZWVuIHNwZWNpZmllZCBieSAmcXVvdDtNVVNUIGJlIGFic2VudC4mcXVvdDsuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgaXMg cGVyaGFwcyBtb3JlIG9idmlvdXMgaW4gUkZDIDU5MTIsIHdoaWNoIHByb3ZpZGVzIGFuIGV4cGxp Y2l0IEFTTi4xIG1vZHVsZSB0aGF0IGNhcHR1cmVzIHRoZXNlIGVuY29kaW5nIHJlcXVpcmVtZW50 cyAoc3BlY2lmaWNhbGx5LCBzZWUgU2VjdGlvbiA4LCBBU04uMSBNb2R1bGUgZm9yIFJGQyA0MDU1 KTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_f0ae2bd5921d40a68cbae00730a5b04einfineoncom_-- From nobody Thu Sep 5 13:21:15 2019 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD6EF120868 for ; Thu, 5 Sep 2019 13:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lEXQBLXgJyzg for ; Thu, 5 Sep 2019 13:21:12 -0700 (PDT) Received: from mail-qk1-x741.google.com (mail-qk1-x741.google.com [IPv6:2607:f8b0:4864:20::741]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D662B1207FF for ; Thu, 5 Sep 2019 13:21:11 -0700 (PDT) Received: by mail-qk1-x741.google.com with SMTP id f13so3459021qkm.9 for ; Thu, 05 Sep 2019 13:21:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=p+GoVmNDYVTPNcPudNE2AhCp3ld7kHGiKFnT3fsCULI=; b=gRbzeGcKesCXMdoXPbTGTExF0HySzHWf0JMBiKPprNfkhBCgSKeuY8iIdxm07PDfVv krkggqcwjulKZZggEiF5x5JJ2zrmS09+HuGjz4ZgTjtn4CH03Y5pA3JDzOvbV5nLAfwP eJLxFAu9YMM+3srL64EcnPnSl7Gf2mxMGZlBXfOGEcs/D7mapikyBqNuTVXgQKwmb6me 9/J6Cjd00DxsKGOBAASzTHnV3WQ8RSTuOpgpvrxMcRGFi75N8fjCX4mLeENN4KToOSM+ 2ipssv5OYB3woqAHf/XpDkfdsdq9I2gBHnX/iuWnjT+jVwPYI3PmppKV4ttFSx9O5H0D Lp4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=p+GoVmNDYVTPNcPudNE2AhCp3ld7kHGiKFnT3fsCULI=; b=dHKN2z8L9AF12YbLJ/Vq6wDuh5I1MfuW4dJqLVB75dvux6LHgeBl0jWx77/Z8/FImd fuAwh8y3+pWAPCvgXb4kh+8liqxdxvLkXDGekm/22TOs7hC5UBQB13IrW/hl93tjkfo3 t0bnvllZ9Cd2NMwgGYYm/MUKGq9oEPhbaVo696DXLQcuZNCQ9XfMH7tB4QsC57oYGVpg RHsKefZ5aOP7vnxgS0def8dzQxtgTCiozwA0leJI5o2fEo0t3CRkh/vGppZiPP8D5tlR T0yeaP81IycXD/qqzIOiionbHxPjUqQslAdJXFEpIpHVPuUArOLE90KmzFWUDPWlhI8r 83dg== X-Gm-Message-State: APjAAAWVIzng5c068nj0ceMZePqbbwjTr+dDuamyTXGaD4E/euusgceD ozYDb0bsMth9ggjVV1QH/hNISPx0qks= X-Google-Smtp-Source: APXvYqxpKZkCQTc/65g29VKIehYLqGTBRuMGw0p6DfM7W10wLW2Ct1kuryDJCrZ3nIURPKyFbiEW7g== X-Received: by 2002:a37:883:: with SMTP id 125mr4927939qki.478.1567714870566; Thu, 05 Sep 2019 13:21:10 -0700 (PDT) Received: from ?IPv6:2601:152:4400:437c:ed88:5732:4488:cfe8? ([2601:152:4400:437c:ed88:5732:4488:cfe8]) by smtp.gmail.com with ESMTPSA id h10sm1895949qtk.18.2019.09.05.13.21.09 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Sep 2019 13:21:10 -0700 (PDT) To: pkix@ietf.org References: <5eec7483c95247cb8968752588ff09f2@infineon.com> From: Michael StJohns Message-ID: <0ec81bda-d7a8-63db-457a-ea8f6be255e5@nthpermutation.com> Date: Thu, 5 Sep 2019 16:21:08 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------5C9A3C96DA6C8E4E75855C62" Content-Language: en-US Archived-At: Subject: Re: [pkix] Certificate Encoding Questions X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2019 20:21:14 -0000 This is a multi-part message in MIME format. --------------5C9A3C96DA6C8E4E75855C62 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 9/5/2019 12:09 PM, Ryan Sleevi wrote: > > > On Thu, Sep 5, 2019 at 11:19 AM > wrote: > > I have a few simple questions about ASN.1 encoding for X.509 > certificates. Can you help? > > 1)The KeyUsage extension includes a BIT STRING. Is this encoded so > that the most significant bit in the DER encoded value is bit 0 > (digitalSignature)? After looking at a few certificates, that > seems to be true but I want to verify. > > > X..690 addresses this, as that describes how DER encoding (and BER > encoding) work on the wire. > > In X.690 (08/15), the relevant clause will be 8.6.2.1 (for the general > BER encoding) and 11.2 for the further DER modifications. The left most bit of the left most byte is bit 0 in a BitString. That's Bit 1 of byte 0.  (Bits are numbered in the bytes from 1-8).    So {digitalSignature} would be encoded  03 02 07 80 > 2)RFC 5754 says that when the algorithm OID in an > AlgorithmIdentifier structure is sha256WithRSAEncryption, the > parameters MUST be NULL. Would that NULL value encode to an > additional 05 00 at the end of the SEQUENCE? Again, I observe this > to be true but I want to verify it. > > Yes. Omission would have been specified by "MUST be absent.". > > This is perhaps more obvious in RFC 5912, which provides an explicit > ASN.1 module that captures these encoding requirements (specifically, > see Section 8, ASN.1 Module for RFC 4055) This is one of those things where it depends on the actual algorithm.   AlgorithmIdentifier is defined as > AlgorithmIdentifier ::= SEQUENCE { > algorithm OBJECT IDENTIFIER, > parameters ANY DEFINED BY algorithm OPTIONAL } which says first look at the algorithm field before trying to parse parameters.    In this case, the actual controlling document is RFC8017 not RFC5912 and that defines the parameter field as NULL rather than omitting it which probably would have been a smarter definition.   From an implementation POV, I'd be surprised if anyone actually tries to parse the parameters field, but you're safer setting it to NULL  { 05 00 }. Mike > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --------------5C9A3C96DA6C8E4E75855C62 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 9/5/2019 12:09 PM, Ryan Sleevi wrote:


On Thu, Sep 5, 2019 at 11:19 AM <Steve.Hanna@infineon.com> wrote:

I have a few simple questions about ASN.1 encoding for X.509 certificates. Can you help?

 

1)      The KeyUsage extension includes a BIT STRING. Is this encoded so that the most significant bit in the DER encoded value is bit 0 (digitalSignature)? After looking at a few certificates, that seems to be true but I want to verify.


X..690 addresses this, as that describes how DER encoding (and BER encoding) work on the wire.

In X.690 (08/15), the relevant clause will be 8.6.2.1 (for the general BER encoding) and 11.2 for the further DER modifications.

The left most bit of the left most byte is bit 0 in a BitString.  That's Bit 1 of byte 0.  (Bits are numbered in the bytes from 1-8).    So {digitalSignature} would be encoded  03 02 07 80 



 

2)      RFC 5754 says that when the algorithm OID in an AlgorithmIdentifier structure is sha256WithRSAEncryption, the parameters MUST be NULL. Would that NULL value encode to an additional 05 00 at the end of the SEQUENCE? Again, I observe this to be true but I want to verify it.

Yes. Omission would have been specified by "MUST be absent.".

This is perhaps more obvious in RFC 5912, which provides an explicit ASN.1 module that captures these encoding requirements (specifically, see Section 8, ASN.1 Module for RFC 4055)

This is one of those things where it depends on the actual algorithm.   AlgorithmIdentifier is defined as

 AlgorithmIdentifier  ::=  SEQUENCE  {
        algorithm               OBJECT IDENTIFIER,
        parameters              ANY DEFINED BY algorithm OPTIONAL  }
which says first look at the algorithm field before trying to parse parameters.    In this case, the actual controlling document is RFC8017 not RFC5912 and that defines the parameter field as NULL rather than omitting it which probably would have been a smarter definition.   From an implementation POV, I'd be surprised if anyone actually tries to parse the parameters field, but you're safer setting it to NULL  { 05 00 }.

Mike



 

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


--------------5C9A3C96DA6C8E4E75855C62-- From nobody Wed Sep 25 15:07:18 2019 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12C851200A4 for ; Wed, 25 Sep 2019 15:07:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJ9F1pAWMsXg for ; Wed, 25 Sep 2019 15:07:12 -0700 (PDT) Received: from mail.nmhq.net (mail.nmhq.net [95.129.49.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5906512000F for ; Wed, 25 Sep 2019 15:07:12 -0700 (PDT) Received: from matthies by mail.nmhq.net with local (Exim 4.89) (envelope-from ) id 1iDFRC-00050d-8k for pkix@ietf.org; Thu, 26 Sep 2019 00:07:06 +0200 Date: Thu, 26 Sep 2019 00:07:06 +0200 From: Niklas Matthies To: pkix@ietf.org Message-ID: <20190925220706.pbzitg6bqr2mfqkz@nmhq.net> Mail-Followup-To: pkix@ietf.org References: <20190712200549.2kgzjqodj5afnxlt@nmhq.net> <20190716145808.x6slwzijkvdkodyg@nmhq.net> <32262DB0-BA95-4ECD-ACF9-B5BD50F7B442@aaa-sec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <32262DB0-BA95-4ECD-ACF9-B5BD50F7B442@aaa-sec.com> X-Clacks-Overhead: GNU Terry Pratchett X-Editor: VIM - Vi IMproved 8.0 X-Operating-System: Linux 4.4.112 x86_64 User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [pkix] Clarification on "zero" hash value in SigPolicyHash (CAdES) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2019 22:07:16 -0000 Coming back to this topic... To summarize, I believe it's fairly clear now that option 3 was the intended interpretation, despite being poorly communicated by the wording in the standard. I've also now come to strongly favor option 3 due to its aim of maximizing compatibility with prior implementations that know nothing about zero-hash values and expect a real hash value to be present in accordance with earlier versions of the standard. In particular, existing implementations that only check for the hash length, possibly as part of their format checks, or that implicitly rely on the hash value having the correct length without checking it, would remain unaffected, and in the worst case would merely report a policy hash mismatch -- as opposed to a format error, or possibly a crash if the implementation blindly reads n bytes based on the algorithm identifier value. In the meantime, there's the additional compatibility consideration that signatures generated by implementations that have correctly adopted the interpretation of option 3 should be honored. On the other hand, the wording in the standard is sufficiently unclear that some implementers have interpreted it differently than intended, and thus signatures have been produced and are "in the wild" with zero hashes of different length. In the light of that situation, I would propose the following approach for a future revision of the standard: 1. Signature validation applications SHALL interpret a zero hash value of any length (including zero-length) as an unknown/unspecified hash value. 2. Signature creation applications outputting a zero hash SHOULD generate it with a length consistent with the algorithm identifier, but MAY generate it with any length (including zero-length). The first point ensures that existing signatures created under either interpretation remain valid. The second point maintains the originally intended interpretation (option 3) as the recommended form of a zero hash, while allowing other forms in accordance with the first point. Signature creators are then still free to use e.g. an empty OCTET STRING if they care less about interoperability with legacy implementations and more about the following objection. Regarding the objection that a real hash value may happen to be all-bits-zero and would be incorrectly interpreted as an unknown hash value: While such an occurrence cannot be ruled out, it is exceedingly unlikely. In probabilistic terms, a bit flip due to cosmic radiation or other soft error is vastly more likely. It's hard to conceive how an attacker could exploit that possibility, assuming strong hash algorithms. I simply don't think it is an issue. As a side note: I wonder why the authors of V1.7.3 didn't just introduce a new algorithm OID defined to indicate an unknown hash value. (It could even formally be defined to denote the trivial hash algorithm that maps all inputs to the same empty value.) Possibly there were concerns that existing implementations might somehow fail badly due to the unknown algorithm. Or maybe setting the hash value to zero just seemed the simpler solution overall. Anyway, please feel free to relay my thoughts to the ESI group. Niklas On Wed 2019-07-17 at 09:53h, Stefan Santesson wrote on pkix: >Niklas, > >Thanks for your analysis, which quite possibly is very true. > >However, I would just add that an empty OCTET STRING value would also be "syntactically correct" on the ASN.1 level. > >Stefan Santesson > >On 2019-07-16, 16:58, "pkix on behalf of Niklas Matthies" wrote: > > It now occurred to me that sigPolicyHash field being optional in ETSI > TS 101 733 V1.6.3 (2005-09) probably was discovered to be a mistake > because (1) it introduces a parsing ambiguity with > sigPolicyQualifiers, as both are optional SEQUENCEs, and (2) because > it broke compatibility with existing implementation. > > So it would seem that the zero hash value was introduced as a > workaround to still be able to have an optional hash, syntactically > masquerading as a real hash, and thus maintaining compatibility with > the earlier versions at least on the ASN.1 level. Then the note about > backwards compatibility would not be referring to the support of > "zero" hash values, but to the fact that keeping the sigPolicyHash > field mandatory for backwards compatibility reasons leaves no other > choice than to use a "compatible" encoding for a missing hash value. > > This interpretation would favor option 3 (using the length implied by > the hash algorithm), as this arguably causes the least disruption for > pre-V1.6.3 (and RFC-3126-based) implementations. > > Niklas > > > On Fri 2019-07-12 at 22:05h, Niklas Matthies wrote on pkix: > >Dear all, > > > >I hope that someone can shed some light on the definition and origin > >of the special-case "zero" hash value for SigPolicyHash in CAdES. The > >main question is what exactly constitutes a "zero" hash value on the > >ASN.1 level. > > > >In the most current CAdES specification, ETSI EN 319 122-1 V1.1.1 > >(2016-04), the zero hash value is described as follows (clause > >5.2.9.1, page 20): The sigPolicyHash field shall contain the > >identifier of the hash algorithm and the hash of the value of the > >signature policy. > > The hashValue within the sigPolicyHash may be set to zero to > >indicate that the policy hash value is not known. > > > > NOTE: The use of a zero-sigPolicyHash value is to ensure > >backwards compatibility with earlier versions of ETSI TS 101 733 [1]. > > > >The ASN.1 definition of SigPolicyHash is as follows: > > > > SignaturePolicyId ::= SEQUENCE { > > sigPolicyId SigPolicyId, > > sigPolicyHash SigPolicyHash, > > sigPolicyQualifiers SEQUENCE SIZE (1..MAX) OF > >SigPolicyQualifierInfo OPTIONAL > > } > > > > SigPolicyHash ::= OtherHashAlgAndValue > > > > OtherHashAlgAndValue ::= SEQUENCE { > > hashAlgorithm AlgorithmIdentifier, > > hashValue OtherHashValue } > > > > OtherHashValue ::= OCTET STRING > > > >The question is what constitutes a "zero" hash value. A zero-length > >octet string? Any octet string where all octets are zero? Is the > >length of the octet string relevant, e.g. can or should it match the > >length implied by the hash algorithm? > > > >I spent some time going back the history of the standards to find the > >"earlier version" relevant for the note about backwards compatibility, > >however that search was inconclusive. > > > >All versions of ETSI TS 101 733 from the latest V2.2.1 (2013-04) back > >to V1.7.4 (2008-07) include the following note, which had a second > >sentence added: > > > > NOTE: The use of a zero-sigPolicyHash value is to ensure > >backwards compatibility with earlier versions of the > > current document. If sigPolicyHash is zero, then the hash > >value should not be checked against the calculated hash value > >of the signature policy. > > > >Confusingly, this now talks about sigPolicyHash being zero (whatever > >that would mean), not about the hashValue field within sigPolicyHash. > > > >The same text appears in RFC 5126 (February 2008). > > > >The previous version ETSI TS 101 733 V1.7.3 (2007-01) is the first > >version to talk about a zero hash value, and the note is just one > >sentence again: > > > > The hashValue within the sigPolicyHash max [sic] be set to zero to > >indicate that the policy hash value is not known. > > > > NOTE: The use of zero policy hash value is to ensure backward > >compatibility with earlier versions of the current document. > > > >In addition, the annex states the following: > > > > Annex K (informative): Changes from the previous version > > > > • if the hash of the signature policy is unknown, then, by > >convention, the sigPolicyHash shall be set to all zero > > > >Here again, the annex talks about sigPolicyHash being set to zero, not > >the hashValue within sigPolicyHash. > > > >On the RFC side, the same note first appears in > >https://tools.ietf.org/html/draft-ietf-smime-cades-02 (May 2007), and > >the sentence above (without the note) first appears in > >https://tools.ietf.org/html/draft-ietf-smime-cades-01 (April 2006). > > > >In the previous ETSI TS 101 733 V1.6.3 (2005-09), the sigPolicyHash > >field is optional (which is mandatory in all previous and all > >subsequent versions), and the following note is included: > > > > NOTE: In the previous version of TS 101 733 (i.e. version > >1.5.1) sigPolicyHash was mandatory. Implementations requiring > >to be backward compatible with version 1.5.1 and previous > >versions of the current document MUST include SigPolicyHash. > > > >None of the previous versions, from ETSI TS 101 733 V1.5.1 (2003-12) > >back to ETSI TS 101 733 V1.2.2 (2000-12) (the earliest version > >available at > >https://www.etsi.org/deliver/etsi_ts/101700_101799/101733/), as well > >as RFC 3126 (September 2001), do mention anything about zero hash > >values. > > > >So it remains unclear to which specification backwards compatiblity is > >intended. The point where the wording about zero hash values was > >introduced suggests that this may be about V1.6.3, where the > >sigPolicyHash field was optional. However, it's not clear how a "zero" > >hash value would achieve compatibility with the case of a missing > >sigPolicyHash field. > > > >I would appreciate any clarification on that topic. > > > >Kind regards, > >Niklas > > > >_______________________________________________ > >pkix mailing list > >pkix@ietf.org > >https://www.ietf.org/mailman/listinfo/pkix > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > > >