Comments on

[Charles Moore <cmoore@xxxxxxxxxxxxx>]

REPLACE:
2.2.2 Mandatory schemes

The criteria above allow for a large number of initial registration / 
certification schemes. This specification mandates that conforming CA 
equipment, RA equipment, and EE equipment must support the second 
scheme listed below. Any entity may additionally support other schemes,
if desired.

WITH
The criteria above allow for a number of initial registration / 
certification schemes. This specification does not mandate a particular
scheme, but describes two schemes in the following sections. Any entity
may support these or other schemes, if desired.
A future PKIX specification will support key generation protocol
requirements.

RATIONAL: Document agreements.

REPLACE
2.2.2.1 Centralized scheme

In terms of the classification above, this scheme is, in some ways, 
the simplest possible, where:

- initiation occurs at the certifying CA;
- no on-line message authentication is required;
- "key generation" occurs at the certifying CA (see Section 2.2.1.3);
- no confirmation message is required.

WITH
2.2.2.1 Centralized scheme

In this scheme:

- initiation occurs at the CA or RA entity;
- no on-line message authentication is required;
- "key generation" occurs at the RA or CA entity;
- no confirmation message is required.

RATIONAL: Changes to align with stated requirements in previous sections
to allow generation at the RA.

ADD to 3.1.2 PKI Message Body 
Add an additional  branch be added to the CHOICE.  The
additional branch would be:

	other [48] SEQUENCE {
			oid	OBJECT IDENTIFIER,
			value	ANY DEFINED BY oid  }

The tag number does not concern me.

RATIONAL: Missed in update

REPLACE 
CertificateValidityDate ::= CHOICE {
      utcTime        UTCTime,
      generalTime    GeneralizedTime
  }

WITH
CertificateValidityDate ::= GeneralizedTime

RATIONAL: There is no need to support the legacy UTCTime in the request.





Charles Moore
Signet Systems Pty Ltd
Phone: +61 7 3256 7465 Fax: +61 7 3256 6794