1. Major issues (do not comply with "MUST/MUST NOT")
(1) Section 3 of the Classic AP 4.1 describes "Any single subject
distinguished name must be linked to one and only one entity.  Over
the entire lifetime of the CA it must not be linked to any other
entity.", but according to the current AIST GRID CA's CP/CPS, it is
not guaranteed that a single subject DN is linked to one and only one
entity over the entire lifetime.
I think this is not an easy problem.
For example, suppose 10 years later from now, I will not be in AIST
and another Yoshio Tanaka at AIST may apply his certificates.  Since
minimum retention period of the logs is 3 years, any record of vetting
myself (current Yoshio Tanaka) and my subjectDN may not exist.  In
such case, how the AIST GRID CA can guarantee that my subject DN
("/C=JP/O=AIST/OU=GRID/CN=Yoshio Tanaka") will NOT be used for the 2nd
Yoshio Tanaka???
Practically, it shouldn't be a problem, but we need to consider how to
draft the CP/CPS to guarantee this requirement.

(2) Section 3.2 of the Classic AP 4.1 describes "Certifications may
not be renewed or re-keyed for more than 5 years without a form of
identity and eligibility verification, and this procedure must be
described in the CP/CPS.", but current AIST GRID CA's CP/CPS does not
clearly describe the renewal of end-entity certificates.
We will add the description of this issue in one month.

(3) Section 4.3 of the Classic AP 4.1 and section 3.3.8 of the Grid
Certificate Profile describe "CRLDistributionPoints MUST contain at
least one httpURL *i.e., not an https URL) in end entity
certificates."
End entity certificates issued by AIST GRID CA include an X509v3 CRL
Distribution Point extension not as an HTTP URL but as an HTTPS URL.
We will modify the profile of our CA software for issuing end-entity
certificates to comply with this requirement in one month.

(4) Section 8 of the Classic AP 4.1 describes "Accredited CAs must
define a privacy and data release policy compliant with the relevant
national legislation.", but current AIST GRID CA's CP/CPS does not
describe it.  We need to add, but as asked by Masuko-san and Morrise,
we need to consider how to describe...  I'll send a separate email on
this issue.

2. Minor issues (do not comply with "SHOULD/SHOULD NOT")
(1) Section 3.3.2 of the Grid Certificate Profile describes
"for X509v3 keyUsage extension, nonRepudation valud SHOULD NOT be set
for server certificates.", but server and service certificates issued
by AIST GRID CA include nonRepudation as one of values of the keyUsage
extension.
We will modify the profile of our CA software for issuing end-entity
certificates to comply with this requirement in one month.

(2) Section 3.3.3 of the Grid Certificate Profile describes
"The extendedKeyUsage extension SHOULD be included in end-entity
certificates.", but end-entity certificates issued by AIST GRID CA do
not include extendedKeyUsage extension.
We will modify the profile of our CA software for issuing end-entity
certificates to comply with this requirement in one month.  We will
set clientAuth for user certificates and clientAuth/serverAuth for
server/service certificates.

(3) Section 3.3.12 of the Grid Certificate Profile describes "The
subjectAltnativeName extension SHOULD be present for server
certificates.", but server/service certificates issued by AIST GRID CA
do not include subjectAltnativeName extension.
We will modify the profile of our CA software for issuing end-entity
certificates to comply with this requirement in one month.  We will
include subjectAltnativeName extension setting FQDN in the dNSName
attribute.