Newline characters in the value of extension parameters is always not permitted when creating an AuthRequest.

[GoogleCodeExporter]

What steps will reproduce the problem?

1. Sends an AuthRequest message with an extension parameter that has newline 
   characters in its value.
2. Receives the message at the server endopoint and reconstructs it from the 
   request parameters.

 line 80-81 of the SampleServer shows an example of this case:
 ...
 // --- process an authentication request ---
 AuthRequest authReq =
     AuthRequest.createAuthRequest(request, manager.getRealmVerifier());
 ...

 This causes a MessageException to be thrown that says: "Invalid parameter:".

What is the expected output? What do you see instead?

It seems to me that newline characters in the extension parameters should be 
permitted when receiving auth messages using an HTTP encoding.

Background:
I am currently prototyping an extension for enhancing message security that 
implements the MessageExtension and it has an parameter containing newlines 
in its value.  To be more specific, the parameter is to send/receive the X.509 
certificate in PEM format.

I understand the reason for not permitting and strictly validating newlines 
is due to the constraints of Key-Value Form Encoding in direct communication 
and I am also considering that there may be better format than PEM.

What version of the product are you using? On what operating system?

Latest branch as of April 12, 2009, Fedora 10

Please provide any additional information below.

o In AuthRequest class:
    ...
    public static AuthRequest createAuthRequest(ParameterList params,
                                                RealmVerifier realmVerifier)
            throws MessageException
    {
        AuthRequest req = new AuthRequest(params);

        req.setRealmVerifier(realmVerifier);

        req.validate();
    ...
When creating an AuthRequest, validate() is always invoked even when the 
parameters are sent in indirect communication and then the isValid() method 
likewise, which will result in validation failure.

In Parameter class:
    public boolean isValid()
    {
        return !((_key != null && _key.indexOf(':') > -1) ||
                (_key != null && _key.indexOf('\n') > -1) ||
                (_value != null && _value.indexOf('\n') > -1));
    ...

Original issue reported on code.google.com by shuichi....@gmail.com on 13 Apr 2009 at 8:59

[GoogleCodeExporter]

The Key-Value Form Encoding is (also) used for all OpenID messages when 
computing 
the signature, regardless of the transport layer encoding that will be used 
when the 
message actually gets sent. It is essential that all parties can reliably parse 
the 
fields and be able to count on the newline separator for this.

If an extension needs to use characters that are defined as reserved by the 
core 
spec, the extension needs to specify an escaping/encoding mechanism for them.

Original comment by Johnny.B...@gmail.com on 13 Apr 2009 at 9:16

[GoogleCodeExporter]

Thank you for your comment.

I had completely overlooked that portion of the spec  :'( 
Now I really understood what you said.

I will consider using a different format or encoding PEM strings with
some sort of escaping mechanism.
Thank you for directing me to the right direction.  That really helped me a lot!

Original comment by shuichi....@gmail.com on 13 Apr 2009 at 2:20

[GoogleCodeExporter]

Original comment by Johnny.B...@gmail.com on 6 May 2009 at 4:57

• Changed state: Invalid