Directory service under development. Fill out application form with signature (from who?). Information is checked before accepting. This will be put on the Internet.
Anyone who has some sort of relationship with the institution can register. For example, employees, LCG testbed workers, are registered.
How is this enforced?
This is a strong recommendation, but is not enforced.
Based on comments by Tony and David Groep. No problems/conflicts with these changes.
About 200: 10 users, 190 hosts.
Should these be revoked? They have the same DNs. The CNRS certs should be revoked, but it must be done in an orderly way.
The CA in Taiwan is run professionally and should be approved.
Proposal: Approve this CA
Agreed
Now we must get details to include CA in distribution.
Tier of CAs, similar to DOE grids. Root CA and Service CA which are traditional, according to min requirements. Also have KCA for user certs.
Request that Root CA and Service CA are treated as ordinary CAs and that KCA is treated as an online CA.
Change to minimum requirements is that the requirement for being either offline or having FIPS level 3 HSM.
Root CA used only for signing KCA and Service CA keys.
Need to enforce in signing policy that KCA key can only be used to sign short-lived certs.
Only change to min requirements is removal of offline requirement. Everything else should be retained.
Section 4.4.4 contradicts 2.6.2
2.6.2: CRL published every 2 weeks 4.4.4: CRP published monthly
These will be reconciled
Section 2.1.1
Replacement of KCA would have minimal impact
.
Claim that it is less of an impact than replacing Root CA.
Only delay should be distribution of new KCA key. This can be signed with Root CA for security.
A delay of 4 months could be expected to get other sites, etc.
up to date. Change to thereby reducing the impact
.
This means that we might have to make a decision on part of the CP.
Are we approving the CP, a contract
? Or are we approving the
individual CA.
Problem is that approving the CA is tantamount to approving the CP, which could get interpreted as approval of the KCA.
The OID identifies the CP, but not under which policy the cert was issued. The OID has to identify the policy without any other information. Include this requirement in the min requirements.
Dane will split the CP/CPS into traditional and online parts. Milan and Ursula will referee the Fermilab CP/CPSs.
Linux Rule-Based Access Control (RBAC) not used yet, as they are more familiar with LIDS.
OpenCA requests sent by email. Jens will offer some help.
Almost ready. There have been some changes recently. It will be submitted to the CA list within a few weeks. How quickly is approval needed?
If there is an incident
with an institution cert, who is responsible.
Email request, signed by existing key, would be useful for re-keying.
Possible to setup client authentication on Apache, which could be used for renewals.
Jens and Roberto (in absentia)
Using two /O= (organisation) attributes in the DN. RFC2459 superseded by RFC3280, which allows this. Multiple O attributes caused problem, and did not display correctly in Netscape. This seems to be accepted by experts.
Used by PyCA. Needs testing with lots of software!
Since there are no changes affecting the min requirements, a deep review may not be necessary.
If changes for requesting/approval are required then this will need to be approved by PMA. Other changes could just be announced.
CNRS issuing in multiple namespaces, this is a conflict in authority.
Changes to many areas of policy.
As soon as possible, but it may take several months.
CP and service originally aimed at Grid community. When it was required to provide to a wider audience the policy was changed.
A split was made, with a new OID used for non-Grid certs.
Change is to declare a more general scope, with no change to operational matters.
Approved
OU changed from VO of RA to host DNS domain of RA. No problem with this change. A new CPS will be issued.
Approved
Change name of CA from Grid-CA to GridKa-CA. Now O and OU are mandatory
Changes related to release of personal information to site managers, under legal requirements, etc.
Are other CAs willing to provide this information to the relying services, the VOs. DOE setting up trouble ticket system to share information between VOs.
There are data protection issues here, as the users have to give permission for this information to be released, and indeed may be given the option to turn this down.
used to indicate version changes.