On 24/12/2018 19:52, Viktor Dukhovni wrote:
>> On Dec 24, 2018, at 2:44 PM, Salz, Rich via openssl-users
>> wrote:
>>
>> Pre-shared keys (PSK) don't require certs, maybe that meets the need. A
>> thing to know about PSK is that each side is fully trusted, and if one side
>> gets the key
> On Dec 24, 2018, at 5:51 PM, Kyle Hamilton wrote:
> If a certificate identifies an Issuer, then the certificate cannot contain an
> empty sequence of RDNs in the Subject and still be conformant to PKIX.
Yes, CA certificates need to have a non-empty subject name if they're
to be used for
In order for an Issuer to exist in PKIX, it must be the Subject of another
Certificate (or of a trust anchor). If a certificate identifies an Issuer,
then the certificate cannot contain an empty sequence of RDNs in the
Subject and still be conformant to PKIX. This is because the Subject of
the
> On Dec 24, 2018, at 2:44 PM, Salz, Rich via openssl-users
> wrote:
>
> Pre-shared keys (PSK) don't require certs, maybe that meets the need. A
> thing to know about PSK is that each side is fully trusted, and if one side
> gets the key stolen, then the thief can pretend to be either side.
>While certificate-less TLS is in theory possible with RFC7250 bare public
> keys
Pre-shared keys (PSK) don't require certs, maybe that meets the need. A thing
to know about PSK is that each side is fully trusted, and if one side gets the
key stolen, then the thief can pretend to be
If all you need is RSA then you will probably find it easier to write a
makefile of your own. You will have to do multiple builds to get all the
missing pieces, such as the BN facility, the memory allocation, the error
stack, etc.
--
openssl-users mailing list
To unsubscribe:
In message <3fc4d543-d71a-8c22-566a-d902c4f7d...@gmail.com> on Mon, 24 Dec 2018
13:17:51 +0100, Gisle Vanem said:
> Richard Levitte wrote:
>
> >> I experimented some more. I figured the "auto" does not work.
> >> But this works:
> >>perl crypto\aes\asm\aesni-x86_64.pl nasm > tmp-file.s
>
I am implementing a module for ruby-openssl to add CMS API access to ruby.
(Once I figure it out, I will likely look at how to refactor PKCS7 API code,
but I don't care about that yet)
PKCS7 has the PKCS7_SIGNER_INFO object, and it is declared in pkcs7.h with
DECLARE_ASN1_FUNCTIONS().
CMS has
On Mon, Dec 24, 2018 at 04:29:49PM +, Matt Caswell wrote:
> How about using PSKs? That way you completely avoid the need for a
> certificate.
> Authentication is implied since both peers must have access to the PSK for the
> connection to succeed. ECDHE can be combined with the PSK to create
On 24/12/2018 11:51, Christian wrote:
> Hello, people. I'm a beginner with OpenSSL and with cryptography in general,
> and
> have been wondering how to best implement an upcoming system.
>
> I apologise in advance for any grammar or orthography mistakes, as English
> isn't
> my native
On Mon, Dec 24, 2018 at 04:25:54PM +0100, Christian wrote:
> > Your research has led you astray. The ECDHE-RSA-AES128-GCM-SHA25
> > ciphersuiteo *is* RSA authenticated and offers forward secrecy,
>
> Then how would I load my static RSA keys into my SSL_CTX? Simply by
> using
Your research has led you astray. The ECDHE-RSA-AES128-GCM-SHA25
ciphersuiteo *is* RSA authenticated and offers forward secrecy,
Then how would I load my static RSA keys into my SSL_CTX? Simply by
using SSL_CTX_use_PrivateKey_file on client and server? As far as I
understand the mechanism
On Mon, Dec 24, 2018 at 12:51:17PM +0100, Christian wrote:
> This sounds like a typical RSA scenario, however I also want to have
> forward security, which requires me to use something with temporary keys
> only - I'm having ECDHE in mind for that, ECDHE-RSA-AES128-GCM-SHA256 in
> particular.
I’m not sure, heh. ;-)
-F
> On Dec 24, 2018, at 3:17 AM, Walter H. wrote:
>
> and which CA does this as the forum guidelines say?
>
>> On 23.12.2018 22:50, Felipe Gasper wrote:
>> Actually, per the latest CA/Browser forum guidelines, subject.CN is not only
>> optional but “discouraged”.
>>
On 21/12/2018 06:12, prithiraj das wrote:
> I am using OpenSSL 1.1.1 from OpenSSL's website and trying to build OpenSSL
> on a
> Windows 64 bit machine using Perl 64 bit version and nasm v2.13.03. I have
> used
> the *no-shared* option in the Perl Configure to only build the static library
>
Richard Levitte wrote:
I experimented some more. I figured the "auto" does not work.
But this works:
perl crypto\aes\asm\aesni-x86_64.pl nasm > tmp-file.s
diff tmp-file.s crypto\aes\aesni-x86_64.asm
No diffs.
Why does the the generation of .asm-files be so damn hard to
figure out? Some
Hello, people. I'm a beginner with OpenSSL and with cryptography in
general, and have been wondering how to best implement an upcoming system.
I apologise in advance for any grammar or orthography mistakes, as
English isn't my native language.
We have a local network with a databse in which
On 18/12/2018 08:21, Dmitry Belyavsky wrote:
> Hello,
>
> Is it possible to send empty renegotiation_info extension instead of
> TLS_EMPTY_RENEGOTIATION_INFO_SCSV using openssl s_client?
No, this isn't possible. We only ever send the renegotiation_info extension on a
reneg ClientHello.
Matt
Hi All,
Please accept this as a gentle reminder to the previous mail in the
mailchain. And also would a custom makefile (if created for this purpose)
help in this regard?
Thanks and Regards,
Prithiraj
On Fri, 21 Dec 2018 at 06:12, prithiraj das wrote:
> I am using OpenSSL 1.1.1 from OpenSSL's
A bit off-topic but is it also a good idea to follow these guidelines in
non-browser use cases, for example for a client certificate which is used
to autenticate on a TLS connection which will be used for another protocol
such as MQTT? In this case the SubjectCN looks like a "natural" place to
put
and which CA does this as the forum guidelines say?
On 23.12.2018 22:50, Felipe Gasper wrote:
Actually, per the latest CA/Browser forum guidelines, subject.CN is not only
optional but “discouraged”.
-FG
smime.p7s
Description: S/MIME Cryptographic Signature
--
openssl-users mailing list
21 matches
Mail list logo
