On 08/27/2018 04:07 PM, Hubert Kario wrote:
On Monday, 27 August 2018 20:57:53 CEST Robert Moskowitz wrote:
On 08/27/2018 02:33 PM, Hubert Kario wrote:
On Thursday, 23 August 2018 16:35:01 CEST Robert Moskowitz wrote:
On 08/23/2018 09:00 AM, Tomas Mraz wrote:
On Wed, 2018-08-22 at 20:08 -0400, Robert Moskowitz wrote:
On 08/22/2018 11:48 AM, Matt Caswell wrote:
On 22/08/18 00:53, Robert Moskowitz wrote:
On 08/21/2018 06:31 PM, Matt Caswell wrote:
On 21/08/18 16:24, Robert Moskowitz wrote:
Thanks!
Once Fedora beta picks this up, I will run my scripts against
it and see
if all cases of hash with ED25519 are fixed.
Unfortunately the command line usability changes for this
didn't make it
into the beta. They should still be in the final release.
Sigh. That means you will get it right. Right? :)
Change seems simple enough.
The relevant change has now been merged to master.
Fedora had already built pre9.1. But on the off chance, I will look
at
it with tomorrow's build.
I'm sorry but no, I am not updating Fedora with current git tree
checkout. You'll have to wait for the next prerelease or the final
version if there are no further prereleases.
Tomas,
Thanks for responding here.
I have been preparing an Internet Draft on how to build an ED25519 pki.
I know have the choice of:
building my own 1.1.1 pre9 for testing.
Wait to push the draft out until 1.1.1 is fully released.
Fudge the draft by adding yet another caveat (yes there is a caveat
section that I developed in creating the ECDSA pki draft) that the
commands are for how it is suppose to work in production 1.1.1, not what
I had to do in the prerelease.
Decisions decisions. Thing is I want the draft out so I can push for
EDDSA support in IEEE 802.1AR with the next meeting early Sept.
I'm not sure if providing command line examples for one particular tool
are a good idea...
Example certificates, sure, but not commands to generate them...
"We can't test out the security part of the protocol because we cannot
get certificates"
"We ran our tests with security disable because we could not afford the
cost and time for a test pki."
"We did test with RSA certificates from vendor A." (and they were using
old libs that would not support ecdsa, but marketed it as such.)"
Over the years and in protocol design development, I have heard too many
we can't. So I set about with, "here is one way." Since then I have
had a few people actually thank me for making it possible for them to
build an ecdsa pki for their product testing needs. Just one justifies
my effort.
well, I see nothing wrong with providing documentation and how-to's, I just
don't see that it should be elevated to an Internet Draft level...
by its very nature it needs to be constantly updated, so having it in a static
RFC is contrary to that
that is the value of Internet Drafts that many of us IETFers have
figured out. draft versions can just keep on going and the tools will
take you to the current draft. IDs have become neat working documents,
though there is more github work coming along. More workgroups are
doing requirements docs that will never be published as RFCs; they will
stay as IDs. Much better source of why did the wg do? than plow through
the old mailing list archives. The IESG is actually encouraging such a
use of IDs.
now, for generating testing certificates (and what's more important, the whole
PKI) we are using this script to provide sensible defaults and easy way to
generate certificates with just few options departing from those defaults:
https://github.com/redhat-qe-security/certgen
I will take a look at this. It did not come up in my google searches a
year ago. Guess just not asking the right question or github is
protected from google...
to get a PKI you run those commands:
source certgen/lib.sh
x509KeyGen ca
x509KeyGen server
x509SelfSign ca
x509CertSign --CA ca server
The private key file will be printed by use of:
x509Key server
to get certificate file name you run:
x509Cert server
In testing situations I have been in, intermediate CAs, revocation, the
like are needed.
Plus getting more interest in 802.1AR certs with vendors (can't get
certs to test out my product design).
(easy switches are also provided to get DER files or PKCS#12 files instead of
the default PEM format)
I will be interested to see how you handle DER, as I found cases where
the command line was broken. Read my caveat section. In some cases you
have to make the file in PEM then convert to DER. Plus there is no DER
way to handle cert chains as was discussed here a year ago. So I will
be interested to see how you handle cert chains non-PEM.
to get ecdsa certificate, you just need to change one of the above lines
with x509KeyGen to have `-t ecdsa` specified. Want RSA-PSS certificate? do `-t
rsa-pss`.
See runtest.sh for other examples.
I will take a look.
It is compatible with all versions of openssl since RHEL-4 (so 0.9.7), if a
given feature is supported in that version of openssl.
(while ed25519 support is not yet there, it will be in few weeks, I was
running just basic tests of it, without involving full PKI)
Nice. See https://github.com/rgmhtt/draft-moskowitz-ecdsa-pki
I am right now adding an algorithm variable to support ed488.
This actually does not work right with 1.1.1-pre9, as PR 6901 did not
make that build, so I have to do my command and .cnf patches still. If
I publish prior to 9/11 (2nd day of Rosh Hashana, so I won't be doing
any work the beginning of next week), I will have to include text (that
a later draft version will remove) about this caveat. Given what I have
to do this week, I will probably not publish until middle of next week.
IEEE 802.1 will be meeting in Oslo, so I will be working remotely to get
a PAR going to rev 802.1AR to support EDDSA based on my work. Now there
is a standards org that has real challenges with advances like this.
802.1AR-2018 only supports RSA and ECDSA p256 and p384.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
