I spent a significant time with the Dartmouth PKI project. The goals were to stand up a PKI for Dartmouth and then produce a PKI that could be distributed to Universities as open source with simple startup solutions. Dartmouth initially used the Sun Directory and Identity Manager Software, but changed course when Sun discontinued the Identity Manager. Initially we wanted to provide each student with a PKI public key that could be used to authenticate the user on public and private terminals to applications that had been modified to permit access only to those whose private keys matched the public keys stored in the Dartmouth LDAP directory. Later private keys were used to "authorize VPNs" and to authorize laptop's access to the wireless network. Further work that is ongoing developed a method by which guests could obtain a temporary private key so that their laptop could use the network on a temporary basis.
In order to use public terminals with the modified applications, students were required to have a PKI token that maintained their private key and did all signing, etc. with the private key without releasing it to Microsoft's browser.
(We noted in our work with the Educause PKI effort that Verisign would not sign a University's generating key. They would however sell key pairs to University users, e.g., University of Texas and University of California.)
The initial Dartmouth work is complete. You can learn more about it at:
Note: the Sun Identity Manager is now an Open Source Project at Red Hat and could be used with the material developed at Dartmouth.
Dartmouth now has a development project to bridge the use of certificates generated by different CA's. It is called the Higher Education Bridge Certificate Authority. It would be desirable for University generated certificates to be recognized by Federal Entities, DoD, NIH, NSF. We worked hard with Peter Alterman at NIH to test out these concepts.
I took a different course, obtaining the Microsoft Windows Server 2003 (SP1) which has a better version of PKI than Windows Server 2000.
For academic use, this server is very inexpensive. It provides much of the support that is desired with the use of the Active Directory. As has been pointed out in other posts, one of the major costs for an organization is key management: generation and maintenance. Entrust does a super, automatic job of this. Microsoft offers the possibility of authorizing certied users of the active directory to cause keys to be generated and then stored in their entry in the AD. Further the administrator can specify that the keys be renewed automatically -- that is that a new public key certificate is generated within the active directory context automatically. It also permits subsidiary key/certificate generation CAs on machines of domains related to the CA. Within the AD, it is possible to generate keys for computers that are part of the domain as well as for users within the domain. These keys can be used to provide encrypted communication between the machines in a IP4 or IP6 VPN. In this way laptop to server communication can be secured.
Unfortunately, the templates provided for the generation of certificates may not be augmented! (at least as far as SP1). Nor may one add to the collection of certificate types; in particular, no attribute certificates are permitted. Entrust does permit the manufacture of attribute certificates (at least as of 2002). These certificates are desirable to provide additional information that might change during the life of an ident
Slashdot Mirror
I spent a significant time with the Dartmouth PKI project. The goals were to stand up a PKI for Dartmouth and then produce a PKI that could be distributed to Universities as open source with simple startup solutions. Dartmouth initially used the Sun Directory and Identity Manager Software, but changed course when Sun discontinued the Identity Manager. Initially we wanted to provide each student with a PKI public key that could be used to authenticate the user on public and private terminals to applications that had
been modified to permit access only to those whose private keys matched the public keys stored in the Dartmouth LDAP directory. Later private keys were used to "authorize VPNs" and to authorize laptop's access to the wireless network. Further work that is ongoing developed a method by which guests could obtain a temporary private key so that their laptop could use the network on a temporary basis.
In order to use public terminals with the modified applications, students were required to have a PKI token that maintained their private key and did all signing, etc. with the private key without releasing it to Microsoft's browser.
(We noted in our work with the Educause PKI effort that Verisign would not sign a University's generating key. They would however sell key pairs to University users, e.g., University of Texas and University of
California.)
The initial Dartmouth work is complete. You can learn more about it at:
http://www.dartmouth.edu/comp/about/projects/pki/
http://www.dartmouth.edu/~deploypki/
http://www.dartmouth.edu/~pkilab/
Note: the Sun Identity Manager is now an Open Source Project at Red Hat and could be used
with the material developed at Dartmouth.
Dartmouth now has a development project to bridge the use of certificates generated by different
CA's. It is called the Higher Education Bridge Certificate Authority. It would be desirable for University generated certificates to be recognized by Federal Entities, DoD, NIH, NSF. We worked
hard with Peter Alterman at NIH to test out these concepts.
http://www.dartmouth.edu/comp/about/projects/pki/l earn/related.html
I took a different course, obtaining the Microsoft Windows Server 2003 (SP1) which has a better version of PKI than Windows Server 2000.
For academic use, this server is very inexpensive. It provides much of the support that is desired with the use of the Active Directory. As has been pointed out in other posts, one of the major costs for an organization is key management: generation and maintenance. Entrust does a super, automatic job of this. Microsoft offers the possibility of authorizing certied users of the active directory to cause keys to be generated and then stored in their entry in the AD. Further the administrator can specify that the keys be renewed automatically -- that is that a new public key certificate is generated within the active directory context automatically. It also permits subsidiary key/certificate generation CAs on machines
of domains related to the CA. Within the AD, it is possible to generate keys for computers that are part of the domain as well as for users within the domain. These keys can be used to provide encrypted communication between the machines in a IP4 or IP6 VPN. In this way laptop to server communication can be secured.
Unfortunately, the templates provided for the generation of certificates may not be augmented! (at least as far as SP1). Nor may one add to the collection of certificate types; in particular, no attribute certificates are permitted. Entrust does permit the manufacture of attribute certificates (at least as of 2002). These certificates are desirable to provide additional information that might change during the life of an ident