[erlang-questions] Handshake failure with DHE-DSS cipher suites

[Ingela Andin]

I think it belongs in

diff --git a/lib/public_key/asn1/PKIX1Algorithms88.asn1
b/lib/public_key/asn1/PKIX1Algorithms88.asn1
index 6cc6745..13ac6fa 100644
--- a/lib/public_key/asn1/PKIX1Algorithms88.asn1
+++ b/lib/public_key/asn1/PKIX1Algorithms88.asn1
@@ -40,6 +40,12 @@
   }
    -- encoding for DSA signature generated with SHA-1 hash

+id-dsa-with-sha256  OBJECT IDENTIFIER  ::=  { joint-iso-itu-t(2)
++        country(16) us(840) organization(1) gov(101) csor(3)
++        nistalgorithm(4) sigalgs(3) 2 }
++
+
+
    Dss-Sig-Value  ::=  SEQUENCE  {
       r       INTEGER,
       s       INTEGER  }

You are welcome to submit a PR.

Regards Ingela Erlang/OTP - Team Ericsson AB

2018-05-15 18:12 GMT+02:00 Per Hedeland <per@REDACTED>:

> On 2018-05-15 15:08, Ingela Andin wrote:
> > Hi!
> >
> > I think that the oid is missing due to an oversight in adding it when
> crypto was updated to support it. For some reason (which I do not know)
> early versions of crypto did only
> > support sha1 (sha) with dsa.
>
> Afer further digging, I think it's just a matter of "evolution" - the
> 'id-dsa-with-sha1' oid is defined in asn1/PKIX1Algorithms88.asn1, but
> 'id-dsa-with-sha256' is a more recent thing, and neither defined there
> nor in any of the other modules i the asn1 directory, and I'm not sure
> it "belongs" in any of them.
>
> The definitions that can be found on the 'net agree on the numerical oid
> elements, but there are actually at least two variants on the
> (irrelevant here) naming of them - the one under "DSA with SHA-2 family"
> on
> https://csrc.nist.gov/Projects/Computer-Security-
> Objects-Register/Algorithm-Registration
> seems pretty authoritative to me:-), but it's not given as part of any
> ASN.1 module AFAIU. However
> https://www.itu.int/ITU-T/formal-language/itu-t/x/x509/2016/
> AlgorithmObjectIdentifiers.html
> seems to do that, with a module that also includes most but not all of
> the definitions that are handled by public_key:pkix_sign_types/1...
>
> > The correct oid name should be in the generated include file included in
> public_key.hrl
>
> Well it isn't, since it isn't defined in any of the modules in the asn1
> directory. But anyway, just dropping the definition from above into the
> one of them that seems to have most of the definitions handled by
> pkix_sign_types/1 makes for a slighly nicer diff (below).
>
> > Without looking into this further, I suspect that  the passing of the
> suites, could be due to that the  actual sha function used is a result of
> the "hash_sign negotiation"  that depends on the
> > hash_sign hello extension.
>
> I'm not worried by that:-), but I'd like to make the DHE-DSS suites
> work. I'll go with the below diff for now, but maybe OTP will fix it
> "properly" in some future version?
>
> --Per
>
> diff --git a/lib/public_key/asn1/PKCS-1.asn1 b/lib/public_key/asn1/PKCS-1.
> asn1
> index 117eacd..1df6719 100644
> --- a/lib/public_key/asn1/PKCS-1.asn1
> +++ b/lib/public_key/asn1/PKCS-1.asn1
> @@ -87,6 +87,12 @@ id-sha512  OBJECT IDENTIFIER  ::=  { joint-iso-itu-t(2)
>          nistalgorithm(4) hashalgs(2) 3 }
>
>
> +-- This probably doesn't belong here, but...
> +id-dsa-with-sha256  OBJECT IDENTIFIER  ::=  { joint-iso-itu-t(2)
> +        country(16) us(840) organization(1) gov(101) csor(3)
> +        nistalgorithm(4) sigalgs(3) 2 }
> +
> +
>  RSAPublicKey ::= SEQUENCE {
>      modulus           INTEGER,  -- n
>      publicExponent    INTEGER   -- e
> diff --git a/lib/public_key/src/public_key.erl
> b/lib/public_key/src/public_key.erl
> index 0341266..75305cb 100644
> --- a/lib/public_key/src/public_key.erl
> +++ b/lib/public_key/src/public_key.erl
> @@ -498,6 +498,8 @@ pkix_sign_types(?'id-dsa-with-sha1') ->
>      {sha, dsa};
>  pkix_sign_types(?'id-dsaWithSHA1') ->
>      {sha, dsa};
> +pkix_sign_types(?'id-dsa-with-sha256') ->
> +    {sha256, dsa};
>  pkix_sign_types(?'ecdsa-with-SHA1') ->
>      {sha, ecdsa};
>  pkix_sign_types(?'ecdsa-with-SHA256') ->
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20180516/cf38ab1d/attachment.htm>