[websec] Suggestions for Fixing PKI

[Alice Wonder <[e-mail]>]

Dear List,

This is just for thought, I have neither the resources nor energy to 
push it through.

I would use the existing DNS system to do the equivalent of OCSP stapling.

ICANN creates a new TLD, we can call it pki.

Only certificate authorities can register names in pki.

The registry `Example Certificates, LTD.' would register example.pki

Even though the system uses the DNS system, only a limited subset of RR 
types would be allowed in the pki. TLD.

For example, MX and A and AAAA records etc. should not be allowed, it is 
a utility TLD intended to serve as infrastructure.

For the serial number in the SOA record, seconds since UNIX epoch would 
be what I would suggest. As serial is 32-bit that will eventually wrap 
but DNS allows for serial to wrap. Whether it is seconds since UNIX 
epoch or something else doesn't matter but I do suggest the serial be 
standardized, and YYYYMMDDnn does not allow enough updates in a 24 hour 
period.

BIND etc. probably shouldn't be used for the master, the master should 
probably be a custom server that talks to the CA's database and probably 
shouldn't have a public facing IP address, but bind / NSD / whatever 
could serve as slaves, there is no need for non-standard RR types to be 
used and they shouldn't be used.

Each signed certificate will have a serial number assigned by the 
certificate authority. That may actually already exist. I would suggest 
they be ASCII characters <= 63 with existing DNS label limitations, but 
no need for hostname restrictions. For example d3we74ldqw1190 could be a 
valid serial number. The serial number should be included in the signed 
TLS certificate.

For each valid certificate, the DNS server will respond as an 
authoritative DNS to a request for a TXT record of the serial number. 
For example:

     dig TXT d3we74ldqw1190.example.pki. +short

would then get the rdata for that certificate, with a record that can be 
DNSSEC validated, if the certificate is valid.


If the certificate is revoked, I *might* get a DNSSEC signed response. 
If the certificate was never issued then I would get a DNSSEC signed 
response stating is does not exist. NSEC is probably good enough for 
that, doesn't need the complexity of NSEC3 IMHO.

For the rdata - it should include the OCSP uri, timestamp, and whether 
or not the certificate was valid at the time of the timestamp.

TLS clients could then validate a certificate by doing a simple DNS 
query. If they don't get a DNSSEC validating response, they fall back to 
using the OCSP URI provided in the certificate.
If they get a validating response stating the record does not exist, 
they reject the certificate.
If they get a validating response stating the record does exist but the 
certificate has been revoked, they reject the certificate.
If they get a validating response stating the record does exist and the 
certificate was not revoked, the client can then look at the timestamp 
and if it is recent enough - accept the certificate, otherwise do the 
OCSP lookup itself.

This would solve the problem of certificate authorities having the 
ability to track users, because the client would be using their local 
recursive resolver to query for the information. It would also solve the 
problem of a sudden spike at a web site radically increasing traffic at 
the certificate OCSP server, because the local resolvers would cache the 
requests until the TTL expires.

Obviously this solution needs more details and someone to take the idea 
to the appropriate powers, but that is how I would solve the revoked 
certificate problem if I was emperor of the Internet.

I would personally limit the RR types to SOA, TXT, RP, and the DNSSEC RR 
types, and DNSSEC should be required. But there may be valid reasons for 
some other RR types. I would suggest that CAs push updates to the slaves 
every 5 to 10 minutes. For the TTL on TXT records, 1800 would be what I 
would use but it seems to me like a lot of resolvers ignore that and 
make up their own TTL. For the negative TTL I would suggest 120 seconds. 
But really until this is implemented those are just numbers, real usage 
will help refine them.

Thank you for your time,

Alice Wonder