Re: [TLS] Call for acceptance on multi-stapling

[Martin Rex <[e-mail]>]

Kyle Hamilton wrote:
> 
> Eric Rescorla <[e-mail]> wrote:
> >
> > At the meeting in Paris there was broad consensus to adopt Yngve's
> > TLS Multi-Stapling draft
> > (http://www.ietf.org/id/draft-pettersen-tls-ext-multiple-ocsp-03.txt).
> >
> > The WG chairs would like to confirm this consensus. Please send any
> > comments by Wednesday April 25.
> 
 [quotations rearranged from Kyle's original response]
>
> I (grudgingly) shall support this, with many reservations.

I support adopting the work.


> 
> 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.

This was a _known_ characteristic/shortcoming of X.509/PKIX when it
was (re-)used by SSLv3 and carried through to TLSv1.0, that revocation
checking was designed strictly out-of-band.  Originally CRLs, OCSP & SCVP
were later defined as alternative mechanisms, but similarly out-of-band.

Therefore I consider it INappropriate to blame X.509 for what it is
(even though I dislike this property of the X.509 architecture myself).

There are huge benefits associated with the multiple OCSP-responses
stapling, obviating the RP from additional third-party communication
in order to verify the TLS peer's certificate (chain), and protecting
the RPs privacy.  On top of this, the credential holder is in the
best position to ensure an efficiently accessible OCSP responder
for his own certificate (chain), efficiently cache OCSP responses
for his own cert (chain) and to refresh them out-of-band.

> 
> That we can't do this is a bug in PKIX, not a bug in TLS.  That we
> can't get multiple certificate status responses in a single structure
> is a failure of PKIX, not TLS.  Working around it in TLS-WG is
> inefficient, and will not solve the same problem in other PKIX client
> protocols.

Actually, I believe just the opposite.  While CRL suffers from a
design defect that can result in real world security vulnerability,
the OCSP design and the narrow set of acceptable signer certs is
a _huge_ improvement over CRLs, without that CRL signer design flaw.


-Martin