PKIX 3 Certificate Request format

[dpkemp@xxxxxxxxxxxxxx (David P. Kemp)]

The PKIX meeting minutes, promptly submitted by Steve Kent, said:

> 	The presentation on the Part 3 document was made by its
> authors, S. Farrell and C. Adams.
>  [...]
> There is
> a separate issue about use of PKCS-10, which is somewhat less powerful
> than what is currently offered.  Thus the suggestion is to make
> PKCS-10 a format option, but not the only format option for
> certificate request messages.


At the WG meeting, Dave Solo heartily endorsed the idea of adding
PKCS-10 certificate requests in addition to the PKIX-3 certificate
requests, and Russ Housley suggested replacing the PKIX request with
the PKCS-10 request.

In addition, Tim Polk's Minimum Interoperability Specification (MISPC)
document includes certificate requests in both PKIX and encapsulated
PKCS-10 formats.

For reference, the core of the two request formats are as follows:

PKIX-3/MISPC:
    CertTemplate ::= SEQUENCE {
	version		[0] Version		OPTIONAL,
	serial		[1] INTEGER		OPTIONAL,
	signingAlg	[2] AlgorithmIdentifier	OPTIONAL,
	subject		[3] Name		OPTIONAL,
	validity	[4] OptionalValidity	OPTIONAL,
	issuer		[5] Name		OPTIONAL,
	publicKey	[6] SubjectPublicKeyInfo OPTIONAL, --required :-)
	issuerUID	[7] UniqueIdentifier	OPTIONAL, -- not supported
	subjectUID	[8] UniqueIdentifier	OPTIONAL, -- not supported
	extensions	[9] Extensions		OPTIONAL
    }

PKCS-10:
    CertificationRequestInfo ::= SEQUENCE {
	version		Version,
	subject		Name,
	subjectPublicKeyInfo SubjectPublicKeyInfo,
	attributes	[0] IMPLICIT Attributes
    }



The PKIX-3 format appears to be a proper superset of the PKCS-10
format, i.e. every possible certificate that could be requested
using PKCS-10 can also be requested using PKIX-3, however PKCS-10
cannot support several of the PKIX-3 request fields.

IMO, the PKIX-3 certificate request should remain as it is. Replacing the
current request format with PKCS-10 would reduce functionality; adding
PKCS-10 requests in addition to the current format would increase
complexity without offering any corresponding benefit. Creating a
protocol with two non-orthogonal messages to perform a single function
is a poor design practice.

The argument was made that PKCS-10 needs to be added to PKIX-3 in order
to accommodate existing legacy implementations.  This is not true -
all implementations are free to use either PKIX-3 or PKCS-10 or
both, without modifying either specification.  There is no need
to create a muddy hybrid specification to enable interoperability
with legacy apps - implementations can continue to support PKCS-10
for as long as there is a market need to do so.

Moreover, no existing PKCS-10 implementations will conform to
the MISPC spec.  They will all need to be modified to add the
PKIMessage encapsulation around the PKCS-10 cert request.  This
is a major, non-trivial modification to the code - if you are going
to expend that amount of development effort you might as well also
make the tiny additional change to put the request in PKIX-3 format.

In summary, the PKIX-3 specification should not have its existing
certificate request replaced or augmented by a PKCS-10-format message.
The MISPC specification should not include an encapsulated PKCS-10
message, instead it should state that either PKIX-3 PKIMessage's
or raw PKCS-10 messages should be supported for interoperability,
with a sunset date for the PKCS-10 support.

         dpk