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
_______________________________________________
websec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/websec
