Re: Certificates format

On 1/25/13 2:47 AM, "David Pierre" <[email protected]> wrote:

>I have made some tests on certificates and i thought i have missunderstood
>certificate part.
>
>On server part, i create a RSA key, create a certificate with this key and
>saved all these information in a .p15 file, that correspond to my "server
>key". Then when I start a session (still on server side), I take this
>server
>key and load it as attribute (private key). When a client would attempt to
>connect, the server will provide the associated certificate.

FWIW, PKCS#15 is not particularly common for software token key storage.
For good or ill, PKCS#12 is more common, though splitting pairs into
separate PKCS#8 and PKCS#7 structures for private and public key storage
respectively is also used.  Peter has definite opinions about PKCS#12.  :)
 

However, you're generally free to store keys outside a crypto module
however you like, though it's probably a good idea to keep the private key
wrapped up.

>On client side, activating the session provides possibility to get the
>certificate (sent during the activation). Once i get the certificate with
>getAttribute, i can check it and export it in a .der format. The
>certificate
>is saved, containing only public key.

>Is my reasoning logical ? Am I right ?

Basically.  Transfer of a certificate from service to relying party
depends on the protocol and options you're negotiating.  E.g., some
protocols permit sending key identifiers instead of the entire
certificates, which assumes the relying party has a certificate pool to
draw on.

Strictly speaking, there are no standards for file formats for X.509/PKIX
data structures, just a set of more-or-less common conventions.  All the
PKIX standards define are the data structures, which leverage ASN.1 DER
encoding as a canonicalization method for signatures.  ASN.1 DER is very
common for network protocols, so often this is used when encoding for
transmission as well.

For file storage, most software takes the easy route simply writes the
wire encoding to a file, but there's no real rules here.  DER encoding and
PEM-encoded DER are the most common encodings, with PKCS#7, 8, and 12
being the most common structures, but nothing stops you from using another
encoding like XER or stuffing raw key bytes in a database if you felt like
it.  For example, Microsoft CryptoAPI's internal storage is basically a
memory dump to file--everything's in little-endian byte order.

-- T



_______________________________________________
Cryptlib mailing list
[email protected] via Mail: [email protected]
Archive: ftp://ftp.franken.de/pub/crypt/cryptlib/archives/
http://news.gmane.org/gmane.comp.encryption.cryptlib
Posts from non-subscribed addresses are blocked to prevent spam, please
subscribe in order to post messages.