March 14, 2001
Attendees
* Jim Jokl (chair) - Virginia
* Renee Frost - Michigan/Internet2
* Ellen Vaughan - Internet2
* Ken Klingenstein - Colorado/Internet2
* Chris Misra - Massachusetts
* Neal McBurnett - Avaya
* Deb Crocker - Alabama
* Michael Gettes - Georgetown
* Bob Morgan - Washington
* Bob James - Pitt
* Keith Hazelton - Wisconsin
* Bill Doster - Michigan
* Ben Chinowsky (scribe)
- Internet2
Discussion
The group opened the discussion with a review of the action items from the last meeting. [All who have not yet downloaded the CREN root cert will do so and give Judith feedback on the process.]
Eric reported that he'd done this and found it difficult to find the cert. [AI] Eric will send feedback to Judith suggesting that a prominent link to the CREN root cert be added to the CREN CA page. [Jim will redraft the last paragraph of the dc naming recommendation according to today's discussion.] Done; the paragraph now says "HEPKI-TAG also recommends that domain component names be used in addition to any information that can be encoded directly into the certificate. When searching for additional data about the Subject or Issuer, applications should always prefer a direct reference to the information over using the more generalized approach of Domain Component names and DNS SRV records to locate the data." Bob Morgan observed that "any info that can be encoded directly" means attributes that are designed for looking up particular kinds of information, and asked that the draft state this explicitly. [AI] Jim, with Bob M.'s help, will tweak the first sentence of the last paragraph of the dc naming recommendation. The group also considered and rejected the idea of adding more explanatory detail to the dc naming recommendation. Bob M. noted that the next version of the LDAPEXT document will say that if you're using DNS, the cert has to give the name of the DNS service, not the name of the host; the document will also explicitly specify the need to verify the SSL cert on the final target server.
[Bob Morgan will forward to Jim the mail he sent Microsoft about root cert deployment issues.] Still to do.
[Bob Morgan will contact Microsoft about root cert deployment issues.] Still to do.
[Anyone who has cycles will contribute to the SACRED scenarios document or mailing list before IETF.] See below.
[Ken will list Shibboleth's PKI questions for TAG.] See below.
[Keith will send information from NIST to MACE.] Done during this call.
Michael reported on an Ed/Fed/Mitretek session in which the possibility was discussed of a HEBCA trial with ten or so Internet2 schools using Mitretek bridge technology. The trial would make use of Apache plug-ins, on the server side only. Mitretek is interested in getting feedback on usability; they will be joining the PKI Labs calls, and possibly the TAG calls as well.
Ken noted that he'd received some information from Kevin Unrue on Cornell's unhappy experience with smartcards. Ellen is now shaping this into a discussion outline.
Jim noted that Mine would very much like to get some feedback on her cert profile maker (CPM) tool. Keith noted that he had talked to Mine about CPM, and that he's impressed with the user interface. Keith characterized CPM as "a cert-profile-creating wizard"; as the cert profile can be formatted in XML, an actual cert can in turn be created from it.
Ken reported on his FBCA discussion with Peter Alterman and Tim Polk. Deployment is now planned for the end of April; apparently they are not at all discouraged by the recent GAO report. Alterman and Polk are very interested in the projected PKI Labs conference; Ken is planning to send them a proposal next week.
Keith, Bill, and Jim noted that (respectively) Wisconsin, Michigan, and Virginia have committed to deploying CREN-signed institutional certs.
Finally there was a discussion of Shibboleth PKI issues. [AI] Ken will send TAG the Shibboleth PKI questions he wrote up as part of the the Shibboleth out-of-band work. Ken grouped TAG's issues here under two headings: 1) the format of the signed XML objects that Shibboleth will make use of, and 2) keys: what kind to use, how to exchange them, how to revoke them, how to protect them, etc. Bob M. argued that the PKI issues raised by Shibboleth are exactly the same issues raised by putting an SSL server on the web, and that therefore they should be handled the same way; he thinks the requirements of the October 1 demo can be met with existing SSL and commercial certs. Ken noted, and Bob M. acknowledged, that if Jeff is right about copyright limitations on the use of commercial certs, this would present a problem for this suggested solution. Ken suggested CREN certs as an alternative. In this case, an intermediary cert might be necessary in order to avoid exposure of the institutional key. As it appears that CAs issued by CREN can't issue server certs, the need for intermediary certs may in turn necessitate CREN issuing server certs. [AI] Ken will find out if CAs issued by CREN can issue server certs, and contact Judith to discuss further as necessary. [AI] Jim will make Shibboleth PKI the main agenda item for the next TAG call. [AI] All will read the design documents on http://middleware.internet2.edu/shibboleth/, especially "Shibboleth Flows". [AI] Ken will produce a short document to guide the discussion of Shibboleth PKI issues.
Action Items
* [AI] Eric will send
feedback to Judith suggesting
that a prominent link to
the CREN root cert be added
to the CREN CA page.
* [AI] Jim, with Bob M.'s
help, will tweak the first
sentence of the last paragraph
of the dc naming recommendation.
* [AI] Ken will send TAG
the Shibboleth PKI questions
he wrote up as part of the
the Shibboleth out-of-band
work.
* [AI] Ken will find out
if CAs issued by CREN can
issue server certs, and
contact Judith to discuss
further as necessary.
* [AI] Jim will make Shibboleth
PKI the main agenda item
for the next TAG call.
* [AI] All will read the
design documents on http://middleware.internet2.edu/shibboleth/,
especially "Shibboleth
Flows".
* [AI] Ken will produce
a short document to guide
the discussion of Shibboleth
PKI issues.