Subject: [Trans] [trans] #112 (rfc6962-bis): Consider permitting the status_request_v2 TLS extension

From: "trans issue tracker" <[email-masked]>
Date: Tue, 03 Nov 2015 15:22:50 -0000

#112: Consider permitting the status_request_v2 TLS extension

 Currently we require TLS clients to implement the original status_request
 (RFC6066) TLS extension (aka OCSP stapling) in order to comply with CT.

 The IETF standardized status_request_v2 (RFC6961) a couple of years ago.
 I'm not aware of any implementations of it yet.  Indeed, some browsers may
 never implement it, because they already have proprietary mechanisms for
 revoking intermediate certificates.  Nevertheless, it would seem a little
 strange for 6962-bis to contain absolutely no mention of
 status_request_v2.  If a TLS client and a TLS server both implement CT and
 both implement status_request_v2, why not permit status_request_v2 to be
 used for distributing SCTs?

 I think we should permit status_request_v2 as an optional 4th mechanism
 for distributing SCTs.  In other words...
   - TLS servers MUST support at least 1 of the 3 existing mechanisms for
 sending SCTs (same as today); and TLS servers MAY also support sending
 SCTs via status_request_v2.
   - TLS clients MUST implement all 3 existing mechanisms for receiving
 SCTs (same as today); and TLS clients MAY also support receiving SCTs via
 status_request_v2.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:  draft-ietf-trans-
  [email-masked]           |  [email-masked]
     Type:  enhancement              |     Status:  new
 Priority:  minor                    |  Milestone:
Component:  rfc6962-bis              |    Version:
 Severity:  -                        |   Keywords:
-------------------------------------+-------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/112>
trans <http://tools.ietf.org/trans/>