<div dir="ltr"><div><div><div><div>Thank you Brent.<br><br></div>The SP is built with OpenSAML Java(2.6.3). Like you correctly guessed, at the moment I am looking to resolve a Credential from KeyInfo. I checked xmltooling and it does have resolvers, but I think I&#39;ll need to understand about the resolvers and which resolvers to use. Thank you for the pointer. <br><br></div>Thank you for the advise on establishing trust. I now understand how important it is and I would implement it. The more complex example at the bottom serves as a great resource for this. <br><br></div>If there happen to be examples citing the usage of credential resolvers and a basic signature trust engine, it would be great to know them. I plan on using a local trust store at the SP for establishing the trust.<br><br></div>Thank you,<br>Sundeep<br><div><div><div> <br><div><div><div><div><div><div><div><div class="gmail_extra"><pre><b><font size="+1">List:       <a href="http://marc.info/?l=shibboleth-dev&amp;r=1&amp;w=2">shibboleth-dev</a>
Subject:    Re: XML signature validation
From:       Brent Putman &lt;putmanb () georgetown ! edu&gt;
Date:       <a href="http://marc.info/?l=shibboleth-dev&amp;r=1&amp;b=201412&amp;w=2">2014-12-15 18:38:35</a>
Message-ID: <a href="http://marc.info/?i=548F2AAB.10400%20%28%29%20georgetown%20%21%20edu">548F2AAB.10400 () georgetown ! edu</a></font>
[<a href="http://marc.info/?l=shibboleth-dev&amp;m=141866872901636&amp;q=raw">Download message RAW</a>]</b>

<a href="http://marc.info/?l=shibboleth-dev&amp;m=141866872901636&amp;q=p2"><b>[Attachment #2 (multipart/alternative)]</b></a>


On 12/15/14 1:22 PM, Sandy wrote:
&gt;
&gt;
&gt; 1. Is it a good practice to use the public key from the SAML assertion?

That&#39;s a complicated question.  The short answer is, you can literally
extract the key from the Signature&#39;s KeyInfo and cryptographically
verify the signature with it - but you can&#39;t *only* do that.  One way or
another, you have to verify the trust of the key using out-of-band
information, such as SAML metadata.

&gt; 2. If yes, are there any existing utility methods - that I&#39;m unaware
&gt; of - to create or validate the signature without having to append and
&gt; pre-pend the markers.

Yes, there are lots of ways to build the cert from the base64-encoded
DER without the PEM headers/footers.  Those are not really part of the
encoding.  You didn&#39;t say what your SP is built with, but if it&#39;s
OpenSAML Java (or I assume also C++) then we have helpers in xmltooling
for that purposes.  But we also have higher level components, for
example which resolve a Credential from a KeyInfo, or which wrap that in
the entire trust-establishment process (TrustEngine).

&gt; 3. Why are the markers stripped off from the x509certificate in
&gt; idp-metadata.xml.

They&#39;re not specified nor allowed by the spec which defines the KeyInfo
structure (the XML Signature specification).

The headers/footers that you&#39;re calling &quot;markers&quot; are from PEM format,
used on disk, in MIME email, etc.  The use case here doesn&#39;t specify
that format.

&gt;
&gt; For the record, I have followed
&gt;
&gt; <a href="https://wiki.shibboleth.net/confluence/display/OpenSAML/OSTwoUserManJavaDSIG" rel="nofollow">https://wiki.shibboleth.net/confluence/display/OpenSAML/OSTwoUserManJavaDSIG</a>
&gt;
&gt;
&gt; page, which was helpful, but the method call
&gt; &#39;getVerificationCredential()&#39; was not clear, which is what I was
&gt; trying to implement.
&gt;

Ok.  It&#39;s deliberately left unclear, b/c it&#39;s just a sketch of the API. 
You typically wouldn&#39;t want to actually do that in the real world, at
least not *just* that.  Note the big red box above about &quot;Trust
Establishment&quot;, don&#39;t ignore that.

The more complex example below that with the TrustEngine is conceptually
what you really have to do.   There&#39;s layers of abstraction in there,
but ultimately you have to verify the trust of the signing key or else
you have zero security.  You can&#39;t just trust what is in the Signature&#39;s
KeyInfo.<br><br><br></pre><div class="gmail_quote">On Mon, Dec 15, 2014 at 7:22 PM, Sandy <span dir="ltr">&lt;<a href="mailto:sundeep.nitw@gmail.com" target="_blank">sundeep.nitw@gmail.com</a>&gt;</span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div><div>Hello,<br><br></div>I have turned ON 
signing responses and assertions for my SP. I am able to see that the 
IdP is signing both in the assertion. While validating the signature at 
SP, I am trying to use the public key sent in the XML signature. I am 
obtaining the public key from the XML DOM, but I have to pre-pend 
&#39;-----BEGIN CERTIFICATE-----&#39; and append &#39;-----END CERTIFICATE-----&#39; to 
generate an java.security.cert.X509Certificate object. Upon further
 investigation, I see that these lines are being removed while 
generating the idp-metadata.xml(at MetadataGeneratorParameters.getCertificateContents()).<br><br></div>1. Is it a good practice to use the public key from the SAML assertion?<br></div>2.
 If yes, are there any existing utility methods - that I&#39;m unaware of - 
to create or validate the signature without having to append and 
pre-pend the markers.<br></div>3. Why are the markers stripped off from the x509certificate in idp-metadata.xml.<br><br></div><div>For the record, I have followed <br><br><a href="https://wiki.shibboleth.net/confluence/display/OpenSAML/OSTwoUserManJavaDSIG" target="_blank">https://wiki.shibboleth.net/confluence/display/OpenSAML/OSTwoUserManJavaDSIG</a> <br><br>page,
 which was helpful, but the method call &#39;getVerificationCredential()&#39; 
was not clear, which is what I was trying to implement.<br></div><div><br></div>Thank you,<br></div>Sundeep<br><br></div>P.S.: My apologies for posting this question first in the users list. It belongs to the dev list. My bad! As always, I appreciate your patience. Thank you.<br></div>
</blockquote></div></div></div></div></div></div></div></div></div></div></div></div></div>