Subject: [lamps] Early discussion of First Issued/Member-Since

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 29 Jun 2017 12:06:52 -0400

In response to Ryan's request.

This is the first reference to it that is showing up on my mailing list
searches. There did not seem to be any comment on that part of the proposal
in that thread but it does provide a starting point for IPR Prior Art.

I am not aware of any patent claims made by myself or any other party.

My recollection is that this was not the first time I discussed it. The
only objections I recall there were:

1) This is only needed if you do short lived certs and we are not doing
that until we have an automated issue mechanism.

2) This would make CA services 'sticky' as changing CA would mean resetting
the First Issued indication.

My recollection was that the main reason for not going ahead was (1) which
is now answered (as far as IETF is concerned) by ACME.

We can address (2) while maintaining audit capability by allowing a CA to
rely on an earlier CA's First Issued if the subject provides a satisfactory
cryptographic proof they are the same party. E.g. by countersigning the CSR
with an old key.

This is one of those problems where it is a question of how many epicycles
you wish to specify and whether you wish to leave some for future work.

We have not discussed the structure of the extension. It could be merely a
simple date or it could be a date plus an explanatory attribute stating the
source of the first issued, whether this is the original key, a rekey, a
subject change or a CA change. Or perhaps it is just a list of dates using
the OPTIONAL feature of ASN.1

Adding support for short lived certs into TRANS is likely to be something
of a performance in its own right when the time comes. While it is not
necessary to provide any support at all, there is an obvious advantage to
not cluttering up the logs or in splitting up the logs so that there are
verbose and redacted versions.

I see First Issued as potentially a piece of mechanism that might prove
useful if we get to that problem rather than a reason to tackle it.

---------- Forwarded message ----------
From: Phillip <[email-masked]>
Date: Mon, Mar 25, 2013 at 12:44 PM
Subject: Re: [cabfpub] OCSP Stapling and Short-Lived Certificates Proposal
To: [email-masked]

Let us look at the situation in the most abstract terms possible. There are
three types of information that might affect the client's decision to
accept a certificate and present an assurance to the user (i.e. padlock or
green bar):

* The first date on which the subject was validated by the issuer (aka
Member Since)
* The most recent date on which the subject was validated by the issuer
(aka Last validated)
* The most recent date at which the issuer is known to have reported valid
status (Last status)

>From a security point of view it does not matter how the information is
obtained, what matters is what information is available and how it is
processed. Right now the issue date of the cert is identical to Last
Validated which leads to the BR making particular assumptions. If that
assumption is getting in the way of making the right decision to allow
short lived certs as an alternative to OCSP then lets put that information
into a certificate extension so that a client does not lose any information
if we move to short lived certs. I would like to put Member Since and Last
Validated in the cert if they are not the same as the issue date.

Since we already allow for a delay in issue of status information it seems
perfectly acceptable to assume that cert status is valid within a short
time window of issue. If we look at what we have to do server side for OCSP
stapling and what we have to do for short lived certs it is essentially the
same. Short lived certs are simpler on the client side, only one trust
chain to check. The client could even pre-fetch status for frequently used
certs if that makes sense.

There are issues to do with time. But note that even though we are obliged
to allow for time to be out of sync on the client we can reasonably demand
that CAs are correct to within an minute. The question is how the client
should react when the status appears to be stale. There are serious issues
there but they are exactly the same regardless of the status mechanism. We
can't solve a time sync problem for short lived certs by pulling an OCSP
token as that will appear to be stale or in the future as well.

There are three questions for Last Status:

* What status mechanisms do we want issuers to support?
* What should the client do when it does not have valid status?
* What should the BR allow?

The last is not necessarily the same as first two. I think that we should
not try to force the client into any particular approach to status other
than a client should not be telling an end user a certificate is good if it
does not have recent status. Turning on SSL is fine, a client should be
able to turn on SSL any time that it would accept a raw TCP connection. But
telling the user that they are safe with either the padlock or the green
bar should not happen if the status is stale.

_______________________________________________
Public mailing list
[email-masked]
https://cabforum.org/mailman/listinfo/public