[openssl-users] OpenSSL version 1.1.1 pre release 9 published

[Robert Moskowitz]

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.