Subject: WGLC on draft-ietf-pkix-new-asn1-05.txt

From: Stefan Santesson <[email-masked]>
Date: Thu, 09 Jul 2009 03:06:41 +0200

Initiating WG last call on draft-ietf-pkix-new-asn1-05.txt
Last call ends on Friday July 24.

/Stefan

---

From: "Charles W. Gardiner" <[email-masked]>
Date: Fri, 10 Jul 2009 11:57:11 -0400

My apologies for responding so late about this draft, but I have only 
recently had enough time to study carefully its implications for updating 
our ASN.1 "compiler" to accept the new notation.  So far I have several 
concerns:

1. The files PKIXExplicit88 and PKIXImplicit88 import things from each 
other, creating an importing "loop".  This upsets the creation of ".h" 
files for C or C++ programs.  The looping can be prevented in the ".h" 
files with "#ifndef" statements, but the precedence of definitions will not 
always be correct.  This problem could be solved quite easily by taking 
some things out of either or both files and putting them in one or more 
other files which the PKIX*plicit88 files could import.

2. The ParamOptions described in AlgorithmInformation is not much use to a 
computer.  Translating the shades of necessity to numbers does not help 
either, particularly as the numbers are not in order of necessity.  (What 
percentage of messages having parameters should be rejected if the 
preferredAbsent option is specified?)  Most of the options offered, namely 
required, absent and optional, can be achieved by choosing an appropriate 
form of the PARAM statement: for required, just give the TYPE; for absent, 
omit the PARAM statement completely; and for optional, use ARE OPTIONAL in 
the PARAM statement.  Perhaps inheritable could be dealt with by a variant 
of the ARE statement, or maybe that condition is implied by OPTIONAL.

3. The disambiguation of SignatureAlgs and PublicKeys by the use of the 
file names, e.g PKIXAlgs-2008.SignatureAlgs, seems like a significant 
extension of the language.  Other cases use the name of a construct, as in 
the definition of SingleAttribute where it says ATTRIBUTE.&Type, but file 
names only appear in IMPORT statements.  Is this use of the language 
allowed in those difficult X68* documents? It might be simpler to change 
the names of the ambiguous terms in one case, e.g. SignatureAlgsOAEP 
(assuming that PKIXAlgs-2008 came first).  Or maybe both should be changed.

4. PKIXExplicit88 has the statement "AttributeType ::= ATTRIBUTE.&id".  Why 
not simply say AttributeType ::= OBJECT IDENTIFIER"?  This is a minor 
point, but it seems to me that the present wording requires extra work by a 
computer or by a person trying to understand what is meant.  The simpler 
description is used in many other places, so why not this one?

     The draft document certainly takes advantage of the abstractions 
allowed by the 2002 notation, and in some ways makes things more 
comprehensible -- once one masters the lingo.  I think attention to the 
points noted above would make the document easier to use by machine.

Charlie Gardiner

---

From: "Jim Schaad" <[email-masked]>
Date: Sun, 12 Jul 2009 07:49:00 +0300

Please see the comments embedded in the message.

> -----Original Message-----
> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Charles W. Gardiner
> Sent: Friday, July 10, 2009 6:57 PM
> To: Stefan Santesson; [email-masked]
> Subject: Re: WGLC on draft-ietf-pkix-new-asn1-05.txt
> 
> 

We have not introduced any new looping in the PKIX 5280 ASN.1 modules.
These modules have long had such loops in them.  If you go to a larger set
of modules to compile you will find even worse looping may occur.  Any ASN.1
compiler must be able to deal with this looping when doing emissions to .h
files.

> of the ARE statement, or maybe that condition is implied by OPTION

We could order the values of ParamOptions if desired, however I do not
actually see any benefit to doing so.  No message should be rejected on
decoding when preferredAbsent is the value (the parameters should be decoded
and used), however when messages are encoded then the parameters should be
omitted.  The presence if this value in the object definition is to deal
with the text which says "the parameters for an algorithm have the type
NULL, the parameters SHOULD be omitted, but you MUST accept the parameters
if they are present."  This is, unfortunately a very common construction and
we need to represent this so that code can be written by the user (not the
compiler) that can correctly deal with it.  Having it emitted from the ASN.1
module rather than hand extracted from the text makes this more consistent.

> (assuming that PKIXAlgs-2008 came first).  Or maybe both should be

We looked at doing this both ways, that is using a single common name and
requiring the prefix of a module, and using distinguished names for each
module.  I finally decided that the use of a single common name makes it
clearer what the Object Set is used for and that clarity was worth requiring
that the module name (as defined in the import statement) be prefixed on the
single common name.

Please note that the reference to a variable as module.name was defined as
an acceptable part of the language in the 1988 ASN.1 syntax, while it was
not frequently used, it has always been in the language definition.

> description is used in many other places, so why not this one?

I might be willing to think about this type of change for the benefit of a
person, but not for the compiler. Taking your logic one step farther it
would make sense to eliminate the use of AttributeType and just use OBJECT
IDENTIFIER wherever AttributeType is used.  This would make it even easier
for the person reading the module.  This is one change that could be made,
however I don't know that I see a real benefit to making the change.

> points noted above would make the document easier to use by machine.

Jim Schaad

---

From: Kurt Zeilenga <[email-masked]>
Date: Sun, 12 Jul 2009 05:38:34 -0700

On Jul 11, 2009, at 9:49 PM, Jim Schaad wrote:
>>
>> 4. PKIXExplicit88 has the statement "AttributeType ::=  
>> ATTRIBUTE.&id".
>> Why
>> point, but it seems to me that the present wording requires extra  
>> work
>> by a

X.501(2008) uses:
   AttributeType  ::=  ATTRIBUTE.&id

Using
   AttributeType ::= OBJECT IDENTIFIER

in the PKIX module would, I think, would be confusing to readers of  
both specifications.  Consistency is a good thing.

Regarding other issues raised, I generally agree with Jim's response.   
In summary, I oppose making changes in response to Charlie's comment.

-- Kurt

---

From: Sean Turner <[email-masked]>
Date: Tue, 14 Jul 2009 09:37:37 -0400

We need to align ECParameters with RFC 5480.  PKIX agreed to comment out 
  the specifiedCurve and namedCurve choices.  I leave the choice to you 
as to which way you'd like to fix it (though I tend to lean towards the 
1st):

ECParameters ::= CHOICE {
  namedCurve      CURVE.&id({NamedCurve})
  -- implicitCurve   NULL
  -- specifiedCurve  SpecifiedECDomain
  -- implicitCurve and specifiedCurve MUST NOT be used in PKIX.
  -- Details for specifiedCurve can be found in [X9.62].
  -- Any future additions to this CHOICE should be coordinated
  -- with ANSI X.9.
}

or

ECParameters ::= CHOICE {
  namedCurve      CURVE.&id({NamedCurve}),
  implicitCurve   NULL,
  specifiedCurve  SpecifiedECDomain
  -- specifiedCurve MUST NOT be used in PKIX.
  -- Details for SpecifiedECDomain can be found in [X9.62].
  -- Any future additions to this CHOICE should be coordinated
  -- with ANSI X.9.
}
WITH COMPONENTS {namedCurve PRESENT}

spt

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 21 Jul 2009 14:22:56 -0700

The advantage of using the second option is that certificates which use the,
for PKIX, deprecated options would still decode correctly.

The disadvantage of using the second option is that a small piece of ASN.1
in the CMS world would need to be modified for some obsolete text where a
NULL was permitted in an AlgorithmParameter to say that the same EC
parameters were being used (rather than being in some way implicit).

My personal preference is the second option merely because it is the least
restrictive, but I would be willing to accept either one.

Jim

> [email-masked]] On Behalf Of Sean Turner
> Sent: Tuesday, July 14, 2009 6:38 AM
> To: [email-masked]

---

From: "Charles W. Gardiner" <[email-masked]>
Date: Wed, 22 Jul 2009 10:48:38 -0400

>Please see the comments embedded in the message.

<snip>

>compiler must be able to deal with this looping when doing emissions to .h

     Alas, I see that X68* does not prohibit looping,so I'll go along.

>module rather than hand extracted from the text makes this more consistent.

     The suggestion of accepting one thing when decoding and creating 
another when encoding sounds a little like a distinguished encoding rule, 
but it is not in X690.  Won't it create problems in validating signatures 
if one decodes a certificate and then encodes the ToBeSigned part (perhaps 
changing the parameters) to make a hash?  It sounds like something that 
might be a source of trouble as well as something that requires special 
treatment beyond what X68* specifies.

     While on that part of the files, I think the CERT KEY USAGE syntax is 
somewhat baffling, because there is no way AFAIK to express in ASN.1 how to 
get from, say, SubjectPublicKeyInfo to the Extension for KeyUsage.  It 
looks like another case where a person might figure it out but a computer 
can't without some special code for just that situation.

>not frequently used, it has always been in the language definition.

     OK, I see it is allowed.

>person, but not for the compiler.

     Wouldn't it help the compiler, too?

>Taking your logic one step farther it
>however I don't know that I see a real benefit to making the change

     Making it even easier sounds useful.

Charlie Gardiner

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 22 Jul 2009 09:57:32 -0700

See embedded comments

> From: Charles W. Gardiner [mailto:[email-masked]]
> Sent: Wednesday, July 22, 2009 7:49 AM
> To: Jim Schaad
> Cc: Stefan Santesson; [email-masked]
> Subject: RE: WGLC on draft-ietf-pkix-new-asn1-05.txt
> 
> > > 2. The ParamOptions described in AlgorithmInformation is not much
> use
> > > to a
> > > omit the PARAM statement completely; and for optional, use ARE
> OPTIONAL
> > > in

Both of these constitute META-DATA.  As such it does not directly change how
the encoding, decoding or compiler generated validation is done.  The data
is provided in the module, in a usable form for user code, so that the code
writer does not need to search through the text of the document to find the
same data. 

In terms of how it would be used, consider how one should encode the SHA-1
hash algorithm identifier.  Depending on the document one is reading, it
says either omit the parameter or encode NULL as the parameter.  Having the
information available as part of the meta-data generated by the compiler
allows for code to determine which usage is to be done for a specific
encoding of the SHA-1 hash algorithm.  Having this data generated makes it
easier to be consistent and more correct on such usage.

> > > extension of the language.  Other cases use the name of a
> construct, as
> > > in
> > > the definition of SingleAttribute where it says ATTRIBUTE.&Type,
> but
> > > file

It makes absolute no difference to my compiler which way it is encoded for
some things, but for some other things it might make a difference.  The
folding of types is done differently for basic types and for types in
restrictions.  I would need to go back and do some careful reading to make
sure that it would all be kosher.   However given that this is the "normal"
way to represent the type information I would lean to leaving it as it is.

Jim

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 29 Jul 2009 11:02:42 +0200

It is my interpretation of the last call discussion that all comments have
been dealt with and that we are ready to hand this document over to the
IESG.

/Stefan