Re: [TLS] Status of X.509v3 TLS Feature Extension?

[Rob Stradling <[e-mail]>]

On 27/04/14 13:07, Tom Ritter wrote:
> There isn't much gain in requiring it on a per-certificate basis, but
> on a host basis it makes a lot more sense. (Not that putting it on a
> cert is bad, just insufficient.)  There were a couple ideas for making
> this a header here:
> http://www.ietf.org/mail-archive/web/tls/current/msg10351.html I too
> would like Must Staple to come back.

AIUI, PHB intends to progress the tls-feature draft just as soon as IANA 
allocates an OID for the new certificate extension.  It's not dead, just 
resting.

An OID allocation request was submitted well over a year ago.  The 
reason for the delay is that following the shutdown of the PKIX WG, 
control of the PKIX OID registry is being transferred to IANA.  IINM, 
the transfer is still not yet complete.

> -tom
>
> On 24 April 2014 15:55, Klemens Baum <[e-mail]> wrote:
>> After the whole Heartbleed incident, it has become obvious that the
>> current mechanisms for Certificate Revocation are inadequately
>> enforced by clients.
>>
>> To combat the issue, it would seem desirable for a security-conscious
>> server operator to be able to require the use of OCSP stapling on a
>> per-certificate basis. There was already an Internet-Draft (now
>> expired) for an X.509v3 extension which would provide this feature:
>> https://datatracker.ietf.org/doc/draft-hallambaker-tlsfeature/
>>
>> Clients supporting the extension could display an enhanced security
>> indicator (e.g. "Certificate Status: Not revoked") for certificates
>> carrying the extension which pass validation, which would also
>> motivate more widespread adoption of OCSP stapling in favor of CRLs
>> and client-initiated OCSP requests.
>>
>> Since the draft looked very promising, I suggest that it should be
>> unexpired. If anyone with the authority to do so agrees, please submit
>> a request for resurrection per the guidelines at
>> http://www.ietf.org/ietf-ftp/1id-guidelines.txt.
>>
>> A few minor clarifications may still be needed so that it can be
>> quickly implemented by major browsers and the CAs:
>>
>> - The tls-feature OID is currently specified with a value of { id-pe 1
>> }, which corresponds to 1.3.6.1.5.5.7.1.1 (authorityInfoAccess, itself
>> already an X.509v3 extension). Surely a new OID in the
>> pkix.privateExtension arc will need to be allocated by IANA and if
>> this is the case, it should be noted in the section "IANA
>> Considerations".
>>
>> Please share your opinions!

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online