Subject: RE: Comments on Draft-ietf-pkix-asn1-translation

From: "Carl Wallace" <[email-masked]>
Date: Tue, 28 Jul 2009 10:19:16 -0400

Thanks, Jim.  I accepted all of your suggested text and will address ANY
and the integer option of ANY DEFINED BY.  There were three comments I
didn't quite follow.

Section 2.1.2 - The SubjectPublicKeyInfo one is a strained example.  It
assumes that one actually understands the structures from RFC5280.  i.e.
no similar comment to the extnValue case and the adjacent OCTET STRING
cannot been seen.

[CRW] I don't understand your point.  Would you prefer a DSA signature
value as an example or maybe an ASN.1 dump?

Section 2.1.2 - The example might be more interesting if you actually
dumped the Extension object - thus seeing the OCTET STRING wrapping.

[CRW] The example is a dump of the extension, including the OCTET
STRING.  Would you prefer it be scoped just to the OCTET STRING?

Section 2.2.3 -
   The example of the BIT STRING does not have a constraint on it.  You
could refer the the example just above.
   
[CRW] The lack of a constraint is noted in the text describing the
example, which is demonstrating usage of prose as a means of
constraining the value.  The purpose of the example is to show that a
constraint cannot be specified relative to a field within the
AlgorithmIdentifier structure.

> -----Original Message-----
> From: Jim Schaad [mailto:[email-masked]]
> Sent: Tuesday, July 28, 2009 2:50 PM
> To: Carl Wallace
> Cc: 'Charles W. Gardiner'; [email-masked]
> Subject: Comments on Draft-ietf-pkix-asn1-translation
> 
> Sorry I did not get to this sooner, I completely missed the
publication
> announcement and did not realize that it had been put out.
> 
> New Paragraph for section #1.
> 
> Transforming a new ASN.1 module to an older ASN.1 module can be
> performed in
> a fairly mechanical manner, much of the transformation consists of
> deleting
> new constructs.  Transforming an older ASN.1 module to a newer ASN.1
> module
> can be done fairly mechanically, if one does not wish to move many of
> the
> constraints that are contained in the prose into the ASN.1 module.  If
> the
> constraints are to be added, then the conversion can be a complex
> process.
> 
> Section 1.1 - Delete paragraph #1 - I think that the only place where
> you
> have these keywords is in the examples, an as such it does not make
> sense to
> have the compliance terms defined.
> 
> Section 2.1.1 - ANY DEFINED BY can use either an OBJECT IDENTIFIER or
> an
> INTEGER as the identification field.  (See ExtensionAttribute in
> RFC5280.)
> 
> Section 2.1.1 - Need to talk about a plain ANY - see RFC5280
> AttributeValue
> 
> Section 2.1.1 - s/does not provide a means/does not provide a formal
> means/
> 	New sentence:  Any associations are done in the comments of the
> module and/or the text of the associated document.
> 
> Section 2.1.2 - The SubjectPublicKeyInfo one is a strained example.
It
> assumes that one actually understands the structures from RFC5280.
> i.e. no
> similar comment to the extnValue case and the adjacent OCTET STRING
> cannot
> been seen.
> 
> Section 2.1.2 - The example might be more interesting if you actually
> dumped
> the Extension object - thus seeing the OCTET STRING wrapping.
> 
> Section 2.1.3 - I want to change the intro here a bit.
> 
> Information object classes are defined in [].  Object classes allow
> protocol
> designers to associated pieces of data that are in some way
associated.
> In
> the most generic of terms, an Information Object class can be thought
> of as
> a database schema, with Information Object Sets being instances of the
> databases.
> 
> Unlike type definitions, object classes with the same structure are
not
> equivalent.  Thus if you have:
> 
>     FOO ::= TYPE-IDENTIFIER
>     BAR ::= TYPE-IDENTIFIER
> 
> FOO and BAR are not interchangeable.
> 
> TYPE-IDENTIFIER is one of the predefined information object classes in
> Annex
> A of [].  This provides for a simple mapping from an OBJECT IDENTIFIER
> to a
> data type.  The tag UNIQUE on &id means that this value may appear
only
> once
> in an Information Object Set, however multiple objects can be defined
> with
> the same &id value.
> 
> Section 2.2.2 -
> 
>    Component relation constraints are often used to bind the type
field
>    of an open type to the identifier field.  Using the binding in this
> ways
> allows for
>    a compiler to immediately decode the associated type when the
> containing
> structure is defined.  The following example from
>    [RFC2560] as updated [I-D.ietf-pkix-new-asn1] demonstrates this
>    usage.
> 
> Section 2.2.2 -
> 
> In this example, the responseType has a simple constraint applied to
it
> while the response field is constrained to contain a type
>    identified by the responseType field.  The controlling field is
> identified
> 
> 
> Section 2.2.2
> 
> For example, the following example includes invalid
>    atNotation in the defintion of the signature field within the
SIGNED
> paramterized type.
> 
>  Section 2.2.2
> 
>    In the above example, the outermost SEQUENCE, SET or CHOICE
relative
>    to the parameters field is the structure named ToBeSigned.
> 
> 		- the structure is NOT named ToBeSigned.  The type is
not
> actually named, but would probably be best referred to as the SIGNED
> type
> (or SIGNED parameterized type).
> 
> Section 2.2.3 -
>    The example of the BIT STRING does not have a constraint on it.
You
> could refer the the example just above.
> 
> 
> Section 4.1 and Section 4.2
>   We need to have some level of checklists at this point which allows
> people
> to know what they needed to be doing.
> 
> 4.1
> 1) Remove all Information Set Class, Information Set Object and
> Information
> Set Object Set definitions and imports from the file.
> 
> 2) Replace all fixed Type Information Set Class element references
with
> the
> fixed type.
> 
> 3) Delete all simple constraints
> 
> 4) Delete all CONTAINING statements
> 
> 5) Convert the remaining Content Constraints into either ANY or ANY
> DEFINED
> BY statements.
> 
> 6) Remove version and extension markers
> 
> 7) Hand instantiate all instances of parameterized types.
> 
> 
> 4.2  Simple
> 
> 1) Use TYPE-IDENTIFIER.&Type for "ANY"
> 
> 2) Use TYPE-IDENTIFIER.&Type for "ANY DEFINED BY ..."
> 
> 4.2  Complex
> 
> 1)  Identify each unique class that should be defined based on what
> types of
> things exist.
> 
> 2)  Define an Information Object Class for each of the classes above
> with
> the appropriate elements.
> 
> 3)  Define the all of appropriate Information Object Sets based on the
> classes defined in step 2 along with the different places that they
> should
> be used.
> 
> 4)  Replace ANY by the appropriate class and variable type element.
> 
> 5)  Replace ANY DEFINED BY with the appropriate variable type element
> and
> the components constraint.
> 
> 6)  Add any simple constraints as appropriate.
> 
> 7)  Define any objects and fill in elements for object sets as
> appropriate.
> 
> 
> There is probably more -- but this is a good first cut.
> 
> Jim
> 
> 
>