2011/3/9 Dave Thompson <dthomp...@prinpay.com>

> >       From: owner-openssl-us...@openssl.org On Behalf Of ikuzar
> >       Sent: Tuesday, 08 March, 2011 13:02
>
> >       I am going to explain below what I HAVE TO do :
> >       a) I have to store certificates in a map which is a shared memory.
> > ( I have to do this, I have no choice, because I have to continue
> > what guy before me had started ). So I think it's better to store
> > x509 structure which represents the certificate instead of string.
> > I think it is a good idea. isn't it ?
>
> If the purpose of putting this data in shared memory is to share it,
> and assuming you mean the typedef X509 aka struct x509_st, no.
> Many openssl API structs, including that one, consist mostly of
> pointers to data stored elsewhere in memory -- which in any other
> process is invalid and will produce garbage or crashes.
>
> If you only need to share the map but not its contents, which would
> be silly, you could have X509's in your private memory, and just
> put pointers in the shared map, and no other process can use them,
> but if the map is keyed it could see the keys, and know that e.g.
> your process has *some* cert for server#3 or server.domain.name.
>

=> I want to make something like :
template<class StrType> struct certificate : shared {
    StrType  uri;
    StrType  sn;
    StrType  data;

certificate(X509* cert) {
     char commonName[512];
     subject_name = X509_get_subject_name(cert);
     X509_NAME_get_text_by_NID(subject_name, NID_commonName, commonName,
512);

     uri = commonName;
     sn  = get_sn(cert);// I 'll deal with it later
     data = get_data(cert); // I 'll deal with it later
}

-- then, this certificate defined above is encapsulated in a cacheitem
structure.
-- In fact, map stores a range of cacheitem. Map will be read and written
from different 'forked' childs :
-- there is a class certmanager which manage these cacheitems ( add, get,
delete items from cache, ...etc). I use URI as key for map.
For example, I 'll search item which URI = 213...@etu-univ.com

>
>
>       b) I must be able to extract uri, serial_number from x509
> > structure and store them into a STRING variable. Is there a way
> > to exact URI and SN ? ( see source code above ).
>
> You can definitely get serial. Warning: nowadays serials usually
> aren't sequential (i.e. not 1,2,3,...) and aren't so much numbers
> as longish bitstrings encoded as numbers. Best to treat it as
> opaque, and if you need a UI display it as hex bytes.
> In particular, it's not safe to treat serial directly
> as a C string, as the code in your earlier post seems to;
> if you want a C string and even more so if you want
> human-legible text, do hex or base64 or somesuch.
>
> What URI? policy? CRLdist? OCSP? Something else?
> If you can identify it you should be able to get it.
> And a (valid) URI will actually be good char-string data.
> Although if it's encoded as BMP(2byte) or Universal(4),
> you need appropriate 'wide' char/string support; any given
> C can't have both, and it's not guaranteed to have either.
>


> => I have to store in the certificate an URI which identify an user. this
> URI is like this : phone_number@domain. example : 0123456...@etu-univ.com( 
> this is a SIP uri ). I though I could store it in CN ... was I wrong ?
> have any other suggestion ?
>
> But the combination of "URI" and serial doesn't make sense;
> they don't relate to each other at all. *Issuer* plus serial
> is commonly (but not always) used to identify a certificate.
> Issuer is never a URI. It is *sometimes* a domainname, which
> can be PART of a URL which is one kind of URI, but that is
> not the same thing as being a URI. If issuer is what you want,
> yes you can get it, and even in a nice-for-humans (but not
> necessarily programs) text string form, look for "oneline".
>
> >       c) is it possible to send x509 structure (certificate)
> > to peer ? ( apart from handshake ) I 'd like to write something
> > like: SSL_write(ssl, X509* cert)
>
> No for the same reason as above; the x509_st itself has pointers
> only valid within one process memory. This is exactly why 'wire'
> encodings exist, and the usual one for X.509 (including SSL) is DER.
> Openssl also prefers DER or PEM-wrapped-DER for local storage,
> but here other methods are *possible*.
>
>
> ______________________________________________________________________
> OpenSSL Project                                 http://www.openssl.org
> User Support Mailing List                    openssl-users@openssl.org
> Automated List Manager                           majord...@openssl.org
>

Reply via email to