PKI root signing ceremony, etc.

[Dave Howe]

Rich Salz wrote:
>> *shrug* it doesn't retroactively enforce the safety net - but that's
>> ok, most MS products don't either :)
> The whole point is to enhance common practice, not stay at the lowest
> common denominator.
If someone has *already* issued a certificate - and ignored the CA flag - is
it part of the software's duty to somehow point this out to you? But
regardless, as this only applies to imported keys you would never actually
see it in Real Life (tm)

>> Key management and auditing is pretty much external to the actual
>> software regardless of which solution you use I would have thought.
> You'd be wrong. :)  I did just download and use XCA for a little bit.
> It's practically impossible to audit.  Every key in the database is
> protected with the same password.
um, this is a **CA** - you have *one* key in the database, your CA key. It
is bad practice to generate the keys on the CA machine and transport them to
the server they will be used on - instead, the Cert request should be
generated on the end-use machine, and the *request* transported to the CA,
signed, and the certificate returned. That way, the private key never leaves
the machine it was generated for and used on, and is protected by its own
password.

> The system ask for the password
> as soon as it starts up.  If I leave the program running while
> I leave my computer, I'm screwed.
Then don't leave it running. If you got out of your car but left the engine
running, and somebody stole the car, would you blame the design of the car?

> The key-holder isn't asked to
> confirm each signing -- there's no *ceremony* -- and they never
> enter the password after the program starts.  For any kind of root
> these are all very bad.
This is just fine for a root - the root acquires 'n' signing requests, opens
the program, signs or rejects the requests as appropriate, then closes the
program.  It is not the duty of the CA to generate keys or enter certificate
information - that is the requestor's problem, which he can do with the
tools appropriate to his machine (openssl on almost anything, the built in
keygen in IIS and several other webservers, and so forth. I am actually
disappointed in XCA (compared to the earlier but awkward to set up OpenCA
project) in that no browser-accessable request interface is provided. of
course XCA is compatable with importing requests made from OpenCA, and
exporting them back into an openCA "pickup" dir..... but really it would be
nice to be compatable with the interface most key requestors are used to.

> XCA is pretty nice for a Level-2 or small Level-1 CA.  The template
> management, etc., is pretty good.  (Having them tied to the key
> database, and having the keys be unlocked while making cert requests,
> are both real bad ideas, however.)
There is no mystical value in having to type a key lots of times. I was just
pointing out what other options are out there (I would have pointed out
EBCrypt as well, which appears better suited to your current ritual, but its
website seems to have vanished)