Subject: [xmpp] Thoughts on ACDNA vs XDNA

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 15 Jan 2010 12:21:01 -0500

(starting a new thread because I'm just getting around to  
subscribing...)

To support the discussion of DNA via ACs (call it ACDNA) or via XML- 
based assertions (call it XDNA), here's a side-by-side comparison of  
the common operations:

ACTORS: Customer, Origin Hosting Provider (HP), Relying Hosting Provider

ADD
-- ACDNA: Customer creates AC and provides it to Origin HP
-- XDNA:
	-- Customer stores XML assertion at verification URI
	-- Customer provides verification URI to Origin HP

AUTHENTICATE
-- ACDNA: 
	-- Origin HP sends assertion with AC as proof
	-- Recipient HP validates AC
	-- Recipient HP compares public key in cert to public key in TLS
-- XDNA:
	-- Origin HP sends assertion with verification URI as proof
	-- Relying HP accesses verification URI to get HP-ID
	-- Relying HP compares HP-ID to authenticated ID of Origin HP

REMOVE / REVOKE
-- ACDNA: No revocation defined, only expiry
-- XDNA: Customer deactivates verification URI

In terms of their requirements, the two options are mostly the same.   
In both cases, the Origin HP has to store additional Customer state  
(verification URI or AC), and the Origin HP sends the same XMPP  
messages to the Relying HP (modulo a few bytes).  All parties have to  
have domain certificates in both cases.  I'm fairly well convinced  
that they have the same security properties.

The trade-off seems to be between computation and traffic: In ACDNA,  
the Customer has to produce an AC and the Relying HP has to validate  
it.  In XDNA, the Customer has to operate a web service that serves up  
the verification URI over HTTPS, and the Relying HP has to access that  
URI.

This arrangement seems to me to increase the burden on the Customer,  
since he now has to operate a web service and do crypto every time his  
domain is presented -- no just once to create an AC.   The exchange  
here is between one-time burden of implementing AC creation/validation  
(which can be spread across multiple users) and an ongoing burden of  
operating a validation URI.  XDNA also makes Hosting Providers reliant  
on their Customers to properly operate web servers so that their XMPP  
services function properly.

Net of all that, the AC solution seems better to me.
--Richard

---

From: Dave Cridland <[email-masked]>
Date: Fri, 15 Jan 2010 23:04:05 +0000

> -- ACDNA: No revocation defined, only expiry

No, revocation is also defined, as I understand things, and operates  
by the same essential means as Public Key Certificate revocation.

So there is both "Expiry" and "Revocation", meaning there is *also*  
an online hosting burden for the Customer. However, there's also a  
defined case for what happens when you cannot obtain the revocation  
status of a particular cert.

That said, the crypto cost is low, and the hosting burden can easily  
be handed off to a third party, since you could at minimum simply  
host a CRL somewhere, and the AC itself can contain that location.  
(Possibly - perhaps the customer's signing cert does).

> -- XDNA: Customer deactivates verification URI
Again, no, I don't think that's good enough, I think you need some  
form of explicit revocation.

That in turn means you have a burden *after* you've finished with the  
hosting provider.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 15 Jan 2010 18:14:33 -0500

> by the same essential means as Public Key Certificate revocation.

Actually, the current draft says
"
The extensions field MUST include the non-critical noRevAvail  
extension, as defined in Section 4.3.6 of [I-D.ietf-pkix-3281update],  
to indicate that no revocation information is available from the  
attribute certificate issuer.
"

You could add revocation (per standard X.509 techniques, as you note),  
but it's not there now.

--Richard

---

From: Sean Turner <[email-masked]>
Date: Fri, 15 Jan 2010 22:50:04 -0500

Richard L. Barnes wrote:
> The extensions field MUST include the non-critical noRevAvail extension, 
> as defined in Section 4.3.6 of [I-D.ietf-pkix-3281update], to indicate 
> that no revocation information is available from the attribute 
> certificate issuer.
> "
> 

I put this is because RFC 3281 (and it's update) requires that the no 
revocation option must be supported.  Pointers in the AC (i.e., 
revocation information available) are a should.  I figured we should go 
with the must mechanism.

spt