...
Steve Crocker trained you well in constantly saying (so that people might eventually believe you) X.509 cannot occur as there is no infrastructure.
Steve Crocker aside, I believe that X.509 can occur and hope that it does.
Turns out (now there is money flowing the certs business) the infrastructure was there all along.
I'll grant you that there are communities using certificates and some of those communities are large, but that's not the same as an infrastructure. The communities using certificates are doing so for their own purposes and their certificates are not necessarily used or accepted by others. It's a start. It's better than what we had before (nothing), but still has a way to go before it reaches infrasturture status.
D&B have huge organizational dbs, suitable for auth managament, and Equifax have huge residential dbs suitable for...
Yes, D&B, Equifax, TRW and the like *could* cache such information and make it available, which is pretty much what they do now with credit information. They may be part of the solution in the future, but they're not right now.
The directory problem has been solved by the Web; see several directory services now available at URLs, and cert distribution within those only required a mime-type...
Solved? No, Making progress? Yes.
With refienement, LDAP may well be integrated into the Web as a locator protocol for more refined service access, but its immaterial functionally.In the end, isn't the application granting a privilege the sole arbiter of the validity of a certificate? Maybe, as I said previously, "validity" is the wrong word. A certificate may be perfectly valid in the X.509 sense, but it may not be "valid for a particular purpose."Of course. certs only perform key distirbution. That key may be obtained over such a channel which allows the applciation to assume the properties are suitable for a given use. In practice such properties come down to a policy oid, which the app can select on, and know represent an authenicated channel of authoitative keying. Subscriber agreement during certiifcate management then allows consumers to decide whether the policies are suitable for use in support of purpose A or B, or none. The cert is itself immaterial; what matters is its background management procedures embodied in the policy id.
I would argue that some (many?) decisions are going to be made out-of-band, without the aid of policy ids. If you want to put more information in a certificate so that an application has more information on which to base a decision, great, but applications need not act on any particular information in that certificate.
A specific extensions can easily be critical or non-critical in all cases. Being able to say otherwise in the certificate with the criticality flag creates confusion (I think this is similar to your original question). It is a shame that the OID space for extensions can't be divided into critical and non-critical (say, even and odd), creating an atomic bond between the extension and its criticality -- no need for external, possibly ambiguous, rules identifying extensions as critical or not.We can do this. IETF PKIX creates a pkix oid in the internet space, and has two subtrees. Into one or the other it reassigns the numbers of the ISO oids, and all IETF people use the IANA versions. Its only a number, but with pkix-profiled criticality specialization suggested by TIS. This is exactly how IETF needs to add value to the raw ISO work, to make it practicable.
Sounds good to me. Would be nice if such basic changes could be folded back into the ISO standard so that there would be fewer differences between pure ISO and the IETF defined use. Mark
binUpq1y19dnQ.bin
Description: application/moss-signature