- caops-wg - lists.ogf.org

DockerCon EU: Trust and Image Provenance | Docker Blog
by Sill, Alan 20 Jan '15

20 Jan '15

Thought you would be interested in the following link. Topic: demo of a proof of concept showing what is possible using public key cryptography for establishing trust within the Docker engine Link: http://blog.docker.com/2015/01/dockercon-eu-trust-and-image-provenance/ Alan

1 0

OASIS #PKCS 11 TC publishes 3 Committee Specifications and 1 Committee Note
by Sill, Alan 30 Dec '14

30 Dec '14

Thought you would be interested in the updates published at the following link. Topic: OASIS is pleased to announce the approval and publication of three new Committee Specifications and a Committee Note by the members of the OASIS PKCS 11 TC: PKCS #11 Cryptographic Token Interface Base Specification Version 2.40 Committee Specification 02 16 November 2014 PKCS #11 Cryptographic Token Interface Current Mechanisms Specification Version 2.40 Committee Specification 02 16 November 2014 PKCS #11 Cryptographic Token Interface Historical Mechanisms Specification Version 2.40 Committee Specification 02 16 November 2014 PKCS #11 Cryptographic Token Interface Usage Guide Version 2.40 Committee Note 02 16 November 2014 Overview: The PKCS #11 Base Specification provides normative definition of PKCS #11 objections, attributes and operations. The PKCS #11 Current Mechanisms document describes the application of PKCS #11 objects, attributes and operations for specific mechanisms currently in general use. The PKCS #11 Historical Mechanisms document describes the application of PKCS #11 objects, attributes and operations for specific mechanisms that have been but are no longer in general use. The PKCS #11 Cryptographic Token Interface Usage Guide provides guidance on using PKCS #11 v2.40. Link: https://www.oasis-open.org/news/announcements/the-oasis-pkcs-11-tc-publishe… Alan

1 0

OASIS KMIP TC publishes 11 Committee Specifications and 2 Committee Notes On Key Management
by Sill, Alan 16 Dec '14

16 Dec '14

Thought you would be interested in the following link. Topic: The Key Management Interoperability Protocol (KMIP) is a single, comprehensive protocol for communication between clients that request any of a wide range of encryption keys and servers that store and manage those keys. By replacing redundant, incompatible key management protocols, KMIP provides better data security while at the same time reducing expenditures on multiple products. These documents are intended for developers and architects who wish to design systems and applications that interoperate using the Key Management Interoperability Protocol Specification. Link: https://www.oasis-open.org/news/announcements/the-kmip-tc-publishes-11-comm… Alan

1 0

Fwd: MAGIC meeting, November 18, 2:00-4:00, SC14, Room 264
by Sill, Alan 12 Nov '14

12 Nov '14

For those who are attending Supercomputing 2014, the following session may be of interest. (MAGIC is the US government inter-agency group charged with coordinating activity and information on networking and middleware services.) Alan Begin forwarded message: > Resent-From: <lsn-magic(a)nitrd.gov> > From: Von Welch <vwelch(a)iu.edu> > Subject: Re: MAGIC meeting, November 18, 2:00-4:00, SC14, Room 264 > Date: November 12, 2014 at 3:47:19 PM CST > To: "Miller, Grant CTR" <miller(a)nitrd.gov>, lsn-magic <lsn-magic(a)nitrd.gov> > > Grant, all, > > An agenda for our meeting on the 18th is attached. > > Von > > > On 11/7/14 8:58 AM, Miller, Grant CTR wrote: >> Colleagues, >> >> Our next MAGIC meeting is Tuesday, November 18 from 2:00-4:00 local time at the SC14 Convention Center, Room 264. Von Welch is organizing a session on international Identity Management to take advantage of the SC14 participants (Thank you Von!). >> >> I attach brief minutes form our October MAGIC meeting. I welcome all comments and suggestions for these minutes. Also attached is a statement of the LSN tasking to MAGIC for the upcoming year. >> >> This meeting will not be supported by teleconference or WebEx but I will post minutes and presentations on the MAGIC Web site. >> >> >> >> I look forward to seeing you at SC14! >> >> >> >> Regards, >> >> Grant Miller (contractor) >> >> NCO/QinetiQ-NA >> >> Coordinator: High End Computing, Large Scale Networking >> >> miller(a)nitrd.gov <mailto:miller@nitrd.gov> >> >> 703 292 4873 >> >> >> >> >> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------! > > --- >> All e-mails to and from this account are for NITRD official use only and subject to certain disclosure requirements. >> If you have received this e-mail in error, we ask that you notify the sender and delete it immediately. >

1 0

Fwd: [pkix] Proposed revisions to X.509
by Sill, Alan 26 Sep '14

26 Sep '14

FYI - information provided by Tony Rutkowski below. Alan Begin forwarded message: From: Tony Rutkowski <tony(a)yaanatech.com> Subject: [pkix] Proposed revisions to X.509 Date: September 25, 2014 at 3:31:06 PM GMT+2 To: Kathleen Moriarty <kathleen.moriarty.ietf(a)gmail.com>, Stephen Farrell <stephen.farrell(a)cs.tcd.ie> Cc: <pkix(a)ietf.org>, <smime(a)ietf.org> Reply-To: <tony(a)yaanatech.com> PKIX and IETF/CABF groups - as part of their collaborative roles - may be interested in the proposed amendment document just published. -t _______________________________________________ pkix mailing list pkix(a)ietf.org https://www.ietf.org/mailman/listinfo/pkix

1 0

Fwd: [Nsi-wg] slides for NSI AA presentation Monday 22 September 2014
by Sill, Alan 22 Sep '14

22 Sep '14

FYI. Review and thoughts to the author are recruited (by me). Thoughts welcome on how we can improve communication among and between members of the OGF groups, and more widely between the networking and security portions of the community on this topic. Alan Begin forwarded message: From: Hans Trompert <hans.trompert(a)surfnet.nl<mailto:hans.trompert@surfnet.nl>> Date: September 19, 2014 at 12:40:29 PM CDT To: "nsi-wg(a)ogf.org<mailto:nsi-wg@ogf.org>" <nsi-wg(a)ogf.org<mailto:nsi-wg@ogf.org>> Subject: [Nsi-wg] slides for NSI AA presentation Monday 22 September 2014 Hi, Please find attached my slides for the NSI AA presentation Monday 22 September 2014 in Uppsala. Cheers, HansT.

2 1

Fwd: useful information about bestman2 and SHA2 host certificates
by Sill, Alan 13 Sep '14

13 Sep '14

Hmm, more in the SHA2 and jglobus story below. Any other related experience out there? Alan Begin forwarded message: From: Horst Severini <hs(a)nhn.ou.edu> Subject: useful information about bestman2 and SHA2 host certificates Date: September 13, 2014 at 2:56:49 AM GMT+1 To: <osg-sites(a)OPENSCIENCEGRID.ORG>, <usatlas-t2-l(a)lists.bnl.gov> Cc: <adt027(a)latech.edu>, <hs.greenw(a)phys.latech.edu> Reply-To: <hs(a)nhn.ou.edu> Hi all, since we just found out the hard way, I thought I'd send an email and warn people who may run up against the same issue fairly soon. This is documented somewhere, but I'm not sure how many people actually know about it -- at least I hadn't read it before. =) So the problem is that if you request a new hostcert on a RHEL6/SL6/CentOS6 machine with the latest openssl version installed, then the hostkey which that procedure produces won't work with bestman2; somehow the version of jglobus that bestman2 uses doesn't like it. The details are here: https://twiki.grid.iu.edu/bin/view/Documentation/Release3/InstallOSGBestman… In a nutshell, the solution seems to be to run the following command on the newly produced hostkey file: openssl rsa -in hostkey.pem -out hostkey.pem.old Then move the original hostkey.pem out of the way, rename hostkey.pem.old back to hostkey.pem, and then make a copy of that to bestman/bestman.key as well, as usual for bestman2. At least that worked for us, Joel Snow tested it. Thanks to Wei Yang for reminding us about this issue. By the way, the DigiCert certificate expiration reminder email system is currently being fixed, too -- well, it has been fixed, but this fix will most likely be deployed on September 23 during the monthly maintenance, so you may want to have a closer look at all your certificates as well and make sure none of them expire before that. We were also bitten by that. :) Cheers, Horst

2 1

Linux Journal Article: Provisioning X.509 using RFC 7030
by Sill, Alan 12 Sep '14

12 Sep '14

Thought this article would be of interest to the group, given discussions on similar topics today. Alan

1 0

Re: [caops-wg] [Nsi-wg] [voms-proc-wg] OGF NSI networking architecture and need for certificates with restricted user base
by Sill, Alan 31 Jul '14

31 Jul '14

Hi John, I'd like to point out that the International Grid Trust Federation - http://igtf.net - was established specifically to provide a high-quality source of trusted CAs used in global research cyberinfrastructure and has been fulfilling this role for many years. These certificates, both for individuals and for hosts or services, provide the trust federation basis for large-scale computational grids and associated cloud projects, and might be a good source for your project. Generally obtaining grid certificates is available through national research and education initiatives or associated projects. OGF is on the verge of announcing free availability of these certificates to its members to make them available more broadly, and in addition will be supporting the availability of commercially trusted certificates (useful for those cases where you do want the certificate pre-loaded without going through installing an IGTF trust store to support your application) at discounted rates from the same supplier as the free grid ones. We do have a pretty well developed authorization community that can help with implementation issues like the ones that you mentioned. As for the widespread availability of certificates, this is generally seen as a good thing, depending on your needs. Obtaining a certificate from a commercial CA is easy, of course, and doesn't require the individual identity verification that is required by at least some of the IGTF profiles. For control-plane peering of service agents, I assume that simple possession of a valid certificate is not enough, and what you need is an authorization layer that says that a particular DN is allowed to carry out operations on the network function being controlled. We had planned to put together a workshop on identity management for software defined networking for SC'14, but I don't think we got that submitted in time. This sounds like a topic that would be good to discuss at an OGF meeting or other gathering of the NSI group. Alan On Jul 31, 2014, at 6:21 PM, John MacAuley <macauley(a)es.net> wrote: > Yes, I was indeed mixing authentication and basic authorization. I have solved the issue by adding certification DN authorization in Apache after the TLS session is established. It is just too bad TLS gets established in the first place with these wide ranging CAs. Seems a bit senseless in the grand scheme of security. > > Java based implementations can override the default SSL Engine to give customized handling of the certificates, which solves my problem during the negotiation phase. Unfortunately, not everyone can do this. > > "Self-signed certificates will not scale." - It really depends on the deployment requirements of the application. We are discussing control plane peering of service agents, of which an organization will typically have a handful to tens for the foreseeable future. I would not use self-signed for use cases where I am dealing with 100 - 1,000s of clients. In that case it definitely does not scale. However, having to provision 1,000s of access control lists to restrict access does not scale as well. If this was the case an entirely different solution would be required that does not depend on SSL/TLS for anything other than encryption. > > As they say, six of one, half a dozen of the other. > > Thank you for the feedback. > > John > > On 2014-07-31, at 10:58 AM, Mischa Salle <msalle(a)nikhef.nl> wrote: > >> Hi Alan, >> >> I think he's mixing authentication and authorization. If I look at >> page 10, my reaction is, there is nothing wrong in trusting that client >> cert #2 is client cert #2, that's only the authentication part. That >> doesn't mean you also *allow* client cert #2. Same on page 11, trusting >> a certificate there should mean trusting that the identity is what it >> claims to be. Doesn't mean allowing it to enter. >> If this is indeed his whole use-case, I would say, go for (a subset of) >> public CAs and restrict access based on specific DNs. That gives you >> still all the revocation and renewal possibilities while at the same >> time allowing for restricted access. >> A private CA could work, but is a lot of work, and not trivial to keep >> safe... Self-signed certificates will not scale. They give no way of >> revocation, big problems with expiry etc. >> If they need more advanced authZ, such as based on certain roles, than >> indeed VOMS attribute certificates might be useful, although that would >> mean software adaptations. >> >> Best wishes, >> Mischa Sallé >> >> On Wed, Jul 30, 2014 at 03:34:08PM +0000, Sill, Alan wrote: >>> Dear folks in the OGF CAOPS, VOMS-PROC and NSI working groups. >>> >>> I'd like to initiate some discussion among the participants in these >>> working groups for the use case referred to in the talk at the link >>> below. >>> >>> Some review of the conditions for this use case would be helpful. Note >>> this is also a use case that comes up in Internet-of-Things >>> discussions, and has caused some discussion on the PKIX group list >>> (though that group is now dormant of course) and other related lists >>> lately. >>> >>> To me this is a familiar situation with well-known parameters, but >>> possibly some additional considerations, and might possibly lead to >>> some useful communication among the members in these groups about >>> solutions that could be applied using existing technologies that would >>> avoid the possible downsides associated with the proposed use of >>> self-signed certificates. (For example, extended attribute >>> certificates as used in VOMS, though the same or perhaps through a >>> different implementation, might be a good solution here; other >>> solutions might be contemplated that would be more attractive than >>> self-signed certificates for this situation.) >>> >>> Your comments, discussion and input are recruited (by me -- I'm not >>> speaking for the NIS-WG members per se!), and I hope that all parties >>> will regard this as useful discussion for information exchange only. >>> >>> Thanks, >>> Alan >>> >>> Begin forwarded message: >>> >>> From: Guy Roberts <Guy.Roberts(a)dante.net<mailto:Guy.Roberts@dante.net>> >>> Subject: RE: [Nsi-wg] Wednesday's NSI conf call >>> Date: July 30, 2014 at 1:30:19 PM GMT+2 >>> To: Alan Sill <kilohoku150(a)gmail.com<mailto:kilohoku150@gmail.com>> >>> >>> Hi Alan, >>> >>> Please find the slides on NSI security here: >>> >>> https://redmine.ogf.org/dmsf/nsi-wg?folder_id=6592 >>> >>> The proposal is that NSAs will run their own private Certificate Authorities (self-signing) rather than using public Certificate Authorities. Participating NSAs will then exchange information about each other’s Certificates in an ad hoc way. >>> >>> This solution does not scale well as private Certificates have to be manually shared, but it reduces the size of the certificate pool. >>> >>> Guy >>> >>> From: Alan Sill [mailto:kilohoku150@gmail.com] >>> Sent: 30 July 2014 10:56 >>> To: Guy Roberts >>> Cc: Alan Sill >>> Subject: Re: [Nsi-wg] Wednesday's NSI conf call >>> >>> Guy, >>> >>> On Jul 30, 2014, at 11:02 AM, Guy Roberts <Guy.Roberts(a)dante.net<mailto:Guy.Roberts@dante.net>> wrote: >>> >>> - comments/feedback from last week’s presentation from John on ‘Secure Communications with Self Signed Certificates’ >>> >>> Are copies of these slides available? I would like to understand the context. >>> >>> (In general, use of self-signed certificates is risky at best, so I would like to understand the use case here.) >>> >>> Alan >>> >> >>> _______________________________________________ >>> voms-proc-wg mailing list >>> voms-proc-wg(a)ogf.org >>> https://www.ogf.org/mailman/listinfo/voms-proc-wg >> >> >> -- >> Nikhef Room H155 >> Science Park 105 Tel. +31-20-592 5102 >> 1098 XG Amsterdam Fax +31-20-592 5155 >> The Netherlands Email msalle(a)nikhef.nl >> __ .. ... _._. .... ._ ... ._ ._.. ._.. .._.. >> _______________________________________________ >> nsi-wg mailing list >> nsi-wg(a)ogf.org >> https://www.ogf.org/mailman/listinfo/nsi-wg > > _______________________________________________ > nsi-wg mailing list > nsi-wg(a)ogf.org > https://www.ogf.org/mailman/listinfo/nsi-wg

1 0

OGF NSI networking architecture and need for certificates with restricted user base
by Sill, Alan 30 Jul '14

30 Jul '14

Dear folks in the OGF CAOPS, VOMS-PROC and NSI working groups. I'd like to initiate some discussion among the participants in these working groups for the use case referred to in the talk at the link below. Some review of the conditions for this use case would be helpful. Note this is also a use case that comes up in Internet-of-Things discussions, and has caused some discussion on the PKIX group list (though that group is now dormant of course) and other related lists lately. To me this is a familiar situation with well-known parameters, but possibly some additional considerations, and might possibly lead to some useful communication among the members in these groups about solutions that could be applied using existing technologies that would avoid the possible downsides associated with the proposed use of self-signed certificates. (For example, extended attribute certificates as used in VOMS, though the same or perhaps through a different implementation, might be a good solution here; other solutions might be contemplated that would be more attractive than self-signed certificates for this situation.) Your comments, discussion and input are recruited (by me -- I'm not speaking for the NIS-WG members per se!), and I hope that all parties will regard this as useful discussion for information exchange only. Thanks, Alan Begin forwarded message: From: Guy Roberts <Guy.Roberts(a)dante.net<mailto:Guy.Roberts@dante.net>> Subject: RE: [Nsi-wg] Wednesday's NSI conf call Date: July 30, 2014 at 1:30:19 PM GMT+2 To: Alan Sill <kilohoku150(a)gmail.com<mailto:kilohoku150@gmail.com>> Hi Alan, Please find the slides on NSI security here: https://redmine.ogf.org/dmsf/nsi-wg?folder_id=6592 The proposal is that NSAs will run their own private Certificate Authorities (self-signing) rather than using public Certificate Authorities. Participating NSAs will then exchange information about each other’s Certificates in an ad hoc way. This solution does not scale well as private Certificates have to be manually shared, but it reduces the size of the certificate pool. Guy From: Alan Sill [mailto:kilohoku150@gmail.com] Sent: 30 July 2014 10:56 To: Guy Roberts Cc: Alan Sill Subject: Re: [Nsi-wg] Wednesday's NSI conf call Guy, On Jul 30, 2014, at 11:02 AM, Guy Roberts <Guy.Roberts(a)dante.net<mailto:Guy.Roberts@dante.net>> wrote: - comments/feedback from last week’s presentation from John on ‘Secure Communications with Self Signed Certificates’ Are copies of these slides available? I would like to understand the context. (In general, use of self-signed certificates is risky at best, so I would like to understand the use case here.) Alan

1 0