PKIX-1 new draft/Last Call?

[Tim Polk <[e-mail]>]

I have submitted a new draft of PKIX Part 1.  I will attempt to summarize
the changes in the document.

1. It's bigger.  (Are you sitting down?) We're up to 107 pages - 45 of
which are appendices.  The main culprit is the two ASN.1 modules - one in
1988 syntax, the other 1993.

2. We have an RSA patent statement!

3. We have two example certificates and one CRL.  (Together, they comprise
a certificate path of length two.)  Thanks to David Kemp and Michael Quinn
from NSA for putting this together on *extremely* short notice.

4. There were a handful of unaddressed comments from Peter Williams and
Charlie Gardiner as of Memphis.  They are all taken care.  (Well, I think
they are taken care of.  I should wait to hear from Peter and Charlie.)

5. KEA was removed and I have submitted a separate I-D profiling KEA
certificates with respect to Part 1.  The goal is an Informational RFC.
(Part 1 could not be considered for standard status if it included a
classified algorithm.)

That takes care of the "old business".  There were a number of new issues
that arose on the list since the Memphis meeting.  I never seemed to catch
up before the threads died down, so I just read each thread and did my best
to accomodate the "sense of the group." Here is an overview:

6. Key Usage - ISO added two new values: encipherOnly and decipherOnly.
They are only defined if the keyAgreement value is asserted. Part 1 now
includes these values as well.

In addition, there was an extended discussion regarding which combinations
of keyUsage values "make sense." The Part 1 text makes no general
statements, but it does explicitly specify which combinations are
appropriate when the subjectPublicKeyInfo field contains a key for
algorithm X for any algorithm in section 7 (DSA, RSA, D-H).

7. ASN.1 tweaks. There are a couple.  Thanks to Dean Povey and John Pawling
in particular.

One should be highlighted. Charlie Gardiner noticed an ambiguity in the
encoding of a certificate without extensions.  It could be encoded as
version 3 with an empty SEQUENCE of extensions instead of version 1 or 2.

The ASN.1 for Extensions
	Extension ::=  SEQUENCE of Extension
hads been modified to state
	Extension ::= SEQUENCE SIZE (1..MAX) of Extension

This prevents a CA from issuing a version 3 certificate without extensions.
 In this case, the certificate should be version 1 or 2.

8. Path Validation
Check this one closely!  I re-wrote the path validation section, describing
a path that begins with a self-signed certificate (containing the public
key of your most trusted CA, for example).  I believe this text explicitly
addresses comments on the list (from Denis, Peter, and others) about use of
local certificates to impose security policy, and it also describes
extending the algorithm for multiple trusted certificates.

(I believe this text will be more helpful for readers who are not path
validation experts than repeating the X.509 text.  However, I worry that
some error crept in, making it incompatible with the X.509 text.)

9. Year 2000/Certificate validity
A thread on year 2000 evolved into the differences between the latest ISO
and PKIX-1 texts on validity dates.  ISO was clearer and more acceptable to
the group.  I made the appropriate changes.

10. Subject Names
The text now states that the subject and issuer distinguished name fields
(where they are used) are X.500 Distinguished Names, not just some sequence
of RDNs.  I also added text from Warwick stating "The DN, when non-null,
must be
unique for each subject entity certified by the one CA.  A CA may issue
more than one certificate with the same DN to the same subject entity."

11. The Certificate Issuer CRL entry was added.

Now - on to the "stuff we didn't do"

A. unique ids
There is no change here. The draft states that conforming CAs shall NOT
populate this field; clients are required to process this field or reject
certificates that include it.

A vocal minority would like unique ids *required*.

There is good reason the CA vendors are against unique ids. No one wants to
use them, since we have no idea how to use or manage them. In addition,
everything the minority wanted to do with the unique id could be done with
the distinguished name or an alternative name.

As you can tell, I am against unique ids and in the absence of a clear
majority for using them, the text was not changed.

B. ECDSA
There seems to be support for a profile of ECDSA for PKIX.  I would prefer
a new document, though, instead of adding to Part 1.

I am volunteering to work with Don Johnson from Certicom to prepare an I-D
(like the KEA document) before the December meeting.

(Note: there were several mildly negative comments on ECDSA regarding
exclusion of Weil Theorem and complex multiplication methods for random
number generation. These limitations were removed in the last ANSI X9.62
draft.)

C. The SET Root CA extension
There was thread of 16 messages regarding this extension.  The group was
pretty divided on this one.  Since it is a critical extension, all PKIX-1
conforming clients would be required to implement it.  I'm inclined to
exclude it on that basis, but we should probably examine it a little more
closely.

D. Combination certificates
There has been a recent thread on certificates containing both signature
and confidentiality keys.  Part 1 doesn't preclude this.  The only
recognized OIDs  for subjectPublicKeyInfo fields correspond to one key (one
RSA key, one DSA key OR one Diffie-Hellman key).  I believe this is an
acceptable compromise, especially since the biggest consumer of combination
certificates (MISSI) is transitioning to separate certificates.

Finally, I believe the document is ready for WG Last Call.  I will make
that request of the chairs.  So, if you've been waiting to read this whale,
now is the time!

Regards,

Tim Polk