Encrypting NameID's and Signing Logout Messages

[Cantor, Scott]

> The reasons for signing and encrypting assertions is obvious, and the same
> reasons would apply to front-channel SLO requests.  But to some extent, the
> arguments that apply to not signing front-channel AuthnRequests also apply:
> there isn't much damage that can be done by forging a LogoutRequest other
> than being annoying and potentially losing sessions and data in applications.

That's potentially pretty significant in some systems, but there's not much risk when the client stores the session that matches, you can't just log somebody else out like you can if the state is on the server. It happens that systems deciding to ignore that part of the standard often tend to rely on NameIDs containing publically guessable values.

Encryption is really a separate issue, and it's obviously the reason I'm just done with NameIDs.

The primary argument is that once you demonstrate you don't pay attention to the standard, the chances of you caring about any of the standard start approaching zero. It's a sign that I can't trust the deployer more than it is an important control. I know they didn't read, don't care, and don't need any consideration from me when I point out their bugs. It saves me time. Paradoxically, signing requests often tells me the same thing. Blindly doing something also tells me you didn't think about it, or more critically, bother to ask.

The best argument against signing them is entirely mutually reinforcing: the same people can't handle their keys and can't handle key rollover, so if I have to pick between supporting encryption and signing logout, I'd take the former and avoid the problems that come up when you try and roll your shared signing/encryption key every year with no understanding of the complications of that process.

-- Scott