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

From: Carlisle Adams <[email-masked]>
Date: Fri, 2 Mar 2001 10:07:33 -0500

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.

---

From: "Phillip H. Griffin" <[email-masked]>
Date: Fri, 02 Mar 2001 12:51:29 -0500

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:  [email-masked]    Raleigh, North Carolina 27608-2319 USA
------------------------------------------------------------

> Carlisle Adams wrote:
> 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.
> 
>           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....).
> 
>           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...).
> 
>           requests in cr and kur (at least a couple of people have
>           asked for this on the list, including Magnus).
>

---

From: Magnus Nystrom <[email-masked]>
Date: Thu, 8 Mar 2001 18:10:51 +0100 (W. Europe Standard Time)

Carlisle,

Thanks for taking our views into account. A few comments on the new
versions of rfc2510bis and rfc2511bis:

-The waiting status issue:
 We feel that it is a bit disturbing that no polling req/rep
 PKIMessages are defined. The result is that the protocol does not
 define what to do in those instances when a "waiting" status is
 returned. It would be much more satisfying to define this within CMP
 than rely on some underlying transport to do the polling (with what
 PKIMessage? - and it would have to be defined for all conceivable CMP
 transports, too...)

-While the use of an empty SubjectPublicKey to indicate the type of
 key an end-user would like to have centrally generated seems
 possible, it will not give the user a possibility to indicate
 e.g. desired public exponent or modulus length. A method which is
 more flexible would perhaps be preferable?

-The CMPCertificate type: Looking in rfc2511-bis-01, it does not
 appears as if there is a corresponding framework suggested to allow a
 requester to indicate that it would like, e.g. a WTLS Certificate to
 be returned. Is this intended? One could imagine, e.g., a
 CertTemplateChoice.

-ASN.1 modules:

 I also took a few minutes to check the ASN.1 with my syntax checker.

 RFC 2511bis: There is one simple problem and one slightly harder one.

 a) You need to remove the "CRMF" before "DEFINITIONS" - the module has
    already been named above to "PKIXCRMF".

 b) PKIXCRMF imports definitions from both RFC 2459 (bis) and CMS. CMS
    in turn, imports definitions from ITU/ISO specifications rather
    than PKIX RFCs. Now this would be ok, unless it was for the fact
    that RFC 2459bis and RC2511bis use 1988 syntax, as does CMS, but
    CMS imports from modules written in 1993 syntax. This creates a
    mess for those using commercial compilers, since UTF8Strings (used
    in ISO documents but defined explicitly in PKIX documents) aren't
    supported in 1988 but are in 1993, so one cannot compile these
    modules with either a "1988" switch or a "1993" switch. My advice
    would of course be to move to 1993/1997 ASN.1 altogether, but if
    this is not possible due to PKIX policies, I'd suggest a change to
    make CMS dependent on PKIX modules rather than external modules
    (yes, I realize that CMS is owned by S/MIME and not by PKIX).

 RFC2510bis:

 c) You state that there is no PKCS #10 ASN.1 module defined; this is
    not correct. RFC 2986 does contain a (1993) module.

 d) I would prefer if X9.68 certificates were not mentioned in this
    document.

 e) Since you already import from rfc2459 modules, why not also import
    the UTF8String definition from there?

 Other than that I found the very same errors as James Manger did.

-- Magnus

---

From: "Phillip H. Griffin" <[email-masked]>
Date: Fri, 09 Mar 2001 08:48:49 -0500

Magnus and Carlisle,
A few comments below.

>  more flexible would perhaps be preferable?

In rfc2510bis, for other key formats, allowing a user 
to choose domain parameters known to be viable or key
lengths of sufficient strength would also be a plus.

----

Note that in rfc2510bis under "B2. Algorithm Use 
Profile", useful references for HMAC and ECDSA 
could help readers. These are columns could 
include X9.71 and X9.62.

>  be returned. Is this intended? One could imagine, e.g., a

I notice that a couple of places in rfc2510bis state
"See Appendix D and [rfc2511bis] for CertReqMessages
syntax", and that Appendix D does provide direction
for "specifying a template for a certificate other 
than an X.509v3 public-key certificate". 

The use of type AttributeTypeAndValue here seems 
quite flexible enough to handle any type of  
certificate format. This is a far less restrictive
design than using a choice type. It opens up market
possibilities rather than closing them.

>     in ISO documents but defined explicitly in PKIX documents) aren't

Actually the situation is even worse than
described here. The use in IETF modules of
class UNIVERSAL tags is not valid ASN.1 under
any version of the ASN.1 standards.

It is an IETF concoction made up I believe
to allow old X.208 and X.209 based tools to
make use of new ASN.1 types never defined 
in those standards, but defined for years 
and years now in the current ASN.1 standards.

This kludge allowed old tools to provide 
much needed national language support without
being updated or corrected, and allowed folks
with copies of X.208 and X.209 (which have not
been corrected or amended for years) to avoid 
buying the current ASN.1 standards. 

At one time, the current ASN.1 standards were
not available except for a charge, and there 
were various copies of different versions of 
X.208 and X.209 floating around for free.

But the X.680 and X.690 series standards are
currently free for download from the itu.ch 
web site. Up until a couple of weeks ago at 
least, when I last checked, all you had to do
was to enter an email address to get three
free documents. New email address, three more
standards.

>     would of course be to move to 1993/1997 ASN.1 altogether, but if

Agreed. This is the best possible solution.
Not only does it eliminate the concoction
noted above, it allows the use of other new 
types and encoding rules by adopters of IETF
standards.

>     (yes, I realize that CMS is owned by S/MIME and not by PKIX).

Not sure that this will really do more than 
cover the problem with a little sand. What 
will a compliant tool kit do if it discovers 
a value of type RELATIVE-OID in an ANY or 
embedded in an OCTET STRING? Crash and burn
is my guess. But this new type is already
being used to advantage in the new ANSI X9.84
biometrics standard and in the design of the
new compressed (see asn-1.com/x968.htm) domain
certificate syntax in ANSI X9.68:2.

>  d) I would prefer if X9.68 certificates were not mentioned in this

I would prefer that these X.509 based domain certificates
were still mentioned, but that the text be changed from
"X9.68" to "X9.68:2". Only the profile part of this series
that Magnus worked on has been dropped by the X9F1 working 
group. The other part of this series, part one, was being 
edited by Rich Ankney. I've taken this edit work on and will 
attempt to progress the work in the coming year.

>     the UTF8String definition from there?

It is no more valid really to import an invalid 
type definition than to simply define the type 
using invalid notation. It only hides the problem
for the casual reader.

Phil
----