Re: resumption problem
On Thu, Mar 26, 2020 at 12:40:08AM +, Jeremy Harris wrote: > Looks like I'm wrong, from the behaviour. > > It's the second of the possible places, and "i" is 129. > It appears to be failing the WPACKET_sub_allocate_bytes_u16() > call. %rsi before the call, which I think should be > the "namelen" arg, has value 172. Right, you're running out of space by trying to send too many CA names. It is better to have this fail, so you can figure what is trying to dump your entire trusted CA list (of names) to the server, than to actually have that silently "work". Now you need to find out why that's happening. Perhaps your "openssl.cnf" (Linux distro mistake?) causes the damage for all applications even without explicit code to that end in Exim? Or you're calling something to make it happen. -- Viktor.
Re: resumption problem
On 24/03/2020 20:25, Viktor Dukhovni wrote: >>> I'm guessing it is not the first. The second would an issue with a >>> particular issuer on the CA list (does Exim configure a list of CAs to >>> send to the server?), >> >> I don't think so Looks like I'm wrong, from the behaviour. It's the second of the possible places, and "i" is 129. It appears to be failing the WPACKET_sub_allocate_bytes_u16() call. %rsi before the call, which I think should be the "namelen" arg, has value 172. -- Cheers, Jeremy
Re: OpenSSL 111: authorityKeyIdentifier
Makes perfectly sense. Thank you.
> Am 25.03.2020 um 18:49 schrieb Viktor Dukhovni :
>
> On Wed, Mar 25, 2020 at 05:47:01PM +0100, Dirk wrote:
>
My expectation (maybe wrong) is that the serial and the issuer name belong
to
the same X509 certificate that the key id belongs to.
>>>
>>> Your expectation is "wrong". The issuer DN in the AKID is in fact
>>> supposed to be the issuer's issuer. It would be redundant to
>>> encode the issuer DN there, it is already present in the EE
>>> certificate.
>>
>> Thank you Victor. Can you point me to the rfc that defines this?
>
> You could just save time and take my word for it, based on the logical
> argument that the issuer public key is identified by the serial number
> and DN of the CA that signed its certificate (the combination required
> to be unique) and that repeating the EE issuer DN would be redundant.
> The text in RFC 5280 is not terribly clear, but is basically a brief
> restatement of X.509.
>
> If you really want to puzzle over more text see (page 24, physical page
> 34 of):
>
>http://handle.itu.int/11.1002/1000/9590-en?locatt=format:pdf
>
>8.2.2.1 Authority key identifier extension
>
>This field, which may be used as either a certificate extension or
>CRL extension, identifies the public key to be used to verify the
>signature on this certificate or CRL. It enables distinct keys used
>by the same CA to be distinguished (e.g., as key updating occurs).
>This field is defined as follows:
>
>authorityKeyIdentifier EXTENSION ::= {
>SYNTAX AuthorityKeyIdentifier IDENTIFIED BY
> id-ce-authorityKeyIdentifier
>}
>
>AuthorityKeyIdentifier ::= SEQUENCE {
>keyIdentifier [0] KeyIdentifier OPTIONAL
>authorityCertIssuer [1] GeneralNames OPTIONAL
>authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL }
>( WITH COMPONENTS {..., authorityCertIssuer PRESENT,
> authorityCertSerialNumber PRESENT} |
> WITH COMPONENTS {..., authorityCertIssuer ABSENT,
> authorityCertSerialNumber ABSENT} )
>
>KeyIdentifier ::= OCTET STRING
>
>The key may be identified by an explicit key identifier in the
>keyIdentifier component, by identification of a certificate for the
>key (giving certificate issuer in the authorityCertIssuer component
>and certificate serial number in the authorityCertSerialNumber
>component), or by both explicit key identifier and identification of
>a certificate for the key. If both forms of identification are used
>then the certificate or CRL issuer shall ensure they are consistent.
>A key identifier shall be unique with respect to all key identifiers
>for the issuing authority for the certificate or CRL containing the
>extension. An implementation which supports this extension is not
>required to be able to process all name forms in the
>authorityCertIssuer component. (See 8.3.2.1 for details of the
>GeneralNames type.)
>
>Certification authorities shall assign certificate serial numbers
>such that every (issuer, certificate serial number) pair uniquely
>identifies a single certificate. The keyIdentifier form can be used
>to select CA certificates during path construction. The
>authorityCertIssuer, authoritySerialNumber pair can only be used to
>provide preference to one certificate over others during path
>construction.
>
>This extension is always non-critical.
>
> --
>Viktor.
Re: OpenSSL 111: authorityKeyIdentifier
On Wed, Mar 25, 2020 at 05:47:01PM +0100, Dirk wrote:
> >> My expectation (maybe wrong) is that the serial and the issuer name belong
> >> to
> >> the same X509 certificate that the key id belongs to.
> >
> > Your expectation is "wrong". The issuer DN in the AKID is in fact
> > supposed to be the issuer's issuer. It would be redundant to
> > encode the issuer DN there, it is already present in the EE
> > certificate.
>
> Thank you Victor. Can you point me to the rfc that defines this?
You could just save time and take my word for it, based on the logical
argument that the issuer public key is identified by the serial number
and DN of the CA that signed its certificate (the combination required
to be unique) and that repeating the EE issuer DN would be redundant.
The text in RFC 5280 is not terribly clear, but is basically a brief
restatement of X.509.
If you really want to puzzle over more text see (page 24, physical page
34 of):
http://handle.itu.int/11.1002/1000/9590-en?locatt=format:pdf
8.2.2.1 Authority key identifier extension
This field, which may be used as either a certificate extension or
CRL extension, identifies the public key to be used to verify the
signature on this certificate or CRL. It enables distinct keys used
by the same CA to be distinguished (e.g., as key updating occurs).
This field is defined as follows:
authorityKeyIdentifier EXTENSION ::= {
SYNTAX AuthorityKeyIdentifier IDENTIFIED BY id-ce-authorityKeyIdentifier
}
AuthorityKeyIdentifier ::= SEQUENCE {
keyIdentifier [0] KeyIdentifier OPTIONAL
authorityCertIssuer [1] GeneralNames OPTIONAL
authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL }
( WITH COMPONENTS {..., authorityCertIssuer PRESENT,
authorityCertSerialNumber PRESENT} |
WITH COMPONENTS {..., authorityCertIssuer ABSENT,
authorityCertSerialNumber ABSENT} )
KeyIdentifier ::= OCTET STRING
The key may be identified by an explicit key identifier in the
keyIdentifier component, by identification of a certificate for the
key (giving certificate issuer in the authorityCertIssuer component
and certificate serial number in the authorityCertSerialNumber
component), or by both explicit key identifier and identification of
a certificate for the key. If both forms of identification are used
then the certificate or CRL issuer shall ensure they are consistent.
A key identifier shall be unique with respect to all key identifiers
for the issuing authority for the certificate or CRL containing the
extension. An implementation which supports this extension is not
required to be able to process all name forms in the
authorityCertIssuer component. (See 8.3.2.1 for details of the
GeneralNames type.)
Certification authorities shall assign certificate serial numbers
such that every (issuer, certificate serial number) pair uniquely
identifies a single certificate. The keyIdentifier form can be used
to select CA certificates during path construction. The
authorityCertIssuer, authoritySerialNumber pair can only be used to
provide preference to one certificate over others during path
construction.
This extension is always non-critical.
--
Viktor.
Re: OpenSSL 111: authorityKeyIdentifier
Thank you Victor. Can you point me to the rfc that defines this? Best Am 25.03.2020 um 15:32 schrieb Viktor Dukhovni : > > >> >> On Mar 24, 2020, at 11:12 AM, Dirk Menstermann wrote: >> >> My expectation (maybe wrong) is that the serial and the issuer name belong to >> the same X509 certificate that the key id belongs to. > > Your expectation is "wrong". The issuer DN in the AKID is in fact > supposed to be the issuer's issuer. It would be redundant to > encode the issuer DN there, it is already present in the EE > certificate. > > -- >Viktor. >
Re: New decode_errors due to EOF changes in master and 1.1.1e
Thanks. I'll try searching GH issues next time (or opening a new one?) rather than replying to a commit. On 3/25/20 2:37 AM, Matt Caswell wrote: > There is an ongoing discussion on this issue here: > > https://github.com/openssl/openssl/issues/11378 > > In the specific case of s_client/s_server this actually uncovered a bug > in s_server, which is why you see the problem there. > > Matt > > On 24/03/2020 23:35, John Baldwin wrote: >> I replied to the original commit on GH but haven't seen any responses so >> thought I would follow up here as well. >> >> https://github.com/openssl/openssl/pull/10907 >> >> After this PR was merged, I am now getting what look like spurious errors >> for a "normal" connection end. For example, if I run 'openssl s_client -msg' >> against an 'openssl s_server -www' instance, I now get this error at the >> end of the connection: >> >> >> >> > ??? [length 0005] >> 15 03 03 00 1a > TLS 1.2, Alert [length 0002], fatal decode_error >> 02 32 >> 34370928640:error:14095126:SSL routines:ssl3_read_n:unexpected eof while >> reading:/usr/src/crypto/openssl/ssl/record/rec_layer_s3.c:303: >> >> Note that unlike the description of the commit log, this is not a case of >> terminating the connection early via Ctrl-C. In this case, the remote >> end (server) has closed the connection normally after sending the requested >> file. The client then gets EOF when trying to read another SSL record after >> reading the last byte of the sent file. >> >> Is this the expected behavior? It sure gave me a head scratch as I first >> noticed this after rebasing a branch adding KTLS RX support for FreeBSD, and >> I >> thought it was a bug in my changes until I finally narrowed it back to this >> commit. It seems a bit odd for a normal close to trigger an error instead of >> a clean EOF back from SSL_read(). >> -- John Baldwin
Re: OpenSSL 111: authorityKeyIdentifier
> On Mar 24, 2020, at 11:12 AM, Dirk Menstermann wrote: > > My expectation (maybe wrong) is that the serial and the issuer name belong to > the same X509 certificate that the key id belongs to. Your expectation is "wrong". The issuer DN in the AKID is in fact supposed to be the issuer's issuer. It would be redundant to encode the issuer DN there, it is already present in the EE certificate. -- Viktor.
Ok but I try to connect and it doesn’t work ... and I try to ope ssl and it mantioned Thant I cant because of the reason 7
Re: New decode_errors due to EOF changes in master and 1.1.1e
There is an ongoing discussion on this issue here: https://github.com/openssl/openssl/issues/11378 In the specific case of s_client/s_server this actually uncovered a bug in s_server, which is why you see the problem there. Matt On 24/03/2020 23:35, John Baldwin wrote: > I replied to the original commit on GH but haven't seen any responses so > thought I would follow up here as well. > > https://github.com/openssl/openssl/pull/10907 > > After this PR was merged, I am now getting what look like spurious errors > for a "normal" connection end. For example, if I run 'openssl s_client -msg' > against an 'openssl s_server -www' instance, I now get this error at the > end of the connection: > > > > ??? [length 0005] > 15 03 03 00 1a TLS 1.2, Alert [length 0002], fatal decode_error > 02 32 > 34370928640:error:14095126:SSL routines:ssl3_read_n:unexpected eof while > reading:/usr/src/crypto/openssl/ssl/record/rec_layer_s3.c:303: > > Note that unlike the description of the commit log, this is not a case of > terminating the connection early via Ctrl-C. In this case, the remote > end (server) has closed the connection normally after sending the requested > file. The client then gets EOF when trying to read another SSL record after > reading the last byte of the sent file. > > Is this the expected behavior? It sure gave me a head scratch as I first > noticed this after rebasing a branch adding KTLS RX support for FreeBSD, and I > thought it was a bug in my changes until I finally narrowed it back to this > commit. It seems a bit odd for a normal close to trigger an error instead of > a clean EOF back from SSL_read(). >
Re: 3.0 FIPS related questions
On 24/03/2020 15:02, Salz, Rich wrote: > >>> The second question is somewhat related. Has there been a decision yet >> whether the FOM 3.0 will go through a 140-2 or a 140-3 validation? > >>We are going through 140-2. > > Has the list of validated platforms been made public yet? No, not yet. Although I don't see a great reason why they shouldn't be. I'll raise it and check everyone is happy to do so. > > For people using a different platform, will they still be able to claim > "vendor affirmed" if they follow particular build steps? > Yes, we believe this will remain as per the previous module. The build process will be different, but the ability to vendor affirm other platforms should remain. Matt
RE: RAND SEED in vxworks6.9
FYI: I restarted the discussion in #7946 https://github.com/openssl/openssl/issues/7946#issuecomment-603545804 Matthias
