Re: Creating an X25519 client certificate

[Robert Moskowitz]

On 3/17/21 9:48 PM, tincanteksup wrote:



On 18/03/2021 01:22, Robert Moskowitz wrote:



On 3/17/21 8:17 PM, Viktor Dukhovni wrote:

Well, CSRs are self-signed, and X25519 does not support signing, so
you CANNOT have an X25519 CSR.


Slap myself on the forehead

Of course I know that.  But did not stop to think this through.   :(

Will read through all this and get back here



Wait until you spend 3 days waiting for an answer about Firefox
which I accidentally asked in #VBox ..

My forehead still bears the palm print and smarts!
I think it was the 'ox' which blinded me for so long. ;-)


I will have to discuss this with Russ...

A quick 'solution' to proof of ownership COULD be achieved IF:

The CA has an ECDH cert signed with its signing cert.

The client uses this to create a shared secret to KMAC the CSR.

The devil is in the details and I have other fish to fry...

Re: Creating an X25519 client certificate

[Robert Moskowitz]

On 3/17/21 8:17 PM, Viktor Dukhovni wrote:

On Wed, Mar 17, 2021 at 07:44:05PM -0400, Robert Moskowitz wrote:


I have created my X25519 pub/priv keypair with:

openssl genpkey -algorithm X25519\
       -out $dir/private/$clientemail-X.key.$format

Are you sure you didn't want ed25519 instead?  X25519 is a key agreement
menthod, not a signature method.

My limited understanding is that for encrypted S/MIME, and ECDH cert
is needed.  Thus if ED25519 is used for signing said S/MIME, X25519 is
used for encrypting.

I see, this is for CMS, so you're trying to support:

 https://tools.ietf.org/html/draft-ietf-curdle-cms-ecdh-new-curves-10


openssl req -config $dir/openssl-intermediate.cnf\
       -key $dir/private/$clientemail-X.key.$format \
       -subj "$DN" -new -out $dir/csr/$clientemail-X.csr.$format

which is what I used for ED25519 client certs.  But I get an error:

140487683954496:error:0608D096:digital envelope
routines:EVP_PKEY_sign_init:operation not supported for this
keytype:crypto/evp/pmeth_fn.c:39:

Not surprising, why do you expect this to work?

Shooting from the hip, a bit.  If I am going to have an X25519 cert,
then I need a csr and this is the command to make one.  So try it and
see what it does.  Not too well, it turns out.

Well, CSRs are self-signed, and X25519 does not support signing, so
you CANNOT have an X25519 CSR.


Slap myself on the forehead

Of course I know that.  But did not stop to think this through.   :(

Will read through all this and get back here


You can however create an X25519
certificate directly for a given key:

https://crypto.stackexchange.com/questions/19452/static-dh-static-ecdh-certificate-using-openssl

with other details (names, extensions, ...) pulled from a CSR.
What can't get is proof of posession.


Oh, and I am ASSuMEing that a CA cert of ED25519 signs an X25519 client
cert.  Haven't found instructions on this, but it seems reasonable...

https://crypto.stackexchange.com/questions/27866/why-curve25519-for-encryption-but-ed25519-for-signatures

Well the CA can use any algorithm that supports signing, and is widely
supported.  It does not have to be Ed25519.

Re: Creating an X25519 client certificate

[Robert Moskowitz]

On 3/17/21 7:22 PM, Viktor Dukhovni wrote:

On Wed, Mar 17, 2021 at 05:50:41PM -0400, Robert Moskowitz wrote:


I have created my X25519 pub/priv keypair with:

openssl genpkey -algorithm X25519\
      -out $dir/private/$clientemail-X.key.$format

Are you sure you didn't want ed25519 instead?  X25519 is a key agreement
menthod, not a signature method.


My limited understanding is that for encrypted S/MIME, and ECDH cert is 
needed.  Thus if ED25519 is used for signing said S/MIME, X25519 is used 
for encrypting.


I have seen CA Cert policies for "Device Encryption Certificates" that 
use:  id-ecPublicKey {1 2 840 10045 2 1}; I need to talk to the CP 
author more about this and what he sees the equiv Edward cert would look 
like.





openssl req -config $dir/openssl-intermediate.cnf\
      -key $dir/private/$clientemail-X.key.$format \
      -subj "$DN" -new -out $dir/csr/$clientemail-X.csr.$format

which is what I used for ED25519 client certs.  But I get an error:

140487683954496:error:0608D096:digital envelope
routines:EVP_PKEY_sign_init:operation not supported for this
keytype:crypto/evp/pmeth_fn.c:39:

Not surprising, why do you expect this to work?


Shooting from the hip, a bit.  If I am going to have an X25519 cert, 
then I need a csr and this is the command to make one.  So try it and 
see what it does.  Not too well, it turns out.





Can someone point me to what I am missing?

Oh, and I am ASSuMEing that a CA cert of ED25519 signs an X25519 client
cert.  Haven't found instructions on this, but it seems reasonable...

https://crypto.stackexchange.com/questions/27866/why-curve25519-for-encryption-but-ed25519-for-signatures

very familiar with this point and did look at this response during my 
searches today.


I quite understand in TLS the use of EdDSA certs that allow 
keyEncipherment and ?dataEncipherment? to permit an ECDHE exchange.


but my limited research claims that for S/MIME you can have an X25519 
cert for static ECDH, rather than ephemeral, saving supposedly the 
exchange of keys before sending encrypted S/MIME.

Creating an X25519 client certificate

[Robert Moskowitz]

I have created my X25519 pub/priv keypair with:

openssl genpkey -algorithm X25519\
    -out $dir/private/$clientemail-X.key.$format

And displays properly with:

openssl pkey -in $dir/private/$clientemail-X.key.$format -text -noout


So now to make the csr with:

openssl req -config $dir/openssl-intermediate.cnf\
    -key $dir/private/$clientemail-X.key.$format \
    -subj "$DN" -new -out $dir/csr/$clientemail-X.csr.$format

which is what I used for ED25519 client certs.  But I get an error:

140487683954496:error:0608D096:digital envelope 
routines:EVP_PKEY_sign_init:operation not supported for this 
keytype:crypto/evp/pmeth_fn.c:39:


I can't figure out from my config file why this error.  and googling the 
error has not helped.  yet.


Can someone point me to what I am missing?

Oh, and I am ASSuMEing that a CA cert of ED25519 signs an X25519 client 
cert.  Haven't found instructions on this, but it seems reasonable...


thanks

Re: Format and standard for CSR

[Robert Moskowitz]

On 8/29/19 9:20 AM, Michael Richardson wrote:

Robert Moskowitz  wrote:
 > I am writing an Internet Draft that will include transmission of a CSR, 
so I
 > need to reference the proper source.  No more sloppy, "well it works...".

 > Some digging said it is in PKCS#10 - CSR.  But I did not stop with
 > that.

RFC2986 is PKCS10.
RFC7030 references that, I don't think that there is anything newer.
But, maybe I've mis-understood your question?


To bring up 7030, yes you have.

7030 is not something you want to run over a highly constrained network, 
involving a highly constrained device.  It does provide some good 
guidelines for 'completeness'.  Is ANIMA using it?  And ANIMA is not 
just constrained devices.


For this project there are strong arguments to do all registration stuff 
within HIP messages.  At least for initial design.


It is not my job in this project to declare a winner in best CSR format 
design.  For the initial specification, I need to do a best effort on 
current practice.  PKCS#10 seems to be that.


You may be one of the parties at the Hackathon.   And perhaps the only 
one on this list.

Re: Format and standard for CSR

[Robert Moskowitz]

On 8/29/19 11:20 AM, Salz, Rich wrote:


A CSR is most commonly a PKCS#10 object and therefore defined in ASN.1 
and encoded in DER.


https://github.com/openssl/openssl/blob/master/crypto/include/internal/x509_int.h#L53



thanks, Rich

It all fits together now

Re: Format and standard for CSR

[Robert Moskowitz]

Uri, Greetings!

On 8/28/19 6:09 PM, Blumenthal, Uri - 0553 - MITLL wrote:
Do you have an ASN.1 definition fit the content of CSR, or are you 
willing to create one?


For now working with ASN.1.

IMHO, DER would be a pretty good choice, fat better than something 
home-brewed and non-standard.


take a look at rfc 7049.  This is the standard for data objects over 
constrained networks.  Then look at


draft-birkholz-core-coid

For work being done to define by a good team to meld x.509 stuff with CBOR.

"The wonderful thing about standards is there are so many to choose from."

There was a reference point to Grace Hopper saying this in '58.



Regards,
Uri

Sent from my iPhone

On Aug 28, 2019, at 17:49, Robert Moskowitz <mailto:r...@htt-consult.com>> wrote:


CSR is an object in a container that goes over a 'wire'. Sometimes 
the wire is very small (BT4) so the container needs to be tightly 
designed.


It should be a standard, not something totally off the wall.  Well I 
could do it in CBOR, and probably will at some point, but for now 
something more common in PKIX world should work.


Mangle it, stuff it down the wire, de-mangle it and use it. For now I 
am referencing RFC 2986.


What do you suggest.  Please reference documents that can be 
referenced in the document.


Thanks


On 8/28/19 5:23 PM, Michael Sierchio wrote:


I don't see the point in DER encoding for a CSR – The RA and CA 
decide the composition of the cert, based on the rules and CPA that 
they follow, and of course any cert issued will be in DER format, 
and may include reordering or modified/expanded extensions and key 
use restrictions.  A CSR is basically an assertion that includes 
pubkey, proof of possession of the private key, and any request 
elements required by policy.  It's a one-time document that needs to 
be validated precisely once.



On Wed, Aug 28, 2019 at 6:49 AM Robert Moskowitz 
mailto:r...@htt-consult.com>> wrote:


I am writing an Internet Draft that will include transmission of
a CSR,
so I need to reference the proper source.  No more sloppy, "well it
works...".

Some digging said it is in PKCS#10 - CSR.  But I did not stop
with that.

A bit more googling lead me to RFC 4211...

When I create a CSR with:

    openssl req -config openssl-intermediate.cnf\
    -key ./private/client.key.pem \
    -subj "$DN" -new -out ./csr/client.csr.pem

What format is this?  Are there better, more concise formats
(e.g. DER?)
for transmission over constrained networks?

I can dump it with

    openssl req -text -noout -verify -in ./csr/client.csr.pem

But that does not really tell me the format, only what is in the
cert.

Thanks



--

"Well," Brahmā said, "even after ten thousand explanations, a fool 
is no wiser, but an intelligent person requires only two thousand 
five hundred."


- The Mahābhārata

Re: Format and standard for CSR

[Robert Moskowitz]

CSR is an object in a container that goes over a 'wire'.   Sometimes the 
wire is very small (BT4) so the container needs to be tightly designed.


It should be a standard, not something totally off the wall.  Well I 
could do it in CBOR, and probably will at some point, but for now 
something more common in PKIX world should work.


Mangle it, stuff it down the wire, de-mangle it and use it.  For now I 
am referencing RFC 2986.


What do you suggest.  Please reference documents that can be referenced 
in the document.


Thanks


On 8/28/19 5:23 PM, Michael Sierchio wrote:


I don't see the point in DER encoding for a CSR – The RA and CA decide 
the composition of the cert, based on the rules and CPA that they 
follow, and of course any cert issued will be in DER format, and may 
include reordering or modified/expanded extensions and key use 
restrictions.  A CSR is basically an assertion that includes pubkey, 
proof of possession of the private key, and any request elements 
required by policy.  It's a one-time document that needs to be 
validated precisely once.



On Wed, Aug 28, 2019 at 6:49 AM Robert Moskowitz <mailto:r...@htt-consult.com>> wrote:


I am writing an Internet Draft that will include transmission of a
CSR,
so I need to reference the proper source.  No more sloppy, "well it
works...".

Some digging said it is in PKCS#10 - CSR.  But I did not stop with
that.

A bit more googling lead me to RFC 4211...

When I create a CSR with:

    openssl req -config openssl-intermediate.cnf\
    -key ./private/client.key.pem \
    -subj "$DN" -new -out ./csr/client.csr.pem

What format is this?  Are there better, more concise formats (e.g.
DER?)
for transmission over constrained networks?

I can dump it with

    openssl req -text -noout -verify -in ./csr/client.csr.pem

But that does not really tell me the format, only what is in the cert.

Thanks



--

"Well," Brahmā said, "even after ten thousand explanations, a fool is 
no wiser, but an intelligent person requires only two thousand five 
hundred."


- The Mahābhārata

Re: Format and standard for CSR

[Robert Moskowitz]

Peter, thank you for the response.

On 8/28/19 10:09 AM, Bowen, Peter wrote:

I think you want RFC 2986 (https://tools.ietf.org/html/rfc2986 ).  That is the most 
recent "PKCS #10" specification that I have seen and should align with what 
`openssl req` creates.  Adding '-outform DER' to your command will output in DER; the 
default output is PEM which is defined in RFC 7468 (https://tools.ietf.org/html/rfc7468 ).


This will be within a HIP registration exchange (rfc 8003), so PKCS #10 
in DER seems best.



Depending on your use case, you may want to consider using a SPKAC formatted 
request instead.  See `openssl spkac` and https://en.wikipedia.org/wiki/SPKAC 
for more info.


Considering the process, the PKCS10 fits better.

thanks for the references.



On 8/28/19, 6:49 AM, "openssl-users on behalf of Robert Moskowitz" 
 wrote:

 I am writing an Internet Draft that will include transmission of a CSR,
 so I need to reference the proper source.  No more sloppy, "well it
 works...".
 
 Some digging said it is in PKCS#10 - CSR.  But I did not stop with that.
 
 A bit more googling lead me to RFC 4211...
 
 When I create a CSR with:
 
 openssl req -config openssl-intermediate.cnf\

 -key ./private/client.key.pem \
 -subj "$DN" -new -out ./csr/client.csr.pem
 
 What format is this?  Are there better, more concise formats (e.g. DER?)

 for transmission over constrained networks?
 
 I can dump it with
 
 openssl req -text -noout -verify -in ./csr/client.csr.pem
 
 But that does not really tell me the format, only what is in the cert.
 
 Thanks
 
 

Format and standard for CSR

[Robert Moskowitz]

I am writing an Internet Draft that will include transmission of a CSR, 
so I need to reference the proper source.  No more sloppy, "well it 
works...".


Some digging said it is in PKCS#10 - CSR.  But I did not stop with that.

A bit more googling lead me to RFC 4211...

When I create a CSR with:

   openssl req -config openssl-intermediate.cnf\
   -key ./private/client.key.pem \
   -subj "$DN" -new -out ./csr/client.csr.pem

What format is this?  Are there better, more concise formats (e.g. DER?) 
for transmission over constrained networks?


I can dump it with

   openssl req -text -noout -verify -in ./csr/client.csr.pem

But that does not really tell me the format, only what is in the cert.

Thanks

cSHAKE support

[Robert Moskowitz]

Does openssl (and the CLI) support cSHAKE (NIST SP800-185)?

Or is there a way to use the SHAKE support to get cSHAKE behavior?

thanks

Re: client certs with no subjectName only SAN

[Robert Moskowitz]

On 8/16/19 12:34 PM, Erwann Abalea wrote:

Bonjour,

Having a critical extension adds 3 octets (the BOOLEAN tag, length=1, 
value=0xff). It may, as a side effect, enlarge the number of octets necessary 
to encode some structure size.

Remove the 2 Netscape extensions, they're way obsolete (don't know why OpenSSL 
keeps them by default).

If size is a hard constraint:
  - you can probably remove the emailProtection EKU (it's an OID, you'll gain 
10 octets). Depending on your use-case, you may need to tweak the EKU (or 
remove it completely).
  - SKI and AKI extensions may not be necessary
  - Key Usage may be marked as non critical (it's a SHOULD in PKIX)


I will look at this and figure out what to change in my .cnf.  I have 
been using what I have in my:


draft-moskowitz-eddsa-pki


A quick reading of RFC8002 tells me that you may need to include the 
IssuerAltName extension as well?


That is the 8002 SHOULD.  But following rfc 2119 on SHOULD, since I can 
calculate the Issuer HHIT from the prefix in issuerName and the Issuer's 
Public Key (not carried in the client cert, got to go up the chain to 
get that), I am avoiding at this stage of development to closely follow 
8002.  Still thinking on all this.


Thank you on your help



Cordialement,
Erwann Abalea

Le 16/08/2019 17:11, « openssl-users au nom de Robert Moskowitz » 
 a écrit :

 Viktor,
 
 
 On 8/16/19 8:41 AM, Viktor Dukhovni wrote:

 >> On Aug 16, 2019, at 6:13 AM, Salz, Rich via openssl-users 
 wrote:
 >>
 >> subjectAltName is rarely marked as critical; sec 4.2.1.6 of PKIX says 
"SHOULD mark subjectAltName as non-critical"
 > This is wrong.  When the subject DN is empty, the subjectAltName should 
be
 > marked as critical.  IIRC some Java implementations reject the 
certificate
 > otherwise.
 
 I have just created a client cert with empty subjectName and critical

 subjectAltName.  Interestingly, it is 4 bytes larger than the earlier
 non-critical SAN cert.  See below for the output of the cert.
 
 >> I can believe that OpenSSL doesn't support empty subjectName's.  An empty one, with no relative disintuished name components, is not the same as not present.

 > OpenSSL supports empty (empty RDN sequence) subject DNs.
 > The "-subj /" option is one way to make that happen.
 >
 > Empty is of course different from "absent", which is not
 > possible, since the subject DN is a required component of
 > an X.509 certificate.
 
 I now have it clear that Empty SN is NOT a cert with NO SN.  It is there

 with null content.
 
 Thank you all.
 
 $ openssl x509 -noout -text -in $dir/certs/device2.cert.pem

 Certificate:
  Data:
  Version: 3 (0x2)
  Serial Number:
  c9:8f:b2:7b:e1:95:74:d0
  Signature Algorithm: ED25519
  Issuer: CN = 2001:24:28:14::/64
  Validity
  Not Before: Aug 16 14:54:58 2019 GMT
  Not After : Aug 25 14:54:58 2020 GMT
  Subject:
  Subject Public Key Info:
  Public Key Algorithm: ED25519
  ED25519 Public-Key:
  pub:
  69:4f:1c:77:56:69:3a:cd:86:c4:3a:b0:67:b9:50:
  c3:12:9c:6f:85:65:a0:8f:fa:b5:74:b1:c4:56:f8:
  4c:a5
  X509v3 extensions:
  X509v3 Basic Constraints:
  CA:FALSE
  Netscape Cert Type:
  SSL Client, S/MIME
  Netscape Comment:
  OpenSSL Generated Client Certificate
  X509v3 Subject Key Identifier:
 8A:8D:18:B6:F7:70:7D:17:64:AA:2F:C7:FF:1F:C2:30:E2:D8:56:DD
  X509v3 Authority Key Identifier:
 keyid:B1:45:18:9B:33:82:6C:74:29:69:2A:15:93:3B:1C:31:D2:37:D6:CA
 
  X509v3 Key Usage: critical

  Digital Signature, Non Repudiation, Key Encipherment
  X509v3 Extended Key Usage:
  TLS Web Client Authentication, E-mail Protection
  X509v3 Subject Alternative Name: critical
  IP Address:2001:24:28:14:2B6E:2C43:A2D8:507C
  Signature Algorithm: ED25519
   01:54:3e:d2:21:36:27:57:f2:da:d7:ee:42:ec:8f:05:99:b1:
   4b:de:2c:c4:3b:95:6f:ba:f6:25:a5:10:bb:2d:5c:9b:15:46:
   dc:67:ea:b4:74:df:a6:52:60:6f:cd:06:af:f4:69:5f:37:1a:
   ba:1a:b4:17:c0:bb:0f:da:be:02
 
 
 

Re: client certs with no subjectName only SAN

[Robert Moskowitz]

Viktor,


On 8/16/19 8:41 AM, Viktor Dukhovni wrote:

On Aug 16, 2019, at 6:13 AM, Salz, Rich via openssl-users 
 wrote:

subjectAltName is rarely marked as critical; sec 4.2.1.6 of PKIX says "SHOULD mark 
subjectAltName as non-critical"

This is wrong.  When the subject DN is empty, the subjectAltName should be
marked as critical.  IIRC some Java implementations reject the certificate
otherwise.


I have just created a client cert with empty subjectName and critical 
subjectAltName.  Interestingly, it is 4 bytes larger than the earlier 
non-critical SAN cert.  See below for the output of the cert.



I can believe that OpenSSL doesn't support empty subjectName's.  An empty one, 
with no relative disintuished name components, is not the same as not present.

OpenSSL supports empty (empty RDN sequence) subject DNs.
The "-subj /" option is one way to make that happen.

Empty is of course different from "absent", which is not
possible, since the subject DN is a required component of
an X.509 certificate.


I now have it clear that Empty SN is NOT a cert with NO SN.  It is there 
with null content.


Thank you all.

$ openssl x509 -noout -text -in $dir/certs/device2.cert.pem
Certificate:
    Data:
    Version: 3 (0x2)
    Serial Number:
    c9:8f:b2:7b:e1:95:74:d0
    Signature Algorithm: ED25519
    Issuer: CN = 2001:24:28:14::/64
    Validity
    Not Before: Aug 16 14:54:58 2019 GMT
    Not After : Aug 25 14:54:58 2020 GMT
    Subject:
    Subject Public Key Info:
    Public Key Algorithm: ED25519
    ED25519 Public-Key:
    pub:
    69:4f:1c:77:56:69:3a:cd:86:c4:3a:b0:67:b9:50:
    c3:12:9c:6f:85:65:a0:8f:fa:b5:74:b1:c4:56:f8:
    4c:a5
    X509v3 extensions:
    X509v3 Basic Constraints:
    CA:FALSE
    Netscape Cert Type:
    SSL Client, S/MIME
    Netscape Comment:
    OpenSSL Generated Client Certificate
    X509v3 Subject Key Identifier:
8A:8D:18:B6:F7:70:7D:17:64:AA:2F:C7:FF:1F:C2:30:E2:D8:56:DD
    X509v3 Authority Key Identifier:
keyid:B1:45:18:9B:33:82:6C:74:29:69:2A:15:93:3B:1C:31:D2:37:D6:CA

    X509v3 Key Usage: critical
    Digital Signature, Non Repudiation, Key Encipherment
    X509v3 Extended Key Usage:
    TLS Web Client Authentication, E-mail Protection
    X509v3 Subject Alternative Name: critical
    IP Address:2001:24:28:14:2B6E:2C43:A2D8:507C
    Signature Algorithm: ED25519
 01:54:3e:d2:21:36:27:57:f2:da:d7:ee:42:ec:8f:05:99:b1:
 4b:de:2c:c4:3b:95:6f:ba:f6:25:a5:10:bb:2d:5c:9b:15:46:
 dc:67:ea:b4:74:df:a6:52:60:6f:cd:06:af:f4:69:5f:37:1a:
 ba:1a:b4:17:c0:bb:0f:da:be:02

Re: Acquire Entropy for embedded platform

[Robert Moskowitz]

On 8/16/19 5:44 AM, Dr Paul Dale wrote:
I investigated HAVEGE fairly deeply a couple of years ago.  I am 
completely in agreement with the basis of this source, however the 
sticking point was the “expansion” phase.  Essentially, every bit of 
entropy gathered is turned into (just under) thirty two bits of 
“entropy”.  This is logically and physically impossible.  As a source, 
it appears reasonable to the usual tests (i.e. dieharder), although 
TestU01 <https://en.wikipedia.org/wiki/TestU01> does pick up on it 
being less than ideal.


I would, however, recommend Stephan Müller's CPU Jitter 
<https://www.chronox.de/jent/doc/CPU-Jitter-NPTRNG.html>.  The 
gathering is well researched and performed, no hidden tricks are 
present and the bits produces are equiprobable.


Thanks.  I will take a look at CPU Jitter.  Entropy can be an issue on 
some of my armv7 boards.  I run CentOS on them, so all I need to find 
are rpms for something to test it out...





Pauli
--
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7 3031 7217
Oracle Australia




On 16 Aug 2019, at 7:31 pm, Robert Moskowitz <mailto:r...@htt-consult.com>> wrote:




On 8/16/19 5:26 AM, Chitrang Srivastava wrote:

Hi,

I am working on an embedded platform and now ported openssl 1.1.1b
TLS 1.2/1.3 is working fine.
While analysing random number , Rand pool initialization calls where 
I am returning like this ,

size_t *rand_pool_acquire_entropy*(RAND_POOL *pool)
{
        return rand_pool_entropy_available(pool);
}
As noticed that *rand_unix.c* has an implementation wcih samples 2 
bits of RTC, would that give enough entropy or any other 
recommendation to have enough entropy for embedded platforms?



Check out: https://issihosts.com/haveged

I talk about it here: 
http://www.htt-consult.com/CentOS7-armv7.html#RANDOMNESS

Re: client certs with no subjectName only SAN

[Robert Moskowitz]

On 8/16/19 7:58 AM, Salz, Rich wrote:

In the same paragraph, the sentence before the one you're quoting says "If the 
subject field contains an empty sequence, then the issuing CA MUST include a 
subjectAltName extension that is marked as critical."
 


I will run another test today and see if it is as easy as claimed to 
flag SAN critical.




It's not possible to have a missing subject name in a certificate, the 
field is not OPTIONAL.


I was wondering more the construction of the cert when 'no 
subjectName'.  You confirmed that the object is there. Probably length 
0.  I will have to look at that asnparse listing more critically.


   
You are of course correct.  Thanks Erwann.  (He has forgotten more about ASN1 than I ever knew :)




Why I ask, perhaps seemingly dumb questions, here.  Those that really 
know the stuff are still around.


I learned enough ASN1 to get by with x.509 and snmp and have forgotten 
much of what I learned ~20 years ago.  I do have an iana enterprise 
number that I used in some of my OID proposals in both way back then.


The failing read access really bites.

thanks both of you.

Re: Acquire Entropy for embedded platform

[Robert Moskowitz]

On 8/16/19 5:26 AM, Chitrang Srivastava wrote:

Hi,

I am working on an embedded platform and now ported openssl 1.1.1b
TLS 1.2/1.3 is working fine.
While analysing random number , Rand pool initialization calls where I 
am returning like this ,

size_t *rand_pool_acquire_entropy*(RAND_POOL *pool)
{
        return rand_pool_entropy_available(pool);
}
As noticed that *rand_unix.c* has an implementation wcih samples 2 
bits of RTC, would that give enough entropy or any other 
recommendation to have enough entropy for embedded platforms?



Check out:    https://issihosts.com/haveged

I talk about it here: 
http://www.htt-consult.com/CentOS7-armv7.html#RANDOMNESS

Re: IPv6 address encoding in commonName

[Robert Moskowitz]

Jackob,

I thank you for all this.  I will be studying it over the coming week(s).

Bob

On 8/15/19 5:39 PM, Jakob Bohm via openssl-users wrote:

[Top posting to match]

Note that the actual DC name element is still used for actual domains 
when interacting with Microsoft Active Directory authentication, 
including associated X.509 certificates.  So it shouldn't be used for 
something contrary.


The shortest useful form in terms of certificate size would probably be:

Put an informal (but fixed format) description of the address scope in 
the user readable CN in certificates at all levels (rootCA, itemCA and 
end cert).  Put appropriate human readable organization name or 
equivalent in the O name element in rootCA and itemCA.  Make the end 
cert DN as short as possible.


For example "CN=HIT CA 2 example corp,O=example corp,C=TH" -> "CN=HIT 
factory CA xy,O=Example Chon Buri plant,C=TH" -> "CN=HIT CA for 
[...],O=In your device,C=XX" -> "CN=[2001:db8:a:b::],C=XX" (Using "XX" 
to represent the device might be in any country).


Put the actual address in the appropriate SAN in the end cert (this 
will be a binary address).


Put name restrictions in the all the CAs (intermediary and special 
purpose root), these will be a binary address and length for the 
allowed type and the appropriate "nothing" notation for all the other 
defined name restriction types except the distinguished name type.


Do not include ID number fields except the certificate serial number, 
which also protects the signature hash algorithm via randomization 
(since SHA-1 phase out began, but potentially useful for modern 
algorithms).


Use a short offline-compatible revocation URL such as "ex.th/xy.crl" 
for hierarchies run by the hypothetical EXample conglomerate in 
THailand, where the xy part is a very short name assigned by that 
conglomerate to the issuing central CA or factory intermCA.


On 15/08/2019 18:49, Robert Moskowitz wrote:



On 8/14/19 6:47 PM, Michael Richardson wrote:

Robert Moskowitz  wrote:
 > I am fiddling around with an intermediate CA signing cert 
that the CA's
 > 'name' is it HIP (RFC 7401) HIT which is a valid IPv6 
address. Actually a
 > Hierarchical HIT as in draft-moskowitz-hierarchical-hip (to 
be revised soon).


 > For a client cert, it would be easy to put the HIT in 
subjectAltName per RFC
 > 8002 (with a null subjectName), but a CA cert MUST have a 
non-empty

 > subjectName.

 > Thus all I want in this subjectName is commonName with the HIT.
 > I am looking for examples of IPv6 addresses in commonName.

I thought that RFC3779 did exactly what you want, but it does not 
define new
Subject DN, but rather a new extension that will be bound to the 
Subject.
(I was surprised that RFC3779 was not in the SIDR WG's list of 
documents,but

I guess it preceeded the SIDR working group, and occured in PKIX)

In ANIMA's ACP document, we have an abomination that leverages 
rfc822Name,

mostly because we figure the odds of getting anything else through
off-the-shelf CAs is nil.
Note to consumed with things in your stomach:
https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-20#section-6.1.2 



Jakob Bohm via openssl-users  wrote:
 > As the author of a proposal in this area, could you define a 
notation
 > for IPv6 DNs, perhaps one that actually reflects the 
hierarchical nature

 > of IPv6 addresses?

RFC3779 does some of that, but not in the DN itself.

 > You could take inspiration from the (unfortunately rarely used)
 > hierarchical DN representation of DNS names (this used the DNS
 > specific DC name components).  Overall the goal is to allow 
X.500

 > distinguished name restrictions to work correctly.

Yes, we could abuse the DC component.
Were you thinking about:
  DC=2001/DC=0db8


This looks closest to what is needed here, as the prefix for HHITs is 
currently proposed at /64.


So it would be DC=2001/DC=0024/DC=0028/DC=0014

But the OID for DC is bi: 0.9.2342.19200300.100.1.25

Ouch.

So I will research this more, but for this early stage in the 
development I will use:


CN=2001:24:28:14::/64

Thanks for all the comments here.



 > In practice you could follow the nibble notation as already used
 > for delegation of IPv6 reverse lookups in DNS.

so more correctly:
  DC=2/DC=0/DC=0/DC=1/DC=d/DC=b/DC=8

 > However for the CN in the end cert you could perhaps use the 
full

 > DNS reverse IPv6 name
 > 
"x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.ip6.arpa"
 > or the URL/Mail notation 
"[:::::::]"
 > where the hex notation shall be the shortest form permitted 
by the

 > IPv6 notation spec.

Bob, this seems like the best immediate hack to me.



Enjoy

Jakob

Enjoy

Jakob

Re: client certs with no subjectName only SAN

[Robert Moskowitz]

On 8/15/19 4:13 PM, Salz, Rich wrote:

subjectAltName is rarely marked as critical; sec 4.2.1.6 of PKIX says "SHOULD mark 
subjectAltName as non-critical"


Fine with me.


I can believe that OpenSSL doesn't support empty subjectName's.  An empty one, 
with no relative disintuished name components, is not the same as not present.


It does seem empty with that -subj / command line option.

I am not seeing subjectName in this dump of the cert:

$    openssl asn1parse -i -in $dir/certs/device1.cert.pem
    0:d=0  hl=4 l= 439 cons: SEQUENCE
    4:d=1  hl=4 l= 361 cons:  SEQUENCE
    8:d=2  hl=2 l=   3 cons:   cont [ 0 ]
   10:d=3  hl=2 l=   1 prim:    INTEGER   :02
   13:d=2  hl=2 l=   9 prim:   INTEGER   :C98FB27BE19574CF
   24:d=2  hl=2 l=   5 cons:   SEQUENCE
   26:d=3  hl=2 l=   3 prim:    OBJECT    :ED25519
   31:d=2  hl=2 l=  29 cons:   SEQUENCE
   33:d=3  hl=2 l=  27 cons:    SET
   35:d=4  hl=2 l=  25 cons: SEQUENCE
   37:d=5  hl=2 l=   3 prim:  OBJECT    :commonName
   42:d=5  hl=2 l=  18 prim:  UTF8STRING :2001:24:28:14::/64
   62:d=2  hl=2 l=  30 cons:   SEQUENCE
   64:d=3  hl=2 l=  13 prim:    UTCTIME   :190815195117Z
   79:d=3  hl=2 l=  13 prim:    UTCTIME   :200824195117Z
   94:d=2  hl=2 l=   0 cons:   SEQUENCE
   96:d=2  hl=2 l=  42 cons:   SEQUENCE
   98:d=3  hl=2 l=   5 cons:    SEQUENCE
  100:d=4  hl=2 l=   3 prim: OBJECT    :ED25519
  105:d=3  hl=2 l=  33 prim:    BIT STRING
  140:d=2  hl=3 l= 226 cons:   cont [ 3 ]
  143:d=3  hl=3 l= 223 cons:    SEQUENCE
  146:d=4  hl=2 l=   9 cons: SEQUENCE
  148:d=5  hl=2 l=   3 prim:  OBJECT    :X509v3 Basic 
Constraints

  153:d=5  hl=2 l=   2 prim:  OCTET STRING  [HEX DUMP]:3000
  157:d=4  hl=2 l=  17 cons: SEQUENCE
  159:d=5  hl=2 l=   9 prim:  OBJECT    :Netscape Cert Type
  170:d=5  hl=2 l=   4 prim:  OCTET STRING  [HEX DUMP]:030205A0
  176:d=4  hl=2 l=  51 cons: SEQUENCE
  178:d=5  hl=2 l=   9 prim:  OBJECT    :Netscape Comment
  189:d=5  hl=2 l=  38 prim:  OCTET STRING  [HEX 
DUMP]:16244F70656E53534C2047656E65726174656420436C69656E74204365727469666963617465

  229:d=4  hl=2 l=  29 cons: SEQUENCE
  231:d=5  hl=2 l=   3 prim:  OBJECT    :X509v3 Subject Key 
Identifier
  236:d=5  hl=2 l=  22 prim:  OCTET STRING  [HEX 
DUMP]:041497B0DCA27493CF765E826C089C467383D3868E9A

  260:d=4  hl=2 l=  31 cons: SEQUENCE
  262:d=5  hl=2 l=   3 prim:  OBJECT    :X509v3 Authority 
Key Identifier
  267:d=5  hl=2 l=  24 prim:  OCTET STRING  [HEX 
DUMP]:30168014B145189B33826C7429692A15933B1C31D237D6CA

  293:d=4  hl=2 l=  14 cons: SEQUENCE
  295:d=5  hl=2 l=   3 prim:  OBJECT    :X509v3 Key Usage
  300:d=5  hl=2 l=   1 prim:  BOOLEAN   :255
  303:d=5  hl=2 l=   4 prim:  OCTET STRING  [HEX DUMP]:030205E0
  309:d=4  hl=2 l=  29 cons: SEQUENCE
  311:d=5  hl=2 l=   3 prim:  OBJECT    :X509v3 Extended 
Key Usage
  316:d=5  hl=2 l=  22 prim:  OCTET STRING  [HEX 
DUMP]:301406082B0601050507030206082B06010505070304

  340:d=4  hl=2 l=  27 cons: SEQUENCE
  342:d=5  hl=2 l=   3 prim:  OBJECT    :X509v3 Subject 
Alternative Name
  347:d=5  hl=2 l=  20 prim:  OCTET STRING  [HEX 
DUMP]:301287102001002400280014B8AF2789CBB9F7AC

  369:d=1  hl=2 l=   5 cons:  SEQUENCE
  371:d=2  hl=2 l=   3 prim:   OBJECT    :ED25519
  376:d=1  hl=2 l=  65 prim:  BIT STRING

client certs with no subjectName only SAN

[Robert Moskowitz]

There are a number of things I am not clear on, and so far my searching 
and reading is coming up short.


If there is no subjectName, only subjectAltName, is the subjectName 
still present in the cert only empty or is it totally gone.


I have found that if I put

-subj /

in the openssl req, I end up with an empty subjectName.  Or is there 
someway to totally remove this from the cert?


For the subjectAltName, is it suppose to be flagged critical?  I have 
seen references of:


subjectAltName=critical,email:certt...@example.com

Is this correct and the way to set SAN as critical?

thanks

The cert I have made so far is:

$openssl x509 -noout -text -in $dir/certs/device1.cert.pem
Certificate:
    Data:
    Version: 3 (0x2)
    Serial Number:
    c9:8f:b2:7b:e1:95:74:cf
    Signature Algorithm: ED25519
    Issuer: CN = 2001:24:28:14::/64
    Validity
    Not Before: Aug 15 19:51:17 2019 GMT
    Not After : Aug 24 19:51:17 2020 GMT
    Subject:
    Subject Public Key Info:
    Public Key Algorithm: ED25519
    ED25519 Public-Key:
    pub:
    7a:a6:f2:7d:14:8f:fd:a9:55:d9:6f:d6:04:a1:e6:
    6d:9e:34:1f:d3:2b:59:80:cc:2f:4c:83:4f:81:a0:
    10:36
    X509v3 extensions:
    X509v3 Basic Constraints:
    CA:FALSE
    Netscape Cert Type:
    SSL Client, S/MIME
    Netscape Comment:
    OpenSSL Generated Client Certificate
    X509v3 Subject Key Identifier:
97:B0:DC:A2:74:93:CF:76:5E:82:6C:08:9C:46:73:83:D3:86:8E:9A
    X509v3 Authority Key Identifier:
keyid:B1:45:18:9B:33:82:6C:74:29:69:2A:15:93:3B:1C:31:D2:37:D6:CA

    X509v3 Key Usage: critical
    Digital Signature, Non Repudiation, Key Encipherment
    X509v3 Extended Key Usage:
    TLS Web Client Authentication, E-mail Protection
    X509v3 Subject Alternative Name:
    IP Address:2001:24:28:14:B8AF:2789:CBB9:F7AC
    Signature Algorithm: ED25519
 32:2e:7d:4d:ad:4d:87:4c:57:1a:df:ef:e3:ec:2b:b5:a7:fe:
 2f:48:73:32:72:1a:b6:4a:cd:e4:88:75:98:4d:b0:9a:79:48:
 2b:2c:12:68:0f:c0:86:bd:d9:4e:4b:85:fb:f3:91:68:f4:ec:
 18:99:dd:7e:d5:f8:b6:f0:08:0e

Re: IPv6 address encoding in commonName

[Robert Moskowitz]

On 8/14/19 6:47 PM, Michael Richardson wrote:

Robert Moskowitz  wrote:
 > I am fiddling around with an intermediate CA signing cert that the CA's
 > 'name' is it HIP (RFC 7401) HIT which is a valid IPv6 address. Actually a
 > Hierarchical HIT as in draft-moskowitz-hierarchical-hip (to be revised 
soon).

 > For a client cert, it would be easy to put the HIT in subjectAltName per 
RFC
 > 8002 (with a null subjectName), but a CA cert MUST have a non-empty
 > subjectName.

 > Thus all I want in this subjectName is commonName with the HIT.
 > I am looking for examples of IPv6 addresses in commonName.

I thought that RFC3779 did exactly what you want, but it does not define new
Subject DN, but rather a new extension that will be bound to the Subject.
(I was surprised that RFC3779 was not in the SIDR WG's list of documents,but
I guess it preceeded the SIDR working group, and occured in PKIX)

In ANIMA's ACP document, we have an abomination that leverages rfc822Name,
mostly because we figure the odds of getting anything else through
off-the-shelf CAs is nil.
Note to consumed with things in your stomach:
   
https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-20#section-6.1.2

Jakob Bohm via openssl-users  wrote:
 > As the author of a proposal in this area, could you define a notation
 > for IPv6 DNs, perhaps one that actually reflects the hierarchical nature
 > of IPv6 addresses?

RFC3779 does some of that, but not in the DN itself.

 > You could take inspiration from the (unfortunately rarely used)
 > hierarchical DN representation of DNS names (this used the DNS
 > specific DC name components).  Overall the goal is to allow X.500
 > distinguished name restrictions to work correctly.

Yes, we could abuse the DC component.
Were you thinking about:
  DC=2001/DC=0db8


This looks closest to what is needed here, as the prefix for HHITs is 
currently proposed at /64.


So it would be DC=2001/DC=0024/DC=0028/DC=0014

But the OID for DC is bi: 0.9.2342.19200300.100.1.25

Ouch.

So I will research this more, but for this early stage in the 
development I will use:


CN=2001:24:28:14::/64

Thanks for all the comments here.



 > In practice you could follow the nibble notation as already used
 > for delegation of IPv6 reverse lookups in DNS.

so more correctly:
  DC=2/DC=0/DC=0/DC=1/DC=d/DC=b/DC=8

 > However for the CN in the end cert you could perhaps use the full
 > DNS reverse IPv6 name
 > 
"x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.ip6.arpa"
 > or the URL/Mail notation "[:::::::]"
 > where the hex notation shall be the shortest form permitted by the
 > IPv6 notation spec.

Bob, this seems like the best immediate hack to me.

openssl req error with DN having a / in it

[Robert Moskowitz]

Developing saga on creating an intermediate CA cert with only CN and 
said CN should be:


CN=IPv6::2001:24:28:24/64

Note that / in CN that seems to be a challenge.

   commonName="/CN=IPv6::2001:24:28:24/64"
   DN=$commonName
   echo $DN

   openssl req -config $cadir/openssl-root.cnf\
   -key $dir/private/intermediate.key.pem \
   -keyform pem -outform $format -subj "$DN" -new\
   -out $dir/csr/intermediate.csr.pem

req: Hit end of string before finding the equals.
problems making Certificate Request

Then I tried:

   commonName="/CN=IPv6::2001:24:28:24//64"
   DN=$commonName
   echo $DN

guessing that / was acting as an escape designator, tried the command 
again and got the same


req: Hit end of string before finding the equals.
problems making Certificate Request

So how do I get that / into the CN?

thanks

Re: IPv6 address encoding in commonName

[Robert Moskowitz]

On 8/14/19 3:26 PM, Salz, Rich wrote:

 RFC 8002 (with a null subjectName), but a CA cert MUST have a non-empty
 subjectName.

Non-empty subjectName or non-empty commonName within the subject name?

Shrug.  Doesn't matter, I guess.  Just populate it with the string version of 
the HIT name, something like
CN=IP Address 2001:27:dcfc:cb8:d53g:5364:48bj
?


That is what I am coming to see.  Always 'nice' to follow existing 
practice.  But given now, set the precedence!





My searches today have come up empty.
   
I tried crt.sh and also came up empty; https://crt.sh/?CAName=%25%3A%25  This is not surprising since I would not expect any public CA's to have this kind of thing.


   

Re: IPv6 address encoding in commonName

[Robert Moskowitz]

On 8/14/19 11:21 AM, Jakob Bohm via openssl-users wrote:

On 14/08/2019 04:55, Robert Moskowitz wrote:
I am fiddling around with an intermediate CA signing cert that the 
CA's 'name' is it HIP (RFC 7401) HIT which is a valid IPv6 address. 
Actually a Hierarchical HIT as in draft-moskowitz-hierarchical-hip 
(to be revised soon).


For a client cert, it would be easy to put the HIT in subjectAltName 
per RFC 8002 (with a null subjectName), but a CA cert MUST have a 
non-empty subjectName.


Thus all I want in this subjectName is commonName with the HIT.

I am looking for examples of IPv6 addresses in commonName.

My searches today have come up empty.


If no one comes up with good established practice examples, here are
some ideas you may work on.

For CA certificates that are not self-signed end certs, it would be
practical to use a CN that is intentionally different from the end
certs, such as "Example corp HIP CA for 2001:db8::/48" .


I am working with a 2-tier pki.  The root CA cert will have some sort of 
standard DN for subjectName, naming the owner of the pki. The 
intermediate signing CA certs are for the agencies that actually 
register and, to some degree, manage these devices.  All these agencies 
will be 'named' by the HHIT (draft-moskowitz-hierarchical-hip) derived 
from the ed25519 key of their signing cert.  Well they are named by 
their /64 per the draft.   And perhaps that is better, as over the years 
there will be new signing certs with different keys, but the same HHIT 
prefix. Hmmm.


Also size of the DN is important as it is the issuerName in the client 
cert which may get transmitted over a very constrained (e.g. BT4) link.  
The intermediate CA cert has ITS issuerName of the root cert that 
identifies the pki for this purpose.  So the CN could simply be:


CN=2001:24:28:24/64

This would be for a HHIT HDA 20 in RRA 10 that is using HIT Suite 4.  
Makes perfect sense.  :)




As the author of a proposal in this area, could you define a notation
for IPv6 DNs, perhaps one that actually reflects the hierarchical nature
of IPv6 addresses?


The challenge with this is there is an ASSuMption that it looks like an 
IPv6 prefix so that is what is intended.  It might have to be more 
explicit like:


CN=IPv6::2001:24:28:24/64

Or something close to that.


You could take inspiration from the (unfortunately rarely used)
hierarchical DN representation of DNS names (this used the DNS
specific DC name components).  Overall the goal is to allow X.500
distinguished name restrictions to work correctly.

In practice you could follow the nibble notation as already used
for delegation of IPv6 reverse lookups in DNS.

However for the CN in the end cert you could perhaps use the full
DNS reverse IPv6 name
"x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.ip6.arpa" 


or the URL/Mail notation "[:::::::]"
where the hex notation shall be the shortest form permitted by the
IPv6 notation spec.


I am striving for smallness so that the client issuerName is small. This 
is scary long.  The routing prefix style is probably best for my purpose.




Examples of boundaries where hierarchical divisions would be practical
(if making a new design, it should be useful outside the HIT/HIP
standards):


That is why the standard IPv6 prefix notation is best.  People are use 
to it.




1. After the 1st nibble to cater for IANA design assignments (0 is
  special, 2 and 3 used for current live assignments, f used for
  special transmission modes such as multicast and local segment).

2. After the 2nd to 4th nibble to reflect assignments to continents
  (RIRs).  Different continents may operate under conflicting legal
  regimes for internal purposes, such as certificate privacy.

3. After the 4th to 6th nibble to reflect typical operator (LIR)
  assignments.

4. After the 6th to 8th nibble to reflect customer or other specific
  net assignments.

5. After the 14th nibble to reflect a single IEEE assigned MAC prefix
  (For example fe80:0:0:0:3a94:ed00::/88 would match the net local
  addresses of NETGEAR hardware using the 38-94-ED OUI block).

6. After the 18th nibble to reflect a single IEEE assigned MAC
  prefix excluding similar-looking non-MAC addresses (For example
  fe80:0:0:0:3a94:edff:fe00:/104 for that same block).

7. Even later nibbles to reflect assignment of part of an OUI block
  to a factory or production line that generates certificates for
  devices as they are manufactured.


The CA goes as long in the prefix as needed.  Parsing it follows the 
'known' rules.



Enjoy

Jakob


Oh, I am.  ;)

Re: Convert eddsa public key fro PEM to DER

[Robert Moskowitz]

On 8/14/19 8:42 AM, Matt Caswell wrote:


On 14/08/2019 13:21, Robert Moskowitz wrote:


On 8/14/19 6:22 AM, Matt Caswell wrote:

On 14/08/2019 11:06, Robert Moskowitz wrote:

I googled how to convert a PEM public key to DER and only found examples for RSA
keys.  Mine are ed25519.  I thought it would be a simple algorithm substitution:

$ openssl ed25519 -pubin -inform PEM -in $dir/private/intermediate.key.pem\

    -outform DER -out $dir/private/intermediate.key.der

Invalid command 'ed25519'; type "help" for a list.

So since my other commands use -algorithm, I tried:

$ openssl -algorithm $algorithm -pubin -inform PEM -in
$dir/private/intermediate.key.pem\

    -outform DER -out $dir/private/intermediate.key.der

Invalid command '-algorithm'; type "help" for a list.

So what is the command to convert an ed25519 public key from DER to PEM.  The
command I used to create the key was:

     openssl genpkey -aes256 -algorithm ed25519\
     -outform pem -out $dir/private/intermediate.key.pem

Firstly, that command creates a private key not a public key.

The what does the following say:

$    openssl pkey -inform $format\

     -in $dir/private/intermediate.key.pem -text -noout

Enter pass phrase for /home/rgm/uasca/intermediate/private/intermediate.key.pem:
ED25519 Private-Key:
priv:

It says in the two lines above that you have a private key. Every private key
implicitly has an associated public key with it (which is also shown below). But
the combined set is private, because it contains private data. By contrast if
you just have a public key then there is no private portion and so the whole key
is public.


Thanks.  It is beginning to filter into my morning brain mush.



Matt




     70:71:84:2b:81:e8:78:cb:6b:9c:97:28:92:7f:72:
     16:0a:40:fd:7b:38:e6:71:f7:2e:ad:2d:19:8e:e6:
     cf:58
pub:
     a4:de:b3:3c:b7:bd:12:5b:1a:e5:ac:58:76:15:7e:
     e8:98:2c:87:57:8b:c4:5b:98:33:d5:41:b5:e2:a4:
     54:db



So if you want to convert the above *private* key into DER then:

openssl pkey -in ed25519.pem -out ed25519.der -outform DER

If on the other hand you want to read the above *private* key and output the
associated *public* key in DER then:

openssl pkey -in ed25519.pem -out ed25519-pub.der -outform DER -pubout

Yes. thanks.  That works.


Matt

Re: Convert eddsa public key fro PEM to DER

[Robert Moskowitz]

On 8/14/19 6:22 AM, Matt Caswell wrote:


On 14/08/2019 11:06, Robert Moskowitz wrote:

I googled how to convert a PEM public key to DER and only found examples for RSA
keys.  Mine are ed25519.  I thought it would be a simple algorithm substitution:

$ openssl ed25519 -pubin -inform PEM -in $dir/private/intermediate.key.pem\

   -outform DER -out $dir/private/intermediate.key.der

Invalid command 'ed25519'; type "help" for a list.

So since my other commands use -algorithm, I tried:

$ openssl -algorithm $algorithm -pubin -inform PEM -in
$dir/private/intermediate.key.pem\

   -outform DER -out $dir/private/intermediate.key.der

Invalid command '-algorithm'; type "help" for a list.

So what is the command to convert an ed25519 public key from DER to PEM.  The
command I used to create the key was:

    openssl genpkey -aes256 -algorithm ed25519\
    -outform pem -out $dir/private/intermediate.key.pem

Firstly, that command creates a private key not a public key.


The what does the following say:

$    openssl pkey -inform $format\
>    -in $dir/private/intermediate.key.pem -text -noout
Enter pass phrase for 
/home/rgm/uasca/intermediate/private/intermediate.key.pem:

ED25519 Private-Key:
priv:
    70:71:84:2b:81:e8:78:cb:6b:9c:97:28:92:7f:72:
    16:0a:40:fd:7b:38:e6:71:f7:2e:ad:2d:19:8e:e6:
    cf:58
pub:
    a4:de:b3:3c:b7:bd:12:5b:1a:e5:ac:58:76:15:7e:
    e8:98:2c:87:57:8b:c4:5b:98:33:d5:41:b5:e2:a4:
    54:db




So if you want to convert the above *private* key into DER then:

openssl pkey -in ed25519.pem -out ed25519.der -outform DER

If on the other hand you want to read the above *private* key and output the
associated *public* key in DER then:

openssl pkey -in ed25519.pem -out ed25519-pub.der -outform DER -pubout


Yes. thanks.  That works.



Matt

Convert eddsa public key fro PEM to DER

[Robert Moskowitz]

I googled how to convert a PEM public key to DER and only found examples 
for RSA keys.  Mine are ed25519.  I thought it would be a simple 
algorithm substitution:


$ openssl ed25519 -pubin -inform PEM -in $dir/private/intermediate.key.pem\
>  -outform DER -out $dir/private/intermediate.key.der

Invalid command 'ed25519'; type "help" for a list.

So since my other commands use -algorithm, I tried:

$ openssl -algorithm $algorithm -pubin -inform PEM -in 
$dir/private/intermediate.key.pem\

>  -outform DER -out $dir/private/intermediate.key.der

Invalid command '-algorithm'; type "help" for a list.

So what is the command to convert an ed25519 public key from DER to 
PEM.  The command I used to create the key was:


   openssl genpkey -aes256 -algorithm ed25519\
   -outform pem -out $dir/private/intermediate.key.pem

thanks

IPv6 address encoding in commonName

[Robert Moskowitz]

I am fiddling around with an intermediate CA signing cert that the CA's 
'name' is it HIP (RFC 7401) HIT which is a valid IPv6 address. Actually 
a Hierarchical HIT as in draft-moskowitz-hierarchical-hip (to be revised 
soon).


For a client cert, it would be easy to put the HIT in subjectAltName per 
RFC 8002 (with a null subjectName), but a CA cert MUST have a non-empty 
subjectName.


Thus all I want in this subjectName is commonName with the HIT.

I am looking for examples of IPv6 addresses in commonName.

My searches today have come up empty.

Thank for any reference(s).

[openssl-users] Successful testing of 1.1.1

[Robert Moskowitz]

Fedora 29 beta just provided (in testing-update repo):

openssl-1.1.1-2.fc29.armv7hl.rpm

Against this version, I successfully produced by ED25519 pki per:

https://github.com/rgmhtt/draft-moskowitz-eddsa-pki

I have some minor textual edits to make in the draft and then submit 
it.  Then I can also go to IEEE 802.1 and raise up adding EDDSA support 
to IEEE 802.1AR.


Thank you for providing the code base!

And all your help along the way.


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] X25519 - why openssl shows server temp key as 253 bits?

[Robert Moskowitz]

My source is Dr. Lange at the IETF meeting in Toronto when the IETF 
selected EC25519.


A curve point needs an x and a y.  But do you need the y for the 
computation.  Do you only need its sign?  I don't know.  I am not a 
mathematician.


I may have misunderstood her at the time.

On 09/04/2018 10:19 AM, Jakob Bohm wrote:

On 04/09/2018 15:43, Robert Moskowitz wrote:
And I seem to recall that one bit is for compact representation. That 
is, is y positive or negative. With p256, you have to transmit x and 
y or deal with the compact representation patent.



Not sure if this applies do X25519 and Ed255 which use different
techniques than the traditional curves.

Those two are also intended to avoid data-dependent if() statements
(because of side channel attacks), but remain vulnerable on CPUs
where division or multiplication instructions have data-dependent
time and/or power consumption (which is unfortunately most of the
common ones).


On 09/04/2018 08:00 AM, Kyle Hamilton wrote:
Probably because the definition of X25519 requires that bits 0, 1, 
and 2 of the first byte of the private key are set to 0 before being 
used, and OpenSSL counts the number of bits including the 
highest-order set bit. (Really, there's an additional 2 bits that 
are also set to known values: bit 6 of the last byte is set, and bit 
7 of the last byte is cleared.  In my view, this actually reduces 
the necessary brute-force search space from 256 bits to 251 bits. 
However, literally any 32-byte string can be used as a public key.  
Apparently, djb views this as sufficient to call it a 256-bit 
strength function.)


For the specification, please see the subsection entitled 
"Responsibilities of the User" in section 3 of 
https://cr.yp.to/ecdh/curve25519-20060209.pdf .


-Kyle H





On Mon, Sep 3, 2018, 22:29 M K Saravanan <mailto:mksa...@gmail.com>> wrote:


    Hi,

    When using openssl with X25519, why it shows the server temp key
    as 253 bits?

    Example:

    ---
    No client certificate CA names sent
    Peer signing digest: SHA256
    Peer signature type: RSA
    Server Temp Key: X25519, 253 bits
    ---

    I thought Curve25519 is using 256 bit keys.

    Why 253 instead of 256?

    with regards,
    Saravanan



Enjoy

Jakob


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] X25519 - why openssl shows server temp key as 253 bits?

[Robert Moskowitz]

And I seem to recall that one bit is for compact representation. That 
is, is y positive or negative.  With p256, you have to transmit x and y 
or deal with the compact representation patent.


On 09/04/2018 08:00 AM, Kyle Hamilton wrote:
Probably because the definition of X25519 requires that bits 0, 1, and 
2 of the first byte of the private key are set to 0 before being used, 
and OpenSSL counts the number of bits including the highest-order set 
bit.  (Really, there's an additional 2 bits that are also set to known 
values: bit 6 of the last byte is set, and bit 7 of the last byte is 
cleared.  In my view, this actually reduces the necessary brute-force 
search space from 256 bits to 251 bits. However, literally any 32-byte 
string can be used as a public key.  Apparently, djb views this as 
sufficient to call it a 256-bit strength function.)


For the specification, please see the subsection entitled 
"Responsibilities of the User" in section 3 of 
https://cr.yp.to/ecdh/curve25519-20060209.pdf .


-Kyle H





On Mon, Sep 3, 2018, 22:29 M K Saravanan > wrote:


Hi,

When using openssl with X25519, why it shows the server temp key
as 253 bits?

Example:

---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA
Server Temp Key: X25519, 253 bits
---

I thought Curve25519 is using 256 bit keys.

Why 253 instead of 256?

with regards,
Saravanan
-- 
openssl-users mailing list

To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users





-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Robert Moskowitz]

On 08/27/2018 04:55 PM, Benjamin Kaduk via openssl-users wrote:

On Mon, Aug 27, 2018 at 04:38:24PM -0400, Robert Moskowitz wrote:


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:

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...

Well, see https://datatracker.ietf.org/doc/draft-wkumari-not-a-draft/ .


Warren is a riot.  I really should have put in a typo comment to him 
about 'safely razor' which probably should be 'safety razor'.  But then 
kind of knowing Warren, this could have been intentional so I left it 
alone. :)





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.

Yup!  Internet-Draft is a fine terminus for some types of document.
Many TLS registries now have a registration policy that explicitly calls out
an internet-draft that is never published as anything else, as a valid 
specification
for getting a codepoint assignment.

-Ben


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [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 o

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

[Robert Moskowitz]

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.


If my making EDDSA certs easy for testing and I get one IoT product 
using certs that would otherwise claim that their product could not 
support the overhead of certs, it has been worth it.


I don't expect RFCs  from these draft.  Now Internet Drafts live forever 
(the drafts Yakov and I did for RFC 1597 are gone).  So my work will be 
around for others to use without a lot of pecking at google and this 
list to get it working.


And with eddsa, I did find one issue.  I was on the front side of things 
for a change.



--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Robert Moskowitz]

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.



--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Robert Moskowitz]

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.




Matt



Matt



On 08/21/2018 08:36 AM, OpenSSL wrote:

  OpenSSL version 1.1.1 pre release 9 (beta)
  ===

  OpenSSL - The Open Source toolkit for SSL/TLS
  https://www.openssl.org/

  OpenSSL 1.1.1 is currently in beta. OpenSSL 1.1.1 pre release 9
has now
  been made available. For details of changes and known issues see
the
  release notes at:

   https://www.openssl.org/news/openssl-1.1.1-notes.html

  Note: This OpenSSL pre-release has been provided for testing ONLY.
  It should NOT be used for security critical purposes.

  The beta release is available for download via HTTP and FTP from
the
  following master locations (you can find the various FTP mirrors
under
  https://www.openssl.org/source/mirror.html):

    * https://www.openssl.org/source/
    * ftp://ftp.openssl.org/source/

  The distribution file name is:

   o openssl-1.1.1-pre9.tar.gz
     Size: 8411103
     SHA1 checksum: 01a42e93a34746340974b9fafe960226f7d10ff7
     SHA256 checksum:
95ebdfbb05e8451fb01a186ccaa4a7da0eff9a48999ede9fe1a7d90db75ccb4c

  The checksums were calculated using the following commands:

   openssl sha1 openssl-1.1.1-pre9.tar.gz
   openssl sha256 openssl-1.1.1-pre9.tar.gz

  Please download and check this beta release as soon as possible.
  To report a bug, open an issue on GitHub:

   https://github.com/openssl/openssl/issues

  Please check the release notes and mailing lists to avoid duplicate
  reports of known issues. (Of course, the source is also available
  on GitHub.)

  Yours,

  The OpenSSL Project Team.




--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Robert Moskowitz]

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.



Matt



On 08/21/2018 08:36 AM, OpenSSL wrote:

 OpenSSL version 1.1.1 pre release 9 (beta)
 ===

 OpenSSL - The Open Source toolkit for SSL/TLS
 https://www.openssl.org/

 OpenSSL 1.1.1 is currently in beta. OpenSSL 1.1.1 pre release 9
has now
 been made available. For details of changes and known issues see the
 release notes at:

  https://www.openssl.org/news/openssl-1.1.1-notes.html

 Note: This OpenSSL pre-release has been provided for testing ONLY.
 It should NOT be used for security critical purposes.

 The beta release is available for download via HTTP and FTP from the
 following master locations (you can find the various FTP mirrors
under
 https://www.openssl.org/source/mirror.html):

   * https://www.openssl.org/source/
   * ftp://ftp.openssl.org/source/

 The distribution file name is:

  o openssl-1.1.1-pre9.tar.gz
Size: 8411103
SHA1 checksum: 01a42e93a34746340974b9fafe960226f7d10ff7
SHA256 checksum:
95ebdfbb05e8451fb01a186ccaa4a7da0eff9a48999ede9fe1a7d90db75ccb4c

 The checksums were calculated using the following commands:

  openssl sha1 openssl-1.1.1-pre9.tar.gz
  openssl sha256 openssl-1.1.1-pre9.tar.gz

 Please download and check this beta release as soon as possible.
 To report a bug, open an issue on GitHub:

  https://github.com/openssl/openssl/issues

 Please check the release notes and mailing lists to avoid duplicate
 reports of known issues. (Of course, the source is also available
 on GitHub.)

 Yours,

 The OpenSSL Project Team.




--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] ED488 question

[Robert Moskowitz]

On 08/21/2018 11:29 AM, Viktor Dukhovni wrote:



On Aug 21, 2018, at 11:27 AM, Robert Moskowitz  wrote:

Was thinking about ED488 last night.  I am personally not interested in these 
larger curves, but perhaps I can make my draft 'more complete' if I include 488 
along with 25519.

Are there any parameters beyond changing the algorithm from ed25519 to ed488?  
Is a hash needed for the version of ed488 implemented?

Ed448 is a drop-in-replacement for Ed25519, only the sizes of keys and 
signatures
change.

Thought so, but decided to stick my neck out and ask before I run my 
scripts and test and then get interesting errors.


May STILL get interesting errors :)  But that is the challenging part of 
it all.


thanks
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] ED488 question

[Robert Moskowitz]

Was thinking about ED488 last night.  I am personally not interested in 
these larger curves, but perhaps I can make my draft 'more complete' if 
I include 488 along with 25519.


Are there any parameters beyond changing the algorithm from ed25519 to 
ed488?  Is a hash needed for the version of ed488 implemented?


thanks

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Robert Moskowitz]

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.


On 08/21/2018 08:36 AM, OpenSSL wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512


OpenSSL version 1.1.1 pre release 9 (beta)
===

OpenSSL - The Open Source toolkit for SSL/TLS
https://www.openssl.org/

OpenSSL 1.1.1 is currently in beta. OpenSSL 1.1.1 pre release 9 has now
been made available. For details of changes and known issues see the
release notes at:

 https://www.openssl.org/news/openssl-1.1.1-notes.html

Note: This OpenSSL pre-release has been provided for testing ONLY.
It should NOT be used for security critical purposes.

The beta release is available for download via HTTP and FTP from the
following master locations (you can find the various FTP mirrors under
https://www.openssl.org/source/mirror.html):

  * https://www.openssl.org/source/
  * ftp://ftp.openssl.org/source/

The distribution file name is:

 o openssl-1.1.1-pre9.tar.gz
   Size: 8411103
   SHA1 checksum: 01a42e93a34746340974b9fafe960226f7d10ff7
   SHA256 checksum: 
95ebdfbb05e8451fb01a186ccaa4a7da0eff9a48999ede9fe1a7d90db75ccb4c

The checksums were calculated using the following commands:

 openssl sha1 openssl-1.1.1-pre9.tar.gz
 openssl sha256 openssl-1.1.1-pre9.tar.gz

Please download and check this beta release as soon as possible.
To report a bug, open an issue on GitHub:

 https://github.com/openssl/openssl/issues

Please check the release notes and mailing lists to avoid duplicate
reports of known issues. (Of course, the source is also available
on GitHub.)

Yours,

The OpenSSL Project Team.

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAlt8Ah8ACgkQ2cTSbQ5g
RJGYTAgAm4xPeNBGKAsmA9eoRm8FkQHew1zhf9G2P677n26+JKwoUBx7O6c/zhKV
c9wP5xjvDl3KlUNw3gga2URIE95wj4RGMOcLUxWEVci+oR7luRXDocJKcAfppLcl
50T4OKL/5tqtAodI700t42SlA4EWyZIv+Kt5YMzQnkbbelGqFA8Loi1yDks+JwWU
2xlx4ukAvCNUuHvKIs85QaRi5PSWRZHE4o49ijP+ynUSxSqjGTLpeW+Ij6pHOH+e
2rKAScmx1Ll3ZK50dVnlWif6H7hjftWclqbNXrGy76SUQjmmzi1vxAm8ftmgUZEP
qXxGwJpfpCirNBHPSXeaMSe4thZeCw==
=etGy
-END PGP SIGNATURE-


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] EDDSA test results

[Robert Moskowitz]

Oops.  That is the Fedora 29 beta...

On 08/10/2018 04:44 PM, Robert Moskowitz wrote:

I have followed the procedure I made for ECDSA certs in:

draft-moskowitz-ecdsa-pki (an update is pending on typos I encountered 
in this run through)


But making ED25519 certs instead.

Other than obvious changes (e.g. -algorithm ed25519) and hash 
specification, I was successful.


My testing was done on a Fedora-armhfp-28-beta system providing openssl:

OpenSSL 1.1.1-pre8 (beta) FIPS 20 Jun 2018

I am going to assume that PR6901 will go into the next beta and I can 
drop the '-md null' from some command lines and do not have to make 
special .cnf files without md_default lines.


I will test this on the next beta to be sure (trust, but verify!)

Remaining to do:

Using the tree command, here are some certificate size comparisons

      ECDSA ED25519

Root cert   826 737

Intermedicate CA cert   806     721

Client cert 944     834

Server cert    1086 971



thank you for making ED25519 available!



--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] EDDSA test results

[Robert Moskowitz]

I have followed the procedure I made for ECDSA certs in:

draft-moskowitz-ecdsa-pki (an update is pending on typos I encountered 
in this run through)


But making ED25519 certs instead.

Other than obvious changes (e.g. -algorithm ed25519) and hash 
specification, I was successful.


My testing was done on a Fedora-armhfp-28-beta system providing openssl:

OpenSSL 1.1.1-pre8 (beta) FIPS 20 Jun 2018

I am going to assume that PR6901 will go into the next beta and I can 
drop the '-md null' from some command lines and do not have to make 
special .cnf files without md_default lines.


I will test this on the next beta to be sure (trust, but verify!)

Remaining to do:

Using the tree command, here are some certificate size comparisons

          ECDSA ED25519

Root cert   826 737

Intermedicate CA cert   806     721

Client cert     944     834

Server cert    1086 971



thank you for making ED25519 available!

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] EDDSA crl creation woes

[Robert Moskowitz]

On 08/09/2018 09:34 AM, Matt Caswell wrote:


On 08/08/18 20:49, Robert Moskowitz wrote:

Finally back on working on my EDDSA pki.

Working on beta Fedora29 which now ships with:

OpenSSL 1.1.1-pre8 (beta) FIPS 20 Jun 2018


To recap, there are challenges on hash specification.  In creating
certs, I cannot have default_md line in my .cnf file, or at least for it
to = sha256.  And in those commands where I had to have -md sha256 with
ecdsa, I have to have -md null.  This is compared to those commands that
took -sha256 and now require nothing in the command line about the hash.

So one to crl:

    openssl ca -config $dir/openssl-$intermediate.cnf \
  -gencrl -out $dir/crl/$crl

Using configuration from /root/ca/intermediate/openssl-intermediate.cnf
Enter pass phrase for /root/ca/intermediate/private/intermediate.key.pem:
variable lookup failed for CA_default::default_md
3069739024:error:0E06D06C:configuration file
routines:NCONF_get_string:no
value:crypto/conf/conf_lib.c:275:group=CA_default name=default_md

In this .cnf file, there is no default_md line.

So I added -md to the command line:

    openssl ca -config $dir/openssl-$intermediate.cnf -md null\
  -gencrl -out $dir/crl/$crl

And that worked.

Very confusing.  It would be preferable if EDDSA related generation just
ignores md values?



I've just created PR 6901 that will hopefully improve things. This
basically ignores any -md or default_md setting if EdDSA is in use.

https://github.com/openssl/openssl/pull/6901


Matt,

Thanks for addressing this.  It will keep a lot of questions off the 
user list once use of EDDSA becomes 'mainline'.


Please let me know when a beta is out with this change so I can ask the 
Fedora team to grab it so I can test it.


It pulls a big caveat section from the eddsa-pki draft I am writing.


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] EDDSA crl creation woes

[Robert Moskowitz]

Finally back on working on my EDDSA pki.

Working on beta Fedora29 which now ships with:

OpenSSL 1.1.1-pre8 (beta) FIPS 20 Jun 2018


To recap, there are challenges on hash specification.  In creating 
certs, I cannot have default_md line in my .cnf file, or at least for it 
to = sha256.  And in those commands where I had to have -md sha256 with 
ecdsa, I have to have -md null.  This is compared to those commands that 
took -sha256 and now require nothing in the command line about the hash.


So one to crl:

   openssl ca -config $dir/openssl-$intermediate.cnf \
 -gencrl -out $dir/crl/$crl

Using configuration from /root/ca/intermediate/openssl-intermediate.cnf
Enter pass phrase for /root/ca/intermediate/private/intermediate.key.pem:
variable lookup failed for CA_default::default_md
3069739024:error:0E06D06C:configuration file 
routines:NCONF_get_string:no 
value:crypto/conf/conf_lib.c:275:group=CA_default name=default_md


In this .cnf file, there is no default_md line.

So I added -md to the command line:

   openssl ca -config $dir/openssl-$intermediate.cnf -md null\
 -gencrl -out $dir/crl/$crl

And that worked.

Very confusing.  It would be preferable if EDDSA related generation just 
ignores md values?



--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Errors on EndEntity cert generation

[Robert Moskowitz]

On 07/27/2018 01:26 PM, Viktor Dukhovni wrote:

On Jul 27, 2018, at 1:20 PM, Robert Moskowitz  wrote:

On 07/27/2018 01:14 PM, Viktor Dukhovni wrote:

On Jul 27, 2018, at 1:07 PM, Robert Moskowitz  wrote:

Error Loading extension section server_cert
3065065488:error:0E06D06C:configuration file routines:NCONF_get_string:no 
value:crypto/conf/conf_lib.c:275:group=CA_default name=email_in_dn
3065065488:error:0E06D06C:configuration file routines:NCONF_get_string:no 
value:crypto/conf/conf_lib.c:275:group=CA_default name=rand_serial
3065065488:error:2206D06C:X509 V3 routines:X509V3_parse_list:invalid null 
name:crypto/x509v3/v3_utl.c:360:
3065065488:error:22097069:X509 V3 routines:do_ext_nconf:invalid extension 
string:crypto/x509v3/v3_conf.c:93:name=crlDistributionPoints,section=
3065065488:error:22098080:X509 V3 routines:X509V3_EXT_nconf:error in 
extension:crypto/x509v3/v3_conf.c:47:name=crlDistributionPoints, value=

Please help me with these latest errors.

Start with a less exotic ".cnf" file.  These are all configuration errors,
unrelated to ed25519.  Get a working RSA config file, and then switch
algorithms.


I am using a working ecdsa config file

It is a good idea to read that file and match the error messages
to the file content.  You'll quickly find a bunch of $ENV:: settings
that must yield non-empty results, but you (surely) don't have those
environment variables set...  There are perhaps other issues.


I read those messages and got stuck on the first and did not catch the 
last 2.  My procedure did not set ocspIAI and crlDP.  :(


Even though my write up says to make sure to do this!  Sigh.

Got my EE server cert.  Onwards!




(the one in my draft-moskowitz-ecdsa-pki):

# OpenSSL intermediate CA configuration file.
# Copy to `$dir/intermediate/openssl-intermediate.cnf`.

[ ca ]
# `man ca`
default_ca = CA_default

[ CA_default ]
# Directory and file locations.
dir= $ENV::dir
cadir = $ENV::cadir
format= $ENV::format

certs = $dir/certs
crl_dir  = $dir/crl
new_certs_dir  = $dir/newcerts
database = $dir/index.txt
serial= $dir/serial
RANDFILE = $dir/private/.rand

# The Intermediate key and Intermediate certificate.
private_key = $dir/private/intermediate.key.$format
certificate = $dir/certs/intermediate.cert.$format

# For certificate revocation lists.
crlnumber= $dir/crlnumber
crl= $dir/crl/intermediate.crl.pem
crl_extensions = crl_ext
default_crl_days  = $ENV::default_crl_days

# SHA-1 is deprecated, so use SHA-2 instead.
# default_md  = sha256

name_opt = ca_default
cert_opt = ca_default
default_days= 375
preserve = no
policy= policy_loose
copy_extensions= copy

[ policy_strict ]
# The root CA should only sign intermediate certificates that match.
# See the POLICY FORMAT section of `man ca`.
countryName = match
stateOrProvinceName  = match
organizationName  = match
organizationalUnitName  = optional
commonName  = optional

[ policy_loose ]
# Allow the intermediate CA to sign a more
#  diverse range of certificates.
# See the POLICY FORMAT section of the `ca` man page.
countryName = optional
stateOrProvinceName  = optional
localityName= optional
organizationName  = optional
organizationalUnitName  = optional
commonName  = optional
UID= optional

[ req ]
# Options for the `req` tool (`man req`).
default_bits  = 2048
distinguished_name  = req_distinguished_name
string_mask= utf8only
req_extensions= req_ext

# SHA-1 is deprecated, so use SHA-2 instead.
# default_md = sha256

# Extension to add when the -x509 option is used.
x509_extensions  = v3_ca

[ req_distinguished_name ]
# See <https://en.wikipedia.org/wiki/Certificate_signing_request>.
countryName= Country Name (2 letter code)
stateOrProvinceName = State or Province Name
localityName  = Locality Name
0.organizationName  = Organization Name
organizationalUnitName = Organizational Unit Name
commonName = Common Name
UID  = User ID

# Optionally, specify some defaults.
# countryName_default = US
# stateOrProvinceName_default  = MI
# localityName_default= Oak Park
# 0.organizationName_default= HTT Consulting
# organizationalUnitName_default  =

[ req_ext ]
subjectAltName = $ENV::subjectAltName

[ v3_ca ]
# Extensions for a typical CA (`man x509v3_config`).
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true
# keyUsage = critical, digitalSignature, cRLSign, keyCertSign
keyUsage = critical, cRLSign, keyCertSign

[ v3_intermediate_ca ]
# Extensions for a typical intermediate CA (`man x509v3_config`).
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true, pathlen:0
# keyUsage = critical, digitalSignature, cRLSign, keyCertSign
keyUsage = critical, cRLSign, keyCertSign

[ usr_cert ]
# Extensions for client certificates (`man x509v3_config`).
basicConstraints = CA:FALSE
nsCertType = client, email
nsComment = "OpenSSL Generated Client Certificate"
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,

Re: [openssl-users] Errors on EndEntity cert generation

[Robert Moskowitz]

On 07/27/2018 01:14 PM, Viktor Dukhovni wrote:



On Jul 27, 2018, at 1:07 PM, Robert Moskowitz  wrote:

Error Loading extension section server_cert
3065065488:error:0E06D06C:configuration file routines:NCONF_get_string:no 
value:crypto/conf/conf_lib.c:275:group=CA_default name=email_in_dn
3065065488:error:0E06D06C:configuration file routines:NCONF_get_string:no 
value:crypto/conf/conf_lib.c:275:group=CA_default name=rand_serial
3065065488:error:2206D06C:X509 V3 routines:X509V3_parse_list:invalid null 
name:crypto/x509v3/v3_utl.c:360:
3065065488:error:22097069:X509 V3 routines:do_ext_nconf:invalid extension 
string:crypto/x509v3/v3_conf.c:93:name=crlDistributionPoints,section=
3065065488:error:22098080:X509 V3 routines:X509V3_EXT_nconf:error in 
extension:crypto/x509v3/v3_conf.c:47:name=crlDistributionPoints, value=

Please help me with these latest errors.

Start with a less exotic ".cnf" file.  These are all configuration errors,
unrelated to ed25519.  Get a working RSA config file, and then switch
algorithms.

I am using a working ecdsa config file (the one in my 
draft-moskowitz-ecdsa-pki):


# OpenSSL intermediate CA configuration file.
# Copy to `$dir/intermediate/openssl-intermediate.cnf`.

[ ca ]
# `man ca`
default_ca = CA_default

[ CA_default ]
# Directory and file locations.
dir= $ENV::dir
cadir = $ENV::cadir
format= $ENV::format

certs = $dir/certs
crl_dir  = $dir/crl
new_certs_dir  = $dir/newcerts
database = $dir/index.txt
serial= $dir/serial
RANDFILE = $dir/private/.rand

# The Intermediate key and Intermediate certificate.
private_key = $dir/private/intermediate.key.$format
certificate = $dir/certs/intermediate.cert.$format

# For certificate revocation lists.
crlnumber= $dir/crlnumber
crl= $dir/crl/intermediate.crl.pem
crl_extensions = crl_ext
default_crl_days  = $ENV::default_crl_days

# SHA-1 is deprecated, so use SHA-2 instead.
# default_md  = sha256

name_opt = ca_default
cert_opt = ca_default
default_days= 375
preserve = no
policy= policy_loose
copy_extensions= copy

[ policy_strict ]
# The root CA should only sign intermediate certificates that match.
# See the POLICY FORMAT section of `man ca`.
countryName = match
stateOrProvinceName  = match
organizationName  = match
organizationalUnitName  = optional
commonName  = optional

[ policy_loose ]
# Allow the intermediate CA to sign a more
#  diverse range of certificates.
# See the POLICY FORMAT section of the `ca` man page.
countryName = optional
stateOrProvinceName  = optional
localityName= optional
organizationName  = optional
organizationalUnitName  = optional
commonName  = optional
UID= optional

[ req ]
# Options for the `req` tool (`man req`).
default_bits  = 2048
distinguished_name  = req_distinguished_name
string_mask= utf8only
req_extensions= req_ext

# SHA-1 is deprecated, so use SHA-2 instead.
# default_md = sha256

# Extension to add when the -x509 option is used.
x509_extensions  = v3_ca

[ req_distinguished_name ]
# See <https://en.wikipedia.org/wiki/Certificate_signing_request>.
countryName= Country Name (2 letter code)
stateOrProvinceName = State or Province Name
localityName  = Locality Name
0.organizationName  = Organization Name
organizationalUnitName = Organizational Unit Name
commonName = Common Name
UID  = User ID

# Optionally, specify some defaults.
# countryName_default = US
# stateOrProvinceName_default  = MI
# localityName_default= Oak Park
# 0.organizationName_default= HTT Consulting
# organizationalUnitName_default  =

[ req_ext ]
subjectAltName = $ENV::subjectAltName

[ v3_ca ]
# Extensions for a typical CA (`man x509v3_config`).
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true
# keyUsage = critical, digitalSignature, cRLSign, keyCertSign
keyUsage = critical, cRLSign, keyCertSign

[ v3_intermediate_ca ]
# Extensions for a typical intermediate CA (`man x509v3_config`).
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true, pathlen:0
# keyUsage = critical, digitalSignature, cRLSign, keyCertSign
keyUsage = critical, cRLSign, keyCertSign

[ usr_cert ]
# Extensions for client certificates (`man x509v3_config`).
basicConstraints = CA:FALSE
nsCertType = client, email
nsComment = "OpenSSL Generated Client Certificate"
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
keyUsage = critical,nonRepudiation,digitalSignature,keyEncipherment
extendedKeyUsage = clientAuth, emailProtection
crlDistributionPoints = $ENV::crlDP
authorityInfoAccess = $ENV::ocspIAI

[ server_cert ]
# Extensions for server certificates (`man x509v3_config`).
basicConstraints = CA:FALSE
nsCertType = server
nsComment = "OpenSSL Generated Server Certificate"
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer:always
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
crlDistributionPoints = $ENV::crlDP
authorityInfoAccess = $E

[openssl-users] Errors on EndEntity cert generation

[Robert Moskowitz]

The hits just keep on coming.  Made my cert req,

   openssl req -config $dir/openssl-intermediate.cnf\
   -key $dir/private/$serverfqdn.key.$format \
   -subj "$DN" -new -out $dir/csr/$serverfqdn.csr.$format

DN='/C=US/ST=MI/L=Oak Park/O=HTT Consulting'

then tried to make the cert with:

   openssl ca -config $dir/openssl-intermediate.cnf -days 375\
   -extensions server_cert -notext -md null \
   -in $dir/csr/$serverfqdn.csr.$format\
   -out $dir/certs/$serverfqdn.cert.$format

(note use of -md null and nothing got the earlier error)

Using configuration from /root/ca/intermediate/openssl-intermediate.cnf
Enter pass phrase for /root/ca/intermediate/private/intermediate.key.pem:
Error Loading extension section server_cert
3065065488:error:0E06D06C:configuration file 
routines:NCONF_get_string:no 
value:crypto/conf/conf_lib.c:275:group=CA_default name=email_in_dn
3065065488:error:0E06D06C:configuration file 
routines:NCONF_get_string:no 
value:crypto/conf/conf_lib.c:275:group=CA_default name=rand_serial
3065065488:error:2206D06C:X509 V3 routines:X509V3_parse_list:invalid 
null name:crypto/x509v3/v3_utl.c:360:
3065065488:error:22097069:X509 V3 routines:do_ext_nconf:invalid 
extension 
string:crypto/x509v3/v3_conf.c:93:name=crlDistributionPoints,section=
3065065488:error:22098080:X509 V3 routines:X509V3_EXT_nconf:error in 
extension:crypto/x509v3/v3_conf.c:47:name=crlDistributionPoints, value=



Please help me with these latest errors.

Thanks

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Intermediate cert file failure

[Robert Moskowitz]

On 07/27/2018 12:35 PM, Viktor Dukhovni wrote:



On Jul 27, 2018, at 11:25 AM, Robert Moskowitz  wrote:

3064446992:error:2006D080:BIO routines:BIO_new_file:no such 
file:crypto/bio/bss_file.c:79:
variable lookup failed for CA_default::default_md
3064446992:error:0E06D06C:configuration file routines:NCONF_get_string:no 
value:crypto/conf/conf_lib.c:275:group=CA_default name=default_md

Well ca(1) wants either an explicit "md" option or a default_md.
Perhaps it does not yet support ed25519.  You can sign directly
with "openssl x509", but first try

openssl ca -md null
or
openssl ca -md default

and see if either of those work.


-md null worked:

   openssl ca -config $cadir/openssl-root.cnf -days 3650\
   -extensions v3_intermediate_ca -notext -md null\
   -in $dir/csr/intermediate.csr.$format\
   -out $dir/certs/intermediate.cert.pem

Can't open /root/ca/intermediate/index.txt.attr for reading, No such 
file or directory
3064946704:error:02001002:system library:fopen:No such file or 
directory:crypto/bio/bss_file.c:72:fopen('/root/ca/intermediate/index.txt.attr','r')
3064946704:error:2006D080:BIO routines:BIO_new_file:no such 
file:crypto/bio/bss_file.c:79:

Check that the request matches the signature
Signature ok
Certificate Details:
    Serial Number:
    ad:0f:52:5d:91:70:1a:d3
    Validity
    Not Before: Jul 27 16:41:03 2018 GMT
    Not After : Jul 24 16:41:03 2028 GMT
    Subject:
    countryName   = US
    stateOrProvinceName   = MI
    organizationName  = HTT Consulting
    commonName    = Signing CA
    X509v3 extensions:
    X509v3 Subject Key Identifier:
DB:5F:0C:00:54:DD:A6:EB:61:BD:79:13:0A:2D:EA:0A:19:82:E8:C5
    X509v3 Authority Key Identifier:
keyid:D6:1B:BA:96:44:EF:F1:07:59:35:A7:F2:77:5F:82:24:21:53:9A:9F

    X509v3 Basic Constraints: critical
    CA:TRUE, pathlen:0
    X509v3 Key Usage: critical
    Certificate Sign, CRL Sign
    X509v3 Subject Alternative Name:
    email:postmas...@htt-consult.com
Certificate is to be certified until Jul 24 16:41:03 2028 GMT (3650 days)
Sign the certificate? [y/n]:y


1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated

There was no file index.txt.attr, but now there is:

# cat index.txt.attr
unique_subject = yes

I don't remember this from my ecdsa work with 1.1.0

This issue with md is definitely and issue.  I can try -md null on the 
self-signed root cert, but it seems that this should not even be 
referenced for ed25519


But I got my intermediate cert, so on to the next step.

thanks for your help, Viktor.


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Intermediate cert file failure

[Robert Moskowitz]

on a default_md error:

   openssl req -config $cadir/openssl-root.cnf\
   -key $dir/private/intermediate.key.$format \
   -keyform $format -outform $format -subj "$DN" -new\
   -out $dir/csr/intermediate.csr.$format

format=pem

   openssl rand -hex $sn > $dir/serial # hex 8 is minimum, 19 is maximum

   openssl ca -config $cadir/openssl-root.cnf -days 3650\
   -extensions v3_intermediate_ca -notext\
   -in $dir/csr/intermediate.csr.$format\
   -out $dir/certs/intermediate.cert.pem

Using configuration from /root/ca/openssl-root.cnf
Enter pass phrase for /root/ca/private/ca.key.pem:
Can't open /root/ca/intermediate/index.txt.attr for reading, No such 
file or directory
3064446992:error:02001002:system library:fopen:No such file or 
directory:crypto/bio/bss_file.c:72:fopen('/root/ca/intermediate/index.txt.attr','r')
3064446992:error:2006D080:BIO routines:BIO_new_file:no such 
file:crypto/bio/bss_file.c:79:

variable lookup failed for CA_default::default_md
3064446992:error:0E06D06C:configuration file 
routines:NCONF_get_string:no 
value:crypto/conf/conf_lib.c:275:group=CA_default name=default_md


Why is it asking for index.txt.attr?  I made serial which at least with 
ecdsa overrode using index.txt?


And then default_md is commented out in both my .cnf files.


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] ed25519 self-signed root cert

[Robert Moskowitz]

On 07/27/2018 10:43 AM, Viktor Dukhovni wrote:



On Jul 27, 2018, at 10:36 AM, Robert Moskowitz  wrote:

nyway error on the next step:

# openssl req -config $dir/openssl-root.cnf\

  -set_serial 0x$(openssl rand -hex $sn)\
  -keyform pem -outform pem\
  -key $dir/private/ca.key.pem -subj "$DN"\
  -new -x509 -days 7300 -extensions v3_ca\
  -out $dir/certs/ca.cert.pem

Enter pass phrase for /root/ca/private/ca.key.pem:
3064983568:error:1010F08A:elliptic curve routines:pkey_ecd_ctrl:invalid digest 
type:crypto/ec/ecx_meth.c:801:

Do you have a "default_md" in your configuration file?
Ed25519 and Ed448 sign the raw data, not a digest thereof.

It might be more use-friendly to figure out a way to ignore
the requested digest rather than throw an error...



Ouch.  That is bad.  Since ed25519 does not use md, it should not error 
out on this at all.  Makes it especially challenging for a cnf file to 
have multiple uses.  I commented out default_md and it worked.  Dumping 
it shows:


# openssl x509 -inform pem -in $dir/certs/ca.cert.pem\
> -text -noout
Certificate:
    Data:
    Version: 3 (0x2)
    Serial Number:
    49:b3:1f:0f:cf:8a:9a:d9
    Signature Algorithm: ED25519
    Issuer: C = US, ST = MI, L = Oak Park, O = HTT Consulting, CN = 
Root CA

    Validity
    Not Before: Jul 27 14:49:02 2018 GMT
    Not After : Jul 22 14:49:02 2038 GMT
    Subject: C = US, ST = MI, L = Oak Park, O = HTT Consulting, CN 
= Root CA

    Subject Public Key Info:
    Public Key Algorithm: ED25519
    ED25519 Public-Key:
    pub:
    ea:c7:3a:3c:80:49:ce:c9:a6:eb:a4:01:0a:11:df:
    62:58:27:e0:af:77:5c:3e:fd:73:08:24:f8:e4:b1:
    45:0c
    X509v3 extensions:
    X509v3 Subject Key Identifier:
D6:1B:BA:96:44:EF:F1:07:59:35:A7:F2:77:5F:82:24:21:53:9A:9F
    X509v3 Authority Key Identifier:
keyid:D6:1B:BA:96:44:EF:F1:07:59:35:A7:F2:77:5F:82:24:21:53:9A:9F

    X509v3 Basic Constraints: critical
    CA:TRUE
    X509v3 Key Usage: critical
    Certificate Sign, CRL Sign
    X509v3 Subject Alternative Name:
    email:postmas...@htt-consult.com
    Signature Algorithm: ED25519
 93:f9:f9:c2:a6:e7:ca:8f:5c:82:4b:fa:7f:a8:0f:4c:e2:46:
 52:f3:99:d0:ad:f0:2c:2b:b4:f3:90:26:27:8f:36:2b:ed:cf:
 58:c5:f4:28:78:ec:59:53:13:ac:96:32:fa:07:ac:b6:d8:eb:
 78:2c:da:19:95:6e:ed:36:bb:09


So on to the next step.


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] ed25519 self-signed root cert

[Robert Moskowitz]

genpkey worked without those options.  I am going to have to look at the 
RFC again, as there are different types of ed25519 certs, but how will 
that work out in openssl?  I will have to remember back to a 
conversation at had at IETF 100...


Anyway error on the next step:

# openssl req -config $dir/openssl-root.cnf\
>  -set_serial 0x$(openssl rand -hex $sn)\
>  -keyform pem -outform pem\
>  -key $dir/private/ca.key.pem -subj "$DN"\
>  -new -x509 -days 7300 -extensions v3_ca\
>  -out $dir/certs/ca.cert.pem
Enter pass phrase for /root/ca/private/ca.key.pem:
3064983568:error:1010F08A:elliptic curve routines:pkey_ecd_ctrl:invalid 
digest type:crypto/ec/ecx_meth.c:801:


where dir=/root/ca



--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] genpkey for ed25519

[Robert Moskowitz]

Here we go again with figuring out what to put in the command lines.  
Dr. Google is not giving up enough answers.


For ecdsa I started with:

openssl genpkey -aes256 -algorithm ec\
 -pkeyopt ec_paramgen_curve:prime256v1\
 -outform pem -pkeyopt ec_param_enc:named_curve\
 -out $dir/private/ca.key.pem

I found one reference that I should use -algorithm ed25519 (though the 
example used caps: ED25519)


But I have not found recommendation for ec_parmgen_curve or ec_param_enc

Can someone point me to the information on values for these (and I 
suspect I will be hitting others as I go).


thanks



--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] EDDSA support yet?

[Robert Moskowitz]

On 07/26/2018 11:59 AM, Tomas Mraz wrote:

On Thu, 2018-07-26 at 10:33 -0400, Robert Moskowitz wrote:

On 07/26/2018 10:19 AM, Tomas Mraz wrote:

On Thu, 2018-07-26 at 10:10 -0400, Robert Moskowitz wrote:

On 07/26/2018 10:07 AM, Viktor Dukhovni wrote:

On Jul 26, 2018, at 9:01 AM, Robert Moskowitz  wrote:

My Fedora 28 shipped with:

OpenSSL 1.1.0h-fips  27 Mar 2018

Does that have ED25519 support?

No.  You'd need 1.1.1 for that, it is currently in beta.


No wonder Dr. Google failed me.  I will have to see what I can
do.
Perhaps put together a Rawhide system then try for a build.  But
that
takes for a time commitment.


Please note that there is now openssl-1.1.1-pre8 in Rawhide since
yesterday. Hopefully the TLS-1.3 is final before Fedora 29 final
release so we will not ship an openssl prerelease in it.


Does this include the armv7hl image?  If so, it is not a stretch for
me
to build an image on one of my test Cubieboards.

Fedora does builds for armv7hl. However I do not see any sufficiently
fresh Rawhide image that would contain this build.



With:  Fedora-Xfce-armhfp-Rawhide-20180726.n.2-sda.raw.xz

# openssl version
OpenSSL 1.1.1-pre8 (beta) FIPS 20 Jun 2018

So now let's see how making an ED25519 PKI works.


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] EDDSA support yet?

[Robert Moskowitz]

On 07/26/2018 11:59 AM, Tomas Mraz wrote:

On Thu, 2018-07-26 at 10:33 -0400, Robert Moskowitz wrote:

On 07/26/2018 10:19 AM, Tomas Mraz wrote:

On Thu, 2018-07-26 at 10:10 -0400, Robert Moskowitz wrote:

On 07/26/2018 10:07 AM, Viktor Dukhovni wrote:

On Jul 26, 2018, at 9:01 AM, Robert Moskowitz  wrote:

My Fedora 28 shipped with:

OpenSSL 1.1.0h-fips  27 Mar 2018

Does that have ED25519 support?

No.  You'd need 1.1.1 for that, it is currently in beta.


No wonder Dr. Google failed me.  I will have to see what I can
do.
Perhaps put together a Rawhide system then try for a build.  But
that
takes for a time commitment.


Please note that there is now openssl-1.1.1-pre8 in Rawhide since
yesterday. Hopefully the TLS-1.3 is final before Fedora 29 final
release so we will not ship an openssl prerelease in it.


Does this include the armv7hl image?  If so, it is not a stretch for
me
to build an image on one of my test Cubieboards.

Fedora does builds for armv7hl. However I do not see any sufficiently
fresh Rawhide image that would contain this build.


From the Fedora-arm list:

openssl-1.1.1-0.pre8.fc29 was built and tagged into f29 late yesterday
so it will be in the next successful compose which might be tomorrow
(there's been a few issues), look for the next rawhide report to the
mailing list, else you can just "dnf upgrade" your current f29 image
and you'll get it once it makes the mirrors.


So if is off to power up a cubieboard and get ready to build an image 
for testing.





--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] EDDSA support yet?

[Robert Moskowitz]

On 07/26/2018 10:19 AM, Tomas Mraz wrote:

On Thu, 2018-07-26 at 10:10 -0400, Robert Moskowitz wrote:

On 07/26/2018 10:07 AM, Viktor Dukhovni wrote:

On Jul 26, 2018, at 9:01 AM, Robert Moskowitz  wrote:

My Fedora 28 shipped with:

OpenSSL 1.1.0h-fips  27 Mar 2018

Does that have ED25519 support?

No.  You'd need 1.1.1 for that, it is currently in beta.


No wonder Dr. Google failed me.  I will have to see what I can do.
Perhaps put together a Rawhide system then try for a build.  But
that
takes for a time commitment.


Please note that there is now openssl-1.1.1-pre8 in Rawhide since
yesterday. Hopefully the TLS-1.3 is final before Fedora 29 final
release so we will not ship an openssl prerelease in it.

Does this include the armv7hl image?  If so, it is not a stretch for me 
to build an image on one of my test Cubieboards.



--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] EDDSA support yet?

[Robert Moskowitz]

On 07/26/2018 10:07 AM, Viktor Dukhovni wrote:



On Jul 26, 2018, at 9:01 AM, Robert Moskowitz  wrote:

My Fedora 28 shipped with:

OpenSSL 1.1.0h-fips  27 Mar 2018

Does that have ED25519 support?

No.  You'd need 1.1.1 for that, it is currently in beta.

No wonder Dr. Google failed me.  I will have to see what I can do. 
Perhaps put together a Rawhide system then try for a build.  But that 
takes for a time commitment.


thanks


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] EDDSA support yet?

[Robert Moskowitz]

My Fedora 28 shipped with:

OpenSSL 1.1.0h-fips  27 Mar 2018

Does that have ED25519 support?

It takes real time to set up my full test environment, and I really 
don't have the time right now if I am going to have to see what is in 
store for Fedora 29...


Thanks

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Hardware client certificates moving to Centos 7

[Robert Moskowitz]

On 09/28/2017 01:25 PM, Stuart Marsden wrote:

Hi

thanks for all the comments and suggestions, especially the ones I 
could understand


centos 7
yum upgrade

openssl version gives:

OpenSSL 1.0.2k-fips  26 Jan 2017


it looks like

echo 'LegacySigningMDs md5' >> /etc/pki/tls/legacy-settings

allows the reading of Md5 Client certificates (which are still being 
installed in "not released yet" phones)


I am almost concerned this is being done intentionally to meet some 
security downgrade requirement.  I the more reason to only use this cert 
to bootstrap your own cert for the actual management.





That is a week of my life I wont get back

thanks again

Stuart


On 27 Sep 2017, at 19:02, Michael Wojcik 
> wrote:



From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
Of Jochen Bern
Sent: Wednesday, September 27, 2017 06:51
To: openssl-users@openssl.org 
Subject: Re: [openssl-users] Hardware client certificates moving to 
Centos 7


I don't know offhand which OpenSSL versions did away with MD5, but you
*can* install an 0.9.8e (+ RHEL/CentOS backported security patches)
straight off CentOS 7 repos:


Ugh. No need for 0.9.8e (which is from, what, the early Industrial 
Revolution?). MD5 is still available in OpenSSL 1.0.2, assuming it 
wasn't disabled in the build configuration. I think Stuart is dealing 
with an OpenSSL build that had MD5 disabled in the Configure step.


Heck, MD4 and MDC2 are still available in 1.0.2 - even with the 
default configuration, I believe. I'm looking at 1.0.2j here and it 
has GOST, MD4, MD5, MDC2, RIPEMD-60, SHA, SHA1, SHA-2 (all standard 
lengths), and Whirlpool.


That's just for digests, obviously; but the point is the MD5 support 
is still there. And yes, 1.0.2j can handle certificates with 
md5WithRsaEncryption signatures.


--
Michael Wojcik
Distinguished Engineer, Micro Focus



--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users




Dr Stuart Marsden
*Tel:* +44 (0)1494 414100
*Email:* stu...@myphones.com 

Altos Banner





-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Hardware client certificates moving to Centos 7

[Robert Moskowitz]

On 09/27/2017 08:07 AM, Stuart Marsden wrote:

Hi

I think I know what you are going to say - MD5?


Lots of problems with that cert.  If you have some connection with the 
vendor, have them read IEEE 802.1AR-2009 standard for Device Identity 
credentials.  You will be supporting this phone different from those 
that follow the standard.




I ran openssl s_server -verify , then ran the x509 command as you 
suggested using the captured client certificate


This phone model has only just gone into production,  and I am using a 
"preview version" of the hardware


Is there a way a can install  a version of openssl on a dedicated 
standalone Centos 7 server which will support these phones?


I run Centos7 on arm platforms  There are lots of ways to run dedicated 
C7 servers.  Talk about this on the Centos-user or Centos-arm list.




That would be preferable to me than having to leave Centos 6 servers 
just for this


A lot of years until EOL for Centos6.  They just did it for C5...



Thanks everyone for your help sofar

Stuart


openssl x509 -noout -text -in yealink.pem
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
30:30:31:35:36:35:63:38:62:65:36:66
Signature Algorithm: md5WithRSAEncryption
Issuer: C=CN, ST=Fujian, L=Xiamen, O=Yealink Network 
Technology Co.,Ltd., OU=yealink.com , CN=Yealink 
Equipment Issuing CA/emailAddress=supp...@yealink.com 


Validity
Not Before: Mar 1 00:00:00 2014 GMT
Not After : Feb 24 00:00:00 2034 GMT
Subject: C=CN, ST=Fujian, L=Xiamen, O=Yealink Network 
Technology Co.,Ltd., OU=Yealink Equipment, 
CN=001565c8be6f/emailAddress=supp...@yealink.com 


Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (1024 bit)
Modulus:
00:e9:22:52:1a:47:bf:06:4d:2e:86:4f:61:5e:f8:
70:47:7f:c7:7d:4d:1e:b7:9f:0d:38:d2:79:8e:e9:
47:88:f3:f1:dd:75:d0:b3:d7:72:da:aa:e8:72:12:
7e:67:5c:c1:63:f3:6e:54:48:f7:46:a8:1c:fe:6a:
96:13:87:31:68:bb:89:98:b5:45:8d:c2:ef:24:a0:
47:7c:bf:20:d6:88:6b:95:4b:3a:f4:90:ec:a1:b2:
8a:4e:f9:2a:01:02:ba:f9:7f:52:b7:5f:71:18:d4:
40:74:56:75:94:e1:2e:ed:87:69:5a:33:ca:51:45:
06:ce:5e:5d:f1:ff:c1:5f:2f
Exponent: 65537 (0x10001)
Signature Algorithm: md5WithRSAEncryption
74:a9:f7:02:52:51:86:c9:09:15:c9:2e:32:1b:29:81:b6:d0:
a9:7a:88:61:5a:fe:22:3e:6d:68:e3:71:64:e2:12:1f:5a:0e:
35:54:19:b8:4a:e5:a1:70:27:0f:3b:99:ae:db:d1:bc:77:39:
22:0a:4d:71:a9:08:ca:c4:e0:28:a6:a0:e4:bc:9d:56:c1:ad:
49:4b:5c:70:b2:a7:e8:64:ef:fa:fa:c0:1c:89:92:63:c5:67:
55:ab:d9:65:57:4b:a8:6e:59:a6:d3:4b:ff:9b:27:8b:0e:ea:
ac:71:de:6c:5d:97:c7:78:17:40:4b:03:79:81:1b:02:31:6c:
fa:01:4a:c2:e2:c2:d6:14:4c:ff:9a:1c:41:ed:14:c2:eb:b4:
f5:1b:db:06:d7:1f:e3:bc:69:d0:f7:d6:8e:13:db:7b:f1:15:
5c:11:b9:18:56:6b:d3:0f:96:20:99:a3:19:01:83:9a:f2:65:
4d:7d:6b:41:92:d2:d1:4d:40:74:b7:8b:a8:54:ba:bf:b0:04:
0e:a0:45:5b:62:c1:0e:7b:48:7d:c8:96:62:99:50:e7:44:b1:
8a:01:e0:ec:b7:42:6c:3d:52:16:70:3b:0f:e6:e3:31:8b:31:
ee:62:fd:fd:3c:94:90:04:05:99:7b:b2:c0:41:8f:92:05:db:
46:a6:2d:ed:ba:e5:70:61:45:52:a4:f0:97:54:cf:75:9d:8b:
f9:89:f2:01:0e:7f:f7:b6:1f:1c:03:56:a6:cc:d0:00:99:b9:
f1:e3:6b:18:d5:69:46:38:a3:23:ba:f3:76:08:ff:02:bc:15:
df:91:67:6e:94:62:35:34:a2:fa:d3:33:01:da:00:b6:07:4c:
89:7e:f3:98:dc:81:e5:0f:4a:19:ea:fe:91:02:3a:9d:22:25:
a9:38:f8:2f:91:ca:09:e1:6c:12:b2:68:a6:a2:af:8b:41:f7:
61:e5:40:2f:98:60:18:10:90:af:55:50:8a:31:2d:17:82:d2:
13:cf:27:5b:fa:c8:ee:74:e1:98:00:26:56:24:68:38:b4:e3:
21:ee:3c:8b:16:32:72:93:fc:3b:0f:13:9a:b1:97:e8:6e:ca:
33:00:ee:7b:30:7c:e2:e7:14:99:a0:5f:f1:f9:95:1f:fc:5c:
17:79:33:2a:f1:fd:89:6e:50:d8:d7:8d:05:95:3f:11:72:c7:
69:e8:0f:4c:82:7b:9d:26:86:04:60:b2:3b:24:76:4a:34:c6:
87:ef:e6:e7:8b:53:98:de:f4:cc:d8:39:b2:2d:ea:09:a4:80:
f3:c2:d7:bd:6f:7b:7d:4c:35:b2:23:ca:56:fc:5b:6d:08:05:
6b:11:bd:c6:4b:92:4f:46


On 27 Sep 2017, at 01:04, Kyle Hamilton > wrote:


openssl x509 -noout -text -in clientcertificate.pem

You may need to extract the client certificate from wireshark, but you
could also get it from openssl s_server.

Specifically, that error message is suggesting that there's a message
digest encoded into the certificate which is unknown to the trust
path.

Chances are, it's probably MD5.  MD5 was broken a long time ago, and
is no longer trustworthy.  (SHA1 is also a possibility, but it was
made unacceptable a lot more recently.)

-Kyle H


On Tue, Sep 26, 2017 at 8:56 AM, Stuart Marsden > wrote:

Sorry how can I tell ?

I can run a wireshark if necessary

thanks


On 26 Sep 2017, at 16:36, Wouter Verhelst 
> wrote:


On 26-09-17 17:26, Stuart Marsden wrote:
[ssl:info] [pid 1611] SSL Library Error: error:0D0C50A1:asn1 
encoding 

Re: [openssl-users] Hardware client certificates moving to Centos 7

[Robert Moskowitz]

On 09/26/2017 08:04 PM, Kyle Hamilton wrote:

openssl x509 -noout -text -in clientcertificate.pem

You may need to extract the client certificate from wireshark, but you
could also get it from openssl s_server.

Specifically, that error message is suggesting that there's a message
digest encoded into the certificate which is unknown to the trust
path.

Chances are, it's probably MD5.  MD5 was broken a long time ago, and
is no longer trustworthy.  (SHA1 is also a possibility, but it was
made unacceptable a lot more recently.)


If it IS a 802.1AR RSA cert (the original drivers for 802.1AR was 
protecting VoIP phones), 802.1AR-2009 says:


6.3.5.1 RSA Signing

If the key is an RSA key, then this operation shall generate a PKCS1 
signature as defined in RFC 3447 with

the signature algorithm of RSASSA-PKCS1-v1_5, for maximum interoperability.

The currentEncoding specifies the current encoding of the data. The 
dataOctets are partially encoded for
RFC 3447 signing prior to calling this DevID module interface. A value 
of PKCS1HASH_SHA256
indicates that the dataOctets are a SHA256 hash of the original data as 
specified by RFC 3447 id-sha256.
The DevID Module will continue encoding the data, starting at RFC 3447 
Section 9.2 step 2, by building
and padding the DigestInfo ASN.1 value and then building the full PKCS1 
signature.


A currentEncoding value of PKCS1DIGESTINFO_OPAQUE indicates that the 
dataOctets are already
encoded into the equivalent of the RFC 3447 Section 9.2 step 2 specified 
DigestInfo. The DevID Module
will continue encoding the data, starting at RFC 3447 Section 9.2 step 
3, by padding the dataOctet as
specified for the DigestInfo ASN.1 value, and then building the full 
PKCS1 signature.


NOTE—Some uses of PKCS1 specify an alternative to the RFC 3447 
DigestInfo structure. For example TLS 1.1 RFC4346 specifies “a 36-byte 
structure of two hashes (one SHA and one MD5).” The use of
PKCS1DIGESTINFO_OPAQUE provides support for this type of construct. It 
also provides a mechanism for
components leveraging the DeviceID Module to obtain PCKS1 signatures 
using legacy hash algorithms such as SHA-1 or MD5.



And:

7.3.1 RSASSA-PKCS1-v1.5

The RSASSA-PKCS1-v1.5 signature method is defined in RFC 3447. The 
algorithm shall be either
sha1WithRSAEncryption or sha256WithRSAEncryption. The algorithm 
identifiers are:


sha1WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2)us(840)
rsadsi(113549) pkcs(1) pkcs-1(1) 5 }

sha256WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2)us(840)
rsadsi(113549) pkcs(1) pkcs-1(1) 11 }

Support for sha1WithRSAEncryption is included for maximum 
interoperability but is not recommended.
When the sha1WithRSAEncryption or sha256WithRSAEncryption algorithm 
identifiers appear in the
algorithm field as an AlgorithmIdentifier, the encoding must omit the 
parameters field. That is, the
AlgorithmIdentifier shall be a SEQUENCE of one component, the object 
identifier

sha1WithRSAEncryption or sha256WithRSAEncryption.




-Kyle H


On Tue, Sep 26, 2017 at 8:56 AM, Stuart Marsden  wrote:

Sorry how can I tell ?

I can run a wireshark if necessary

thanks



On 26 Sep 2017, at 16:36, Wouter Verhelst  wrote:

On 26-09-17 17:26, Stuart Marsden wrote:

[ssl:info] [pid 1611] SSL Library Error: error:0D0C50A1:asn1 encoding 
routines:ASN1_item_verify:unknown message digest algorithm

So which message digest algorithm is the client trying to use?

--
Wouter Verhelst
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users



--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Hardware client certificates moving to Centos 7

[Robert Moskowitz]

On 09/26/2017 11:26 AM, Stuart Marsden wrote:

Hi

I have Centos/Apache servers for securely provisioning IP phones using hardware 
client certificates embedded in the phones.

for this test I have allowed all protocols and ciphers

on Centos 6 this works fine, the rpms are:

openssl098e-0.9.8e-20.el6.centos.1.x86_64
openssl-1.0.1e-57.el6.x86_64
openssl-devel-1.0.1e-57.el6.x86_64

on centos 7 the rpms are:

openssl098e-0.9.8e-29.el7.centos.3.x86_64
openssl-1.0.2k-8.el7.x86_64
openssl-libs-1.0.2k-8.el7.x86_64
xmlsec1-openssl-1.2.20-7.el7_4.x86_64
openssl-devel-1.0.2k-8.el7.x86_64

on Centos 7 the logging with "Loglevel debug"  in the apache config file is a 
lot less than Centos 6


The SSL fails to establish with the error below:


ssl_engine_kernel.c(1890): [client XX.XX.31.200:47576] AH02043: SSL virtual 
host for servername  found

ssl_engine_kernel.c(1360): [client XX.XX.31.200:47576] AH02275: Certificate 
Verification, depth 1, CRL checking mode: none [subject: 
emailAddress=supp...@yealink.com,CN=Yealink Equipment Issuing 
CA,OU=yealink.com,O=Yealink Network Technology 
Co.\\,Ltd.,L=Xiamen,ST=Fujian,C=CN / issuer: 
emailAddress=supp...@yealink.com,CN=Yealink Equipment Issuing 
CA,OU=yealink.com,O=Yealink Network Technology 
Co.\\,Ltd.,L=Xiamen,ST=Fujian,C=CN / serial: E17F3D266C47321E / notbefore: Nov  
7 12:45:52 2013 GMT / notafter: Nov  7 12:45:52 2033 GMT]


Please provide a complete dump of the hardware certificate.  There may 
be a subjectAltName with fields that require an hex dump.  I want to see 
if these are IEEE 802.1AR certificates...


If they are, they are suppose to be used to provision an owner (lDevID) 
certificate.  But they should be usable; they may be ECDSA certs.


You can see some examples on how to create (and display) ECDSA 802.1AR 
certs in:


https://datatracker.ietf.org/doc/draft-moskowitz-ecdsa-pki/




ssl_engine_kernel.c(1360): [client xx.xx.31.200:47576] AH02275: Certificate 
Verification, depth 0, CRL checking mode: none [subject: 
emailAddress=supp...@yealink.com,CN=001565c8be6f,OU=Yealink Equipment,O=Yealink 
Network Technology Co.\\,Ltd.,L=Xiamen,ST=Fujian,C=CN / issuer: 
emailAddress=supp...@yealink.com,CN=Yealink Equipment Issuing 
CA,OU=yealink.com,O=Yealink Network Technology 
Co.\\,Ltd.,L=Xiamen,ST=Fujian,C=CN / serial: 303031353635633862653666 / 
notbefore: Mar  1 00:00:00 2014 GMT / notafter: Feb 24 00:00:00 2034 GMT]

[ssl:info] [pid 1611] [client xx.xx.31.200:47576] AH02276: Certificate 
Verification: Error (7): certificate signature failure [subject: 
emailAddress=supp...@yealink.com,CN=001565c8be6f,OU=Yealink Equipment,O=Yealink 
Network Technology Co.\\,Ltd.,L=Xiamen,ST=Fujian,C=CN / issuer: 
emailAddress=supp...@yealink.com,CN=Yealink Equipment Issuing 
CA,OU=yealink.com,O=Yealink Network Technology 
Co.\\,Ltd.,L=Xiamen,ST=Fujian,C=CN / serial: 303031353635633862653666 / 
notbefore: Mar  1 00:00:00 2014 GMT / notafter: Feb 24 00:00:00 2034 GMT]

[ssl:info] [pid 1611] [client xx.xx.31.200:47576] AH02008: SSL library error 1 
in handshake (server xxx.xxx.xxx.xxx:443)
[ssl:info] [pid 1611] SSL Library Error: error:0D0C50A1:asn1 encoding 
routines:ASN1_item_verify:unknown message digest algorithm
[ssl:info] [pid 1611] SSL Library Error: error:14089086:SSL 
routines:ssl3_get_client_certificate:certificate verify failed
[ssl:info] [pid 1611] [client xx.xx.31.200:47576] AH01998: Connection closed to 
child 3 with abortive shutdown


It fails across several phone vendors.

Any suggestions greatly received, thanks in advance

Stuart




--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] reading DER format public keys

[Robert Moskowitz]

On 09/15/2017 11:57 AM, Michael Richardson wrote:

The PEM_* routines, as documented at:
 https://www.openssl.org/docs/man1.0.2/crypto/PEM_read_bio_PUBKEY.html
do not claim to read DER format input. (Actually they don't say anything about 
DER).
Ruby's library uses:
 pkey = PEM_read_bio_PUBKEY(bio, NULL, ossl_pem_passwd_cb, (void *)pass);

It's documentation claims it read DER, which either it's wrong, or the
underlying ruby extension or SSL code has changed.

There must be a way to read DER format public keys.
I'm suspecting that maybe the magic is in the way the BIO is created?
(FAQ question PROG03, hints this for PKCS7 processing).


I had problems with DER using the command line options.  I can create, 
and display a DER keypair, a CSR, a self-signed cert.  I cannot use a 
CSR to make a cert where everything is DER.  So something is missing 
somewhere.  If you search back a bit, you will find my postings on this 
with the error messages I got.



Going to read the source code.


You are better man than I...

Bob

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Doubt regarding O-SSL and setting the duration of certificates

[Robert Moskowitz]

On 09/13/2017 09:31 AM, Michael Richardson wrote:

Robert Moskowitz <r...@htt-consult.com> wrote:
 > The devices never test out the lifetime of their certs. That is up to

Exactly...
(Do you think about the MacGyver/StarTrek/A-Team/Leverage/MissionImpossible
plot line that goes along with each engineering decision?...)


Never was into watching TV.  Maybe saw half a dozen MI and maybe 4 - 5 
StarTrek, so I really can't answer this...  :)



 > validating servers. And the iDevID is not really intended for operational
 > use. Rather it is the security bootstrap for the lDevID. See the work 
being
 > done in the ANIMA workgroup as an example of what to do with this. 
Michael
 > Richardson, who recently joined this list is working on the related 
Internet
 > Draft(s).

 > I should test out a cert beyond 2038 on my armv7 32 bit Cubieboard. Will 
try
 > that tomorrow

 > I HAVE made certs with this value and I am displaying their content. But 
that
 > system is off right now. I will get one of the samples also tomorrow.

 > And yes, the industry does need to think some about this...

I suspect that the value: literal value 1231235959Z will simply come to
mean "the end of time", even after the year 10,000.  It has a well known
DER encoding, and one can memcmp() it.
Perhaps we will define an OID which means "no expiry", and start including
that.  I don't think the expiry date is an optional part.


Nice thought.  Not really an option.


I will also have example vouchers, voucher requests and ECDSA ("prime256v1")
certs with known private keys (so you can replicate my work) for the ANIMA
BRSKI document, perhaps next week.


Do we agree on the DN and SAN content per 802.1AR?  I am not entirely 
confident with my reading of what I contributed to!  Well at that time I 
left the cert profile to others.  I can send you a whole pki tree zipped 
up.  Do you have any 'live' specimens?




I'd rather publish Curve25519/EdDSA examples, but it's too bleeding edge for 
the moment.


We wait until 1.1.1 ships.  But MAYBE we should be doing builds and 
testing now instead of after it ships...



--
]   Never tell me the odds! | ipv6 mesh networks [


Odds are it won't make a difference.

Bob

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Doubt regarding O-SSL and setting the duration of certificates

[Robert Moskowitz]

On 09/13/2017 09:39 AM, Salz, Rich via openssl-users wrote:

An X509v3 certificate has “notBefore” and “notAfter” fields.  If either of 
those is not present, then it is not an X509v3 certificate.  The time marked by 
those fields is the validity period.

If you want “never expires” X509v3 certificates, the best you can do it put a 
very large value in the notAfter field.  Some software may have issues around 
32bit representation of classic Unix time_t and therefore have problems with 
times greater than 2038; OpenSSL does not have those problems.

The OpenSSL command-line tools do not handle every possible corner case, 
including the ability to reasonably set dates that more than 7,500 years in the 
future.  You will have to modify the source.


It handles notAfter past 2038 (25*365 days from today):

   openssl req -config $dir/openssl-root.cnf\
-set_serial 0x$(openssl rand -hex $sn)\
-keyform $format -outform $format\
-key $dir/private/ca.key.$format -subj "$DN"\
-new -x509 -days 9125 -sha256 -extensions v3_ca\
-out $dir/certs/ca.cert.$format

   openssl x509 -inform $format -in $dir/certs/ca.cert.$format\
-text -noout

...
Validity
Not Before: Sep 13 17:09:50 2017 GMT
Not After : Sep  7 17:09:50 2042 GMT
...

I create 802.1AR cert with:

default_enddate   = 1231235959Z # per IEEE 802.1AR

in the config:

...
Validity
Not Before: Sep  7 04:43:27 2017 GMT
Not After : Dec 31 23:59:59  GMT
...


So it seems you can create things like signing certs with enddates out 
beyond 2038 and you can create EE certs with 'end of time' enddates.


The rest is up to the software that uses these certs...

Bob

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Doubt regarding O-SSL and setting the duration of certificates

[Robert Moskowitz]

The devices never test out the lifetime of their certs.  That is up to 
the validating servers.  And the iDevID is not really intended for 
operational use.  Rather it is the security bootstrap for the lDevID.  
See the work being done in the ANIMA workgroup as an example of what to 
do with this.  Michael Richardson, who recently joined this list is 
working on the related Internet Draft(s).


I should test out a cert beyond 2038 on my armv7 32 bit Cubieboard. Will 
try that tomorrow


I HAVE made certs with this value and I am displaying their content.  
But that system is off right now.  I will get one of the samples also 
tomorrow.


And yes, the industry does need to think some about this...

On 09/12/2017 06:51 PM, Frank Migge wrote:

This is an interesting statement.

>> should use the GeneralizedTime value 1231235959Z (10) in the 
notAfter field ...
>> Solutions verifying a DevID are expected to accept this value 
indefinitely


Isn't using that large a time value in certificates problematic? Not 
all systems can handle it today. At best, they may gracefully decline 
it as invalid. Windows up to version 10 is unable to display it, and 
fails to work with such a cert.


Even closer into the future, 20 years from now, I am not sure how far 
the industry came in dealing with the upcoming year 2038 problem on 
32bit systems. It is indirectly related to OpenSSL when system time is 
used, converted to or from. Particularly in IOT/ICS industry 
situations with scaled down CPUs, long device lifespans and support 
requirements, functional validation with future time settings would 
definitely be a good idea on the test plan.


Frank

Robert Moskowitz <mailto:r...@htt-consult.com>
Wednesday, September 13, 2017 12:57 AM
IEEE 802.1ARce (latest draft addendum) specifies:

8.7 validity

The time period over which the DevID issuer expects the device to be 
used.


All times are stated in the Universal Coordinated Time (UTC) time 
zone. Times up to and including
23:59:59 December 31, 2049 UTC are encoded as UTCTime as 
YYMMDDHHmmssZ. Times later than
23:59:59 December 31, 2049 UTC are encoded as GeneralizedTime as 
MMDDHHmmssZ.


The time the DevID is created is encoded in the notBefore field of 
DevID certificates. Each DevID chain
certificate has a notBefore value that encodes a time that is the 
same as or prior to that of any DevID

certificate that relies on the chain for certificate validation.

The latest time a DevID is expected to be used is encoded in the 
notAfter field of the DevID certificate.
Each DevID chain certificate has a notBefore value that encodes a 
time that is the same as or later than that of any DevID certificate 
that relies on the chain for certificate validation.


Devices possessing an IDevID are expected to operate indefinitely 
into the future and should use the
GeneralizedTime value 1231235959Z (10) in the notAfter field of 
IDevID certificates. Solutions
verifying a DevID are expected to accept this value indefinitely. 
Values in notAfter fields are treated as

specified in RFC 5280.

Footnote: (10)
This value corresponds to one second before the year 10 000; note the 
creation of an opportunity for the Y10K bug fix industry.


=

It is really rare to find humor in IEEE specifications!

Bob

On 09/12/2017 11:39 AM, Alejandro Pulido wrote:

Robert Moskowitz <mailto:r...@htt-consult.com>
Tuesday, September 12, 2017 11:30 PM
Depends on the question

'Infinite' duration is used in IEEE 802.1AR Device Identities.  The 
concept is the vendor installs the certificate in read-only memory.  
It is expected to be good for the life of the device.


On 09/11/2017 05:32 AM, Alejandro Pulido wrote:

Alejandro Pulido <mailto:alexxp...@hotmail.com>
Monday, September 11, 2017 6:32 PM
Dear team of OpenSSL,
First of all, congratulations for your invaluable work!
I have a question regarding the issue of certificates X.509 with 
infinite duration and I don't know where to submit it.

Please, could you help me?
Thank you very much and kind regards



*/Alejandro J Pulido Duque/*





-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Doubt regarding O-SSL and setting the duration of certificates

[Robert Moskowitz]

IEEE 802.1ARce (latest draft addendum) specifies:

8.7 validity

The time period over which the DevID issuer expects the device to be used.

All times are stated in the Universal Coordinated Time (UTC) time zone. 
Times up to and including
23:59:59 December 31, 2049 UTC are encoded as UTCTime as YYMMDDHHmmssZ. 
Times later than
23:59:59 December 31, 2049 UTC are encoded as GeneralizedTime as 
MMDDHHmmssZ.


The time the DevID is created is encoded in the notBefore field of DevID 
certificates. Each DevID chain
certificate has a notBefore value that encodes a time that is the same 
as or prior to that of any DevID

certificate that relies on the chain for certificate validation.

The latest time a DevID is expected to be used is encoded in the 
notAfter field of the DevID certificate.
Each DevID chain certificate has a notBefore value that encodes a time 
that is the same as or later than that of any DevID certificate that 
relies on the chain for certificate validation.


Devices possessing an IDevID are expected to operate indefinitely into 
the future and should use the
GeneralizedTime value 1231235959Z (10) in the notAfter field of 
IDevID certificates. Solutions
verifying a DevID are expected to accept this value indefinitely. Values 
in notAfter fields are treated as

specified in RFC 5280.

Footnote: (10)
This value corresponds to one second before the year 10 000; note the 
creation of an opportunity for the Y10K bug fix industry.


=

It is really rare to find humor in IEEE specifications!

Bob

On 09/12/2017 11:39 AM, Alejandro Pulido wrote:


Hello!


Thanks for the response.

I was thinking of setting the duration fo the certificate to infinite,

i.e. the Validity period set to infinite.

Because in the information I have, the only possibility is to set the 
duration (in days) with the command, but the command doesn't allow to 
put other value rather an integer.



Thanks again



*/Alejandro J Pulido Duque/*

*De:* Robert Moskowitz <r...@htt-consult.com>
*Enviado:* martes, 12 de septiembre de 2017 14:30:20
*Para:* openssl-users@openssl.org; Alejandro Pulido
*Asunto:* Re: [openssl-users] Doubt regarding O-SSL and setting the 
duration of certificates

Depends on the question

'Infinite' duration is used in IEEE 802.1AR Device Identities. The 
concept is the vendor installs the certificate in read-only memory.  
It is expected to be good for the life of the device.


On 09/11/2017 05:32 AM, Alejandro Pulido wrote:

Dear team of OpenSSL,
First of all, congratulations for your invaluable work!
I have a question regarding the issue of certificates X.509 with 
infinite duration and I don't know where to submit it.

Please, could you help me?
Thank you very much and kind regards



*/Alejandro J Pulido Duque/*






-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Doubt regarding O-SSL and setting the duration of certificates

[Robert Moskowitz]

Depends on the question

'Infinite' duration is used in IEEE 802.1AR Device Identities.  The 
concept is the vendor installs the certificate in read-only memory. It 
is expected to be good for the life of the device.


On 09/11/2017 05:32 AM, Alejandro Pulido wrote:

Dear team of OpenSSL,
First of all, congratulations for your invaluable work!
I have a question regarding the issue of certificates X.509 with 
infinite duration and I don't know where to submit it.

Please, could you help me?
Thank you very much and kind regards



*/Alejandro J Pulido Duque/*




-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Why is this OCSP response reporting a hash using SHA1?

[Robert Moskowitz]

On 09/12/2017 09:38 AM, Robert Moskowitz wrote:



On 09/12/2017 09:09 AM, Dr. Stephen Henson wrote:

On Mon, Sep 11, 2017, Robert Moskowitz wrote:


I would actually really like to have a SIMPLE OCSP responder.  But
so far have not found one.  freeIPA has one buried within it, but
that is too disruptive to install unless you buy into freeIPA.

Well the OpenSSL ocsp respoder isn't much use for that, it only 
handles one
request at a time, can't handle dynamic updates in the status 
information
(needs to be restarted), has pretty awful performance (reads status 
from a
text file which resides in memory) and you can't tell it which 
interface to

bind to either.

There is a way to deal with some of those issues by running the ocsp 
utility
from a CGI script in a web server. The script decodes the OCSP 
request, hands

it to the ocsp utility and sends back the response. The down side is the
performance is worse: the OCSP utility has to parse the text file and 
read it

into memory on every incoming request.


Yeah, I thought of the cgi (or php) approach and kind of cringed. That 
is why I am still googling for OCSP responders.  Rather depressing how 
little is out there.
I see ocspd available in Fedora.  I will have to do a bit of 
reading  Perhaps part of OpenCA,,,


Sometimes start in the 'obvious' starting point.  Like your own OS repo...




Also nice would be index.txt in SQL.

Bob



--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Why is this OCSP response reporting a hash using SHA1?

[Robert Moskowitz]

On 09/12/2017 09:09 AM, Dr. Stephen Henson wrote:

On Mon, Sep 11, 2017, Robert Moskowitz wrote:


I would actually really like to have a SIMPLE OCSP responder.  But
so far have not found one.  freeIPA has one buried within it, but
that is too disruptive to install unless you buy into freeIPA.


Well the OpenSSL ocsp respoder isn't much use for that, it only handles one
request at a time, can't handle dynamic updates in the status information
(needs to be restarted), has pretty awful performance (reads status from a
text file which resides in memory) and you can't tell it which interface to
bind to either.

There is a way to deal with some of those issues by running the ocsp utility
from a CGI script in a web server. The script decodes the OCSP request, hands
it to the ocsp utility and sends back the response. The down side is the
performance is worse: the OCSP utility has to parse the text file and read it
into memory on every incoming request.


Yeah, I thought of the cgi (or php) approach and kind of cringed. That 
is why I am still googling for OCSP responders.  Rather depressing how 
little is out there.


Also nice would be index.txt in SQL.

Bob

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Why is this OCSP response reporting a hash using SHA1?

[Robert Moskowitz]

On 09/11/2017 12:23 PM, Salz, Rich via openssl-users wrote:
 
 Ah,  put -sha256 in the CLIENT request.  Seems kind of backward.  Or at

 least the server should have some control over the hash used?
 


Well, it is the client that is making the request, so therefore the client 
needs to hash the cert information.


Ah, I see.  I was looking at this from the wrong side.


A production-quality OCSP responder might have configuration controls to 
specify which type of digests it wants to see in the request.  As with most of 
the OpenSSL command-line interface, it’s not a product.


Understood.  This is mostly about providing a development/testing 
environment.  And if your standard calls out use of OCSP, then you 
really should include that in testing.  I am getting ready to focus on 
the IETF SIngapore hackathon...


I would actually really like to have a SIMPLE OCSP responder.  But so 
far have not found one.  freeIPA has one buried within it, but that is 
too disruptive to install unless you buy into freeIPA.


thanks

Bob

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Why is this OCSP response reporting a hash using SHA1?

[Robert Moskowitz]

On 09/08/2017 10:08 PM, Dr. Stephen Henson wrote:

On Fri, Sep 08, 2017, Robert Moskowitz wrote:


I am using the test responder:

openssl ocsp -port 2560 -text -rmd sha256\
  -index index.txt \
  -CA certs/ca-chain.cert.pem \
  -rkey private/$ocspurl.key.pem \
  -rsigner certs/$ocspurl.cert.pem \
  -nrequest 1


What is the SHA1 hash report about?  It comes right after the line:
Certificate ID:

 Certificate ID:
   Hash Algorithm: sha1
   Issuer Name Hash: CA1F5832FA387F0127D8E0583F7331D1B903DBF0
   Issuer Key Hash: A3278D00B053BF259193A4833E669C451DAD36E0
   Serial Number: 762900CAB55A4762

It's the hash algorithm used to hash the issuer name and key to identify them.


And how do you get it to use sha256?

I would think that the -rmd sha256 in the responder command would that?  
What does it do anyway?  It is listed in the -help:


 -rmd valDigest Algorithm to use in signature of OCSP 
response


but not in the man page.

Ah,  put -sha256 in the CLIENT request.  Seems kind of backward.  Or at 
least the server should have some control over the hash used?


thanks

Bob

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] New version of draft-moskowitz-ecdsa-pki

[Robert Moskowitz]

I want to thank all for the help over the past few weeks.   Here is the 
latest version.  I know I have a few things to tune up.  Like why the 
SHA1 in the OCSP response.  I also want to put more justification in the 
beginning for people to use this (Standards writers, developers, 
testers).


But as often said, Internet Draft revision numbers are free and it is 
better to get things out stepwise then wait until everything is done.


Next big addition is IEEE 1609.2 cert support.

Bob




 Forwarded Message 
Subject:New Version Notification for draft-moskowitz-ecdsa-pki-01.txt
Date:   Fri, 08 Sep 2017 12:26:36 -0700
From:   internet-dra...@ietf.org
To: 	Robert Moskowitz <r...@labs.htt-consult.com>, Liang Xia 
<frank.xiali...@huawei.com>, Henk Birkholz 
<henk.birkh...@sit.fraunhofer.de>, Liang Xia <frank.xiali...@huawei.com>




A new version of I-D, draft-moskowitz-ecdsa-pki-01.txt
has been successfully submitted by Robert Moskowitz and posted to the
IETF repository.

Name:   draft-moskowitz-ecdsa-pki
Revision:   01
Title:  Guide for building an ECC pki
Document date:  2017-09-07
Group:  Individual Submission
Pages:  31
URL:
https://www.ietf.org/internet-drafts/draft-moskowitz-ecdsa-pki-01.txt
Status: https://datatracker.ietf.org/doc/draft-moskowitz-ecdsa-pki/
Htmlized:   https://tools.ietf.org/html/draft-moskowitz-ecdsa-pki-01
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-moskowitz-ecdsa-pki-01
Diff:   https://www.ietf.org/rfcdiff?url2=draft-moskowitz-ecdsa-pki-01

Abstract:
   This memo provides a guide for building a PKI (Public Key
   Infrastructure) using openSSL.  All certificates in this guide are
   ECDSA, P-256, with SHA256 certificates.  Along with common End Entity
   certificates, this guide provides instructions for creating IEEE
   802.1AR iDevID Secure Device certificates.

  



Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Why is this OCSP response reporting a hash using SHA1?

[Robert Moskowitz]

I am using the test responder:

   openssl ocsp -port 2560 -text -rmd sha256\
 -index index.txt \
 -CA certs/ca-chain.cert.pem \
 -rkey private/$ocspurl.key.pem \
 -rsigner certs/$ocspurl.cert.pem \
 -nrequest 1


What is the SHA1 hash report about?  It comes right after the line: 
Certificate ID:



openssl ocsp -CAfile certs/ca-chain.cert.pem \
  -url http://127.0.0.1:2560 -resp_text \
  -issuer certs/8021ARintermediate.cert.pem \
  -cert certs/$targetcert.cert.pem

OCSP Response Data:
OCSP Response Status: successful (0x0)
Response Type: Basic OCSP Response
Version: 1 (0x0)
Responder Id: O = HTT Consulting, OU = Devices
Produced At: Sep  8 16:11:38 2017 GMT
Responses:
Certificate ID:
  Hash Algorithm: sha1
  Issuer Name Hash: CA1F5832FA387F0127D8E0583F7331D1B903DBF0
  Issuer Key Hash: A3278D00B053BF259193A4833E669C451DAD36E0
  Serial Number: 762900CAB55A4762
Cert Status: revoked
Revocation Time: Sep  7 06:48:28 2017 GMT
This Update: Sep  8 16:11:38 2017 GMT

Response Extensions:
OCSP Nonce:
0410DBAEC40AE0C9696C715A8F476383D112
Signature Algorithm: ecdsa-with-SHA256
 30:46:02:21:00:a7:3e:9f:40:29:21:bc:1b:af:22:41:f7:5d:
 70:d8:3f:db:98:16:7c:62:b4:e9:cf:4c:1e:43:db:fa:07:42:
 f7:02:21:00:f6:05:82:c8:85:ef:dc:17:ec:0f:59:ce:5e:fd:
 36:8f:ac:5a:29:32:17:9d:22:c1:c2:77:e8:f7:7a:0c:ff:af
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
aa:56:78:7a:d5:f7:de:4f
Signature Algorithm: ecdsa-with-SHA256
Issuer: C=US, ST=MI, O=HTT Consulting, OU=Devices, CN=802.1AR CA
Validity
Not Before: Sep  7 06:40:11 2017 GMT
Not After : Dec 31 23:59:59  GMT
Subject: O=HTT Consulting, OU=Devices
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:d8:a1:6c:09:c0:13:fc:30:6f:02:1e:a0:d3:cc:
02:8c:b0:e1:2a:84:1d:94:ed:2e:92:b8:25:d0:00:
3d:a0:1a:43:dc:83:12:13:e0:74:a4:97:b7:4e:ed:
26:18:c0:36:38:a1:f8:c0:bb:d8:5c:14:cd:a7:23:
f5:71:51:bc:6c
ASN1 OID: prime256v1
NIST CURVE: P-256
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
X509v3 Subject Key Identifier:
57:34:03:80:50:53:9B:EA:2A:06:37:FF:8A:1E:32:72:70:DD:41:9F
X509v3 Authority Key Identifier:

keyid:A3:27:8D:00:B0:53:BF:25:91:93:A4:83:3E:66:9C:45:1D:AD:36:E0

X509v3 Key Usage: critical
Digital Signature
X509v3 Extended Key Usage: critical
OCSP Signing
X509v3 Subject Alternative Name:
DNS:ocsp.htt-consult.com, email:postmas...@htt-consult.com
Signature Algorithm: ecdsa-with-SHA256
 30:44:02:20:2b:99:ba:72:2a:e5:4c:1b:c1:9c:6a:72:f9:8e:
 8f:5f:97:ec:35:e0:19:f3:7f:58:c4:4b:67:fe:dc:47:68:45:
 02:20:37:07:0a:be:09:bd:20:b5:21:c5:23:80:4a:4d:57:47:
 56:4a:79:cc:6d:e0:57:5e:ef:bc:9b:eb:6d:3a:db:73
-BEGIN CERTIFICATE-
MIICMTCCAdigAwIBAgIJAKpWeHrV995PMAoGCCqGSM49BAMCMFoxCzAJBgNVBAYT
AlVTMQswCQYDVQQIDAJNSTEXMBUGA1UECgwOSFRUIENvbnN1bHRpbmcxEDAOBgNV
BAsMB0RldmljZXMxEzARBgNVBAMMCjgwMi4xQVIgQ0EwIBcNMTcwOTA3MDY0MDEx
WhgPOTk5OTEyMzEyMzU5NTlaMCsxFzAVBgNVBAoMDkhUVCBDb25zdWx0aW5nMRAw
DgYDVQQLDAdEZXZpY2VzMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE2KFsCcAT
/DBvAh6g08wCjLDhKoQdlO0ukrgl0AA9oBpD3IMSE+B0pJe3Tu0mGMA2OKH4wLvY
XBTNpyP1cVG8bKOBszCBsDAJBgNVHRMEAjAAMB0GA1UdDgQWBBRXNAOAUFOb6ioG
N/+KHjJycN1BnzAfBgNVHSMEGDAWgBSjJ40AsFO/JZGTpIM+ZpxFHa024DAOBgNV
HQ8BAf8EBAMCB4AwFgYDVR0lAQH/BAwwCgYIKwYBBQUHAwkwOwYDVR0RBDQwMoIU
b2NzcC5odHQtY29uc3VsdC5jb22BGnBvc3RtYXN0ZXJAaHR0LWNvbnN1bHQuY29t
MAoGCCqGSM49BAMCA0cAMEQCICuZunIq5UwbwZxqcvmOj1+X7DXgGfN/WMRLZ/7c
R2hFAiA3Bwq+Cb0gtSHFI4BKTVdHVkp5zG3gV17vvJvrbTrbcw==
-END CERTIFICATE-
Response verify OK
certs/Wt1234.cert.pem: revoked
This Update: Sep  8 16:11:38 2017 GMT
Revocation Time: Sep  7 06:48:28 2017 GMT


Thank you

Bob


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Problems with se...rver mode of openssl ocsp

[Robert Moskowitz]

On 09/07/2017 04:13 PM, Dr. Stephen Henson wrote:

On Thu, Sep 07, 2017, Robert Moskowitz wrote:


Good progress.  A few questions:

on 
https://jamielinux.com/docs/openssl-certificate-authority/online-certificate-status-protocol.html

The sample server test command is:

openssl ocsp -port 127.0.0.1:2560 -text -sha256 \
   -index intermediate/index.txt \
   -CA intermediate/certs/ca-chain.cert.pem \
   -rkey intermediate/private/ocsp.example.com.key.pem \
   -rsigner intermediate/certs/ocsp.example.com.cert.pem \
   -nrequest 1

Turns out this is a wrong format for -port.  Only the portnum is
allowed, not the host.  Turns out that

-port 2560

works as it seems to be listening on localhost.  But how DO you set
up which address to listen on?  -host seems to be only for client
mode, and I don't see how I would use -url.


There is currently no option to do that.


OK.  It does listen on localhost, so I'm OK with just -port 2560.  I 
will have to send Jamie a note...



The -sha256 option results in the error:

ocsp: Digest must be before -cert or -serial
ocsp: Use -help for summary.

I don't see either -cert or -serial in that command.  If I leave the
hash out, it defaults to sha1.  How do I specify the hash?


Do you mean the digest the response is signed with? Try the -rmd option if so.


No such option documented at:

https://www.openssl.org/docs/man1.1.0/apps/ocsp.html

but 'openssl ocsp -help' does list it.  I am assuming that I would use:

-rmd sha256

Be a bit to I get back to that part of the test

thanks

Bob

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Problems with server mode of openssl ocsp

[Robert Moskowitz]

Good progress.  A few questions:

on 
https://jamielinux.com/docs/openssl-certificate-authority/online-certificate-status-protocol.html


The sample server test command is:

openssl ocsp -port 127.0.0.1:2560 -text -sha256 \
  -index intermediate/index.txt \
  -CA intermediate/certs/ca-chain.cert.pem \
  -rkey intermediate/private/ocsp.example.com.key.pem \
  -rsigner intermediate/certs/ocsp.example.com.cert.pem \
  -nrequest 1

Turns out this is a wrong format for -port.  Only the portnum is 
allowed, not the host.  Turns out that


-port 2560

works as it seems to be listening on localhost.  But how DO you set up 
which address to listen on?  -host seems to be only for client mode, and 
I don't see how I would use -url.


The -sha256 option results in the error:

ocsp: Digest must be before -cert or -serial
ocsp: Use -help for summary.

I don't see either -cert or -serial in that command.  If I leave the 
hash out, it defaults to sha1.  How do I specify the hash?


thanks

Bob

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Env variables in config file to add a whole line

[Robert Moskowitz]

On 09/06/2017 01:31 PM, Salz, Rich via openssl-users wrote:

…

 $crlDP
 $ocspIAI
 


This is not supported.  You can only put variables in *values*


OK.  But now I have to work out  values.

Bob

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Env variables in config file to add a whole line

[Robert Moskowitz]

I got past the error to build the CSR by using:

crlDistributionPoints = $ENV::crlDP
authorityInfoAccess = $ENV::ocspIAI

Just $crlDP failed even though I had this defined in the [ca} section.

The CSR does not use the user_cert or server_cert.  This was 'just' a 
config file syntax issue.  When I try to make the cert I get the following:


crlDP=URI:http://www.htt-consult.com/pki/intermediate.crl.pem
default_crl_days=30
ocspIAI="OCSP;URI:http://ocsp.htt-consult.com;

   openssl ca -config $dir/openssl-intermediate.cnf -days 375\
   -extensions server_cert -notext -md sha256 \
   -in $dir/csr/$serverfqdn.csr.$format\
   -out $dir/certs/$serverfqdn.cert.$format

It works.   But if I DON'T want a CRL or OCSP support and I use:

crlDP=
ocspIAI=

with the same command I get:


Error Loading extension section server_cert
3069510608:error:0E06D06C:configuration file 
routines:NCONF_get_string:no 
value:crypto/conf/conf_lib.c:275:group=CA_default name=email_in_dn
3069510608:error:2206D06C:X509 V3 routines:X509V3_parse_list:invalid 
null name:crypto/x509v3/v3_utl.c:316:
3069510608:error:22097069:X509 V3 routines:do_ext_nconf:invalid 
extension 
string:crypto/x509v3/v3_conf.c:93:name=crlDistributionPoints,section=
3069510608:error:22098080:X509 V3 routines:X509V3_EXT_nconf:error in 
extension:crypto/x509v3/v3_conf.c:47:name=crlDistributionPoints, value=


So I need a way to have a 'null' value for NO CRL or NO OCSP.

I don't want to have to use SED to edit the config file based on what 
the goal is...


thanks

Bob




On 09/06/2017 12:23 PM, Robert Moskowitz wrote:
I am trying to use an environment variable to add a whole line to the 
config file.  This is to control adding (or not providing) CRL and/or 
OCSP support.


export shows:

declare -x crlDP="crlDistributionPoints = 
URI:http://www.htt-consult.com/pki/intermediate.crl.pem;

declare -x default_crl_days="default_crl_days  = 30"
declare -x ocspIAI="authorityInfoAccess = 
OCSP;URI:http://ocsp.htt-consult.com;


The config file starts with:


[ ca ]
# `man ca`
default_ca = CA_default

[ CA_default ]
# Directory and file locations.
dir= $ENV::dir
cadir = $ENV::cadir
format= $ENV::format
crlDP = $ENV::crlDP
default_crl_days  = $ENV::default_crl_days
ocspIAI  = $ENV::ocspIAI


The usr_cert section has:

[ usr_cert ]
# Extensions for client certificates (`man x509v3_config`).
basicConstraints = CA:FALSE
nsCertType = client, email
nsComment = "OpenSSL Generated Client Certificate"
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
keyUsage = critical,nonRepudiation,digitalSignature,keyEncipherment
extendedKeyUsage = clientAuth, emailProtection
$crlDP
$ocspIAI

Note that the line with "$crlDP" is line 123

When I run the command:

openssl req -config $dir/openssl-intermediate.cnf   -key 
$dir/private/$serverfqdn.key.$format-subj "$DN" -new -sha256 
-out $dir/csr/$serverfqdn.csr.$format


I get the error:

req: Error on line 123 of config file 
"/home/rgm/ca/intermediate/openssl-intermediate.cnf"

unable to find 'distinguished_name' in config
problems making Certificate Request
3070145488:error:0E06D06A:configuration file 
routines:NCONF_get_string:no conf or environment 
variable:crypto/conf/conf_lib.c:272:


note that if I:

grep -n distinguished_name openssl-intermediate.cnf

68:distinguished_name  = req_distinguished_name
78:[ req_distinguished_name ]

So the warning about unable to find 'distinguished_name' in config

Is misleading.  The problem is more likely with line 123 which is only 
the env variable.


I can play around with this and hopefully the variables to work as

crlDistributionPoints = $crlDP

And if $crlDP is empty, it will not put an empty value into the cert.  
But why does what I have not work?


thanks

Bob



--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Env variables in config file to add a whole line

[Robert Moskowitz]

I am trying to use an environment variable to add a whole line to the 
config file.  This is to control adding (or not providing) CRL and/or 
OCSP support.


export shows:

declare -x crlDP="crlDistributionPoints = 
URI:http://www.htt-consult.com/pki/intermediate.crl.pem;

declare -x default_crl_days="default_crl_days  = 30"
declare -x ocspIAI="authorityInfoAccess = 
OCSP;URI:http://ocsp.htt-consult.com;


The config file starts with:


[ ca ]
# `man ca`
default_ca = CA_default

[ CA_default ]
# Directory and file locations.
dir= $ENV::dir
cadir = $ENV::cadir
format= $ENV::format
crlDP = $ENV::crlDP
default_crl_days  = $ENV::default_crl_days
ocspIAI  = $ENV::ocspIAI


The usr_cert section has:

[ usr_cert ]
# Extensions for client certificates (`man x509v3_config`).
basicConstraints = CA:FALSE
nsCertType = client, email
nsComment = "OpenSSL Generated Client Certificate"
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
keyUsage = critical,nonRepudiation,digitalSignature,keyEncipherment
extendedKeyUsage = clientAuth, emailProtection
$crlDP
$ocspIAI

Note that the line with "$crlDP" is line 123

When I run the command:

openssl req -config $dir/openssl-intermediate.cnf   -key 
$dir/private/$serverfqdn.key.$format-subj "$DN" -new -sha256 
-out $dir/csr/$serverfqdn.csr.$format


I get the error:

req: Error on line 123 of config file 
"/home/rgm/ca/intermediate/openssl-intermediate.cnf"

unable to find 'distinguished_name' in config
problems making Certificate Request
3070145488:error:0E06D06A:configuration file 
routines:NCONF_get_string:no conf or environment 
variable:crypto/conf/conf_lib.c:272:


note that if I:

grep -n distinguished_name openssl-intermediate.cnf

68:distinguished_name  = req_distinguished_name
78:[ req_distinguished_name ]

So the warning about unable to find 'distinguished_name' in config

Is misleading.  The problem is more likely with line 123 which is only 
the env variable.


I can play around with this and hopefully the variables to work as

crlDistributionPoints = $crlDP

And if $crlDP is empty, it will not put an empty value into the cert.  
But why does what I have not work?


thanks

Bob

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Testing OCSP with openssl

[Robert Moskowitz]

On 09/05/2017 11:59 AM, Dr. Stephen Henson wrote:

On Tue, Sep 05, 2017, Robert Moskowitz wrote:


Jamie Nugyen's guide uses openssl to test OCSP with 'openssl ocsp':

https://jamielinux.com/docs/openssl-certificate-authority/online-certificate-status-protocol.html

What is unclear here is:

Does openssl read the index.txt file once at startup, or does it
read it with each query.  From the way I read his guide it reads
like index.txt is only read at startup.


Once on startup. The mini-responder is only a test utility.
It is not usable as a full blown responder.


Oh, I got the test utility limitation.  Just for my guide, after 
revoking the certificate which results in index.txt being updated, does 
the test 'openssl ocsp' service need to be restarted to reread the 
index.txt file?


So from your response, just the once at startup, and I will have to 
specify (as Jamie does in his guide) to restart the test responder.


I am searching for a 'simple' OCSP responder for myself...

Thanks

Bob

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Testing OCSP with openssl

[Robert Moskowitz]

Michael,

Thanks for this concise review.  I look at it as the "Big Bang theory of 
Security".  i.e. what comes first.


And HOW DID we get those heavy metals beyond Iron?  :)

Bob

On 09/05/2017 09:10 AM, Michael Wojcik wrote:

From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
Of Robert Moskowitz
Sent: Tuesday, September 05, 2017 08:43

Also he recommends password protecting the keypair.  That results in
needing to provide the password at responder startup.  Is this the
'normal' approach?  Is the password provided in some other file (like a
responder config file)?  I am use to putting SQL passwords into php
config files, not that I like that...

That's one of the oldest problems in IT security. Most approaches fall into one 
of three categories:

- Specialized hardware. This was one of the original intended uses for Sun's 
JavaButton hardware token, back in the '90s, but the JavaButton never really 
took off. These days we have various flavors of HSMs which act as key vaults 
and signing servers - though then you have the problem of authenticating to the 
signing server, or if you offload all crypto operations, authenticating to the 
crypto server. TPMs (which are essentially integrated HSMs), smartcard readers, 
etc can also hold keys, but typically require some authentication by a human at 
system startup.

- Attended startup with manual passphrase entry. The server can't start until 
someone enters the passphrase at the keyboard.

- Passphrase or private key in a file for unattended startup, hopefully 
protected as well as possible by filesystem permissions, filesystem encryption, 
etc. This is obviously the weakest choice for key protection, since it has a 
wider threat tree (more paths for an attacker to make use of the private key) 
than the other two options.

For general-purpose applications where you don't need particularly good 
performance, such as a moderate-volume web server, there are some very 
inexpensive hardware options. OpenSSL works well with the NitroKey HSM (via the 
PKCS#11 engine), for example. Things get tougher as you add requirements.



--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Testing OCSP with openssl

[Robert Moskowitz]

Jamie Nugyen's guide uses openssl to test OCSP with 'openssl ocsp':

https://jamielinux.com/docs/openssl-certificate-authority/online-certificate-status-protocol.html

What is unclear here is:

Does openssl read the index.txt file once at startup, or does it read it 
with each query.  From the way I read his guide it reads like index.txt 
is only read at startup.


Also he recommends password protecting the keypair.  That results in 
needing to provide the password at responder startup.  Is this the 
'normal' approach?  Is the password provided in some other file (like a 
responder config file)?  I am use to putting SQL passwords into php 
config files, not that I like that...


thanks

Bob

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] [openssl-dev] How to use BIO_do_connect(), blocking and non-blocking with timeout, coping with errors

[Robert Moskowitz]

Here is the URL for the paper fromusenix:

https://www.usenix.org/system/files/conference/usenixsecurity12/sec12-final228.pdf

I would like to find a more recent work as well.

On 09/01/2017 06:32 PM, Salz, Rich via openssl-users wrote:


FWIW, there’s a ‘libtls’ library from the libre folks that might be 
worth looking at.


If you come up with useful snippets we can start by posting them to 
the wiki, for example






-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Internet Draft Guide to creating an EDSA PKI

[Robert Moskowitz]

On 09/01/2017 04:30 PM, Blumenthal, Uri - 0553 - MITLL wrote:

On 9/1/17, 16:26, "openssl-users on behalf of Michael Wojcik" 
 wrote:


Bob, I just want to say thanks for producing this. Even if it never makes 
it out of I-D stage, there's a lot of useful information here.

It would probably make a good addition to the OpenSSL wiki, too.
 
+1 on both.


Rich indicated that he would link this I-D on the wiki.

And I-Ds are 'forever'.

So far there are a couple nits on the draft.  Nothing on the body. One 
item that perhaps others might know of and can help...


In the Security section I reference papers on problems with lack of 
randomness.  I found the one paper that I really remember:


https://factorable.net/weakkeys12.extended.pdf

But perhaps there is a better site for this paper and perhaps people 
here know of more papers like this to put in the reference section..


Thanks

Bob

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Another problem with openssl x509 -req -- default_enddate

[Robert Moskowitz]

On 08/30/2017 09:22 PM, Michael Richardson wrote:

Viktor Dukhovni  wrote:
 > So indeed, you'd not be the first to consider a special-purpose
 > concise format.  It is somewhat surprising that the applications
 > you're considering use X.509 certificates at all, rather than just
 > raw public keys.  With expiration times in the year "", the
 > extra bloat of certificates is perhaps just useless baggage.

We are leveraging the political unity behind 802.1AR (which defines the
IDevID). As a profile it's pretty thin, relying extensively (but
appropriately) on IETF documents,  yet still leaving a bunch of stuff rather
under-specified.


By intent.


While devices possessing IDevIDs don't need all the cert chain stuff,
the network infrastructure validating them may need it.  Given supply chain
complexity, it could well be in the IDevID that linking back to the
manufacturer requires a chain of certificates.  (My KitchenAid dishwasher is
made and serviced by Whirlpool, but was sold to me by Sears.  I'd expect
Sears' certificate to be in the electronic invoice)


Actually there was extensive discussion that this would be LDevIDs. The 
manufacturer is KitchenAId.  Their IDevID.  So that Whirlpool can 
service it, a Whirlpool LDevID.  We could not come to any consistent 
scenario on Sears as the Merchant.  No real difference than Target 
selling a TracPhone.  What interaction do they have after the sale?


Or there is NO KitchenAid Identity in the machine.  They were just a job 
shop for Whirlpool so only a Whirlpool IDevID...


You missed out on all the fun discussions, Michael.  You just get to 
pick up the pieces!


The real drivers, at the time was Cisco and Aruba for their phones...


 > Admittedly, I don't know how the security model in question relates
 > to the real-world constraints of the supply chain, who gets to sign
 > certificates for devices allowed to participate, and whether a
 > certificateless public key database might have been a realistic
 > option.

No, it's just not.
In the 6tisch (constrained) version of BRSKI, which is at:

https://bitbucket.org/6tisch/draft-richardson-6tisch-dtsecurity-secure-join/src/b84347549d469806067cf60b323444f97a98ee83/dtsecurity-zerotouch-join-00.txt?at=master=file-view-default
until the rename of the document is approved.  Section 2.2 explains that the
constrained device will have/need only the raw public key of the manufacturer, 
and
will treat the IDevID as a blob.  The private key should be stored in
whatever form is most convenient for computation, like the Apple boot loader
does.   Still, some people will have TPMs with complicated interfaces.


Lots of groups taking the basics and putting them together in a way that 
SHOULD work for them...


Bob

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Another problem with openssl x509 -req -- default_enddate

[Robert Moskowitz]

On 08/30/2017 10:33 AM, Viktor Dukhovni wrote:

On Wed, Aug 30, 2017 at 06:03:03AM -0400, Robert Moskowitz wrote:


I woke up a little clearer head, and realized, that a truly
constrained device won't even bother with DER, but just store the raw
keypair.

FWIW, Apple's boot firmware stores the signature key as the raw
RSA key bits in little-endian form for efficient computation on
Intel CPUs.  No PEM or ASN.1 in sight.

Similarly, there's no ASN.1 in the DNSSEC DNSKEY RDATA format.
For RSA just the key and exponent octets:

 $ echo $(dig +short +nosplit -t dnskey . | grep -w 256 | awk '{print $NF}' | openssl 
base64 -A -d | hexdump -ve '/1 "%02x"')
 
030100018bf1ad038eba329d673fb7ecffa82f897b7b7e7fd1d887fe66484c68e5a787fcd591902b8d8737149f92249a8629cf477b746108630b7f77357e13a2b4a24c9cbbe9305675d34e902fc8686a9c6f87ab53e9d0ef99362dfd2822903ba930a4dd4933601aa12831c702bd94762b44eee14b0dca17e2704b0a8687e45b5fc6152ac93951bb44415c012e28efab3914c53f45e0039be5cd5997b700a46fd1bc1a49c7b8ed63540c2edecc8f4551c4ac86da5ecd7e8da86f5962fe0e8e3077e940f932f7fa9524fb32930f69dcabb65b24165d768f53ecf663be7b56254cc81c83166511408e98be57ba60874a352985d980351b880d6cf682c02f528b49d9a82183

The "03" is the exponent length (limited to 255 octets), the "10
00 01" is the usual F_4 (65537) exponent, and the remaining 512
nibbles are the RSA modulus.

So indeed, you'd not be the first to consider a special-purpose
concise format.  It is somewhat surprising that the applications
you're considering use X.509 certificates at all, rather than just
raw public keys.  With expiration times in the year "", the
extra bloat of certificates is perhaps just useless baggage.
Admittedly, I don't know how the security model in question relates
to the real-world constraints of the supply chain, who gets to sign
certificates for devices allowed to participate, and whether a
certificateless public key database might have been a realistic
option.


I am the author of HIP (rfc 7401) and to a large extent, raw public keys 
for Identity.  I started this work in January '99, before most of the 
current stuff using raw keys came around.  I know that Apple parallel 
developed much of their work.  Stewart Cheshire has said that if he had 
found the time to read HIP, he would have used it for the call home 
function.  And I know all about DNSKEY, as a few years into HIP, we 
chose to use the DNSKEY format in the HI parameter payload, dropping our 
own format.


I also worked with Sigma Design on Zwave 2.0 which uses raw EC25519 keys.

But not everyone agrees with me on raw keys, and I do recognize the need 
of 3rd party identity assertions.  And this is, to a large measure, what 
IEEE 802.1AR-2009 Secure Identities offers.  But 1AR is only about the 
Identities, and not how to manage and bootstrap from iDevIDs to 
lDevIDs.  The IETF workgroup, ANIMA is working on this.  And Michael 
Richardson, who just joined this list, is one of the authors on those 
documents.  Oh, and NETCONF is working on it for network infrastructure 
devices with their 'zero touch' drafts. Of course those are NOT 
constrained devices...


Getting 802.1AR-2009 does require an IEEE login, but is free thanks to 
us IEEE 802 meeting attendees paying a bit extra to IEEE to make our 
docs free 6 months after publication.  Of course the addendum that is in 
final prep is NOT available free (to non-attendees), but the changes do 
not impact this discussion.



--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Internet Draft Guide to creating an EDSA PKI

[Robert Moskowitz]

I want to thank people here for their help.  I welcome you to look at 
the 1st cut of my work, I welcome comments.


I have to 'keep my fingers off of it' for a bit.  Start on the CRL and 
OCSP parts in a week or so.


Bob


 Forwarded Message 
Subject:New Version Notification for draft-moskowitz-ecdsa-pki-00.txt
Date:   Wed, 30 Aug 2017 06:53:03 -0700
From:   internet-dra...@ietf.org
To: 	Robert Moskowitz <r...@labs.htt-consult.com>, Liang Xia 
<frank.xiali...@huawei.com>, Henk Birkholz 
<henk.birkh...@sit.fraunhofer.de>, Liang Xia <frank.xiali...@huawei.com>




A new version of I-D, draft-moskowitz-ecdsa-pki-00.txt
has been successfully submitted by Robert Moskowitz and posted to the
IETF repository.

Name:   draft-moskowitz-ecdsa-pki
Revision:   00
Title:  Guide for building an ECC pki
Document date:  2017-08-30
Group:  Individual Submission
Pages:  26
URL:
https://www.ietf.org/internet-drafts/draft-moskowitz-ecdsa-pki-00.txt
Status: https://datatracker.ietf.org/doc/draft-moskowitz-ecdsa-pki/
Htmlized:   https://tools.ietf.org/html/draft-moskowitz-ecdsa-pki-00
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-moskowitz-ecdsa-pki-00


Abstract:
   This memo provides a guide for building a PKI (Public Key
   Infrastructure) using openSSL.  All certificates in this guide are
   ECDSA, P-256, with SHA256 certificates.  Along with common End Entity
   certificates, this guide provides instructions for creating IEEE
   802.1AR [IEEE.802.1AR_2009] iDevID Secure Device certificates.

  



Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Another problem with openssl x509 -req -- default_enddate

[Robert Moskowitz]

Viktor,

On 08/30/2017 12:59 AM, Viktor Dukhovni wrote:

On Wed, Aug 30, 2017 at 12:17:09AM -0400, Robert Moskowitz wrote:


So back to openssl ca and deal with no way to directly create a DER
formatted cert.

Definitely a deficiency.

Not really a deficiency, as the certificates in question need to
be squirreled away in PEM format in the CA's "certs/" directory
(compatibility with longstanding behaviour), and are much more
easily exported, via email etc., in PEM format.

It is trivial to convert a PEM certificate to DER.  Mind you,
if I wanted a specialized CA, I'd go with the C API, where
you can do *exactly* what you want:

   * Store metadata in a SQL database.
   * Read keys directly from PKCS8
   * Write certs directly in DER form
   * ...

The openssl ca(1) program is to some extent just a demo, that meets
only the simplest needs.  Perhaps you were looking for a turnkey
CLI, but you have a specialized new use-case, and it is not entirely
surprising that it is not directly supported.

Patches to support missing features that might be of use to others
are welcome.  The software evolves best through community participation.


I am not a coder.  In fact I pretty much stopped writing code in the 
'80s.  I DID some programming in B on Honeywells.  The only place where 
B escaped Bell Labs.  I never got to C; moved on to other IT support 
work, then to coding standards in English...


I have some limited scripting skills.

So as much as would like to contribute code, with maybe 2 years to 
retirement, I am not going to pick it up.  But who knows, maybe I will 
take a C programming course as part of my retirement activities.


I kind-of slept on this issue. I know that I can convert a PEM cert to 
DER, but I have been thinking about 'what of the other portions, like 
the keypair file?'  I woke up a little clearer head, and realized, that 
a truly constrained device won't even bother with DER, but just store 
the raw keypair.  So doing the creation all PEM and converting what is 
needed as DER to DER may be a realistic approach.


thanks for your help on this.

Bob

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Another problem with openssl x509 -req -- default_enddate

[Robert Moskowitz]

Viktor,

thanks for the explanation. Obviously I read more into the man that was 
really there:


https://www.openssl.org/docs/man1.1.0/apps/x509.html

So back to openssl ca and deal with no way to directly create a DER 
formatted cert.


Definitely a deficiency.

On 08/29/2017 07:25 PM, Viktor Dukhovni wrote:

On Tue, Aug 29, 2017 at 05:36:34PM -0400, Robert Moskowitz wrote:


Another problem.  It is almost like it is not reading the CA selction?

Not "almost", but actually as expected, since "openssl x509 -req"
is not the ca(1) application.


openssl x509 -req -extfile $dir/openssl-8021AR.cnf \
 -extensions 8021ar_idevid -days 365 -sha256 \
 -set_serial 0x$(openssl rand -hex $sn) \
 -inform $format -in $dir/csr/$DevID.csr.$format \
 -outform $format -out $dir/certs/$DevID.cert.$format \
 -CAkeyform $format -CAkey $dir/private/8021ARintermediate.key.$format \
 -CAform $format -CA $dir/certs/8021ARintermediate.cert.$format

does not.  Even if I leave out the -days option.

It just creates a signed certificate based on the command-line
options, with only the extensions (-extfile option) read from a
configuration file.  The only concession to ca(1)-like behaviour
is support for a compatible serial number file (likely subject to
race conditions absent external locks to serialize invocations).

 * The version is 3, since you're using extensions
 * The serial number is specified on the command line.
 * The issuer DN is taken from the signing certificate.
 * The subject DN and public key are copied from the CSR

That just leaves the dates, and you get to specify the duration
from *now* with "-days".

With "x509 -req" you're building certs pretty much from the ground
up, a short C program will do exactly the same work, and could use
an explicit end date, rather than an increment of 'n' days from
the present.



--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Not updating index.txt

[Robert Moskowitz]

On 08/29/2017 07:24 PM, Dr. Stephen Henson wrote:

On Tue, Aug 29, 2017, Robert Moskowitz wrote:


I started out making certs from csrs with:

openssl ca -config $dir/openssl-intermediate.cnf -extensions
usr_cert -days 375 -notext -md sha256 \
   -in $dir/csr/$clientemail.csr.$format -out
$dir/certs/$clientemail.cert.$format

And that worked well enough, but I found some limitations (DER) with
it and switched to:


openssl x509 -req -days 375 -extfile $dir/openssl-intermediate.cnf\
-extensions usr_cert -sha256\
-set_serial 0x$(openssl rand -hex $sn)\
-inform $format -in $dir/csr/$clientemail.csr.$format\
-outform $format -out $dir/certs/$clientemail.cert.$format\
-CAkeyform $format -CAkey $dir/private/intermediate.key.$format\
-CAform $format -CA $dir/certs/intermediate.cert.$format

I just noticed that this format does not update the index.txt file.
Why?  What do I need to add so it does?


Unlike ca the  index.txt file is not used by the x509 utility at all it also
only uses the configuration file for extensions.


This, and what Viktor said is 'waking me up to' req is NOT a solution.

Back to ca.

thanks


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Another problem with openssl x509 -req -- default_enddate

[Robert Moskowitz]

Another problem.  It is almost like it is not reading the CA selction?

openssl ca -config $dir/openssl-8021AR.cnf -extensions 8021ar_idevid 
-notext -md sha256 \

  -in $dir/csr/$DevID.csr.pem -out $dir/certs/$DevID.cert.pem

processes the default_enddate

default_enddate= 1231235959Z # per IEEE 802.1AR

to produce:

Not Before: Aug 29 21:19:33 2017 GMT
Not After : Dec 31 23:59:59  GMT


But

   openssl x509 -req -extfile $dir/openssl-8021AR.cnf\
-extensions 8021ar_idevid -days 365 -sha256\
-set_serial 0x$(openssl rand -hex $sn)\
-inform $format -in $dir/csr/$DevID.csr.$format\
-outform $format -out $dir/certs/$DevID.cert.$format\
-CAkeyform $format -CAkey 
$dir/private/8021ARintermediate.key.$format\

-CAform $format -CA $dir/certs/8021ARintermediate.cert.$format

does not.  Even if I leave out the -days option.

I am thinking, do I need to use:

-extensions ca 8021ar_idevid

?? but that will probably be a syntax error.

thanks


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Not updating index.txt

[Robert Moskowitz]

I started out making certs from csrs with:

openssl ca -config $dir/openssl-intermediate.cnf -extensions usr_cert 
-days 375 -notext -md sha256 \
  -in $dir/csr/$clientemail.csr.$format -out 
$dir/certs/$clientemail.cert.$format


And that worked well enough, but I found some limitations (DER) with it 
and switched to:



   openssl x509 -req -days 375 -extfile $dir/openssl-intermediate.cnf\
   -extensions usr_cert -sha256\
   -set_serial 0x$(openssl rand -hex $sn)\
   -inform $format -in $dir/csr/$clientemail.csr.$format\
   -outform $format -out $dir/certs/$clientemail.cert.$format\
   -CAkeyform $format -CAkey $dir/private/intermediate.key.$format\
   -CAform $format -CA $dir/certs/intermediate.cert.$format

I just noticed that this format does not update the index.txt file. 
Why?  What do I need to add so it does?


Bob


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Existing connections on certification expires

[Robert Moskowitz]

On 08/28/2017 09:44 AM, Alan Buxey wrote:

hi,



2) How can i get the list of ciphers supported by openssl 01.01.0f ?


openssl ciphers -v ???



These question looks to be very basic but i could not find any concrete
information regarding the same googling.

Google provides the answers if your question is well formed. or you
could just read the
openssl man pages?


And I have found Professor Google to be very patient with me as I form 
my questions to get answers I can work with.  But there HAVE been times 
when my search foo has been weak, and the good Professor just can't 
figure out what I want to learn


Bob


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Existing connections on certification expires

[Robert Moskowitz]

On 08/28/2017 09:07 AM, Viktor Dukhovni wrote:

On Mon, Aug 28, 2017 at 06:13:51AM -0400, Robert Moskowitz wrote:


1) What happens to the existing SSL connections on certification expiry?
Does the openssl disconnects the existing connection?

No, once authenticated, TLS connections continue indefinitely,
until either party chooses to disconnect.  The expiration of the
certificate does not invalidate the integrity of the original key
exchange, and presents no obvious increased risk of active attack.


Generally speaking:

openssl has nothing to do with a SSL/TLS connection.  It created the
certificate, it is not the application using the certificate.

This is wrong.  Many applications delegate certificate verification
to the OpenSSL library.  OpenSSL does not limit connection lifetime
based on certificate expiration.


Argh, you are right.  The libraries are indeed used.  I was thinking the 
whole program.  My error.  Thinking too narrowly.





That is commonly a server app (HTTPS, IMAPS, VPN server, etc.) and a client
(Web browser, Mail client, VPN client).  Most of these pay no attention to
the expiry date.

This is wrong.


They pay no attention to the expiry date to force the session to end at 
that time by adjusting the session lifetime to be no later than the 
expiry date.  Though there are probably apps out there with this behavior.


They do indeed ensure that the certificate is within its dates.  A 
nuance that I did not make clear.



--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Existing connections on certification expires

[Robert Moskowitz]

On 08/28/2017 06:13 AM, Robert Moskowitz wrote:



On 08/28/2017 01:09 AM, mahesh gs wrote:

Hello All,

We are using openssl for providing the secured communication for our 
application. I have some basic queries about the openssl behaviour.


1) What happens to the existing SSL connections on certification 
expiry? Does the openssl disconnects the existing connection?


Generally speaking:

openssl has nothing to do with a SSL/TLS connection.  It created the 
certificate, it is not the application using the certificate.


That is commonly a server app (HTTPS, IMAPS, VPN server, etc.) and a 
client (Web browser, Mail client, VPN client).  Most of these pay no 
attention to the expiry date.  Some, like IPsec specify to check the 
expiry date and set the maximum connection lifetime to less that it.  
Of course even there your mileage will vary by how each product author 
read the specs.


I recall now the IPsec debate on this.  The consensus was that at the 
time of connection setup, the certificate was valid.  Thus the parties 
could set whatever connection lifetime they have in their policy.  It 
was not considered MANDATORY to shorten the lifetime to the certificate 
expiry date.  This was important, as there are IPsec policies with 
month-long connection lifetimes.






2) How can i get the list of ciphers supported by openssl 01.01.0f ?

These question looks to be very basic but i could not find any 
concrete information regarding the same googling.


Thanks,
Mahesh G S








-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Existing connections on certification expires

[Robert Moskowitz]

On 08/28/2017 01:09 AM, mahesh gs wrote:

Hello All,

We are using openssl for providing the secured communication for our 
application. I have some basic queries about the openssl behaviour.


1) What happens to the existing SSL connections on certification 
expiry? Does the openssl disconnects the existing connection?


Generally speaking:

openssl has nothing to do with a SSL/TLS connection.  It created the 
certificate, it is not the application using the certificate.


That is commonly a server app (HTTPS, IMAPS, VPN server, etc.) and a 
client (Web browser, Mail client, VPN client).  Most of these pay no 
attention to the expiry date.  Some, like IPsec specify to check the 
expiry date and set the maximum connection lifetime to less that it.  Of 
course even there your mileage will vary by how each product author read 
the specs.




2) How can i get the list of ciphers supported by openssl 01.01.0f ?

These question looks to be very basic but i could not find any 
concrete information regarding the same googling.


Thanks,
Mahesh G S




-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Cant get openssl x509 to work as documented

[Robert Moskowitz]

Jakob,

You make a good point.  In fact, after some reflection, there is 
probably no reason for the device to store more than the 96 bytes of 
keyvalue in secure store.  If some format is needed to use the key, that 
can be done at that time.  This is for the case where the device 
supports only one algorithm.


I know that the current practice is crypto agility, but IoT, 
particularly automotive IoT, will select and live with one for a 
generation of product.  When the next best thing is selected, then that 
will be used, but not retrofitted.  I hope that soon, I will be able to 
push Ed25519; I am concerned about the computational cost, though (still 
not clear why SHA512 and not SHAKE128).  Meanwhile P256 is what is fielded.


Bob

On 08/23/2017 03:52 PM, Jakob Bohm wrote:

On 22/08/2017 22:26, Robert Moskowitz wrote:
Want to continue this thread but with new information.  I built a 
Fedora-arm 26 system (on a Cubieboard2) and it has openssl version 
1.1.0f


I built my DER root cert (and private key) no problem.

I built my DER Intermediate cert private key and CSR no problem.

For the following command:

sn=8
format=der
dir=/root/ca3
cadir=/root/ca3

openssl x509 -req -days 3650 -extfile $cadir/openssl-root.cnf 
-extensions v3_intermediate_ca\

 -sha256 -set_serial 0x$(openssl rand -hex $sn)\
 -inform $format -in $dir/csr/intermediate.csr.$format\
 -outform $format -out $dir/certs/intermediate.cert.$format\
 -CAkeyform $format -CAkey $cadir/private/ca.key.$format\
 -CAform $format -CA $cadir/certs/ca.cert.$format

I built this reading:

https://www.openssl.org/docs/man1.1.0/apps/x509.html

This generates:

3069592528:error:0906D06C:PEM routines:PEM_read_bio:no start 
line:crypto/pem/pem_lib.c:691:Expecting: CERTIFICATE REQUEST


The man page above has CAkeyform and CAform in the summary, but no 
details below.  I am ASSUMEing DER is now supported.


for -sha256, I finally figured out that -[digest] is how the the man 
presents which hash to use.


Why does this command use -extfile and not -config?  Is it because 
ALL that is taken from config is -extensions?  Confusing to the 
casual user.


But why the error?

And yes, I know I can convert a PEM cert to DER, but I would also 
have to convert the private key, and maintain duo structures in 
places.  Would RATHER have a parallel setup.  Of course there is the 
challenge of the cert chain that Viktor earlier explained. OCSP? :)




I don't think you have to pass all the various formats as PEM just
because you pass one of them as such.  After all, there are separate
-XXXform style options for most of them.

For example, you could store the CA private key in the encryption-
supporting PEM format on the plentyful memory of the SD card, while
using the more compact DER format for certificates and CSRs stored
on embedded controllers (ECUs, dashboard displays etc.).

Where OpenSSL bugs prevent use of DER for a file, it can be converted
on the fly, storing the converted file in RAM (using tmpfs or similar).


Enjoy

Jakob


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Cant get openssl x509 to work as documented

[Robert Moskowitz]

On 08/23/2017 03:52 PM, Jakob Bohm wrote:

On 22/08/2017 22:26, Robert Moskowitz wrote:
Want to continue this thread but with new information.  I built a 
Fedora-arm 26 system (on a Cubieboard2) and it has openssl version 
1.1.0f


I built my DER root cert (and private key) no problem.

I built my DER Intermediate cert private key and CSR no problem.

For the following command:

sn=8
format=der
dir=/root/ca3
cadir=/root/ca3

openssl x509 -req -days 3650 -extfile $cadir/openssl-root.cnf 
-extensions v3_intermediate_ca\

 -sha256 -set_serial 0x$(openssl rand -hex $sn)\
 -inform $format -in $dir/csr/intermediate.csr.$format\
 -outform $format -out $dir/certs/intermediate.cert.$format\
 -CAkeyform $format -CAkey $cadir/private/ca.key.$format\
 -CAform $format -CA $cadir/certs/ca.cert.$format

I built this reading:

https://www.openssl.org/docs/man1.1.0/apps/x509.html

This generates:

3069592528:error:0906D06C:PEM routines:PEM_read_bio:no start 
line:crypto/pem/pem_lib.c:691:Expecting: CERTIFICATE REQUEST


The man page above has CAkeyform and CAform in the summary, but no 
details below.  I am ASSUMEing DER is now supported.


for -sha256, I finally figured out that -[digest] is how the the man 
presents which hash to use.


Why does this command use -extfile and not -config?  Is it because 
ALL that is taken from config is -extensions?  Confusing to the 
casual user.


But why the error?

And yes, I know I can convert a PEM cert to DER, but I would also 
have to convert the private key, and maintain duo structures in 
places.  Would RATHER have a parallel setup.  Of course there is the 
challenge of the cert chain that Viktor earlier explained. OCSP? :)




I don't think you have to pass all the various formats as PEM just
because you pass one of them as such.  After all, there are separate
-XXXform style options for most of them.

For example, you could store the CA private key in the encryption-
supporting PEM format on the plentyful memory of the SD card, while
using the more compact DER format for certificates and CSRs stored
on embedded controllers (ECUs, dashboard displays etc.).

Where OpenSSL bugs prevent use of DER for a file, it can be converted
on the fly, storing the converted file in RAM (using tmpfs or similar).


I know this is an option, and if I can't get this working, then I have 
to punt.


I am considering to make the Root and Intermediate files all PEM, and 
only the EE is DER.


Should get to that tomorrow.  I would rather establish that what I tried 
above is just still not allowed, or it is a bug.


Bob

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Cant get openssl x509 to work as documented

[Robert Moskowitz]

Viktor,

Thank you for this in-depth explanation.

I have talked to a number of large potential customers where certs are 
important but they are highly constrained.  This includes the auto 
sector with ECUs that are really pressed to the wall (like on the engine 
block and already running at 130C!)


A PEM ECDSA private key file (not passworded) is 241 bytes.  The DER 
equivalent is 121 bytes.  Even if we follow the ANIMA model that allows 
both the iDevID and lDevID certs to use the same key (shudder), a 120 
bytes of secure store savings is a big issue. Otherwise we double this 
storage cost.   Ed25519 should be smaller, as the public key is 32 
bytes, not the 64 of P256.  But I don't like that they used SHA512 for 
Ed25519 rather than SPAKE128 (they used SPAKE256 for Ed488).


And then there is the cert store in regular storage, plus whatever 
support (like chains) needed.  As I think more of this, 802.1AR-2009 
only expects to device to have its iDevID cert, not also the cert chain 
to the root.  It never has to verify its cert, the manufacturer stuffed 
it in at built time into read only memory with an expiry date of 
forever.  It is the lDevID part that ANIMA is building into a complex 
bootstrap process that I don't totally agree with.  And NETCONF is doing 
their flavor of it.  Sigh.


The IETF CORE wg is looking at this too.

I have to munch on this problem a lot more.

Bob

On 08/22/2017 10:19 AM, Viktor Dukhovni wrote:

On Aug 21, 2017, at 9:02 PM, Robert Moskowitz <r...@htt-consult.com> wrote:

openssl x509 -req -days 3650 -extensions v3_intermediate_ca -inform $format\
-in $dir/csr/intermediate.csr.$format -outform $format -out 
$dir/certs/intermediate.cert.$format\
-CAkeyform $format -CAkey $cadir/private/ca.key.$format -CAform $format\
-CA $cadir/certs/ca.cert.$format

Where format=der and got that der is an invalid option.  Plus the 'help' 
reported:

It is trivial to convert a PEM certificate to DER, just pipe the output through
"openssl x509 -outform DER".  Mind you this is often the wrong thing to do, 
because
the DER form of an X.509 certificate holds *exactly* one certificate, while 
users
often need a certificate *chain*, that also includes the requisite intermediate
certificates.  With PEM, the certificate file can just all the certificates back
to back.  With DER only the EE certificate appears in the file.

While PKCS#7 can hold a bunch of certificates in DER form, it is not typically
used a certificate chain file by any applications, and IIRC there's no 
indication
of which of the certificates is the end-entity certificate in a PKCS#7 file.

The only widely used DER form for chains is PKCS#12 which holds the private
key as well as the certificate chain, and has a mandatory passphrase.  I use
PKCS#12 (instead of JKS) for Java TLS server applications, set the file
access mode to 0600, and since there's no point in prompting batch applications
for a passphrase, set the passphrase to "umask 077", since that's the only
effective protection for the private key.

It is not clear that PKCS#12 is compellingly more compact than PEM, the only
reason I use it is that Java supports JKS and PKCS#12, but not PEM.


Note that -CAkeyform is invalid and that -CAkey can only be PEM.

As explained before, the API for DER PrivateKey objects does not
support passwords, and the CLI does not have a way to indicate
the use PKCS8PrivateKey instead.  The PrivateKey interface can
read only unencrypted PKCS#8 in PEM form.


Even when I used my pem CA key, I still got errors.  -config is
not an option, where does this command get the config file from?
-extensions says it looks to the config file for that label!

The config file for "x509 -req" is specified with "-extfile ...".


SHA256 is not listed as a valid hash.

Many more X.509 digest algorithms are supported in this context
than (sadly) are listed in the manpage.  Perhaps there should
be a command that lists all supported x.509 hash algorithms,
and the documentation for commands that take any of the
supported algorithms can just refer the reader to the output
of that command.



--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Cant get openssl x509 to work as documented

[Robert Moskowitz]

Want to continue this thread but with new information.  I built a 
Fedora-arm 26 system (on a Cubieboard2) and it has openssl version 1.1.0f


I built my DER root cert (and private key) no problem.

I built my DER Intermediate cert private key and CSR no problem.

For the following command:

sn=8
format=der
dir=/root/ca3
cadir=/root/ca3

openssl x509 -req -days 3650 -extfile $cadir/openssl-root.cnf 
-extensions v3_intermediate_ca\

 -sha256 -set_serial 0x$(openssl rand -hex $sn)\
 -inform $format -in $dir/csr/intermediate.csr.$format\
 -outform $format -out $dir/certs/intermediate.cert.$format\
 -CAkeyform $format -CAkey $cadir/private/ca.key.$format\
 -CAform $format -CA $cadir/certs/ca.cert.$format

I built this reading:

https://www.openssl.org/docs/man1.1.0/apps/x509.html

This generates:

3069592528:error:0906D06C:PEM routines:PEM_read_bio:no start 
line:crypto/pem/pem_lib.c:691:Expecting: CERTIFICATE REQUEST


The man page above has CAkeyform and CAform in the summary, but no 
details below.  I am ASSUMEing DER is now supported.


for -sha256, I finally figured out that -[digest] is how the the man 
presents which hash to use.


Why does this command use -extfile and not -config?  Is it because ALL 
that is taken from config is -extensions?  Confusing to the casual user.


But why the error?

And yes, I know I can convert a PEM cert to DER, but I would also have 
to convert the private key, and maintain duo structures in places.  
Would RATHER have a parallel setup.  Of course there is the challenge of 
the cert chain that Viktor earlier explained.  OCSP? :)


Bob

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Cant get openssl x509 to work as documented

[Robert Moskowitz]

On 08/22/2017 10:53 AM, Salz, Rich via openssl-users wrote:

  > SHA256 is not listed as a valid hash.
 

Many more X.509 digest algorithms are supported in this context
than (sadly) are listed in the manpage.  Perhaps there should
   be a command that lists all supported x.509 hash algorithms,
and the documentation for commands that take any of the

  >   supported algorithms can just refer the reader to the output
  >   of that command.
 
Fixed in 1.1.0 and later; “list—digest-algorithms” command.  And the manpages should say things like “any supported digest” and such.



I was going by:

https://www.openssl.org/docs/man1.0.2/apps/x509.html

Which has a very short list.  And not SHA256.

Bob

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Cant get openssl x509 to work as documented

[Robert Moskowitz]

I had a frustrating day.  I looked at the documentation at:

https://www.openssl.org/docs/man1.0.2/apps/x509.html

My Fedora24 reports that I am at version 1.0.2k

I made the following comand:

openssl x509 -req -days 3650 -extensions v3_intermediate_ca -inform $format\
 -in $dir/csr/intermediate.csr.$format -outform $format -out 
$dir/certs/intermediate.cert.$format\

-CAkeyform $format -CAkey $cadir/private/ca.key.$format -CAform $format\
 -CA $cadir/certs/ca.cert.$format

Where format=der and got that der is an invalid option.  Plus the 'help' 
reported:


Note that -CAkeyform is invalid and that -CAkey can only be PEM.

Even when I used my pem CA key, I still got errors.  -config is not an 
option, where does this command get the config file from? -extensions 
says it looks to the config file for that label!


SHA256 is not listed as a valid hash.

usage: x509 args
 -inform arg - input format - default PEM (one of DER, NET or PEM)
 -outform arg- output format - default PEM (one of DER, NET or PEM)
 -keyform arg- private key format - default PEM
 -CAform arg - CA format - default PEM
 -CAkeyform arg  - CA key format - default PEM
 -in arg - input file - default stdin
 -out arg- output file - default stdout
 -passin arg - private key password source
 -serial - print serial number value
 -subject_hash   - print subject hash value
 -subject_hash_old   - print old-style (MD5) subject hash value
 -issuer_hash- print issuer hash value
 -issuer_hash_old- print old-style (MD5) issuer hash value
 -hash   - synonym for -subject_hash
 -subject- print subject DN
 -issuer - print issuer DN
 -email  - print email address(es)
 -startdate  - notBefore field
 -enddate- notAfter field
 -purpose- print out certificate purposes
 -dates  - both Before and After dates
 -modulus- print the RSA key modulus
 -pubkey - output the public key
 -fingerprint- print the certificate fingerprint
 -alias  - output certificate alias
 -noout  - no certificate output
 -ocspid - print OCSP hash values for the subject name and 
public key

 -ocsp_uri   - print OCSP Responder URL(s)
 -trustout   - output a "trusted" certificate
 -clrtrust   - clear all trusted purposes
 -clrreject  - clear all rejected purposes
 -addtrust arg   - trust certificate for a given purpose
 -addreject arg  - reject certificate for a given purpose
 -setalias arg   - set certificate alias
 -days arg   - How long till expiry of a signed certificate - def 
30 days

 -checkend arg   - check whether the cert expires in the next arg seconds
   exit 1 if so, 0 if not
 -signkey arg- self sign cert with arg
 -x509toreq  - output a certification request object
 -req- input is a certificate request, sign and output.
 -CA arg - set the CA certificate, must be PEM format.
 -CAkey arg  - set the CA key, must be PEM format
   missing, it is assumed to be in the CA file.
 -CAcreateserial - create serial number file if it does not exist
 -CAserial arg   - serial file
 -set_serial - serial number to use
 -text   - print the certificate in text form
 -C  - print out C code forms
 - - digest to use, see openssl dgst -h output for list
 -extfile- configuration file with X509V3 extensions to add
 -extensions - section from config file with X509V3 extensions to add
 -clrext - delete extensions before signing and input certificate
 -nameopt arg- various certificate name options
 -engine e   - use engine e, possibly a hardware device.
 -certopt arg- various certificate text options
 -checkhost host - check certificate matches "host"
 -checkemail email - check certificate matches "email"
 -checkip ipaddr - check certificate matches "ipaddr"


So it looks like for now, I cannot make a guide that easily supports DER 
or PEM.  DER really seems to be an issue how to make.


My searching has come up pretty empty.  No instructions out there.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users