I have an ECDSA signature supplied to me as R and S byte arrays and
lengths (from an HSM).
How do I add them to the X509 structure?
Is there an API, a set of calls, or do you have any hints?
~~
For RSA, I simply filled in the ASN1_BIT_STRING length, data, and flags,
but an RSA signature is
On 8/16/19 12:34 PM, Erwann Abalea wrote:
Bonjour,
Having a critical extension adds 3 octets (the BOOLEAN tag, length=1,
value=0xff). It may, as a side effect, enlarge the number of octets necessary
to encode some structure size.
Remove the 2 Netscape extensions, they're way obsolete
Bonjour,
Having a critical extension adds 3 octets (the BOOLEAN tag, length=1,
value=0xff). It may, as a side effect, enlarge the number of octets necessary
to encode some structure size.
Remove the 2 Netscape extensions, they're way obsolete (don't know why OpenSSL
keeps them by default).
Viktor,
On 8/16/19 8:41 AM, Viktor Dukhovni wrote:
On Aug 16, 2019, at 6:13 AM, Salz, Rich via openssl-users
wrote:
subjectAltName is rarely marked as critical; sec 4.2.1.6 of PKIX says "SHOULD mark
subjectAltName as non-critical"
This is wrong. When the subject DN is empty, the
> On Aug 16, 2019, at 6:13 AM, Salz, Rich via openssl-users
> wrote:
>
> subjectAltName is rarely marked as critical; sec 4.2.1.6 of PKIX says "SHOULD
> mark subjectAltName as non-critical"
This is wrong. When the subject DN is empty, the subjectAltName should be
marked as critical. IIRC
On 8/16/19 5:44 AM, Dr Paul Dale wrote:
I investigated HAVEGE fairly deeply a couple of years ago. I am
completely in agreement with the basis of this source, however the
sticking point was the “expansion” phase. Essentially, every bit of
entropy gathered is turned into (just under) thirty
On 8/16/19 7:58 AM, Salz, Rich wrote:
In the same paragraph, the sentence before the one you're quoting says "If the
subject field contains an empty sequence, then the issuing CA MUST include a
subjectAltName extension that is marked as critical."
I will run another test today
>In the same paragraph, the sentence before the one you're quoting says "If
> the subject field contains an empty sequence, then the issuing CA MUST
> include a subjectAltName extension that is marked as critical."
>It's not possible to have a missing subject name in a certificate,
* Honestly, I’d like to add CPU Jitter to OpenSSL as one of its default
entropy sources.
* I dread the effort that this would entail.
Open an issue and maybe someone with an older platform will work on doing it.
I don’t think the project has any need to support such things. (Members of
Not just dedicated black box rngs in verious chips (such as
multifunction I/O chips or the old Intel BIOS chip), but also
general hardware that happens to have plenty of inherent
randomness due to its design or implementation.
The simple easy to add RNG circuits include some completely
open
I agree. Using internal hardware in the processor for entropy depends on
everything. Each processor needs to be independently quantified and not doing
so becomes a risk assessment.
As for hardware sources, they are essentially black boxes and could contain
anything. It is extremely
Bonjour,
In the same paragraph, the sentence before the one you're quoting says "If the
subject field contains an empty sequence, then the issuing CA MUST include a
subjectAltName extension that is marked as critical."
It's not possible to have a missing subject name in a certificate, the
from the git repo of cpu jitter i see few files only so may be easy to
compile at least.
Yeah it can be added to openssl source with macro to enable it.
On Fri, Aug 16, 2019 at 4:05 PM Dr Paul Dale wrote:
> Honestly, I’d like to add CPU Jitter to OpenSSL as one of its default
> entropy
[Top posting for consistency]
More than OS dependency, this depends on the exact hardware on the platform:
CPU, support chips, peripheral chips. Usually some of these can provide
much more randomness than the highly predictable time of day/year RTC clock.
And if none do, there are simple RNG
Thanks Pauli,
I did checked CPU Jitter and it looks promising. It has openssl engine
support too.
So i guess I have to add this add provide OS specific calls and it should
work.
Will keep you posted.
Thanks,
On Fri, Aug 16, 2019 at 3:15 PM Dr Paul Dale wrote:
> I investigated HAVEGE fairly
I investigated HAVEGE fairly deeply a couple of years ago. I am completely in
agreement with the basis of this source, however the sticking point was the
“expansion” phase. Essentially, every bit of entropy gathered is turned into
(just under) thirty two bits of “entropy”. This is logically
Two bits of RTC is nowhere near enough entropy. I could break two bits by hand
in a few seconds — there are only four possibilities.
The best outcome is an hardware random number generator. These are often not
readily available.
Next would be waiting for enough entropy from interrupts,
On 8/16/19 5:26 AM, Chitrang Srivastava wrote:
Hi,
I am working on an embedded platform and now ported openssl 1.1.1b
TLS 1.2/1.3 is working fine.
While analysing random number , Rand pool initialization calls where I
am returning like this ,
size_t *rand_pool_acquire_entropy*(RAND_POOL
Hi,
I am working on an embedded platform and now ported openssl 1.1.1b
TLS 1.2/1.3 is working fine.
While analysing random number , Rand pool initialization calls where I am
returning like this ,
size_t *rand_pool_acquire_entropy*(RAND_POOL *pool)
{
return
19 matches
Mail list logo
