Subject: NR -- a CA guarantee to archive certificate status?

From: "Bob Jueneman" <[email-masked]>
Date: Mon, 23 Aug 1999 12:54:50 -0600

I believe that we are making some progress, and at least
clarifying the definition.

Because of the length of this analysis I'll again state the conclusions, 
and then provide my analysis:

"In summary, we can see that the NR bit might reasonably be used to 
denote a certificate for which the CA has accepted the responsibility to
archive the certificate status for a period of time after the expiration date.

"However, issues of retention and access to such records for longer than 
about 10 years after the scheduled expiration date would make such a reliance
problematic, given the vagaries of business and the lack of a statutory 
requirement for the transference of such records to another trusted third party."

-------

The biggest problem with the existing definition of the NR bit is that it 
ambiguously, and circularly, refers to a "non-repudiation service" 
without defining such a thing, or saying who has to do what, for whom,
for how long, etc.

Elliot has proposed what I think is a very reasonable interpretation --
the CA by setting the NR bit is saying that it will maintain an archive of
the status of that certificate for some period of time beyond the expiration date.

If that is what is meant, and there is a reasonable consensus, that's 
fine with me -- we can then go on to argue the need for other 
mechanisms to deal with the issue of rebuttable presumption, etc.,which 
should almost certainly take the form of  additional keyUsage bits.

But back to the now simplified (or at least now understood) definition of 
NR as providing a CA archive for certificate status.  We would still have 
a few questions to deal with, and I would like to see some reasonable
minimum requirements stated so that as a relying party I don't have to go
read all of the text of a CA's CPS in order to know whether I have to 
archive the certificates myself. So please bear with me as I try to
determine whether such an approach is reasonable and practical.

1.  How long will the certificates be archived?  "In perpetuity" is a very long
time, but there isn't a statute of limitations for civil reliance.  In some cases, 
in particular wills and trusts, documents could be admitted into evidence 
50 years or more after they were signed. In the case of real property, the
issue could potentially go back much, much further. (In the 1940's my 
grandmother sued the town of Cape Girardeau, MO, for not complying 
with the terms of a bequest of a significant amount of land to the town
by one of my ancestors who founded the town in the late 1700's!  Since
the bequest stated that the land would revert to his heirs and successors,
she said in effect, either use it as intended, or it's mine!)

Storage keeps getting cheaper and cheaper, but keeping up with the 
progression of technology is the challenge -- as anyone who 
needs a quad-density  5-1/4" floppy disk reader would soon discover.
It sounds funny to say it in a digital age, but probably the safest form
of archive would be a journal printed on high-quality paper and stored 
in a secure repository.  The CA's working records would presumably
be stored on disk, and updated and copied each year to keep them 
refreshed.

Assuming that perhaps 10 to 20% of all certificates are revoked for some 
cause such as a change of name or address or business relationship,
all that needs to be stored is a once a year printout of the range of 
certificate serial numbers which expired during that year,  together 
with the serial number, date, and revocation reason code for those 
certificates which were revoked during that year.  

Assuming a 10 digit serial number, a three digit date, a 1 digit reason
code, and a space per revoked certificate, that's 15 characters each.
It would certainly be possible to print 10 such fields per line, and 100
lines per page using a small but readable font, or 1000 revoked 
certificates per single-sided page. A single ream of paper (500 sheets)
would therefore suffice to hold a million revoked certificates, out of say
5 to 10 million active certificates.  Even if a CA were to issue 100 million
certificates per year, this would only amount to about ten such books 
per year, or one case of copier paper per year.

Based on this analysis, it would appear that retaining such records for 
even one hundred years would not represent an unreasonable
burden on any CA who chooses to go into that business -- 100
boxes or cases of paper stacked five high and ten wide would fit 
in a small office with plenty of room left over.

2.  The next question is what happens to such records if a CA goes 
out of business, and how to locate a particular CA that issued a 
certificate 100 years ago, whether they are still in business or not,
since it is fairly likely that various mergers and acquisitions will have
caused the CA to change their name and address multiple times.

It's clear that a CA cannot be allowed to go out of business and have
the storage company trash all of the records for failure of the CA to 
pay their storage bills if we are to rely on this mechanism!

States such as Utah that have created some form of state licensure
for Certification Authorities have typically provided for the cessation of
activities by a licensed CA, either by having some other CA or 
repository pick up the responsibility, or having the State itself act as 
the repository of last resort.  Unfortunately, most states, including for 
example Illinois, make no provision for the continuing availability
of a CA's records, and without statutory authority the state would not
be compelled to accept such records -- and especially not for unlicenced 
CAs.

Even if the State were to take over such records, practical experience 
suggests that relying on the state to actually be able to find something 
in their archives might be problematic at best -- even birth certificates 
and land records are sometimes lost.

This suggests that although it seems quite reasonable and feasible for even 
a large CA, one with hundred of millions of certificates issued each year,
to securely archive the status of those certificates for up to 100 years, 
RELYING on such a CA to stay in business for that long, or to arrange for 
some other trusted party to take over the responsibility, may be rather
unrealistic.

That being the case, we probably need to think about significantly shorter 
times periods where the archive would be guaranteed, like perhaps 
10 years after the expiration date of a certificate.  It would not be unreasonable
to require an operational CA to deposit such records with a repository, with
the storage fees for the next 10 years paid in advance.

In all probability, 10 years would cover nearly all of the real needs for the 
certificate status as of a given point in time.  And any relying party who could
reasonably expect to have to rely on a digital signature for longer than 
that amount of time would have the alternative of archiving a current, 
timestamped CRL or OCSP response along with the document in question.

In summary, then, we can see that the NR bit might reasonably be used to 
denote a certificate for which the CA has accepted the responsibility to
archive the certificate status for a period of time after the expiration date.

However, issues of retention and access to such records for longer than 
about 10 years after the scheduled expiration date would make such a reliance
problematic, given the vagaries of business and the lack of a statutory 
requirement for the transference of such records to another trusted third party.

Comments?

Bob

Robert R. Jueneman
Security Architect
Network Security Development
Novell, Inc.
122 East 1700 South
Provo, UT 84606
[email-masked]
1-801-861-7387

>>> Elliot Ginsburg <[email-masked]> 08/23/99 06:47AM >>>
Since the CA sets these bits, we have to decide what the CA is asserting
when it sets or doesn't set a bit. Just as we have decided that when the
CA asserts a policy OID, it is saying that it created this cert
according to the named policies. When I use that cert, am I asserting
something about policy because I used it? I don't know, but I do know
that the CA did make an assertion.

So what does the CA assert with the NR bit? One possibility has been
mentioned already for the meaning of the CA setting the NR bit, and that
is whether this cert can be used for non-repudiation. Its one thing,
when I get a message, to trust who sent it and the integrity of the
content; its quite another to be able to verify this five years from
now. So I, as a CA, might tell you that this cert is usable now, but
don't come back to me in five years, because I do not run a
non-repudiation service. Which would imply that if the NR is set, there
is an assertion that this cert was intended to be used for
non-repudiation and can be relied on for that, however non-repudiation
was defined in the policies of the CA. As a relying party, I will not
store this message away and assume I have proof of the signer's actions
if the NR bit is not set.

Elliott N Ginsburg
CygnaCom Solutions
[email-masked] 
703-848-0883
703-848-0960(FAX)

---

From: Ed Gerck <[email-masked]>
Date: Mon, 23 Aug 1999 12:30:39 -0700

> requirement for the transference of such records to another trusted third party."

I agree and, to be consistent and really solve the issue, I suggest that the name
NR bit needs to be changed to POA bit, as in "proofOfAuthentication bit".   This
is clearly not a "NR bit", whatever that might be.  This is a service which provides
various proofs of authentication acts done by the CA  (CA of subscriber, CA of
subscriber's private-key challenge response, CA of signing CAcertificate, CA of
cert issuance, CA of CRL, etc.)

As you say below,

> without defining such a thing, or saying who has to do what, for whom,

Let us not go into a worse mistake in the new incarnation of this issue,
by having a "NR bit" that  does not even refer to a "non-repudiation service"
and does not define such a thing, but bears the blame ;-) -- while it does a
whole lot of useful things (proof of CA authentication acts) that it would
not say.

Cheers,

Ed Gerck