OpenSAML user discussion

[Xavier Drudis Ferran <>]

Hello. 

I must be missing something, but I can't seem to understand what's happening. 
Sorry if this does not belong to opensaml, but since I'm using it and
I don't understand whether it's a bug in opensaml or (much more likely)
a bug in my understanding, I would wellcome any answer (including 
"that's impossible, check your facts again"). 

Since I made this mail too long, I'll try to summarize first with a short  
question:

If in an assertion A and an assertion B the digest value is the same
and the public key of the signer is the same, can assertion A validate
its digest and fail the signature verification but assertion B pass
both digest and signature validation ? The difference between A and B
is only whitespace in the enveloped Signature element (not in the
signed content). I though both should pass all or both fail digest
validation (or at most one should fail both digest and signature
validation).

Now the long story:

I have a SAML 2.0 assertion (well, not quite compliant, but something 
close enough to validate). When I try to validate its signature with
a TrustEngine I get a 

2008-03-03 10:56:45,775  INFO  [org.apache.xml.security.signature.Reference] 
Verification successful for URI "#_tpgDUpcix88SjlFX
Dxaiu66z6Pbxqdktr"

I interpret this as meaning the digest matches the signed element (this ID is 
in the Assertion element that contains the Signature). 
But then I get 

2008-03-03 10:56:45,775  DEBUG 
[org.apache.xml.security.signature.XMLSignature] jceSigAlgorithm    = 
SHA1withRSA
2008-03-03 10:56:45,775  DEBUG 
[org.apache.xml.security.signature.XMLSignature] jceSigProvider     = 
SunRsaSign
2008-03-03 10:56:45,776  DEBUG 
[org.apache.xml.security.signature.XMLSignature] PublicKey = Sun RSA public 
key, 1024 bits
  modulus: 
142677862666553342374455417636898453906080990913265792554568740805973577254145434969127729273099783791267610173164503
51282079191469345889510401870808962235693965224934881891607898042494110256509864936974270782898559951856323264338695682682377369
2806888963737763467476998944211060129658674521925874706205670527
  public exponent: 65537
2008-03-03 10:56:45,777  DEBUG 
[org.opensaml.xml.signature.SignatureValidator] Signature did not validate 
against the credential
's key
2008-03-03 10:56:45,777  DEBUG 
[org.opensaml.xml.signature.impl.BaseSignatureTrustEngine] Signature 
validation using candidate v
alidation credential failed


So, one would say the signing key is wrong, it hasn't been signed
with the correct key (in this case the one inline in the KeyInfo element). 

I know it's not the case because this is a test assertion, but anyway, 
what puzzles me is that if I remove the line feeds in the assertion 
it then validates. If I check the public key in the debug log it is the 
same as the key that failed, the only difference is the lf in the assertion.
I understand whitespace or lf in the signed element
may make a signature fail, but I interpret the error as meaning 
the digest is right, and therefore the content is the same. 
Furthermore, the original assertion only has lf inside the Signature
element, so I'm not changing the signed content. I thought the content of the 
Signature element is not taken
into account in order to validate the signature (well it is taken 
into account in order to get keys, digests, signature value... but 
it is not signed itself as it would be an infinite recursion and serve
no purpose). So I thought whitespace changes inside the Signature 
element should not make one validate and not the other. Some lf
are inside the Base64 of the certificate in the KeyInfo or in the
SignatureValue, but this again should not change the signature
value or the public key (at least the public key is logged the same, 
and I tried removing the lf only inside the SignatureValue 
and it still fails like the original assertion). 


Sorry if I made it too long or not clear enough, but I don't see it
very clearly myself. Maybe I ignore something on xml signatures, which
is fundamental, but the problem is I fear I'm going to get assertions that
don't validate, and although I can remove lf in my SP before
validating them, and make them validate, it sounds weird (and fragile)
to me to have to make such a modification...

Thanks. 



 

-- 
Xavi Drudis Ferran