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

[Magnus Nystrom <magnus@xxxxxxxxxxxxxxx>]

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

On Fri, 2 Mar 2001, 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).