Publishing S/MIME certificate

[LecrisUT]

I have recently come across this guide from 2015 on publishing PKI and GPG keys over DNS (implying DNSSEC as well probably), and I would like to hear your thoughts on how this would work here? Can we get the castle signed keys publicly trusted like this? And there are other GPG methods, such as this older guide for serving the keys. Are there equivalent S/MIME ones for those also, to basically just point to castle CA's public repository link, e.g. like a PKA record?

Regarding publishing the emails online, it seems that they simply do it by hashing the user part of the email. Isn't that compliant enough for the castle repository over the obfuscation?

[polhenarejos]

The whole purpose of these guides is to have a public repo of the certs. Despite the fact it is not so realistic add/modify DNS records for every email account, it does not solve the problem of verification. The problem can be solved more efficiently by setting up a server to get the public cert before the encryption at ISP level, like PGP does. If you want to send an encrypted mail to john.doe@foobar.com would be as simplest as querying to foobar.com server asking for the john.doe cert. This is not standardized but it could be.

Publishing CASTLE public keys in the DNS record would not do the trick. When browsers, email clients or Acrobat validate the signature, they use their own local trust stores. At each update, they refresh the local stores, but this is not something online. Plus, it does not add valuable trust to the chain. The trust of a signature does not come by the signer's certificate itself, but signer's certificate is trusted previously via an agreement, audit or other offline mechanisms. The only way (besides enterprise agreements) is the user trust the certificate being fully aware of it, which is translated onto accepting the cert into its own local trust store.

If the solely purpose is to verify the S/MIME certificate, it contains the URI of CASTLE public certificate, which can be used to validate the signature (it is applicable to all X509 certificates).

The public repository, like CT, does not add trust to the chain, but transparency. Adding transparency is important, specially for detecting suspicious issues to prevent fraud and hacks, but it does not replace the processes of gaining trust.

Hashing emails is useful if you want to index them. If you need only to show or display, it is enough with obfuscation. The search by email is still available without obfuscation.

[LecrisUT]

So then even if you add an SMIMEA record, acvording to the rfc, it would not be trusted unless the root certificate is also trusted?

I guess the same applies to the PGP keys, those only offer a way to auto-detect, but not automatically trust it. Still, there are no proposals to standardize an equivalent .well-known or openpgpkey.example.com?

[polhenarejos]

That's what I think. From the RFC8162:

6.  Application Use of S/MIME Certificate Associations

   The SMIMEA record allows an application or service to obtain an
   S/MIME certificate or public key and use it for verifying a digital
   signature or encrypting a message to the public key.  The DNS answer
   MUST pass DNSSEC validation; if DNSSEC validation reaches any state
   other than "Secure" (as specified in [RFC4035]), the DNSSEC
   validation MUST be treated as a failure.

   If no S/MIME certificates are known for an email address, an SMIMEA
   DNS lookup MAY be performed to seek the certificate or public key
   that corresponds to that email address.  This can then be used to
   verify a received signed message or can be used to send out an
   encrypted email message.  An application whose attempt fails to
   retrieve a DNSSEC-verified SMIMEA resource record from the DNS should
   remember that failed attempt and not retry it for some time.  This
   will avoid sending out a DNS request for each email message the
   application is sending out; such DNS requests constitute a privacy
   leak.

So, SMIMEA records are a repo for obtaining the certificate for verifying signed emails or to encrypt messages. They are not used to validate the chain nor to display the green lock. Intermediate CA certs used for signing certs are not associated to a particular email and they are not SMIME certs. Thus, they are not neither added to SMIMEA records nor TLSA, since they are not TLS certs.

To validate the chain of trust, the TXT record could be used to publish the public key/cert of the CA and intermediates via specific tag, like DKIM or SPF do. They could be used to ensure the issued cert comes from a legit CA and not from a faked CA. It would be like a SSL pining but a bit relaxed. However, it should be standardized and used by agents like Chrome, Firefox, Thunderbird or other clients.