Silly CA/certs questions...

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Silly CA/certs questions...

Jeff Wiegley-2
Sorry for the newb question but I've been reading howtos and
turorials all afternoon and I can't figure out how to make
a CA thingy. (Or even if I should)

Second sorry that this is so long. It's a reflection of how
confused all of this has made me. If you want to skip to the
summary question at the end feel free to do so.

I maintain about a dozen servers.  While installing openvpn
in TLS mode I got sick and tired of having certs that don't
match the names of the machines and don't end at a trusted
signed certificate.

I have a domain "mydomain.com" for example.
   Within that domain I have several "servers" of importance
   to me which seem to need TLS/SSL certificates:
      1) www.mydomain.com needs a cert for web service.
      2) smtp.mydomain.com needs a cert for TLS SMTP reception.
      3) imap.mydomain.com needs a cert for secure imap.
      4) vpn.mydomain.com needs a cert for VPN service.
      5) ssh.mydomain.com needs a cert too.

Now clearly my VPN clients all need individual TLS certs
to authenticate against the VPN server because it's a two
way authentication.

Here's the odd bit. All of these services are running on the
same machine.  I'm tired of scripts "magically" creating new certs
for everything everytime the machine is reinstalled or something.
I'm tired of having my imap cert and my web certs having a
common name of mail.mydomain.com (mail is the primary purpose
for the server.) It seems more correct to have the cert tied
to the actual name I want to connect to the server as so in
case my web traffic gets too heavy and I have to move the
web service off of mail.mydomain.com I can simply move the
cert with it.

I'm cheap, I don't want to pay veri$ign to get a verisign
signed certificate (let alone half a dozen of them.) and
cacert.org seems overkill since I'm the only one that really
needs to use my own machines (except for web/mail) so I
don't care if the certs end in a self signed certificate that
I have to install as a CA. (If I've got an wrong assumptions
in there forgive me, I already know I can't figure out what
the heck I'm trying to do or talk about.

I want to point my mail program at imap.mydomain.com and
smtp.mydomain.com. I want people to point their browser at
www.mydomain.com and I want my roadwarriors to point their
VPN clients at vpn.mydomain.com. So that when I have to
change the actual machine the services are made available
from I don't have to bother all my users/clients.

First major question:
What is the difference between a CA, CA certificate and a
CA root certificate???

My guess is that I make CA, then I make a CA certificate,
then I install the CA certificate in /etc/ssl/certs on all my
servers/clients. Then I can use that CA cert to sign any other
certs I want for individual services or client authentication.

Is that correct?

Questions:
1) Is it possible to make my own CA thing (I use "thing" because
    I can't for the life of me figure out if I mean CA, CA certificate,
    root certificate or master certificate, all of which I have seen
    used seemingly arbitrarily on several dozen information sites
    today.) Should I install this "thing" as a trusted CA on my
    servers?  I think so, but I'm totally confused. I mean could it
    possible to get more conflicting advice...

    Here's what several sites have told me:

    site 1:
       openssl genrsa -des3 -out ca.key 1024
       openssl req -new -x509 -days 1001 -key ca.key -out ca.cer

       And then no information as to where or how to install
       this in my servers. Seems like /etc/ssl/certs would be a
       good place except *nothing* else there ends in .cer so
       I'm figuring this either created the wrong type of certificate
       or there is some other magical command I have to run to
       to convert to pem format.

       Also no information on how I sign something with this.

    site 2: http://sial.org/howto/openssl/ca/
       This site has "it" wrapped up in some sort of obfuscating
       make file.

       And again, no instructions how or where to install it so
       that certificates signed by this CA.

       This is possibly the worst site I came across in being
       thuroughly vacuous in it's tutorial abilities.

    site 3: http://www.openssl.org/docs/apps/CA.pl.html
       Yeah! another wrapper. Software convenience wrappers are a
       lot like condoms in my opinion. Just messy. I'd like to
       understand the process instead of guessing or relying on a
       wrapper to make magical, incorrect guesses for me. But at least
       this seems to be a defacto standard interface. Instead of a
       wrapper the openssl tool/system should either be intuitive to
       use or have exceptional documentation on how to use it with
       lots of concrete, useful examples.

       So now I've got lots of easy, abstract options to choose from:
       -newcert: Yeah! I can make a self signed cert. Do I need a
                 self signed cert for what I described? Do I need just
                 a cert or do I need a CA cert or do I need a CA root
                 cert?
       -newreq: What in the world is a certificate request?
                wouldn't that be something you sent verisign in
                order to obtain a certificate? I doubt it, but
                how else is one suppose to interpret "creates a new
                certificate request?" If it really is a request for
                a certificate then who do I send this request to once
                I create to obtain my desired cert?
       -newca: creates a new CA heirarchy. This sounds good to me.
               But it doesn't create a CA cert? do I need both a
               CA heirarchy and a CA cert? which do I create first?
               Does one need the other?

       -sign
       -signca
       -signcert ugh. ok these seem to sign things. I know my service
                 certs need to be signed. I know that ssl/tls just
                 walks back up the signature/cert chain until a trusted
                 cert is found or a self signed cert is encountered.
                 I actually do know that my CA cert needs to be
                 self-signed (if I need a CA cert at all) and needs to
                 installed in such a way that it is trusted. But I
                 can't figure that how.

       Oh good... I especially liked this part for -signca...
       "This is useful when creating intermediate CA from a root CA."
       Have I just learned that I also need an intermediate CA in addition
       to my root CA??? is a root CA the same as a root CA certificate
       or does it mean a root CA heirarchy??

2) Once I have the CA item figured out how do I create new certs for
    services that are signed by this CA thing?

Please forgive me for being rude. I'm tired, I'm hungry, Got a huge
headache, can't get my sewing machine parts back together into anything
that resembles a sewing machine and I've spent several hours today just
trying to understand the nomenclature of this stuff again. I have spent
probably a hundred or more hours over the past few years trying to
understand this exact same thing and never succeeded, forced to give up
everytime.

Summary:

    Would somebody tell me the exact, complete steps, using only the
openssl program, on unix/linux how to make yourself capable of being an
authority and signing additional certificates for use with individual
services?

The answer should include
   A) A list of openssl commands.
   B) For each command brief description of the purpose of the command
   C) A description of how to install the result as an authoritative
      certificate so that clients automatically accept certificates
      signed by the result.

The only thing I can offer is that if you help me then I will attempt
to write a very detailed and accurate description of the process so
that newbs like me don't have such a difficult time adopting this
system in the future.

Thanks,

- Jeff
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Silly CA/certs questions...

Kyle Hamilton
Don't worry about the newb questions, and I can help you answer them.
I will reply inline, and I'm going to clear the background information
so that the answers I give you will be more readable.  (I am, however,
going to take the background information into account.)

On 2/21/06, Jeff Wiegley <[hidden email]> wrote:
> I'm cheap, I don't want to pay veri$ign to get a verisign
> signed certificate (let alone half a dozen of them.) and
> cacert.org seems overkill since I'm the only one that really
> needs to use my own machines (except for web/mail) so I
> don't care if the certs end in a self signed certificate that
> I have to install as a CA. (If I've got an wrong assumptions
> in there forgive me, I already know I can't figure out what
> the heck I'm trying to do or talk about.

From a software point of view, a CA is a certificate that has an
extension ("CA:true") embedded in it.  A CA is not automatically
trusted when it is encountered; it is only trusted if explicit trust
is placed in it (by either the vendor of the software or the user), or
if trust is inherited from an explicitly trusted certificate.

A "root CA" is a self-signed certificate with the "CA:true" extension.
 This is called the "trust anchor", as it is where all trust should be
placed in a given X.509 hierarchy.

> I want to point my mail program at imap.mydomain.com and
> smtp.mydomain.com. I want people to point their browser at
> www.mydomain.com and I want my roadwarriors to point their
> VPN clients at vpn.mydomain.com. So that when I have to
> change the actual machine the services are made available
> from I don't have to bother all my users/clients.

This is perfectly acceptable, though it is possible to have one
certificate that identifies multiple names (through the
"subjectAltName" extension).  There is no reason you can't issue
individual certificates with individual keypairs, though.

> First major question:
> What is the difference between a CA, CA certificate and a
> CA root certificate???

A "CA" is a "Certifying Authority".  It is a non-electronic entity
which verifies the authenticity of the credentials being requested,
and then issues those credentials.  (Think of something like the DMV,
issuing an ID card -- a CA is essentially like that, except that
instead of a physical card being the credential, the logical
certificate structure is the credential, no matter if it's stored in
software, on a smart card, or whathaveyou..)

As I mentioned above, a "CA certificate" is a certificate that has the
"CA:true" extension embedded in it.

A "CA root certificate" is a CA certificate that is signed by the
private key that corresponds to the public key in its certificate --
i.e., it is "self-signed".  The CA root certificate corresponds with
the Certifying Authority in whom all trust is placed.

> My guess is that I make CA, then I make a CA certificate,
> then I install the CA certificate in /etc/ssl/certs on all my
> servers/clients. Then I can use that CA cert to sign any other
> certs I want for individual services or client authentication.
>
> Is that correct?

Basically, yes.  There are some caveats, however.

The certificates you issue from your CAs (be they root CAs or
'chained' CAs, which are signed by another CA) must adhere to a
standard format, and the certificate extensions must match what the
software they are going to be interacting with expect.  In addition,
EVERY CERTIFICATE MUST HAVE A UNIQUE, POSITIVE SERIAL NUMBER.  This is
very important, because that serial number is the primary way that a
certificate is identified by any software that uses it.

> Questions:
> 1) Is it possible to make my own CA thing (I use "thing" because
>     I can't for the life of me figure out if I mean CA, CA certificate,
>     root certificate or master certificate, all of which I have seen
>     used seemingly arbitrarily on several dozen information sites
>     today.) Should I install this "thing" as a trusted CA on my
>     servers?  I think so, but I'm totally confused. I mean could it
>     possible to get more conflicting advice...

If you are attempting to create a CA, then you are a CA.
Congratulations -- you now have the responsibility for individually
issuing credentials to make use of your network.  Getting the software
set up, though, is a bit trickier.  (I'll address the
"interoperability software" issue first: yes, you install your CA root
certificate, which you will generate, as a trusted certificate in
every device and software that is going to be relying on your CA's
signatures.  Otherwise, how could they know that the CA that signed it
is really the CA that is supposed to have signed it?)

>     Here's what several sites have told me:
>
>     site 1:
>        openssl genrsa -des3 -out ca.key 1024
>        openssl req -new -x509 -days 1001 -key ca.key -out ca.cer

There's a MUCH easier front-end to this, though you will need to get a
CVS snapshot in order to make use of it.  It's called CA.pl or
CA.sh... either one of which will do what you need it to.  There is
documentation for it on the openssl.org website, as well as in the man
pages included in the distribution.

The command above is very unlikely to result in a workable CA, because
it does not embed the "CA:true" attribute in the certificate it
generates.  (And I would recommend at least a 2048 bit RSA key,
instead of 1024, but that's because I'm paranoid of the advances in
computing that are being made.)


>        And then no information as to where or how to install
>        this in my servers. Seems like /etc/ssl/certs would be a
>        good place except *nothing* else there ends in .cer so
>        I'm figuring this either created the wrong type of certificate
>        or there is some other magical command I have to run to
>        to convert to pem format.

What software are you using, that points to /etc/ssl/certs?  Is it a
particular Linux distribution, or is that where you have chosen to put
your trusted certificate store?

>
>        Also no information on how I sign something with this.
>

well, actually, the second command is basically what you use to sign
it -- use '-req' instead of '-x509' -- but again, I recommend using
the CA.sh or CA.pl wrappers to make it easier.

>     site 2: http://sial.org/howto/openssl/ca/
>        This site has "it" wrapped up in some sort of obfuscating
>        make file.
>
>        And again, no instructions how or where to install it so
>        that certificates signed by this CA.
>
>        This is possibly the worst site I came across in being
>        thuroughly vacuous in it's tutorial abilities.

It's also not run by OpenSSL, so nothing can be done about it by us. ;)

>     site 3: http://www.openssl.org/docs/apps/CA.pl.html
>        Yeah! another wrapper. Software convenience wrappers are a
>        lot like condoms in my opinion. Just messy. I'd like to
>        understand the process instead of guessing or relying on a
>        wrapper to make magical, incorrect guesses for me. But at least
>        this seems to be a defacto standard interface. Instead of a
>        wrapper the openssl tool/system should either be intuitive to
>        use or have exceptional documentation on how to use it with
>        lots of concrete, useful examples.

The wrapper is important because of the detail that it hides behind
the scenes.  In a followup message to this one, I'll explain the
process of certificate creation and verification in fairly
excruciating detail -- however, for information on the formats that it
creates (and why certain things have to be done the way they are) you
will need to read the ITU recommendation X.509 [you can get up to 3
documents per year from the ITU free of charge], as well as all of the
IETF/IESG documents (RFCs) that relate to the term 'X.509' -- at this
writing, there are 31 of them.  It would also help if you read the
'Secure Sockets Layer' and 'Transport Layer Security' RFCs, as well as
possibly the IPSEC RFCs.  [This is going to take you at least a week
to read, and probably another month to cross-reference and get a
working understanding of.]

The OpenSSL tools do, for those who have read the above documents,
have exceptional documentation.  It is NOT the place of OpenSSL to
provide a complete primer on exactly why it does what it does (that
honor is left for "Securing Networks with OpenSSL", a book published
by O'Reilly and Associates, information on which can be found at
http://www.oreilly.com/catalog/openssl/index.html ).

If you want better documentation, with lots of useful examples for
someone in your frame of mind, you (or someone with as little
knowledge as you) are going to have to be the one to write it.  Those
of us who have been dealing with cryptography for at least a decade
don't have the necessary detachment to be able to do it, as our very
thought patterns have been warped by understanding it.

>
>        So now I've got lots of easy, abstract options to choose from:
>        -newcert: Yeah! I can make a self signed cert. Do I need a
>                  self signed cert for what I described? Do I need just
>                  a cert or do I need a CA cert or do I need a CA root
>                  cert?

You need a CA certificate.  That's what the -newcert option does, it
creates a self-signed root CA certificate.

>        -newreq: What in the world is a certificate request?
>                 wouldn't that be something you sent verisign in
>                 order to obtain a certificate? I doubt it, but
>                 how else is one suppose to interpret "creates a new
>                 certificate request?" If it really is a request for
>                 a certificate then who do I send this request to once
>                 I create to obtain my desired cert?

Actually, the 'request' is something you send to ANY CA, not just
Verisign.  Once you have generated the request (which should be
generated under an account other than the one you use to run the CA
software, but that's 'separation of duty best practice'), you have a
private key and a public key.  The request contains the public key
that you (the CA) are being asked to certify.

>        -newca: creates a new CA heirarchy. This sounds good to me.
>                But it doesn't create a CA cert? do I need both a
>                CA heirarchy and a CA cert? which do I create first?
>                Does one need the other?

This is the initialization of the CA directory hierarchy, which
contains the certificates that have been issued by the CA with the CA
certificate, the CRLs that have been issued by that CA certificate, an
index file specifying what the next serial number in series is, and
probably a couple of other things that I'm forgetting.  It defaults to
creating a CA directory hierarchy rooted by a directory titled
'demoCA' in the current directory.

>
>        -sign
>        -signca
>        -signcert ugh. ok these seem to sign things. I know my service
>                  certs need to be signed. I know that ssl/tls just
>                  walks back up the signature/cert chain until a trusted
>                  cert is found or a self signed cert is encountered.
>                  I actually do know that my CA cert needs to be
>                  self-signed (if I need a CA cert at all) and needs to
>                  installed in such a way that it is trusted. But I
>                  can't figure that how.

Your service certificates need to be signed, yes.  There are different
ways that a certificate request can be signed, and here's the
difference:

-sign takes a certificate request located in the file 'newreq.pem',
which is in PEM format, and signs it according to the default policy.
It puts the output into 'newcert.pem'.

-signcert takes a self-signed X.509 certificate and re-signs it with
the current CA certificate.

-signCA takes a newreq.pem and signs it with a different
configuration, so that it becomes a valid 'chained' CA.

-xsign takes a certificate request located in the file 'newreq.pem',
which is in PEM format, and signs it according to the default policy.
It writes its output to stdout, so you can redirect it into a filename
of your choosing.

>        Oh good... I especially liked this part for -signca...
>        "This is useful when creating intermediate CA from a root CA."
>        Have I just learned that I also need an intermediate CA in addition
>        to my root CA??? is a root CA the same as a root CA certificate
>        or does it mean a root CA heirarchy??

An 'intermediate CA' is a CA that you delegate trust to.  Generally it
has a shorter validity period than the root CA, and is used to sign
certificate requests for a limited time.  It may also be operated by
someone other than the main CA.  In your instance, you do not appear
to need this functionality; however, if you end up having multiple
sites, you can create delegated CAs for them and have someone there
use THAT CA to sign certificates valid under your CA's trust.

>
> 2) Once I have the CA item figured out how do I create new certs for
>     services that are signed by this CA thing?
>

To generate new certs for services, the easiest way is to take their
current certificates, copy them one by one into the 'newreq.pem' file,
and then use CA.pl -signcert .  This will eliminate the need to
generate new keys or a new request for each service.  (Note that after
you run that command, you will have a file called 'newcert.pem', which
must be copied back to the location that you got the original
certificate for that service from.)

> Please forgive me for being rude. I'm tired, I'm hungry, Got a huge
> headache, can't get my sewing machine parts back together into anything
> that resembles a sewing machine and I've spent several hours today just
> trying to understand the nomenclature of this stuff again.

Oh, hey.  Forgive me for being rude -- I have an infected compromised
root canal, am on massive loads of antibiotics and prescription
painkillers which aren't doing a thing to help with the pain, and I'm
tired and hungry because it's keeping me from sleeping and chewing
anything makes the entire side of my head feel like it's on fire.  I
also can't find my leatherworking tools, and am trying to figure out
how to pay this coming month's rent on my disability check.  and I
/wish/ I had sewing machine parts to try to assemble into a sewing
machine.

Politeness doesn't cost a thing, even if you're in discomfort.  (And
just my saying this makes me feel like I'm being rude, because I feel
like I'm lecturing when it's unwarranted.)

The nomenclature of this stuff IS COMPLICATED.  There is no way around
that, because the ITU decided that they knew best, and the IETF has
been trying to work with the ISO standards that the ITU
recommendations became.  Our hands are tied, here -- and I'm very,
very sorry that it's difficult to write any kind of documentation that
works.  (I might try to write something to include into the "extra
contributed docs" section, though.)

> I have spent
> probably a hundred or more hours over the past few years trying to
> understand this exact same thing and never succeeded, forced to give up
> everytime.

This is why the wrapper exists, honestly.  The OpenSSL team does do
its best to make it as easy as possible, but there's simply too much
complexity underneath to fully hide.

>
> Summary:
>
>     Would somebody tell me the exact, complete steps, using only the
> openssl program, on unix/linux how to make yourself capable of being an
> authority and signing additional certificates for use with individual
> services?

CA.pl -newcert # create a new keypair and self-signed certificate,
located where the next command wants them
CA.pl -newca # Creates the CA directory hierarchy, making the
self-signed certificate into a CA, and putting the files it needs
[such as the private key file] where the -sign, -xsign, -
CA.pl -newreq # (for each service that you want to generate a new
request for).  The private key will be located in the newreq.pem file,
along with the certificate request.
CA.pl -xsign > service.pem # This will take the newreq.pem file and
sign it, WITHOUT PUTTING THE PRIVATE KEY INTO THE .PEM FILE.  You need
to have both the newreq.pem and the service.pem files copied to a
place specifically for that service, before you do the -newreq again.

The CA program will request information, including something called
"Distinguished Name", or DN.  This is.. complicated to explain, but
I'll do my best.

The DN of an individual is supposed to be in the format
C=/O=/OU=/[OU=/...]/CN=<user's name>/E=<user's email address>.  This
is a holdover from when the ITU honestly thought that there would be a
single worldwide root CA that would issue certificates to governments,
which would then issue them to companies, and the companies would
issue them to individuals.  (It's the X.500 naming schema, and it's
also how LDAP sees things.)  HOWEVER... CN=<user's name> works just as
well without all the overhead.  (This is how OpenCA does it.)

(If you're curious, C=Country, O=Organization, OU=Organizational Unit,
CN=Common Name, E=Email.)

For servers, there should be only one entry in the DN field, and that
is "DN=server.name.company.com".  However, you may have multiple DNs
in the same certificate (or a 'wildcard' "DN='*.company.com", which
will match any server under the company.com domain, and
DN=company.com, which will match if the user doesn't type 'www' or
'imap' or 'mail' or whathaveyou).

>
> The answer should include
>    A) A list of openssl commands.
>    B) For each command brief description of the purpose of the command
>    C) A description of how to install the result as an authoritative
>       certificate so that clients automatically accept certificates
>       signed by the result.

Because the procedure varies from client software to client software
and server software to server software, doing part C is impossible.  I
can give you the general procedure, though the specifics depend on the
software you're using:

The cacert.pem file must be placed into the 'trusted root
certificates' directory for the software you're using.  (You may wish
to run:
openssl x509 -inform PEM -outform PEM -in cacert.pem -out
cacerttrust.pem -trustout
if you are using any other software that uses openssl; I'm not sure at
what point trust is checked, so it's probably better to be safe than
sorry.)  If you are using a directory for CA certificates, and it's
used by anything that uses openssl, you need to copy the trusted
certificate into the directory and then run the c_rehash script in
that directory.

For software other than anything using OpenSSL, you need to check the
docs for that software... but ALL SOFTWARE - SERVER AND CLIENT - MUST
HAVE THE NEW CA IN ITS TRUSTED LIST.  If that is not done, the
certificates issued by your CA will not be trusted by that software.

Once that is done, your server software config needs to be modified to
ask for certificates from your CA's name, for client authentication
purposes.

>
> The only thing I can offer is that if you help me then I will attempt
> to write a very detailed and accurate description of the process so
> that newbs like me don't have such a difficult time adopting this
> system in the future.

How's this: You write, I go over for technical accuracy, and then we
submit it? :)

>
> Thanks,
>
> - Jeff

-Kyle H
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Silly CA/certs questions...

Georg Lohrer-6
Hi Kyle,
   
On Mi, 22 Feb 2006, Kyle Hamilton wrote:

[lots of interesting stuff snipped]

let me jump into your thread for a short remark.

Kyle, thank you very much for your patience with such rookies like myself and
maybe Jeff. As you wrote:

> The nomenclature of this stuff IS COMPLICATED.  There is no way around
> that, because the ITU decided that they knew best, and the IETF has
> been trying to work with the ISO standards that the ITU
> recommendations became.  Our hands are tied, here -- and I'm very,
> very sorry that it's difficult to write any kind of documentation that
> works.  (I might try to write something to include into the "extra
> contributed docs" section, though.)

Your recent post clarify or fills some gaps in my knowledge about this X.509
stuff and handling such an environment. I have read lots of HOWTO's and
documentation and everytime have come to the point, there the doc is too old
inaccurate, wrong or even all of them.
So there are lots of white-spots and gaps belonging to this theme in my
knowledge.

Especially your and Stephens help on last sunday (!) was invaluable. I
cannot give back help in this context, but be assured that there are other
themes I really know my stuff :-) And accomodation like yours is always a
good reason to do the same on my grounds.

How about letting you last mailing-list entry as an entry-point for a
advanced beginners HOWTO? Only raw text, nothing else, no extra work.

ciao, Georg
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Silly CA/certs questions...

Mark-62
In reply to this post by Jeff Wiegley-2
Hi Jeff,

It sounds like you are going through exactly the same process I went
through a while back.  I thoroughly emphasise!

It looks like you have already had a very thorough answer to your
questions so I'll let you digest these for now :-)

> > The only thing I can offer is that if you help me then I
> will attempt
> > to write a very detailed and accurate description of the process so
> > that newbs like me don't have such a difficult time adopting this
> > system in the future.

I had that exact thought and have already written such a document.  It
is by no means complete so I haven't attempted to submit/publish it yet.

> How's this: You write, I go over for technical accuracy, and then we
> submit it? :)

Maybe we could collaborate on such a project?

Mark Williams
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Silly CA/certs questions...

Kyle Hamilton
In reply to this post by Georg Lohrer-6
I've been trying to take a bit of load off of Dr. Henson, cuz he has
other work to do.  I can't contribute to him financially,
unfortunately, but I do have what I think is a lot of knowledge on the
topic, and am willing to help out as much as I can.

However, there are some questions that only he can answer.  I'm adding
to my own knowledgebase from his answers as we go along.

On 2/22/06, Georg Lohrer <[hidden email]> wrote:

> Hi Kyle,
>
> let me jump into your thread for a short remark.
>
> Kyle, thank you very much for your patience with such rookies like myself and
> maybe Jeff. As you wrote:
>
> > The nomenclature of this stuff IS COMPLICATED.  There is no way around
> > that, because the ITU decided that they knew best, and the IETF has
> > been trying to work with the ISO standards that the ITU
> > recommendations became.  Our hands are tied, here -- and I'm very,
> > very sorry that it's difficult to write any kind of documentation that
> > works.  (I might try to write something to include into the "extra
> > contributed docs" section, though.)
>
> Your recent post clarify or fills some gaps in my knowledge about this X.509
> stuff and handling such an environment. I have read lots of HOWTO's and
> documentation and everytime have come to the point, there the doc is too old
> inaccurate, wrong or even all of them.
> So there are lots of white-spots and gaps belonging to this theme in my
> knowledge.

I'm not going to lie -- there's blank spots and gaps in MY knowledge
of this stuff.  (I've been trying to read all of the RFCs and
documentation that I referenced, and good GOD is it a pain to
understand.  ITU specs are like reading Engrish stereo instructions.
IETF specs are like reading "War and Peace".)

> Especially your and Stephens help on last sunday (!) was invaluable. I
> cannot give back help in this context, but be assured that there are other
> themes I really know my stuff :-) And accomodation like yours is always a
> good reason to do the same on my grounds.
>
> How about letting you last mailing-list entry as an entry-point for a
> advanced beginners HOWTO? Only raw text, nothing else, no extra work.

Because a scenario needs to be built-up, and I snipped the scenario
out of my reply to Jeff.  However, a wiki might be appropriate for
such a thing... hmmm....

-Kyle H
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Silly CA/certs questions...

Kyle Hamilton
In reply to this post by Mark-62
Just a comment, in-line...

On 2/22/06, Mark <[hidden email]> wrote:
> Hi Jeff,
> > > The only thing I can offer is that if you help me then I
> > will attempt
> > > to write a very detailed and accurate description of the process so
> > > that newbs like me don't have such a difficult time adopting this
> > > system in the future.

I honestly think that the ITU process (which is basically "governments
and telephone companies") have absolutely no regard for the people who
are trying to implement these standards.  The specs they write are
geared for people who understand bureaucratese [just try reading the
spec for BER sometime -- er, wait, don't, I wouldn't wish that on my
worst enemy].  I don't like this, and part of my reason for wanting to
be involved in the OpenSSL project is because I want to make it much
more accessible.

For example, X.500 is the directory standard.  That set of standards
also specify a means of querying that directory, starting at a global
root and resolving referrals.  This cannot under any circumstances
work -- so LDAP, the Lightweight (X.500) Directory Access Protocol was
created by the IETF to work around the technical deficiencies.

BER is supposed to be an "agnostic" encoding mechanism... but now we
have XML, which is better at it than BER could ever dream.  But, due
to past mistakes (on Netscape's and Verisign's parts, originally, if I
understand history correctly), we're stuck with DER-based
certificates, which have to be encoded into 5-bit ASCII to effectively
transmit over a text-only channel.  This is, to my mind, a
disgustingly suboptimal solution.

> I had that exact thought and have already written such a document.  It
> is by no means complete so I haven't attempted to submit/publish it yet.

Why not post what you've got, and we can work on it?

> > How's this: You write, I go over for technical accuracy, and then we
> > submit it? :)
>
> Maybe we could collaborate on such a project?

Again, I'll go over it for technical accuracy.  (Since I can find the
references that I've run into, and know how to read them, I'll take
the 'technical editor' job.)

One of the things that has always bugged me about OpenSSL is its lack
of user-friendly documentation.  Yes, it was always meant to be a
library and some command-line tools... but understanding what those
command-line tools actually do is difficult.  A kind of "intro to
OpenSSL and all of its dependent technologies" would be a very nice
thing to have.

-Kyle H
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Silly CA/certs questions...

Mark-62
In reply to this post by Jeff Wiegley-2
Hi Kyle,

> > I had that exact thought and have already written such a
> document.  It
> > is by no means complete so I haven't attempted to
> submit/publish it yet.
>
> Why not post what you've got, and we can work on it?

It was prepared while I was working for a client although I have
modified it since.  I would be happy to post it once I have considered
if there are any copyright issues.

Mark Williams
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Silly CA/certs questions...

Kyle Hamilton
Best to ask the client to sign off on it -- explain that he (it, in
the case of a corporation) benefitted from the technology, and
benefitted from you writing it to understand the technology, and that
it would a) retain a 'some material contributed by' acknowledgement,
thus being a form of free advertising (if he wants it), and b) go a
long ways to help support the technology that he's benefitting from,
to help understand the deficiencies and make it even better and more
user-friendly.

(Work produced under contract with another entity belongs to that
entity as a 'work for hire', even if it's only partially related.  at
least, that's my understanding of the situation, and since I don't
want to get involved in any copyright disputes, I'd like to make sure
it's okay.)

-Kyle H

On 2/22/06, Mark <[hidden email]> wrote:

> Hi Kyle,
>
> > > I had that exact thought and have already written such a
> > document.  It
> > > is by no means complete so I haven't attempted to
> > submit/publish it yet.
> >
> > Why not post what you've got, and we can work on it?
>
> It was prepared while I was working for a client although I have
> modified it since.  I would be happy to post it once I have considered
> if there are any copyright issues.
>
> Mark Williams
> ______________________________________________________________________
> OpenSSL Project                                 http://www.openssl.org
> User Support Mailing List                    [hidden email]
> Automated List Manager                           [hidden email]
>
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Silly CA/certs questions...

Mark-62
In reply to this post by Jeff Wiegley-2
Hi,

> Best to ask the client to sign off on it

I have asked and they are OK about me posting the document.

Here it is (An RTF attachment).  Please bear in mind it was
written for a particular use in mind and will need modifying to
make it more general.

Mark Williams

SSLNotes_rtf.zip (38K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Silly CA/certs questions...

Jeff Wiegley-2
Kyle,

   That response was AWESOME! Though it did raise more questions
that I'll ask in a later post after I've digested more and tried
to play with some of the stuff you mentioned. (And you're right,
suffering is no reason to be rude. Sorry.)

Georg, I liked the idea for an advanced beginners HOWTO a lot. I
        am willing to organize or help with this.

Mark, I received your rtf document but have not had time to read
       it as my day today is packed with lectures starting soon that
       I haven't prepared for. But I think collaborating on such a
       [advanced beginners HOWTO] project is a fantastic idea. I have
       lots of topics and questions that I think would make for
       good additions to such a really fine document.

I think Kyle's suggestion of a wiki is a really good way to
collaborate on this because we can all make changes and add ideas
to it. This way we can avoid any overall gaps even though each of
us (mostly me) has some gaps in our knowledge.

I would suggest a multipage-wiki that can be hyperlinked so that we
can fork off pages for topics that are too detailed or cover obscure
necessities without that information cluttering up the main/earlier
pages geared towards the true newbs such as myself.

I haven't set up a wiki before. I'll look into later today or
tomorrow afternoon. If anybody has suggestions for what wiki
software to use I'd like to hear them. (My publication expertise
is in the TeX/LaTeX arena, not so much wiki/HTML.)

- Jeff
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Silly CA/certs questions...

Georg Lohrer-6
Hi,

On Mi, 22 Feb 2006, Jeff Wiegley wrote:

> Georg, I liked the idea for an advanced beginners HOWTO a lot. I
>        am willing to organize or help with this.

yes, me too.

But - the idea now has a lot of strength and speed, but do the "old-men"
of
OpenSSL really want such a way? I don't know.

> I haven't set up a wiki before. I'll look into later today or
> tomorrow afternoon. If anybody has suggestions for what wiki
> software to use I'd like to hear them. (My publication expertise
    > is in the TeX/LaTeX arena, not so much wiki/HTML.)

I have setup DokuWiki (run without backside-database system) for my own
purposes for documenting my affairs and experiences. Was about 3-4 hours
to
get it run. If you have low front-side expectations (no splendid design,
    no extraordinary gimmicks, etc.) it's a piece of cake.

Ciao, Georg
   
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Silly CA/certs questions...

Kyle Hamilton
MediaWiki requires a MySQL backend, but it runs quite well and has a
fairly decent set of design templates included with it.  (It's what
powers Wikipedia, among others.)

A wiki is, by its very nature, a multi-page, document-hotlink system.
This makes distilling it down for a paper publication much more
difficult, but it also makes for the ability for multiple authors to
edit different pages simultaneously.  It also allows cross-referencing
much more easy.

And, if you're familiar with LaTeX, you're much more likely to
understand Wiki markup than HTML -- HTML is (loosely) based on SGML;
Wiki markup is more based on [[tag this]] going to a new page called
'tag this', parsed dynamically on the server side.  (Some Wikis use
WikiMarkUpWithInternalCaps, but I can't stand that format, honestly.)

I have not yet gotten the chance to look at the RTF attachment, but I
will as soon as I catch up on other stuff.  (There's a list of wiki
hosts at http://en.wikibooks.org/wiki/Wiki_Science:How_to_start_a_Wiki#.22Hosted_wiki.22_and_Wiki_hosts
-- I haven't looked at them, except to say that I don't believe
wikicities would be a good choice for this project.)

Cheers,

-Kyle H

On 2/22/06, Georg Lohrer <[hidden email]> wrote:

> Hi,
>
> On Mi, 22 Feb 2006, Jeff Wiegley wrote:
>
> > Georg, I liked the idea for an advanced beginners HOWTO a lot. I
> >        am willing to organize or help with this.
>
> yes, me too.
>
> But - the idea now has a lot of strength and speed, but do the "old-men"
> of
> OpenSSL really want such a way? I don't know.
>
> > I haven't set up a wiki before. I'll look into later today or
> > tomorrow afternoon. If anybody has suggestions for what wiki
> > software to use I'd like to hear them. (My publication expertise
>     > is in the TeX/LaTeX arena, not so much wiki/HTML.)
>
> I have setup DokuWiki (run without backside-database system) for my own
> purposes for documenting my affairs and experiences. Was about 3-4 hours
> to
> get it run. If you have low front-side expectations (no splendid design,
>     no extraordinary gimmicks, etc.) it's a piece of cake.
>
> Ciao, Georg
>
> ______________________________________________________________________
> OpenSSL Project                                 http://www.openssl.org
> User Support Mailing List                    [hidden email]
> Automated List Manager                           [hidden email]
>
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Silly CA/certs questions...

Georg Lohrer-6
On Mi, 22 Feb 2006, Kyle Hamilton wrote:

> (There's a list of wiki
> hosts at http://en.wikibooks.org/wiki/Wiki_Science:How_to_start_a_Wiki#.22Hosted_wiki.22_and_Wiki_hosts
> -- I haven't looked at them, except to say that I don't believe
> wikicities would be a good choice for this project.)

And for further information at
http://en.wikipedia.org/wiki/Comparison_of_wiki_software you'll find a
comparison of some well known wikis.
http://c2.com/cgi/wiki?WikiEngines shows the most available wiki-SW at your
fingertips.

Ciao, Georg

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Silly CA/certs questions...

Mark-62
In reply to this post by Jeff Wiegley-2
Hi Kyle, Georg, Jeff & All,

> A wiki is, by its very nature, a multi-page, document-hotlink system.
> This makes distilling it down for a paper publication much more
> difficult, but it also makes for the ability for multiple authors to
> edit different pages simultaneously.  It also allows cross-referencing
> much more easy.

I must admit to be unfamiliar with a "wiki".  I have always
used a plain old wordprocessor for documentation (I must be getting
old!).

I'm sure the ability to have multiple authors is useful, but it would be
handy to be able to print the document.  Personally I would like to
keep the document in plain text or common wordprocessor format for
simplicity.

Regards,
Mark Williams
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Silly CA/certs questions...

Georg Lohrer-6
Mark,

On Do, 23 Feb 2006, Mark wrote:

> I'm sure the ability to have multiple authors is useful, but it would
> be
> handy to be able to print the document.

oh that's not mutually exclusive. Most of the Wiki's provide some rather
good
printouts. Some of them (the wikis) even provide a pdf-transfiguration.

> Personally I would like to
> keep the document in plain text or common wordprocessor format for
> simplicity.

The real general text-format with all possible ways of
pre-write-output-transformation would be to use SGML. The next best would
be
to have DocBook or at least on the word-formatting side LaTeX itself.
If someone is a little bit familiar with LaTeX or HTML-formatting, all
Wiki-input basics will be plain easy.
On the other hand, if the information is stored in the wiki it is not
really
simple to get it out of there in another format. If that way is desired
or
necessary, nothing would be as flexible as SGML with different
output-filters
for LaTeX, PDF, DOC-formats, plain-text, etc.
But with a wiki it's very simple and easy to run iterativly through the
edit-store-correct-store cycle. With distinguished documents which have
to be
passed around or are stored in a (distributed) version control system it
will
be a pain.
So it depends on the real needs of this documentation and last not least
the
time the authors will spend for this work.

Ciao, Georg
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Silly CA/certs questions...

Nicolas Margaine
Hi,

I know that MediaWiki has an XML export format (http://meta.wikimedia.org/wiki/XML_export).
The problem is that all the wiki markups are not translated in XML.
The best solution would be to export the mediaWiki data in a docbook xml format.
Unfortunately, as said in http://www.hula-project.org/Wiki_Conversion this seems to be un incomplete solution. (the best solution seems to be flexbisonparse but I didn't try it)

Regards,

Nicolas Margaine


On 2/23/06, Georg Lohrer <[hidden email]> wrote:
Mark,

On Do, 23 Feb 2006, Mark wrote:

> I'm sure the ability to have multiple authors is useful, but it would
> be
> handy to be able to print the document.

oh that's not mutually exclusive. Most of the Wiki's provide some rather
good
printouts. Some of them (the wikis) even provide a pdf-transfiguration.

> Personally I would like to
> keep the document in plain text or common wordprocessor format for
> simplicity.

The real general text-format with all possible ways of
pre-write-output-transformation would be to use SGML. The next best would
be
to have DocBook or at least on the word-formatting side LaTeX itself.
If someone is a little bit familiar with LaTeX or HTML-formatting, all
Wiki-input basics will be plain easy.
On the other hand, if the information is stored in the wiki it is not
really
simple to get it out of there in another format. If that way is desired
or
necessary, nothing would be as flexible as SGML with different
output-filters
for LaTeX, PDF, DOC-formats, plain-text, etc.
But with a wiki it's very simple and easy to run iterativly through the
edit-store-correct-store cycle. With distinguished documents which have
to be
passed around or are stored in a (distributed) version control system it
will
be a pain.
So it depends on the real needs of this documentation and last not least
the
time the authors will spend for this work.

Ciao, Georg
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]



--
Nicolas Margaine