On Mon, Nov 03, 2008 at 02:47:02AM -0600, Nicolas Williams wrote: > On Mon, Nov 03, 2008 at 11:10:20AM +1300, Brian E Carpenter wrote: > > Comments: > > > > Here, then, is a generic re-statement of this structure, in pseudo- > > ASN.1: > > > > What's pseudo-ASN.1? This is normative, so why isn't it ASN.1? > > RFC2743 lays out the *abstract* API for "generic security services". > > RFC2743 uses "pseudo-ASN.1". > > I kept the style of RFC2743.
I should add a bit more about RFC2743 here. RFC2743 uses pseudo-ASN.1 for two distinct things: - To specify a small amount of on-the-wire bits. For this true ASN.1 and DER would have been better, of course. - To specify the types of function input arguments and output results. RFC2743 uses only "scalar" (in the Perl5 sense) or simple (in the ASN.1 sense) types. Everything's an OCTET STRING, an OBJECT IDENTIFIER, an INTEGER, or some type made up for RFC2743 (e.g., CREDENTIAL HANDLE). RFC2744 changed the type of one argument, channel bindings, to be structured, no longer scalar. This I-D uses pseudo-ASN.1 to model that now-structured view of channel bindings imposed by RFC2744. This I-D also provides an encoding for this structure, but the encoding is not a ASN.1 encoding (not BER, DER, CER, PER nor XER). The chosen encoding (from RFC1964/RFC4121) is not one of the standard encoding rules of ASN.1 because there already exist implementations of the chosen encoding -- we're promoting code re-use. Mechanism designers are, however, left to choose their own encoding if they don't like the one from RFC1964/RFC4121. Nico -- _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
