There’s a separate regression/change we noticed. In RabbitMQ, we currently use ?'id-domainComponent' and ?'street-address' macros that disappeared between RC3 and RC4. This is very old code and we can probably change it quite easily, but it’s not clear whether these macros were removed intentionally or accidentally.
Ok, updated PR try again. I think this is how we will solve it for OTP-28.0 but I think that we would like to make some API functions for Password Based Encryption in public key so that not all of these records need to be exposed, if you want to use it outside of handling PEM-files. And maybe if there are some newer algorithms that you want to add that should be added to OTPs public_key ?
1 Like
I will now loot at the domain and street macros.
I add back ‘id-domainComponent’ but street-address seem to have been removed in the new specs.
Thanks a lot! I’ve tested commit 140f280cd3e13dae026bb93f087f966dde6db342 of your branch and here are my findings:
- Jose still doesn’t compile but a simple change from
EncryptedPrivateKeyInfo_encryptionAlgorithmtoEncryptionAlgorithmIdentifieris sufficient to compile it. I hope that’s a correct change. - While I can make it compile, some tests fail. When I switch to OTP27.3.3, fewer tests fail… I will need more time to understand what’s failing and why (I’m not familiar with Jose internals at all, we just use it as a dependency in RabbitMQ)
- After the change to Jose and removal of the
street-addressusage, I can compile and start RabbitMQ
CC @potatosalad, in case you are interested in this conversation
I’ve also been investigating jose and found that these functions crash in 28 but work in 27.
public_key:der_encode('SubjectPublicKeyInfo',{'SubjectPublicKeyInfo',
{'AlgorithmIdentifier',{1,2,840,10045,2,1},<<6,5,43,129,4,0,34>>},
<<4,7,187,159,230,244,88,107,121,139,128,132,154,156,41,218,110,252,32,77,
113,43,240,245,31,30,100,188,99,199,177,60,227,97,146,100,79,213,223,
191,91,97,225,37,53,10,26,178,151,251,187,220,102,206,153,225,247,253,
176,216,190,177,50,112,89,139,225,135,12,45,78,189,212,157,93,60,152,10,
232,1,37,168,191,14,42,155,29,152,245,76,139,100,210,7,157,86,233>>}).
public_key:der_encode('PrivateKeyInfo',{'PrivateKeyInfo',v1,
{'PrivateKeyInfo_privateKeyAlgorithm',{1,3,101,112},asn1_NOVALUE},
<<4,32,233,181,192,232,242,61,135,51,157,56,189,189,150,53,204,72,177,206,
251,50,108,238,68,42,255,63,213,69,4,19,173,10>>,
asn1_NOVALUE}).
public_key:pem_entry_encode('PrivateKeyInfo',{'PrivateKeyInfo',v1,
{'PrivateKeyInfo_privateKeyAlgorithm',{1,3,101,112},asn1_NOVALUE},
<<4,32,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0>>,
asn1_NOVALUE})
We’ll continue digging tomorrow to see what is going on.
1 Like
I have added some backwards compatibility wrappers for this. Note however that we do not support those formats when decoding. We will for the “subjectPublickeyInfo” decode according to new spec. And PrivateKeyInfo has always been decode further so that user need not deal with so much oid-matching.
Erlang/OTP 28 [RELEASE CANDIDATE 4+] [erts-15.2.7] [source-140f280cd3] [64-bit] [smp:8:8] [ds:8:8:10] [async-threads:1] [jit:ns]
Eshell V15.2.7 (press Ctrl+G to abort, type help(). for help)
1> Encoded = public_key:der_encode(‘SubjectPublicKeyInfo’,{‘SubjectPublicKeyInfo’,
{‘AlgorithmIdentifier’,{1,2,840,10045,2,1},<<6,5,43,129,4,0,34>>},
<<4,7,187,159,230,244,88,107,121,139,128,132,154,156,41,218,110,252,32,77,
113,43,240,245,31,30,100,188,99,199,177,60,227,97,146,100,79,213,223,
191,91,97,225,37,53,10,26,178,151,251,187,220,102,206,153,225,247,253,
176,216,190,177,50,112,89,139,225,135,12,45,78,189,212,157,93,60,152,10,
232,1,37,168,191,14,42,155,29,152,245,76,139,100,210,7,157,86,233>>}).
<<48,118,48,16,6,7,42,134,72,206,61,2,1,6,5,43,129,4,0,34,
3,98,0,4,7,187,159,230,244,…>>
2> public_key:der_decode(‘SubjectPublicKeyInfo’, Encoded).
{‘SubjectPublicKeyInfo’,{‘PublicKeyAlgorithm’,{1,2,840,
10045,2,1},
{namedCurve,{1,3,132,0,34}}},
<<4,7,187,159,230,244,88,107,121,139,128,132,154,156,41,
218,110,252,32,77,113,43,240,245,31,30,…>>}
3>
PEncoded = public_key:der_encode(‘PrivateKeyInfo’,{‘PrivateKeyInfo’,v1,
{‘PrivateKeyInfo_privateKeyAlgorithm’,{1,3,101,112},asn1_NOVALUE},
<<4,32,233,181,192,232,242,61,135,51,157,56,189,189,150,53,204,72,177,206,
251,50,108,238,68,42,255,63,213,69,4,19,173,10>>,
asn1_NOVALUE}).
<<48,46,2,1,0,48,5,6,3,43,101,112,4,34,4,32,233,181,192,
232,242,61,135,51,157,56,189,189,150,…>>
4> public_key:der_decode(‘PrivateKeyInfo’, PEncoded).
{‘ECPrivateKey’,1,
<<233,181,192,232,242,61,135,51,157,56,189,189,150,53,204,
72,177,206,251,50,108,238,68,42,255,63,…>>,
{namedCurve,{1,3,101,112}},
asn1_NOVALUE,asn1_NOVALUE}
Thanks a lot! Just to be clear, I still see 10 test failures in Jose with this latest version, compared to 2 failures with 27.3.3. Plus, I need to change EncryptedPrivateKeyInfo_encryptionAlgorithm to EncryptionAlgorithmIdentifier to make it compile in the first place.
But if I understand correctly, at this point you believe that this change in OTP is what you want to ship and further changes should be on Jose’s side, to make it compatible with OTP28?
We are still investigating, so not sure yet. Do any of your tests that use jose fail?
Looks like we have no failures that could be linked directly to this change. make -C deps/rabbitmq_auth_backend_oauth2 ct-system gives me:
- no errors on OTP27
- 4 errors on OTP28-rc3, OTP28-rc4 and OTP from PR-9839
So it looks like we have some OTP28 work to do (we don’t run our test suites on OTP28 yet unfortunately) but nothing directly linked to the ASN.1 change.
1 Like
observer starts fine on final release (OTP 28.0) now. Thanks @dgud .
1 Like