[pubcookie-dev] function make_crypt_keyfile()

[Nathan Dors]

Greetings Steve.

Re: make_crypt_keyfile(), sounds reasonable to me on the surface, 
but I defer to the real programmers to assess its strengths and 
any implications it has for Windows. Could be that it's something 
we could change quite easily; I wouldn't know.

Re: wildcard certs, we added support for them, as well as subject 
alt names, since the 3.1.1 release.

Re: next release, I'm thinking tomorrow, 3.2.0 beta1, but only the 
Unix components (login cgi, keyserver, keyclient, and module).

-Nathan

On Fri, 3 Dec 2004, Steve Losen wrote:

> Greetings pubcookie developers,
>
> I have been working with pubcookie 3.1.1 and would like to suggest
> a code improvement.
>
> Function make_crypt_keyfile() takes a hostname and generates the
> name of the file that holds the symmetric encryption key for that
> host.  For example, host foo.bar.com might result in the pathname
>
> /usr/local/pubcookie/keys/foo.bar.com
>
> In security.h function make_crypt_keyfile() is declared static.
>
> Consequently this function is defined static in two source files:
> security_legacy.c and libpubcookie.c, so there are two versions
> of it.  I think that this function should be global and defined
> in just security_legacy.c
>
> Because hostnames are case insensitive and you cannot depend on
> consistent capitalization, it makes sense to lower case the
> hostname when generating the file name.  The version of
> make_crypt_keyfile() in libpubcookie.c does this, but the version
> in security_legacy.c does not.  Furthermore, the make_crypt_keyfile()
> in libpubcookie.c has the antisocial behavior of modifying the
> string pointed to by the "peername" argument, which is declared
>
> const char *peername
>
> It "lowerifies" the input string and then copies it to the end of
> the pathname.
>
> I suggest removing "static" from the declaration of make_crypt_keyfile()
> in security.h.  I suggest removing the function definition in
> libpubcookie.c and I suggest replacing the definition in
> security_legacy.c with this or something equivalent:
>
> /**
> * generates the filename that stores the DES key
> * @param peername the certificate name of the peer
> * @param buf a buffer of at least 1024 characters which gets the filename
> * @return always succeeds
> */
> void make_crypt_keyfile(pool *p, const char *peername, char *buf)
> {
>    const char *dir, *sep;
>    int i, j;
>    pbc_log_activity(p, PBC_LOG_DEBUG_LOW, "make_crypt_keyfile: hello\n");
>    dir = PBC_KEY_DIR;
>    sep = DIR_SEP;
>    i = 0;
>    for (j = 0; i < 1023 && dir[j] != 0; j++) {
>        buf[i++] = dir[j];
>    }
>    if (i > 0 && i < 1023 && buf[i-1] != *sep) {
>        buf[i++] = *sep;
>    }
>    for (j = 0; i < 1023 && peername[j] != 0; j++) {
>        buf[i++] = tolower(peername[j]);
>    }
>    buf[i] = 0;
>    pbc_log_activity(p, PBC_LOG_DEBUG_LOW, "make_crypt_keyfile: goodbye\n");
> }
>
> I suggest defining the function in security_legacy.c because that
> is where DIR_SEP is defined.
>
> I suspect that I have had more problems with upper/lower case than others
> because we are using "wild card" certificates on several of our web
> servers. For example, a host such as
>
> conan.itc.Virginia.EDU
>
> has a certificate where the subject DN has this in the CN field:
>
> *.itc.virginia.edu
>
> I have made some modifications to pubcookie to deal with these wild
> cards.  I use getpeername(),  gethostbyaddr() and gethostname() to
> obtain hostnames when the CN begins with "*." .  So here is where
> I encounter inconsistent capitalization.
>
> I also had to make a couple mods so that keyclient and keyserver
> accept these wild card certs when they match the hostname.
>
> If you are interested, I would be happy to contribute this code.
>
> Does anyone know about when the next release of pubcookie is coming
> out?
>
> Steve Losen   scl at virginia.edu    phone: 434-924-0640
>
> University of Virginia               ITC Unix Support
>
>
> _______________________________________________
> pubcookie-dev mailing list
> pubcookie-dev at u.washington.edu
> http://mailman1.u.washington.edu/mailman/listinfo/pubcookie-dev
>