[openssl.org #764] Small OpenSSL
There is a minor error in my submission from two days ago, a missing newline character which needs to be printed into the modified apps/Makefile.ssl. the typo affects platforms which are built with the -DDSO_DLFCN compile option. Regards, Martin Here is the corrected Configure file, gzipped (See attached file: Configure.gz) __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
ASN1 implicit/explicit tagging
Hi all,
I have 2 versions of a DER-encoded pkcs7-enveloped-data and I would
like to know which one is correct:
I have attached their printable parsed form and they only differ
in one point, namely at the
EnvelopedData.encryptedContentInfo.encryptedContent component:
- the verExpl.txt encodes it as
[0] {
368 04 1312: OCTET STRING
: FE FE 9F 9C C5 C7 FC 28 FD B0 BA 4B 08 AF AD 3C
: E3 05 A6 89 FF 8A 9A C7 48 FC CC 7B 98 31 DA 3D
: F0 6A 82 6B 7A 47 32 53 F5 C6 F1 39 6B 77 C6 FE
: 8E B0 01 F4 15 9C 51 4A 72 12 71 51 5C 10 BC D4
: 9E F4 AD E5 B3 B1 B9 7F D5 26 BD E1 44 13 24 DD
: 30 A1 32 63 2D 65 B6 71 64 09 52 32 0D FB 6A 65
: 8F 71 86 72 C3 13 61 37 F4 EF E6 73 92 DB F5 7E
: 23 79 82 64 C6 4A 7B 3F BD 3A F6 6B C9 EE A9 14
: [ Another 1184 bytes skipped ]
: }
while the verImpl.txt encodes it as
[0]
: 19 83 FD 11 13 B8 20 3C ED C9 CB B7 3F 06 97 3B
: 46 C7 03 09 FE 24 B8 7B 1D B7 DD F6 05 68 81 85
: B4 21 70 95 6B AB A7 33 54 77 00 F5 D7 CC FC 5F
: 18 47 7E 63 41 94 22 A9 C7 5C 56 09 89 49 BD C7
: 67 D8 9B 48 82 B7 4B 64 F8 D9 11 F3 F8 AE 04 81
: E7 C1 4F 37 F0 37 36 D0 A3 B1 A9 DB 67 09 C1 64
: B6 E0 4B 2D 2A D6 47 2C 24 49 D5 7A 5E 4B 6F FF
: 0E 6E 8B D8 8E 58 85 E9 76 41 02 7D A1 A3 D4 AD
: [ Another 1192 bytes skipped ]
If I check the grammar of that objetct ([0] IMPLICIT EncryptedContent
OPTIONAL),
it seems that it is the verImpl.txt that is correct since IMPLICIT tagging
is used.
Am I correct?
Pierre De Boeck
Sr System Engineer
Cipherquest
email:[EMAIL PROTECTED]
BEGIN:VCARD
VERSION:2.1
N:De Boeck;Pierre
FN:Cipherquest
ORG:Cipherquest
TITLE:Sr System Engineer
TEL;WORK;VOICE:+352 (264) 78201
TEL;HOME;VOICE:+32 2 759 44 96
TEL;CELL;VOICE:+32 0479846599
TEL;WORK;FAX:+352 (264) 78202
ADR;WORK:;;Rue de l'eau 22;Luxembourg;;1449;Luxembourg
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:Rue de l'eau 22=0D=0ALuxembourg 1449=0D=0ALuxembourg
KEY;X509;ENCODING=BASE64:
MIIHFDCCBfygAwIBAgIBDjANBgkqhkiG9w0BAQUFADCBnTETMBEGCgmSJomT8ixkARkTA2Nv
bTEhMB8GCgmSJomT8ixkARkTEW1pc3Npb25jcml0aWNhbGl0MRkwFwYDVQQKExBNaXNzaW9u
IENyaXRpY2FsMQ4wDAYDVQQLEwVVc2VyczE4MDYGA1UEAxMvTWlzc2lvbiBDcml0aWNhbCBT
QSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkgVXNlcnMwHhcNMDIwNTMxMTIzODQ5WhcNMDUwNTMw
MTIzODQ5WjCBmzETMBEGCgmSJomT8ixkARkTA2NvbTEhMB8GCgmSJomT8ixkARkTEW1pc3Np
b25jcml0aWNhbGl0MRkwFwYDVQQKExBNaXNzaW9uIENyaXRpY2FsMQ4wDAYDVQQLEwVVc2Vy
czE2MBwGCgmSJomT8ixkAQETDnBpZXJyZS5kZWJvZWNrMBYGA1UEAxMPUGllcnJlIERlIEJv
ZWNrMFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBAOM/j+er1XEuDjwTzM5DrE/pu1PMH1ObaZCY
VDwzAuUVg5wxRFqK4vYbQkRoP3mbUDOlE9/LvZqBNh0WJkheFTUCAwEAAaOCBCUwggQhMBEG
CWCGSAGG+EIBAQQEAwIFoDAsBglghkgBhvhCAQIEHxYdaHR0cDovL3d3dy5taXNjcml0LmJl
L0NsYXZpcy8wOgYJYIZIAYb4QgEDBC0WK2RyQ2VydFNlcnZlci9kckNBL3Jldm9rZS5hc3A/
SWRDYT00JnNlcmlhbD0wOgYJYIZIAYb4QgEEBC0WK2RyQ2VydFNlcnZlci9kckNBL3Jldm9r
ZS5hc3A/SWRDYT00JnNlcmlhbD0wOQYJYIZIAYb4QgEHBCwWKmRyQ2VydFNlcnZlci9kckNB
L3JlbmV3LmFzcD9JZENhPTQmc2VyaWFsPTAyBglghkgBhvhCAQgEJRYjZHJDZXJ0U2VydmVy
L2RyQ0EvcG9saWN5LmFzcD9JZENhPTQwLgYJYIZIAYb4QgENBCEWH2EgdXNlciBjZXJ0IGZv
ciBQaWVycmUgRGUgQm9lY2swHQYDVR0OBBYEFPl9oN0hgQQpsBcvMqM1vtTmqa0EMC8GA1Ud
EQQoMCaBJHBpZXJyZS5kZWJvZWNrQG1pc3Npb25jcml0aWNhbGl0LmNvbTALBgNVHQ8EBAMC
BPAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMIHHBgNVHSMEgb8wgbyAFB3Gqkxo
8jPYniuQwaajND7lkzVJoYGgpIGdMIGaMRMwEQYKCZImiZPyLGQBGRMDY29tMSEwHwYKCZIm
iZPyLGQBGRMRbWlzc2lvbmNyaXRpY2FsaXQxGTAXBgNVBAoTEE1pc3Npb24gQ3JpdGljYWwx
CzAJBgNVBAsTAkNBMTgwNgYDVQQDEy9NaXNzaW9uIENyaXRpY2FsIFNBIFRydXN0IENlcnRp
ZmljYXRlIEF1dGhvcml0eYIBAzBdBgNVHRIEVjBUgQ5wZGVAbWlzY3JpdC5iZYZCaHR0cDov
L3d3dy5taXNjcml0LmJlL0NsYXZpcy9kckNlcnRTZXJ2ZXIvZHJDQS9ob21lcGFnZS5hc3A/
SWRDYT00MIHRBgNVHSAEgckwgcYwgcMGCisGAQQBolQBAQEwgbQwQwYIKwYBBQUHAgEWN2h0
dHA6Ly93d3cubWlzY3JpdC5iZS9DbGF2aXMvZHJDZXJ0U2VydmVyL2RyQ0EvQ1BTLmh0bWww
bQYIKwYBBQUHAgIwYTAaFhBNaXNzaW9uIENyaXRpY2FsMAYCAQECAQQaQ3RoaXMgaXMgYW4g
ZXhwZXJpbWVudGFsIGNlcnRpZmljYXRlIHBvbGljeSAoMS4zLjYuMS40LjEuNDQzNi4xLjEu
MSkwTgYDVR0fBEcwRTBDoEGgP4Y9aHR0cDovL3d3dy5taXNjcml0LmJlL0NsYXZpcy9kckNl
cnRTZXJ2ZXIvZHJDQS9jcmwuYXNwP0lkQ2E9NDANBgkqhkiG9w0BAQUFAAOCAQEAjAm35s2r
c8R0M/wqhgrhNQCfO0V2dRN9shFf4X/lYvMJEZi0kWWafSg8XnBlt4H48GyfwYqSweQHanqU
+uT1bf6WESqbSk7n3Dj5cwlWUUhyAeLkHBhlUu9b/IZWVUuUQ0ZpwbW+d6tIoyaA4mhNcMge
v/uKsNmUnY+ft5hrEpTnipJkVl0Tx8HazdtDM5/a03FNqEq7rBR6Zibg5JwXH+OXT1qaGRfX
HXNKR6sAJdZuf4DnnP4xwAqxViFOQhXdbEvN1kEJvCXmmVmLtmalSM7tjLbkbXIifSgHVz+F
YHUTUDMvKo8CIOtp/rJJAUEZdnbUYLey7UMnZbPIA+siw7==
KEY;X509;ENCODING=BASE64:
minor bug in apps/apps.c
Hello folks,
there seems to be a minor bug
in the pasword getter:
Bye
Goetz
Index: apps/apps.c
===
RCS file: /usr/cvsroot/openssl/apps/apps.c,v
retrieving revision 1.73
diff -u -r1.73 apps.c
--- apps/apps.c 2003/10/29 14:25:50 1.13
+++ apps/apps.c 2003/11/14 14:54:45
@@ -501,7 +501,7 @@
{
const char *password =
((PW_CB_DATA *)UI_get0_user_data(ui))-password;
- if (password[0] != '\0')
+ if (password password[0] != '\0')
{
UI_set_result(ui, uis, password);
return 1;
@@ -525,7 +525,7 @@
{
const char *password =
((PW_CB_DATA *)UI_get0_user_data(ui))-password;
- if (password[0] != '\0')
+ if (password password[0] != '\0')
return 1;
}
default:
--
Goetz Babin-Ebell, TC TrustCenter AG, http://www.trustcenter.de
Sonninstr. 24-28, 20097 Hamburg, Germany
Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126
smime.p7s
Description: S/MIME Cryptographic Signature
Re: Porting OpenSSL to Palm OS
I need the crypto portion. I have found the SSLEay 0.8.1 port to PalmOS. Is this the port you are talking about? What are the problems you faced? What are limitations of PalmOS you faced? I am new to PalmOS and we are using OpenSSL for some existing application which we need to port to PalmOS. ..Ram From: Arne Ansper [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Porting OpenSSL to Palm OS Date: Thu, 13 Nov 2003 20:09:22 +0200 (FLE Standard Time) I need OpenSSL on Palm OS. I have searched the archives and have found some references to people attempting to port to Palm OS. Has anyone ported it? What state is it in? And what problems did anyone face porting it to Palm? What parts do you need? Porting the complete OpenSSL is quite hard because of the PalmOS limitations. We did a port some years ago for Palm IIIx (I think that we got X.509 stuff and signing to work) and it was not so easy. But perhaps current Palm OS has less limitations and is easier to work. Arne __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] _ Concerned that messages may bounce because your Hotmail account is over limit? Get Hotmail Extra Storage! http://join.msn.com/?PAGE=features/es __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: ASN1 implicit/explicit tagging
On Fri, Nov 14, 2003, Pierre De Boeck wrote:
Hi all,
I have 2 versions of a DER-encoded pkcs7-enveloped-data and I would
like to know which one is correct:
I have attached their printable parsed form and they only differ
in one point, namely at the
EnvelopedData.encryptedContentInfo.encryptedContent component:
- the verExpl.txt encodes it as
[0] {
368 04 1312: OCTET STRING
: FE FE 9F 9C C5 C7 FC 28 FD B0 BA 4B 08 AF AD 3C
: E3 05 A6 89 FF 8A 9A C7 48 FC CC 7B 98 31 DA 3D
: F0 6A 82 6B 7A 47 32 53 F5 C6 F1 39 6B 77 C6 FE
: 8E B0 01 F4 15 9C 51 4A 72 12 71 51 5C 10 BC D4
: 9E F4 AD E5 B3 B1 B9 7F D5 26 BD E1 44 13 24 DD
: 30 A1 32 63 2D 65 B6 71 64 09 52 32 0D FB 6A 65
: 8F 71 86 72 C3 13 61 37 F4 EF E6 73 92 DB F5 7E
: 23 79 82 64 C6 4A 7B 3F BD 3A F6 6B C9 EE A9 14
: [ Another 1184 bytes skipped ]
: }
while the verImpl.txt encodes it as
[0]
: 19 83 FD 11 13 B8 20 3C ED C9 CB B7 3F 06 97 3B
: 46 C7 03 09 FE 24 B8 7B 1D B7 DD F6 05 68 81 85
: B4 21 70 95 6B AB A7 33 54 77 00 F5 D7 CC FC 5F
: 18 47 7E 63 41 94 22 A9 C7 5C 56 09 89 49 BD C7
: 67 D8 9B 48 82 B7 4B 64 F8 D9 11 F3 F8 AE 04 81
: E7 C1 4F 37 F0 37 36 D0 A3 B1 A9 DB 67 09 C1 64
: B6 E0 4B 2D 2A D6 47 2C 24 49 D5 7A 5E 4B 6F FF
: 0E 6E 8B D8 8E 58 85 E9 76 41 02 7D A1 A3 D4 AD
: [ Another 1192 bytes skipped ]
If I check the grammar of that objetct ([0] IMPLICIT EncryptedContent
OPTIONAL),
it seems that it is the verImpl.txt that is correct since IMPLICIT tagging
is used.
Am I correct?
Well yes and no. If it was an IMPLICIT and EXPLICIT issue then yes it should
be IMPLICIT. However from your attachment:
366 A0 NDEF: [0] {
368 04 1312: OCTET STRING
: FE FE 9F 9C C5 C7 FC 28 FD B0 BA 4B 08 AF AD 3C
: E3 05 A6 89 FF 8A 9A C7 48 FC CC 7B 98 31 DA 3D
: F0 6A 82 6B 7A 47 32 53 F5 C6 F1 39 6B 77 C6 FE
: 8E B0 01 F4 15 9C 51 4A 72 12 71 51 5C 10 BC D4
: 9E F4 AD E5 B3 B1 B9 7F D5 26 BD E1 44 13 24 DD
: 30 A1 32 63 2D 65 B6 71 64 09 52 32 0D FB 6A 65
: 8F 71 86 72 C3 13 61 37 F4 EF E6 73 92 DB F5 7E
: 23 79 82 64 C6 4A 7B 3F BD 3A F6 6B C9 EE A9 14
: [ Another 1184 bytes skipped ]
The first thing to notice here is that NDEF. This is therefore not DER but
BER: NDEF is not allowed in DER.
That might indeed be an explicitly tagged octet string with an indefinte length
construted outer tag enclosing a definite length octet string. That would be
wrong, however I'd say that isn't the case here.
What IMHO is much more likely is that it is an implicitly tagged indefinite
length *constructed* octet string which would be perfectly acceptable.
It isn't actually possible to distinguish between the two because they both
have the same encoding.
So the probable answer to you question is that if DER is not compulsory then
both are correct.
Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Funding needed! Details on homepage.
Homepage: http://drh-consultancy.demon.co.uk
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
RE: ASN1 implicit/explicit tagging
Ok, I think that PKCS7 accepts both DER and BER.
So I suppose that the verImpl.txt is perfectly legal. Right?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Dr. Stephen Henson
Sent: Friday, November 14, 2003 5:53 PM
To: [EMAIL PROTECTED]
Subject: Re: ASN1 implicit/explicit tagging
On Fri, Nov 14, 2003, Pierre De Boeck wrote:
Hi all,
I have 2 versions of a DER-encoded pkcs7-enveloped-data and I would
like to know which one is correct:
I have attached their printable parsed form and they only differ
in one point, namely at the
EnvelopedData.encryptedContentInfo.encryptedContent component:
- the verExpl.txt encodes it as
[0] {
368 04 1312: OCTET STRING
: FE FE 9F 9C C5 C7 FC 28 FD B0 BA 4B
08 AF AD 3C
: E3 05 A6 89 FF 8A 9A C7 48 FC CC 7B
98 31 DA 3D
: F0 6A 82 6B 7A 47 32 53 F5 C6 F1 39
6B 77 C6 FE
: 8E B0 01 F4 15 9C 51 4A 72 12 71 51
5C 10 BC D4
: 9E F4 AD E5 B3 B1 B9 7F D5 26 BD E1
44 13 24 DD
: 30 A1 32 63 2D 65 B6 71 64 09 52 32
0D FB 6A 65
: 8F 71 86 72 C3 13 61 37 F4 EF E6 73
92 DB F5 7E
: 23 79 82 64 C6 4A 7B 3F BD 3A F6 6B
C9 EE A9 14
: [ Another 1184 bytes skipped ]
: }
while the verImpl.txt encodes it as
[0]
: 19 83 FD 11 13 B8 20 3C ED C9 CB B7 3F 06 97 3B
: 46 C7 03 09 FE 24 B8 7B 1D B7 DD F6 05 68 81 85
: B4 21 70 95 6B AB A7 33 54 77 00 F5 D7 CC FC 5F
: 18 47 7E 63 41 94 22 A9 C7 5C 56 09 89 49 BD C7
: 67 D8 9B 48 82 B7 4B 64 F8 D9 11 F3 F8 AE 04 81
: E7 C1 4F 37 F0 37 36 D0 A3 B1 A9 DB 67 09 C1 64
: B6 E0 4B 2D 2A D6 47 2C 24 49 D5 7A 5E 4B 6F FF
: 0E 6E 8B D8 8E 58 85 E9 76 41 02 7D A1 A3 D4 AD
: [ Another 1192 bytes skipped ]
If I check the grammar of that objetct ([0] IMPLICIT EncryptedContent
OPTIONAL),
it seems that it is the verImpl.txt that is correct since
IMPLICIT tagging
is used.
Am I correct?
Well yes and no. If it was an IMPLICIT and EXPLICIT issue then
yes it should
be IMPLICIT. However from your attachment:
366 A0 NDEF: [0] {
368 04 1312: OCTET STRING
: FE FE 9F 9C C5 C7 FC 28 FD B0 BA 4B
08 AF AD 3C
: E3 05 A6 89 FF 8A 9A C7 48 FC CC 7B
98 31 DA 3D
: F0 6A 82 6B 7A 47 32 53 F5 C6 F1 39
6B 77 C6 FE
: 8E B0 01 F4 15 9C 51 4A 72 12 71 51
5C 10 BC D4
: 9E F4 AD E5 B3 B1 B9 7F D5 26 BD E1
44 13 24 DD
: 30 A1 32 63 2D 65 B6 71 64 09 52 32
0D FB 6A 65
: 8F 71 86 72 C3 13 61 37 F4 EF E6 73
92 DB F5 7E
: 23 79 82 64 C6 4A 7B 3F BD 3A F6 6B
C9 EE A9 14
: [ Another 1184 bytes skipped ]
The first thing to notice here is that NDEF. This is therefore not DER but
BER: NDEF is not allowed in DER.
That might indeed be an explicitly tagged octet string with an
indefinte length
construted outer tag enclosing a definite length octet string.
That would be
wrong, however I'd say that isn't the case here.
What IMHO is much more likely is that it is an implicitly tagged
indefinite
length *constructed* octet string which would be perfectly acceptable.
It isn't actually possible to distinguish between the two because
they both
have the same encoding.
So the probable answer to you question is that if DER is not
compulsory then
both are correct.
Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Funding needed! Details on homepage.
Homepage: http://drh-consultancy.demon.co.uk
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: ASN1 implicit/explicit tagging
On Fri, Nov 14, 2003, Pierre De Boeck wrote: Ok, I think that PKCS7 accepts both DER and BER. Yes it does. BER is used for streamed content. Though some profiles may require DER. So I suppose that the verImpl.txt is perfectly legal. Right? They are both legal. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
