On 12/09/2017 15:10, Nikos Mavrogiannopoulos wrote:
>
> That is, because a TLS server would typically sign with whatever
> algorithm the client supports and would very rarely be interested to
> utilize the security advantages of including the parameters (which,
> advantages, are quite unclear even
On 11/09/2017 19:42, Eric Rescorla wrote:
> Ugh.
>
> Generally, the idea with signature schemes is that they are supposed to
> reflect
> both the capabilities of your TLS stack and the capabilities of your PKI
> verifier [0]. So, yes, if you advertise this it is supposed to work. So,
> ideally
>
On 08/09/2017 23:59, Peter Wu wrote:
>
> In particular, for certificates:
>
> - Limitations on salt length?
> - What AlgorithmIdentifier OID to use?
> - Whether to constrain other AlgorithmIdentifier Params? (MGF, hash
>algorithm, trailerField)?
>
Note that you have to check any PSS rest
On 21/07/2017 16:00, Ilari Liusvaara wrote:
>
> I suppose some new dual-version TLS 1.2/1.3 libraries might have the
> same issue as mine: supported groups is just plain ignored for ECDSA,
> and siganture algorithms have the TLS 1.3 meanings, even in TLS 1.2.
>
That is potentially a problem yes.
--
Dr Stephen N. Henson.
Founder member of the OpenSSL project: http://www.openssl.org/
On 21/07/2017 20:45, Dr Benjamin Kaduk wrote:
> On 07/21/2017 08:41 AM, Dr Stephen Henson wrote:
>> On 21/07/2017 14:23, Hubert Kario wrote:
>>> Signature Algorithms for ECDSA now define
On 21/07/2017 14:23, Hubert Kario wrote:
> Signature Algorithms for ECDSA now define both the curve and the hash
> algorithm:
>
> ecdsa_secp256r1_sha256(0x0403), ecdsa_secp384r1_sha384(0x0503),
> ecdsa_secp521r1_sha512(0x0603),
>
> This is in contrast to the TLS 1.2 protocol, where any hash can
On 26/04/2017 14:41, Ilari Liusvaara wrote:
> On Wed, Apr 26, 2017 at 03:23:57PM +0200, Martin Rex wrote:
>>
>> The issue with RSA-PSS digital signatures is that they were defined
>> with additional (unnecessary) parameters that are encoded (=hidden) in the
>> ASN.1 AlgorithmIdentifier, and that ar
On 25/04/2017 15:36, Benjamin Kaduk wrote:
> On 04/25/2017 07:08 AM, Dr Stephen Henson wrote:
>> On 18/02/2017 02:31, Dr Stephen Henson wrote:
>>> Does this apply to RSASSA-PSS (RSA-PSS signing only) keys in end entity
>>> certificates too?
>>>
>>&g
On 18/02/2017 02:31, Dr Stephen Henson wrote:
>
> Does this apply to RSASSA-PSS (RSA-PSS signing only) keys in end entity
> certificates too?
>
> For example could a TLS 1.2 server legally present a certificate containing an
> RSASSA-PSS key for an appropriate ciphersuite?
On 27/03/2017 08:47, Olivier Levillain wrote:
>
> For a longer version, post-handshake records of type Handshake can be of
> three kinds:
> - NewSessionTicket (sent by the server, and that can safely be ignored
> entirely by clients)
> - KeyUpdate (sent by either party, requiring only a bit of sta
On 09/02/2017 21:17, Eric Rescorla wrote:
> Hi folks,
>
> We need to close on an issue about the size of the
> state in the HelloRetryRequest. Because we continue the transcript
> after HRR, if you want a stateless HRR the server needs to incorporate
> the hash state into the cookie. However, this
On 18/02/2017 16:26, Viktor Dukhovni wrote:
> On Sat, Feb 18, 2017 at 02:31:19AM +0000, Dr Stephen Henson wrote:
>
>>
>> For example could a TLS 1.2 server legally present a certificate containing
>> an
>> RSASSA-PSS key for an appropriate ciphersuite? Similarly c
On 18/02/2017 10:01, Martin Thomson wrote:
> On 18 February 2017 at 13:31, Dr Stephen Henson
> wrote:
>> could a TLS 1.2 server legally present a certificate containing an
>> RSASSA-PSS key for an appropriate ciphersuite? Similarly could a client
>> present
>> a cer
On 08/02/2017 21:17, Ilari Liusvaara wrote:
> On Wed, Feb 08, 2017 at 07:34:16PM +, Timothy Jackson wrote:
>> I have a question on RFC5246 (TLS 1.2) and how it’s going to interact with
>> RSASSA-PSS as we roll out TLS 1.3. Does the prohibition against RSASSA-PSS
>> apply only to the signatures
A couple of questions on the format and handling of certificate_extensions.
What format is the data that appears in certificate_extension_values? I'd say
that it should be in the same format as the content octets of the extnValue
field of Extension (from RFC5280 et al). So (for example) it would b
Draft 18 says:
RSASSA-PSS algorithms Indicates a signature algorithm using RSASSA-
PSS [RFC3447] with MGF1. The digest used in the mask generation
function and the digest being signed are both the corresponding
hash algorithm as defined in [SHS]. When used in signed TLS
16 matches
Mail list logo
