Re: [IETF-PKIX] Comments on Malpani and PKIX OCSP drafts

["David P. Kemp" <dpkemp@xxxxxxxxxxxxxx>]

> From: Michael Myers <mmyers@verisign.com>
>
> The expressive power of ASN.1 is overkill in this case.  It burdens the
> implementor with a steep learning curve, expensive tools, and delays in
> market access just to gain access to an integer value expressing the current
> state of a certificate's status.

Horsefeathers.  How long has Netscape included the KEYGEN construct in
their product line?

(For those not familiar with KEYGEN, it is a component of FORM which
does ASN.1 encoding of a certification request, Base64 encodes the
result, and includes it in an HTTP name=value response just like all
other application/x-www-form-urlencoded FORM components).

Has the use of KEYGEN produced a steep learning curve, expensive tools,
and delays to market for Netscape or for any CAs which work with
web browser input?


> This issue is not one of thin-client vs. full client but more with the
> fundamental problem being addressed and a rational balance
> between that problem's scope and the tools needed to effect
> its solution.

What kind of "rational balance"?  Isn't a syntax which is simple for
simple cases and incrementally extensible to handle more complex
requirements preferable to one which works only for simple requirements
and succombs to baroqueness when faced with anything else?

I would love to see a code-size bakeoff between OCSPs; I am conviced
that Malpani OCSP would fit into a smartcard or palmtop with more room
and cycles to spare than Myers/Ankney OCSP.

Nonetheless, after speaking with Rich, I am not inclined to suggest
that PKIX endorse the use of Malpani OCSP in lieu of Myers/Ankney
OCSP.  Instead, it may be preferable to use the Notary protocol,
perhaps with components of Malpani OCSP rolled in, as a vehicle for
both simple and extended validation requirements.  For online use with
HTTP/TLS, the Notary protocol messages can be neatly encapsulated as
Ambarish suggests, while still being usable over other
transport/protection mechanisms such as SMTP/CMS.