Subject: RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt

From: "David P. Kemp" <[email-masked]>
Date: Fri, 2 Jul 1999 13:32:49 -0400 (EDT)

> From: "Peter Williams" <[email-masked]>
> 
> I think the SNMP example holds here, given it
> is simple but also uses BER and a ASN.1-based notation. The full CMIF model
> was addressed by the IESG-policy and WG ethic, but reduced, and
> a simple to implement protocol was specified.  If we were to here
> use any OSI message encoding, Id have us use the SNMP BER Subset
> and have it specified in the notation used in
> the SNMP RFCs. A hundred implementations of this
> already exist; a reusable one even comes free with Windows
> and a $50  code sample book.

RFC1157 defines the BER subset as:

   Also for the sake of simplicity, the SNMP uses only a subset of the
   basic encoding rules of ASN.1 [10].  Namely, all encodings use the
   definite-length form.  Further, whenever permissible, non-constructor
   encodings are used rather than constructor encodings.

"Wherever permissible" is pretty wishy-washy language for a standard
specification; the software can't be simplified unless constructed
encodings of primitive data items are prohibited, period.

I might suggest a few additional restrictions to enable the ultimate
in simple software: no PDUs larger than 4GB (4 byte max length field),
no UNIVERSAL tags except { BOOLEAN, INTEGER, BITSTRING, OCTETSTRING,
OID, ENUMERATED, UTF8STRING, SEQUENCE, GENERALIZEDTIME },
no CONTEXT tags with a value > 30, no APPLICATION or PRIVATE tags at all.
SET is omitted to eliminate DER sorting code.  UTCTIME is omitted because
it's 1999 already.  The other string types are omitted simply because too
many choices are too many - UTF8 can encode everything without penalizing
Latin-only implementations.  I'd hate to get rid of DEFAULT and OPTIONAL
in a "tiny ASN.1" language specification, but would suggest that protocol
definitions avoid using them.

I'm not sure what you mean by the notation used in the SNMP RFCs; as
far as I can tell, it's standard ASN.1 except for a *lot* of extra
whitespace.   What RFC1157 writes as:

             Message ::=
                     SEQUENCE {
                          version        -- version-1 for this RFC
                             INTEGER {
                                 version-1(0)
                             },

                         community      -- community name
                             OCTET STRING,

                         data           -- e.g., PDUs if trivial
                             ANY        -- authentication is being used
                     }

PKIX might write as:

       Message ::= SEQUENCE {
          version     INTEGER version-1(0),  -- version-1 for this RFC
          community   OCTET STRING,          -- community name
          data        ANY }                  -- e.g., PDUs if trivial
                                             -- authentication is being used

I find the compact format more readable, but concede that indentation
and brace placement is a matter of religious preference.  Was there
anything more profound you had in mind when referring to notation?

---

From: "Peter Williams" <[email-masked]>
Date: Fri, 2 Jul 1999 11:13:41 -0500

> anything more profound you had in mind when referring to notation?

Profundity is not my style: keeping the use of SCVP syntax notation 
conforming with the style used in the various SNMP 
RFCS would be an ideal, if you all go this direction.

Unless there is a reason, use the types (and tags) pre-defined. Part
of the style benefit is that one does not invent [tagged] types when
existing definitions can be leveraged. After all, several hundred
MIBs could make do with a restricted type set.

Rather than invent a new tiny notation, perhaps just adopt the snmp
style guidelines. A whole, multi-vendor, SNMP industry already suceeded
in this adoption. And that industry, unlike PKIX, interoperates technically
in the real world.

Dont let this SNMP tack sidetrack the list from the idea that
non-BER approaches may be deemed suitable. The protocol could used
Signed XML text for the message object encoding, for all it really 
matters. Wider architectural-needs understanding and discussion
in the document may help here.

Peter.

> -----Original Message-----
> From: David P. Kemp [mailto:[email-masked]]
> Sent: Friday, July 02, 1999 12:33 PM
> To: [email-masked]
> Subject: RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt 
> 
> 
>