On Wed, Apr 15, 2015 at 10:23:32AM -0700, Rick Andrews wrote:
> > The the CA's job, the certificate would be obtained by the customer and
> > provisioned by the customer via a customer admin portal.
>
> I think what's being asked is how would the CA do the verification before
> issuing the cert?
All the CA is ever expected to verify is that the customer in
question is the rightful "owner" of the name in the certificate.
How services associated with that name are hosted is irrelevant,
that's between the customer and service provider.
> > CAs should never issue certificates for a domain to a third party.
> > So there's nothing to standardize.
>
> We do it all the time. You outsource your web site to a hosting
> company, and the hosting company applies for and gets the cert on
> your behalf.
However common, or even essential to support various business
practices, this is rather a bad idea. It means that the whole
system is fundamentally broken. But I rant, this is going off-
topic.
The issuance of SRV-ID is no different than the issuance of CN-ID
or DNS-ID. The only new thing is that it has not been used very
much to date. Regardless of where in the certificate the name is
recorded, or the exact "type" or "format" of the name, the real
issue is supporting multi-tenant hosting of domains by other domains,
which maps poorly into the Web PKI.
This draft is just trying to limit the scope of certificates that
clients delegate to providers. DANE eliminates the need entirely.
I don't know whether SRV-ID is likely to see much adoption. It is
a logically and technically sound idea, but it remains to be seen
whether it is a practically sound idea. Ditto for DANE. So we
perhaps we just try all the approaches and see what works.
Note that SRV-ID does not displace DNS-ID or CN-ID, indeed the same
SNI domain is sent regardless. All that SRV-ID does, is *allow*
the server to respond with an SRV-ID if when that's all the hosted
provider has on hand. If the customer, provider and CA "conspire"
to provision a certificate for the entire domain (rather than a
particular service), that'll still work.
The first step is to ask RPs (Relying Parties) to accept SRV-ID
where applicable. Then hosting providers, their customers and
CAs might figure out when to provision them, subject to demand
for such services.
Will SRV-ID actually get much traction? No idea.
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
