AsiaPacificGrid PMA Meeting 2006-6-29 (VTC) Note taker: David Bannon ----- Action items from this meeting ------ * report on "time separated issuing from all (?) members. * CNIC to revise based on comments provided. * Please note new Authorisation Profile. * Please note new Minimum Requirements Document * Yoshio to discuss keyusage critical issue and the fact that Globus ignores it at Ottawa * Note next VTC in week 24th July ----------------------- Meeting started several minutes late due to technical issues. Present AIST, APAC, ASGCC, CNIC, KEK, KISTI, NAREGI (via Yoshio), NGO, Thai, UoHyd NCHC not present due to technical problems. Updates from chair. ---------------------------- GGF17 in Toyko - session of the IGTF, agreed to distribute tar ball every two or three weeks. (before that every 3 months) Release three ver 1.4, 1.5, and finally 1.6 on June 20th due to problems at Naragi, key length not 2K, was 1K. So violates CP/CPS, informed IGTF members, necessary to release 1.6 with out NARAGI entry. * Now NARIGI will launch a new CA with correct key length. * Person representing Naragi CA has left, looking for new representative, will be represented by Yoshio in mean time. * Yoshio attended the June 2 Euro PMA F2F in Hungary. Yoshio Given some tasks there, review classic Auth profile, * Ottawa next 17July to 19, TAGPMA F2F meeting. APAC - Introduced new CPS, v1.3, changes required after March review, mostly documentation issues. ASGCC - Howard - new cpcps who to submit ? Any comments please ? Changes include name hierarchy, added new method to identify users. A lot of minor changes, does tend to add up to a major revision. Yoshio - please send the CP/CPS to the group for review. CNIC - Responses to Questions - 2.1.3 ensure cert used only for our machines. Not for other end entities. Yoshio - as described, can only identify ca system operators, the number of certs is small, you should consider completely different procedure issue procedure. More strict procedure recommended. Don't need a web interface. It seems operation and procedure for issues is same with other groups if you can limit number of certs. Separate procedure between the two CA, easy to resolve. 2.1.3 - sub CA, private key must be encrypted form. 3.3 - expiration, if cert has expired, not suspended. 4.2.1 - F2F meeting and official documents identifying end entities. UA must see official docs. Ensure that member of other organisation that belong to the group. Yoshio - must have in person meeting. CA email is plain email. Not signed or encrypted. Yoshio - must be secure, trusted, ie PGP, plain cannot be accepted. How do you generate CRI encode ? Morris - it is encrypted. Private code is encrypted by public key. Is 2048 bit private key for sub CA. How subscriber renews - send email to CA containing reason for renewal. 4.4.3 - in all case the CA shall try and protect subscriber - if sub send email to RA, we receive request and generate as necessary. Can determine subscriber identity. Yoshio - your cert can sign emails ? Morris - Yes. Modify CPS according to these comments - separate issues. Morris - Send signed email to generate renewal request. Another method is appropriate when applied to sub CA. KEK - Reviewing CP/CPS requirements to use HTTP rather than HTTPS for CRL. Spec of user interface. Yoshio - if cert issued by unknown CA there is a problem when using https - most CAs now use HTTP, including commercial. For AIST issued CRL from HTTPS and had no problems because cert issued by Verisign. But now changed to http, both are still valid. All new certs point to http connection, this is the recommended approach. If you use email in common name, user id, we have agreed not to use such attributes. Suggest you use subjects alt name instead. KISTI - sent report to mailing list. In May and June issued 33 certs, 8 user and 24 host, 55 issued from Jan to now. Upgrading web based SW in July. CPCS documents being translated to Korean. Changing from MD5 to SHA1 signing method. Preparing for Auditing. Yoshio - may be able to visit KISTI in September 20-22. Perhaps Sept 19 is audit day ? NCHC - skipped due to connection problem NECTEC - submitted report, using OpenCA and OpenSSL. Expect to finish CPS mid july. NGO - Use of commercial CA, NetTrust, labelling of keyusage basic constraint as critical. And lifespan. Difficult to change, note its labels as "must have", signed at root level, things that we have to follow up. Can we change life to 20 years. Yoshio - yes, maybe. Have to vote. Now that Profile say 20 years we have that opportunity, all we need change is the APAGridPMA rule. Note - change of APGrid Rule ------------------------------ Are all members happy with changing root certificate life to 20 years ? Yes, no dissenting voices - twenty years is now permitted. NGO (continued) KeyUsage is marked as critical. Suggest you use a "sub CA". Yoshio will discuss at Ottwa. SDSC - not present. Thai - Just at starting point waiting for numbers, the CPS should be ready to submit in a month and a half. Would like to have approval for experimental CA in September, is that possible ? Yoshio - yes. Expect production CA by Q1 2007. APGrid Minimum Requirement Discussion ------------------------------------- New version of minimum CA req, created 1st November. Approval postponed until now. New draft based on latest version of Classic PKI profile as managed by EugridPMA. CA mus be off line or use hardware enc 141 - now 142. Equivalent so not an issue. Must have keyusage critical - a recommended value, basic constraints not CA, checked some certs in distributions, some have an addition signature, must include RFC2119, if set must be critical, apply to keyusage. CA can request revocation. Revocation circumstances - not a fundamental modification. New - revocation request must be authenticated. CRL must be compliant with v1 or v2 as per RFC3380, MDS5 must not be used. New End user cert - expanded from 12 months to 13 months. New CRL distro point must be specified in certificate, must be http (not https). Must contain OID and OID only (including CPS release no). Sub Alt name content - confusion between use of 'shall' and 'should'. Actual name Record archival - must be available to auditor, keep 3 years. Yoshio - do we agree with the new requirements - Yes! Yoshio - effective from today, we must ensure we are compliant with version 1.3, not necessarily immediately. Don't need to revoke any existing certs. New Classic Auth Profile. ------------------------------------ "Should" as described in RFC2119 - valid reason. Full implications must be understood. Addition could mean PMA ask CA to explain, better to say "should". Different to "must". Thats implies its not a strict requirement, if a clear explanation is make and PMA is satisfied, can be OK. FQDN - not practical to ask "owner". David - The CA operators check the names in any host certificate to ensure it appears to be sensible for the organisation and ensures certificates are only issed at request of someone who already has a personal APACGrid certificate (and therefore attended a F2F meeting). John - the FQDN must reflect organisation, requester must provide a letter, letterhead, signed saying person is employee of org and host is valid. Interesting situation when names clash. Changes of status of certificate - seems OK. Time separated operation - home work for all of us. If we issue certs on a time separated basis (an most probably do so), please describe process. New profile may cause problems. Please send email to list before TAGPMA July 17-19th. Software token - credentials renewed for 5 years. None of our CAs use hardware tokens so not an important issue to us. (David - did I record this correctly ? What about KEK ?) Vote must take place to remove accreditation for non compliant CA. David suggested that a vote was too time costly, chairman could act immediately. Yoshio explained difference between having a CA's bundle withdrawn (which might need urgent action) and excluding a member CA from the group which is a serious situation and needs careful consideration. David withdrew suggestion. Disclose architecture - Report from Europe of a CA that did not have an appropriate architecture, they had used a hardware security device and did not therefore need to have an off line machine but they had combined the two machines into one. This was considered not acceptable and demonstrated the need to require a CA to disclose its architecture so problems like this can be detected. Tamper Protected logs for systems using HSM - Yoshio - not an easy thing to do. KEK can you do this ? Please advise. Lost v compromised key ? A compromised key's certificate MUST be revoked as soon as possible, urgently. A lost (ie accidentally deleted) is not really urgent. How can we enforce the rule about a user requesting the revokion in a timely manner - very difficult ! Can we measure entropy of 72 bits - Yoshio, anyone know how ? - no! Next VTC in the week of July 24th --------------------------------- Thank you for your attendance.