Subject: Robustness principle

From: Mike <[email-masked]>
Date: Tue, 18 Nov 2008 12:50:04 -0800

The robustness principle is not necessarily bad when it is
applied as it was originally intended.  It has two parts:

    1 - be liberal in what you accept
    2 - be conservative in what you send

The problem is that some people incorrectly interpret the
second part to mean, "if you accepted something non-standard
(that would otherwise have been rejected), *attempt to fix
it* before passing it along, so what you send is standard-
compliant."

W.R.T. a non-DER-encoded certificate, I think the best thing
you can do as an RP is to first attempt to validate it as is,
and if that fails, optionally attempt to re-encode it as DER
and validate it a second time.  That is being liberal in
what you accept.

However, DO NOT pass your "fixed" version on to anyone else;
always give them the original.  That is being conservative
in what you send.  It may seem like you should help your
neighbor, but perhaps they wield the kind of power that can
cause the originator to actually fix their broken software,
making the situation better for everyone.

I have a lot of experience in email server software design
where in the 90's it was considered a good thing to fix email
messages that didn't have proper CR-LF line endings.  This
"helpful" behavior causes too many problems, so it is no
longer recommended.  It, too, was done in the name of the
robustness principle, but the principle does not actually
advocate modifying relayed objects.

Mike

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 18 Nov 2008 16:05:12 -0500

Mike,

If signature verification on "as is" fails, but succeeds for DER
encoded, what harm do you see in saving, using and relaying DER encoded?

One harm I see is that the payload that contained the certificate
itself, may be signed and that signature will break.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Mike
Sent: Tuesday, November 18, 2008 3:50 PM
To: [email-masked]
Subject: Robustness principle

Mike

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 18 Nov 2008 21:50:09 +0000

I agree, but I'm not sure where this has applicability within the context of standardization.

If you pass a certificate to me where the signature validates, I will be able to use it and trust it regardless of whether you "fixed" it.

The situation is quite different when we talk about signed objects. For this case there is only one single representation of the signed data that will match the signature. The Relying Party is safe as long as the signature validates and the signed data can be decoded.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> On Behalf Of Santosh Chokhani
> Sent: den 18 november 2008 15:05
> To: Mike; [email-masked]
> Subject: RE: Robustness principle
>
>
> Mike,
>

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 18 Nov 2008 16:59:09 -0500

Stefan,

The purpose of my post was that while relaying payload is a good
principle, if I am going to use the certificate to create a new payload,
I should DER encode the certificate if the signature verifies on the DER
encoding.

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]] 
Sent: Tuesday, November 18, 2008 4:50 PM
To: Santosh Chokhani; Mike; [email-masked]
Subject: RE: Robustness principle

I agree, but I'm not sure where this has applicability within the
context of standardization.

If you pass a certificate to me where the signature validates, I will be
able to use it and trust it regardless of whether you "fixed" it.

The situation is quite different when we talk about signed objects. For
this case there is only one single representation of the signed data
that will match the signature. The Relying Party is safe as long as the
signature validates and the signed data can be decoded.

Stefan Santesson
Senior Program Manager

---

From: Mike <[email-masked]>
Date: Tue, 18 Nov 2008 15:25:26 -0800

> encoded, what harm do you see in saving, using and relaying DER encoded?

Saving and using the fixed version for your own purposes is fine, but
you shouldn't pass it along.  If re-encoding the certificate renders
it valid, then somewhere along the way somebody broke it.  That broken
software needs to be fixed, so if you don't pass along the fixed
version, discovering where the problem is will be much easier, and
there will be more unhappy people to pressure them for a fix.  As an
engineer I understand that it may be easier to just add a little code
to work around a problem.  Then you end up with something like SSLv2
with so many little workarounds that are not in any document which
make it nearly impossible to implement (and interoperate).  Fortunately
SSLv2 can now be considered historical.

Mike

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 19 Nov 2008 00:45:50 +0000

I would say that it is impossible to successfully generalize what an appropriate behavior is.
What is reasonable in one situation and context is not reasonable in another.

No matter what we say, implementers will do what best serves their customers and their own business.

Stefan Santesson
Senior Program Manager

> Sent: den 18 november 2008 17:25
> To: [email-masked]
> Subject: Re: Robustness principle
>
>