Re: Time to dump X.400 support?
On Tue, Sep 24, 2013 at 5:25 PM, Phillip Hallam-Baker hal...@gmail.comwrote: Looking at the extreme breach of trust by US govt re PRISM, I think it is time to do something we should have done decades ago but were stopped at US Govt request. Lets kill all support for X.400 mail. Actually, as far as I'm aware, the US and UK government uses of X.400 are being phased out fairly rapidly, so they'd probably support trimming out most of the support from PKIX too. This is still in use, I know. But looking through the PKIX spec the schema is ten pages long. I count seven pages of garbage that we could kill if we abandoned support for X.400, garbage character sets no longer needed, bogus time formats, etc. etc. Certificates do not need to be as complicated as X.509v3 made them. To work with certificates issued for the Internet, an application needs to support only 20% of the PKIX schema at most. I'd be interested to see a more concrete proposal. I would offer my apps-oriented viewpoint in the work, too. Dave.
Time to dump X.400 support?
Looking at the extreme breach of trust by US govt re PRISM, I think it is time to do something we should have done decades ago but were stopped at US Govt request. Lets kill all support for X.400 mail. This is still in use, I know. But looking through the PKIX spec the schema is ten pages long. I count seven pages of garbage that we could kill if we abandoned support for X.400, garbage character sets no longer needed, bogus time formats, etc. etc. Certificates do not need to be as complicated as X.509v3 made them. To work with certificates issued for the Internet, an application needs to support only 20% of the PKIX schema at most. -- Website: http://hallambaker.com/
Re: Time to dump X.400 support?
Phillip Hallam-Baker hal...@gmail.com wrote: Lets kill all support for X.400 mail. +1000. We should do this because nobody new is going to use it. The other reasons you mentioned are just icing. -- Michael Richardson mcr+i...@sandelman.ca, Sandelman Software Works pgpYSfDNjZbDG.pgp Description: PGP signature
Re: Time to dump X.400 support?
Phill, On 09/24/2013 05:25 PM, Phillip Hallam-Baker wrote: Looking at the extreme breach of trust by US govt re PRISM, I think it is time to do something we should have done decades ago but were stopped at US Govt request. Lets kill all support for X.400 mail. This is still in use, I know. But looking through the PKIX spec the schema is ten pages long. I count seven pages of garbage that we could kill if we abandoned support for X.400, garbage character sets no longer needed, bogus time formats, etc. etc. Certificates do not need to be as complicated as X.509v3 made them. To work with certificates issued for the Internet, an application needs to support only 20% of the PKIX schema at most. Sure, if we went back to the late 1990's that'd have been worth doing. And sure, if we re-invent rfc 5280 public key certs we can not include some stuff. Not that I see much benefit in re-inventing 5280 PKCs as a thing to do in and of itself. (And of course DANE includes hardly any ASN.1 nonsense if you pick the right options so we already have an option without that baggage.) But I see no benefit in messing around with rfc 5280 at this stage for fun. (I said the same to the ITU-T person who seems to want to do that with their x.509 spec the other day when the topic came up on wpkops.) So -1 to that kind of change unless there's a much better reason. S.
Re: Time to dump X.400 support?
On Tue, Sep 24, 2013 at 3:19 PM, Stephen Farrell stephen.farr...@cs.tcd.iewrote: Phill, On 09/24/2013 05:25 PM, Phillip Hallam-Baker wrote: Looking at the extreme breach of trust by US govt re PRISM, I think it is time to do something we should have done decades ago but were stopped at US Govt request. Lets kill all support for X.400 mail. This is still in use, I know. But looking through the PKIX spec the schema is ten pages long. I count seven pages of garbage that we could kill if we abandoned support for X.400, garbage character sets no longer needed, bogus time formats, etc. etc. Certificates do not need to be as complicated as X.509v3 made them. To work with certificates issued for the Internet, an application needs to support only 20% of the PKIX schema at most. Sure, if we went back to the late 1990's that'd have been worth doing. And sure, if we re-invent rfc 5280 public key certs we can not include some stuff. Not that I see much benefit in re-inventing 5280 PKCs as a thing to do in and of itself. (And of course DANE includes hardly any ASN.1 nonsense if you pick the right options so we already have an option without that baggage.) But I see no benefit in messing around with rfc 5280 at this stage for fun. (I said the same to the ITU-T person who seems to want to do that with their x.509 spec the other day when the topic came up on wpkops.) So -1 to that kind of change unless there's a much better reason. I wasn't thinking so much of re-opening RFC5280 as declaring them obsolete with the intention to remove them in future editions should those ever occur. Perhaps of more immediate effect, can we revisit the issue of OCSP responders having to report 'VALID' for a non existent certificate? Every one of the people who objected is a US government contractor and the only party that purportedly has a difficulty with the idea that an OCSP responder should be able to provide a definitive statement is the US DoD. As I pointed out in the wake of FLAME, this particular change would have made it easier to detect the type of attack performed on Microsoft in the FLAME malware. -- Website: http://hallambaker.com/
