Does Your Company Use a PKI Solution? 171
punkrokk asks: "I am doing an Independent study of the feasibility of a Microsoft Certificate Services PKI in a distributed company. So far, it appears from my research that MS has the best supported implementation of a X.509 based PKI solution, for the Windows environment. While there are a few major weaknesses in a X.509 Public Key Infrastructure, one of which being Certificate Revocation Lists, using one is better than nothing. You do get a tangible security benefit, in addition to doing switch port authentication, and VPN quarantines. The problem is the cost of implementation is pretty steep, from the planning side. What do you guys do for dual factor authentication? Has anyone had Verisign sign their Certificate Authority? If you have implemented a MS Certificate Service infrastructure, I would appreciate your comments."
GeoTrust (Score:5, Informative)
More information, with presentations and descriptions of our deployment:
http://doit.wisc.edu/middleware/pki/ [wisc.edu]
UW/GeoTrust/EDUCAUSE joint press release:
http://doit.wisc.edu/middleware/pki/geotrustuwpki
For more information about UW-Madison's PKI deployment, contact Nick Davis [mailto]
Re:GeoTrust (Score:1)
kerberos (Score:1, Informative)
Re: (Score:2)
Re:kerberos (Score:2)
Re: (Score:2)
MS PKI (Score:4, Informative)
Security through obscurity (Score:5, Funny)
Security is good, but only as good as the weakest link in the chain. If you have humans working for you, they are the weakest link. It's a lot like a car with a flat tire. You should change to the spare, but realistically, the spare is probably a small tire that isn't really designed to be run on for long distances and will cause you to lose control if you rely on it too much.
Re:Security through obscurity (Score:5, Funny)
Re:Security through obscurity (Score:1)
Re:Security through obscurity (Score:1)
Re:Security through obscurity (Score:1)
(Sorry, we were just wagging our dicks today at work over who had the lowest slashdot userid, and I won by a wide margin).
Re:Security through obscurity (Score:2)
Oh, and you lose....
Re:Security through obscurity (Score:2, Funny)
Hard of hearing, there, grand pa? Here, have some oatmeal and your coffee. The Price Is Right is gonna be on shortly. Let me push you up to about 3 inches away from the TV and crank the volume to max for you. Here's your blanket.
Re:Security through obscurity (Score:2)
Re:Security through obscurity (Score:2)
Don't forget! (Score:2)
And don't forget you should only go 50 MPH on that spare tire, which of course is referring to making sure the security staff is give
In a word... (Score:3, Funny)
CertAlert Software (Score:2, Informative)
I didn't notice that I there... (Score:5, Funny)
other PKI options (Score:5, Informative)
Also, don't hardcode your CRL URL into your certificates. If that web server goes down, your entire PKI could break. It is better to leave revocation out of certificates and get all of your important PKI clients to use OSPF.
For the root node of your PKI:
Take a laptop, scratch off all networking-type thingks (modem jack, ethernet jack), generated your root CA key, use it to sign your intermediate CA certificates, then lock the laptop in a safe.
Re:other PKI options (Score:5, Interesting)
Use the MS PKI software for the clients, but use OpenSSL to generate your certs. If you ever have to integrate with something old or ugly, MS generated certs can be a little weird (read, lots of things that only MS does). Note to bore you with the details, but see this [auckland.ac.nz] document for the gory details of certificate interchange. It's really amazing it works at all.
About MS, the document says:
The document goes on to have an entire section on Microsoft bugs. Although, to be fair, I suspect a good many of them have been fixed and a good many still remain.
So...save yourself the headache...when generating your certs, use OpenSSL with the scripts that come with it. It is quite possibly the least erratic implementation of a CA. Yes, this does make it much more complex to operate. However, so does the following very important recommendation.
Like the parent post says, put it on a machine and lock it in a room (if you do a lot of business, a safe or vault would not be unwarranted). Make sure that any passwords (i.e. for encrypted root private keys) are written down in an envelope and stored in a different, highly secure location. The only thing more frustrating than bad PKI is good PKI when the person who knows the private key password was hit by a bus.
Re:other PKI options (Score:3, Funny)
Is your company currently searching for new talents ? I am quite good at this game. And Quake too. 5 years experience. Have managed team of 3+ player. I deserve this job !
Re:other PKI options (Score:2)
We've been looking at Entrust, and they have some impressive offerings. However, for a full implementation (we're a medium enterprise with a few thousand certificates needed), it's really expensive. Low end of estimates is a fair amount into six digits, and it's several weeks of dedicated work to get all of the policies and procedures in place and accepted by Entrust. But at the end of it, there's rea
Re:other PKI options (Score:5, Informative)
I suspect you mean OCSP here.
OCSP is definitely the way to do revocation. The CRL concept comes from the days before there was a real Internet, Lauren Kohnfelder's Msc thesis in '79. In that context a CRL is the only way to make the scheme work.
The problem with CRLs is that they are a bit like the old credit card blacklists that the cashiers used to have at department store checkouts. First there was a page of stolen card numbers, then a booklet, eventually it was going to be the size of a telephone book. Thats when the VeriPhone card verification machines appeared. An online check for every transaction.
With OCSP there is a realtime certificate status check for each transaction. That means a certain commitment to infrastructure but there are providers who can outsource PKI infrastructure to five nines or better.
Of course once you have a certificate status lookup per transaction you might as well move to a key centric PKI model similar to what Brian LaMachia did with PGP at MIT. Ultimately the PKI world is headed towards the XKMS style interaction which is simply a key centric PKI with a Web Service front end.
There are ways to extend the CRL model, distribution points, delta CRLS, partitioned CRLs, Kocher style revocation trees. I have even suggested similar schemes myself in the past. Ultimately I don't find them very convincing.
Whether you should go the homebrew route, implement an application or get an outsourced service really depends on what your resources are and what your needs are. The thing you have to be careful of is the fact that people cost money too.
For the root node of your PKI: Take a laptop, scratch off all networking-type thingks (modem jack, ethernet jack), generated your root CA key, use it to sign your intermediate CA certificates, then lock the laptop in a safe.
Just go buy a couple of decent FIPS certified hardware tokens from someone like n-cipher.
Re:other PKI options (Score:2)
Re:other PKI options (Score:2)
Nor apparently to spell correctly. I only bother to offer the correction of paid for payed because your misspelling seemed so reasonable and I didn't want it to gain any traction.
Re: (Score:3)
CRL, OCSP and PKIX (Score:3, Informative)
Regarding the use of the CRL distribution point extension, a URI that points to a DNS alias can help alleviate the risk.
"OSPF" was likely a botched reference to OCSP (Online Certificate Status Protocol), defined in RFC 2560 [ietf.org].
Finally, read the PKIX spec on certificate management, RFC 3280 [ietf.org]. It will give you a much more detailed understanding of how PKI should work than any vendor docs. This level of understanding is critical if you start playing the role of CA.
If you do your homework, and understand ho
Re:other PKI options (Score:2)
cheers.
Re:other PKI options (Score:1)
Re:other PKI options (Score:2)
Re:other PKI options (Score:5, Informative)
There is actually a knoppix-based live-cd distro called roCA [intrusion-lab.net] that runs tinyCA that is designed to store the certificates on a USB thumb drive. The idea is that you lock up the CD and thumb drive. A bit easier than an entire laptop..
* I'm not really sure this is an all-out "PKI" system in the "enterprise" sense of the word. As I'm not a security expert -- just an IT guy that needed an easy way to manage certificates -- I don't really understand the buzzword-laden PKI industry, that seems to have lots of companies that sell PKI management software without really explaining what exactly they do.
I am doing a 802.1x authication test lab now (Score:5, Interesting)
Re:I am doing a 802.1x authication test lab now (Score:1)
Re:I am doing a 802.1x authication test lab now (Score:2)
I've found Funk Software's [funk.com] wireless Odyssey client [funk.com] can help smooth out the wrinkles by levelling out some of these steps. You can also choose a pre-configured deployment that will be able to assist you roll out this solution.
Just another option....
/K
Re:I am doing a 802.1x authication test lab now (Score:3, Informative)
This might seem like a small problem, but remember that you will not have a IP-address at the logon and therefore the client computer will not load logonscripts and Group polices. To get around this with a enterprise WPA solution you will have to issue two certificates, one for the user and one for the computer.
Re:I am doing a 802.1x authication test lab now (Score:2)
Is what you're talking about done automatically by Windows XP SP2? That is my only guess, since all of our clients use the Intel Pro Set software to connect through WPA, I'm guessing it would be impossible to have them connect before the user logs in, since the Intel util won't be loaded.
Comment removed (Score:3, Insightful)
Piloted (Score:4, Interesting)
I'm new to this, tell me about it. (Score:2)
What, exactly, were you trying to do? What were you trying to protect, from who and did this really do it? When you saw WLAN, is that wide area network or wireless local area network? If it's wireless, why is it you have to worry about that? How much did all of this cost and how many users did it cover?
I've got big doubts wh
Re:I'm new to this, tell me about it. (Score:2)
WLAN == Wireless Lan. As the primary motivation, we were looking at a migration to one of the EAP authentication schemes (Wikipedia article [wikipedia.org]) for large numbers of WLAN clients. Of specific interest was efficient certificate distribution and management. Additio
Re:I'm new to this, tell me about it. (Score:2)
Easy answer: because it's Slashdot, and anyone who says a *insert any currently out of favour vendor, but usually M$* product actually works will collect a bunch of mostly ACs who spew out zero content posts claiming your a shill for *insert any currently out of favour vendor, but usually M$*.
Real answer: Because from your perspective in your moms basement, having never actually done something (well...anything, ever, nor will you ever) like architecting a large scale PKI rollout
public keys, go figure... (Score:4, Funny)
we now use a terra-cotta sleeping bunny key safe [a-artfurniture.com] and feel much more secure.
In C++ terms (Score:1, Funny)
BTW, the "Images" shown at the bottom of the screen are completely irrelevant to the bunny picture.
Re:public keys, go figure... (Score:1)
You'd better change your company policies before the boss reads this, or you could be out of a job for releasing important trade secrets no matter how cute that bunny is!
Re:public keys, go figure... (Score:2)
1) Did you see the *price* for that bunny? Darn expensive way to try and hide your keys. Why not simply keep the keys in a bag under a rock in the garden?
2) The paranoid side wonders if the website owners would be willing to release the addresses of where something like this was shipped. Talk about easy shopping for crooks, a list of houses that probably leave keys outside!
Still, the bunny is nicer looking then a frog.
Re:public keys, go figure... (Score:2)
Ah, but who can put a price on peace of mind? Think of the children! Are you with us, or with the terrorists? You have to sacrifice some of your liberties for the sake of security.
You bet yer ass we do! (Score:2, Funny)
Does that count?
Entrust (Score:4, Informative)
Re:Entrust (Score:1)
Your research (Score:2, Informative)
"NICI" and "Directory Services" and "NetWare" are the keywords which will be most helpful in your search for additional information on this subject.
Re:Novell PKI (Score:1)
That's exactly what you want.
BlueSocket (Score:1)
Re:BlueSocket (Score:1)
OpenSSL (Score:3, Insightful)
OpenSSL is very powerful and useful. I have used it for many of its encryption routines (such as locking up my pr0n collection while I am in the Middle East!).
strike
No (Score:4, Funny)
Re:No (Score:2)
Be nice to the unfortunate ones even when their efforts are truely pathetic.
Happy Friday the 13th.
Federal Govt. Use (Score:3, Interesting)
We (Navy via NMCI) use multi-factor identification. Most commands have CAC cards (basically just smart cards) that store multiple keys (one for email, one for web pages, one for digital sigs). To access any data on the cards (including certs) you also need a PIN. Furthermore, most systems have an additional (strong) login uname/pass after your cert is accepted. The result is password overload but fairly decent security.
You minimally have dual authentication factors (physical card access and PIN) and is most cases triple authentication.
Re:Federal Govt. Use (Score:2)
CRLs and the future (Score:5, Informative)
For the newbs, CRLs or Certificate Revocation Lists are nothing more than lists of which certs have been revoked. If you're going to deal in non-physical access tokens (as opposed to, say, metal keys and RFID badges) you're eventually going to want to deal with the eventuality that people's lifespans are generally longer than the amount of time that they have access to your stuff. PKI is excellent for mathematically proving that noone that can't factor huge primes can get your secrets just by looking at bits on the wire, but you can't really demand that your recently fired employees surrender their keys since they could very well have made copies in advance. Now that I think about it I suppose the same is true of keys, so consider CRLs the digital equivalent of changing locks.
A CRL is a list of all they key IDs of keys that have been revoked. If you get terminated, you go on the list, and when you subsequently try to use your key, even though mathematically it works great, if you're on the CRL you get a 403 (or big guys with guns or whatever your model for Access Denied happens to be).
CRLs are as dead end as it gets. Especially if you're working with a lot of end-devices or end-users, your CRL situation is going to get fantastically out of control very quickly. Picture, if you will, the DoD. How many people do you think had keys last year who aren't entitled to them now? Sure, the really old keys expire, but the new keys that were revoked all have to be downloaded *every time* a user makes a query, or else you risk race conditions of varying severity. (One could easily imagine the race to get home and log in over the VPN to copy the Secret Plans after being fired; the amount of time a user would need to do this is about the longest you'd want to go between CRL updates. If a CRL was many megabytes large and if the authenticating device got many hundreds of requests per second you might have a problem.
OCSP [techtarget.com] , or Online Certificate Status Protocol, is a huge step in the right direction; instead of downloading the entire CRL to the authenticating device, the device instead makes a quick call to a OCSP responder, querying the status of the cert. The OCSP has a store of CRLs which it obtains from the CA/VA, and can create a signed response containing the status of the certificate: good or revoked (or, I suppose, unrecognized or otherwise munged). Now you only have to distribute CRLs to one/several devices, instead of every one in the infrastructure.
Some groups (Corestreet [corestreet.com], among others) have created distributed versions of OCSP which use precomputed proof lists in order to avoid the problem of distributing private keys to a network of distributed OCSP responders for use in signing OCSP responses. This D-OCSP is vastly more powerful and flexible than CRLs (and proportionally expensive).
PKI is a pretty daunting challenge to implement correctly, and its even harder to make the other links in the chain nearly as strong as the crypto. Best of luck.
vvj
Factor Large Primes?? (Score:2)
I think you'll find that factoring large prime numbers is rather easy.
I think you mean to say, "find the prime factors of large integers."
Re:CRLs and the future (Score:2)
For example, if I took a laptop on a business trip and used it on someone's network then left it there while I was at lunch, I may realize I should revoke my certs on that laptop and request new ones.
However, if I were fired, my certificates do not need to be revoked, the permissions associated with my identity are simply denied.
Red Hat Certificate System (Score:5, Insightful)
Our product is fairly widely deployed. For example, every single one of the 18+ million Certificates issued from the US Dept of Defense CAC (smartcard) deployment use our Certificate Authority. There are many other deployments within the Federal government also.
In addition, someone mentioned Geotrust. Geotrust built their certificate issuance service on top our certificate authority, so of course I think very highly of them.
Our product is an enterprise-class (meaning hugely scalable, and fault tolerant), full featured, mature product, written by engineers with many years experience in the PKI field.
But, I would like to turn the question around - If you haven't deployed a PKI yet, what is stopping you?
As an example, one of the deployment-blockers we found in the past few years was the poor integration PKI management systems (Certificate Authorities) had with Smartcard Management Systems. So, we engineered a smartcard management system, and bundled into the Certificate System at no extra cost.
What applications would people like to see PKI-enabled that aren't already?
And since I'm a Red Hat employee now, I am constantly thinking about integration with Red Hat Enterprise Linux and Fedora - so, what changes would you want to see happen?
Public PKI (Score:3, Insightful)
I honestly think that, after 20 years of PKI "about-to-take-off" that the tipping point isn't going to come from corporations: It's is going to come from customers, most likely of Paypal or Ebay or CitiBank or Bank of America or Walmart or CVS or Postal Service or whomever (RadioShack?).
What will drive this will be developing and promoting a decent public PKI system. "Stop by the Customer Service Counter with enough ID and someone (with a bit of training) w
Re:Public PKI (Score:2)
In this article [gsec.co.uk] I quickly found - tokens are about twice as popular than certificates for securing your bank transactions.
Seeing as this security stuff is suddenly fashiona
Re:Public PKI (Score:2)
What will drive this will be developing and promoting a decent public PKI system. "Stop by the Customer Service Counter with enough ID and someone (with a bit of training) will certify you for a "Trusted Customer Card & Code" today!"
It already exists, well in Canada anyways.
The Government of
Re:Red Hat Certificate System (Score:1)
will there be at least a download for evaluation?
what do you need from the smart card side? I'm one
of the opensc and openct developers, and we support
a lot of commercial available smart cards and national
id cards in our pkcs#11 module. in contrast yous software supports only a single card according to the documentation.
what about any place for discussion? last time I checked
there was no mailing list or anything, and on the directory
server list I was told, re
Re:Red Hat Certificate System (Score:1)
What would I like to see PKI-enabled? If we're talking Web Services then I think we're already there; Apache is well capable of logging me in when I supply a client cert via my browser and USB token. PKI-enabled shell is available as w
Re:Red Hat Certificate System (Score:2)
There are a bunch of reasons. Setting up a PKI is relatively simple once you go through the very difficult part of deciding what you want to accomplish, set up the requisite documents like a certificate management policy.
The biggest challenge is certificate management. Everything from enrollement, updates, revocation, key escrow, and mobility. MS certificate server is very bare bones and good at what it was designed to do--issue certificates to
PKI? What PKI? (Score:4, Interesting)
I do security work for a Fortune 100 company, and while we've got the usual SSL certs on some of our web servers, we haven't yet had a compelling business case that would justify the huge expense to do PKI right. Coupled with the belief that PKI done wrong is worse than not doing PKI at all, we've stuck with point solutions for our encryption needs thus far.
I believe that we're moving forward with certs in the ActiveDirectory to facilitate EAP-TLS on our wireless, and that will probably go farther towards "universal" certificates for our end users, but since rolling out smart card readers to tens of thousands of users will be a significant investment, using certs for regular auth to the AD just isn't cost justified yet.
In the mean time, we've got self-signed certs for signing internal applications, and use some commercial, GPG-like software for desktop/email encryption :-) SSH works quite well for shell access, although the onesie-twosie management of the RSA keys is a major bitch.
In reality, I doubt that we'll ever go for a full-blown PKI done right. Every time we look at it, we figure out that the servers, admins, training, and physical security improvements will cost $6 million, and it won't really buy that much. For important authentication things, especially remote access, using those random-number tokens works really well, and doesn't have nearly the costs associated with them that PKI does.
Re:PKI? What PKI? (Score:1)
I am doing this research for a few reasons, and the only reason I say MS is because:
that's what's on 90 % of corporate desktops(95% of ours, and yes, red hat and mac osX "can" work with MS cert services);
it is integrated with my company's current environment, and while the PKI itself may be complex to configure, plan and install;
it allows me to automate quite a bit and I can just manage certs and CRL's (which 2003 has delta CRL's, significantly reducing network load)
Support Costs (Score:2)
I think the cost for a cert is between $50 and $120 or so. But issuing and managing can be a headache. I'll bet my office of about 3000 people has had *at least* a 50% password failure rate. The smart cards only give you 4 failures then they commit suicide and have to be reacti
Red Hat Certificate System (Score:1)
It is based on the Netscape Certificate Server product (which is in use at the DoD as part of a huge certificate infrastructure) but has numerous additional features including a smartcard/token management system that enables two factor authentication out of the box.
MS is not a PKI standard, but size matters (Score:3, Informative)
Although MS may have a bastardized implementation of PKI, it has some primary flaws. For starters, MS will only allow their domain controller certs to be constructed in some specific fashion. If you are a small firm and it is inexpensive to gut your PKI quickly, then play with MS implementations.
Stick with standards compliance for larger implementations. You never know how someone is going to need to use your infrastructure, and it is a REAL PAIN to adjust (bigger = exponentially harder). For example, one day you might need to do something with hardware cards or trusted peers. If your chosen version doesn't play that way, you could be screwed. Just find another job, fast.
If all you want is single sign on with a piece of plastic, buy a SSO solution and be done with it. But if you want a root CA, subordinate CAs which issue hardware, software, server, and mcs credentials, then that's a real PKI.
If you don't have the facilities to handle physical security needed for a PKI, then find a vendor.
The first part of PKI is Policy (read - legal junk that gives your Base64 blobs some sort of validity). You need a CP and a CPS and that requires a lot of typing. Once you get that down, then you can survey offerings and find what you need. Some hints at decent products are from Novell and a section of RedHat that was formerly known as NSS.
I'm not stricly MS bashing, but some will see 2 linux vendors and say "oh, he just hates Windows". Fact is there are plenty of PKI standards and Microsoft doesn't do it correctly - why should they when everyone uses Windows to sign in.
I sure hope you are not working on HSPD12Re:MS is not a PKI standard, but size matters (Score:1)
Further more, I think all implementations of PKI are "bastardized ones", because the architecture is always slightly different, and X509v3 specification is not really that specific about what you put into the certs and how.
Further more, setting up Certificate
PKI is a stupid name (Score:3, Interesting)
just my 2 cents.
Re:PKI is a stupid name (Score:2)
PKI is not a single entity, and it doesn't need a single icon associated with it. PKI is used for Digital Signatures, SSL, and encryption among many other things- and hence a generic term Public Key Infrastructure to indicate any implementation of Public Key Cryptography.
Does SSH count? (Score:2)
Taint anywhere NEAR that simple... (Score:5, Informative)
If you're looking for port-level authentication on your networks, wired or wireless, then IEEE 802.1X is the answer.
(dot)1X uses EAP (Extensible Authentication Protocol) Methods. MS gives you two big methods out of the box w/ the XP client: PEAP-MS-CHAPv2 (think: login/passwd) and EAP-TLS (think: digital certs), and provides the server level support in the form of certificate services, IAS (internet authentication server) and integration of both into the AD. Other methods are around, typically from other vendors (at additional cost). To impliment one not supported by MS out of the box, you need client-side and server side support.
IF (BIG IF) you have an MS infrastructure, your client machine logins are probably hanging off the domain controller, and use one of the above methods, or, can easily (and transparently to your users) move to one.
NOW, once either one is in place, implimenting port level auth is straightforward.... unless you do not have 100% XP clients. Nobody does in my experience (think: Printservers, other headless network clients). Then you get to get REALLY inventive with firewalls, vlans, switches, etc. and you can "get there". Taint gonna be easy....
There are open solutions on the client side, even in an MS infrastructure. Google for "wpa_supplicant".
NOW, back to your question: The MS PKI will prolly scale as well as AD itself. No better, worse.
This answer is deceptively simple. You have to overlay it on YOUR network, YOUR security policy, YOUR needs, YOUR level of expertise, etc.
MS does eat their own dawgf00d in this area, and I personally know some of the architects and implementors.
I AM NOT A MS FAN. That being said, they have (mostly) gotten this right.
There is a book from MS Press: Deploying Secure 802.11 Wireless Networks with Microsoft® Windows, ISBN: 0-7356-1939-5, which is obviously oriented on wireless nets, but which steps you through setting all of the
Recommended....
I sincerely hope this helps..
-RED
Re:Taint anywhere NEAR that simple... (Score:1)
I like you comment about putting it on my network, my security policy, etc....
I am (un)lucky (whatever) to have consistency in my network (all XP and 2000 clients, and mostly windows servers, not that I'm all for it, but at least I can keep it simple, so I'm looking at the ease of scaling it in my existing AD, and I'm not such a big company that it'll be much of a problem.
But in my research paper, I want to be able to say:
Yes you can implement this in an academic or large corporate environment, and with
Re:Taint anywhere NEAR that simple... (Score:1)
Plastic Keyboard Injury solution? (Score:1)
This was allegedly to prevent people from "borrowing" them, but everyone knows that it was because Dan the sales-guy (moron) tried to smash the keyboard over the monitor because he couldn't figure out that the printer was out of paper.
Dan nearly put out a VP's good eye with his backswing.
yes, yes we do (Score:1, Funny)
Microsoft PKI (Score:5, Informative)
Fashioning it in Windows is quite simple, as Windows domain participants will automatically enroll for the types of certificates that you want, for example, allowing the machines to authenticate into the domain silently. I've written several detailed implementation how-tos on these subjects (kafkaATtelusDOTnet, if you're interested).
As soon as you leave the Windows world, then all these things become a bit trickier. No longer can you simply let the the Windows Certificate Services generate your certificates silently, since you'll need to intercede to generate the type of certificates that want. Controlling how these certificates are constructed becomes somewhat difficult (not impossible, just tricky). How and what you want will totally depend on the applications that you're using. You're probably far better off getting a PKI solution based on OpenSSL in that case, especially if you need to interoperate with non-Windows applications and devices (such as CISCO routers). If you don't have time to write any code, look into RSA Security [rsasecurity.com]. They're wayyyy cheaper than Verisign, and you don't have to deal with the hassle of outsourcing.
Another poster recommended using OCSP - thats fine, but I don't believe there is a native OCSP client built in to Windows. You either have to roll your own, or obtain one (RSA, for example, has one. As well as Computer Associates OCSPro). In fact, there is no reason why you can't implement both redundantly. Use both the CRL distributionpoints (CRLdP) extension *and* the AIA extension to get this done.
Another citation, I believe, referred to Peter Guttmans (very old) document on various PKI implementations, X.509 Style Guide [auckland.ac.nz]. This document is horrendously outdated, as the tools and apps are far more widespread than they were wayyyy back in 2000.
Anyways, for what its worth, if you know what you're doing PKI has distinct advantages to add to your electronic security (although a blind reliance on it won't help you at all).
If you don't know what you're doing, then you'd better go with a vendor that will support you.
Re:Microsoft PKI (Score:2, Interesting)
OpenVPN (Score:2, Informative)
Take a look at OpenCA (Score:1)
Re:Take a look at OpenCA (Score:2)
OpenCA is an OpenSSL based solution with a LDAP backing it all up, mostly written in perl. It might be more difficult to set it up, and hardware support in OpenSSL can be sketchy. But it is pretty active and you might want to take a look. There's also something called EJBCA (Enterprise Java Beans Certificate Authority), it relies on JCA and might be able to handle some hardware as well.
Problem is to ge
PKI is not an end in itself... (Score:3, Informative)
- PKI is not an end in itself, it is just a tool: before designing a PKI solution, you really need to know exactly what end solution you're trying to put in place: Windows Logon? VPN Access? Device authentication in your infrastructure? Email encryption/signature ? Web authentication? Once you know the requirements of your end solution, the choice of a PKI as a security layer for that solution will be far easier.
- The technical solution is the easy part: as can be seen on the other posts, there are plenty of Certificate Authorities around, all with their technical strenghts and weaknesses. What they do not address is the process part around PKI - the CP/CPS and others -, in other words how the PKI shall be used, who is allowed to do what, how the various components shall be protected, procedures defined to address various scenarios (administrator run over by a bus, role separation, administration procedures, key ceremony, key escrow, revocation policy, etc.). This is really the tricky part because it is what will make your PKI a really strong solution or just a gimmick...
As a conclusion, in some cases the Microsoft CA will be fine (say you mainly want to do smart card logon on a 'standard' Windows network), in other cases other solutions will be more suitable, but in every case, the hardest part (as in 'the most expensive part') will be the creation of the policies revolving around your PKI. If after analysis you find out a strong PKI policy does not seem that important in your particular case, chances are you don't really need a PKI but another form of strong authentication. For instance, 2 factor Auth based on one time password tokens or similar, which are much lighter to put in place from an admin point of view, though not quite as strong as PKI, of course...
Just my 2 cents,
Edouard
Government (Score:2)
Huh? (Score:3, Funny)
Switch port authentication? You don't need a certificate to authenticate someone plugging into your switch port. Just look at the dude and see you recognize him.
Although I guess we could pin our public keys on our shirts like nametags and walk around that way.
Re:Huh? (Score:2)
You mean, you don't? How would you know who's who without a DH key negotiation on your calculators before speaking to each other?
Alternative (Score:2, Interesting)
Because they have passed their webtrust compativle security audit, they will soon have major browser inclusion. Thus we will soon have a single cert that can be used for email encryption, IM encryption using certs using Simp ( http://www.secway.com/ [secway.com] ), and SmartCard logon to th
Try PHPki (Score:4, Interesting)
2. Generated oodles of certificates for our entire staff (SMIME certs, so they work with Outlook 2K and 2K3)
3. Published each of their certificates to the Global Address List
4. Had everyone set the option in Outlook to include their public cert as an attachment to signed/encrypted emails
5. Had everyone install the CA's root cert on their machine
Now they can send eachother signed and encrypted emails, all WITHOUT any kind of Microsoft CA or server. It's important in our environment that the private certs NOT be stored where the email/Exchange admins have access to them, so while it takes a little manual labor, it's FREE and works very very well.
PKI (Score:1)
well where i'm from (Score:1)
Need vs Practicality (Score:3, Insightful)
The people who would be responsible for keys, can just barely handle email.
I know I'm not alone, and I know I'm not the only lone admin who would have to be responsible for put such a system in place, and have to hold hands & train users.
I have researched my eyes out.
openCA anyone? (Score:2)
How does it compare to other solutions metioned here?
- Microsoft PKI
- RH Certification System
- tyneCA
- phpCA
End of public-key crypto (Score:2)