On Tue, Feb 24, 2004 at 01:39:26AM +0100, Dr. Stephen Henson wrote: > On Mon, Feb 23, 2004, Lev Walkin wrote: > > > Dr. Stephen Henson wrote: > > >On Mon, Feb 23, 2004, Chris Brook wrote: > > > > > > > > >>Is there any support in crypto->x509(v3) for certificate policy > > >>processing/checking as described in X.509 or PKIX? I had a quick look > > >>through the code but did not see anything? Or is it planned since it is > > >>required for some of the PKI compliance tests? > > >>This gets pretty complex with pathLengthConstraints, Name Constraints, > > >>User > > >>and Authority Constrained policies. Perhaps someone is planning a > > >>contribution. > > > > > > > > >Not that I know of. I was asked about the possibility of adding support by > > >someone last year. After lots of discussions nothing happened. I haven't > > >heard anything more for a couple of months. > > > > > >I could resurrect it if there was sufficient interest. > > > > Are we talking about proper checking of ASN.1 subtype constraints, or of > > something more higher level? > > > > No its a different thing entirely. The ASN1 subtype constraints aren't that > essential for this and in some cases strict enforcement is a bad idea. > > In fact the ASN1 code for encoding and decoding almost all the relevant > extensions has been in OpenSSL for some time. CertificatePolicies has been > there for some years, I know because I wrote it and still have nightmares. > > A few very complex things like ORAddress aren't in there but I've never seen > any examples of its use.
exactly. Manipulating names, attributes and other stuff to hash-it-all-together and apply private key then might be not always the best way to go. Lots of research was done since this scheme was introduced and some practical results could be achieved implementing math instead of ASN.1 Please dont get me wrong here: good ASN.1/DER code is a value to handle something specified this way already > However I digress. What we are talking about here is processing things like > CertificatePolicies in the OpenSSL certificate chain verify code something > which it doesn't currently do. Quick example might be constraints introduced to make verification fail in case of something doesnt match (that is, strncmp() != 0). Designated-verifier signatures might also fit this scenario with additional benefit of better privacy and strong crypto background. Attributes encoded as part of private key (introduced by Brands), might be another solution to consider. Yes both are quite different from X.509 still might serve the same purposes namely to derive keys for SSL/TLS and commit to a document regards, Vadim ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
