Blumenthal, Uri - 0553 - MITLL wrote:
> Hmm... Registering an OID dedicated to express this case should be
> feasible, and perfectly within the ASN.1 rules. One question - where in
> the OID tree would it live, as offhand I don't have any idea. It can't
> be too deep down, and
Hmm... Registering an OID dedicated to express this case should be feasible,
and perfectly within the ASN.1 rules. One question - where in the OID tree
would it live, as offhand I don't have any idea. It can't be too deep down, and
also, it better be fairly short.
>From the ASN.1 point of
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of
> Viktor Dukhovni
> Sent: Thursday, March 21, 2019 14:07
> To: openssl-users@openssl.org
>
> > On Mar 21, 2019, at 1:57 PM, Viktor Dukhovni
> wrote:
> >
> >2. Emit a "harmless" default OID (such as 0.0), returning
> On Mar 21, 2019, at 1:57 PM, Viktor Dukhovni
> wrote:
>
>1. Return failure from i2d_ASN_OBJECT(), which then percolates
> up to failure to encode the containing structure.
>
>2. Emit a "harmless" default OID (such as 0.0), returning to
> the behaviour prior to 1.0.1i
>
First, let me prefix that while I don't want to badmouth anybody, even
incompetence cannot excuse deliberately generating bad/unparsable encoding.
That's one of the cases when the cure is clearly worse than the disease.
On 3/21/19, 13:58, "openssl-users on behalf of Viktor Dukhovni"
wrote:
On Thu, Mar 21, 2019 at 05:22:24PM +, Blumenthal, Uri - 0553 - MITLL wrote:
> > On the DER padding front, the minimal
> > working suffix is 7 bytes:
Apparently I can't count today, clearly the suffix is 8 bytes.
> >
> >30 03-- Length 3 sequence
> >06 01 00 -- OBJECT ID: 0.0
> >
+1 to Viktor's points.
Regards,
Uri
Sent from my iPhone
> On Mar 21, 2019, at 12:52, Viktor Dukhovni wrote:
>
> On Thu, Mar 21, 2019 at 01:00:14PM +, Salz, Rich via openssl-users wrote:
>
>>> This software however is 7 years old, we’re not in a position to drop
>>> everything and
On Thu, Mar 21, 2019 at 01:00:14PM +, Salz, Rich via openssl-users wrote:
> >This software however is 7 years old, we’re not in a position to drop
> > everything and rewrite it.
>
> Then don't upgrade? If it's for a CA you don't need TLS 1.3 for example.
>
> Or take the existing
>This software however is 7 years old, we’re not in a position to drop
> everything and rewrite it.
Then don't upgrade? If it's for a CA you don't need TLS 1.3 for example.
Or take the existing OpenSSL code that works and jam it into the current
release.
> On Mar 20, 2019, at 9:35 PM, Viktor Dukhovni
> wrote:
>
> Your github issue notes a change from 1.0.1 to 1.0.2, not a change
> within the 1.0.2 patch release series...
>
> Changes of behaviour between 1.0.1 and 1.0.2 were not off limits.
>
> When testing a short program to reproduce the
> On Mar 20, 2019, at 8:36 PM, Graham Leggett wrote:
>
> The problem seems that at some point during the 1.0.2 releases, the X509_REQ
> was previously serialised with what looks like an empty X509_ALGOR structure:
>
> 507:d=2 hl=2 l= 1 prim: OBJECT:itu-t
>
> and at some point
On 19 Mar 2019, at 18:00, Viktor Dukhovni wrote
:
> Well, the *standard* structure for passing around just the unsigned
> data underlying a CSR (X509_REQ), is a CertificationRequestInfo
> (X509_REQ_INFO). So if the modules are to use *standard* structures
> to communicate. The object being
On Tue, Mar 19, 2019 at 02:04:14PM +0200, Graham Leggett wrote:
> > Why do you need to do the encode and decode? What's wrong with the original
> > request object?
>
> The code is a modular ca, and different modules communicate with each other
> generically using the standard DER encoded
On 19 Mar 2019, at 03:22, Viktor Dukhovni wrote:
>> On Mar 18, 2019, at 8:22 PM, Graham Leggett wrote:
>>
>> How would I decode the X509_REQ_INFO structure on the other side, turning it
>> back into X509_REQ?
>
> The function returns the DER form of the CRI, which can then be signed.
> You
> On Mar 18, 2019, at 8:22 PM, Graham Leggett wrote:
>
> How would I decode the X509_REQ_INFO structure on the other side, turning it
> back into X509_REQ?
The function returns the DER form of the CRI, which can then be signed.
You can use d2i_X509_REQ_INFO() to get an X509_REQ_INFO, but
On 18 Mar 2019, at 22:02, Dave Coombs wrote:
>> This makes sense - however there don’t appear to be any APIs in openssl that
>> allow you to manipulate a X509_REQ_INFO structure. I can create it, and
>> encode/decode it, but there is no X509_REQ_INFO_get_subject_name() (or
>> friends) to
On 18 Mar 2019, at 22:27, Viktor Dukhovni wrote:
>> (Even in the 1.1 API, where they are opaque, i2d_re_X509_REQ_tbs will encode
>> a given X509_REQ's X509_REQ_INFO for you.)
>
> Yes, i2d_re_X509_REQ_tbs is the key function for constructing the
> "to be signed" (tbs) request:
>
> int
> On Mar 18, 2019, at 4:02 PM, Dave Coombs wrote:
>
> (Even in the 1.1 API, where they are opaque, i2d_re_X509_REQ_tbs will encode
> a given X509_REQ's X509_REQ_INFO for you.)
Yes, i2d_re_X509_REQ_tbs is the key function for constructing the
"to be signed" (tbs) request:
int
> This makes sense - however there don’t appear to be any APIs in openssl that
> allow you to manipulate a X509_REQ_INFO structure. I can create it, and
> encode/decode it, but there is no X509_REQ_INFO_get_subject_name() (or
> friends) to populate the structure. X509_REQ_INFO itself is opaque.
On 18 Mar 2019, at 18:49, Viktor Dukhovni wrote:
> A mandatory part of the CSR is missing. It is malformed.
Some further digging shows the CSR is indeed malformed - the old openssl code
created a CSR like this:
507:d=2 hl=2 l= 1 prim: OBJECT:itu-t
while the new openssl code
> On Mar 18, 2019, at 6:51 AM, Graham Leggett wrote:
>
> The CSR is incomplete, but isn’t malformed.
A mandatory part of the CSR is missing. It is malformed.
> The CSR is the in the process of being built. Part of that process involves
> sending the partially complete CSR to another
On 18 Mar 2019, at 12:51, Graham Leggett wrote:
>> which has a non-zero length signature algorithm OID (l = 9). Your
>> example has "l=0" where one would expect the signature OID after
>> the extensions.
>
> How do I fix openssl to parse this as it did before?
I've raised this at
On 18 Mar 2019, at 04:55, Viktor Dukhovni wrote:
> On Mon, Mar 18, 2019 at 01:06:19AM +0200, Graham Leggett wrote:
>
>> [root@localhost ~]# openssl req -in req.bin -inform der
>> unable to load X509 request
>> 139903756527504:error:0D0C40D8:asn1 encoding
>> routines:c2i_ASN1_OBJECT:invalid
On Mon, Mar 18, 2019 at 01:06:19AM +0200, Graham Leggett wrote:
> [root@localhost ~]# openssl req -in req.bin -inform der
> unable to load X509 request
> 139903756527504:error:0D0C40D8:asn1 encoding routines:c2i_ASN1_OBJECT:invalid
> object encoding:a_object.c:287:
>
Hi all,
While porting some code across from RHEL6 (openssl-1.0.1e-42) to RHEL7
(openssl-1.0.2k-16), I am getting the failure below where previously the code
worked.
The code creates an X509_REQ, populates it, and then passes this to a module.
Before passing it to the module, the structure is
25 matches
Mail list logo
