Maybe we just didn’t. At least not with the command line tools.
The CHANGES file lists a merge between « dh », « gendh », and « dhparam » in
2000, but no evolution since then.
The oldest version I could find is 0.9.6, and there’s no command-line DH key
generation.
Cordialement,
Erwann Abalea
On Thu, Jun 30, 2016 at 5:11 PM, Matt Caswell wrote:
>
>
> On 30/06/16 16:54, Salz, Rich wrote:
> >> Since X25519 is not the first "encrypt-only" algorithm in the
> >> OpenSSL universe, how was requesting certificates handled for
> >> such algorithms in the past?
> >
> > It
On 30/06/16 16:54, Salz, Rich wrote:
>> Since X25519 is not the first "encrypt-only" algorithm in the
>> OpenSSL universe, how was requesting certificates handled for
>> such algorithms in the past?
>
> It wasn't.
>
>> For example how would one request a DH certificate?
>
> You couldn't.
>
> Since X25519 is not the first "encrypt-only" algorithm in the
> OpenSSL universe, how was requesting certificates handled for
> such algorithms in the past?
It wasn't.
> For example how would one request a DH certificate?
You couldn't.
I don't recall anyone ever asking for such a thing on
Which brings back my generalized question from yesterday:
Since X25519 is not the first "encrypt-only" algorithm in the
OpenSSL universe, how was requesting certificates handled for
such algorithms in the past?
For example how would one request a DH certificate?
Whatever was defined back then
Yes, I can certainly program my way out of the problem, but it would be
nice if the command line tool allowed me a way to do it.
Thanks!
Mike
On Thu, Jun 30, 2016 at 9:37 AM, Erwann Abalea
wrote:
> Ok, you’re talking about OpenSSL command line tool only, I missed
Ok, you’re talking about OpenSSL command line tool only, I missed that part.
The solution should then be to modify apps/ca.c:certify() function to add an
arg, and avoid the call to X509_REQ_verify when desired.
Cordialement,
Erwann Abalea
Le 29 juin 2016 à 19:17, Michael Scott
tsets
On 6/29/16, Abe Racioppo wrote:
> 290620161352
>
> On 6/29/16, Salz, Rich wrote:
>>
>>> But surely the openssl command line tool should provide a mechanism for
>>> allowing an X25519-based certificate to be signed by a CA.
>>
>>> Its seems that
290620161352
On 6/29/16, Salz, Rich wrote:
>
>> But surely the openssl command line tool should provide a mechanism for
>> allowing an X25519-based certificate to be signed by a CA.
>
>> Its seems that the "certificate request" protocol, which requires
>> self-signing, prevents
> But surely the openssl command line tool should provide a mechanism for
> allowing an X25519-based certificate to be signed by a CA.
> Its seems that the "certificate request" protocol, which requires
> self-signing, prevents this in this case.
Yes, that is exactly the point.
--
On Wed, Jun 29, 2016 at 6:21 PM, Salz, Rich wrote:
>
> > To repeat: X25519 only supports key exchange. The 25519 signing
> > mechanism is not yet defined.
>
Which I don't have a problem with.
But surely the openssl command line tool should provide a mechanism for
allowing an
> To repeat: X25519 only supports key exchange. The 25519 signing
> mechanism is not yet defined.
And see also: https://datatracker.ietf.org/doc/draft-ietf-curdle-pkix/
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>as it objects that X25519 does not support signature.
To repeat: X25519 only supports key exchange. The 25519 signing mechanism is
not yet defined.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Thanks Erwann, but that's not an answer to my question.
To get the CA to sign (using RSA or anything) a certificate that contains
an X25519 public key, that certificate must first submit to the CA
something called a "Certificate request". This takes the form of the
supplicant certificate, which
Bonjour,
You may have a classic certificate containing your {X,Ed}{25519,448,whatever}
public key once:
* an OID is allocated to identify this type of public key (it will go into
tbs.subjectPublicKeyInfo.algorithm.algorithm)
* a set of associated optional parameters are defined for
> 1. What is CFRG, I don't remember that acronym.
Crypto Forum Research Group, part of the IETF's affiliated research group.
Co-chair is Kenny Paterson of lucky-13 (etc). Useful documents here as well as
pointers to the mailing list https://datatracker.ietf.org/rg/cfrg/documents/
> 2.
WellI can help with CFRG - its Crypto Forum Research Group.
Mike
On Wed, Jun 29, 2016 at 4:10 PM, Jakob Bohm wrote:
> On 29/06/2016 16:53, Salz, Rich wrote:
>
>> How do I do this? Using the OpenSSL command line tool, a certificate
>>> request must be self-signed, but
On 29/06/2016 16:53, Salz, Rich wrote:
How do I do this? Using the OpenSSL command line tool, a certificate request
must be self-signed, but the X25519 elliptic curve (newly supported in version
1.1.0), doesn't do signature, it can only be used for key exchange.
You cannot do it.
You should
> How do I do this? Using the OpenSSL command line tool, a certificate request
> must be self-signed, but the X25519 elliptic curve (newly supported in
> version 1.1.0), doesn't do signature, it can only be used for key exchange.
You cannot do it.
You should look at the CFRG documents on
19 matches
Mail list logo