libpki-devel — LibPKI Development Issues and Solutions

[Libpki-devel] Post-Quantum Certificates and Composite Crypto (Hybrid Certs)

[Dr. P. <dir...@op...>]

Hello LibPKI Community,

as some of you noticed, we have been working, recently, to provide 
support for post-quantum certificates in LibPKI. Specifically, the 
current version of the source (0.9.6) is looking at exploring few 
different options for the next generation PKIs.

Here's some of the features we are working on that we really would like 
the community support for.

*Composite Crypto Support (Hybrid Classic and Post-Quantum)*

LibPKI is adding support for using multiple algorithms/keys via the 
Composite Crypto idea that we are promoting for standardization at the 
IETF. The Composite Crypto option combines multiple public keys in 
certificates and multiple signatures in all X.509 and other data 
structures we support. You can find more info here:

  * https://github.com/EntrustCorporation/draft-ounsworth-pq-composite-keys
    (composite keys)
  * https://github.com/EntrustCorporation/draft-ounsworth-composite-sigs
    (composite signatures)

Many companies and projects are implementing this solution to provide 
Hybrid options for the ones of us that do not trust neither classic or 
post-quantum by itself.

The LibPKI implementation, currently, generates a new Algorithm (the 
COMPOSITE) and allows for generating keys, requests, etc. More work is 
needed to provide support for explicit combinations of algorithms and 
for the verifying of multiple signatures within a composite signature.

The use of Composite Crypto could be seen as a one-off need or maybe a 
change in our field. Specifically, the question that it is on our minds 
is about the longevity of PKIs (i.e., 50 years horizons). With the 
advent of post-quantum cryptography and group-based theories, maybe the 
time for long-term PKIs is now over? Maybe it is time for us to really 
look into shorter crypto-periods (7-10 years) and evolution of PKIs into 
dynamic ecosystems (7-10 years with migration built-in).

If you are interested in working on Composite Crypto... please join our 
efforts!

The IETF discussion on Hybrid certificates is available from the LAMPS 
working group:

  * https://mailarchive.ietf.org/arch/browse/spasm/ (mailing list archive)

*Post-Quantum Certificates (Direct vs. Hash-n-Sign)*

The standardization process for post-quantum public-key cryptography has 
progressed into its final phase and we need to start talking about how 
we are going to integrate these new algorithms in our certificates and 
PKIs. We are leading a small group of people and companies to 
investigate and propose approaches for how to use, for example, direct 
signing vs. hash-n-sign. This has many implications for the use of 
hybrid cryptography (i.e., the number of different OIDs to identify 
algorithm combinations).

The LibPKI support is provided through the OQS library and the 
OQS-OpenSSL wrapper that is available here:

  * https://openquantumsafe.org/

We are also working on a LibPKI-native implementation of Dilithium to 
investigate the use of a single algorithm identifier to handle all 
security levels of the algorithms (i.e., Dilithium2022 -> Level 2, Level 
3, and Level 5).

At IETF 115 we started a interoperability project/hackaton for PQC and 
Composite Crypto. The project was started at IETF 115 Hackaton and is 
supported by many different entities such as big companies (e.g., 
DigiCert, CISCO, etc.) and open-source projects (e.g., PyCrypto, Rust 
Crypto).

The GITHUB repository is available here:

  * https://github.com/IETF-Hackathon/pqc-certificates


*A Complex World Requires Higher Ethics*

When we started the OpenCA projects, we lived in a different world. 
Regrettably, today, terrorists countries like Russia are threatening the 
world-peace, making all other issues that we are dealing with much worst.

At OpenCA Labs, we condemn the use of violence in any form and, in 
particular, the use of WAR as an instrument of political gain. Russia 
and all the countries that continue to support a terrorist attack on the 
sovereign country of Ukraine are on the WRONG side of history and we 
will do everything we can to support the free people of Ukraine.

Because of these reasons, we have changed our LICENSE agreement to make 
sure that we do not directly or indirectly support terrorists, violence, 
and wars. If you or your organization are directly or indirectly 
supporting the war or the Russian terrorist country, please be aware 
that you are no longer among the welcome people in our community and you 
are legally required NOT to use any of our products. We hope that this 
policy will make you change your mind about supporting terrorism, 
violence, and death.

*Happy Holidays*

We hope that the world could grow and understand the need for a more 
ethical and intelligent way of taking decisions and in the meantime we 
would like to wish you all the best possible holidays you can celebrate.

At OpenCA we will never stop striving for a better world with our work 
and commitment to providing easy security for all.

Happy Holidays!!!


-- 
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo

[Libpki-devel] Standard Interfaces for Cryptographic APIs

[Massimiliano P. <dir...@op...>]

Hi all,

we started a new initiatives for defining specifications for "Standard 
Interfaces for Cryptographic APIs". The idea is to provide a very 
practical approach to defining an API that can be implemented on top of 
current (and future) cryptographic libraries that will provide 
application portability.

We are currently hosting few web pages here:

     http://cryptoapi.openca.org

There we have the link to the mailing list we will use for discussing 
the work.

The initiative is at its very beginning and we hope to involve many 
experts, practitioners, cryptographers, and vendors. The expected output 
for the (not yet an IETF WG) working group is twofold: specifications 
and implementations.

Please let me know if you would like to participate.. and/or just 
subscribe to the mailing list and post your questions there.

Have a great day,

Cheers,
Dr. Max

Re: [Libpki-devel] [Openca-ocspd] Segfault in libpki 0.8.7 was: (no subject)

[Martin H. <he...@hl...>]

On 08/29/2014 05:37 PM, Martin Hecht wrote:
> your stack trace starts in PKI_HTTP_free and this is not very often
> used.
sorry, this was bad English. I meant that this function is not called in
many places in the code, which helps to locate the problem (of course
this function is used to free the data structure after every request is
processed)

> ...Geert De Prins has proposed a patch for libpki 0.8.5...
and this fix addresses an issue in this section of code which handles
the PKI_HTTP data structure and therefore I am proposing to try this
patch and see if it solves the problem.

Martin

Re: [Libpki-devel] [Openca-ocspd] Segfault in libpki 0.8.7 was: (no subject)

[Martin H. <he...@hl...>]

Hi,

your stack trace starts in PKI_HTTP_free and this is not very often
used. I don't know what exactly microsofts certutil does to connect to
the ocspd, but in my tests this week the daemon was running without
problems. However, Geert De Prins has proposed a patch for libpki 0.8.5
(http://sourceforge.net/p/openca/mailman/message/32603322/) which shall
fix problems with large CRL lists. Maybe this is the case here as well:
the response of the root ca might not be large enough to overflow the
buffer, but the one of the inermediate ca might be.
The patch applies (with exception of a comment line) with a few lines
offset to libpki 0.8.7 (see attachment). You might want to try this.

kind regards,
Martin


On 08/28/2014 09:48 PM, Asd wrote:
> I have installed libpki (0.8.7) and ocspd (3.1.0) onDebian Stable Linux 3.15.0 CEST 2014 i686 GNU/Linux.libpki: ./configure --prefix=/usr; make; make installocspd: ./configure --prefix=; make; make install Then start:# /etc/init.d/ocspd start-debug syslog:ocspd[29204]: Configuration loaded and parsed On WIndows 7:certutil -URL .....\rootCA.crt works, butcertutil -URL .....\interCA.crt makes segfault. In syslog:ocspd[29205]: [core.c:291] [ERROR] SIGABRT::received - should not happen,
> ocspd[29205]: [core.c:292] [ERROR] SIGABRT::please enable strict locking.
> ocspd[29205]: [core.c:293] [ERROR] ERROR::SIGABRT::Fatal Error, aborting server! in terminal:# *** glibc detected *** /sbin/ocspd: double free or corruption (!prev): 0x095874c8 ***
> ======= Backtrace: =========
> /lib/i386-linux-gnu/i686/cmov/libc.so.6(+0x70ff1)[0xb7155ff1]
> /lib/i386-linux-gnu/i686/cmov/libc.so.6(+0x72858)[0xb7157858]
> /lib/i386-linux-gnu/i686/cmov/libc.so.6(cfree+0x6d)[0xb715a99d]
> /usr/lib/libpki.so.87(PKI_Free+0x2e)[0xb767b3de]
> /usr/lib/libpki.so.87(PKI_ZFree+0x4a)[0xb767b43a]
> /usr/lib/libpki.so.87(PKI_MEM_free+0x3c)[0xb767b48c]
> /usr/lib/libpki.so.87(PKI_HTTP_free+0x54)[0xb76ad374]
> /sbin/ocspd[0x804c613]
> /sbin/ocspd[0x804c2c5]
> /lib/i386-linux-gnu/i686/cmov/libpthread.so.0(+0x5c39)[0xb7645c39]
> /lib/i386-linux-gnu/i686/cmov/libc.so.6(clone+0x5e)[0xb71bbe1e] What am I doing wrong? 
>

[Libpki-devel] Progressing Revocation and Discovery Standards for X509 PKIs

[Massimiliano P. <dir...@op...>]

Hi All,

As many of us have probably had to deal with some pain points when 
developing and/or using applications together with X509 PKIs. I hope 
that the projects we promote (i.e., OpenCA PKI, OpenCA OCSPD, and 
LibPKI) have been helpful in providing useful solution. However, issues 
still exist in interacting with PKIs. In particular, some of the most 
painful areas are related to service (and repository) discovery and 
efficient revocation. Besides implementing specific solutions for 
well-defined (and usually quite closed) environments, no existing 
standards efficiently address these issues.

In the past we participated to discussions within the Internet 
Engineering Task Force (IETF) and implemented the standardized protocols 
(e.g., OCSP). However, the Working Group (WG) that was historically 
responsible for advancing the status of these standards (required for 
interoperability across applications and organizations) was declared 
closed - therefore, today, there is no proper venue where this 
standardization work can happen. It seems that the IETF is still on the 
fence about the need for solving these issues and that strong consensus 
is required in order to open a new WG that will address these problems.

I was wondering what the OpenCA community thinks about the need to 
provide standards that cover the aforementioned issues (e.g., by 
providing enhancements over existing solutions - like OCSP over DNS, by 
providing new more-compact revocation formats that would better cope 
with high-volume transactions environments than OCSP, and - ultimetely - 
by providing PKIX discovery protocols that will ease interacting with 
certificate-related services and with federating identities) and if 
anybody would feel like they can contribute to the discussion and, 
eventually, to the needed work (via the PKIX mailing list - 
https://www.ietf.org/mailman/listinfo/pkix).

If the proposal for working on these issues will move forward, I think 
that the OpenCA Labs could very well work on implementing those 
standards and, therefore, solve those issues for lots of us in a 
standardized and interoperable way.

Cheers,
Max

Re: [Libpki-devel] [Openca-ocspd] GET request errors

[Martin H. <he...@hl...>]

Hi,

I have found out a few more details on the problem with Macintosh's ocspd:

My previous patch helped to have the server running stable, but
PKI_HTTP_get_message still didn't return a useful path value for ocspd.
I have added a few lines to fix this for the time being, until the
official release appears.

The other thing with the GET requests is that they were not(!)
url-encoded, so there are slashes somewhere in the middle of the query.
I have created a patch for ocspd which gives it a second try when B64
decoding fails due to such a request.
However, I believe this is non-standard and should be fixed by Macintosh.

By the way, I have finally found a simple way to debug the get-requests:
wget ${server-ip}:2560/${request} -O ocsp.response
where I grab the request string using tcpdump -vvv -A |  grep GET.*HTTP
and last but not least I verify the response with:
openssl ocsp -respin ocsp.response -CAfile cacert.pem

Doing so, I noticed that step of url-encoding this string was not done
on the client-side and that was the reason, why the request was not
valid and the communication was closed (actually, ocspd did send the
5-byte response to the client). With the attached patches our server
runs stable and the ocspd on the client side successfully verifies the
certificates for Safari, even for non-url-encoded get-requests. It takes
some time and there are several ocsp requests for the same certificate
at once, but that's really something to fix on the client side.

best regards,
Martin

PS: Sorry for creating so much "noise" on the mailing list, but I hope
that this work might help others, too.

Re: [Libpki-devel] [Openca-ocspd] GET request errors

[Martin H. <he...@hl...>]

Hi,

I have created a patch for libpki-0.8.2.

Basically, if the Request-URI starts with a '/' we have to do something
special, because the default parser is unable to extract an url from
such a request. As I have written beginning of the week my idea was to
prepend "localhost" and give that to the default parser (without
"http://", because that is stripped off anyway, if it was present).

Furthermore, I believe I have found the reason for the crashes we have
observed. The trailing '\x0' char was written beyond the end of the
string, and I have included the checks on the url pointers I mentioned
last week,  also in this patch in the attachment.

With this fix I have a running ocspd 2.5.1 with libpki 0.8.2 now, in the
sense that the daemon does not crash. But still the Macintosh ocspd as a
client refuses to work together with the openca-ocspd server. The client
sends its GET request which can be handled now (no crashes, no errors
about B64 decoding the requests), but when I listen on the network there
is no reply from the server. This could be because the client closes the
connection too early. The request itself is ok, because when I capture
it and send it manually with openssl, I receive a proper answer (well,
ok, submitting it with openssl it is send via POST and not via GET
method, but anyhow, the request itself is not messed up).

The http headers in the GET request captured from the communication of
the Mac look as follows:

GET //{base64 encoded request in der form} HTTP/1.1
Host: {RA-host extracted from the certificate to verify}:2560
Accept-Encoding: gzip, deflate
Accept: */*
User-Agent: ocspd/1.0.1
Accept-Language: de-de
Cache-Control: max-age=300
Connection: keep-alive

Is there any check of the accepted language? I didn't find anything like
that. Maybe the client simply closes the connection before the server
has a chance to send an answer. Anyhow, browsing around it seems OSX
10.9 "Mavericks" is having problems with their OCSP and some users are
reporting that they have "solved" the problem by turning off CRL & OCSP
checking in the Certificates Preferences in Keychain Access...
 
best regards,
Martin

Re: [Libpki-devel] [Openca-ocspd] GET request errors

[Martin H. <he...@hl...>]

Hi developers,

We had a closer look at our crashes of ocspd. I'm adding libpki-devel to
this mail (previous mails went to the ocspd-devel list, but by now I
believe the fix should be done in libpki).

The client which caused the trouble is a Macintosh implementation of
oscpd (running on a Mac with OS X 10.9) which handles the verification
of certificates for Safari.
Actually, it sends a GET-request (in contrast to my firefox which uses
POST to send the data, which works fine).

According to RFC 2560 a get request looks as follows:
GET {url}/{url-encoding of base-64 encoding of the DER encoding of the
OCSPRequest}

In the requests which caused the crashes, {url} was "/", so there were
two slashes after the GET and url- and base64-decoding failed due to
this extra slash at the beginning. When I strip off all the slashes at
the beginning, I can successfully decode the original der-formatted ocsp
request, save it to a temporary file, parse it with openssl, and re-send
it to the ocspd which then returns "Response verify OK".

Let's look at the sources now. The problem is that in
ocspd_req_get_socket in ocspd/src/ocspd/request.c, there is a call to
PKI_HTTP_get_message in libpki/src/net/http_s.c. To make this work for
this particular case, the latter should be able to parse an URL
containing  just a slash, and it should return a reasonable http_msg
object. I believe it would work fine, if we would prepend urls that
start with a slash e.g. by "http://localhost" somewhere where the http
headers are parsed. Maybe if this is done in the right place, later on
in the code sock->url is properly defined. I haven't looked that much
into the details of  libpki/src/net/pki_socket.c yet, but I'm going to
try this out.

best regards,
Martin

Re: [Libpki-devel] format string errors

[Massimiliano P. <Massimiliano.Pala@Dartmouth.edu>]

Hi Oden,

thanks a lot!!! I will review the patch and include them in the new version
of the library - which I plan to release soon as I made some more upgrades
to the provided command-line tools.

Cheers,
Max


On 02/17/2011 06:24 AM, Oden Eriksson wrote:
> Hello.
>
> We have been patching libpki for quite some time now to get rid of format
> string errors in the code (patch attached). These error as seen when you use
> "-Wformat -Werror=format-security".

[Libpki-devel] Announcement::New Website

[Massimiliano P. <Massimiliano.Pala@Dartmouth.edu>]

Dear OpenCA Community,

we recently worked very hard to provide a new look to our website. We hope
that the change will help you to easily find the required resources.

Please provide us with feedback about the new layout by sending us simple
comments (e.g., "I really like it!", "I preferred the old layout..") or
suggestions (e.g., "The link to AbC should be moved here..", "You should
add a new link to DeFgh..").


Best Regards,
Massimiliano Pala
OpenCA Labs

[Libpki-devel] New LibPKI Version (Tiger) v0.3.0 is available

[Massimiliano P. <Massimiliano.Pala@Dartmouth.edu>]

       Announcement:
       =============

         The OpenCA Team announce the availability of the new version of the LibPKI
         library:

	Current Version: v0.3.0 (tiger)


       Project Overview:
       =================

         The LibPKI Project is aimed to provide an easy-to-use PKI library for
         PKI enabled application development. The library provides the developer
         with functionalities to manage Public Key Certificates, from generation
         to validation.
         The LibPKI Project enables developers with the possibility to implement
         complex cryptographic operations with a few simple library calls by
         implementing an high-level cryptographic API.

         The library constitutes the core of the OpenCA-NG Project. We provide it
         as a separate package in order to encourage applications developers to
         use it in their packages.

         Currently we support for OpenSSL libraries as low-level crypto provider.


       Project Status:
       ===============

	o [19 Apr 2009] Tiger release available for download (libpki v0.3.0)
         o [16 Jan 2009] Shark release available for download (libpki v0.2.0)
         o [20 Mar 2008] Third release available for download (libpki v0.1.9)
         o [25 Oct 2007] Second release available for download (libpki v0.1.8)
         o [23 Mar 2007] First initial code available for download (libpki v0.1.1)


       Major Changes and Fixes:
       ========================

       o added support for Cross Certificate Pair (for bridge PKI
         support) via pki-xpair tool which allows to download (from a URI),
         create, parse the crossCertificatPair data object
       o updated the PRQP module to the last specs from IETF (draft-ietf-pkix-prqp-03.txt)
       o added full support for PKCS#11 devices
       o added a new command line tool - pki-tool - that allows to manage the PKI
         TOKENS (both hardware and software). In particular it is possible to generate
         keys, sign requests, sign certificates, etc.


       Current Project developers' Tasks:
       ==================================

         Massimiliano Pala is currently working on:
         - Continuing Integration of TPM for Key operations/management;
         - Enhancing support for PKCS#11 devices (adding ECDSA/DSA support for future
           devices)
         - Fixing extension management code;
         - Extending the Log subsystem to provide signed and verifiable logs;


       Open Issues:
       ============

         o Extensions management is still not stable for complex exts, the code
           needs to be checked and extended
         o Integration with TPM in development
         o Support for NSS still pending
         o Porting to Win32 (provide support for Microsoft Crypto API)


       Wishes:
       =======

        o Let us know (!)


       References:
       ===========

       The OpenCA Project main website can be found at

            http://www.openca.org/

       You can find all current versions and available documentation there. You
       can also download any part of the software or documentation also at the
       official ftp site:

	http://www.openca.org/projects/libpki
	http://ftp.openca.org/libpki

       or from one of the official mirrors:

	http://www.openca.org/mirrors.shtml

       Thanks
       ======

       Thank you for supporting the Open Source community by using/contributing to/
       reporting bugs/cheering this project! Now go ahead and actively contribute to
       make the world a better place!


                                                          - The OpenCA Team -

[Libpki-devel] PKCS11 - The disturbing Truth about libp11 and OpenSC!

[Massimiliano P. <Massimiliano.Pala@Dartmouth.edu>]

Hi all,

I am developing the PKCS#11 driver for LibPKI and I am playing around with
some other code - especially the libp11 which is used by many software:
- OpenSSL's ENGINE for PKCS#11
- OpenSC

When creating the key, the behaviour a user would expect from these driver
is to generate the keypair in the device and then, eventually, export the
public part. However, the libp11 behaves differently. What it really does
is generating the key is software and then import it into the device - which
totally invalidates the assumptions made when using a PKCS#11 device!

Therefore, my advice is: do not use OpenSC + libp11 (for PKCS#11 access) if
you are concerned about the security of your private key!

I will develop an application that will print out the "properties" of
public/private keys in a PKCS#11 device so that you can check out what
the status of your generated keys is - the tool will probably be part
of the LibPKI package.

Later,
Max

[Libpki-devel] New LibPKI Version (Shark) v0.2.0 is available

[Massimiliano P. <Massimiliano.Pala@Dartmouth.edu>]

      Announcement:
      =============

        The OpenCA Team announce the availability of the new version of the LibPKI
        library:

	Current Version: v0.2.0 (shark)


      Project Overview:
      =================

        The LibPKI Project is aimed to provide an easy-to-use PKI library for
        PKI enabled application development. The library provides the developer
        with functionalities to manage Public Key Certificates, from generation
        to validation.
        The LibPKI Project enables developers with the possibility to implement
        complex cryptographic operations with a few simple library calls by
        implementing an high-level cryptographic API.

        The library constitutes the core of the OpenCA-NG Project. We provide it
        as a separate package in order to encourage applications developers to
        use it in their packages.

        Currently we support for OpenSSL libraries as low-level crypto provider.


      Project Status:
      ===============

        o [16 Jan 2009] Shark release available for download (libpki v0.2.0)
        o [20 Mar 2008] Third release available for download (libpki v0.1.9)
        o [25 Oct 2007] Second release available for download (libpki v0.1.8)
        o [23 Mar 2007] First initial code available for download (libpki v0.1.1)


      Major Changes and Fixes:
      ========================

      o Added graphical installer for different distributions (Linux/Fedora,
        Linux/Ubuntu, Mac OS X/Darwin, etc.)
      o Updated the PRQP module to the last specs from IETF PKIX WG
        (draft-ietf-pkix-prqp-02.txt)
      o Fixed support for multi threaded applications (dynamic and static
        threads initialization for OpenSSL/ENGINE)
      o Fixed support for nChipher devices
      o Updated PKCS11 driver (added Slot Interface and Slot info retrieval
        functionalities)


      Current Project developers' Tasks:
      ==================================

        Massimiliano Pala is currently working on:
        - Continuing Integration of TPM for Key operations/management;
        - Enhancing support for PKCS#11 devices;
        - Fixing extension management code;
        - Extending the Log subsystem to provide signed and verifiable logs;


      Open Issues:
      ============

        o Extensions management is still not stable for complex exts, the code
          needs to be checked and extended
        o Integration with TPM in development
        o Support for NSS still pending
        o Porting to Win32 (provide support for Microsoft Crypto API)


      Wishes:
      =======

       o Let us know (!)


      References:
      ===========

      The OpenCA Project main website can be found at

           http://www.openca.org/

      You can find all current versions and available documentation there. You
      can also download any part of the software or documentation also at the
      official ftp site:

	http://www.openca.org/projects/libpki
	http://ftp.openca.org/libpki

      or from one of the official mirrors:

	http://www.openca.org/mirrors.shtml

      Thanks
      ======

      Thank you for supporting the Open Source community by using/contributing to/
      reporting bugs/cheering this project! Now go ahead and actively contribute to
      make the world a better place!


                                                         - The OpenCA Team -

[Libpki-devel] New LibPKI Version (v0.1.8) available

[Massimiliano P. <pa...@cs...>]

     Announcement:
     =============

       The OpenCA Team announce the availability of the new version of the LibPKI
       library:

	Current Version: v0.1.8


     Project Overview:
     =================

       The LibPKI Project is aimed to provide an easy-to-use PKI library for PKI
       enabled application development. The library provides the developer
       the needed functionalities to manage Public Key Certificates, from generation
       to validation.
       The LibPKI Project enables developers with the possibility to implement complex
       cryptographic operations with a few simple function calls by implementing an
       high-level cryptographic API.

       The library constitutes the core of the OpenCA-NG Project, anyway we provide it
       as a separate package in order to encourage applications developers to use it in
       their packages.

       Currently support for OpenSSL and KMF libraries is provided as low-level crypto
       provider.


     Project Status:
     ===============

       o [25 Oct 2007] Second release available for download (libpki v0.1.8)
       o [23 Mar 2007] First initial code available for download (libpki v0.1.1)


     Major Changes and Fixes:
     ========================

       o Added a Log subsystem
       o Integrated new version of PRQP
       o Added support for OpenSSL ENGINE usage
       o Added first support for PKCS11 URL retrieval (pkcs11://)
       o Added MySQL support for URL retrieval
       o Fixed support for LDAP URL retrieval
       o Added support for SCEP messages to the library
       o Initial CMS support added
       o support for extensions management into libpki by using certificate profiles
         and oid configuration file (xml based)
       o Added support for certificate, request and certificate chain writing
         through PKI_TOKEN interface
       o Added support for different signature schemes (RSA/DSA/ECDSA with RC2/RC5/SHA1)
       o Fixed compilation problems on Solaris 9/Solaris 10/Solaris 11
       o Fixed compilation problems on FreeBSD
       o Fixed LDAP differences with OpenLDAP and Sun's LDAP (support for both is
         provided)


     Current Project developers' Tasks:
     ==================================

       Massimiliano Pala is currently working on:
       - Integration of TPM for Key operations/management;
       - Adding support for PKCS#11 devices;
       - Fixing extension management code;
       - Extending the Log subsystem to provide signed and verifiable logs;


     Open Issues:
     ============

       o Extensions management is still not stable for complex exts, the code
         needs to be checked and extended
       o Integration with TPM in development
       o Still deciding if to provide our own PKCS#11 subsystem or rely on
         the crypto lower layer (e.g., ENGINE or KMF)
       o Binary Packages generation for Ubuntu (linux) and MacOS X
       o Porting to Win32 (provide support for Microsoft Crypto API)


     Wishes:
     =======

      o Let us know (!)


     References:
     ===========

     The OpenCA Project main website can be found at

          http://www.openca.org/

     You can find all current versions and available documentation there. You
     can also download any part of the software or documentation also at the
     official ftp site:

	http://www.openca.org/projects/libpki
	http://ftp.openca.org/libpki

     or from one of the official mirrors:

	http://www.openca.org/mirrors.shtml

     Thanks
     ======

     Thank you for supporting the Open Source community by using/contributing to/
     reporting bugs/cheering this project! Now go ahead and actively contribute to
     make the world a better place!


                                                        - The OpenCA Team -

[Libpki-devel] PRQP command line client

[Massimiliano P. <pa...@cs...>]

Hi all, Scott,

I have finally managed to integrate the new version of the PRQP into libPKI.
We now have a client that is capable to generate requests and parse responses
for PRQP.

Much work is still to be done about verification and parsing of responses,
though. Here it is the output for the various services that can be queried
through the prqp_client example program. Any feedback about the options is
welcome!

:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

USAGE: ./prqp_client options

Where options are:
  -issuer <dn>        - Issuer's of the CA certificate DN (optional if certfile
                        or cacertfile is provided)
  -serial <num>       - Serial Number of the CA certificate (optional)
  -certfile <file>    - Certificate to find CA services for (optional if
                        issuer is provided)
  -cacertfile <file>  - CA certificate to find serviced of (optional)
  -service <id>       - Service which URL is to be asked (optional, multiple
                        accepted)

Where service <id> can be:

  * General Services
      [ocsp] OCSP Service
      [caIssuers] CA Information
      [timeStamping] TimeStamping Service
      [dvcs] DVCS Service
      [scvp] SCVP Service

  * Repositories Location:
      [certificateRepository] Certificate Repository
      [crlRepository] CRL Repository
      [deltaCrl] Delta CRL Base Address

  * PKI Service Gateways:
      [cmsGateway] CMS Gateway
      [scepGateway] SCEP Gateway
      [xkmsGateway] XKMS Gateway

  * PKI Basic Services Location:
      [revokeCertificate] Certificate Revocation Service
      [requestCertificate] Certificate Revocation Service
      [suspendCertificate] Certificate Suspension Service

  * Extended Services Location:
      [webdavCert] Webdav Certificate Validation Service
      [webdavRev] Webdav Certificate Revocation Service

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

-- 

Best Regards,

	Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]            pa...@cs...
                                                  pro...@op...

Dartmouth Computer Science Dept               Home Phone: +1 (603) 397-3883
PKI/Trust - Office 063                        Work Phone: +1 (603) 646-9179
--o------------------------------------------------------------------------

[Libpki-devel] PRQP Paper

[Massimiliano P. <pa...@cs...>]

Hi Scott, all,

I was thinking about integrating the PRQP protocol support directly into
libPKI. The RFC of PRQP can be downloaded from here:

       http://www.ietf.org/internet-drafts/draft-pala-prqp-00.txt

This would have the advantage to have the PRPQ available through libPKI,
but the disadvantage that it will be impossible to distribute the libPRQP
without libPKI... although I think this is the right thing to do, let me
know if you have arguments against this...

Later,
Max