- caops-wg - lists.ogf.org

Web Authentication: An API for accessing Public Key Credentials Level 1
by Sill, Alan 17 Jan '19

17 Jan '19

Thought you would be interested in the following link. Topic: Web Authentication: An API for accessing Public Key Credentials Level 1 W3C Proposed Recommendation, 17 January 2019 Link: https://www.w3.org/TR/2019/PR-webauthn-20190117/ Publication history: https://www.w3.org/standards/history/webauthn Alan

1 0

Fwd: Change in Subject Alternative Names policy for host certificates issued by the CERN CA
by Sill, Alan 19 May '17

19 May '17

Begin forwarded message: From: Paolo Tedesco <Paolo.Tedesco(a)cern.ch<mailto:Paolo.Tedesco@cern.ch>> Date: May 19, 2017 at 4:24:30 AM CDT To: "dg-eur-ca(a)services.cnrs.fr<mailto:dg-eur-ca@services.cnrs.fr>" <dg-eur-ca(a)services.cnrs.fr<mailto:dg-eur-ca@services.cnrs.fr>> Cc: Emmanuel Ormancey <Emmanuel.Ormancey(a)cern.ch<mailto:Emmanuel.Ormancey@cern.ch>>, Thomas Baron <Thomas.Baron(a)cern.ch<mailto:Thomas.Baron@cern.ch>>, Daniel Fernandez Rodriguez <daniel.fernandez(a)cern.ch<mailto:daniel.fernandez@cern.ch>> Subject: Change in Subject Alternative Names policy for host certificates issued by the CERN CA Reply-To: Paolo Tedesco <Paolo.Tedesco(a)cern.ch<mailto:Paolo.Tedesco@cern.ch>> Dear all, As you probably know, recently Google Chrome has stopped supporting the common name in host certificates (https://groups.google.com/a/chromium.org/forum/#!msg/security-dev/IGT2fLJrA…) and now expects the certificate to contain a DNS Subject Alternative Name. After this change, we have started receiving support cases for the CERN Certification Authority about CERN certificates being rejected by Chrome. For this reason, we would like to introduce a new requirement in our CP/CPS, stating that host certificate requets must contain a SAN in DNS format matching the host in the certificate subject. I'm attaching the updated CP/CPS document for review. The changed sections are 4.1.2 (for host certificates autoenrollment) and 4.2.1 (for user submitted requests). If I don't get any objections by Monday 5 June, I'll publish the updated CP/CPS and proceed to update the tools and the website to be compliant with the new policies. Best regards, Paolo

1 0

Apropos Certificate Transparency
by Jensen, Jens (STFC,RAL,SC) 15 Mar '17

15 Mar '17

... this may be of interest to CAOPS as it provides some information around the deployment of RFC6962 and aims to address privacy concerns. Also note there's a 6962-bis. https://arxiv.org/abs/1703.02209 Mind you if there were privacy concerns I'd just build my own CT service and keep it hidden and use the signed metadata in TLS connections (the SCT). However, that sort of loses the "transparency" part as transparency is only available privately. One fine day when I have a spare moment I shall work again on my implementation - you may recall that I implemented the Merkle tree half - the one that provides the irreversible(ish) logs - but not the other bits. Regards --jens

1 0

[cabfpub] Future of WebPKI at F2F
by Sill, Alan 12 Mar '17

12 Mar '17

Thought you would be interested in the following link. I am not involved with this effort, but thought this would be of interest to the CAOPS group and IGTF community. Topic: Future of WebPKI at F2F "At the upcoming F2F we have several agenda slots to discuss the Future of WebPKI. I've agreed to shepherd these slots. We are going to use an unconference format for these slots. We will collect a list of potential discussion topics and spend a little time on Wednesday sorting them and getting indications of interest in each topic. We will then take the ones with the highest interest and run three sets of breakout sessions to discuss them. For each breakout session slot there will be multiple simultaneous topics. At the end of each breakout, we will convene back as a large group and hear a brief (10 minute) summary from each breakout. Potential topics can come from anyone. I would invite people to post ideas to the public list or questions list or to email me directly. At the F2F, there will be a drop box for additional ideas that will be open through lunch on Wednesday. If you are not attending the F2F, or are not a Forum member, please still contribute topics you think we should consider discussing. Here are some ideas of either topics to discuss or goals for the WebPKI that can inspire a discussion topic: * How do we get to 95%+ of websites available over HTTPS with strong ciphersuites? * Making HTTPS the default mode of browsers and making HTTP connections specifically marked as untrusted * Full publication for all issued publicly-trusted certificates, whether that%u2019s via CT, a related mechanism, or something else entirely * Certificate lifetime reduction to 13 months within 3 years, and 3-6 months in 5 years * Much greater use of automation for certificate replacement, using standard protocols * CAA fully deployed and implemented * Multiple hash functions widely supported * Better elliptic curves widely supported * Initial support for post-quantum crypto algorithms * What should the role of RAs be in the WebPKI? * Should we have a base set of expectations for publicly trusted CAs regardless of type of certificate? * How should CT information be delivered? Should all CAs include SCTs in OCSP responses? * What requirements should there be on the use of virtualization technology when used in CA systems? * Should name constrained CAs exist in the WebPKI? If so, what value do they provide? * How do we enable more algorithms in the WebPKI (for example, EC signature standards from around the world)? * Enhancing DANE with EV -- giving website owners the best of both worlds * Using signature malleability to expedite certificate issuance * High assurance favicons using polyglot certificates To be clear, not all of these will be discussed or are even good ideas. We will decide what to discuss at the F2F." Link: https://cabforum.org/pipermail/public/2017-March/010023.html Alan

1 0

CAOPS WG GFD-R.225 revised version (final)
by David Groep 23 Mar '16

23 Mar '16

Dear all, Following on from the long trajectory towards an update/recommendation of GFD.25, all comments received during the latest round, as well as all the comments made during the latest CAOPS remote meeting in January this year, have now been incorporated in the document https://redmine.ogf.org/dmsf_files/25 with the source version at https://redmine.ogf.org/attachments/226/igtf-certificate-profile-GFD225-201… dated March 2016. Thanks again to everyone for commenting: I propose that Jens now pushes this version to the editor ... unless people spot obvious mistakes still in the coming weeks. Shall we consider this to be the WG last call on the version? Best, DavidG. -- David Groep ** Nikhef, Dutch National Institute for Sub-atomic Physics,PDP/Grid group ** ** Room: H1.50 Phone: +31 20 5922179, PObox 41882, NL-1009DB Amsterdam NL **

2 1

Draft NIST Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths
by Sill, Alan 31 Jul '15

31 Jul '15

Perhaps of interest to this group: Draft NIST Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths http://csrc.nist.gov/publications/PubsDrafts.html#800-131Ar1 Comments due 14 Aug 2015 Alan

1 0

Information on RFC 7517 "JSON Web Key (JWK)", May 2015
by Sill, Alan 21 May '15

21 May '15

Thought you would be interested in the following link. Topic: RFC 7517 "JSON Web Key (JWK)", May 2015 Abstract A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification. Link: http://www.rfc-editor.org/info/rfc7517 Alan

1 0

Street/PostalCode and Grid Certificate Profile
by Basney, Jim 30 Apr '15

30 Apr '15

Hi, Am I too late to make a comment on the update to GFD.125? I'd like to propose adding Street and PostalCode to the "subject name RDN component recommendations" with a recommendation of "should not be used". We find that these RDN components are not displayed consistently across software, and that Java's X500Principal class rejects PostalCode outright with java.io.IOException: Invalid keyword "POSTALCODE". Unfortunately these RDN components made their way into some certificates issued by the InCommon IGTF Server CA, which we are now working to correct. Thanks, Jim

2 1

Vault - HashiCorp
by Sill, Alan 28 Apr '15

28 Apr '15

Thought you would be interested in the following link. (For information only, no association and endorsement implied.) Topic: Vault APR 28 2015 MITCHELL HASHIMOTO Today we announce Vault %u2014 a tool for securely managing secrets and encrypting data in-transit. From storing credentials and API keys to encrypting passwords for user signups, Vault is meant to be a solution for all secret management needs. Link: https://hashicorp.com/blog/vault.html One link of interest: http://vaultproject.io/intro/vs/hsm.html Alan

1 1

Open Identity Exchange Launches OIXnet: A Global Registry for Trust Frameworks | Business Wire
by Sill, Alan 23 Apr '15

23 Apr '15

Trust frameworks based on OpenID are emerging, FYI - see below. Alan http://www.businesswire.com/news/home/20150422005217/en/Open-Identity-Excha…

2 2