[xmlsec] RE: FW: X509SerialNumber

Wes Thomas wes at encomia.com
Tue Sep 7 07:23:50 PDT 2004


Thanks for all your replies!

I do wish the spec would be a little more clear... but I'm sure that's by
design :-)

-----Original Message-----
From: Rich Salz [mailto:rsalz at datapower.com] 
Sent: Sunday, September 05, 2004 10:33 PM
To: Wes Thomas
Cc: xmlsec at aleksey.com
Subject: Re: [xmlsec] RE: FW: X509SerialNumber

> Assuming an audit is done in the future, how do you identify the 
> issuer certificate?

Not to be flip, but that's the issuer's problem.  If the issuer wants to
ensure that it is properly identified, it must arrange to put some kind of
identifier in the certificates that it creates.  Yes, you can

> I thought that subject name alone does not guarantee uniqueness. That 
> is the point--if I understand it correctly :-)--of having a serial 
> number. Subject and serial together provide uniqueness.

No they don't.  Two different CA's can issue a certificate with the name
subjectDN and serialNumber.  The *only* guaranttee X509 makes about
uniqueness is that a CA will never issue two different certificates with the
same serial number.  So issuer/serial# uniquely identifies an issued
certificate.

How do you uniquely identify the CA?  Often, just verifying the signature in
the cert is enough.  But if the same CA has multiple certs, then you have to
recurse and get the CA's issuer/serial#, and so on.

> Otherwise how would you find the issuer certificate at a later date 
> without being able to provide the CA with the serial number of the 
> certificate you wish to verify against?

Before deciding to trust a cert, you have to already have accepted the
issuer's certificate.  Or somewhere up the chain.  That's kinda how PKI
works.

> Besides that, <X509SerialNumber> is contained within the 
> <X509IssuerSerial> node! Why would that refer to anything BUT the issuer
data?

Because that's not the way it works.  To uniquely a identify a cert issued
by ca "c=us,dn=FooBar" you need the serialNumber that FooBar assigned.

That's just the way it is.

	/r$

--
Rich Salz                  Chief Security Architect
DataPower Technology       http://www.datapower.com
XS40 XML Security Gateway  http://www.datapower.com/products/xs40.html
XML Security Overview      http://www.datapower.com/xmldev/xmlsecurity.html




More information about the xmlsec mailing list