OpenSAML user discussion

[rangeli nepal <>]

Thank you Brent for a wonderful explanation and the best was 

"The rules/engines then ensure that the supplied signature byte[] is
consistent with both the signed content and the key pair used for
signing, the latter via the corresponding public key, which *is* known
one way or another (e.g. from metadata or from the message).  They also
verify that the public key is trusted.  The crypto is done in
algorithm-specific manner (e.g. RSA) in the corresponding Java Security
Signature impl."

My question is about:

<<the latter via the corresponding public key, which *is* known

one way or another (e.g. from metadata or from the message).  They also

verify that the public key is trusted.>>

1. In my case I get message with ds:X509Certificate and I have similar data in metadata. So I am inferring that rule engine will compute signature using both of them and verify it? I believe Certificate with metadata will be more trusted.

2. Trust engine is intelligent enough to differentiate between sefl signed certificate and commercial certificate?

Thanks again for your time.
Regards,
rn

On Thu, May 27, 2010 at 12:04 AM, Brent Putman <> wrote:

On 5/26/2010 10:18 PM, rangeli nepal wrote:

> Currently I am using SAML2HTTPRedirectDeflateSignatureRule and
> SAML2HTTPPostSimpleSignRule with metadata. Both works for me. Now I am
> trying to understand how they work :).
>
> I think they try to build signature from metadata provided
> credential(X509Certificate) and Message specified credential and
> compare them?

Hit send button too quickly..  Actually, I meant to also add that that
isn't literally quite right, at least for the asymmetric crypto case
(public/private key pair).  Conceptually, the security rules and trust
engines can not compute the signature from the message-specified
credential, because they don't have the corresponding private key. But
of course they don't have to, because the signature (a byte[]) is
obviously included in the message, that being the whole point of this.
The rules/engines then ensure that the supplied signature byte[] is
consistent with both the signed content and the key pair used for
signing, the latter via the corresponding public key, which *is* known
one way or another (e.g. from metadata or from the message).  They also
verify that the public key is trusted.  The crypto is done in
algorithm-specific manner (e.g. RSA) in the corresponding Java Security
Signature impl.

For the symmetric key (HMAC) case, the verifier knows the shared secret,
so it just re-computes the signature byte[] over the message content and
compares to the signature byte[] that was sent in the message.