On 04/17/2018 06:50 PM, Jason A. Donenfeld wrote:
>* Allow specifying 'none' to the --ca parameter, to specify that
> certificates should not be checked against a CA. Note that 'none'
> is already used in other similar options as a special placeholder.
>
>* When '--ca none' is in
>
> 2. instead of storing a certificate on each side, wouldn't it be nice to
> be able to store the public key only of the certificate, or perhaps even
> a hash of the public key of the certificate?
> To me, storing either the certificate itself is not a problem (I recall
> Jason Donenfeld wantin
Hi all,
On 25/05/18 22:56, Simon Rozman wrote:
JJK, I think you are misreading this proposal. No hash is being sent
as a part of the handshake -- its still client and server
certificates that are exchanged and checked during handshake. The hash
is exchanged by a separate channel (say snail mail
What does this accomplish you can’t just basically do with
—client-cert-not-required?
Eric Crist
> On May 25, 2018, at 3:56 PM, Simon Rozman wrote:
>
> Hi,
>
>>> JJK, I think you are misreading this proposal. No hash is being sent
>>> as a part of the handshake -- its still client and server
Hi,
> What does this accomplish you can’t just basically do with —client-cert-not-
> required?
I am using --client-cert-not-required already. :)
But that simplifies only the client half of the equation.
TLS server will always need a certificate. And client will always need to
verify it to prev
Hi,
> > JJK, I think you are misreading this proposal. No hash is being sent
> > as a part of the handshake -- its still client and server
> > certificates that are exchanged and checked during handshake. The hash
> > is exchanged by a separate channel (say snail mail:) in advance, and
> > serves
Hi Selva,
On 25/05/18 16:07, Selva Nair wrote:
On Fri, May 25, 2018 at 9:51 AM, Jan Just Keijser wrote:
On 25/05/18 03:41, Simon Rozman wrote:
Private and public key are still used. The patch stil uses
certificates and TLS, it only replaces the check certificate of the
peer's certificate agai
Hi,
On Fri, May 25, 2018 at 9:51 AM, Jan Just Keijser wrote:
> Hi,
>
> On 25/05/18 03:41, Simon Rozman wrote:
Private and public key are still used. The patch stil uses
certificates and TLS, it only replaces the check certificate of the
peer's certificate against the CA with a
Hi,
On 25/05/18 03:41, Simon Rozman wrote:
Private and public key are still used. The patch stil uses
certificates and TLS, it only replaces the check certificate of the
peer's certificate against the CA with a hash check (certificate
pinning if you want).
So basically instead of saying that yo
On 25/05/18 09:41, Simon Rozman wrote:
> Hi,
>
>>> Private and public key are still used. The patch stil uses
>>> certificates and TLS, it only replaces the check certificate of the
>>> peer's certificate against the CA with a hash check (certificate
>>> pinning if you want).
>>>
>>> So basicall
Hi,
> > Private and public key are still used. The patch stil uses
> > certificates and TLS, it only replaces the check certificate of the
> > peer's certificate against the CA with a hash check (certificate
> > pinning if you want).
> >
> > So basically instead of saying that you trust all certif
On 24/05/18 12:17, Arne Schwabe wrote:
>
>>> When you sign a certificate you are actually singing the hash of the
>>> certificate. So you essentially are saying: "This certificate with the
>>> hash xxxyyy is trusted by my CA". Traditionally we used the MD5 of the
>>> certificate, then SHA1 and now
>> When you sign a certificate you are actually singing the hash of the
>> certificate. So you essentially are saying: "This certificate with the
>> hash xxxyyy is trusted by my CA". Traditionally we used the MD5 of the
>> certificate, then SHA1 and now SHA256 which we signed. (See the weak md5
>>
Hi Arne,
On 23/05/18 16:46, Arne Schwabe wrote:
I have some strong thoughts on this, mostly related to: can someone
explain to me why this is safe?
I've seen that OpenSSH 7.7 now implements something similar (xmss
hash-based signatures,
https://tools.ietf.org/html/draft-irtf-cfrg-xmss-hash-bas
>>
> I have some strong thoughts on this, mostly related to: can someone
> explain to me why this is safe?
>
> I've seen that OpenSSH 7.7 now implements something similar (xmss
> hash-based signatures,
> https://tools.ietf.org/html/draft-irtf-cfrg-xmss-hash-based-signatures-12,
> disabled by def
Hi Steffan,
On 17/05/18 20:31, Steffan Karger wrote:
Hi Jason,
[ Dumping my thoughts so this doesn't remain completely unanswered for
even longer. ]
On 17-04-18 18:50, Jason A. Donenfeld wrote:
OpenVPN traditionally works around CAs. However many TLS-based protocols also
allow an alternative
Hi Jason,
[ Dumping my thoughts so this doesn't remain completely unanswered for
even longer. ]
On 17-04-18 18:50, Jason A. Donenfeld wrote:
> OpenVPN traditionally works around CAs. However many TLS-based protocols also
> allow an alternative simpler mode in which rather than verify certificates
OpenVPN traditionally works around CAs. However many TLS-based protocols also
allow an alternative simpler mode in which rather than verify certificates
against CAs, the certificate itself is hashed and compared against a
pre-known set of acceptable hashes. This is usually referred to as
"fingerpri
18 matches
Mail list logo
