On Wed, Apr 18, 2012 at 8:21 PM, Martin Rex <
mrex@...> wrote:
> Nico Williams wrote:
>>
>> On Wed, Apr 18, 2012 at 8:06 PM, Kyle Hamilton <
aerowolf@...> wrote:
>> > I believe that this is improper for TLS-WG to take up. Â The problem
>> > that multi-stapling is intended to address can be done completely
>> > within an X.509 self-signed structure, and derives from PKIX-WG not
>> > producing a single coherent standard that client protocols can simply
>> > plug in. Â Trying to work around a PKIX-WG problem in TLS is not going
>> > to solve the same types of problems that exist in all other PKIX
>> > client protocols.
>>
>> Self-signed structure? No. If freshness indication is to be solved
>> via PKIX then it has to be backwards compatible with existing relying
>> parties' certificate validation code. The obvious solution is to have
>> online CAs issuing short-lived certs to systems that posses the
>> corresponding long-lived cert, with the online CAs having different
>> keys from the issuers of the long-lived certs (of course).
>>
>> I'd be quite happy with such a scheme. Much happier than with OCSP
>> response stapling, and much, much happier than with a solution based
>> on self-signed certs that [presumably] hold the real cert and OCSP
>> responses.
>
> I'd be EXTREMELY UNHAPPY with short-lived certs, because it entirely
> precludes cert pinning, a scheme that is magnitudes more secure than the
> existing Alzheimer approach of to identifying servers with zero prior
> knowledge over and over and over again.
Short-lived certs aren't a problem if you pin by public key, as in:
http://tools.ietf.org/html/draft-ietf-websec-key-pinning-01-Ekr
_______________________________________________
TLS mailing list
TLS@...
https://www.ietf.org/mailman/listinfo/tls