On Fri, Dec 18, 2009 at 10:25 AM, Scott Cantor <> wrote:
Will Norris wrote on 2009-12-17:
> (We then had a lengthy discussion about the approaches to XRD trust,
mainly
> between Breno and Scott. There are a few holes, but I think I captured
most
> of it:)
Pretty well, I wasn't as focused as I should have been, long day of meetings
and local politics. My rants about the uselessness of PKI can be safely
ignored, the world will either continue down that rathole or not, but that's
not our problem here.
Let me try and summarize what I think was basically agreed about, and Breno
can correct me...
We do a base profile that essentially requires the signing certificate and
the XRD Subject to "match", where that implies TLS matching rules (favor URI
or DNS subjectAltName, allow CN). In the DNS case, the matching only applies
to Subject URIs that can be mapped to an http(s) URI.
The profile doesn't call out any use of X.509 extensions to allow or
disallow such signing (but other profiles may). It also doesn't call out the
certificate validation process (but other profiles may).
It also doesn't call out any transport-related requirements for the
acquisition of the XRD, but may note that risks exist if insecure transports
are used. (Note that this means the XRD could be signed by a different
certificate than the TLS certificate one might encounter when obtaining it.)
Yes, however, if the certificate used in the transport is different from the one in signing, a MitM attacker in possession of the signing certificate would be able to successfully negotiate a TLS connection, so it's unclear to me that a document signed this way is actually more susceptible to MitM attackers if not served over SSL.
It is, in other words, name matching and that's about it. But it can be
implemented by an XRD library with the signing certificate/chain exposed for
consumption by profiles layered on top of this one.
-- Scott
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
--
--Breno
+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)
