Re: [openssl-users] What does EC_KEY_get0_public_key deliver?
Am 09.01.2015 um 01:11 schrieb Matt Caswell: On 09/01/15 00:05, Christian Weber wrote: Thanks Matt, i just assumed the BIGNUMs were the coordinates without any projection - obviously that assumption was wrong - mislead by the funtions name. What interests me is to how you accessed the BIGNUMs in the first place! The EC_POINT structure is opaque and is defined in an internal header file!! Applications shouldn't be reaching into those. Matt Actually i imported the internal header so the structure was known. I marked the import as HACK to access exactly that EC_POINT structure. The hack was carried out because of the lack of knowledge about how to access the public key. I yust did not understand the intention for hiding the EC_POINT structure and didn't find information about how to access the coordinate values which i need to compare with coordinates from other sources (XML Dsig, Element ) or placing them elsewhere. So could you please give a hint or a pointer to where the intended access can be found? BTW: How does one find out which type of ECC is being used (binary or prime)? BTW2: Which compact representation of any public key would you recommend (for program internal comparisons)? Surely i will ban the internal header from my sources as they are not neccessary. Chris ___ openssl-users mailing list openssl-users@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] What does EC_KEY_get0_public_key deliver?
Thanks Matt, i just assumed the BIGNUMs were the coordinates without any projection - obviously that assumption was wrong - mislead by the funtions name. However, we're operating on brainpool curves, so the latter function should do the job. I'll lookup the parameters and try tomorrow. MfG -- Chris Am 08.01.2015 um 22:43 schrieb Matt Caswell : > > > On 08/01/15 17:16, Christian Weber wrote: >> Dear OpenSSL-Users, >> >> recently i found a pitfall using EC_KEY_get0_public_key(key->pkey.ec). >> The function just returns a copy to a pointer to key->pub_key which is a >> EC_POINT pointer. >> The key itself is taken from a certificate using EVP_PKEY *key = >> X509_get_pubkey(cert); >> >> Fine, i assumed, these must be coordinates of the publich key in the >> elements X and Y! >> Both are BIGNUMS as expected. > > How are you accessing the elements X and Y? The internal representation > could be transformed and you should make sure you are using the correct > functions to access them, i.e. one of: > > EC_POINT_get_affine_coordinates_GFp > or > EC_POINT_get_affine_coordinates_GF2m > > Which one to use depends on whether you are using a prime or binary curve. > > Matt > ___ > openssl-users mailing list > openssl-users@openssl.org > https://mta.openssl.org/mailman/listinfo/openssl-users ___ openssl-users mailing list openssl-users@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] What does EC_KEY_get0_public_key deliver?
Dear OpenSSL-Users, recently i found a pitfall using EC_KEY_get0_public_key(key->pkey.ec). The function just returns a copy to a pointer to key->pub_key which is a EC_POINT pointer. The key itself is taken from a certificate using EVP_PKEY *key = X509_get_pubkey(cert); Fine, i assumed, these must be coordinates of the publich key in the elements X and Y! Both are BIGNUMS as expected. BUT instead i got some tranformed coordinates. Finally i got the coordinates by using EC_POINT_point2hex() with the propoer group and converting its output. There seems to be no instantly accessible BIGNUM-pair represesentation of a ECDSA public key, which i would like to gain access to. What am i missing? Thanks in advance -- Chris ___ openssl-users mailing list openssl-users@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] OpenSSL with 64bit Instruction-Set and libraries for Windows? (solved)
Thanks for the response, meanwhile i have managed to generate 'pure' 64-bit openssl versions. In my case the configuration of the ide (VC2013) was simply wrong. I'm using the ide for viewing the code and for debugging purposes. When building the toolkit, the ide was used, too (makefile project). After switching to the proper platform (destination and sdk) and integrating the do_win64 script, the toolkit built flawlwssly. The dependencies are correct now whilst the referenced windows api dlls are still in the same place, e.g. \windows\system32\kernel32.dll. Semmingly the dlls do contain the code for multiple platforms like fat libraries under osx. Thank you -- Christian Weber ___ openssl-users mailing list openssl-users@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
OpenSSL with 64bit Instruction-Set and libraries for Windows?
Dear folks, as far as i can see, there is no true 64-bit support for building openssl (current version 1.0.1j). The contained file INSTALL.W64 states Win64 support as "initial". Following the build instructions i get a resulting makefile which is almost identical with the one generated for VC-WIN32. The compiled libraries remain being build against the 32-bit versions. So what am i missing? Is there any real support for Win64? Thanks in advance -- Christian Weber Security Software Abteilungsleiter Entwicklung mailto:we...@infotech.de -- Infotech Gesellschaft für Informations- und Datentechnik mbH Tel. +49-2361-9130-0 Fax +49-2361-9130-105 Geschäftsführer Rainer Hans Gerichtsstand Recklinghausen Amtsgericht Recklinghausen HRB 1912 USt.-IdNr. DE-811565628 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
SRP in OpenSSL 1.0.1
Dear users and developers, we just read through some of the code examples for SRP usage. Concerning the necessary callbacks we wonder why in s_server.c the verifier parametrization is being delayed. Within apps/s_server.c we can find the comment: "When the callback is called for a new connection we return with a negative value. This will provoke the accept etc to return with an LOOKUP_X509. The main logic of the reinvokes the suspended call (which would normally occur after a worker has finished) and we set the user parameters." There seems to be something missing between 'the' and 'reinvokes', so we cannot understand what's being meant. May it be a security impact to implement the lookup within the callback itself (as done in ssl/ssltest.c, based on user's password) or may there be other error conditions which are covered by relocating the lookup to init_ssl_connection in apps/s_cerver.c? Any opinions about possible security weakening against implementing the lookup within the callback? TIA -- Christian Weber __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: DIRECTORYSTRING and substitute in v1.0.0d
Dr. Stephen Henson schrieb am 22.03.2011 18:50: ... You shouldn't need that patch. I think your problem is: ASN1_OPT(X509_ADMISSION_PROF_INFO, professionOIDs, ASN1_OBJECTS), Which is making an item template optional. Try instead doing: ASN1_SEQUENCE_OF_OPT(X509_ADMISSION_PROF_INFO, professionOIDs, ASN1_OBJECT), Steve. Yes, your're absolutely right. Applying your definition, the proposed path becomes obsolete. Thank you. -- Christian Weber __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
timestamping DETACHED SMIME
Hi all, due to the new streaming support in OpenSSL 1.0.0d the calculations for completing the signature are delayed now. I guess streaming support was meant especially for DETACHED SMIME, but complicates the handling. The PKCS7_sign() routine still does most of the initialization on the p7 structure, but finalizing (i.e. call of PKCS7_final()) is intenionally delayed. Currently PKCS7_final() is called in the last line of SMIME_write_PKCS7(), which is (or at least previously was) the SMIME output routine. Due to this delay it seems difficult to add a timestamp over the signature which needs the signature value, of course. Does anyone know how to interfere the output generation to add an unsigned attribute (like a timestamp) when the signature is already created, but not yet written to the output? Alternatively the finalization might be performed within or right after PKCS7_sign(), just as in the old manner, but then the contents happens to be processed twice (hash calculation and signature processing) when the data is written, because the output routine heavily depends on the new auxiliary asn1 callback. Any hint? What am i missing? TIA -- Christian Weber __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: DIRECTORYSTRING and substitute in v1.0.0d
OK, found it on my own.
I was in need of automatic type checking of the built in multistring types at
parsing
time, i.e. when doing d2i_X509_TEMPLATE_TYPE(...) an templates for new
structures.
Just in case someone might be interested, i found a solution that works for me.
With some digging the code, i found the template type missing for ASN1
multistring types,
namely ASN1_PRINTABLE, DISPLAYTEXT and DIRECTORYSTRING.
I thing that can be obtained by adding:
#define DEFINE_ASN1_ITEM_TEMPLATE(tname) \
ASN1_ITEM_TEMPLATE(tname##) = ASN1_EX_TEMPLATE_TYPE(0, 0, tname##,
tname##)
DEFINE_ASN1_ITEM_TEMPLATE(DIRECTORYSTRING);
DEFINE_ASN1_ITEM_TEMPLATE(ASN1_PRINTABLE);
DEFINE_ASN1_ITEM_TEMPLATE(DISPLAYTEXT);
in my c source. So the correct types are being checked at parsing time.
The underlying types are all of ASN1_STRING. For use within the program, i
added:
typedef ASN1_STRING DIRECTORYSTRING;
typedef ASN1_STRING ASN1_PRINTABLE;
typedef ASN1_STRING DISPLAYTEXT;
in the headerfile. Together with the mentioned patch, concerning template
parsing,
functionality is a good bit enhaced.
Maybe some OM could review these little changes whether they are ok or should
be revised.
If the former, i would appreciate to see them in the mainstream.
Christian Weber wrote on 10.03.2011 at 18:40:
...
--- C:/wrk/openssl-1.0.0d/crypto/asn1/tasn_dec.cTue Jun 15
18:25:06 2010
+++ S:/Build/SAK-2.1/openssl-1.0.0d/crypto/asn1/tasn_dec.cThu Mar
10 01:26:40 2011
@@ -188,6 +188,8 @@
*/
if ((tag != -1) || opt)
{
+/* If OPTIONAL, assume this is OK Patch 5.2.2010 ChWe */
+if (opt) return -1;
ASN1err(ASN1_F_ASN1_ITEM_EX_D2I,
ASN1_R_ILLEGAL_OPTIONS_ON_ITEM_TEMPLATE);
goto err;
We wonder if this critical in any aspect? With the patch the lib still
seems to work for us.
TIA
--
Christian Weber
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
DIRECTORYSTRING and substitute in v1.0.0d
cal in any aspect? With the patch the lib still seems to work for us. What are we missing? Any hints? TIA -- Christian Weber __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
attributecertificate extensions
Dear OpenSSL users,
lately I ran into a problem when trying to parse attributecertificates (ACs).
ACs contain a sequence of attributes which look like x509v5 attributes.
I've decided to use parts of the AC implementation from Daniel Díaz-Sánchez
(downloable at http://www.it.uc3m.es/dds/swRelease/pmi/pmi.xml ). Which works
fine for me so far.
I've implemented some awareness of attribute types as defined by ISIS-MTT v1.1
of 16.3.2004 (which is still current) as additionalinformation, restriction,
monetarylimit, admission and others.
All works fine except for a special AC with the procuration attribute, which is
defined as follows:
ProcurationSyntax ::= SEQUENCE {
country [1] EXPLICIT PrintableString(SIZE(2)) OPTIONAL
typeOfSubstitution [2] EXPLICIT DirectoryString(SIZE(1..128)) OPTIONAL
signingFor [3] EXPLICIT SigningFor
}
SigningFor ::= CHOICE {
thirdPerson GeneralName
certRef IssuerSerial
}
but with exceptions to the type of the field thirdPerson which is't exactly
a GeneralName in sense of OpenSSL.
What I implemented is:
ASN1_CHOICE(X509_PROCURATION_SIGNINGFOR) = {
ASN1_SIMPLE(X509_PROCURATION_SIGNINGFOR, value.thirdPerson, GENERAL_NAME),
ASN1_SIMPLE(X509_PROCURATION_SIGNINGFOR, value.certRef,
X509AT_ISSUER_SERIAL)
} ASN1_CHOICE_END(X509_PROCURATION_SIGNINGFOR)
IMPLEMENT_ASN1_FUNCTIONS(X509_PROCURATION_SIGNINGFOR)
ASN1_SEQUENCE(X509_PROCURATION) = {
ASN1_EXP(X509_PROCURATION, country, ASN1_PRINTABLESTRING, 1),
ASN1_EXP(X509_PROCURATION, typeOfSubstitiution, DIRECTORYSTRING, 2),
ASN1_EXP(X509_PROCURATION, signingFor, X509_PROCURATION_SIGNINGFOR, 3)
} ASN1_SEQUENCE_END(X509_PROCURATION)
IMPLEMENT_ASN1_FUNCTIONS(X509_PROCURATION)
Conforming to RFC 3039 ISIS-MTT states for ACs:
ISIS-MTT PROFILE: The GeneralName MUST be of type directoryName and MAY only
contain:
- RFC3039 attributes, except pseudonym (countryName, commonName, surname,
givenName,
serialNumber, organizationName, organizationalUnitName,
stateOrProvincename,
localityName, postalAddress) and
- SubjectDirectoryName attributes (title, dateOfBirth, placeOfBirth, gender,
countryOfCitizenship, countryOfResidence and NameAtBirth).
The problem arises when it comes to parsing a dateOfBirth attribute, since is
of ASN1
type GENERALIZEDTIME. All other are (more or less) strings.
In OpenSSL GeneralName of Type GEN_DIRNAME is mapped to X509_NAME (see x509v3.h)
which only may hold string values, but no date value.
So parsing an AC which contains such an item, it results in parsing failure:
===
...
2008:error:0D07808C:asn1 encoding routines:ASN1_ITEM_EX_D2I:mstring wrong tag:
X:\openssl\openssl-0.9.8g\crypto\asn1\tasn_dec.c:228:
Type=ASN1_PRINTABLE
2008:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1
error:
X:\openssl\openssl-0.9.8g\crypto\asn1\tasn_dec.c:749:
Field=value, Type=X509_NAME_ENTRY
2008:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1
error:
X:\openssl\openssl-0.9.8g\crypto\asn1\tasn_dec.c:710:
2008:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1
error:
X:\openssl\openssl-0.9.8g\crypto\asn1\tasn_dec.c:710:
2008:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1
error:
X:\openssl\openssl-0.9.8g\crypto\asn1\tasn_dec.c:749:
2008:error:0D08403A:asn1 encoding routines:ASN1_TEMPLATE_EX_D2I:nested asn1
error:
X:\openssl\openssl-0.9.8g\crypto\asn1\tasn_dec.c:578:
2008:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error:
X:\openssl\openssl-0.9.8g\crypto\asn1\tasn_dec.c:338:
Field=d.directoryName, Type=GENERAL_NAME
2008:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1
error:
X:\openssl\openssl-0.9.8g\crypto\asn1\tasn_dec.c:749:
2008:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error:
X:\openssl\openssl-0.9.8g\crypto\asn1\tasn_dec.c:338:
Field=value.thirdPerson, Type=X509_PROCURATION_SIGNINGFOR
2008:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1
error:
X:\openssl\openssl-0.9.8g\crypto\asn1\tasn_dec.c:749:
2008:error:0D08403A:asn1 encoding routines:ASN1_TEMPLATE_EX_D2I:nested asn1
error:
X:\openssl\openssl-0.9.8g\crypto\asn1\tasn_dec.c:578:
Field=signingFor, Type=X509_PROCURATION
===
which is correct since GENERALIZEDTIME is not a string. In tasn_dec, line 227
ASN1_tag2bit
returns 0x8000 (B_ASN1_GENERALIZEDTIME) while it->utype is 0x00013d16
(B_ASN1_PRINTABLE, I guess).
How can I convince OpenSSL to accept dateOfBirth as allowable type in this case?
Any idea?
TIA
--
Christian
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
X509v3 extensions
Dear participators,
trying to add some x509v3 extension awareness tu openssl
we've become a bit short for solutions.
x509 extensions are as versatile as asn1 permits. As extension
to certificates there are an object id and a critical flag
followed by whatsoever.
If it comes to unknown oids at least the asn1parser comes short
for the structure and uses a OCTET_STRING replacement.
My question is: how may one implement an extension to make
openssl aware of yet unknown structures?
The idea was to ust the asn1 template classes together with
appropriate structures.
Given the case of following asn1 definition:
> ValidityModel::= SEQUENCE
> {
> validityModelIdOBJECT IDENTIFIER
> validityModelInfo ANY DEFINED BY validityModelId OPTIONAL
> }
I'se tried some variations of the structure:
> typedef struct X509ValidityModelInfo_st {
> STACK_OF(ASN1_OBJECT) *info;
> } X509VALIDITYMODELINFO;
>
> DECLARE_ASN1_ITEM(X509VALIDITYMODELINFO)
> DECLARE_ASN1_FUNCTIONS(X509VALIDITYMODELINFO)
together with the following code snippet
> ASN1_SEQUENCE(X509VALIDITYMODELINFO) = {
> ASN1_SET_OF(X509VALIDITYMODELINFO, info, ASN1_OBJECT),
> } ASN1_SEQUENCE_END(X509VALIDITYMODELINFO)
>
> IMPLEMENT_ASN1_FUNCTIONS(X509VALIDITYMODELINFO)
>
> int nid = OBJ_txt2nid("id-validityModel");
> int index = X509_get_ext_by_NID(cert, nid, -1);
> X509_EXTENSION *ext = X509_get_ext(cert, index);
>
> if (ext)
> {
> ASN1_OCTET_STRING *os = X509_EXTENSION_get_data(ext); // OK so far...
> const unsigned char *p = os->data;
> X509VALIDITYMODELINFO *mi = d2i_X509VALIDITYMODELINFO(NULL, &p,
> os->length);
> ...
never fetches a result. Surely there may be some mistakes, but I've tried more
than one variation, even with debugging sessions.
Sorry, I can't see anything.
BTW: Source is of Version 0.9.8g running with W2K compiled with VC8 express.
Does any of you have an idea or a hint? A good example could be excellent.
TIA
---
Christian
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: templates and cert chain validity
Hi again,
sorry, we just found the error in using the Macros.
When an asn structure is being parsed, the pointer to the funding
ASN_OCTET_STRING becomes modified and thus points no no freeable
memory.
Christian Weber schrieb am 10.07.2008 13:41:
...
To implement a validity checking which is aware of different models
shell as of RFC 3280 or chain as af ISIS-MTT.
...
Sinse the extension ID (validityModelID) is known, only the Info has to
be coded. I tried:
typedef struct X509ValidityModelInfo_st {
ASN1_OBJECT *info;
} X509VALIDITYMODELINFO;
DECLARE_ASN1_ITEM(X509VALIDITYMODELINFO)
DECLARE_ASN1_FUNCTIONS(X509VALIDITYMODELINFO)
together with
ASN1_SEQUENCE(X509VALIDITYMODELINFO) = {
ASN1_OPT(X509VALIDITYMODELINFO, info, ASN1_OBJECT),
} ASN1_SEQUENCE_END(X509VALIDITYMODELINFO)
IMPLEMENT_ASN1_FUNCTIONS(X509VALIDITYMODELINFO)
and using it with following code
int validityModelIsChain(X509 *_cert)
{
int iRet = 0;
int nid = OBJ_txt2nid("id-validityModel");
X509 *cert = X509_dup(_cert);// local copy
int index = X509_get_ext_by_NID(cert, nid, -1);
X509_EXTENSION *ext = X509_get_ext(cert, index);
if (ext)
{
ASN1_OCTET_STRING *os = X509_EXTENSION_get_data(ext);
X509VALIDITYMODELINFO *mi = 0;
d2i_X509VALIDITYMODELINFO(&mi, (const unsigned char **)&os->data,
os->length);
...
We must not fetch the pointer os->data directly, because it becomes
modified at d2i_...! Now we use:
const unsigned char *p = os->data;
d2i_X509VALIDITYMODELINFO(&mi, &p, os->length);
Afterwards p points to the end of the string at os->data.
Everything is working fine and freeable without memory leaks.
...
if (mi && mi->info)
{
char buf[60];
nid = OBJ_obj2nid(mi->info);
OBJ_obj2txt(buf, sizeof(buf), mi->info, 0);
printf("ValidityModel: %s\n", buf);
iRet = 1;
}
// X509VALIDITYMODELINFO_free(mi); // bad?
}
// X509_EXTENSION_free(ext); // bad, double-release!
X509_free(cert);// neccessary, else leak, but fails
return iRet;
}
...
I've been looking into the sources to find a place where the
cert chain checking is done in terms of the certs span of life.
Downwards the chain each cert should become valid while the issuers
cert is valid.
I thought the right place would be somewhere within x509_vfy.c,
perhaps at check_issued, but the search was in vain.
Is there any function to do a comparation of two ASN_TIME values
correctly though different formats and timezones may be in use?
...
For checking validity against RFC 3280 (shell model) no further time
comparison is needed. Each cert in a chain has to be valid at a certain
point in time (i.e. when used).
That's implemeted sufficiently.
Thanks to all
--
Christian
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
templates and cert chain validity
Hi there,
I'm just about verification of certs. Since X509v3 there are many
extensions with their own types. Some of them are known to the current
implementation, many aren't.
To implement a validity checking which is aware of different models
shell as of RFC 3280 or chain as af ISIS-MTT.
There are some OIDs that should be used to determine which model should
be used. One of them is 1.3.6.1.4.1.8301.3.5 (by TU Darmstadt, Germany)
which comes with this type:
ValidityModel::= SEQUENCE
{
validityModelIdOBJECT IDENTIFIER
validityModelInfo ANY DEFINED BY validityModelId OPTIONAL
}
Sinse the extension ID (validityModelID) is known, only the Info has to
be coded. I tried:
typedef struct X509ValidityModelInfo_st {
ASN1_OBJECT *info;
} X509VALIDITYMODELINFO;
DECLARE_ASN1_ITEM(X509VALIDITYMODELINFO)
DECLARE_ASN1_FUNCTIONS(X509VALIDITYMODELINFO)
together with
ASN1_SEQUENCE(X509VALIDITYMODELINFO) = {
ASN1_OPT(X509VALIDITYMODELINFO, info, ASN1_OBJECT),
} ASN1_SEQUENCE_END(X509VALIDITYMODELINFO)
IMPLEMENT_ASN1_FUNCTIONS(X509VALIDITYMODELINFO)
and using it with following code
int validityModelIsChain(X509 *_cert)
{
int iRet = 0;
int nid = OBJ_txt2nid("id-validityModel");
X509 *cert = X509_dup(_cert); // local copy
int index = X509_get_ext_by_NID(cert, nid, -1);
X509_EXTENSION *ext = X509_get_ext(cert, index);
if (ext)
{
ASN1_OCTET_STRING *os = X509_EXTENSION_get_data(ext);
X509VALIDITYMODELINFO *mi = 0;
d2i_X509VALIDITYMODELINFO(&mi, (const unsigned char **)&os->data,
os->length);
if (mi && mi->info)
{
char buf[60];
nid = OBJ_obj2nid(mi->info);
OBJ_obj2txt(buf, sizeof(buf), mi->info, 0);
printf("ValidityModel: %s\n", buf);
iRet = 1;
}
// X509VALIDITYMODELINFO_free(mi); // bad?
}
// X509_EXTENSION_free(ext); // bad, double-release!
X509_free(cert); // neccessary, else leak, but fails
return iRet;
}
I'm missing how to release the temporary items correctly.
Do you have any hints? Is the above approach reasonable?
==
I've been looking into the sources to find a place where the
cert chain checking is done in terms of the certs span of life.
Downwards the chain each cert should become valid while the issuers
cert is valid.
I thought the right place would be somewhere within x509_vfy.c,
perhaps at check_issued, but the search was in vain.
Is there any function to do a comparation of two ASN_TIME values
correctly though different formats and timezones may be in use?
Any hints?
TIA
--
Christian Weber
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
BN_LLONG use in pq_compat.h
Dear list users, sorry i'm a bit confused due to the meaning of BN_LLONG. We recently changed over to version 0.9.8. On a Windows environment with an old compiler that doesn't support 64 bit-integers (Borland C 5.01), we get compiling errors due to type PQ_64BIT (and SHA_LONG64 also) which seem to undefined. pq_compat.h contains: > #if (defined(THIRTY_TWO_BIT) && !defined(BN_LLONG)) || defined(SIXTEEN_BIT) > || defined(EIGHT_BIT) ...(some lines later)... > #define PQ_64BIT BIGNUM We read that as subtitute for native 64-bit integers. BN_LLONG is defined in opensslconf.h which in turn is included in pq_compat.h so the PQ_64BIT remains undefined. Is this a typo in ph_compat.h? How is BN_LLONG to be read? If defined - BNs shall be used instead of native 64-bit integers - or - - use native 64-bit integers (that are hopefully supported)? TIA -- Christian Weber Business Service Abteilungsleiter mailto:[EMAIL PROTECTED] -- Infotech Gesellschaft für Informations- und Datentechnik mbH Tel. +49-2361-9130-0 Fax +49-2361-9130-105 Geschäftsführer Rainer Hans Gerichtsstand Recklinghausen Amtsgericht Recklinghausen HRB 1912 USt.-IdNr. DE-811565628 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: PKCS7: decoding failed
Sorry again I missed to write that openssl asn1parse does work on the file. The file has been generated esternally (i.e. by german telesec), so we need to know what's wrong with the data to openssl. Marco Roeland wrote: > On Friday September 2nd 2005 Christian Weber wrote: > > >>i'm sorry but I cannot find the reason for the errors resulting in >>calling openssl (Version 0.9.7e or 0.9.8) as follows: >> >>openssl pkcs7 -noout -text -print_certs < decoded.b64 >>unable to load PKCS7 object > > > I have no idea either, but you might want to run > > openssl asn1parse -in decoded.b64 > > which does work on this input and compare the resulting fields and > identifiers with a PKCS7 file that you _can_ read. Perhaps the file was > created with different parameters than OpenSSL expects. Marco: What parameters are you writing about? TIA -- Christian Weber mailto:[EMAIL PROTECTED]Tel: 02361/91300 For information on InfoTech visit http://www.InfoTech.de/ __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
PKCS7: decoding failed
Hello folks, i'm sorry but I cannot find the reason for the errors resulting in calling openssl (Version 0.9.7e or 0.9.8) as follows: openssl pkcs7 -noout -text -print_certs < decoded.b64 unable to load PKCS7 object 5655:error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag:tasn_dec.c:1282: 5655:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error:tasn_dec.c:374:Type=X509_CINF 5655:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:743:Field=cert_info, Type=X509 5655:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:704:Field=cert, Type=PKCS7_SIGNED 5655:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:743: 5655:error:0D08403A:asn1 encoding routines:ASN1_TEMPLATE_EX_D2I:nested asn1 error:tasn_dec.c:572:Field=d.sign, Type=PKCS7 5655:error:0906700D:PEM routines:PEM_ASN1_read_bio:ASN1 lib:pem_oth.c:83: Ca anybody help? PKCS7 Object follows: -BEGIN PKCS7- MIIJOwYJKoZIhvcNAQcCoIIJLDCCCSgCAQExADALBgkqhkiG9w0BBwGgggkQMIIC aDCCAdSgAwIBAgIDMtGNMAoGBiskAwMBAgUAMG8xCzAJBgNVBAYTAkRFMT0wOwYD VQQKFDRSZWd1bGllcnVuZ3NiZWjIb3JkZSBmyHVyIFRlbGVrb21tdW5pa2F0aW9u IHVuZCBQb3N0MSEwDAYHAoIGAQoHFBMBMTARBgNVBAMUCjZSLUNhIDE6UE4wIhgP MjAwMTAyMDEwOTUyMTdaGA8yMDA1MDYwMTA5NTIxN1owbzELMAkGA1UEBhMCREUx PTA7BgNVBAoUNFJlZ3VsaWVydW5nc2JlaMhvcmRlIGbIdXIgVGVsZWtvbW11bmlr YXRpb24gdW5kIFBvc3QxITAMBgcCggYBCgcUEwExMBEGA1UEAxQKNlItQ2EgMTpQ TjCBoTANBgkqhkiG9w0BAQEFAAOBjwAwgYsCgYEAg6KrFSTNXKqe+2GKGeW2wTmb VeflNkp5H/YxA9K1zmEn5XjKm0S0jH4Wfms6ipPlURVaFwTfnB1s++AnJAWfmaya E9BP/pdIY6WtZGgW6aZc32VDMCMKPWyBNyagsJVDmzlakIA5cXBVa7Xqqd3Pew8i 2feMnQXcqHfDv02CW88CBQDBoxIwEDAOBgNVHQ8BAf8EBAMCAQYwCgYGKyQD AwECBQADgYEAOkqkUwdaTCt8wcJLA2zLuOwL5ADHMWLhv6gr5zEF+VckA6qeIVLV f8e7fYlRmzQd+5OJcGglCQJLGT+ZplI3Mjnrd4plkoTNKV4iOzBcvJD7K4tnXPvs 9wCFcC7QU7PLvc1FDsAlr7e4wyefZRDL+wbqNfI7QZTSF1ubLd9AzeQwggKBBgNV BCUwggJ4MIIB5KADAgECAgQBzUtJMAoGBiskAwMBAgUAMG8xCzAJBgNVBAYTAkRF MT0wOwYDVQQKFDRSZWd1bGllcnVuZ3NiZWjIb3JkZSBmyHVyIFRlbGVrb21tdW5p a2F0aW9uIHVuZCBQb3N0MSEwDAYHAoIGAQoHFBMBMTARBgNVBAMUCjZSLUNhIDE6 UE4wIhgPMjAwMzAyMTQxMjEwMTZaGA8yMDA3MDIxNDEyMTAxNlowfjELMAkGA1UE BhMCREUxHDAaBgNVBAoUE0RldXRzY2hlIFRlbGVrb20gQUcxHzAdBgNVBAsUFlBy b2R1a3R6ZW50cnVtIFRlbGVTZWMxMDAMBgcCggYBCgcUEwExMCAGA1UEAxQZVGVs ZVNlYyBQS1MgU2lnRyBDQSAxMzpQTjCBoTANBgkqhkiG9w0BAQEFAAOBjwAwgYsC gYEAhHMKdb6ayCIPINB8+nSJd3O8/QYSfQb76lg0dkRbnaD8IRk0jjEfttmRu+G8 ITjPMf0fCKckq8OzMdyc2X5DjfhjeSxhLatuJNJr78CdOLNh/t32Z12U4uoZZzz0 +U8AX583EBDe2Voliv0rUHc5dwA8qDNA6EQTm6fsQnmv/KMCBQDBoxIwEDAO BgNVHQ8BAf8EBAMCAQYwCgYGKyQDAwECBQADgYEATCdnfEanKI0HjJkef4Ht6zmQ A+WOLeOuE8x4jt79lY5I6hnqbpINc1YEn/AaQUFmMa2QmapOdMdJc9+SmC3N2ILh bFrQUrRvlcqGbNEVClfhXICfLvCG9tZQOVNZOyYTMDclE603TZSCXQvumAyil3Jw BTq6gJCYgSdxVPQ/ymUwggQbMIIDhKADAgECAgQvqpqzMA0GCSqGSIb3DQEBBQUA MH4xCzAJBgNVBAYTAkRFMRwwGgYDVQQKFBNEZXV0c2NoZSBUZWxla29tIEFHMR8w HQYDVQQLFBZQcm9kdWt0emVudHJ1bSBUZWxlU2VjMTAwDAYHAoIGAQoHFBMBMTAg BgNVBAMUGVRlbGVTZWMgUEtTIFNpZ0cgQ0EgMTM6UE4wHhcNMDUwODEwMTAzMTQw WhcNMDcwODEwMTAzMTQwWjBdMQswCQYDVQQGEwJERTEPMA0GA1UECgwGQk1XIEFH MRswGQYDVQQLDBJBYmZhbGxiZWF1ZnRyYWd0ZXIxFDASBgNVBAMMC0x1dGhlciwg SmFuMQowCAYDVQQFEwExMIGhMA0GCSqGSIb3DQEBAQUAA4GPADCBiwKBgQCJg5Ur Uafxq+s3TRnzuuHTxywd4RuIuDmwce/aSBknOleiUg+xCltLizqiUPzMAfvwgLTt mhQXkRCUkQeb9c3VVcm5ojPfEqf+tRX3Kk4iGl5MLfD2kvpe4giEdihtOszvwug4 jIep9lZMVvn3Moe2eJX+KSzltjENG7Qa8xch6QIFAMGjggHDMIIBvzAfBgNV HSMEGDAWgBSE1q6NOppzjbluxBqtx3uqxYSl8zCCAQQGA1UdHwSB/DCB+TCB9qBt oGuGNWxkYXA6Ly9wa3MtbGRhcC50ZWxlc2VjLmRlL289RGV1dHNjaGUgVGVsZWtv bSBBRyxjPWRlhjJodHRwOi8vcGtzLnRlbGVzZWMuZGUvdGVsZXNlYy9zZXJ2bGV0 L2Rvd25sb2FkX2NybKKBhKSBgTB/MQswCQYDVQQGEwJERTEcMBoGA1UEChQTRGV1 dHNjaGUgVGVsZWtvbSBBRzEfMB0GA1UECxQWUHJvZHVrdHplbnRydW0gVGVsZVNl YzExMAwGBwKCBgEKBxQTATEwIQYDVQQDFBpUZWxlU2VjIFBLUyBTaWdHIERJUiAx MzpQTjAYBggrBgEFBQcBAwQMMAowCAYGBACORgEBMB0GA1UdDgQWBBQVCH4Bv6y8 npyEobJ0keHmGXUWzDAOBgNVHQ8BAf8EBAMCBkAwEgYDVR0gBAswCTAHBgUrJAgB ATA3BggrBgEFBQcBAQQrMCkwJwYIKwYBBQUHMAGGG2h0dHA6Ly9wa3MudGVsZXNl Yy5kZS9vY3NwcjANBgkqhkiG9w0BAQUFAAOBgQAGYdA98xGQnZWAh79bEU7bwXer aXTKIDeam0FXeZcxKuQRy0Pu7ZnRXhmkQ1lQX5xc2ytbm0XRg6Ac20oD5Xs/mESG 5lF+dR4/JioXiYxVdgBLPXDp95xNUXC2etx4gtKDNtgVXA6BlyjvNZ6CrMV+32Uv C6ozizLMGeQzS+lM6jEA -END PKCS7- TIA -- Christian Weber mailto:[EMAIL PROTECTED]Tel: 02361/91300 For information on InfoTech visit http://www.InfoTech.de/ __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: MS VC 5: compilation fails
Dear Steven, you're right. MS VC5 compiler can't compile (at least portions of) openssl 0.9.8, but MS VC6 compiler does. Thank you! Steven Reddie wrote: > That error message tends to occur when the code is too complicated for the > compiler. You may be able to avoid the error by rearranging the code in > that module, but it's a hit and miss approach. Upgrading to a newer > compiler should fix the problem (since this builds fine under VC6 and up). > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Christian Weber > Sent: Wednesday, 13 July 2005 4:40 PM > To: openssl-users@openssl.org > Subject: MS VC 5: compilation fails > > Dear 0.9.8 users. > > Openssl 0.9.8 fails to compile under VC 5 with following compiler output: > >>C:\wrk\openssl-0.9.8>nmake -f ms\ntdll.mak >> >>Microsoft (R) Program Maintenance Utility Version 1.62.7022 >>Copyright (C) Microsoft Corp 1988-1997. All rights reserved. >> >>Building OpenSSL >>cl /Fotmp32dll\sha512.obj -Iinc32 -Itmp32dll /MD /W3 /WX /G5 >>/Ox /O2 /O >>b2 /Gs0 /GF /Gy /nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN >>-DL_ENDIAN >> -DDSO_WIN32 -DOPENSSL_USE_APPLINK -I. /Fdout32dll -DOPENSSL_NO_RC5 >>-DOPENSSL_NO >>_MDC2 -DOPENSSL_NO_KRB5 -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c >>.\crypto\sha\s ha512.c sha512.c >>.\crypto\sha\sha512.c(457) : fatal error C1001: INTERNAL COMPILER ERROR >>(compiler file 'E:\utc\src\\P2\regasg.c', line 660) >>Please choose the Technical Support command on the Visual C++ >>Help menu, or open the Technical Support help file for more >>information NMAKE : fatal error U1077: 'cl' : return code '0x2' >>Stop. > > > Is there any cure known? > > TIA > -- > Christian Weber > mailto:[EMAIL PROTECTED]Tel: 02361/91300 > For information on InfoTech visit http://www.InfoTech.de/ > __ > OpenSSL Project http://www.openssl.org > User Support Mailing Listopenssl-users@openssl.org > Automated List Manager [EMAIL PROTECTED] > > ______ > OpenSSL Project http://www.openssl.org > User Support Mailing Listopenssl-users@openssl.org > Automated List Manager [EMAIL PROTECTED] > -- Christian Weber mailto:[EMAIL PROTECTED]Tel: 02361/91300 For information on InfoTech visit http://www.InfoTech.de/ __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
MS VC 5: compilation fails
Dear 0.9.8 users. Openssl 0.9.8 fails to compile under VC 5 with following compiler output: > C:\wrk\openssl-0.9.8>nmake -f ms\ntdll.mak > > Microsoft (R) Program Maintenance Utility Version 1.62.7022 > Copyright (C) Microsoft Corp 1988-1997. All rights reserved. > > Building OpenSSL > cl /Fotmp32dll\sha512.obj -Iinc32 -Itmp32dll /MD /W3 /WX /G5 /Ox /O2 > /O > b2 /Gs0 /GF /Gy /nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN > -DL_ENDIAN > -DDSO_WIN32 -DOPENSSL_USE_APPLINK -I. /Fdout32dll -DOPENSSL_NO_RC5 > -DOPENSSL_NO > _MDC2 -DOPENSSL_NO_KRB5 -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c > .\crypto\sha\s > ha512.c > sha512.c > .\crypto\sha\sha512.c(457) : fatal error C1001: INTERNAL COMPILER ERROR > (compiler file 'E:\utc\src\\P2\regasg.c', line 660) > Please choose the Technical Support command on the Visual C++ > Help menu, or open the Technical Support help file for more information > NMAKE : fatal error U1077: 'cl' : return code '0x2' > Stop. Is there any cure known? TIA -- Christian Weber mailto:[EMAIL PROTECTED]Tel: 02361/91300 For information on InfoTech visit http://www.InfoTech.de/ __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Base64 encoding bug?
4oHhEXAy2aa72TsIZsfJX8BnhtEXlEsH3pt OTqButG4S8I6Xz9oloUfZ6vnN+KxuSSe7SBNAOXQeVUQB5QVe02oyfJFNYBFaVSd Iylg5f55otG1S5DS904A+VHKy17vluVNnySqxwFVzVUlTAsNAYIgfp5i3dp/wkaE ERYUQ2uo03alA4JWYaWqwjx7+3JNKa3oUUMdfz/SJ6e53fR5U95h68Tivos67Z4G vf4GpHckLBUPvw6Ru3oDhtFzbUGqx7vnulyZ9kvWJBJ0nl69w9pG+7H3q4Xe1XPb vwPL4YkoOlm5dnvWY8K18uTLnWFoiOoV3aFxGqEcY2F/P5IAgfpJASVJoYhn6CUY rZcfcEUTnNl8yG5U6SxRYA8w96bp2nCVch08JntbU2q2bouJGV15YgHaSFCWaEZ+ J5w+e2Si3h4q2aM4U8PJ84xR3BZUUyaMPw0gQF45kuVKNVkmR1t/QZVWo2WaQjye FCZLnQvf2Vmq9KvaDVNbc3yXaLi4vZxz95NKtJwRpEv+4brTiKwXrR4NF5CxqtLJ RVT7+FPMkl1vu1R2RwXD6j4ZHLlMy+Jr6ZEMb7UFxBRKWFwmVl3LWwGbmgbRfTMU 741D7nOR5epwe0L34caqgFGT8CT0wIdIsX+bbYI/Q9m/phvAK2LhAPiZgQ2Iegwa ToKrn7ciSTgSvG482O+7/Zl0Ljqo2l61bT04T3dYYGGmWaWbD6lwbN7VjGEuO2UU 0VM2opz27EqeYVNsgDHSYXpQ8hzKDW43Ch29dNm9jap2ZFKu0kFxyAU5If2Viz31 BH1LyT0rRBcUYcGTGcaLgzumYzXZYgDFgpGsNRnGcwnHZoRnLr64roZW+l2qkd57 GuX4A5Pb7M906QrQAyU1y9CTZYFhsTd1Q2BhHbJb5hsZHAoqSJLNj1V+r0GN+Is5 4N4NsJO1MNq8w6eEBHqvx7DMgaDAYwA9Rq/BGjbxb0vlFwLLlQ5E0f5cjP6JBvco XeW4vpbLuxdsugf8jKu0ysOfLE8QR+hSK6YX4iN3jQ/qXdx9q1TkeqaJjy/7WI9+ jPwfce80bZnHEPkIE1iH9/a22KCcwKE3WRXn/7rmEnra9kOy0AWOMoy1NJZXvG7X +Fweb5R5gTvGDmu3LDjdTRPu/H055gUNb8I7/jqwSZ/peB7KH8Tx9vQJ4fGmBwtq 3qMBVZG+X3LM3KfLBRFPX1m6/UYVehKtLQrr9LCiFuZp+0WiuIKnCSZvS5oTQsDh voFQ8doJ3tbhSxp2n+u4qNvC8vVXwyA+E1QDa7zDhbA3QN6zlN8shcYM5w+Zn6ll uxIqAAdPEJpESB0NqM7Gk4EUQbLX7XGM5RZ9VwFWNLjCiuJ11hPJ+31CnnW6Uhn1 Fk5vRjv2vKwf+5HUfuRZTC6juAGPTxAmNXqmElLVbtTzd/qyihCXinJNRbS5M6hX 2trc/1d/USV/RWLCOeaT5UWEnAcEVbDvf1eeHGJXT735MLuLgTnD+w9NAXED5Ui8 4hcKpvyDyJA+M75sE9+uYPTZOjPzM/Y4vJuqftfoiO1YXKX9dCe8jhwMV3dOZ2IT DwkTGybxPjNWQ0lVYapkCNnSZadhMSFwD61wMD2mBMqtGhvtalPPDX7MFqjdoS4E wZSmJevWRrUkfi+XclX51FuLmO620v9f6lTW637MCeqtf+O8UlihodprYDP5nbQL 0uIU7lBSebEQeaHEotMI+DmlhFoYmKE/ygwJJ5VnPIwu4cEuLXP63B0b9qCfh+rj weu4NvN2+LoGI+s1vm7AUBb3UPsObJ3QipGK59/k7/R5STFvlPBt9zCpir8p2B7l QfGVEDAOqzo5nVwc3xUkJULKB61MppDet5mCbw8jygOvgBxo0j/g+niIxbzOoH7L iKxLS0OehjE0VgBX9aN0xcnyzmDUjopgxnuUDufXtm/uuE9Q9/wpkfEXP6BZcHEU gh1GuNDvQFRv0KTeJcXeaBeoKSqaj1Sh0O9/BDLUVVSB0HJSqO5YynccTN+yNaKC N2oYWMl5dyt2ogE1jLeFBRA2vyt0cpzNgPPYKzBQF5hf/AxZ2PtkyNxt9P22AZTo wbJIgLj3ycHcCrBSzNu/GhCPByUDH6DwCCFxDfs0RCEvF7h755DMmxaAdjUDc+n6 PvKjG8A3u3E0kqe3s888FHg/3NouSzC+p62+4Lm/iZyJXZ7lZTKNRktBzL8Z9v4Q nxpUBmGmwt6SeRh/1O85WNaFgEcfyuQibCKxjzB3tZAJekmSii2EKP/MBA9z5Q3U qqtKgRFz0rGIUv1PDNi7aGsJozPBHc9sCfAdK9feG++jOgGTJtF7HAodB26ZPB3U ZHVjU3m2ezydO/ExN/50n/MUgu+9uWhJtQkTKQFd3agmgTBdjC85R3cHNCCQO4BG KB3tqpBqAO+GaA+++nQZzwGw4SbezKnaWXCIeoEUVG5VpfR3QQx5soS9KExr8L0c kaj1rYVEPH7bWvu6oV2ziQXMAj73IaTujkhTbybFdIlr4jUYE0NhE66v3v9ZMS09 /Bhxy+caWpyf5NViL73tNcrDVfM9tgE9PDmaySmvOyzehLa2Bka89NHQ+sRh+6oB XoyxFZg/V0Az39VN1ESwMqHZUhcuMUTVsY9c4xQHbJcv2Y5tylVYPips5lHE3tvr RX7U5Eer42qd1jaWM5vy4lZtW8iUqUIzvGYdZEK2jGiVtpGx7z98wo9AfKpCZKM+ MVtK/oixe9GJksDm+bi3tRhVueZfDLFlMApuBqwsqSXkVJJSD++3NOWQJkvTRAH7 nnG1d9aULRodW3iVbSkSOPXsECPb7u9D5WWs8OS3TZ7PvEKHEmVt3Qmd44hJsbXW 2yfLUrptSC1DcGrvvc9eRSb2g1o= . -- snapp -- Thanks in advance -- Christian Weber mailto:[EMAIL PROTECTED]Tel: 02361/91300 For information on InfoTech visit http://www.InfoTech.de/ __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
How to handle metadata when signing
Hi, when it comes to signing eg mails with openssl exactly the content (plaintext or binary block) happens to be signed. In case of attachments only the attached content is signed and in turn candidate for transmission. The metadata, especially the filename gets lost. What if you want (or need) some metadata? Where do you think are they properly located? For e-mail it could be somewhere within the mime-header, but the generic purpose of the header are to clarify how to handle the mime contents which is firstly some signed content. Do you have any proposal for such headerfields? Another approach is the signature itself. How about integrating the metadata within the signature's ASN structure? Do you hava any recommendation for location and propoer OIDs? Any hint to RFCs concerning this topic? TIA -- Christian Weber mailto:[EMAIL PROTECTED]Tel: 02361/91300 For information on InfoTech visit http://www.InfoTech.de/ __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Unresolved external EVP_sha1
We´re using openssl for a longer time now. With the current official version we´ve got a problem. Compilation under win with nasm and vc5 succeeds. Since our Project are Builder and bc5 Projects we call implib on the resulting dlls with implib -c -a libeay32.lib libeay32.dll and take the resulting lib into the borland projects. Since the latest version 0.9.7e of 10/25 we get an error message from the linker: "Unresolved external EVP_sha1" EVP_md5() and EVP_dss() both do work (with the same lib. Is this a known problem? Any Solution? Thanks in advance -- Christian Weber mailto:[EMAIL PROTECTED]Tel: 02361/91300 For information on InfoTech visit http://www.InfoTech.de/ __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
OCSP Response telesek
OK, the previous answer was pretty fast - thank you. Now there´s another stupid question: why does the command openssl ocsp -respin ocsp.resp -CAfile CAs.pem lead to Response Verify Failure 19961:error:27069070:OCSP routines:OCSP_basic_verify:root ca not trusted:ocsp_vfy.c:148: though the correct root ca cert (CN=6R-Ca 1:PN) is contained in CAs.pem ? The cert seems to be valid and the chain seems to be complete. What´s wrong? Again, the file (this time ocsp.resp) is contained in the following base64-block MIIG4QoBAKCCBtowggbWBgkrBgEFBQcwAQEEggbHMIIGwzCCATuhgYEwfzELMAkG A1UEBhMCREUxHDAaBgNVBAoUE0RldXRzY2hlIFRlbGVrb20gQUcxHzAdBgNVBAsU FlByb2R1a3R6ZW50cnVtIFRlbGVTZWMxMTAMBgcCggYBCgcUEwExMCEGA1UEAxQa VGVsZVNlYyBQS1MgU2lnRyBESVIgMjk6UE4YDzIwMDQwNjIyMDkyMzU3WjCBozCB oDA9MAkGBSsOAwIaBQAEFEYVRei2XiQgH+6qvRyBvvarzxqCBBQMmgzhg7+7+YBo G0Ifr7LFRSj/MAIEL62IToAAGA8yMDA0MDYyMjA5MjM1N1qhTDBKMBoGBSskCAMM BBEYDzIwMDMwNzI4MTUzNDU3WjAsBgUrJAgDDQQjMCEwCQYFKw4DAhoFAAQUb+qB 0hgaeFO1joALJOdZasdM19kwDQYJKoZIhvcNAQEFBQADgYEAdzL3St/c4Z+70yqn BPgFYKy7sGez+PKB2viy6ZtS5kZvoE6CJVnyyk6BHLlE8EoP7Cu8Zl67BHxPbAAj 3NXO/EgPZMZqwEVMju5JMBpDYE28+1s78D3PO5iSJJn5AXIKoTNkrhsvGZa/pOkC +BHsVauaGyHKyLWL+t9fNPf56H+gggTtMIIE6TCCAnkwggHloAMCAQICBAHlZ1kw CgYGKyQDAwECBQAwbzELMAkGA1UEBhMCREUxPTA7BgNVBAoUNFJlZ3VsaWVydW5n c2JlaMhvcmRlIGbIdXIgVGVsZWtvbW11bmlrYXRpb24gdW5kIFBvc3QxITAMBgcC ggYBCgcUEwExMBEGA1UEAxQKNlItQ2EgMTpQTjAiGA8yMDAzMDYzMDA5NTQzMFoY DzIwMDcwNjMwMDk1NDMwWjB/MQswCQYDVQQGEwJERTEcMBoGA1UEChQTRGV1dHNj aGUgVGVsZWtvbSBBRzEfMB0GA1UECxQWUHJvZHVrdHplbnRydW0gVGVsZVNlYzEx MAwGBwKCBgEKBxQTATEwIQYDVQQDFBpUZWxlU2VjIFBLUyBTaWdHIERJUiAyOTpQ TjCBoTANBgkqhkiG9w0BAQEFAAOBjwAwgYsCgYEAiq3HkxUwn7blTpZonuLR4j0h ertCeWBSVhnArFgbxaQij0I9402I7z3pOfjbS9YQcrpEC48psgjq0tTRStOGtaDh iKM5bwA6wl741OGR8yanm9YcGnm6hqHtUv0HIQoYmQxszm5mqUNaHdVKfwaz6s1p JK1I2Fwmvn77OX5NH18CBQDBoxIwEDAOBgNVHQ8BAf8EBAMCAQIwCgYGKyQD AwECBQADgYEAA2UJLezrN0h/iaa2fgGDQRu2tIl/EhYfBnwQQTzBJRw6GzyiGAXz 5EhmiPl13cbOrpHcU/Y5itQY9W53DEby1yqdSHAB0eGaFx4Qv9pOj0CTT76cNxWJ p0zAIyQG1fDMvFp8MkQDwXnFWcHhYy1UpLK66IScJdikZe++8pl03ccwggJoMIIB 1KADAgECAgMy0Y0wCgYGKyQDAwECBQAwbzELMAkGA1UEBhMCREUxPTA7BgNVBAoU NFJlZ3VsaWVydW5nc2JlaMhvcmRlIGbIdXIgVGVsZWtvbW11bmlrYXRpb24gdW5k IFBvc3QxITAMBgcCggYBCgcUEwExMBEGA1UEAxQKNlItQ2EgMTpQTjAiGA8yMDAx MDIwMTA5NTIxN1oYDzIwMDUwNjAxMDk1MjE3WjBvMQswCQYDVQQGEwJERTE9MDsG A1UEChQ0UmVndWxpZXJ1bmdzYmVoyG9yZGUgZsh1ciBUZWxla29tbXVuaWthdGlv biB1bmQgUG9zdDEhMAwGBwKCBgEKBxQTATEwEQYDVQQDFAo2Ui1DYSAxOlBOMIGh MA0GCSqGSIb3DQEBAQUAA4GPADCBiwKBgQCDoqsVJM1cqp77YYoZ5bbBOZtV5+U2 Snkf9jED0rXOYSfleMqbRLSMfhZ+azqKk+VRFVoXBN+cHWz74CckBZ+ZrJoT0E/+ l0hjpa1kaBbpplzfZUMwIwo9bIE3JqCwlUObOVqQgDlxcFVrteqp3c97DyLZ94yd Bdyod8O/TYJbzwIFAMGjEjAQMA4GA1UdDwEB/wQEAwIBBjAKBgYrJAMDAQIF AAOBgQA6SqRTB1pMK3zBwksDbMu47AvkAMcxYuG/qCvnMQX5VyQDqp4hUtV/x7t9 iVGbNB37k4lwaCUJAksZP5mmUjcyOet3imWShM0pXiI7MFy8kPsri2dc++z3AIVw LtBTs8u9zUUOwCWvt7jDJ59lEMv7Buo18jtBlNIXW5st30DN5A== thanks in advance again -- Christian Weber mailto:[EMAIL PROTECTED]Tel: 02361/91300 For information on InfoTech visit http://www.InfoTech.de/ __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
OSCP Resonse signtrust
d1bGllcnVuZ3NiZWjIb3JkZSBmyHVy IFRlbGVrb21tdW5pa2F0aW9uIHVuZCBQb3N0MSEwDAYHAoIGAQoHFBMBMTARBgNV BAMUCjVSLUNBIDE6UE4wgaEwDQYJKoZIhvcNAQEBBQADgY8AMIGLAoGBAIoeQVMn HwaaioVPEQ7Gkr1eQLc1nl0EQqJS/Qh97dAyp4YygJSfInHBbSTb/nd24fG2/bId JmkUqOuO8T+4bB04yoExOMzOQWDX170k+/TrXDIAM65w4ho0CCFr/MW31dTKscXb WScoK8M0TG/YxggBqCRMpqMswDDRu7UnQVp1AgUAwaMSMBAwDgYDVR0PAQH/ BAQDAgEGMAoGBiskAwMBAgUAA4GBADmivIoVUgVHC9iHVQcWWGFCsDM+Zux986oT fFvcPomn1rnR+m/mmoZGxDRMM4Nwt7+YPJ83u7+7LGnEM3uueyx4z/nu5LFAyIHE uEdaVNnjdem40j/6hjxd64ayBB6CuZyVC5I5GWE7TYjr5kP/hu9E1w4tzrP08C5V kb7vu2Cz Sorry, i had to code it this way to get it into the list. Thanks in advance -- Christian Weber mailto:[EMAIL PROTECTED]Tel: 02361/91300 For information on InfoTech visit http://www.InfoTech.de/ __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Howto add signed attributes in mails
Dear OpenSSL user, does anybody have a hint how to add a signed attribute during signing with smime? Further: which OID should be taken to add a attribute like "siged on behalf of..." or "representing (a function)". In which order should that OID be added to the other signed attirbutes (like signing time). In which way should the api be used to extract signed attributes from verfication process or during signing for visualization? Using smime (source), are the singed attributes in the p7 structure? How may we extraxt e.g. the signing time or the other signed attributes as mentioned above? Thanks for hints. -- Christian Weber mailto:[EMAIL PROTECTED]Tel: 02361/91300 For information on InfoTech visit http://www.InfoTech.de __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
BIO Handling
Dear OpenSSL users, we want to want to operate on the Contents of a memory BIO - eg digest - and tried out following implementation: - BIO *mb = BIO_new(BIO_s_mem()); // filling it with some data char* message="This is some data to digest"; BIO_write(mb, message, sizeof(message)); // after the memory bio has been filled BIO *dg = BIO_new(BIO_f_md()), *nul=BIO_new(BIO_s_null()); EVP_MD *md = EVP_md5(); BIO_set_md(dg,md); // get all out of the mb and diget it BIO_push(mb,dg); // append digesting to mem-BIO BIO_push(dg,nul); // get all out of digest-BIO // BIO chain should be: mem-dgst-nul // get the digest now char mdbuf[EVP_MAX_MD_SIZE]; BIO_gets(dg, mdbuf, EVP_MAX_MD_SIZE); - but the memory BIO stays filled, even after performing BIO_flush(mb) and the digest we get out of dg is the digesting start value. So what am I missing? How can the propagation of the memory data through the filter BIO be triggered? Thanks in advance -- Christian Weber mailto:[EMAIL PROTECTED]Tel: 02361/91300 For information on InfoTech visit http://www.InfoTech.de __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
