Re: [security-services] Minutes minutes SSTC/SAML concall Tue 21-Oct-2008

["Tom Scavo" <trscavo@gmail.com>]

On Tue, Oct 21, 2008 at 6:23 PM, Scott Cantor <cantor.2@osu.edu> wrote:
>
> The justification for not requiring DER is that doing so would be analagous
> to us requiring XML be encoded as UTF-8 instead of relying on the XML to
> signal the encoding used.

A better analogy is NameID/@Format =
"urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName".  The SAML
specification of that Format intentionally mirrors that of
<ds:X509SubjectName> in [XMLSig] but I claim that was a mistake.  DN
string comparisons are notoriously difficult as it is, and specifying
that a DN SHOULD conform to RFC2253 (or RFC4515 in the Second Edition
of [XMLSig]) only makes it worse.

> In the case of certificates, ASN.1 is the substrate and, I'm led to
> understand, implementations of ASN.1 libraries handle the encodings that
> people use, just as XML parsers handle the encodings that people use.

Sure, there are numerous encodings of ASN.1 structures, but I claim
that the DER encoding is the most common by far.  In any event, AFAICT
an X.509 v3 certificate is specified to be DER encoded (RFC
2459/3280/5280).  Now X.509 v3 certificates are not normatively
required in the HoK Assertion Profile, but I'd be happy to add such
language if it solves this issue regarding certificate encoding.

(Btw, I don't have access to [X509v3] referred to in [XMLSig].  If
someone has access to that spec, could they please check and see what
it says with respect to encoding?  Thanks.)

I have yet to find a library or deployment that does not rely on
DER-encoded X.509 certificates.  It seems DER is the de facto standard
encoding used by the PEM format.  The underlying encoding of every PEM
formatted certificate I've ever seen is DER.  If someone can produce a
counterexample, please do so.

> In other words, I'm told that it's left open in XMLSignature for a reason,
> and it's not clear to me why we have any better reason to constrain it than
> we would for the XML encoding.

The reason for specifying the encoding is quite clear to me at least.
If the SAML issuer is allowed to bind an arbitrarily encoded X.509
certificate to a HoK assertion, the relying party has no way of
determining what encoding was used, and therefore the relying party is
unable to confirm the subject.

> Alternatively, I guess I'd be in favor of making this a RECOMMENDED
> encoding, but doing that in SAML core itself, rather than requiring every
> profile that touches this element to repeat it.

Right, which is the same language I used in the HoK Assertion Profile
with respect to DNs, but not because I wanted to.  I would much rather
specify a DN MUST conform to RFC2253 (or RFC4515).  There's too much
variability in DN string formats to leave this open.

Tom