- caops-wg - lists.ogf.org

CFP: 6th Annual PKI R&D Workshop
by Frank Siebenlist 20 Sep '06

20 Sep '06

Please take a look at the attached call for papers. Over the years, this PKI R&D Workshop has proven to be one of the most enjoyable security events with high quality papers and very interesting presentations. Securely yours, Frank. ---------------------- 6th Annual PKI R&D Workshop "Applications-Driven PKI (It's The Apps, Stupid!)" NIST, Gaithersburg, MD April 17-19, 2007 http://middleware.internet2.edu/pki07/ This workshop considers the full range of public key technology used for security decisions and supporting functionalities, including authentication, authorization, identity management, federation, and trust. This year's focus is striking the proper balance to permit users to complete tasks requiring security easily while exposing the appropriate security details through all layers of software. This workshop has three goals: Explore the current state of public key technology and emerging trust mechanisms in different domains, including web services, grid technologies, encryption functionality, authentication systems, etc., in academia, research, government, and industry. Share and discuss lessons learned and scenarios encountered from vendors and practitioners from current deployments. Provide a forum for leading security researchers to explore the issues relevant to PKI in relation to applications, usability, security management, identity, trust, policy, authentication, authorization and encryption (e.g., supporting privacy requirements). Call for Papers We solicit papers, case studies, panel proposals, and participation from researchers, systems architects, vendor engineers, and users. Suggested topics include but are not limited to: Reports of real-world experience with the use and deployment of applications that leverage PKI, how best to integrate such usage into legacy systems, and future research directions Federated versus Non-Federated trust models Standards related to PKI and security decision systems, such as X.509, SPKI/SDSI, PGP, XKMS, XACML, XRML, XML signatures, and SAML Identity management (Shibboleth, Liberty, Higgins, InfoCard, etc.) Cryptographic and alternative methods for supporting security decisions, including the characterization and encoding of data Intersection of policy-based systems and PKI Human-Computer Interaction (HCI) advances that improve usability of PKI for users and administrators Privacy protection and implications Use of PKI in emerging technologies (e.g., sensor networks) Scalability and performance of PKI systems Security of the components of PKI systems Security infrastructures for constrained environments Improved human factor designs for security-related interfaces, including authorization and policy management, naming, signatures, encryption, use of multiple private keys, and selective disclosure New paradigms in PKI architectures Submissions should be provided electronically, in PDF, for standard US letter-size paper (8.5 x 11 inches). Paper submissions must not exceed 15 pages (single space, two column format with 1" margins using a 10 pt or larger font) and have no header or footer text (e.g., no page numbers). Proposals for panels should be no longer than five pages and include possible panelists and an indication of which panelists have confirmed participation. Submissions will be handled electronically. Detailed submission instructions can be found at the workshop website (see http://middleware.internet2.edu/pki07/) All submissions will be acknowledged. Submissions of papers must not substantially duplicate work that any of the authors have published elsewhere or have submitted in parallel to any other conferences or journals. Accepted papers will be published in a preproceedings at the workshop and in a final proceedings shortly after the workshop. Deadlines for conference paper and panel submissions are: Papers and Proposals Due: October 22, 2006 Authors Notified: December 18, 2006 Final Materials Due: February 26, 2007 Workshop: April 17-19, 2007 -- Frank Siebenlist franks(a)mcs.anl.gov The Globus Alliance - Argonne National Laboratory

1 0

Re: [caops-wg] [Tagpma-general] IGTF session starting at GGF 18, video connected
by Alan Sill 13 Sep '06

13 Sep '06

To view the stream, enter "4483" in the conference number on the link below, then click the "stream this conference" button. No other credential fields need to be filled in. Alan On Sep 13, 2006, at 12:44 PM, Scott Rea wrote: > what credentials do we use to access?? > -Scott > > Alan Sill wrote: >> Video streaming output is available for those who don't have video >> gear but want to follow the session. The URL for this is: >> >> http://198.128.3.172/ >> >> (streaming output only). Alan Sill TIGRE Senior Scientist High Performance Computing Center TTU ==================================================================== : Alan Sill, Texas Tech University Office: Admin 233, MS 4-1167 : : e-mail: Alan.Sill(a)ttu.edu ph. 806-742-4350 fax 806-742-4358 : ====================================================================

1 0

IGTF session starting at GGF 18, video connected
by Alan Sill 13 Sep '06

13 Sep '06

Video has been connected as per the usual numbers (see message yesterday) 884483 on ESNet, etc. Please feel free to dial in or connect by video Darcy has sent out the agenda. Alan Sill TIGRE Senior Scientist High Performance Computing Center TTU ==================================================================== : Alan Sill, Texas Tech University Office: Admin 233, MS 4-1167 : : e-mail: Alan.Sill(a)ttu.edu ph. 806-742-4350 fax 806-742-4358 : ====================================================================

1 1

CAOPS-WG SESSION IS AVAILABLE ON VIDEO + PHONE NOW
by Alan Sill 12 Sep '06

12 Sep '06

Sorry for the delay. I have connected the CAOPS-WG session to our usual video coordinates as promised. 0011349884483 if on GDS 884483 if registered to ESNet 1-510-883-7860 if by phone, enter 884483# once it answers Alan Alan Sill TIGRE Senior Scientist High Performance Computing Center TTU ==================================================================== : Alan Sill, Texas Tech University Office: Admin 233, MS 4-1167 : : e-mail: Alan.Sill(a)ttu.edu ph. 806-742-4350 fax 806-742-4358 : ====================================================================

1 1

Certificate Profile document, update v0.5
by David Groep 12 Sep '06

12 Sep '06

Dear all, The last version of the certificate profile draft document is now almost two months old, so its high time for a new version that we can discuss in Washington (GGF18). The new version can be found at: http://www.eugridpma.org/temporary/eugridpma-certprofile-20060717-0-5.pdf (and I'll try to upload to GridForge once that works again; there is also an associated MS Word .doc version on the web site). I've completely restructured the document, taking Kaspar's comments into account. So it now has - two separate parts: one for CA certs and one for EE certs - the wording is RFC2119 - reference is to RFC3280 (and no longer 2459) - many extensions added, and more guidance text Please have a look through the document, and send your comments, suggestions, and text on additional extensions. Cheers, DavidG. -- David Groep ** National Institute for Nuclear and High Energy Physics, PDP/Grid group ** ** Room: H1.56 Phone: +31 20 5922179, PObox 41882, NL-1009DB Amsterdam NL **

4 5

CAOPS and IGTF Sesssions and Agenda
by Darcy Quesnel 12 Sep '06

12 Sep '06

Despite what your online and printed material may say, our sessions are as follows: Tue 4:00 pm - 5:30 pm, CAOPS Session (158A-B) Wed 1:30 pm - 3:00 pm, IGTF Session (156) Please tell as many people as possible that this is the case. CAOPS Session Agenda - OCSP Roundup (Jesus Luna, 20") - Audit Guidelines (Yoshio Tanaka, 20") - Authentication Profiles (Tony Genovese, 20") - Certificate Profile (David Groep, 20") IGTF Session Agenda - IGTF Issues (discussion led by Yoshio Tanaka) - MICS Profile (Tony Genovese, 15") - Classic Profile (David Groep, 15") - Root Certificate Profile (5") - Review of the mailing list (5") - Federal and Educational Bridge CA Discussion - AOB and anything left over from CAOPS Darcy

3 3

Updated Authentication Service Profiles doc
by Tony J. Genovese 08 Sep '06

08 Sep '06

CA Operations, I have updated the AuthN service profile document. Please review for our meeting in Washington. https://forge.gridforum.org/sf/go/doc4856?nav=1 Thanks, Tony...

1 0

[wg-all] Mailing List Changes
by Andre Merzky 03 Sep '06

03 Sep '06

Sorry for duplicates ------------------------------------------------------------ As of yesterday, all GGF/OGF mailing lists are migrated to the ogf domain. They are now managed by mailman, the web interface is available at http://www.ogf.org/mailman/listinfo With that migration, all list can be now reached via <list>@ogf.org The old @ggf.org addresses will be available for some time, but are bound to disappear eventually - please start using the ogf addresses! A number of lists have changed their names: ggf-it --> ogf-it ggf-office --> ogf-office ggf-proc-wg --> ogf-proc-wg ggf-sponsors --> ogf-sponsors ggf-tutorials --> ogf-tutorials ggf-compute --> ogf-compute ggflistowners --> ogflistowners ggfstudentmembers --> ogfstudentmembers Postings to the old list names get forwarded to the new ones. With the migration we have also been able to fix the archives - you may have noticed that list archiving stopped sometime in mid June. Well, now its working again, and all mails from June to now have been added to the archive. The list archives can be found at: http://www.ogf.org/archives/<list> If you are an list administrator, and would like to receive the list admin password, please contact postmaster(a)ogf.org. In general, however, we tried to map the old majordomo settings to the mailman settings, in terms of privacy etc, so no or little changes should be required from your side. The spam avoidance policy has been changed to some extent, and is somewhat stricter than before. Please let us know if you experience any trouble with that. On all questions in respect to mailing lists, or mails in general, please contact postmaster(a)ogf.org. Best regards, Andre. -- "So much time, so little to do..." -- Garfield -- wg-all mailing list wg-all(a)ogf.org http://www.ogf.org/mailman/listinfo/wg-all

1 0

IGTF, CAOps, other activities at GGF 18
by Alan Sill 29 Aug '06

29 Aug '06

It would be nice to compile a list of topics and sessions of interest for CA operations and related topics at GGF 18. Does anyone have such a list started? Alan Alan Sill TIGRE Senior Scientist High Performance Computing Center TTU ==================================================================== : Alan Sill, Texas Tech University Office: Admin 233, MS 4-1167 : : e-mail: Alan.Sill(a)ttu.edu ph. 806-742-4350 fax 806-742-4358 : ====================================================================

6 10

Re: AW: [igtf-general] Re: [caops-wg] Certificate Profile document, update v0.5
by David Groep 16 Aug '06

16 Aug '06

Hi Ursula, all, Epting, Ursula wrote: > Dear Jens, David and all, the document is very well done, good work! I've > added some small comments and (possible) corrections of typos (using word > track changes on Jens' doc, after accepting all his changes) I've merged these in and produced version 0.8 - now on the web at http://www.eugridpma.org/temporary/ Most of the comments I've just merged, some are discussed below: * in section 2.1, on the serial number stuff: I've created a new subsection ("2.2 Serial Number") and put all this text there. * in section 3.1, "version number must be set to "2"": this is indeed the encoding of the version number in the first INTEGER of the certificate * section 3.2.1 "dNSName" and others funky capitalisation taken from the standards documents (where things never start with a capital letter) * On the Unicore need for "nsCertType: server, client" I've not seen this requirement before (of having a need for *both* server *and* client being asserted here). If you can dig up the email, I'll be very happy. Please do. * Section 4.2 "Key lengths and hashed" Since SHA-256 is not supported, we'll have to live with SHA-1 for the time being, despite it having only 80 bits effective. Thanks a lot, DavidG. > > Mit freundlichen Gruessen/ With kind regards > > Ursula Epting > > Ursula Epting Forschungszentrum Karlsruhe Institut fuer Wissenschaftliches > Rechnen (IWR) Grid Infrastruktur und Services (GIS) Tel. +049 (0)7247-82-6786 > Fax +049 (0)7247-82-7786 e-mail: ursula.epting(a)iwr.fzk.de > ----------------------------------------------- GridKa-Zertifikat > SHA1-Fingerprint: > 0B:DD:25:06:98:74:D6:81:DD:1E:AF:2F:AD:7A:EA:10:75:CE:7E:6E > ----------------------------------------------- > ************************************************************************** > The Institute for Scientific Computing of Forschungszentrum Karlsruhe will > again run its annual GridKa School from September 11-15, 2006. Please find > further information at http://www.fzk.de/gks06 . > ************************************************************************** > > > > > >> -----Ursprüngliche Nachricht----- Von: Jensen, J (Jens) >> [mailto:J.Jensen@rl.ac.uk] Gesendet: Dienstag, 15. August 2006 09:31 An: >> David Groep; dg-eur-ca(a)services.cnrs.fr Cc: All IGTF Members >> (igtf-general); CAOPS-WG Betreff: RE: [igtf-general] Re: [caops-wg] >> Certificate Profile document, update v0.5 >> >> >> David, I have now finally had time to go through the document and made only >> a few changes. And fixed a few bugs, like commonName cannot use IA5String >> as encoding. I used Word's change tracker. >> >> http://www.grid-support.ac.uk/files/eugridpma-certprofile-2006 >> 0814-0-6-jens.doc >> >> What would be the consequences of saying in 4.1 "RDNs MUST be in the Right >> Order". Will we lose SWITCH and Purdue? >> >> Would it be worth expanding section 5 into a general annotated openssl.cnf? >> If new CAs feel this would be useful, I will be happy to provide something >> (if so, please reply to me). >> >> The document has also gradually started to describe how software deals with >> certificates - browsers, OpenLDAP, etc. This could be expanded. >> >> Thanks, --jens >> >> >> -----Original Message----- From: owner-caops-wg(a)ggf.org >> [mailto:owner-caops-wg@ggf.org]On Behalf Of David Groep Sent: 14 August >> 2006 13:08 To: dg-eur-ca(a)services.cnrs.fr Cc: All IGTF Members >> (igtf-general); CAOPS-WG Subject: Re: [igtf-general] Re: [caops-wg] >> Certificate Profile document, update v0.5 >> >> >> Hi Reimer, >> >> Thanks for the comments. Answers in-line, and a new document is on the web >> at >> >> >> http://www.eugridpma.org/temporary/eugridpma-certprofile-20060 814-0-6.pdf >> >> http://www.eugridpma.org/temporary/eugridpma-certprofile-20060 814-0-6.doc >> >> >> Reimer Karlsen-Masur, DFN-CERT wrote: >> >>> ... In section 2.2: >>> >>> Within the Issuer and Subject DNs, the following attributes >> >> *are known >> >>> to cause problems*: >> >> That was a piece of legacy text that I ought to have removed. As the >> document was restructure, this is now a plain list of attributeTypes. >> >> >>> 2.2.4 DomainComponent, country, organization, >> >> organizationalUnit, etc. >> >>> ... 2.2.5 commonName ... >>> >>> I am confused. Why are these causing problems, except maybe for multiple >>> RDNs of same name (except for DCs)? >> >> Multiple "O"'s are OK, and even multiple CNs are rumoured to be OK (the >> CERN-IS CA will find out :-) >> >> >>> In section 3.3.8 only some forms of the AKI block the in-place >>> replacement of CA certificates. If the AKI does only >> >> contain the hash >> >>> value I think it is working fine. IMO this hash only >> >> changes if the CA >> >>> key changes. And "in-place replacement" means extending the >> >> lifetime of >> >>> a CA certificate and maybe changing the serial number but >> >> nothing else, >> >>> right? >>> >>> If the AKI of an EE cert contains the dirname (i.e. the >> >> subject DN) of >> >>> the issuing CA issuing CA (note: this is the right number >> >> of repetitions >> >>> of "issuing CA" cause it is the *issuer* DN of the EE certs >> >> issuing CA >> >>> cert) plus the EE certs issuing CAs certificate serial number the >>> problems start when the replacement CA certificate gets a >> >> new serial >> >>> number (which it should as to sections above). >>> >>> When an in-place CA cert replacement is eventually planned >> >> for in the >> >>> future and this will come with a CA key change, above does >> >> not apply and >> >>> it is better to not use AKIs at all. >> >> This updated text should be better: The authorityKeyIdentifier is not >> usually interpreted by the software. It is not known to cause issues with >> grid software, as it is ignored. The extension MUST NOT be marked critical. >> >> >> If the AKI contains information that changes when the CA certificate is >> modified, it will block any "smooth" replacement of CA certificates (i.e. >> updating a CA certificate to modify the expiry date). Possible attributes >> in AKI include the directoryName of the authority that issued the issuer >> certificate (safe as it should not change) plus the serial number (which >> may or may not change), and/or the keyId of the end-entity issuing CA. If >> the keyIdentifier has been generated using one of the two recommended >> methods from RFC3280 (i.e. is purely derived from the public key value), it >> will not impair smooth replacement. >> >> >> >>> AKIs are also used in (Sub-)CA certificates, so similar apply there. >>> >>> In section 3.3.12 the AIA could additionally/alternatively hold the >>> issuing CAs certificate download URI. Can also be set in Sub-CA >>> certificates. This can be used to automatically retrieve CA >> >> certs for >> >>> validation path building and path validation. IMO at least >> >> Microsoft's >> >>> smart card Single-Sign-Logon is using these. >> >> Added to 3.3.12. >> >> Cheers, DavidG. >> >> >> >> -- David Groep >> >> ** National Institute for Nuclear and High Energy Physics, PDP/Grid group >> ** ** Room: H1.56 Phone: +31 20 5922179, PObox 41882, NL-1009DB Amsterdam >> NL ** >> >> >> -- David Groep ** National Institute for Nuclear and High Energy Physics, PDP/Grid group ** ** Room: H1.56 Phone: +31 20 5922179, PObox 41882, NL-1009DB Amsterdam NL **

1 0