Understand. I too do not see root CAs like Verisign being much involved; rather, a large enterprise will have its own CA, which makes it easier to use things other than names. But I still see them checking that the identity in the certificate is as expected, rather than just checking that certificate is technically valid.
I recall the issue of 'private' PKI(!) coming up before on this list, and I recall one use case, raised by Anton, where the box serial number as inserted by the manufacturer was also inserted into the certificate installed on the box. (Anton was also a driver for generic certificates). So I see a use case for checking the identity, as well as circumstances, such as yours, where it will not be performed. Tom Petch ----- Original Message ----- From: <[EMAIL PROTECTED]> To: "tom.petch" <[EMAIL PROTECTED]> Cc: "Moehrke, John (GE Healthcare)" <[EMAIL PROTECTED]>; "Joseph Salowey (jsalowey)" <[EMAIL PROTECTED]>; "Rainer Gerhards" <[EMAIL PROTECTED]>; "syslog" <[email protected]>; <[EMAIL PROTECTED]> Sent: Thursday, May 29, 2008 3:41 PM Subject: Re: [Syslog] Some revised text for syslog TLS > [tom-petch]> > > True, but authentication of what? This logic says you might as well use > naked > > public/private keys, as SSH does. For me, the point of all the > > extra hassle of > > certificates is that the keys are bound to an identity/identifier so you > can > > tell, to some degree (depending on what checks the CA has performed) > > to whom you > > are talking. Then it becomes a question of what identifier to use, CN, > MAC, > > etc. > > You live in a radically different threat-asset environment than healthcare > I can tell. In our environment the SSH process would do fine for about > half the users, and the official root CA approach is appropriate to about > 0% of the users. The value of using the certificates for all of them is > software development. Certificates are a widely supported mechanism in > most security libraries. There is no comparable alternative for a > standard format. The half of our world that deals with authentication out > of band can use certificates and ignore all the extraneous infrastructure. > Out of band mechanisms are very significant in healthcare. We have all > sorts of patient safety issues that must be managed. For example, any > hardware change (even just a board swap) can require safety retesting for > patient contact devices. Adding machine identification and authentication > to that process is a low cost addition. It's much cheaper than building > up a suitable PKI infrastructure for the smaller sites. > > The official root CA approach is a non-starter because in the other half > of our world where chain of trust does make sense, the usual root CAs > haven't a clue. Do you really think that Verisign knows whether that PC > in my local hospital has been configured for the admitting clerk's desk or > for the surgical suite? They do not and they do not want to keep track of > that information. There is a completely different chain of trust used in > hospitals and clinics. The trusted anchor is part of the hospital and > clinic organization. It coordinates with the Bio-med department regarding > device allocation. It does know what machines are assigned where and for > what purposes. > > In healthcare you pick a trusted anchor that knows these things. It will > not chain outside the healthcare organization. This organization might be > rather large when you get into various national health systems, but the > anchor is within the healthcare system. > > R Horn > _______________________________________________ Syslog mailing list [email protected] https://www.ietf.org/mailman/listinfo/syslog
