[cabfpub] CABF role for anti-spoofing certificates

[Tony Rutkowski]

Hi Richard,

You provide a helpful overview, and this list was only
intended as a place to start.  If there is interest, it should
be moved to an appropriate sub-list/group.

EVs in their present form are indeed not appropriate.
However, with modifications, the specification could
serve that purpose.  The present stir certificate Internet
Draft is in a rather woeful state, and if nothing else, borrowing
entire sections from the EV specification would improve
the draft.

As you note, the deployment model is controlling.  We're
dealing here with the original most regulated domain name
system in telecommunications - the E.164 global numbering
domain hierarchy.  How one binds certificates to those domains
worldwide is a major TBD.

--tony

On 2016-08-28 7:05 PM, Richard Barnes wrote:
> To Tony's question, "Why not EV?", the answer is simple: EV doesn't 
> make the attestation that STIR needs.  It might be useful in 
> combination with some other technology, but it is not a solution itself.
>
> Now as to how this relates to CABF, a lot of it depends on the model 
> in which STIR is deployed.  In the "authoritative" model, where the 
> holders of blocks of TNs are the CAs, there is probably not a need for 
> anything like the BRs.  The RPKI, which follows this model for IP 
> addresses, has gotten along fine without such rules.   In the "EV" 
> model, where TNs are only authenticated indirectly, STIR actors can 
> just use normal EV certs.
>
> The only scenario where I see a need arising for some sort of CABF 
> work is if we end up in a situation like the web, where third-party, 
> non-authoritative CAs are attesting to possession of TNs (as is done 
> with domain names today).  If this situation arises and there is a 
> need for some BR-like rules in this space, then we will need to 
> address many of the same governance questions as with code signing, 
> email, etc. -- who are the right CAs and relying parties to have 
> collaborate on these new rules. In any case, my personal read of the 
> situation right now is that this is the least preferred scenario among 
> the various parties currently involved.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160829/ad13b062/attachment-0003.html>