OpenSAML user discussion

[hao chen <>]

Hi Scott,

I would very like to listen to your suggestions. I am
doing a project whose programming language is c/c++,
it would verify any saml assertion. Right now the
security requirement is requiring all saml assertions
are signed. Those assertions may generated by java, c,
any program languages, or any federated ID management
servers that follow SAML 1.1. I need to write a
program which can recognize all kind of popular format
of certificates and use them to verify the signature
of saml assertion. Based on your answer to my last
question, signing an assertion may not work in all
cases. Does that indicate our security requirement for
all saml assertions must be signed not be realistic? I
also would like to ask you do me a favor of giving
some code which can read normal format of certificate
storage if you ever have.

I did learn a lot from your responses to my e-mail. I
would like to say thanks again.

hao
--- Scott Cantor 
<>
 wrote:

> > I did see the program strips off the BEGIN/END
> part of
> > certificate file but did not see it strips off the
> > BEGIN/END port of private key file. Do I need to
> do
> > that either modify the key file or the program?
> 
> No, both files would just be PEM. The program dealt
> with the library API by
> just hacking the headers off when it needed to.
> 
> > What is meant by your comment 'didn't support PEM
> > directly but required the input to be base64
> DER,...'?
> > Do you mean I must use base64 encoding if I use
> DER
> > format?
> 
> I mean that the API I had to use only accepts base64
> DER (PEM with no
> headers). The command line parameters are just PEM
> files, and you cannot use
> DER. It's not a general purpose program, it was just
> a way for me to quickly
> test signatures when I had to, particularly early
> on.
> 
> Even now, I don't have a ton of confidence in the
> C++ signing. With Java, I
> can write out the XML in canonical form, but with
> C++, I had to just use a
> hopefully non-modifiying serializer because when I
> tried to use the xsec
> c14n code, it crashed on me.
> 
> The moral is, don't sign unless you have a really
> good reason not to just
> use SSL. XML Signature is a very suspect technology
> because XML isn't
> designed to be byte-preserving. It's mixing oil and
> water. The ways in which
> it works are so fragile as to be untrustworthy
> except under very controlled
> conditions. The parser issues that come up with this
> stuff are ridiculous.
> 
> -- Scott
> 
> 


=====
Best Regard


        
                
__________________________________ 
Celebrate Yahoo!'s 10th Birthday! 
Yahoo! Netrospective: 100 Moments of the Web 
http://birthday.yahoo.com/netrospective/