[xmlsec] Key management / certificate management

Moultrie, Ferrell (ISSAtlanta) FMoultrie at iss.net
Wed Sep 25 20:59:41 PDT 2002

I believe there are other factors to consider that make this more
reasonable than you suggested -- possibly because I'm not sure I
communicated well what the issues and requirements are in my previous
First, my xmlsec setup already assures that the data is verified by a
cert that was issued by one of my trusted roots -- this rules out certs
from untrusted sources up front. I'm also not trying to filter out bad
certs -- I'm quite willing to let them fail and have xmlsec move on to
the next cert.
I'm also interested in looking just at success cases because I only need
to ensure that someone hasn't used a cert, signed by a trusted root,
that wasn't issue to us. In other words, I want to prevent someone from
spoofing valid data with a valid cert from a trusted CA but that cert
wasn't issued to us. For that purpose, I'm interested in validating the
/O= and /OU= attributes. I'm presuming here that my trusted commercial
CA won't issue a cert with our /O= and /OU= information to anyone else
since they'd hopefully not be able to impersonate us in the cert
verification process.
Finally, we're using this process to ensure that static meta-data for
the application hasn't changed since we prepared it before shipment to
the customer. If the customer wants to try to forge the data and attack
himself with a denial-of-service attack by inserting a bunch of 4096-bit
certs, each of which will take time to verify before failing, he's
welcome to do so. There's no profit in it for him -- the only incentive
for anyone to attack the system is to try and get spoofed data to
validate. DoS isn't a significant concern since the customer can only
DoS himself voluntarily!
So, given all that, my only need is to validate when any cert succeeds
that the /O= and /OU= are proper for this application. That's why I
believe that it's quite simple/reliable in this case (but obviously not
in the general case) to merely inspect the certificate that validated
the data and make a go/no-go decision based on that cert and possibly
it's trust chain. 
To do that, I'd like to have a way to access the cert used to verify the
data, and potentially (but not now, and not soon) the cert chain and/or
crl info. For now and even the forseeable future, simply having access
to the X509 structure for the cert validating the key used to validate
the signature would be quite adequate. I can obviously do that by
leaking the defininition of this structure outside of x509.c -- but
that's a hack that is going to cause me pain in the long term I'm sure.
I'd appreciate any suggestions on the reasonableness of this scheme and
what you might consider as a reasonable way to implement it without
violating your designed interfaces.

	-----Original Message-----
	From: Aleksey Sanin [mailto:aleksey at aleksey.com] 
	Sent: Wednesday, September 25, 2002 8:17 PM
	To: Moultrie, Ferrell (ISSAtlanta)
	Cc: xmlsec at aleksey.com
	Subject: Re: [xmlsec] Key management / certificate management
	I believe that there are 2 separate question:
	1) Is it possible to validate cert *after* signature
	The answer is "NO" because the XML DSig standard allows to
specify multiple
	certs for each key. And application MUST check all the certs in
order to find 
	one it accepts. Suppose you have 2 different certs in the signed
message and 
	the first one is "bad" from your point of view and the second
one is "good".
	In the case when cert validation is done *after* signature
verification, (as you suggest),
	the application will pick up the first cert and you cert
validation fails. 
	Of course, you application may return list of the certs, etc.
but this really complicates
	the logic and I am not sure that there no other logic holes. Not
mention that 
	this is bad from performance/ Denial Of Service attack point of
view (I can send you
	a message signed with very big 4096 RSA key in my cert and you
	will spend a lot of time validating the signature only to find
out that cert is invalid).
	2) Apps need to have access to certs used to verify key.
	You are absoluely correct. I am not sure that I want to open
xmlSecX509Data structure but
	I promise to think about something.
	Moultrie, Ferrell (ISSAtlanta) wrote:

		It occurred to me that there's perhaps an easier way
than overriding the
		validation function -- I can check the results structure
after the
		validation is complete. The --print-all shows everything
I need to
		validate the certificate given that I'm controlling the
		certificate store, etc. Looking at
results->key->x509Data->verified with
		X509_get_subject_name() and validating that a proper
certificate was
		used (and that pResult->key->origin ==
xmlSecKeyOriginX509) appears
		quite fine for my application. The only problem I've run
into in
		prototyping this solution is that _xmlSecX509Data struct
is private to
		x509.c. The definition is below:
		  struct _xmlSecX509Data {
		      X509                *verified;
		      STACK_OF(X509)      *certs;
		      STACK_OF(X509_CRL)  *crls;
		Is there another/better way to access the certificate
info used to
		validate the request? Otherwise, shouldn't this be moved
into x509.h so
		that callers can access that data using the result
		-----Original Message-----
		From: Aleksey Sanin [mailto:aleksey at aleksey.com] 
		Sent: Thursday, September 05, 2002 12:01 AM
		To: Moultrie, Ferrell (ISSAtlanta)
		Cc: xmlsec at aleksey.com
		Subject: Re: [xmlsec] Key management / certificate
		As you correctly pointed out, the first your problem
(limiting allowed 
		keys sources
		to x509 certs only) could be simply solved by setting
		of  the xmlSecKeysMngr structure.
		Regarding your other questions about certs validation, I
have to note 
		that the included
		in XMLSec implementation of xmlSecKeysMngr interface is
called "simple"
		You can extend it or completely overwrite yourself :)
You idea about 
		using custom
		verifyX509 callback is absolutely correct. Probably
there is one more 
		way (change
		the OpenSSL verification callback) but I am not sure
that  it is better 
		(for example,
		because this affects all x509 operations in your
		There is no function to load trusted certs from
something other than 
		file or a folder.
		Actually, it is a common practice that trusted certs are
located in a 
		protected folder
		and you have read-only access to it (see Apache,
Mozilla, IE, and other 
		Of course, there are no reasons why you could not load
the trusted cert 
		from memory
		or an XML file. You just need to do some copy/paste :)
		Moultrie, Ferrell (ISSAtlanta) wrote:

			 I'd like to control what public keys and/or
certs are used or usable
			for verifying data. In particular, I'd like to
require that the public
			key be validated by a cert (i.e., that
<sig:KeyValue> supplied
			unvalidated keys not be usable,and, I'd like to
impose certain
			contraints on any cert used (e.g., validating
Issuer, Subject, Usage,
			etc.). While I could search for a KeyValue node
before calling
			validation, it seems like there may be a better
way to accomplish this
			(below). Additionally, it looks like I could
store a new verifyX509
			(xmlSecX509VerifyCallback) pointer in the
xmlSecKeysMngr struct and
			intercept the cert verification. Still, since
I'm very new to all of
			this, I'm wondering if there's not
simpler/better/more direct ways to
			accomplish these types of checks. Any
suggestions or pointers would be
			greatly appreciated!
			 It looks like setting the allowedOrigins flag
of the xmlSecKeysMngr
			structure to xmlSecKeyOriginX509 may solve my
first problem and ensure
			that only keys found in a X509 cert will be
usable. Correct?
			 I don't see any such short-cut for validating
the X509 cert contents
			other than the verifyX509 override I mentioned
earlier. Any other way /
			better option?
			 Finally, it looks like
xmlSecSimpleKeysMngrLoadPemCert() method can


			used to load a trusted root certificate for X509
validation from a


			I'd rather not have a seperate file storing this
information. Is there
			any way to load a trusted cert from a memory
blob or perhaps from a
			second XML document/tree?
			xmlsec mailing list
			xmlsec at aleksey.com

		xmlsec mailing list
		xmlsec at aleksey.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.aleksey.com/pipermail/xmlsec/attachments/20020925/9db3f2bb/attachment.htm

More information about the xmlsec mailing list