Re: [Uta] Opportunistic encryption and authentication agility

[Michael Richardson <[e-mail]>]

Eliot Lear <[e-mail]> wrote:
    >> Well, that's not really correct advice.

    >> The correct advice is that:
    >> If the client is unable to verify the cert via (some set of methods,
    >> locally determined), that it treats the connection as if it was
    >> unencrypted, according the same level of (un)privileges.

    > Perhaps I misread Keith's note, but I didn't take it as advice.  Rather
    > he's assessing the current situation.

I read it as "this is how to implement OE". He wrote:

  keith> Note that as far as I can tell, it will still be possible to
  keith> implement a client that supports only OE; it just doesn't bother
  keith> verifying the cert / DNSSEC + TLSA record / pinned key / whatever.
  keith> Whether that client will


    > Your advice seems reasonably applicable for mail, at least at first
    > blush.  But different protocols have different anticipated environments,
    > and I took Trevor's email Keith's replies to be more general
    > statements.  My favorite example going the other way is SCIM, where you

SCIM == System for Cross-domain Identity Management (?)
     http://datatracker.ietf.org/wg/scim/charter/
     (there are other options to expand that acronym)

Does SCIM have a mode where it is happy (and meaningful) to run unencrypted?
I see in the charter talk about HTTP vs HTTPS.
Reading three pages of the API document, it seems that one could run
LIST/RETRIEVE operations in the clear.

So, actually, I think that my advice is exactly correct.

If the certificates for HTTPS do not verify, then you should treat the
connection exactly as you would if it occured over HTTP.  If that
means that the client shouldn't trust what the server says, then
that's what the client should do.

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-