Subject: [pkix] Certificate flag for 'always stapled'

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 6 Feb 2012 14:16:35 -0500

Discussions on the utility of various revocation mechanisms in another
place arrived at the following problem identified in OCSP: While OCSP
stapling is good for performance, it does nothing to address the
problems that cause current browsers to (mostly) avoid hard-fail when
a valid OCSP token is not returned since the client has no way to know
if a TLS connection should have delivered the stapled cert or not.

Proposal: Introduce a certificate extension that says 'valid OCSP
token must be stapled when used with TLS'.

Mechanism:

If a browser supporting the extension sees a certificate presented in
a TLS session it ignores any OCSP distribution point published in the
cert and will only accept the cert if supported by a valid OCSP token
using the TLS stapling mechanism.

The extension SHOULD NOT be marked critical, legacy browsers will be
unaffected and fail in the ordinary way.

The extension would normally be generated in response to the extension
being published in a CSR. A CSR generating app should only insert the
extension if the server is configured to use OCSP stapling. A server
should provide an operator warning if use of a certificate with the
extension is attempted without stapling being enabled or alternatively
turn on stapling automatically.

-- 
Website: http://hallambaker.com/

---

From: Ryan Hurst <[email-masked]>
Date: Mon, 06 Feb 2012 11:42:44 -0800

Phillip,

While I think its unfortunate such an extension needs to exist (inclusion
of revocation pointers should be all that is necessary for an issuer to
make that statement) I acknowledge that it is needed given where we are.

I for one am supporting of an extension with the semantics you suggest,
that said I think it might make more sense to make it generic, e.g. Not
specific to OCSP and stapling but generic for revocation checking (OCSP
with or without stapling or CRLs).

Ryan

On 2/6/12 11:16 AM, "Phillip Hallam-Baker" <[email-masked]> wrote:

>_______________________________________________
>pkix mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/pkix

---

From: Russ Housley <[email-masked]>
Date: Mon, 6 Feb 2012 18:36:27 -0500

> token must be stapled when used with TLS'.

You really just want the check made by the relying party before making use of the certificate.  Why do you care who makes the request to the OCSP responder?

Russ

---

From: Martin Rex <[email-masked]>
Date: Tue, 7 Feb 2012 01:52:09 +0100 (MET)

Russ Housley wrote:
> You really just want the check made by the relying party before
> making use of the certificate.  Why do you care who makes the request
> to the OCSP responder?

I assume Phillip wants a means for a server (admin) to request a
"hard fail" from clients when not obtaining (stapled) OCSP responses.

Clients may not want to perform OCSP requests for arbitrary
server certs, like for privacy reasons, and more importantly,
clients may _not_ want to perform a hard fail in case that they
do attempt OCSP for a server certificate but fail at the
network layer doing that request.

A client that supports the TLS extension for OCSP response stapling
will reliably be able to obtain OCSP responses from a server that
supports&uses that TLS extension, completely independent of the client's
network connectivity to other places.

-Martin

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 07 Feb 2012 00:58:01 +0000

I'm not necessarily disagreeing with doing this, but...

Isn't this getting very close to a short-lived cert? Presumably
an RP would hard-fail with that with no code or config changes
and it'd be simpler all 'round with no need for new RFCs or code
even on the TLS server or CA. (Well, maybe some business logic
or billing code would need to change.)

So, I guess it'd be good to be clear why this is better than
just short-lived certs, but I'm not at all sure I know of a
good answer for that question.

S

---

From: Martin Rex <[email-masked]>
Date: Tue, 7 Feb 2012 02:45:29 +0100 (MET)

Stephen Farrell wrote:
> 
> Isn't this getting very close to a short-lived cert?

Short-lived TLS server certs is an entirely different can'o'worms
and I believe short-lived X.509 certs are a very bad idea.  

There currently is no workable scheme for key continuity management
in X.509, so short lived certs break certificate pinning pretty badly.
Many servers will need a full restart to switch their certificate
(loss of service) and a failure in the complex X.509 certificate
management process will take out the entire server, so it is
effectively time-bombing your own server and requiring someone to
constantly watch and reset the timer before the cert expires.
No thank you.

>
> Presumably an RP would hard-fail with that with no code or
> config changes

PHB was proposing a new non-critical certificate extension.
Such a change will not affect any moderately reasonable RP at all.
If an RP adopts the code for supporting this extension (and such
support will require the client to offer the TLS extension
and parse the servers stapled OCSP responses from ExtendedServerHello,
then it will simple work without requiring any configuration nor
any additional network connectivity.

> or billing code would need to change.)

If you believe in OCSP _at_all_ for online authentication, then the
only sensible approach outside of a small closed group without privacy
concerns is for each communication peer to convey the OCSP responses
for his own certificates in-band with the communication protocol.

> good answer for that question.

The only real-world scenarion in PKIX where short-lived certs are
supported in a sensible fashion is OCSP signing, when the
OCSP response includes the short-lived OCSP responder cert.

The same thing already does not work for CRLs, because of the lack
of a standized CRL extension to include a short-lived CRL signer cert.

And for other scenarios, any kind of short-lived credential that
is issued by a completely seperate organizational entity is
IMHO screaming for trouble.

-Martin

---

From: "Ryan Hurst" <[email-masked]>
Date: Mon, 6 Feb 2012 18:26:55 -0800

Short lived certificates are great, I used them successfully in a design for
some work I have done in the past.

The problem is that most enrollment clients don't reconfigure servers to use
the new certificate and most applications don't deal with the certificate
change automatically -- the net of which is that without changes to servers
and/or enrollment clients this won't work.

And while I think application vendors/providers could (and should IMHO)
change to deal with these cases better (can you imagine how much time is
wasted dealing with this today) the adoption curve for new servers is
significantly slower than of browsers, I saw a recent article that suggested
that almost 60% of browsers are updated within a year due to the forced
update semantics within it.

My takeaway is this work would be complimentary to improvements in the
enrollment clients/certificate supporting servers and address a near term
problem in  a practical way.

Ryan
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Stephen Farrell
Sent: Monday, February 06, 2012 4:58 PM
To: Phillip Hallam-Baker
Cc: [email-masked]
Subject: Re: [pkix] Certificate flag for 'always stapled'

Isn't this getting very close to a short-lived cert? Presumably an RP would
hard-fail with that with no code or config changes and it'd be simpler all
'round with no need for new RFCs or code even on the TLS server or CA.
(Well, maybe some business logic or billing code would need to change.)

So, I guess it'd be good to be clear why this is better than just
short-lived certs, but I'm not at all sure I know of a good answer for that
question.

S

---

From: "Ryan Hurst" <[email-masked]>
Date: Mon, 6 Feb 2012 18:39:58 -0800

I believe Phillip is suggesting that a standardized way be established for a
certificate issuer to indicate that for a given certificate a successful
OCSP response is needed before the relying party trusts it.

Not for a server admin to specify, via say a TLS extension; a server
operator (or bad guy) would never say "please fail to connect to me", an
issuer on the other-hand may have a warranty or other similar rational that
would require the client to do such a check.

That said its unfortunate such an extension would be required, absence of a
revocation indicator should mean no revocation check is necessary (this is
one of the presumptions behind short-lived certificates being a means to
side-step the need for a revocation check) but the reality is what it is,
such an extension would help.

Ryan 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Martin Rex
Sent: Monday, February 06, 2012 4:52 PM
To: Russ Housley
Cc: [email-masked]
Subject: Re: [pkix] Certificate flag for 'always stapled'

Russ Housley wrote:
> You really just want the check made by the relying party before making 
> use of the certificate.  Why do you care who makes the request to the 
> OCSP responder?

I assume Phillip wants a means for a server (admin) to request a "hard fail"
from clients when not obtaining (stapled) OCSP responses.

Clients may not want to perform OCSP requests for arbitrary server certs,
like for privacy reasons, and more importantly, clients may _not_ want to
perform a hard fail in case that they do attempt OCSP for a server
certificate but fail at the network layer doing that request.

A client that supports the TLS extension for OCSP response stapling will
reliably be able to obtain OCSP responses from a server that supports&uses
that TLS extension, completely independent of the client's network
connectivity to other places.

-Martin

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 6 Feb 2012 22:32:25 -0500

> You really just want the check made by the relying party before making use of the certificate.  Why do you care who makes the request to the OCSP responder?

No, thats not the point. The point is that the server is always going
to provide the token stapled so if there is no stapled token there is
no need to look elsewhere.

The motivation for this is that the Google people are proposing to not
look elsewhere if there is no stapled token. At the moment most of the
browsers will try to pull the OCSP token but give up if it is not
found (soft fail). So the revocation mechanism is effectively
nullified.

What is needed therefore is not merely the statement 'OCSP is
supported', that is what the distribution point says and we have been
told 'really check OCSP and hardfail if not found' is not likely to be
implemented so it really has to be 'if you did not get the OCSP token
in the TLS session then you are being MITM'd and must hardfail'.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 6 Feb 2012 22:37:41 -0500

I like the idea of short lived certs, but we really need to have the
servers implement a common protocol to ensure that they maintain a
fresh cert before it is going to be viable deployment wise.

---

From: "Miller, Timothy J." <[email-masked]>
Date: Tue, 7 Feb 2012 14:43:23 +0000

So perhaps a more pointed question is why should this be a PKIX work item?
 The certificate extensions model is open.  Is the extension syntax
incomplete in some way?

-- T

---

From: Rob Stradling <[email-masked]>
Date: Tue, 07 Feb 2012 14:52:31 +0000

>   The certificate extensions model is open.  Is the extension syntax

If this is a private certificate extension that isn't going to be widely 
deployed, then fair enough.

But if we want to define an extension that all CAs will (eventually) put 
into all TLS Server Certificates and which all TLS Clients will 
(eventually) support, then surely it makes sense to make this a PKIX 
work item?

> -- T
>
> On 2/6/12 9:32 PM, "Phillip Hallam-Baker"<[email-masked]>  wrote:
>
>> On Mon, Feb 6, 2012 at 6:36 PM, Russ Housley<[email-masked]>  wrote:
>>> Phill:
>>>

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
   3rd Floor, 26 Office Village, Exchange Quay,
   Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed.  If you have received this email in error please notify the 
sender by replying to the e-mail containing this attachment. Replies to 
this email may be monitored by COMODO for operational or business 
reasons. Whilst every endeavour is taken to ensure that e-mails are free 
from viruses, no liability can be accepted and the recipient is 
requested to use their own virus checking software.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 7 Feb 2012 11:08:23 -0500

Because the idea is that Pkix is a standard and clients, servers, etc. all use the same extension code and have a common understanding of the semantics which are written down somewhere.

Sent from my iPad

---

From: Stephen Kent <[email-masked]>
Date: Tue, 7 Feb 2012 11:21:18 -0500

>  The certificate extensions model is open.  Is the extension syntax

In general, an extension to a PKIX standard should be pursued in 
PKIX, if one wants broad support for it in CAs and RPs.

Steve

---

From: "Miller, Timothy J." <[email-masked]>
Date: Tue, 7 Feb 2012 21:08:38 +0000

Whether a Subscriber needs a specific OID is a contractual issue between
the Subscriber and the CA.  Any CA can put any arbitrary OID into
Extensions at any time.  The software changes are trivial.  Non-critical
Extensions have no impact on existing implementations[1].  Critical
Extensions have defined processing requirements.

Actual processing of this Extension value is of interest only to the
limited community of browser vendors.

In short, PKIX doesn't set requirements for what a TLS certificate profile
looks like.  TLS WG should do that.

-- T
[1] Yes, Peter, I know.  :)

---

From: Stephen Kent <[email-masked]>
Date: Tue, 7 Feb 2012 18:31:59 -0500

>looks like.  TLS WG should do that.

Tim,

I agree that TLS is responsible for cert & CRL profiles for that protocol.
But, that does not mean that an extension should be developed there, unless
there is agreement that the extension is not of general utility.

Steve

---

From: Michael Myers <[email-masked]>
Date: Tue, 7 Feb 2012 17:03:53 -0700

> there is agreement that the extension is not of general utility.

The extension could indeed have broader applicability.

http://tools.ietf.org/html/rfc4806

Mike

---

From: Chris Richardson <[email-masked]>
Date: Tue, 7 Feb 2012 22:41:57 -0500

> in the TLS session then you are being MITM'd and must hardfail'.

If I'm going to MITM you, I'm not going to use a certificate with this
extension.  To be useful, the RP must remember that the certificate it
saw previously for this domain used this extension.  And if the RP has
to remember a previously seen certificate, what is the advantage of
this proposal over pinning mechanisms?

---

From: "Ryan Hurst" <[email-masked]>
Date: Tue, 7 Feb 2012 20:22:57 -0800

Chris,

That's only true if you are assuming there is another certificate out there
for the same name, that would be true for an existing domain for a limited
period of time since the current certificate will expire, or if a CA were
compromised and would issue arbitrary certificates.

Not that #2 hasn't and won't happen but there is no solving for that problem
in the PKIX model.

Ryan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Chris Richardson
Sent: Tuesday, February 07, 2012 7:42 PM
To: Phillip Hallam-Baker; [email-masked]
Subject: Re: [pkix] Certificate flag for 'always stapled'

If I'm going to MITM you, I'm not going to use a certificate with this
extension.  To be useful, the RP must remember that the certificate it saw
previously for this domain used this extension.  And if the RP has to
remember a previously seen certificate, what is the advantage of this
proposal over pinning mechanisms?
_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix

---

From: Anders Rundgren <[email-masked]>
Date: Wed, 08 Feb 2012 21:01:48 +0100

> some work I have done in the past.

I like the idea as well.  Now assume that the server uses an HSM
for keeping private keys.  Sounds great doesn't it?

However, no HSM can do what a $10 TPM can do, attest the origin of
the *new* key-pair.  BTW, PKIX recently dismissed end-to-end-secured
enrollment/renewal as a valid topic which de-facto leaves us with
stapled OCSP as (IMO) the only realistic choice.

There are also scalability issues that speaks for OCSP.

Anders

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 08 Feb 2012 16:25:32 -0500

New certificate does not necessary imply new private key.  The 
short-term certificates may all contain the same public key.

RFC 3647, Section 4.4.6:

       Certificate renewal means the issuance of a new
       certificate to the subscriber without changing the
       subscriber or other participant's public key or any
       other information in the certificate

Of course, this doesn't eliminate the problems that others have 
mentioned with changing the server's certificate.

---

From: "Ryan Hurst" <[email-masked]>
Date: Wed, 8 Feb 2012 13:50:31 -0800

David,

Your absolutely right, sorry for not being clearer; I do however think that
new-key renewals significantly address the risks of software managed keys
and key compromise so I have a strong preference for that model.

Anders,

As far as the use of TPMs as general purpose cryptography appliances like
one would use a HSM, the performance and reliability characteristics of
these devices make them a poor choice in those environments, they also have
limited crypto capabilities making it impossible to implement some protocols
with them. With that said the attestation model they offer is quite cool;
those systems that do use them for general purpose cryptography scenarios
usually limit their use to just a means to secure the key material at rest.

Ryan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
David A. Cooper
Sent: Wednesday, February 08, 2012 1:26 PM
To: [email-masked]
Subject: Re: [pkix] Certificate flag for 'always stapled'

New certificate does not necessary imply new private key.  The short-term
certificates may all contain the same public key.

RFC 3647, Section 4.4.6:

Of course, this doesn't eliminate the problems that others have mentioned
with changing the server's certificate.

On 02/08/2012 03:01 PM, Anders Rundgren wrote:
>> Short lived certificates are great, I used them successfully in a 
>> design for some work I have done in the past.
> I like the idea as well.  Now assume that the server uses an HSM for 
> keeping private keys.  Sounds great doesn't it?
>
> However, no HSM can do what a $10 TPM can do, attest the origin of the 
> *new* key-pair.  BTW, PKIX recently dismissed end-to-end-secured

---

From: Stephen Kent <[email-masked]>
Date: Wed, 8 Feb 2012 17:06:22 -0500

At 9:01 PM +0100 2/8/12, Anders Rundgren wrote:
>...ed them successfully in a design for
>the *new* key-pair.

Not a new feature, and not unique to TPMs. The HSMs that we provided
in the 90's each contained an RSA key pair unique to the device, and thus
one could determine that the key pair generator was a BBN SafeKeyper, if the
HSM operator wanted to prove this to a 3rd party.

Steve

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 8 Feb 2012 23:29:44 -0500

On Tue, Feb 7, 2012 at 10:41 PM, Chris Richardson <[email-masked]> wrote:
> extension.

Stop right there, my management would be very happy if there was a way
to make a cert undesirable to an attacker!

But looking at the question, it seems as if you imagine that the three
reported incidents of fraudulent certificate issue are the primary
concern here. They are not. The number of certs involved was about a
hundred. Or about the number of system admins that screw up their
system config, lose their key or foul up in some more imaginative way
every day.

>To be useful, the RP must remember that the certificate it

Well its stateless for one. Pinning is inherently a stateful process
and thus more expensive than this mechanism.

But more broadly, this is addressing a separate issue to pinning in my
view. Even with pinning we want revocation to work and hardfail.

---

From: Anders Rundgren <[email-masked]>
Date: Thu, 09 Feb 2012 07:39:20 +0100

> HSM operator wanted to prove this to a 3rd party.

Sure, but I was talking about this in the context of *automatic* renewals.

In fact the passport system created by ICAO and BSI relies entirely on
short-lived certificates that are automatically renewed and with *new*
key material and storage in HSMs.   BSI got it slightly wrong and assumed
that once a key is in a HSM you are done.

Fortunately. Google's Wallet can do secure (attested) updates so it is
not all doom and gloom.

Anders

---

From: Piyush Jain <[email-masked]>
Date: Fri, 10 Feb 2012 10:10:13 -0800

> Phillip Hallam-Baker
> Sent: Monday, February 06, 2012 7:32 PM
> To: Russ Housley
> Cc: [email-masked]
use
> of the certificate.  Why do you care who makes the request to the OCSP
> responder?
> >
> > Russ
> 
> No, thats not the point. The point is that the server is always going to
provide
> the token stapled so if there is no stapled token there is no need to look
> elsewhere.
> 
look
> elsewhere if there is no stapled token. At the moment most of the browsers
> will try to pull the OCSP token but give up if it is not found (soft
fail). So the
> revocation mechanism is effectively nullified.
> 

Not sure if I understand the use case correctly.
It seems that only benefit of this extension is that the CAs will be able to
force the TLS servers to implement OCSP stapling.

I> 
> What is needed therefore is not merely the statement 'OCSP is supported',
> that is what the distribution point says and we have been told 'really
check
> OCSP and hardfail if not found' is not likely to be implemented so it
really has
> to be 'if you did not get the OCSP token in the TLS session then you are
being
> MITM'd and must hardfail'.

If there is an attacker in the middle, why would he present a certificate
with this extension?
Are you saying that this is for scenarios where the CA is compromised or
those where it has issued certificates in error?

---

From: Tom Ritter <[email-masked]>
Date: Fri, 10 Feb 2012 13:33:12 -0500

> those where it has issued certificates in error?

I think the 'big wins' for this mechanism come from enhancements that
haven't been made yet.

For example:
 - In some future browser, a site communicates a security policy
(perhaps in or similar to Strict Transport Security) that says "certs
from me will always have the require-staple extension set".  If the
browser sees a cert presented that doesn't have it, it fails.
 - In some future browser/extension that 'learns' security policy from
the site without being explicitly told it (e.g. site is hosted in the
Us, uses this CA, etc) - this will be another data point
 - A browser chooses to extend a extra-special-super-green bar[1] to a
certificate that has this extension set
 - CAs eventually decide to only issue (EV || DV) certs that have this
extension set ( || for high profile sites || sites that opt in)

One scenario today, the only I could think of in 5 minutes, where this
an advantage is if an attacker compromises a cert in use, it gets
revoked/expires[2], and the attacker wants to use it.  Cert can't get
a good staple, and would be rejected.  For the 'common' attack
scenario of an attacker breaking into or tricking a CA to issue him
his own cert, this doesn't help.

I'm torn.  I like things that add incremental options for site owners
to improve security. But... there's an implementation cost here.  And
the more I survey PKIX as it stands and is being developed now...
there's *so much* for a security conscious administrator to consider.
Do we want to add a whole lot more for relatively small gains?

-tom

[1] Or some other way to say "This cert is double-plus-good", like the
subtle differences in UI we have today between Mixed Content, DV, and
EV certs.
[2] Considering clock attacks

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 10 Feb 2012 10:47:26 -0800

Although this is a proposed PKIX extension, the value of it only comes if certificate emitters and relying parties act on it. The extension itself is pretty trivial, but as the thread has shown, the semantics and implementation are not. If this is pursued, the work should be done where there is more difficulty; that is, it should be in the websec WG, not the pkix WG, although the format of the extension should certainly be reviewed here.

--Paul Hoffman

---

From: Rob Stradling <[email-masked]>
Date: Fri, 10 Feb 2012 21:50:28 +0000

On 10/02/12 18:47, Paul Hoffman wrote:
<snip>
> ...although the format of the extension should certainly be reviewed here.

Rather than define a completely new extension, wouldn't it make more 
sense to extend the existing Authority Information Access extension?

The fields in the AIA extension are accessMethod and accessLocation. 
OCSP is the "method" for both on-line OCSP and stapled OCSP.  The main 
difference between the two is the "location" from which the OCSP 
Response is "accessed".

---

From: Piyush Jain <[email-masked]>
Date: Fri, 10 Feb 2012 21:52:51 -0800

> Sent: Friday, February 10, 2012 1:50 PM
> To: [email-masked]

I think that the use cases that this new extension would server are still
unclear.

> difference between the two is the "location" from which the OCSP Response
> is "accessed".
> 

In any case overloading AIA might not be a good idea. The interpretation of
this extension would differ depending on whether the RP is a TLS client or a
TLS server.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 13 Feb 2012 10:53:53 -0500

We already have a security mechanism in SSL, it is the https URL
method combined with the padlock icon.

Now that is not the best approach, but it is certainly more than
nothing. It would clearly be best if we had a more comprehensive
security policy mechanism. But that is a lot more involved than the
'must staple' flag.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 13 Feb 2012 11:01:40 -0500

Suggesting WebSec is a fair enough point.

The PKIX part is pretty straightforward as you point out. But as Rob
also points out, there is more than one option for expressing the
flag. I would like to get that part squared away first.

As for this being a way for CAs to 'force' use of stapling. I hadn't
really though of it that way. But assuming the cost of supporting this
type of cert is significantly lower than for regular certs, it is
possible that some CAs will offer them at a lower price. That would be
a win win for the customer - better security and a lower cost.

I somehow suspect that the cost reduction is not going to be
significant enough to make a difference for any sites other than the
very busiest.

---

From: "Miller, Timothy J." <[email-masked]>
Date: Mon, 13 Feb 2012 16:02:44 +0000

>security policy mechanism. But that is a lot more involved than the

Machine evaluation & mapping of certification policies?  I could get
behind that.  

-- T