<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Message</TITLE>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2800.1106" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=505403503-26092002><FONT face=Arial color=#0000ff size=2>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.</FONT></SPAN></DIV>
<DIV><SPAN class=505403503-26092002><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=505403503-26092002><FONT face=Arial color=#0000ff size=2>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.</FONT></SPAN></DIV>
<DIV><SPAN class=505403503-26092002><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=505403503-26092002><FONT face=Arial color=#0000ff size=2>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.</FONT></SPAN></DIV>
<DIV><SPAN class=505403503-26092002><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=505403503-26092002><FONT face=Arial color=#0000ff
size=2>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!</FONT></SPAN></DIV>
<DIV><SPAN class=505403503-26092002><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=505403503-26092002><FONT face=Arial color=#0000ff size=2>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. </FONT></SPAN></DIV>
<DIV><SPAN class=505403503-26092002><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=505403503-26092002><FONT face=Arial color=#0000ff size=2>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.</FONT></SPAN></DIV>
<DIV><SPAN class=505403503-26092002><FONT face=Arial color=#0000ff
size=2>Thanks!</FONT></SPAN></DIV>
<DIV><SPAN class=505403503-26092002><FONT face=Arial color=#0000ff
size=2> Ferrell</FONT></SPAN></DIV>
<BLOCKQUOTE style="MARGIN-RIGHT: 0px">
<DIV></DIV>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left><FONT
face=Tahoma size=2>-----Original Message-----<BR><B>From:</B> Aleksey Sanin
[mailto:aleksey@aleksey.com] <BR><B>Sent:</B> Wednesday, September 25, 2002
8:17 PM<BR><B>To:</B> Moultrie, Ferrell (ISSAtlanta)<BR><B>Cc:</B>
xmlsec@aleksey.com<BR><B>Subject:</B> Re: [xmlsec] Key management /
certificate management<BR><BR></FONT></DIV>I believe that there are 2 separate
question:<BR>1) Is it possible to validate cert *after* signature
verification.<BR>The answer is "NO" because the XML DSig standard allows to
specify multiple<BR>certs for each key. And application MUST check all the
certs in order to find <BR>one it accepts. Suppose you have 2 different certs
in the signed message and <BR>the first one is "bad" from your point of view
and the second one is "good".<BR>In the case when cert validation is done
*after* signature verification, (as you suggest),<BR>the application will pick
up the first cert and you cert validation fails. <BR>Of course, you
application may return list of the certs, etc. but this really
complicates<BR>the logic and I am not sure that there no other logic holes.
Not mention that <BR>this is bad from performance/ Denial Of Service attack
point of view (I can send you<BR>a message signed with very big 4096 RSA key
in my cert and you application <BR>will spend a lot of time validating the
signature only to find out that cert is invalid).<BR><BR>2) Apps need to have
access to certs used to verify key.<BR>You are absoluely correct. I am not
sure that I want to open xmlSecX509Data structure but<BR>I promise to think
about something.<BR><BR>Aleksey<BR><BR><BR>Moultrie, Ferrell (ISSAtlanta)
wrote:<BR>
<BLOCKQUOTE
cite=mid121184A7DB1F9143BB5E3FACCB5487570663E2@atlmaiexcp02.iss.local
type="cite"><PRE wrap="">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?
Thanks!
Ferrell
-----Original Message-----
From: Aleksey Sanin [<A class=moz-txt-link-freetext href="mailto:aleksey@aleksey.com">mailto:aleksey@aleksey.com</A>]
Sent: Thursday, September 05, 2002 12:01 AM
To: Moultrie, Ferrell (ISSAtlanta)
Cc: <A class=moz-txt-link-abbreviated href="mailto:xmlsec@aleksey.com">xmlsec@aleksey.com</A>
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"
member
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
implementations).
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 :)
Aleksey
Moultrie, Ferrell (ISSAtlanta) wrote:
</PRE>
<BLOCKQUOTE type="cite"><PRE wrap="">Hi:
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
</PRE></BLOCKQUOTE><PRE wrap=""><!---->be
</PRE>
<BLOCKQUOTE type="cite"><PRE wrap="">used to load a trusted root certificate for X509 validation from a
</PRE></BLOCKQUOTE><PRE wrap=""><!---->file.
</PRE>
<BLOCKQUOTE type="cite"><PRE wrap="">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?
Thanks!
Ferrell
_______________________________________________
xmlsec mailing list
<A class=moz-txt-link-abbreviated href="mailto:xmlsec@aleksey.com">xmlsec@aleksey.com</A>
<A class=moz-txt-link-freetext href="http://www.aleksey.com/mailman/listinfo/xmlsec">http://www.aleksey.com/mailman/listinfo/xmlsec</A>
</PRE></BLOCKQUOTE><PRE wrap=""><!---->
_______________________________________________
xmlsec mailing list
<A class=moz-txt-link-abbreviated href="mailto:xmlsec@aleksey.com">xmlsec@aleksey.com</A>
<A class=moz-txt-link-freetext href="http://www.aleksey.com/mailman/listinfo/xmlsec">http://www.aleksey.com/mailman/listinfo/xmlsec</A>
</PRE></BLOCKQUOTE><BR></BLOCKQUOTE></BODY></HTML>