From nobody Tue Aug 2 06:10:13 2022 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 548AFC13CCE4 for ; Tue, 2 Aug 2022 06:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.687 X-Spam-Level: X-Spam-Status: No, score=-2.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.582, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=digicert.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n5EMIrqj_MxL for ; Tue, 2 Aug 2022 06:10:07 -0700 (PDT) Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2104.outbound.protection.outlook.com [40.107.244.104]) (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 849B9C159482 for ; Tue, 2 Aug 2022 06:10:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JPX4huIQLKUZbT5BVFMEXVcAp3wVXp3fy2SpeA4hBZ/BzP3Jcri7jnnq5LvJRhFbwNA67dortdiGmcVjr39D5PBE8CP7+WRWctma23wXPlGXyG87mAfu6ZVWbvHltyYZgkI1qcjMwyib3bhUCypRDCWovQlSb24ZqSu0CbiPL7ia6OvLsZsnR3LRUDv12bp9DOFkxFhH3VajrUGUSDTrL+i55oOeRWi4oMY6YHC2yuW/WXo5Wmr3XrSyfgXfY51Wb4oQsarKINRIdkbB6AIEFHqXZopnGUd9TWCDsVEP5TPfe4ZNhSh6+c+HT4IuWC+9+1Q1NbvHrIur13YK1bNVbA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=FOXvaQaQquZBYoR2NjdoZ4gyojvf1TRNuBbno7Ys2Dk=; b=ld93sEv2GHCJoHhI2uh8Y3rk2opOozAVmr5l1zhY8mKa5fXNEFXFgabuB6ZH2YEIon/TNC3qe9QqGoCKKC3ZBj1HUKiEeNN7COfcYaDr9Xxe5OrNcGjGoGKg34qV8lNWVwfr1zSWb30p4FbrE8FziKcRC/MDPUDUOATgXgPP2QMsnzLHM3tRWy1IK0LtteAye2kVeSSfl1lXAQRVFoNIFAHx/9gu85iGePNN1LNouwXPRYBYgU0i76Y5YKe3+KJWOJr5a1Dt7U5CKcK4KD+K+XtjkAvf4hKcVybX3C/AtPdGcHn95bsWiAwIDPmXUnDZcljCWUcX6JXXWD/1bc9edQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=digicert.com; dmarc=pass action=none header.from=digicert.com; dkim=pass header.d=digicert.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FOXvaQaQquZBYoR2NjdoZ4gyojvf1TRNuBbno7Ys2Dk=; b=SOnIZy5Bt9sC+Hrap+D+eZdMQc20tBv+19qCaCGVJHBqOBcDagDbG3i8K1DYcPq7dbLYi11+gdEDBQqLzJeTHsbvtTDj2jarikDioFkR3FoQUj7h+uuPJuIiLlCpdAYktfGYALflCsz9Gp6NnYgg/VjtSyKxcktGMAj+NxMCgmVkxT8tDpA2f+vTCLXZ6HawGFOq1+Tjxq4uT9tucU9wr0ydsYCBC4cvBPSRAexkkMaOqxSYZTtpNrgy+IHCevWmVSG2LhSIPpqtOIToxokojtjRyT2Ysjp1gqdZby3NYw6vjGGnbE/zFMIrOCx7G/5ySj0lFR67Ra+e7zTawJBo0g== Received: from DM6PR14MB2186.namprd14.prod.outlook.com (2603:10b6:5:b6::16) by SJ0PR14MB5920.namprd14.prod.outlook.com (2603:10b6:a03:486::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5482.11; Tue, 2 Aug 2022 13:10:02 +0000 Received: from DM6PR14MB2186.namprd14.prod.outlook.com ([fe80::f073:6195:1e12:682b]) by DM6PR14MB2186.namprd14.prod.outlook.com ([fe80::f073:6195:1e12:682b%3]) with mapi id 15.20.5504.014; Tue, 2 Aug 2022 13:10:02 +0000 From: Corey Bonnell To: David von Oheimb , Michael Richardson CC: LAMPS WG Thread-Topic: [lamps] struggling with CSRAttrs Thread-Index: AQHYpQTCW+TI1yXBSEK/awaiIOrS562bb88AgAAlJPA= Date: Tue, 2 Aug 2022 13:10:02 +0000 Message-ID: References: <12352.1657505901@localhost> <563732.1659120308@dooku> <36c409c2-ab92-4ec2-6f1e-235652a243d9@siemens.com> <56a8af3a-63f2-5f19-62d9-59469ab678bf@siemens.com> In-Reply-To: <56a8af3a-63f2-5f19-62d9-59469ab678bf@siemens.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=digicert.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 90556b58-93fe-4ab1-0bce-08da74884f50 x-ms-traffictypediagnostic: SJ0PR14MB5920:EE_ x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: wyJX9SOVkWF2bLnUVV49H/QvHHyfElqoKAJkxWi0ClhmHTaKezD9DoIsU/TZwKvAXiMuNbZp62W+GIvzwySm3vEO72Pd8bh6x6wuXEg9bdGKPZa3vXAiSYSe8KY2u7UAE9UZWh5mE78BZZReF7uesoTGhPoo1P51sI+XWqnxgJ9iTOEm/0jGjxPUQGfFOHC1K4G9qTN3o7s7O26xmpOTLNlTzIwdAuxl/4KoW4FxaHdvAf04wDkw9czYfEVt23Uef6VThPWgVOvXtCY/HlqLxGvNR31pO6SYCmbFSMPWIH0Mncq2Y4toe4m1Q/g2rEFqK3zlcd+DL/nsIuuQVRSDt4wpZ1B9Hhx8VnkNErezHEPtp1NoNV1yEizeZ2fgRJDOIYxv0MwtDp+UKNpmXn7RgHHnqbqjwR+H4/MjM/BH3gRL837maFtmPGyWG5k85K1G/N3sFKBxTtUjU8vNYqO5EIbpB74HzxaTRQ/bI8Nn11jFzSzB0LqMnmwdj5H/busdY7qB2ac/pR0mQQZWabJo0QCfUoz0Vy8DeP0zJpLOA6c4baqJiCtoGa1PVbHo7x5boAIWLrI4zcXit389Q/f8rkADTpDzvJ6faWaxikRWW1H4vP1OtETmP/ost3PomYfc9eVJZdwF6QfG56Po4NcPOrRCslqNDhdmw3tCvESTQcOFCtN3kySyyHOOYJfG/Gai6x6Qh91ek74+Sm9rmFCm5H4kKrYgnhfyuyanu+csDrqKyLNyDfFw+jIRASviKqeDD/b/SqX+vW/LaK0ceOb/vkLmPUg6za+f6QqUcFbq0doRjSY/6RKAOmo8Yi4oPCXUw18NKXggZF0hKgZ28fXbGg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR14MB2186.namprd14.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230016)(136003)(376002)(346002)(396003)(39850400004)(366004)(83380400001)(186003)(4326008)(9326002)(52536014)(66946007)(33656002)(2906002)(8676002)(76116006)(5660300002)(8936002)(64756008)(66556008)(66476007)(66446008)(55016003)(478600001)(110136005)(6506007)(9686003)(7696005)(53546011)(26005)(41300700001)(166002)(316002)(38070700005)(99936003)(38100700002)(86362001)(122000001)(966005)(71200400001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?Vmp0Nk5yNWlLWkV3MnV2Y21PcFlUQXJDRnBQVmF1S212THZTQ3V6SFF5d3JI?= =?utf-8?B?OHIrUldLVmIvZEhmRXpKMllZdTA0RVJaNmsrY3M2c3hVRVI5QXh5eFJXekFF?= =?utf-8?B?RWFhUCtCbzcyOEhuVzhYaTZrWlFCWjQvMGhyeXJCdjkwcW82Z3VQdnduY01C?= =?utf-8?B?YzhkVlFoMWp1WjlXN3RDbk9DRG9kZ0FaeTd5VVUvVFgwZWI4NTRNZDBJY3VI?= =?utf-8?B?Y2FEc2lMamdlRndGUXk1bC9venFjTUtyMmtTa3I2VjRwMytieHVWY1BCSjBO?= =?utf-8?B?OFJiaXp3Z2dZRjE2NkFNNjVPQ3dMaXNmV2xLd1daZy9adm13ckh6b3o5QXlE?= =?utf-8?B?N0tlZkR0Wlk0Ym1KRnVVT3ZXajlDMDlUM2Zxb0xJZ2JQOVJZSjhBakltWW82?= =?utf-8?B?WTR4RkJCNFJqQjhPRk9Nc05uMUZoV1haSGdQeFF1dG9jUHRtUEd6TkVIdmtW?= =?utf-8?B?aUkwZExlMG5WYVE4Wkl2eEY4TTY5VStKcHVkMk00aWM0dFdtNTZIWWFBMTVT?= =?utf-8?B?TG4xclhBWGhydk9hQTk1VkVaSW1mN1VZeG5oS2dvNDJtc2RXYk8vN2ltb3pp?= =?utf-8?B?ZHZBSGh1ZGlscHBhL3M1Qms2N0xOSkpLUFQ5K2pVZzJJY0hUYy9WbjZrcTZx?= =?utf-8?B?ZGY5NXU3dG9mR09ncXZ3dUhzQkQxZ0ViQnQ3Q2R1cTNOVUcvcEx5Uy9yMm5V?= =?utf-8?B?TXJVKzlEL3p6bUFqa01UZEd3blErME9ZZTc2RStUeFJydVk0bFdIeDdCTGJZ?= =?utf-8?B?VjU0ZkNVeWsrck5TNWdhckduQ1JOOU5YVjFOZ2xjSGZPTG5IaGRybVN5S3c2?= =?utf-8?B?ZmtOV2Y0dVZpRGNycGNYVG9iZ0FFQjBrb0hnbkVTVDFXT0Z5S1RVOC9aM1Qz?= =?utf-8?B?c2R1MG95bnpkV2c2ZVJWTlJUUm9saElyaFNqRlFUVEZMdVlYS01XalU5dmdO?= =?utf-8?B?dmg0blNLL21YckpNcUN4N1Z5amxzQkRMdHRrSFI1Y0F6ZGMwKzdwd0xJSnlE?= =?utf-8?B?Y0gvbnRleTVOdUFPcDgyZGNibHBnMVQyamxMdnJ1ZEhWYThnRS9Kdkc3N2hF?= =?utf-8?B?b1lJSUIvcXBlT2NkRDlMYlBNck45cHprWXlPZnpyL2tLdnZhRFdMZlM4akR5?= =?utf-8?B?ODZud2l6RzQ1STk2RWpUN0w1VmRzZXg3VlZZUDFvTVJFQ2J4bXp2eXdkZ1VN?= =?utf-8?B?aE9ZYjExR0lXUXIxTmpHcHlHV0VJeU9rMXdJT2NCWkJ4Yk5wV0h4VzdiMlNz?= =?utf-8?B?TlpCcnFYblNUU0NJYW03NUtlUEdmNDVzVnVKYlhQT2cxQ0drN3dTRFNwdlA4?= =?utf-8?B?Z1krb2ZtSWZ1L2JjTnFRZm9XdktQK2Q2Z2hQb3RGNXg1SE1QL2tvU08rWkEr?= =?utf-8?B?SFBFYjVxQzJSVDdadkRXWHE2UGREbHpoUWpKaXJCQnh6UFlZN3V0YnVLYm1a?= =?utf-8?B?OXJLeVNSczNLN3pvajA3RW1HM0FUWEFGRWxUcENPbVIxVGhwaTdvblFhSDll?= =?utf-8?B?WFZJM3FOTEQ4MnZYSkhmRUNGTDlYWkxEYWR2Rk9yODNLcWtCblh5bmFxcFJ1?= =?utf-8?B?ZW1vam0yUmJ2b0dubGxVOWFEamxQOHBnbXdBTG9kdzRVdlRpOVhIUXlzaW9i?= =?utf-8?B?SU51UEdFaDVid2ZHOW9xaVlYVTk2OFRNUU1kYmcvTjZacHgxY20rQ3VDeUVF?= =?utf-8?B?QzhKMUFFWG5mNjdkTDRReWpwUHNjTkdnU25wN2FrRXBoUVo5UFlJQllZSk94?= =?utf-8?B?R2lSTzhJQ1Y2R3E3QWIrTTBlTDRja0RIRUJNS1BzOElmMml0KzdhUlF0bWow?= =?utf-8?B?eTdnRWdtSmV0SDNqZEZMZUNkbEl4UjNFQ090WlRyWUttbUNTdXpqTzV2R1Jl?= =?utf-8?B?QXhJQ2dMRHMyUERpRVRnVGM5WlpPS1hxMWNBdkp1Zm1qVzFYb2llS0l4Y3hF?= =?utf-8?B?bTY5ekZDN0ZWR0lESXJIRVB0ZWpjM1QwWHRBdE5pSWRhQzAxVHdQSEdIQVN1?= =?utf-8?B?cnFrVlNqTnc0THg5c1VOOE9pVlFIU29GYkJsekRvZ1NXZng1V0kvTTZoQmpD?= =?utf-8?B?NVlZVWhHZXc0TmlsVkpNTHpWZ2IrOGFaUU1ia1I1MEZ6M2Eyb2NhMzFiVmMy?= =?utf-8?Q?Cc/e0N4PMUHeKSBENw8/N8yit?= Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_01A9_01D8A64F.A48115E0" MIME-Version: 1.0 X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR14MB2186.namprd14.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 90556b58-93fe-4ab1-0bce-08da74884f50 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Aug 2022 13:10:02.0898 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: w9XnNtgMXqOwk6ptMwfCbmoEUCn7vcfhuQoenVRbruigIPOCfBi1aXiLsplyZxBn+GGGK3W8934zu4d1M6Bz6/t855Tgg6tW7IOj6ZUtkI4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR14MB5920 Archived-At: Subject: Re: [lamps] struggling with CSRAttrs X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2022 13:10:12 -0000 ------=_NextPart_000_01A9_01D8A64F.A48115E0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_01AA_01D8A64F.A48115E0" ------=_NextPart_001_01AA_01D8A64F.A48115E0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi David, One comment on the encoding of the subjectAltName, copied below: =20 SEQUENCE { OBJECT IDENTIFIER subjectAltName (2 5 29 17) [0] { BOOLEAN TRUE } OCTET STRING, encapsulates { SEQUENCE { [2] 'domain.example' } } } I don=E2=80=99t think the critical BOOLEAN should be tagged above. RFC = 5280, section 4.1 [1] defines Extension as: =20 Extension ::=3D SEQUENCE { extnID OBJECT IDENTIFIER, critical BOOLEAN DEFAULT FALSE, extnValue OCTET STRING -- contains the DER encoding of an ASN.1 value -- corresponding to the extension type identified -- by extnID } =20 Given this ASN.1 definition, I believe the correct encoding of the = subjectAltName would be: =20 SEQUENCE { OBJECT IDENTIFIER subjectAltName (2 5 29 17) BOOLEAN TRUE OCTET STRING, encapsulates { SEQUENCE { [2] 'domain.example' } } } Thanks, Corey =20 [1] https://datatracker.ietf.org/doc/html/rfc5280#section-4.1 =20 From: Spasm On Behalf Of David von Oheimb Sent: Tuesday, August 2, 2022 6:45 AM To: Michael Richardson Cc: LAMPS WG Subject: Re: [lamps] struggling with CSRAttrs =20 Here are further things to clarify, which I happened to come across = yesterday when tweaking the OpenSSL implementation = of X.509 extensions in = PKCS#10 CSRs (and certs). It is common practice for PKCS#10 objects to contain just one X.509 = extension attribute with a single set element, although this appears not explicitly required by RFC 2986 = (at least I did not find this = there), and the value of this attribute is a sequence of actual extensions:=20 Extensions ::=3D SEQUENCE SIZE (1..MAX) OF Extension defined in RFC 5280 section 4.1 = , which also = makes clear that X.509 certs can bear only one such list: TBSCertificate ::=3D SEQUENCE { version [0] EXPLICIT Version DEFAULT v1, ... extensions [3] EXPLICIT Extensions OPTIONAL -- If present, version MUST be v3 } As mentioned on July 19 (see other email below), the CsrAttrs syntax = gives quite some needless freedom how to represent multiple X.509 extensions (and potentially = other types of attributes). =20 I believe we should clarify that=20 * There MUST be at most one attribute describing X.509 extensions, i.e., one bearing the OID extensionRequest (1.2.840.113549.1.9.14) as = its type. * The set in such an X.509 extension value MUST contain exactly one = element. * The value of such an attribute MUST be of type Extensions, i.e., a = sequence of Extension. In this light, I've just updated the example to reflect the type = SEQUENCE OF Extension and extended it with two (non-critical) extensions to make it more = general/educative: SEQUENCE { SEQUENCE { OBJECT IDENTIFIER extensionRequest (1 2 840 113549 1 9 14) SET { SEQUENCE { SEQUENCE { OBJECT IDENTIFIER basicConstraints (2 5 29 19) OCTET STRING, encapsulates { SEQUENCE {} } } SEQUENCE { OBJECT IDENTIFIER extKeyUsage (2 5 29 37) OCTET STRING, encapsulates { SEQUENCE { OBJECT IDENTIFIER serverAuth (1 3 6 1 5 5 7 3 1) } } } SEQUENCE { OBJECT IDENTIFIER subjectAltName (2 5 29 17) [0] { BOOLEAN TRUE } OCTET STRING, encapsulates { SEQUENCE { [2] 'domain.example' } } } } } } } Moreover, we might specify what an empty list of X.509 extensions means, such as to express that no X.509 extensions should/must be used in the = CSR. =20 David =20 =20 On 31.07.22 19:40, David von Oheimb wrote: Hi Michael et al. On 29.07.22 20:45, Michael Richardson wrote:=20 Attribute { ATTRIBUTE:IOSet } ::=3D SEQUENCE { extType ATTRIBUTE.&id({IOSet}), extAttr SET SIZE(1..MAX) OF ATTRIBUTE.&Type({IOSet}{@type}) } Well, this definition is semantically identical to the original one. So better not rename the two fields of the Attribute structure, i.e., we should stick with 'type' and 'values', in particular since there may be attributes that are not X.509 extensions. I found it clearer, but if you object to this rename, then I'll go with = your preference. Let's keep the original field names. Also because this underlines the important fact that we do not change = the ASN.1 syntax at all, which is critical for bits-on-the-wire compatibility, but we just = clarify its use and interpretation. I've just made a pass on lamps-rfc7030-csrattrs.mkd in the GitHub = repository. Its new version contains various suggestions for improvements here and = there. Also updated the subjectAltName example to be of the more usual form of = a dNSName and inserted two questions/remarks: (TODO: Do we want to allow an empty extnValue (which is of type OCTET STRING), which would mean that the client is told to include an X.509 extension of the given type and fill in the concrete value itself?) (TODO: Note that this mechanism does not support telling the client to include in the CSR a specific subject DN, simply because there is no OID for this. I think we should better make this clear, or we have to define such an OID if setting a subject name should be supported.) I also corrected the spelling of my (co-author's) name in = presentations/ietf114-lamps-csrattrs.{fodp,pdf}. David =20 On Tue, 2022-07-19 at 20:58 +0200, David von Oheimb wrote: Hi Michael, Sean, et al., =20 on Sun, 2022-07-10 at 22:18 -0400, Michael Richardson wrote: =20 Sean, sorry to be asking this with less than 24h to ID cut-off. I didn't want to post an updated ID until I had example code that = produced what I *thought* you are suggesting. Moving a SEQ/SET around isn't that hard... only now I've confused myself. =20 We had: =20 CsrAttrs ::=3D SEQUENCE SIZE (0..MAX) OF AttrOrOID =20 AttrOrOID ::=3D CHOICE (oid OBJECT IDENTIFIER, attribute Attribute } =20 Attribute { ATTRIBUTE:IOSet } ::=3D SEQUENCE { extType ATTRIBUTE.&id({IOSet}), extAttr SET SIZE(1..MAX) OF ATTRIBUTE.&Type({IOSet}{@type}) } =20 Well, this definition is semantically identical to the original one. So better not rename the two fields of the Attribute structure, i.e., we = should stick with 'type' and 'values', in particular since there may be attributes that are not X.509 = extensions. According to = = https://datatracker.ietf.org/doc/html/draft-richardson-lamps-rfc7030-csra= ttrs the only thing that is "changed" is the clarification that the = attributes may contain entire X.509 extensions. So BTW I believe we can and should claim that this is bit-on-the wire = compatible with RFC 7030. =20 =20 with the understanding that extAttr could be a SET of Extensions. =20 Better also state that in this case the type/extType field MUST bear the = value extensionRequest (1.2.840.113549.1.9.14). =20 =20 Each Extension is given by: =20 Extensions ::=3D SEQUENCE SIZE (1..MAX) OF Extension =20 The Extensions structure is only needed within certificates (where there = is just one extensions field). All needed here is the Extension structure - there are already more than = enough of those sequences and sets around=20 =20 Extension ::=3D SEQUENCE { extnID OBJECT IDENTIFIER, critical BOOLEAN DEFAULT FALSE, extnValue OCTET STRING -- contains the DER encoding of an ASN.1 value -- corresponding to the extension type identified -- by extnID } =20 =20 1) I'm not sure why I need a SET of a Sequence, unless your intent was = that extAttr could be an *Extension* ?? I'm gonna go with yes here, but I didn't code that yet. =20 In my view, the set-valued=20 =20 extAttr SET SIZE(1..MAX) OF ATTRIBUTE.&Type( = {IOSet}{@type}) (or better, as in the original definition in 7030): values SET SIZE(1..MAX) OF ATTRIBUTE.&Type( = {IOSet}{@type}) =20 is not really needed because multiple attributes can be given anyway = using multiple attributes, and each of them may then have a different = type. If multiple values are given as a set within a single attribute, all its = elements must have the same type. So in practice I suppose that for all attributes the SETs given within = each of them usually will have just one value element. =20 =20 2) I think that extnID would be things like subjectAltName, i.e. OID: 2.5.29.17 =20 Right. =20 =20 But, if so, what is extType for this? =20 The (ext)type is needed to provide the information, using = "extensionRequest", that an X.509 extension is being given in this = attribute. =20 =20 =20 ASN1 that I have right now, where I've put subjectAltName in twice: =20 obiwan-[projects/pandora/fountain](2.6.6) mcr 10396 %dumpasn1 = tmp/csr_bulb1.der 0 84: SEQUENCE { 2 82: SEQUENCE { 4 3: OBJECT IDENTIFIER subjectAltName (2 5 29 17) <--- WHAT = GOE, uS HERE? Replace this by extensionRequest = (1.2.840.113549.1.9.14) =20 =20 9 75: SET { 11 73: SEQUENCE { <--- SEQUENCE here might be undesired. SEQUENCE here is fine, as demanded by the Extension structure. =20 13 3: OBJECT IDENTIFIER subjectAltName (2 5 29 17) 18 3: [0] { The "[0] {" (and the closing 2}") is likely superfluous/wrong here. 20 1: BOOLEAN TRUE : } 23 61: SEQUENCE { 25 59: [0] { 27 57: UTF8String : ' = = rfc8994+fd739fc23c3440112233445500000000+@acp.ex' : 'ample.com' : } : } This encoding of a SAN appears strange to me - which flavor of = GeneralName are you aiming at? =20 : } : } : } : } =20 - David ------=_NextPart_001_01AA_01D8A64F.A48115E0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi David,

One comment on the encoding of the subjectAltName, = copied below:

 

SEQUENCE = {
          OBJECT = IDENTIFIER subjectAltName (2 5 29 = 17)
          [0] = {
            = BOOLEAN = TRUE
           = ; }
          OCTET = STRING, encapsulates = {
            = SEQUENCE = {
           &n= bsp;  [2] = 'domain.example'
         = ;     = }
            = }
          = }

I don=E2=80=99t = think the critical BOOLEAN should be tagged above. RFC 5280, section 4.1 = [1] defines Extension as:

 

Extension=C2=A0 = ::=3D=C2=A0 SEQUENCE=C2=A0 {

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = extnID=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 OBJECT = IDENTIFIER,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = critical=C2=A0=C2=A0=C2=A0 BOOLEAN DEFAULT = FALSE,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 extnValue=C2=A0=C2=A0 = OCTET STRING

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- contains the DER = encoding of an ASN.1 value

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- corresponding to the = extension type identified

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- by = extnID

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = }

 

Given this ASN.1 definition, I believe the correct = encoding of the subjectAltName would be:

 

SEQUENCE = {
          OBJECT = IDENTIFIER subjectAltName (2 5 29 = 17)
          BOOLEAN = TRUE
          OCTET = STRING, encapsulates = {
            = SEQUENCE = {
           &n= bsp;  [2] = 'domain.example'
         = ;     = }
            = }
          = }

Thanks,

Corey

 

[1] https:= //datatracker.ietf.org/doc/html/rfc5280#section-4.1

 

From: Spasm = <spasm-bounces@ietf.org> On Behalf Of David von = Oheimb
Sent: Tuesday, August 2, 2022 6:45 AM
To: = Michael Richardson <mcr+ietf@sandelman.ca>
Cc: LAMPS WG = <spasm@ietf.org>
Subject: Re: [lamps] struggling with = CSRAttrs

 

Here are further things to = clarify, which I happened to come across yesterday
when tweaking the = OpenSSL implementation of X.509 extensions in PKCS#10 CSRs (and = certs).

It is common practice for PKCS#10 objects to = contain just one X.509 extension attribute with a single set = element,
although this appears not explicitly required by RFC 2986 (at least I = did not find this there),
and the value of this attribute is a = sequence of actual extensions: = 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
Extensions=C2=A0 ::=3D=C2=A0 SEQUENCE SIZE (1..MAX) OF =
Extension

defined in RFC = 5280 section 4.1, which also makes clear that X.509 certs can bear = only one such list:

=C2=A0=C2=A0 TBSCertificate=C2=A0 =
::=3D=C2=A0 SEQUENCE=C2=A0 =
{
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
version=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [0]=C2=A0 =
EXPLICIT Version DEFAULT =
v1,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
...
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
extensions=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [3]=C2=A0 EXPLICIT Extensions =
OPTIONAL
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- If present, version =
MUST be =
v3
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
}

As mentioned on July 19 (see = other email below), the CsrAttrs syntax gives quite some = needless

freedom how to = represent multiple X.509 extensions (and potentially other types of = attributes).

 

I = believe we should clarify that

  • There MUST be at most one attribute describing X.509 = extensions,
    i.e., one bearing the OID extensionRequest = (1.2.840.113549.1.9.14) as its type.
  • The set in such an X.509 extension value MUST contain = exactly one element.
  • The value of such an attribute MUST be of type Extensions, = i.e., a sequence of Extension.

In this light, = I've just updated the example to reflect the type SEQUENCE OF = Extension
and extended it with two (non-critical) extensions to make = it more general/educative:

SEQUENCE {
  SEQUENCE = {
    OBJECT IDENTIFIER extensionRequest (1 2 840 = 113549 1 9 14)
    SET = {
      SEQUENCE = {
        SEQUENCE = {
          OBJECT = IDENTIFIER basicConstraints (2 5 29 = 19)
          OCTET = STRING, encapsulates = {
            = SEQUENCE = {}
            = }
          = }
        SEQUENCE = {
          OBJECT = IDENTIFIER extKeyUsage (2 5 29 = 37)
          OCTET = STRING, encapsulates = {
           = SEQUENCE = {
           &n= bsp;  OBJECT IDENTIFIER serverAuth (1 3 6 1 5 5 7 3 = 1)
           &= nbsp; = }
            = }
          = }
        SEQUENCE = {
          OBJECT = IDENTIFIER subjectAltName (2 5 29 = 17)
          [0] = {
            = BOOLEAN = TRUE
           = ; }
          OCTET = STRING, encapsulates = {
            = SEQUENCE = {
           &n= bsp;  [2] = 'domain.example'
         = ;     = }
            = }
          = }
        = }
      }
    }
  = }

Moreover, we = might specify what an empty list of X.509 extensions means,
such as = to express that no X.509 extensions should/must be used in the = CSR.

 

    David

 

 

On 31.07.22 19:40, David von Oheimb = wrote:

Hi Michael et = al.

On 29.07.22 20:45, Michael = Richardson wrote: 

   =
Attribute { ATTRIBUTE:IOSet } ::=3D SEQUENCE =
{
        =
extType  =
ATTRIBUTE.&id({IOSet}),
    =
    extAttr  SET SIZE(1..MAX) OF =
ATTRIBUTE.&Type({IOSet}{@type})
   =
}
Well, this definition is =
semantically identical to the original one.
So =
better not rename the two fields of the Attribute structure, i.e., =
we
should stick with 'type' and =
'values',
in particular since there may be =
attributes that are not =
X.509
extensions.
=
I found it clearer, but if you object to this rename, then I'll go with =
your preference.

Let's keep the original = field names.
Also because this underlines the important fact that we = do not change the ASN.1 syntax at all,
which is critical for = bits-on-the-wire compatibility, but we just clarify its use and = interpretation.

I've just made a pass on = lamps-rfc7030-csrattrs.mkd in the GitHub repository.
Its new version = contains various suggestions for improvements here and there.
Also = updated the subjectAltName example to be of the more usual form of a = dNSName
and inserted two = questions/remarks:

   (TODO: Do we want to = allow an empty extnValue (which is of type OCTET
   = STRING), which would mean that the client is told to include an = X.509
   extension of the given type and fill in the = concrete value itself?)

   (TODO: Note that this = mechanism does not support telling the client
   to include = in the CSR a specific subject DN, simply because there = is
   no OID for this.  I think we should better make = this clear, or we
   have to define such an OID if setting = a subject name should be
   supported.)

I = also corrected the spelling of my (co-author's) name in = presentations/ietf114-lamps-csrattrs.{fodp,pdf}.

 &= nbsp;  David

 


On Tue, 2022-07-19 at 20:58 +0200, David von = Oheimb wrote:

Hi Michael, Sean, et al.,

 

on Sun, 2022-07-10 at 22:18 -0400, Michael Richardson = wrote:

 

Sean, sorry to be asking this with less than 24h to ID = cut-off.

I didn't want to = post an updated ID until I had example code that = produced

what I *thought* = you are suggesting.  Moving a SEQ/SET around isn't = that

hard... only now I've = confused myself.

 

We had:

 

   CsrAttrs ::=3D SEQUENCE SIZE (0..MAX) OF = AttrOrOID

 

   AttrOrOID ::=3D CHOICE (oid OBJECT = IDENTIFIER,

         &= nbsp;           &n= bsp;   attribute Attribute }

 

   Attribute { ATTRIBUTE:IOSet } ::=3D = SEQUENCE {

        = extType  ATTRIBUTE.&id({IOSet}),

        = extAttr  SET SIZE(1..MAX) OF = ATTRIBUTE.&Type({IOSet}{@type})

   = }

 

Well, this definition is semantically identical to the = original one.
So better not rename the two fields of the Attribute = structure, i.e., we should stick with 'type' and 'values',
in = particular since there may be attributes that are not X.509 = extensions.


According = to https://datatracker.ietf.org/doc/html/draft-richa= rdson-lamps-rfc7030-csrattrs
the only thing that is = "changed" is the clarification that the attributes may contain = entire X.509 extensions.

So BTW I believe we can and should claim that this is = bit-on-the wire compatible with RFC 7030.

 

 

with the understanding that extAttr could be a SET of = Extensions.

 

Better also state that in this case the type/extType = field MUST bear the value extensionRequest = (1.2.840.113549.1.9.14).

 

 

Each Extension is given = by:

 

   Extensions  ::=3D  SEQUENCE = SIZE (1..MAX) OF Extension

 

The Extensions structure is only needed = within certificates (where there is just one extensions field).
All = needed here is the Extension structure - there are already more than = enough of those sequences and sets around 3D";-)"

 

   Extension  ::=3D  = SEQUENCE  {

        = extnID      OBJECT = IDENTIFIER,

        = critical    BOOLEAN DEFAULT = FALSE,

        = extnValue   OCTET STRING

         &= nbsp;          -- contains = the DER encoding of an ASN.1 value

         &= nbsp;          -- = corresponding to the extension type = identified

         &= nbsp;          -- by = extnID

        = }

 

 

1) I'm not sure why I need a SET of a Sequence, unless = your intent was that

   extAttr could be an *Extension* ??  = I'm gonna go with yes here, but I

   didn't code that = yet.

 

In my view, the = set-valued 

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 extAttr SET SIZE(1..MAX) OF = ATTRIBUTE.&Type({IOSet}{@type})

(or better, as in the original definition in = 7030):

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 values SET SIZE(1..MAX) OF = ATTRIBUTE.&Type({IOSet}{@type})

 

is not really needed because multiple attributes = can be given anyway using multiple attributes, and each of them may then = have a different type.
If multiple values are given as a set within a = single attribute, all its elements must have the same type.
So in = practice I suppose that for all attributes the SETs given within each of = them usually will have just one value = element.

 

 

2) I think that extnID would be things like = subjectAltName,

   i.e. OID: = 2.5.29.17

 

Right.

 

 

But, if so, what is extType for = this?

 

The (ext)type is needed to provide the information, = using "extensionRequest", that an X.509 extension is = being given in this attribute.

 

 

 

ASN1 that I have right now, where I've put = subjectAltName in twice:

 

obiwan-[projects/pandora/fountain](2.6.6) mcr 10396 = %dumpasn1 tmp/csr_bulb1.der

  0  84: SEQUENCE = {

  2  = 82:   SEQUENCE {

  4   3:     OBJECT = IDENTIFIER subjectAltName (2 5 29 17)  <--- WHAT GOE, uS = HERE?

Replace = this by                   =       extensionRequest = (1.2.840.113549.1.9.14)

 

 

  9  75:     SET = {

 11  = 73:       SEQUENCE {   <--- = SEQUENCE here might be = undesired.

SEQUENCE here is fine, as demanded by the Extension = structure.

 

 13   = 3:         OBJECT IDENTIFIER = subjectAltName (2 5 29 17)

 18   = 3:         [0] = {

The "[0] {" (and the closing = 2}") is likely superfluous/wrong = here.

 20   = 1:           BOOLEAN = TRUE

       = :           = }

 23  = 61:         SEQUENCE = {

 25  = 59:           [0] = {

 27  = 57:           &nbs= p; UTF8String

       = :            =    'rfc8994+fd739fc23c3440112233445500000000+@acp.ex<= /span>'

       = :            =    'ample.com'

       = :            = }

       = :           = }

This = encoding of a SAN appears strange to me - which flavor of GeneralName = are you aiming at?

 

       = :         = }

       = :       }

       = :     }

       :   = }

 

- = David

------=_NextPart_001_01AA_01D8A64F.A48115E0-- ------=_NextPart_000_01A9_01D8A64F.A48115E0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD30w ggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0zMTEx MTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq9M71 IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii72r7IfJS Yd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+ WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh 5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Y d08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXr oq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqG SIb3DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwS TFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJ s13rsgkq6ybteL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLx vlBnt2y98/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76 jRslbWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIFbDCCBFSgAwIBAgIQ DodJIkPnW6h4YZSbQdr2xzANBgkqhkiG9w0BAQsFADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMM RGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2Vy dCBTSEEyIEFzc3VyZWQgSUQgQ0EwHhcNMjAxMDIzMDAwMDAwWhcNMjMxMDIyMjM1OTU5WjCBhzEL MAkGA1UEBhMCVVMxDTALBgNVBAgTBFV0YWgxDTALBgNVBAcTBExlaGkxFzAVBgNVBAoTDkRpZ2lD ZXJ0LCBJbmMuMRYwFAYDVQQDEw1Db3JleSBCb25uZWxsMSkwJwYJKoZIhvcNAQkBFhpjb3JleS5i b25uZWxsQGRpZ2ljZXJ0LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ7GS9HD 58ciFNyhdb9MJ0ekjSUVkaSrGSw2Q/E8euaolJrAuDzssxo+kMYAB2uITc+YQMLQKwsAVJn8KQvB yCGYbwhndp04d0g3l4Iz/E8NRtptBXWCCfcCvKeMW4ICHq8pT7MIYGudOPdfoeXZtCKmxNVWZldu vk+rQaur7Gjxy3K0eGikDr/Ob2pxwfbhO7+LRntPX2/+MGpIGF4MiKqFNLPYcT6FMN7Ls6YfNN19 3lbZbIcSwpMEVk/1lQ3x1pGhIZwifbuBt5jYU5g5WxQM36F33+FQyxdMqp7trNAuWmkvgYWBg52u O8a1bhAkztcGKNippFcDrf/q2/9QZXcCAwEAAaOCAfMwggHvMB8GA1UdIwQYMBaAFOcCI4AAT9jX vJQL2T90OUkyPIp5MB0GA1UdDgQWBBTIYooIDkqWAo6hnwewkz6XesZzXjAMBgNVHRMBAf8EAjAA MCUGA1UdEQQeMByBGmNvcmV5LmJvbm5lbGxAZGlnaWNlcnQuY29tMA4GA1UdDwEB/wQEAwIFoDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwQwYDVR0gBDwwOjA4BgpghkgBhv1sBAECMCow KAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMwgYgGA1UdHwSBgDB+MD2g O6A5hjdodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJlZElEQ0EtZzMu Y3JsMD2gO6A5hjdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJlZElE Q0EtZzMuY3JsMHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNl cnQuY29tMEMGCCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNlcnRT SEEyQXNzdXJlZElEQ0EuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQCAuLHhhfMKHzPgF7Z8KaLgLQI4 aT/31FRSD180x8ZTizYsL3LYsQh17OHLCcGCG3ng8GgU+6Ksfc6rLjiWU7LOfUQbAujzh+Tssvln Ef2TOKKa1ia3emDDLa3dT1PlHyZ7dEydKC3q6kI1sFijUiFZObHJIwiTvEtD2LQZMqTxobsqOcnZ uYk6gkFqkJht9V4rdQVrV5T9rM/n4HzO7Wg9kicBdMqT8rHlK0Jn1OOjZMmUvuTouTZwC+FWw835 YuwK6buxrRb7NrX8eHBSi0wYZ8odw+tNUpwQUCeB6J+SqRim3OOTqem1nIKDCoL4PfSzRUXNNI60 21pXraOzh8ipMIIGTjCCBTagAwIBAgIQBK55YGZmkBq5xX+mbFvczTANBgkqhkiG9w0BAQsFADBl MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNl cnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBBc3N1cmVkIElEIFJvb3QgQ0EwHhcNMTMxMTA1MTIw MDAwWhcNMjgxMTA1MTIwMDAwWjBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5j MRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFzc3Vy ZWQgSUQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc+BEjP2q178AneRstBYei EEMx3w7UFRtPd6Qizj6McPC+B47dJyq8AR22LArK3WlYH0HtagUf2mN4WR4iLCv4un7JNTtW8R98 Qn4lsCMZxkU41z1E+SB8YK4csFoYBL6PO/ep8JSapgxjSbZBF1NAMr1P5lB6UB8lRejxia/N/17/ UPPwFxH/vcWJ9b1iudj7jkUEhW2ZzcVITf0mqwI2Reo2119q4hqCQQrc6dn1kReOxiGtODwT5h5/ ZpzVTdlG2vbPUqd9OyTDtMFRNcab69TvfuR7A+FEvXoLN+BPy4KKDXEY5KbgiSwb87JzPMGwkp4Y fb2rfcV9CKEswp9zAgMBAAGjggL4MIIC9DASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB/wQE AwIBhjA0BggrBgEFBQcBAQQoMCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNv bTCBgQYDVR0fBHoweDA6oDigNoY0aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNz dXJlZElEUm9vdENBLmNybDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0 QXNzdXJlZElEUm9vdENBLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwggGzBgNV HSAEggGqMIIBpjCCAaIGCmCGSAGG/WwAAgQwggGSMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5k aWdpY2VydC5jb20vQ1BTMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAAbwBm ACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0AGUA cwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIAdAAg AEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0AHkA IABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIAaQBs AGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABlAHIA ZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMB0GA1UdDgQWBBTnAiOAAE/Y17yUC9k/ dDlJMjyKeTAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQsFAAOC AQEATtSJJ7n9HYd3fg8oBZDxCi/JOz69k5yQxq/6kVGHMlRr6MrBcVFcmY61+uBiGZmmB5p8Eyfb 5QKihBLZFfYKRFfENI9tcx861qABPd7jguRFa7LrJf2AXh05kL5bQvbOkWDj+aBWDEgQzjNoe82T q/Bqy09YD7l7XRsEgZ6nIuJXSSfukpMIvmkIUwI6Ll3IGfRQgE4C2bBdkbSTh/mWloFVQI5m7YLY uyhf7Uxh7QZYKBlTEUS8RyApsgRs2IlUmTt122d4LB6SeMZVPVgSETJuvUMMTTTbe8ZC2+y+q5th TAaS447fISpQVwTAYKI11SSeZjcJSc/V+GWz4OJuwjGCA78wggO7AgEBMHkwZTELMAkGA1UEBhMC VVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIG A1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOh0kiQ+dbqHhhlJtB2vbHMA0GCWCG SAFlAwQCAQUAoIICFzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0y MjA4MDIxMzA5NTlaMC8GCSqGSIb3DQEJBDEiBCASYKf9D38uPzTxSiObu46Jv2yAwy71qg2+o9Bd mu9ByjCBiAYJKwYBBAGCNxAEMXsweTBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQg SW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFz c3VyZWQgSUQgQ0ECEA6HSSJD51uoeGGUm0Ha9scwgYoGCyqGSIb3DQEJEAILMXugeTBlMQswCQYD VQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29t MSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEA6HSSJD51uoeGGUm0Ha9scw gZMGCSqGSIb3DQEJDzGBhTCBgjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMH MAsGCWCGSAFlAwQBAjAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwCwYJYIZIAWUDBAIB MAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEggEAfEH9 0YBa2PZvk7zj5mPuWyrnQOvVLoPowvWMdGGgKkoPI1F6ss0jkgNC4U+Sie9X+3XN+RDxtgp6X8Jo bI3zXugIRSZU1GpxqvevApwZ6RxNIpM4tIRm3ARrpZbrlBPfZ3FVUzPy0iw2Vo3yB/aWgshiJN1i j3G10pSdzxMdNSfXe4kNJflG+6jtSFvHg+F/1P+c+E9kqag/ub9E8XHV2W5Ky0nNBGteSITvfYRx 1eJL650YpjRmqGV18cVE5lz845KBUhW1UWJj7sf7NGKqE643BJIZwY4p2tqKb829BdzXgVcBUEfS 6AOwl5CmZSBns6GYtpsaDX29b+PtBvAnbQAAAAAAAA== ------=_NextPart_000_01A9_01D8A64F.A48115E0--