Re: I-D ACTION:draft-ietf-pkix-okid-01.txt

[Denis Pinkas <Denis.Pinkas@xxxxxxxx>]

Paul,

You made quite a good job, with this new specification since the hash is now
computed over the whole certificate instead of the public key only.

A few comments:

1. Editorial. Choose either OKID or OCKID. 
   I don't care as long as there is a single acronym.

2. I have some concerns with section 4 when it states:

Because the result of matching the OCKID to the CA certificate is that
the certificate will now become a trust anchor, the system MUST inform
the user of each of the following: 

- That the certificate has become a trust anchor

- The policies used by the issuer of this certificate to issue
subordinate certificates ([PKIX] section 4.2.1.5)

- The basic constraints placed on the issuer of this certificate, such
as the depth of subordinate chain that can be issued under this
certificate ([PKIX] section 4.2.1.10)

- The types of names for which the issuer of this certificate can create
certificates ([PKIX] section 4.2.1.11)

- The policy constraints placed on the issuer of this certificate
([PKIX] section 4.2.1.12)

The system SHOULD give the user a method for later removing the trust in
the CA certificate. The system MUST also check whether the certificate
is properly signed, that is, that the public key in the certificate is
in fact correctly verifies the contents of the certificate.

End of extract.

In most cases the user will only verify that the intended hash matches the
computed hash and will install the self-signed certificates. Controls like
checking the signature of the certificate may be recommanded but should not
be mandatory.

Hence I would propose a text along the following:

"Because the result of matching the OCKID to the CA certificate is that the
certificate will now become a trust anchor, the system MUST inform the user
that the certificate has become a trust anchor.

The system SHOULD give the user a method for later removing the trust in the
CA certificate. 

It MAY provide additional information to the user like:

- The policies used by the issuer of this certificate to issue subordinate
certificates ([PKIX] section 4.2.1.5)

- The basic constraints placed on the issuer of this certificate, such as
the depth of subordinate chain that can be issued under this certificate
([PKIX] section 4.2.1.10)

- The types of names for which the issuer of this certificate can create
certificates ([PKIX] section 4.2.1.11)

- The policy constraints placed on the issuer of this certificate ([PKIX]
section 4.2.1.12)

The system SHOULD also check whether the certificate is properly signed,
that is, that the public key in the certificate is in fact correctly
verifies the contents of the certificate."

Denis