Subject: Re: [pkix] An alternative proposal Was: Fwd: New Version

From: Peter Sylvester <[email-masked]>
Date: Mon, 07 Nov 2011 13:32:51 +0100

If a server can get an OCSP response in a guaranted way,
the CA might as well propose to create short term certs,
one day or so. ? Where is the need for OCSP in that case?

On 10/28/2011 04:35 PM, Martin Rex wrote

The TLS server, on the other hand, can perform OCSP retrieval for
his very own cert with an infrequent recurring asynchronous operation
(e.g. once every few hours), it is always exactly the same OCSP server,
the CA has a contractual obligation towards the Server cert purchaser
to provide this service, and the Server operater can select a suitable
CA with an OCSP service quality and connectivity that meets the servers
expectations.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 7 Nov 2011 13:49:22 -0500

I have proposed essentially that model a few times in the past couple of
years.

The problem seems to be with the download of the cert and installation into
the server which has to be completely automated if that type of scheme was
to work. Umm much like an OCSP token...

Now given where we are, there are practical problems with that model. Most
of the browsers will go demand an OCSP token in any case.

But maybe if the browsers (etc.) recognized short lifetime certs as such
and were willing to special case them now then we could start using that
model a few years down the line.

Right now the practical disadvantages are problematic. But looking at where
we will be in ten years time with most Web servers hosted on short term
cloud services. Well maybe long term certs won't make any sense at all.

I don't want to end up in a situation where the customers are requesting
short term certs so they can manage their cloud exposure but having to
validate the cert chains anyhow.

On Mon, Nov 7, 2011 at 7:32 AM, Peter Sylvester
<[email-masked]>wrote:

> ______________________________**_________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/pkix<https://www.ietf.org/mailman/listinfo/pkix>
>

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

---

From: "Miller, Timothy J." <[email-masked]>
Date: Mon, 7 Nov 2011 19:14:41 +0000

>I have proposed essentially that model a few times in the past couple of

Microsoft has this model in deployment.  Look up Network Access Protection
with health certificates.

>model a few years down the line.

No "special case" is required.  The browsers may need additional
enrollment capabilities, but that doesn't require special handling of the
certificates themselves.  There is no technical difference between a cert
valid for a year, a month, a day, or a minute.

-- T

---

From: Martin Rex <[email-masked]>
Date: Mon, 7 Nov 2011 21:04:56 +0100 (MET)

> one day or so. ? Where is the need for OCSP in that case?

Frequently changing server certificates are a serious problem
with cert pinning, i.e. sensible TLS clients warning about servers
that change their certificate whenever they change it.

And I do not know how many TLS (server) implementations support
transparent "inflight" update the server credential, i.e. while the
server is up and running and has active connections with the current
credential ongoing.

-Martin

---

From: "Miller, Timothy J." <[email-masked]>
Date: Tue, 8 Nov 2011 12:43:56 +0000

>server is up and running and has active connections with the current

IIS tries to do this, but making it work without service interruption
required auto-enrollment and a non-busy CA.  Usually a service
interruption results.

-- T