So I wanted to look at the certificate in question...
I fired up my MS Internet Explorer 5.50.4522.1800 with all the latest patches from Microsoft and went to the site. The little lock at the bottom of my IE window was happy. I opened up the certificate and there was a warning certificate icon and a message: "This certificate has failed to verify for all of its intended purposes."
First of all, this has got to be a bug in IE 5.5 one way or the other: it shouldn't have a "good lock" if it doesn't think that it is good!
If this is the problem (rather than just the dialog being busted), the certificate should be broken everywhere and it just slipped through testing because they thought that if it worked for MSIE, it must be OK.
Let's wip out the latest version of openssl and see what it tells me...
The certificate they are using has a chained CA. Here's the details from (bottom to base CA):
subject=/C=GB/ST=London/L=Westminster/O=The Cabinet Office/OU=Government Gateway/OU=Terms of use at www.trustwise.com/rpa (c) 00/OU=Authenticated by British Telecommunications plc/OU=Member, VeriSign Trust Network/CN=secure.gateway.gov.uk
issuer=/O=VeriSign Trust Network/OU=VeriSign, Inc./OU=VeriSign International Server CA - Class 3/OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign
subject=/O=VeriSign Trust Network/OU=VeriSign, Inc./OU=VeriSign International Server CA - Class 3/OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign
issuer=/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
subject=/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
issuer=/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
The middle certificate also has the same error according to IE 5.5 -- the base certificate is valid.
Looking at the values inside of it (actually with MSIE), I see these unknown Enhanced Key Usage:
Unknown Key Usage(2.16.840.1.113730.4.1)
Unknown Key Usage(1.3.6.1.4.1.311.10.3.3)
And there weren't any other known values mentioned. Since I don't have a MIB that decodes these ASN1 values, I have no idea if they are correct or not. (If you can decode these values, please post them -- I'd love to know what new values have been created. Thanks.)
I wonder if the pre-release beta of MSIE 6.0 also has a "gook lock" and fails to verify when you bring up the dialog as well... (Post a response if you know.)
BTW, the base certificate (which must have been installed with MSIE) is valid for 4 "Enhanced Key Usage (Property)" values that IE 5.5 was able to decode without any problem.
BTW, when the XCF was in 199B Cory, we taught the UNIX Help Sessions (i.e. basic UNIX commands) at the beginning of each semester, consulted on UNIX and C programming issues for the adjacent terminal rooms (and anyone else who walked in) and taught the "C in the UNIX Environment" informal class in addition to peer consulting within the membership. This seemed to give a nice hierarchy of learning levels. I don't remember feeling burdened answering people's questions.
Universities were created so that people could get together and have synergistic learning: people could learn from each other much faster than in isolation. In the XCF, there were always people around who had expertise in one aspect of UNIX programming or another: you could always ask one of the people sitting next to you how to set up a pipe/fork/dup2/exec sequence and typically someone would know.
When computing power was scarce, we worked together for the computing power, but we found that by working together (in the same room) we found that we learned much more and faster. When computing power became more prevalent, people stopped needed to work together for the scarce resource; unfortunately, they didn't seem to have as much learning fallout from their peers when they worked in isolation.
People have said that the Web can take the role of peer interaction, but from my experiences in the workplace, I don't think it can do it as well (or as fast). The difference becomes evident when someone can just look over your shoulder at your code and offer you suggestions as to a simple typo, an algorythimic problem or even style suggestions which would make your code better. Combing through documentation and code over the Internet or even sending your code to some friends for comment, doesn't seem to have the same gain.
In any case, the XCF has dropped down to a single member before and grown again -- typically creating a new major project at the same time. We'll see if it survives again and if it does, what it produces.
"devoted to whupping MIT's butt at xtrek..."
More time was devoted to whupping PinkPuppy and the rest of the CAD Group grad students!
The administrator mention above was Vice-Chancellor Ray Neff. They canned him. In retrospect, I think they hired him to over-spend his budget on purpose!
As for the "hot air grant proposal", it was less "hot air" than most business plans. We were chartered to provide UNIX consulting to students, UNIX programming projects and a learning-bed for UNIX system administrators. The hard part wasn't the computers; it was the space. Luckily, many of the founders were undergraduate staff (sysadmins and programmers) and so the facility seemed to understand that we could put the space to good use for undergrads learning UNIX.
At one point Mr. Terrel writes: "the number of available IP Addresses as being approximately 5.46 * 10^9."
Let's do the math here. How many numbers can be stuffed into 32 bits: 2^32 or 4,294,967,296. (Isn't there more people on the planet than this?)
Wow, that's pretty good: 27% more unique addresses than the pigion-hole principle will allow!
"Put the calculator down." "Step away from the calculator."
This is where I should have stopped reading, but I continued to see what he was really advocating...
Here's were he finally gets to his point: "a 64 or more Bit Expansion of the current IPv4 Addressing Scheme would more closely approach, and possibly exceed, not only the Number of Hosts, as is the promise of IPv6. But, would retain its overall simplicity, in its implementation and ease of use."
OK, 64-bits is smaller than 128-bits and thus simpler for humans, but he clearly doesn't understand the routing problem that exists in the current network. His scheme (which seems to be to go back to Class-based routing but using 64 bits instead of 32 bits) won't reduce the number of routes being proprogated around: think about the number of Class C, D and E's that he's suggesting and you'll find it makes it worse.
Heirarchical routing will reduce the number of routes being proprogated, but to do heirarchical routing you need to waste space and that's where IPv6's biggest win is: the ability to reduce the number of routes being reported across gateways through truely heirarchical routing.
Could we do heirarchical routing in 64 bits? For the kinds of devices that we have now, we might be able to do so, but what happens if more devices get addresses (like your toaster, TV, phone & lights), then it becomes much harder and we'd have to start allocating things strictly again.
The hard part about IPv6 is the transition, not the number of bits being used. If we need more than 32 and the choice is between 64 or 128, choose 128 so we don't have to do it again in another decade.
Slashdot Mirror
So I wanted to look at the certificate in question...
/O=VeriSign Trust Network/OU=VeriSign, Inc./OU=VeriSign International Server CA - Class 3/OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign
/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
I fired up my MS Internet Explorer 5.50.4522.1800 with all the latest patches from Microsoft and went to the site. The little lock at the bottom of my IE window was happy. I opened up the certificate and there was a warning certificate icon and a message: "This certificate has failed to verify for all of its intended purposes."
First of all, this has got to be a bug in IE 5.5 one way or the other: it shouldn't have a "good lock" if it doesn't think that it is good!
If this is the problem (rather than just the dialog being busted), the certificate should be broken everywhere and it just slipped through testing because they thought that if it worked for MSIE, it must be OK.
Let's wip out the latest version of openssl and see what it tells me...
The certificate they are using has a chained CA. Here's the details from (bottom to base CA):
subject=/C=GB/ST=London/L=Westminster/O=The Cabinet Office/OU=Government Gateway/OU=Terms of use at www.trustwise.com/rpa (c) 00/OU=Authenticated by British Telecommunications plc/OU=Member, VeriSign Trust Network/CN=secure.gateway.gov.uk
issuer=
subject=/O=VeriSign Trust Network/OU=VeriSign, Inc./OU=VeriSign International Server CA - Class 3/OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign
issuer=
subject=/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
issuer=
The middle certificate also has the same error according to IE 5.5 -- the base certificate is valid.
And now to verify it with openssl:
secure.gateway.gov.uk.p7b.b64: unable to load certificate file
9917:error:0D0A2007:asn1 encoding routines:d2i_X509_CINF:expecting an asn1 sequence:x_cinf.c:106:address=135048348 offset=0
9917:error:0D09F004:asn1 encoding routines:d2i_X509:nested asn1 error:x_x509.c:103:address=135048344 offset=4
9917:error:0906700D:PEM routines:PEM_ASN1_read_bio:ASN1 lib:pem_lib.c:290:
OK, it failed. Let's see why...
Looking at the values inside of it (actually with MSIE), I see these unknown Enhanced Key Usage:
Unknown Key Usage(2.16.840.1.113730.4.1)
Unknown Key Usage(1.3.6.1.4.1.311.10.3.3)
And there weren't any other known values mentioned. Since I don't have a MIB that decodes these ASN1 values, I have no idea if they are correct or not. (If you can decode these values, please post them -- I'd love to know what new values have been created. Thanks.)
I wonder if the pre-release beta of MSIE 6.0 also has a "gook lock" and fails to verify when you bring up the dialog as well... (Post a response if you know.)
BTW, the base certificate (which must have been installed with MSIE) is valid for 4 "Enhanced Key Usage (Property)" values that IE 5.5 was able to decode without any problem.
Kurt
BTW, when the XCF was in 199B Cory, we taught the UNIX Help Sessions (i.e. basic UNIX commands) at the beginning of each semester, consulted on UNIX and C programming issues for the adjacent terminal rooms (and anyone else who walked in) and taught the "C in the UNIX Environment" informal class in addition to peer consulting within the membership. This seemed to give a nice hierarchy of learning levels. I don't remember feeling burdened answering people's questions.
When computing power was scarce, we worked together for the computing power, but we found that by working together (in the same room) we found that we learned much more and faster. When computing power became more prevalent, people stopped needed to work together for the scarce resource; unfortunately, they didn't seem to have as much learning fallout from their peers when they worked in isolation.
People have said that the Web can take the role of peer interaction, but from my experiences in the workplace, I don't think it can do it as well (or as fast). The difference becomes evident when someone can just look over your shoulder at your code and offer you suggestions as to a simple typo, an algorythimic problem or even style suggestions which would make your code better. Combing through documentation and code over the Internet or even sending your code to some friends for comment, doesn't seem to have the same gain.
In any case, the XCF has dropped down to a single member before and grown again -- typically creating a new major project at the same time. We'll see if it survives again and if it does, what it produces.
More time was devoted to whupping PinkPuppy and the rest of the CAD Group grad students!
The administrator mention above was Vice-Chancellor Ray Neff. They canned him. In retrospect, I think they hired him to over-spend his budget on purpose!
As for the "hot air grant proposal", it was less "hot air" than most business plans. We were chartered to provide UNIX consulting to students, UNIX programming projects and a learning-bed for UNIX system administrators. The hard part wasn't the computers; it was the space. Luckily, many of the founders were undergraduate staff (sysadmins and programmers) and so the facility seemed to understand that we could put the space to good use for undergrads learning UNIX.
At one point Mr. Terrel writes: "the number of available IP Addresses as being approximately 5.46 * 10^9."
Let's do the math here. How many numbers can be stuffed into 32 bits: 2^32 or 4,294,967,296. (Isn't there more people on the planet than this?)
Wow, that's pretty good: 27% more unique addresses than the pigion-hole principle will allow!
"Put the calculator down."
"Step away from the calculator."
This is where I should have stopped reading, but I continued to see what he was really advocating...
Here's were he finally gets to his point: "a 64 or more Bit Expansion of the current IPv4 Addressing Scheme would more closely approach, and possibly exceed, not only the Number of Hosts, as is the promise of IPv6. But, would retain its overall simplicity, in its implementation and ease of use."
OK, 64-bits is smaller than 128-bits and thus simpler for humans, but he clearly doesn't understand the routing problem that exists in the current network. His scheme (which seems to be to go back to Class-based routing but using 64 bits instead of 32 bits) won't reduce the number of routes being proprogated around: think about the number of Class C, D and E's that he's suggesting and you'll find it makes it worse.
Heirarchical routing will reduce the number of routes being proprogated, but to do heirarchical routing you need to waste space and that's where IPv6's biggest win is: the ability to reduce the number of routes being reported across gateways through truely heirarchical routing.
Could we do heirarchical routing in 64 bits? For the kinds of devices that we have now, we might be able to do so, but what happens if more devices get addresses (like your toaster, TV, phone & lights), then it becomes much harder and we'd have to start allocating things strictly again.
The hard part about IPv6 is the transition, not the number of bits being used. If we need more than 32 and the choice is between 64 or 128, choose 128 so we don't have to do it again in another decade.
Kurt