Re: [openssl-users] Getting the Subject name length as a string.
Bonjour, On Wed, 6 Oct 2004 [EMAIL PROTECTED] wrote: Is there any function available in the openssl that gives the length of the entire subject-name as a string. Use X509_NAME_print_ex() with a memory BIO. The function X509_NAME_oneline expects the buffer and its size. In this case, we assume some size and get the name as a string. Using this function, there may be a chance of not getting the entire subject-name as a string. If you really want to use X509_NAME_oneline() (its usage is discouraged as per the man page), then specify a NULL buffer as its output, and it will be correctly allocated for you. -- Erwann ABALEA [EMAIL PROTECTED] - RSA PGP Key ID: 0x2D0EABD5 - ``Average programmers should be rounded up and placed in internment camps to keep them away from keyboards.'' Well known Linux personage __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Compiling openssl to Pocket PC 2003
Hello all, Im trying to compile openssl for use it with a .NET C# solution for Pocket PC 2003 (Windows CE4.20). Im using the MS eMbedded Visual C++ 4.0. Anyone already, had success with something like this? Gilson Cavalcanti Grupo TCI - Business Manager
Certificate fetching for bridge CA configuration
So, this is perhaps the most simple bridge PKI arrangement: +-+---++-+---+ |T| ||T| | +-+---++-+---+ | P Root++ +---+ Q Root| +-+| | +-+ v v +--+--+ +--+--+ (1) | (P Root) | | (Q Root) | +-+ +-+ | Bridge+--+--+ Bridge| +-+ | +-+ | +-+-+ v v +--+--+ +--+--+ | (Bridge) | | (Bridge) | +-+ +-+ ++ P Sign| | Q Sign++ |+-+ +-+| v v +--+--+ +--+--+ | (P Sign) | | (Q Sign) | +-+ +-+ | P End User | | Q End User | +-+ +-+ Here P and Q are two separate PKIs bridged by the bridge Bridge. Let an email sender (or an SSL server) be the offerer, and let the email reader (or the SSL client) be the relying party (latter is standard usage). An offerer in the Q PKI interacts with a relying party in the P PKI. The P relying party needs this certificate chain: +-+---+ |T| | Presumably this is configured into the relying +-+---+ party software, or available from a server that | P Root| is secure and trusted by users of the P PKI +-+ +-+ | (P Root) | (1) This is the toughie -- could be configured into +-+ the P relying party or fetched from P LDAP but | Bridge| is NOT reasonable for Q offerer to supply... +-+ +-+ | (Bridge) | The Q offerer could supply this along with the +-+ End User certificate | Q Sign| +-+ +-+ | (Q Sign) | The Q offerer would supply this +-+ | Q End User | +-+ So, where would you suspect the (1) certificate would be obtained? It is unreasonable for Q End User to supply it, since she does not necessarily know client is from P and so would have to supply EVERY other PKI's bridge certificate. Perhaps it could be loaded from a source named by an Authority Information Access extension in (what? the end user certificate, or the signing certificate?) The only other alternative I can see is to load all the bridge certificates (1) into all the relying parties. -- Charles B (Ben) Cranston mailto: [EMAIL PROTECTED] http://www.wam.umd.edu/~zben __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Certificate fetching for bridge CA configuration
In message [EMAIL PROTECTED] on Thu, 07 Oct 2004 15:20:52 -0400, Charles B Cranston [EMAIL PROTECTED] said: zben So, this is perhaps the most simple bridge PKI arrangement: zben zben +-+---++-+---+ zben |T| ||T| | zben +-+---++-+---+ zben | P Root++ +---+ Q Root| zben +-+| | +-+ zben v v zben +--+--+ +--+--+ zben (1) | (P Root) | | (Q Root) | zben +-+ +-+ zben | Bridge+--+--+ Bridge| zben +-+ | +-+ zben | zben +-+-+ zben v v zben +--+--+ +--+--+ zben | (Bridge) | | (Bridge) | zben +-+ +-+ zben ++ P Sign| | Q Sign++ zben |+-+ +-+| zben v v zben +--+--+ +--+--+ zben | (P Sign) | | (Q Sign) | zben +-+ +-+ zben | P End User | | Q End User | zben +-+ +-+ That diagram throws me off. I've a hard time figuring out what represents certificates, exactly, and it looks like you MIGHT imply that the a bridge certificate could be used directly to verify EE certificates, which is the wrong way to go about it. - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up. -- C.S. Lewis __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
'ml' is not recognized as an internal or external command, operable program or batch file. NMAKE : fatal error U1077: 'ml' : return code '0x1'
Greetings, I'm trying to compile OpenSSL for Windows. I am using openssl-0.9.7d Everything goes well until I get to the part about nmake -f ms\ntdll.mak The error message is: 'ml' is not recognized as an internal or external command, operable program or batch file. NMAKE : fatal error U1077: 'ml' : return code '0x1' Can anyone advise me on how to get around this. I am compiling on a Windows XP host using Microsoft C++ version 7 C:\openssl-source\openssl-0.9.7dnmake -f ms\ntdll.mak Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 Copyright (C) Microsoft Corp 1988-1998. All rights reserved. Building OpenSSL copy nul+ .\crypto\buildinf.h tmp32dll\buildinf.h nul .\crypto\buildinf.h 1 file(s) copied. ml /Cp /coff /c /Cx /Focrypto\md5\asm\m5_win32.obj .\crypto\md5\asm\m5_win32.asm 'ml' is not recognized as an internal or external command, operable program or batch file. NMAKE : fatal error U1077: 'ml' : return code '0x1' Stop. C:\openssl-source\openssl-0.9.7d
RE: 'ml' is not recognized as an internal or external command, operable program or batch file. NMAKE : fatal error U1077: 'ml' : return code '0x1'
I'm trying to compile OpenSSL for Windows. I am using openssl-0.9.7d Everything goes well until I get to the part about nmake -f ms\ntdll.mak The error message is: 'ml' is not recognized as an internal or external command, operable program or batch file. NMAKE : fatal error U1077: 'ml' : return code '0x1' ml.exe is MASM. You either don't have MASM or it's someplace not in your path. MASM is distributed by microsoft in several DDKs and in the processor pack for VC++. You can also configure OpenSSL not to use any assembly language code (I think the parameter is 'no-asm' to configure), and then it won't need MASM. DS __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: 'ml' is not recognized as an internal or external command, operable program or batch file. NMAKE : fatal error U1077: 'ml' : return code '0x1'
Look at: http://msdn.microsoft.com/visualc/productinfo/faq/default.aspx Where can I find MASM? In Visual C++ 6.0, Professional and Enterprise customers could get the Microsoft Assembler (MASM) by downloading VC++ 6.0 Processor Pack. Today MASM ships with Visual Studio .NET Professional and Enterprise as part of Visual C++. ML.EXE is located in the VC7\bin directory. Perhaps your path is just not setup correctly? Or perhaps you chose not to install it? DS __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: 'ml' is not recognized as an internal or external command, operable program or batch file. NMAKE : fatal error U1077: 'ml' : return code '0x1'
Hi Peter, I had the same problem a few months ago, there are two ways to go about this: 1- Since "ml" is messing as its not part of the standard VC++6 (assuming that's what you're using) you need to install MS VC+6 Processor Pack. Note that this requires the installation of either service pack 4 or 5 but NOT 6) 2- Which is easier! using the following command: ms\do_ms instead of: ms\do_masm Personally I used option # 2. I hope this solves your problem. Layla.David Schwartz [EMAIL PROTECTED] wrote: I'm trying to compile OpenSSL for Windows. I am using openssl-0.9.7d Everything goes well until I get to the part about nmake -f ms\ntdll.mak The error message is: 'ml' is not recognized as an internal or external command, operableprogram or batch file. NMAKE : fatal error U1077: 'ml' : return code '0x1'ml.exe is MASM. You either don't have MASM or it's someplace not in yourpath. MASM is distributed by microsoft in several DDKs and in the processorpack for VC++. You can also configure OpenSSL not to use any assemblylanguage code (I think the parameter is 'no-asm' to configure), and then itwon't need MASM.DS__OpenSSL Project http://www.openssl.orgUser Support Mailing List [EMAIL PROTECTED]Aut omated List Manager [EMAIL PROTECTED] Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish.
Re: Compiling openssl to Pocket PC 2003
i was able to compile for Pocket PC 2002 (WinCE 3.0) using embedded VC++ 3.0 and it works fine. the only problem was there wasn't a random source to seed the PRNG. to get around it, i used a .rnd file with random data. i dont know about using it with .NET C#. I used it with Python. cheers Quoting Gilson Cavalcanti [EMAIL PROTECTED]: Hello all, I'm trying to compile openssl for use it with a .NET C# solution for Pocket PC 2003 (Windows CE4.20). I'm using the MS eMbedded Visual C++ 4.0. Anyone already, had success with something like this? Gilson Cavalcanti Grupo TCI - Business Manager This message was sent using IMP, the Internet Messaging Program. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Certificate fetching for bridge CA configuration
In an earlier version of the diagram I had one more level of certificate between the bridge certificates and the end-user certificates, but I was trying to make it simpler. If there is one more certificate between (Bridge)QSign and (QSign)End User it could be supplied by the Q offerer. The cost here seems to be that the certificate marked (1) needs to be available to the relying party, and if the P PKI participates in multiple bridges, then there are multiple certificates in this class. Similarly, if the Q PKI participates in multiple bridges, a Q offerer might have to send along multiple bridge certificates. This means that when a PKI decides to participate in another bridge, certificates have to be disseminated into the client software. This does not scale well. Finding them in a directory seems like a good alternative. In this arrangement I could see there being three separate LDAP repositories: one for PKI P, another for PKI Q, and a third for the bridge itself. BTW my ultimate goal: my pointy-headed boss says we will cross-certify with the Higher Ed bridge, which will then cross-certify with the Federal bridge, then our researchers will be able to submit signed grant applications to NIH. Now I'm just trying to see the shape in which this could possibly ACTUALLY WORK... Richard Levitte - VMS Whacker wrote: In message [EMAIL PROTECTED] on Thu, 07 Oct 2004 15:20:52 -0400, Charles B Cranston [EMAIL PROTECTED] said: So, this is perhaps the most simple bridge PKI arrangement: +-+---++-+---+ |T| ||T| | +-+---++-+---+ | P Root++ +---+ Q Root| +-+| | +-+ v v +--+--+ +--+--+ (1) | (P Root) | | (Q Root) | +-+ +-+ | Bridge+--+--+ Bridge| +-+ | +-+ | +-+-+ v v +--+--+ +--+--+ | (Bridge) | | (Bridge) | +-+ +-+ ++ P Sign| | Q Sign++ |+-+ +-+| v v +--+--+ +--+--+ | (P Sign) | | (Q Sign) | +-+ +-+ | P End User | | Q End User | +-+ +-+ That diagram throws me off. I've a hard time figuring out what represents certificates, exactly, and it looks like you MIGHT imply that the a bridge certificate could be used directly to verify EE certificates, which is the wrong way to go about it. Does the interposition of another level above the end-user certificate address this complaint? Basically I'm trying to understand the text in RFC3280 describing AIA, which seems to refer to the CA that is TWO levels up from the certificate containing the AIA?? -- Charles B. (Ben) Cranston mailto:[EMAIL PROTECTED] http://www.wam.umd.edu/~zben __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Certificate fetching for bridge CA configuration
Charles, One question: Are you talking about the NIST bridge CA concept or some other variants? It is too hard to understand the diagram. With my understanding, the bridge CA is a hub between different CA domains. Thus each root CA (or principal CA) issues a cross certificate to bridge. -Kiyoshi Kiyoshi Watanabe So, this is perhaps the most simple bridge PKI arrangement: +-+---++-+---+ |T| ||T| | +-+---++-+---+ | P Root++ +---+ Q Root| +-+| | +-+ v v +--+--+ +--+--+ (1) | (P Root) | | (Q Root) | +-+ +-+ | Bridge+--+--+ Bridge| +-+ | +-+ | +-+-+ v v +--+--+ +--+--+ | (Bridge) | | (Bridge) | +-+ +-+ ++ P Sign| | Q Sign++ |+-+ +-+| v v +--+--+ +--+--+ | (P Sign) | | (Q Sign) | +-+ +-+ | P End User | | Q End User | +-+ +-+ Here P and Q are two separate PKIs bridged by the bridge Bridge. Let an email sender (or an SSL server) be the offerer, and let the email reader (or the SSL client) be the relying party (latter is standard usage). An offerer in the Q PKI interacts with a relying party in the P PKI. The P relying party needs this certificate chain: +-+---+ |T| | Presumably this is configured into the relying +-+---+ party software, or available from a server that | P Root| is secure and trusted by users of the P PKI +-+ +-+ | (P Root) | (1) This is the toughie -- could be configured into +-+ the P relying party or fetched from P LDAP but | Bridge| is NOT reasonable for Q offerer to supply... +-+ +-+ | (Bridge) | The Q offerer could supply this along with the +-+ End User certificate | Q Sign| +-+ +-+ | (Q Sign) | The Q offerer would supply this +-+ | Q End User | +-+ So, where would you suspect the (1) certificate would be obtained? It is unreasonable for Q End User to supply it, since she does not necessarily know client is from P and so would have to supply EVERY other PKI's bridge certificate. Perhaps it could be loaded from a source named by an Authority Information Access extension in (what? the end user certificate, or the signing certificate?) The only other alternative I can see is to load all the bridge certificates (1) into all the relying parties. -- Charles B (Ben) Cranston mailto: [EMAIL PROTECTED] http://www.wam.umd.edu/~zben __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
