Subject: Re: [Ietf-krb-wg] Review of draft-sorce-krbwg-general-pac-02

From: Nico Williams <[email-masked]>
Date: Tue, 5 Jul 2011 15:38:43 -0500

On Tue, Jun 21, 2011 at 10:20 AM, Cantor, Scott E. <[email-masked]> wrote:
>>>It is worth noting that the SAML Assertion element has the semantics
>>> described in section 5.1 ("PAD Format"); consequently, in principle a
>>>SAML
>>> attribute assertion could be used as the PAD payload.
>
> Perhaps somebody should simply define an ASN.1 encoding for SAML
> assertions.

Well, there's XER (XML encoding rules for ASN.1) and FastInfoSet,
which is an application of PER (ASN.1 Packed Encoding Rules) to an
ASN.1 module derived from an XML schema.  Thus it's possible to
convert between ASN.1 and XML.

The key issue is: does the necessary toolchain exist?  Probably not.
I believe the right thing to do here is to use ASN.1 with DER, because
we have tools for that (e.g., Heimdal's ASN.1 compiler).

> The encoding is unimportant. The semantics are where all the interesting
> code lives.

+1, though I'll add that the availability of tools is an important factor.

Nico
--
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: "Cantor, Scott E." <[email-masked]>
Date: Tue, 5 Jul 2011 20:45:49 +0000

>we have tools for that (e.g., Heimdal's ASN.1 compiler).

Since you were responding to my comment, let me note that what I was
advocating was NOT an encoding of XML into ASN.1, but an encoding of an
existing assertion format into ASN.1, so that the semantics would be
consistent.

If the data is, well, just data, then there are no semantics other than
within the attribute data elements themselves (which in SAML is left to
the definition of those attributes).

-- Scott

---

From: Nico Williams <[email-masked]>
Date: Tue, 5 Jul 2011 16:07:52 -0500

> existing assertion format into ASN.1, so that the semantics would be

What's the difference?  A mapping of XML onto any ASN.1 encoding rules
would give you the same data encoded differently, with no semantics
difference at all (since the data is the same once decoded).

Nico

---

From: "Cantor, Scott E." <[email-masked]>
Date: Tue, 5 Jul 2011 21:14:22 +0000

On 7/5/11 5:07 PM, "Nico Williams" <[email-masked]> wrote:
>What's the difference?

Space mainly, which is what you were worried about.

I could show you what lossless XML -> JSON looks like as compared to
actually expressing the same content directly. I'm sure it would be
similar here.

-- Scott

---

From: Nico Williams <[email-masked]>
Date: Tue, 5 Jul 2011 17:24:38 -0500

> actually expressing the same content directly. I'm sure it would be

Just to be clear I think you thought I was proposing an ASN.1 encoding
that applies to any XML, whatever its schema, while you're proposing
that the schema be mapped to an ASN.1 module and the data re-encoded?
Correct?  But I had the latter in mind (I'm not that familiar with
FastInfoSet, so it's possible I misinterpreted the nature of
FastInfoSet).

In any case, I think it's safe to say that we agree that the encoding
ought to be one of the traditional ASN.1 encoding rules, specifically
DER, for two reasons: a) it's less chatty, b) it's what Simo and other
implementors have tools to work with.

Nico

---

From: "Cantor, Scott E." <[email-masked]>
Date: Tue, 5 Jul 2011 23:32:00 +0000

>FastInfoSet, so it's possible I misinterpreted the nature of

Yes, that's what I meant.

>implementors have tools to work with.

I understand the arguments for ASN.1, just like I'm sure people would
understand why nobody outside of such environments is going to start using
it now.

I'm simply saying that if people are going to dismiss other standards on
the basis of encodings, then I'd rather common semantics be adopted in a
new encoding than create new semantics.

-- Scott