[xmlsec] Key management / certificate management

Aleksey Sanin aleksey at aleksey.com
Wed Sep 25 21:37:07 PDT 2002

Now I got it :) Sorry I am really stupid tonight :( I opened xmlSecX509Data
structure and it should be in tonight's snapshot. BTW, the other way to 
do this
is to plugin your custom x509 verification code on the OpenSSL or XMLSec
levels. But probably it's an overkill for your case.
Regarding DoS attack:  what if hacker (not your customer) will do this? 
or it's
not possible? I have to say that I've seen many systems used in completely
different conditions then they were designed for :) I would bet that one 
the code you are writing will be used to validate incoming requests from 
Internet :)


Moultrie, Ferrell (ISSAtlanta) wrote:

> 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 
> e-mail.
> 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.
> Thanks!
>    Ferrell
>     -----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 verification.
>     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
>     application
>     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.
>     Aleksey
>     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 trusted
>>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 structure?
>>  Ferrell
>>-----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 management
>>As you correctly pointed out, the first your problem (limiting allowed 
>>keys sources
>>to x509 certs only) could be simply solved by setting "allowedOrigins" 
>>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 application).
>>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?
>>> Ferrell
>>>xmlsec mailing list
>>>xmlsec at aleksey.com
>>xmlsec mailing list
>>xmlsec at aleksey.com

More information about the xmlsec mailing list