Re: Update

2019-05-21 Thread Paul Yang



> On May 22, 2019, at 10:16, Salz, Rich  wrote:
> 
>>> I'd be opposed to this last option without IANA/IETF being on board. By 
>>> doing so
>>   we are effectively no longer compliant with IETF TLS since we're using 
>> certain
>>   codepoints and version numbers to mean things that IETF/IANA have no 
>> visibility
>>   of, i.e. we would be doing exactly what Rich was worried about. I don't see
>>   IANA/IETF doing this anytime soon.
>> 
>> For the most part, getting IANA on board requires someone in authority email 
>> to tls-regis...@iana.org asking for code points and pointing to their spec.
> 
>’someone in authority’ here means the author of the spec who is asking for 
> code points?
> 
> 
> Yes.  Or someone involved with the spec.

Hmmm, that would be someone involved in GM/T 0024...

> 





Re: Update

2019-05-21 Thread Paul Yang



> On May 21, 2019, at 22:13, Salz, Rich  wrote:
> 
> 
>>  I'd be opposed to this last option without IANA/IETF being on board. By 
>> doing so
>we are effectively no longer compliant with IETF TLS since we're using 
> certain
>codepoints and version numbers to mean things that IETF/IANA have no 
> visibility
>of, i.e. we would be doing exactly what Rich was worried about. I don't see
>IANA/IETF doing this anytime soon.
> 
> For the most part, getting IANA on board requires someone in authority email 
> to tls-regis...@iana.org asking for code points and pointing to their spec.

’someone in authority’ here means the author of the spec who is asking for code 
points?

> 





Re: Update

2019-05-21 Thread Paul Yang



> On May 21, 2019, at 06:20, Matt Caswell  wrote:
> 
> 
> On 20/05/2019 20:01, Kurt Roeckx wrote:
>> On Mon, May 20, 2019 at 10:21:45AM -0700, Paul Yang wrote:
>>> 
>>> The Chinese modified TLS protocol is not intended to interoperate with any 
>>> other TLS protocols. The cipher suites defined in this protocol should not 
>>> be used with the standard IETF TLS. So I guess what Matt said would be 
>>> feasible to do. But in reality, users may want to have a combination of 
>>> both IETF TLS and Chinese TLS together when he launches a TLS server or 
>>> client, to have the auto-selection functionality if a TLS client comes in. 
>>> So the way of implementation would be tricky...
>> 
>> So I think there are 3 options:
>> - You use TLS, not some Chinese variant, and add things like Chinese
>>  ciphers to it.
> 
> That would be fine but my understanding is that the Chinese government mandate
> this particular Chinese variant in some situations - so we'd also have to 
> change
> government policy which doesn't seem very likely ;-)

You are right. There is currently no official Chinese national standards that 
define cipher suites for IETF TLS yet.

> 
>> - Use something that's not TLS at all, a Chinese variant, and
>>  don't support both protocols on the same port.
> 
> If we decide to add support for the Chinese variant, then this would be my
> preferred way of doing it.
> 
>> - Support both on the same port. This will require coordination
>>  with IANA and/or IETF.
> 
> I'd be opposed to this last option without IANA/IETF being on board. By doing 
> so
> we are effectively no longer compliant with IETF TLS since we're using certain
> codepoints and version numbers to mean things that IETF/IANA have no 
> visibility
> of, i.e. we would be doing exactly what Rich was worried about. I don't see
> IANA/IETF doing this anytime soon.
> 
> Matt
> 





Forthcoming OpenSSL Releases

2019-05-21 Thread Matt Caswell
The OpenSSL project team would like to announce the forthcoming release
of OpenSSL versions 1.1.1c, 1.1.0k and 1.0.2s.

These releases will be made available on 28th May 2019 between approximately
1200-1600 UTC.

OpenSSL 1.1.0k and 1.0.2s contain security hardening bug fixes only but do not
address any CVEs. OpenSSL 1.1.1c is a bug-fix release (and contains the
equivalent security hardening fixes as for 1.1.0k and 1.0.2s where relevant).

Yours

The OpenSSL Project Team



signature.asc
Description: OpenPGP digital signature


Re: Update

2019-05-21 Thread Salz, Rich
 
 >   I'd be opposed to this last option without IANA/IETF being on board. By 
 > doing so
we are effectively no longer compliant with IETF TLS since we're using 
certain
codepoints and version numbers to mean things that IETF/IANA have no 
visibility
of, i.e. we would be doing exactly what Rich was worried about. I don't see
IANA/IETF doing this anytime soon.
   
For the most part, getting IANA on board requires someone in authority email to 
tls-regis...@iana.org asking for code points and pointing to their spec.



Planned server shutdown (move), June 3rd

2019-05-21 Thread Richard Levitte
Hi all,

Our main server will move to a different data center, and therefore
needs to be taken down for a couple of hours.

This is scheduled to happen on Monday June 3rd, between 10:00 and
13:00 CEST (08:00 - 11:00 UTC).

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/


Re: Welcoming our new committers

2019-05-21 Thread Patrick Steuer
Hello and many thanks !

Im really looking forward to working on the project.

Patrick


Re: Welcoming our new committers

2019-05-21 Thread Dmitry Belyavsky
Many thanks for a great honor to become an OpenSSL committer!

I hope to be useful after I understand the procedures.

On Tue, May 21, 2019 at 12:58 AM Paul Dale  wrote:

> Welcome to the team.
>
>
> Pauli
> --
> Oracle
> Dr Paul Dale | Cryptographer | Network Security & Encryption
> Phone +61 7 3031 7217
> Oracle Australia
>
>
> -Original Message-
> From: Matt Caswell [mailto:m...@openssl.org]
> Sent: Monday, 20 May 2019 8:31 PM
> To: openssl-project@openssl.org
> Subject: Welcoming our new committers
>
> Please welcome our four new committers as announced here:
>
> https://www.openssl.org/blog/blog/2019/05/20/committers/
>
> The new committers are:
>
> Dmitry Belyavsky, Shane Lontis, Tomáš Mráz and Patrick Steuer.
>
> Welcome all!
>
> Matt
>


-- 
SY, Dmitry Belyavsky