[gnso-rds-pdp-wg] Use case for WHOIS/RDP

[Rod Rasmussen]

> On Aug 15, 2016, at 3:58 PM, Ayden Férdeline <icann at ferdeline.com> wrote:
> 
> The key point I was raising was that there isn’t a difference between the encryption keys of domain-validated certificates, be they issued by Let’s Encrypt or a paid CA. The level of encryption is the same. That being said, I would like to return to my question about the use case itself: how could the CAs accomplish their desired task if, theoretically, the RDS could not accommodate their needs in the same manner that the WHOIS protocol does at present?
> 
> - Ayden
> 
>> 

That’s an interesting mental exercise, as what the CA’s basically do is tie a domain name to an entity using an authoritative source - exactly what whois is today and an RDS would be in the future (in theory).

Off the top of my head, without some sort to published (public, gated or otherwise) authoritative source, you’d have to either A) involve the registrar for the domain in the process, since they would be the only entity with “ground truth” data available, or B) do some sort of issuance of a token that could be authenticated in some sort of new PKI scheme using the domain name itself to establish authority for that domain.  Ostensibly in either case, you would have some way to transfer the necessary level of validation information to satisfy the CA to issue the CERT.  In case A, you’d need a whole new set of processes that would heavily involve registrars and would have to do a lot of certification work for registrars in their systems, practices, and personnel, and there would definitely be a technical lift to implement systems. I think registrars may have a lot to say about that idea.  Oh, since many of them sell CERTs in their normal course of business, you may have some conflicts of interest to deal with potentially.  In case B, you would have to create an entirely new encrypted identity management regime attached to domain names that was universally accepted, and of course, kept current with protection against cracking etc.  Not quite a moon shot, but definitely a heavy lift.  Let’s just say that removing the ability to authenticate control/ownership of domains used for CERTS from an RDS system of the future would be a major disruptive force.  Would be interesting to see if there would be some other ways to map domains to control and/or ownership without the use of an RDS, but of course, by definition, an RDS provides this capability if it has the data available, and is thus the most efficient manner for doing so.

Oh, speaking to the website idea, besides the circular logic bomb of trying to get authenticated information to issue a CERT for a domain off of a website that doesn’t have a CERT yet, another important consideration that I will remind folks of Internet > Web.  You need CERTs for non-web applications, and cannot assume that there is a website tied to a domain name at all.

I would also note that not all domains require a CERT, but for those that do, they would want to use an efficient system for obtaining one.  We thought of this in the EWG and proposed an actual CERT role as one of the contacts which you could optionally publish the necessary contact information for whatever is required by a CA.  If the CA needs ownership information for EV - that’s fine, just make sure it’s published, or at least obtainable by an entity with the proper credentials to access that information in the system.  We even proposed a system for allowing controlled release of contact information, so that one could make a request for the data, and the person/entity that controls that data can provide permission at that time to that requestor.  That could fit the CERT issuance use case quite nicely, since the current CERT issuance workflow has such back-and-forth messaging confirmation and authentication already built in.  So I will point out again that a lot of work on alternative methods for obtaining data needed for various roles with different levels of consent by the “owners” of that info was covered by the EWG report that shows ways past the current collect all/publish all system.

Rod

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20160815/b3501f7b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20160815/b3501f7b/signature.asc>