Re: [EXTERNAL] Re: Unusual certificates
> The second certificate seems garbaged at the 4th RDN of the > issuerName. > The Base64 edition might have added or deleted some characters. Sorry, looks like my manual word wrapping lost a character: -BEGIN CERTIFICATE- MIIHbDCCBVSgAwIBAgIIO7L2MrGOOTMwDQYJKoZIhvcNAQELBQAwgYAxCzAJBgNV BAYTAlBMMTgwNgYDVQQKDC9Qb2xza2EgV3l0d8Ozcm5pYSBQYXBpZXLDs3cgV2Fy dG/Fm2Npb3d5Y2ggUy5BLjEcMBoGA1UEAwwTQ1VaIFNpZ2lsbHVtIC0gUUNBMTEZ MBcGA1UEYQwQVkFUUEwtNTI1MDAwMTA5MDAeFw0xOTAyMjQyMzAwMDBaFw0yMTAy MjMyMzAwMDBaMHUxCzAJBgNVBAYTAlBMMRAwDgYDVQQEDAdTa2ltaW5hMRcwFQYD VQQqDA5KYWNlayBXb2pjaWVjaDEaMBgGA1UEBRMRUE5PUEwtNzQwNjAyMDgyMTQx HzAdBgNVBAMMFkphY2VrIFdvamNpZWNoIFNraW1pbmEwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDbTjEdIL21ctkfJ88d7EQDegNo5VLyPQXNSp5emoNI Uf/y+RiL47SrWxS/hqYLGLUlItMsA+VCyP/+Oi42nRXcsJrSZdVgqhZTaWTZca8m FOeujXy9eVvnAlnDDeofC5zAxYoW4fQI1/aPwmJ437bHWa6NR0iXT9j0caYfK8vr P+gLlakBJA5RV42mt4CBZMSiNNhA9KMi9UNbtqSzlPEpSJn8Vo2LWUe+yIlUcbCD gaQ5EVi8K7U0j5BLVQfVparZGi7C50V1ZPwWsYlu7v1PKHMDXPwUzOlwZ//UrxdR nv/AFgjLjxuS+FNvCOaiyr0EmxccLKFvqycvx6qOxFulAgMBAAGjggLyMIIC7jCB 2wYIKwYBBQUHAQMEgc4wgcswCAYGBACORgEBMAsGBgQAjkYBAwIBCjAIBgYEAI5G AQQwfAYGBACORgEFMHIwNhYwaHR0cDovL3d3dy5zaWdpbGx1bS5wbC9yZXBvenl0 b3JpdW0vUUNBMV9QRFMucGRmEwJFTjA4FjJodHRwOi8vd3d3LnNpZ2lsbHVtLnBs L3JlcG96eXRvcml1bS9RQ0ExX1BEU1BMLnBkZhMCUEwwFQYIKwYBBQUHCwIwCQYH BACL7EkBATATBgYEAI5GAQYwCQYHBACORgEGATBzBggrBgEFBQcBAQRnMGUwPgYI KwYBBQUHMAKGMmh0dHA6Ly9yZXBvLnNpZ2lsbHVtLnBsL3JlcG96eXRvcml1bS9x Y2ExXzIwMTcuY2VyMCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5zaWdpbGx1bS5w bDAdBgNVHQ4EFgQUVjnQyGMfM0fhHUvao3qe2tB5ZAMwCQYDVR0TBAIwADAfBgNV HSMEGDAWgBRC+k+GNoGdKKGeLRq1ULuqJ/KctDCB+QYDVR0gBIHxMIHuMIHrBgoq hGgBhvg9AAADMIHcMIHZBggrBgEFBQcCAjCBzAyByUt3YWxpZmlrb3dhbnkgY2Vy dHlmaWthdCBwb2RwaXN1IGVsZWt0cm9uaWN6bmVnbyBwb3dzdGHFgiB3IG9wYXJj aXUgbyBQb2xpdHlrxJkgVXPFgnVnIFphdWZhbmlhIENVWiBTaWdpbGx1bS4gVHJl xZvEhyBQb2xpdHlraSBDVVogU2lnaWxsdW0gem5hamR1amUgc2nEmSBwb2QgYWRy ZXNlbSBodHRwOi8vd3d3LnNpZ2lsbHVtLnBsL3JlcG96eXRvcml1bTBCBgNVHR8E OzA5MDegNaAzhjFodHRwOi8vY3JsLnNpZ2lsbHVtLnBsL3JlcG96eXRvcml1bS9x Y2ExXzIwMTcuY3JsMA4GA1UdDwEB/wQEAwIGQDANBgkqhkiG9w0BAQsFAAOCAgEA Jfef0HktjHsgL403s8XQggtqporvp5w2sZcQ+jCPb3h3xrztTjiUbIhw97No7u5J 5LV4pNuczzBynJYBeGQpYG/Tr37HNoCdQ+I8QfllF37O7MwCNWYbmenFjINIHogQ utizdHRIUDP5FY+3ZmTG0ZGz4Yi0Bw+6IEvLZM8SF7Ula9Bkyu/oF5SAN/h/f0t5 3PHIkqsiWG7xRUl9aBgyO8Q72r1tiY1aqfT665nRrOewXQHik9h1Fd/XwWtYZpnG hws8lFKGB/Dfa8BpXpx3hWdVgeUA75Spszt0Pcb0pCJyQ2x3F4VnphGv6p31VN5i d7M+nd3kUYuKHFjxVBWgiVlgeKrCD+wvM/jqNncW6ti6uXaeLM2WBI0FpLuT5ZD2 G5gtLZ8z3wI5BZsp07gl3ARD8EybcJVmVhxpfAcBgOTCoyhGbPKYIS0fmYYCzwFL St+I497avrAQtgDqDcCs1WlZWHts4dUudUJ8rV8uKgtVQUu0HofUZPjNPD8dJw6n 3YrVdsLleXQXKAJZCgti56lH+6eCsVs7fUNPAhnu3AHWvsBwFs/3DM3OBBXX5jtn 8miSC46ndNiq2hIsq+cvfVM4Qw57XDYgLWaINhI0QhluUqOAEDJmYitnesTfs3Ih /CCHBWG9Yw6XkaBk8TCks/OOuo9B9PFGt5wRasty/Ls= -END CERTIFICATE- This now reads correctly with OpenSSL. So the real error here was that sometimes OpenSSL accepts unwrapped base64, and sometimes not, but asn1parse never accepts it. Angus
Re: Unusual certificates
On 2020-06-25 13:25, Hubert Kario wrote:
On Thursday, 25 June 2020 12:15:00 CEST, Angus Robertson - Magenta
Systems Ltd wrote:
A client is having problems reading Polish Centum issued personal
certificates with OpenSSL 1.1.1, which read OK with 1.1.0 and earlier,
mostly.
Using PEM_read_bio_X509 with some of these certificates says
error::lib(0):func(0):reason(0), while the X509 command line
tool says 'unable to load certificate'. Some certificates work with
both methods.
Using the asn1parse command from any version of OpenSSL says 'Error:
offset out of range', while a Javascript based web tool is able to
decode the ASN1, but is perhaps more tolerant of errors.
So it seems there is something in the creation of these certificates
that OpenSSL has never liked, but until 1.1.1 was tolerated
sufficiently to allow them to be read.
This certificate reads OK in 1.1.1 but fails asn1parse:
works just fine for me with 1.1.1g
This certificate can not be read in 1.1.1 but is OK in 1.1.0.
but this one fails parsing
Is there a more tolerant way to read ASN1 than the asn1parse command?
asn1parse expects BER encoding, that already is the most lenient, while
still standards-compliant, encoding that is supported.
Given that it errors out with
139628293990208:error:0D07209B:asn1 encoding
routines:ASN1_get_object:too long:crypto/asn1/asn1_lib.c:91:
I'm guessing a mismatch between utf-8 and string encoding that makes
the lengths inconsistent. Some tools may just ignore them, but that
doesn't
make the certificate well-formed.
I have tried examining these two certificates with Peter Gutmann's
dumpasn1.c
and a generic hex dumper.
For the second certificate, dumpasn1.c complains about a badly encoded
SET at
file offset 0x8E (after Base64 decoding):
0008E 31 19
00090 05 c1 80 d5 41 18 43 04 15 90 55 14 13 0b 4d 4c
000A0 8d 4c 0c 0c 0c 4c 0e 4c 0c
000A9 07 85 c3 4c 4e 4c 0c
My manual attempt to recover from this results in the following
further failures:
Attempt1: Straight BER/DER:
SET {
NULL-object of a very huge length: The number of bytes is
0x80 d5 41 18 43 04 15 90 55 14 13 0b 4d 4c 8d 4c
0c 0c 0c 4c 0e 4c 0c 07 85 c3 4c 4e 4c 0c 8c 8d
0c 8c cc 0c 0c 0c 16 85 c3 4c 8c 4c 0c 8c 8c cc
8c cc 0c 0c 0c 16 8c 1d 4c 42 cc 02 41 80 d5 41
01
-- ERROR: This runs beyond end-of-file
-- ERROR: This runs beyond end-of-SET (0x19 bytes)
}
Attempt2: Assume length byte for zero length NULL object omitted:
SET { NULL-object with missing length-encoding of its zero length
private-tag-1 object with indefinite length
-- ERROR: This runs beyond end-of-SET (0x19 bytes)
}
Attempt3: Treat SET as an opaque blob
SET { -- Contents ignored }
ObjectDescriptor of length 0x151CC bytes
-- ERROR: This runs beyond end-of-file
Attempt4: Treat preceding string as encoded with length 1 too small
SET {
SEQUENCE {
OBJECT IDENTIFIER commonName -- 2.5.4.3
UTF8String 'CUZ Sigillum - QCA11'
-- WARNING: One byte beyond declared length of containing SEQUENCE
}
-- WARNING: One byte beyond declared length of containing SET
}
GraphicString '\c1\80\d5\41\18'
Application-tag-3 object of length 4 bytes: 0x15 90 55 14
PrintableString 4d 4c 8d 4c 0c 0c 0c 4c 0e 4c 0c
-- WARNING: Bad characters
ObjectDescriptor of length 0x151CC bytes
-- ERROR: This runs beyond end-of-file
-- WARNING: This runs beyond length of containing DN (0x80 bytes)
Attempt5: Treat preceding string as encoded with length 2 too small
SET {
SEQUENCE {
OBJECT IDENTIFIER commonName -- 2.5.4.3
UTF8String 'CUZ Sigillum - QCA11\19'
-- WARNING: 2 bytes beyond declared length of containing SEQUENCE
}
-- WARNING: 2 bytes beyond declared length of containing SET
}
NULL-object of a very huge length: The number of bytes is
0x80 d5 41 18 43 04 15 90 55 14 13 0b 4d 4c 8d 4c
0c 0c 0c 4c 0e 4c 0c 07 85 c3 4c 4e 4c 0c 8c 8d
0c 8c cc 0c 0c 0c 16 85 c3 4c 8c 4c 0c 8c 8c cc
8c cc 0c 0c 0c 16 8c 1d 4c 42 cc 02 41 80 d5 41
01
-- ERROR: This runs beyond end-of-file
-- WARNING: This runs beyond length of containing DN (0x80 bytes)
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
Re: [EXTERNAL] Re: Unusual certificates
The second certificate seems garbaged at the 4th RDN of the issuerName. The Base64 edition might have added or deleted some characters. Cordialement, Erwann Abalea Le 25/06/2020 16:00, « openssl-users au nom de Angus Robertson - Magenta Systems Ltd » a écrit : More information, the original certificates supplied by the end user had unwrapped base64 blocks, lines 2,500 long. I wrapped them for email. If I try the asn1parse command on the wrapped certificates, they now attempt to parse, the OK is fine, the bad one now gives an error message from asn1parse: Error in encoding 20236:error:0D07209B:asn1 encoding routines:ASN1_get_object:too long:crypto\asn1\asn1_lib.c:91: and error:09091064:PEM routines:PEM_read_bio_ex:bad base64 decode from PEM_read_bio_X509. The RFC says 'Parsers MAY handle other line sizes' but it would be good if OpenSSL gave a 'PEM line too long' error rather than no error. I'll change my library code to check for line ending in the base64 to give the user a polite message. Now the only problem is what is asn1 decoding unhappy with? Angus
Re: Unusual certificates
More information, the original certificates supplied by the end user had unwrapped base64 blocks, lines 2,500 long. I wrapped them for email. If I try the asn1parse command on the wrapped certificates, they now attempt to parse, the OK is fine, the bad one now gives an error message from asn1parse: Error in encoding 20236:error:0D07209B:asn1 encoding routines:ASN1_get_object:too long:crypto\asn1\asn1_lib.c:91: and error:09091064:PEM routines:PEM_read_bio_ex:bad base64 decode from PEM_read_bio_X509. The RFC says 'Parsers MAY handle other line sizes' but it would be good if OpenSSL gave a 'PEM line too long' error rather than no error. I'll change my library code to check for line ending in the base64 to give the user a polite message. Now the only problem is what is asn1 decoding unhappy with? Angus
Re: Unusual certificates
On Thursday, 25 June 2020 12:15:00 CEST, Angus Robertson - Magenta Systems Ltd wrote: A client is having problems reading Polish Centum issued personal certificates with OpenSSL 1.1.1, which read OK with 1.1.0 and earlier, mostly. Using PEM_read_bio_X509 with some of these certificates says error::lib(0):func(0):reason(0), while the X509 command line tool says 'unable to load certificate'. Some certificates work with both methods. Using the asn1parse command from any version of OpenSSL says 'Error: offset out of range', while a Javascript based web tool is able to decode the ASN1, but is perhaps more tolerant of errors. So it seems there is something in the creation of these certificates that OpenSSL has never liked, but until 1.1.1 was tolerated sufficiently to allow them to be read. This certificate reads OK in 1.1.1 but fails asn1parse: works just fine for me with 1.1.1g This certificate can not be read in 1.1.1 but is OK in 1.1.0. but this one fails parsing Is there a more tolerant way to read ASN1 than the asn1parse command? asn1parse expects BER encoding, that already is the most lenient, while still standards-compliant, encoding that is supported. Given that it errors out with 139628293990208:error:0D07209B:asn1 encoding routines:ASN1_get_object:too long:crypto/asn1/asn1_lib.c:91: I'm guessing a mismatch between utf-8 and string encoding that makes the lengths inconsistent. Some tools may just ignore them, but that doesn't make the certificate well-formed. -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic
Unusual certificates
A client is having problems reading Polish Centum issued personal certificates with OpenSSL 1.1.1, which read OK with 1.1.0 and earlier, mostly. Using PEM_read_bio_X509 with some of these certificates says error::lib(0):func(0):reason(0), while the X509 command line tool says 'unable to load certificate'. Some certificates work with both methods. Using the asn1parse command from any version of OpenSSL says 'Error: offset out of range', while a Javascript based web tool is able to decode the ASN1, but is perhaps more tolerant of errors. So it seems there is something in the creation of these certificates that OpenSSL has never liked, but until 1.1.1 was tolerated sufficiently to allow them to be read. This certificate reads OK in 1.1.1 but fails asn1parse: -BEGIN CERTIFICATE- MIIHXjCCBUagAwIBAgIIbBjyWVjJUvcwDQYJKoZIhvcNAQELBQAwgYAxCzAJBgNV BAYTAlBMMTgwNgYDVQQKDC9Qb2xza2EgV3l0d8Ozcm5pYSBQYXBpZXLDs3cgV2Fy dG/Fm2Npb3d5Y2ggUy5BLjEcMBoGA1UEAwwTQ1VaIFNpZ2lsbHVtIC0gUUNBMTEZ MBcGA1UEYQwQVkFUUEwtNTI1MDAwMTA5MDAeFw0xOTAzMTkwODUxMDBaFw0yMTAz MTgwODUxMDBaMGcxCzAJBgNVBAYTAlBMMREwDwYDVQQEDAhEWklFRFpJQzEPMA0G A1UEKgwGUkFGQcWBMRowGAYDVQQFExFQTk9QTC03NDExMDMwMDQ3MTEYMBYGA1UE AwwPUkFGQcWBIERaSUVEWklDMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAm94BNi+bv2+oUKzN27GV0+95sm1AuDKdiKw7M63HcnjL+YYLoQvhleD7KlZR 7ntZfJ05vpWpQWM0Pt54M1Y8sJQObg+tUDlulVi7nADOrUNb3Tgctq1vbou3OpIp xaQUtC9qNpQbGXkgJRr09/nh5h09n4vgsvtS6cKlFfMe/o6xtUeWPYm+oVoAq5sG in+aBSBdnd73v053kbdZcbDPXmOYuCr6O2MHi7p+McPg2KMJy+wfFX4SGSBJIAY2 Owt6mnIOCU6Y/dAUcbUDtNUTwq+gXL+zg7TdwkDDTohpnluNGfrYV5JYocHO63zo 3W/CyF/enCmNiC9QLakA22O04QIDAQABo4IC8jCCAu4wgdsGCCsGAQUFBwEDBIHO MIHLMAgGBgQAjkYBATALBgYEAI5GAQMCAQowCAYGBACORgEEMHwGBgQAjkYBBTBy MDYWMGh0dHA6Ly93d3cuc2lnaWxsdW0ucGwvcmVwb3p5dG9yaXVtL1FDQTFfUERT LnBkZhMCRU4wOBYyaHR0cDovL3d3dy5zaWdpbGx1bS5wbC9yZXBvenl0b3JpdW0v UUNBMV9QRFNQTC5wZGYTAlBMMBUGCCsGAQUFBwsCMAkGBwQAi+xJAQEwEwYGBACO RgEGMAkGBwQAjkYBBgEwcwYIKwYBBQUHAQEEZzBlMD4GCCsGAQUFBzAChjJodHRw Oi8vcmVwby5zaWdpbGx1bS5wbC9yZXBvenl0b3JpdW0vcWNhMV8yMDE3LmNlcjAj BggrBgEFBQcwAYYXaHR0cDovL29jc3Auc2lnaWxsdW0ucGwwHQYDVR0OBBYEFDFY 5Q2FMMXaCpCyXFmUT2qgyA0JMAkGA1UdEwQCMAAwHwYDVR0jBBgwFoAUQvpPhjaB nSihni0atVC7qifynLQwgfkGA1UdIASB8TCB7jCB6wYKKoRoAYb4PQAAAzCB3DCB 2QYIKwYBBQUHAgIwgcwMgclLd2FsaWZpa293YW55IGNlcnR5ZmlrYXQgcG9kcGlz dSBlbGVrdHJvbmljem5lZ28gcG93c3RhxYIgdyBvcGFyY2l1IG8gUG9saXR5a8SZ IFVzxYJ1ZyBaYXVmYW5pYSBDVVogU2lnaWxsdW0uIFRyZcWbxIcgUG9saXR5a2kg Q1VaIFNpZ2lsbHVtIHpuYWpkdWplIHNpxJkgcG9kIGFkcmVzZW0gaHR0cDovL3d3 dy5zaWdpbGx1bS5wbC9yZXBvenl0b3JpdW0wQgYDVR0fBDswOTA3oDWgM4YxaHR0 cDovL2NybC5zaWdpbGx1bS5wbC9yZXBvenl0b3JpdW0vcWNhMV8yMDE3LmNybDAO BgNVHQ8BAf8EBAMCBkAwDQYJKoZIhvcNAQELBQADggIBACQ+ancYPWmfVDB/PTrV D+nK8TX2HPcbgk/JrGJF0vaL+l9gTprg+3yMlfpcQfBXBsm7RwOEAK8LgaaFb7Ta WPD1635RoGaIZ36k6WgENUjFjANya3RIRSzcOjgpeQWc6SeA++NJjQFNh7J73LMG V5udFwpVug5yzP+LTlZZ/hoY2rN9xmY7QBn/cbgoNieRyUHbxq4zGifiJoVfKEiT Fxl/CoUfnngxsVIsvgxFmGdnMT2j0oBODKoXJ1A8oJAcg8KnYTzI7Dnt3a5cGypv n6V6tGv0IbHxdFu8nnsyNOSp1YhqTcfRzUGXf9NHyj6vyX4UR2ODJPccWC0uSufW 9KYio228yqj0IERG2mr8huJEBW/MEE3STmxT3R6a1OCAsVAPi3gL2yAXfn3Gdiam MLhj/WO3OD9OyiHqTY6+/md4vOHkHy7GnKlYIJblddtziv8ek9uH/imbOQIKDjLN Bvw3j9a55GHT/8+fow2vn31OmSfMWvikP4pntEvuMAwG2laTs19+gWdknt4Q3ma5 NTf9UnbQsFJAcW+gw3QWAmts5fZsQT806OyDvjt6jRlkmuIkeYRcYJ/E2Pg9oKx3 RiCIA1BQTImpYvbTJg9Q1DYQpbDGxDB9ENJDAyMNSIs85nBLvrri4rD6FC4Bz/m/ Og4GfIWH02DKEKBds/zPi+L5 -END CERTIFICATE- This certificate can not be read in 1.1.1 but is OK in 1.1.0. -BEGIN CERTIFICATE- MIIHbDCCBVSgAwIBAgIIO7L2MrGOOTMwDQYJKoZIhvcNAQELBQAwgYAxCzAJBgNV BAYTAlBMMTgwNgYDVQQKDC9Qb2xza2EgV3l0d8Ozcm5pYSBQYXBpZXLDs3cgV2Fy dG/Fm2Npb3d5Y2ggUy5BLjEcMBoGA1UEAwwTQ1VaIFNpZ2lsbHVtIC0gUUNBMTEZ BcGA1UEYQwQVkFUUEwtNTI1MDAwMTA5MDAeFw0xOTAyMjQyMzAwMDBaFw0yMTAyM jMyMzAwMDBaMHUxCzAJBgNVBAYTAlBMMRAwDgYDVQQEDAdTa2ltaW5hMRcwFQYDV QQqDA5KYWNlayBXb2pjaWVjaDEaMBgGA1UEBRMRUE5PUEwtNzQwNjAyMDgyMTQxH zAdBgNVBAMMFkphY2VrIFdvamNpZWNoIFNraW1pbmEwggEiMA0GCSqGSIb3DQEBA QUAA4IBDwAwggEKAoIBAQDbTjEdIL21ctkfJ88d7EQDegNo5VLyPQXNSp5emoNIU f/y+RiL47SrWxS/hqYLGLUlItMsA+VCyP/+Oi42nRXcsJrSZdVgqhZTaWTZca8mF OeujXy9eVvnAlnDDeofC5zAxYoW4fQI1/aPwmJ437bHWa6NR0iXT9j0caYfK8vrP +gLlakBJA5RV42mt4CBZMSiNNhA9KMi9UNbtqSzlPEpSJn8Vo2LWUe+yIlUcbCDg aQ5EVi8K7U0j5BLVQfVparZGi7C50V1ZPwWsYlu7v1PKHMDXPwUzOlwZ//UrxdRn v/AFgjLjxuS+FNvCOaiyr0EmxccLKFvqycvx6qOxFulAgMBAAGjggLyMIIC7jCB2 wYIKwYBBQUHAQMEgc4wgcswCAYGBACORgEBMAsGBgQAjkYBAwIBCjAIBgYEAI5GA QQwfAYGBACORgEFMHIwNhYwaHR0cDovL3d3dy5zaWdpbGx1bS5wbC9yZXBvenl0b 3JpdW0vUUNBMV9QRFMucGRmEwJFTjA4FjJodHRwOi8vd3d3LnNpZ2lsbHVtLnBsL 3JlcG96eXRvcml1bS9RQ0ExX1BEU1BMLnBkZhMCUEwwFQYIKwYBBQUHCwIwCQYHB ACL7EkBATATBgYEAI5GAQYwCQYHBACORgEGATBzBggrBgEFBQcBAQRnMGUwPgYIK wYBBQUHMAKGMmh0dHA6Ly9yZXBvLnNpZ2lsbHVtLnBsL3JlcG96eXRvcml1bS9xY 2ExXzIwMTcuY2VyMCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5zaWdpbGx1bS5wb DAdBgNVHQ4EFgQUVjnQyGMfM0fhHUvao3qe2tB5ZAMwCQYDVR0TBAIwADAfBgNVH SMEGDAWgBRC+k+GNoGdKKGeLRq1ULuqJ/KctDCB+QYDVR0gBIHxMIHuMIHrBgoqh GgBhvg9AAADMIHcMIHZBggrBgEFBQcCAjCBzAyByUt3YWxpZmlrb3dhbnkgY2Vyd
