[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [security-services] Minutes minutes SSTC/SAML concall Tue 21-Oct-2008
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]