Re: [pkix] How do we differentiate authentic servers from proxies performing TLS interception?

["Tom Gindin" <[e-mail]>]

        Tim:

        One good reason for a separate EKU value for proxies might be to 
let the client invoke a different name matching algorithm, although I see 
no case for changing KeyUsage bits here.  It is reasonable for a client 
inside a proxied network to configure a single proxy name + issuer chain 
that will be accepted in advance.
        Making certificates for this purpose distinguishable from ordinary 
TLS server certificates seems unlikely to encourage the use of such 
proxies in countries where they are forbidden by law.

Tom Gindin, CISSP
P.S.    The opinions above are mine and not necessarily those of my 
employer



From:   "Miller, Timothy J." <[e-mail]>
To:     "[e-mail]" <[e-mail]>
Cc:     PKIX <[e-mail]>
Date:   11/12/2015 03:11 PM
Subject:        Re: [pkix] How do we differentiate authentic servers from 
proxies performing TLS interception?
Sent by:        "pkix" <[e-mail]>



> It seems like that's putting the cart before the horse. Getting the 
certificate
> bits right is a Security Engineering 101 issue. Have whomever declare 
their
> intents in advance, and then enforce it. Don't allow certificates to be
> arbitrarily re-purposed or used outside their design parameters. 

Nothing about TLS interception is using certs outside their design 
parameters, or re-purposing a cert.  An intercept MitM creates a valid 
cert binding a specific name under a new authority.  Whether that 
authority has the right to claim that name is not something PKIX 
addresses--that's an enrollment problem and is outside the certificate 
specification.

You can't fix trust by twiddling certificate bits.

-- T
_______________________________________________
pkix mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/pkix