Re: encoding an X.509 certificate

["Tom Scavo" <trscavo@xxxxxxxxx>]

On Sat, Nov 8, 2008 at 4:17 PM, Anders Rundgren
<anders.rundgren@xxxxxxxxx> wrote:
>
> I do not fully agree with the following document:
> http://docs.google.com/Doc?id=ddj3qnj2_231hms5vtgq

Can you say why?

> A certificate should [IMO] always be decodable, and verifiable against a trust anchor, otherwise it
> is not much of a certificate.

Decodable is one thing (the only characteristic I'm interested in, in
fact) but "verifiable against a trust anchor" is quite another.  I
like to think that the certificates in this profile are "meaningless":

http://www.ietf.org/internet-drafts/draft-moreau-pkix-aixcm-00.txt

In other words, SAML holder-of-key subject confirmation does not
require an X.509-based PKI.  The goal is to cryptographically
strengthen the SAML flow.  If this can be done without assuming an
X.509-based PKI, so much the better.

Practically speaking, a typical flow is based on TLS client
"authentication."  A client presents a certificate to the identity
provider via TLS and authenticates by unspecified means.  (If the
identity provider trusts the issuer of the certificate, TLS serves
both purposes of course.)  The certificate from the TLS exchange is
the certificate "possessed" by the identity provider.

If we could limit the choices at the identity provider to one
(<ds:X509Certificate>), this would be a done deal.  Unfortunately,
that's not possible, because if there *is* an X.509-based PKI in
place, there are real use cases for the other XML elements specified
in the XML Signature spec.

Tom