Re: I-D ACTION:draft-ietf-pkix-rfc2510bis-03.txt (and rfc2511bis-01.txt)

["Phillip H. Griffin" <phil.griffin@xxxxxxxxx>]

Petty perhaps, but it might be nice to review 
this ASN.1 rigorously before any progression.

Just browsing through the -03 version I found 
some busted notation. The named integer values
"CMP1999(1), CMP2000(2)" should begin with lower
case letters.

And "implicitConfirm ::= {id-it 13}" should be
"implicitConfirm OBJECT IDNETIFIER ::= {id-it 13}"
and "implicitConfirmValue ::= NULL" is invalid as
well.

A good going over by an automated syntax checker 
tool such as one of the freely available ones at 
http://www.oss.com/products/syntax1.html or listed on
http://asn1.elibel.tm.fr/en/links/index.htm#tools
would probably find some things that I missed by eye.

Phil
----
Phillip H. Griffin    Griffin Consulting
http://asn-1.com      Secure ASN.1 Design & Implementation
p:  +1-919-832-7008   1625 Glenwood Avenue
f:  +1-919-832-7390   Hayes Barton at Five Points
e:  phil@xxxxxxxxx    Raleigh, North Carolina 27608-2319 USA
------------------------------------------------------------

> Carlisle Adams wrote:
> 
> Hi,
> 
> For those of you that are curious, 2510bis-03 and 2511bis-01 are minor
> revisions to the previous drafts which, I believe, address all
> comments received (both privately and on the list) in the past 3
> months.  I feel that both documents are now ready to progress.
> 
> The documents can be found at the following locations:
> 
> 
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc2510bis-03.txt
> 
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc2511bis-01.txt
> 
> The changes between rfc2510bis-02 and rfc2510bis-03 are as follows:
> 
>           p.30:  added a comment on the "waiting" status regarding the
>           possible need for a polling mechanism in the transport layer
>           and allowing the possibility of polling PKIMessages in a
>           future version of this spec.  (You might recall Magnus
>           asking for this on the PKIX list....).
> 
>           p.33:  removed tag "[1]" from publicKeyMAC field (to align
>           with syntax in RFC 2511).
> 
>           p.39:  changed "OCTET STRING" to "string" in comment
>           regarding utf8Pairs ("OCTET STRING" was confusing to some
>           people).
> 
>           p.63:  added a comment regarding the way in which a
>           requester could indicate a preference for algorithm and
>           parameters with respect to centrally-generated key pairs
>           (Magnus also asked how this could be done and I should have
>           given him this answer, but didn't think of it at the
>           time...).
> 
>           p.67:  removed the position-dependence requirement for
>           requests in cr and kur (at least a couple of people have
>           asked for this on the list, including Magnus).
> 
>           p.75:  clarified what gets signed if the AltCertTemplate
>           control is used (someone asked for this on the list).
> 
>           p.80:  (see p.30 above).
> 
>           p.85:  (see p.39 above).
> 
>           p.86:  added the certReqId field to CertStatus (I had done
>           this in the body of the spec, but forgot to copy it to this
>           appendix!).
> 
> The changes between rfc2511bis-00 and rfc2511bis-01 are as follows:
> 
>           pp.1 and 13:  changed the work affiliation for Mike Myers.
> 
>           p.10:  added a missing parenthesis in the second line of the
>           comment under encValue.
> 
>           p.12:  added a reference to PKCS11.
> 
>           p.16:  changed "OCTET STRING" to "string" in comment
>           regarding utf8Pairs ("OCTET STRING" was confusing to some
>           people).
> 
> Carlisle.