1:44 p.m.
Hey bright idea bringers!
The Fedora Certificates issued by FAS are currently set to be
autogenerated if you have an account in FAS. This has one drawback. We
have to keep the password for the CA keys that sign the FAS certificates
in a file on the filesystem so that the automatic signing can use them.
Has anyone else had to confront this problem? Right now I'm thinking of
coding something that involves human interaction to sign the certs and
send email notifying people when their cert is ready to download.
That's certainly doable, but introduces a wait time that isn't in the
current design. I'd love input on better ways to do this.
-Toshio
2:18 p.m.
2008/8/21 Toshio Kuratomi <a.badger(a)gmail.com>:
The Fedora Certificates issued by FAS are currently set to be autogenerated
if you have an account in FAS. This has one drawback. We have to keep the
password for the CA keys that sign the FAS certificates in a file on the
filesystem so that the automatic signing can use them.
Has anyone else had to confront this problem? Right now I'm thinking of
coding something that involves human interaction to sign the certs and send
email notifying people when their cert is ready to download. That's
certainly doable, but introduces a wait time that isn't in the current
design. I'd love input on better ways to do this.
What about using a crypto card like Jesse plans on using for Sigul?
Jeff
2:21 p.m.
On Thu, 21 Aug 2008, Jeffrey Ollie wrote:
2008/8/21 Toshio Kuratomi <a.badger(a)gmail.com>:
>
> The Fedora Certificates issued by FAS are currently set to be autogenerated
> if you have an account in FAS. This has one drawback. We have to keep the
> password for the CA keys that sign the FAS certificates in a file on the
> filesystem so that the automatic signing can use them.
>
> Has anyone else had to confront this problem? Right now I'm thinking of
> coding something that involves human interaction to sign the certs and send
> email notifying people when their cert is ready to download. That's
> certainly doable, but introduces a wait time that isn't in the current
> design. I'd love input on better ways to do this.
What about using a crypto card like Jesse plans on using for Sigul?
I've never actually used a crypto card... Do they add additional security
if they're sitting in a colo always plugged in? If so how do they do
that?
-Mike
2:25 p.m.
On Thu, Aug 21, 2008 at 2:21 PM, Mike McGrath <mmcgrath(a)redhat.com> wrote:
On Thu, 21 Aug 2008, Jeffrey Ollie wrote:
> What about using a crypto card like Jesse plans on using for Sigul?
I've never actually used a crypto card... Do they add additional security
if they're sitting in a colo always plugged in? If so how do they do
that?
I'm not sure either, but the impression that I get is that while you
can get the crypto card to sign certificates, you can't extract the
private key from it.
Jeff
2:34 p.m.
On 2008-08-21 02:21:34 PM, Mike McGrath wrote:
I've never actually used a crypto card... Do they add additional
security
if they're sitting in a colo always plugged in? If so how do they do
that?
I might be wrong, but I think with such a card, encryption/signing takes
place entirely on the card, and thus the secret key is never transferred
anywhere off the card.
Thanks,
Ricky
2:40 p.m.
On Thu, 21 Aug 2008, Ricky Zhou wrote:
On 2008-08-21 02:21:34 PM, Mike McGrath wrote:
> I've never actually used a crypto card... Do they add additional security
> if they're sitting in a colo always plugged in? If so how do they do
> that?
I might be wrong, but I think with such a card, encryption/signing takes
place entirely on the card, and thus the secret key is never transferred
anywhere off the card.
Ah, so the theory being that if someone happens to hit us, they're only
hitting us for as long as the machine is up / card is in. And I assume
the card actually tracks serial numbers and things so we can revoke
anything that was signed in a questionable time?
-Mike
3:22 p.m.
Mike McGrath wrote:
On Thu, 21 Aug 2008, Ricky Zhou wrote:
> On 2008-08-21 02:21:34 PM, Mike McGrath wrote:
>> I've never actually used a crypto card... Do they add additional security
>> if they're sitting in a colo always plugged in? If so how do they do
>> that?
> I might be wrong, but I think with such a card, encryption/signing takes
> place entirely on the card, and thus the secret key is never transferred
> anywhere off the card.
>
Ah, so the theory being that if someone happens to hit us, they're only
hitting us for as long as the machine is up / card is in. And I assume
the card actually tracks serial numbers and things so we can revoke
anything that was signed in a questionable time?
That seems like it would work well. Jesse's been having troubles
obtaining the card he wants, though (and his is a gpg card, not for ssl
certificates).
the big thing might be having open source drivers.
-Toshio
2:43 a.m.
Toshio Kuratomi schreef:
Mike McGrath wrote:
> On Thu, 21 Aug 2008, Ricky Zhou wrote:
>
>> On 2008-08-21 02:21:34 PM, Mike McGrath wrote:
>>> I've never actually used a crypto card... Do they add additional
>>> security
>>> if they're sitting in a colo always plugged in? If so how do they do
>>> that?
>> I might be wrong, but I think with such a card, encryption/signing takes
>> place entirely on the card, and thus the secret key is never transferred
>> anywhere off the card.
>>
>
> Ah, so the theory being that if someone happens to hit us, they're only
> hitting us for as long as the machine is up / card is in. And I assume
> the card actually tracks serial numbers and things so we can revoke
> anything that was signed in a questionable time?
>
That seems like it would work well. Jesse's been having troubles
obtaining the card he wants, though (and his is a gpg card, not for ssl
certificates).
Most of these cards work with OpenSSL just fine - though I'm not sure
what additional hardware drivers are required to interface to the card.
All the card does is protect the private key from being obtained. When
someone has (root) access to the machine, he can use the key for signing
anyway. As such, an hsm should be connected only to a very secure
machine, not running any other services and with highly restricted
access. Connecting one to a Xen machine does not sound like a good idea :)
These keys are protected against hardware intrusion depending on their
security level and will zero out the keys upon hardware tampering.
Kind regards,
Mark
3:56 p.m.
On Sat, 2008-08-23 at 09:43 +0200, Mark Wormgoor wrote:
Most of these cards work with OpenSSL just fine - though I'm not sure
what additional hardware drivers are required to interface to the card.
The crypto cards I'm aware of require a binary kernel driver. Not
suitable for Fedora infrastructure.
The gpg smartcards I ordered are finally on the way, a billing snafu
prevented them from showing up earlier.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
3:06 p.m.
On Thu, 2008-08-21 at 14:18 -0500, Jeffrey Ollie wrote:
What about using a crypto card like Jesse plans on using for Sigul?
I wonder if a TPM can be (ab)used for this, too; they are pretty common
on newer hardware, and store a key in HW that can not be extracted.
Not sure though if anybody has looked at using it to sign SSL certs, and
especially at keeping logs of what was signed in a way that makes it
impossible to tamper with those logs, e.g. to hide the signing of some
certs.
David
3:53 p.m.
On Fri, 22 Aug 2008, David Lutterkort wrote:
On Thu, 2008-08-21 at 14:18 -0500, Jeffrey Ollie wrote:
> What about using a crypto card like Jesse plans on using for Sigul?
I wonder if a TPM can be (ab)used for this, too; they are pretty common
on newer hardware, and store a key in HW that can not be extracted.
Not sure though if anybody has looked at using it to sign SSL certs, and
especially at keeping logs of what was signed in a way that makes it
impossible to tamper with those logs, e.g. to hide the signing of some
certs.
Possibly. I was looking earlier too for something like ssh-agent or gpg
agent to serve this purpose... Haven't seen anything. Which.. well
strikes me as strange. It'd be a software way to do what we're talking
about.
-Mike
12:49 p.m.
2008/8/21 Toshio Kuratomi <a.badger(a)gmail.com>:
Hey bright idea bringers!
The Fedora Certificates issued by FAS are currently set to be autogenerated
if you have an account in FAS. This has one drawback. We have to keep the
password for the CA keys that sign the FAS certificates in a file on the
filesystem so that the automatic signing can use them.
Has anyone else had to confront this problem? Right now I'm thinking of
coding something that involves human interaction to sign the certs and send
email notifying people when their cert is ready to download. That's
certainly doable, but introduces a wait time that isn't in the current
design. I'd love input on better ways to do this.
It depends on the level of security we are wanting. The most secure
places I have been at always make sure there is a human in the loop,
and that human's events are regularly and randomly audited. Even
having hardware tokens to generate things (we had a device that was
hooked in via a serial port so it did not need a kernel driver) for a
high level of CIA you may want a set of humans looking at it. However
it puts in a delay. We would put a 24 hour delay in getting/creating
certs for people which meant we had time to confirm that the person
really was supposed to get it etc..
If the delay and the fact that we aren't doing background checks on
applicants, we probably want to do a multi-tier level of creating
tokens. One set would be ones that people need to be vetted somehow
and have more keys to the kingdom. The other set would be for people
doing common work flow at the project.
I wonder if we can come up with some serial port key generator. I
think the design was a locked box where you keyed in the the master
number via itsy-bitty dipswitches.
--
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"
5719
days inactive
5724
days old
infrastructure@lists.fedoraproject.org
11 comments
8 participants
participants (8)
-
David Lutterkort -
Jeffrey Ollie -
Jesse Keating -
Mark Wormgoor -
Mike McGrath -
Ricky Zhou -
Stephen John Smoogen -
Toshio Kuratomi