Re: Timestamp validation checks critical flag on EKU
Christian:
No, RFC 5280 does not obsolete RFC 3161. RFC 5280 obsoletes RFCs 3280, 4325,
and 4630.
Anyway, RFC 5280 and RFC 3161 are consistent.
RFC 5280 says that the certificate issuer can make the EKU extension critical
or non-critical.
RFC 3161 says that for use with the Time-Stamp Protocol, the certificate issuer
MUST make the EKU extension critical, and it MUST contain id-kp-timeStamping.
Russ
> On Jan 28, 2022, at 9:56 AM, we...@infotech.de wrote:
>
> Dear Russ,
>
> thanks for your reply.
>
> OK, i got it, but RFC 5280 obsoletes RFC 3161 and says:
>
> 4.2.1.12 <https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.12>.
> Extended Key Usage
>
>This extension indicates one or more purposes for which the certified
>public key may be used, in addition to or in place of the basic
>purposes indicated in the key usage extension. In general, this
>extension will appear only in end entity certificates. This
>extension is defined as follows:
>
>id-ce-extKeyUsage OBJECT IDENTIFIER ::= { id-ce 37 }
>
>ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId
>
>KeyPurposeId ::= OBJECT IDENTIFIER
>
>Key purposes may be defined by any organization with a need. Object
>identifiers used to identify key purposes MUST be assigned in
>accordance with IANA or ITU-T Recommendation X.660 [X.660
> <https://datatracker.ietf.org/doc/html/rfc5280#ref-X.660>].
>
>This extension MAY, at the option of the certificate issuer, be
>either critical or non-critical.
>
>If the extension is present, then the certificate MUST only be used
>for one of the purposes indicated. If multiple purposes are
>indicated the application need not recognize all purposes indicated,
>as long as the intended purpose is present. Certificate using
>applications MAY require that the extended key usage extension be
>present and that a particular purpose be indicated in order for the
>certificate to be acceptable to that application.
>
> So what?
>
> BTW: The further obsoletions RFC i.e. Updated by: 6818
> <https://datatracker.ietf.org/doc/html/rfc6818>, 8398
> <https://datatracker.ietf.org/doc/html/rfc8398>, 8399
> <https://datatracker.ietf.org/doc/html/rfc8399>
> do not affect RCF 5280 in this matter.
>
> The main question remains: How to handle this issue?
>
> Thanks In Advance
> --
> Christian Weber
> Am 28.01.2022 um 13:58 schrieb Russ Housley:
>> RFC 3161 says:
>>
>> 2.3. Identification of the TSA
>>
>>The TSA MUST sign each time-stamp message with a key reserved
>>specifically for that purpose. A TSA MAY have distinct private keys,
>>e.g., to accommodate different policies, different algorithms,
>>different private key sizes or to increase the performance. The
>>corresponding certificate MUST contain only one instance of the
>>extended key usage field extension as defined in [RFC2459] Section
>>4.2.1.13 with KeyPurposeID having value:
>>
>>id-kp-timeStamping. This extension MUST be critical.
>>
>>The following object identifier identifies the KeyPurposeID having
>>value id-kp-timeStamping.
>>
>>id-kp-timeStamping OBJECT IDENTIFIER ::= {iso(1)
>>identified-organization(3) dod(6)
>>internet(1) security(5) mechanisms(5) pkix(7)
>>kp (3) timestamping (8)}
>>
>>
>>> On Jan 28, 2022, at 6:25 AM, we...@infotech.de <mailto:we...@infotech.de>
>>> wrote:
>>>
>>> Dear OpenSSL users,
>>>
>>> recently we checked an older timestamp using the OpenSSL Library version
>>> 1.1.1i.
>>> The check revealed, that the timestamp verification failed.
>>>
>>> Digging into the code we found that if an eku entry for timestamping is
>>> preset
>>> it is expected to be marked critical (see v3_purp.c:798 ff.).
>>>
>>> Thats's not the case for the timetamp cert in use.
>>>
>>> We couldn'f find any source that enforces the critical flag on eku
>>> timestamp entries.
>>> RFC 5280 says, that makring the EKU as critical is deliberate tu the issuer.
>>>
>>> Any thoughts or pointer to the mentioned requirement?
>>>
>>> Thanks in advance
>>> --
>>> Christian Weber
>
> --
> Christian Weber
> Entwicklung - Verteilte Systeme
> mailto:we...@infotech.de <mailto:we...@infotech.de>
> --
> Infotech Gesellschaft für
> Informations- und Datentechnik mbH
> Tel. +49-2361-9130-0
> Fax +49-2361-9130-105
>
> Geschäftsführer
> Rainer Hans
>
> Gerichtsstand Recklinghausen
> Amtsgericht Recklinghausen HRB 1912
> USt.-IdNr. DE-811565628
Re: Timestamp validation checks critical flag on EKU
RFC 3161 says:
2.3. Identification of the TSA
The TSA MUST sign each time-stamp message with a key reserved
specifically for that purpose. A TSA MAY have distinct private keys,
e.g., to accommodate different policies, different algorithms,
different private key sizes or to increase the performance. The
corresponding certificate MUST contain only one instance of the
extended key usage field extension as defined in [RFC2459] Section
4.2.1.13 with KeyPurposeID having value:
id-kp-timeStamping. This extension MUST be critical.
The following object identifier identifies the KeyPurposeID having
value id-kp-timeStamping.
id-kp-timeStamping OBJECT IDENTIFIER ::= {iso(1)
identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7)
kp (3) timestamping (8)}
> On Jan 28, 2022, at 6:25 AM, we...@infotech.de wrote:
>
> Dear OpenSSL users,
>
> recently we checked an older timestamp using the OpenSSL Library version
> 1.1.1i.
> The check revealed, that the timestamp verification failed.
>
> Digging into the code we found that if an eku entry for timestamping is preset
> it is expected to be marked critical (see v3_purp.c:798 ff.).
>
> Thats's not the case for the timetamp cert in use.
>
> We couldn'f find any source that enforces the critical flag on eku timestamp
> entries.
> RFC 5280 says, that makring the EKU as critical is deliberate tu the issuer.
>
> Any thoughts or pointer to the mentioned requirement?
>
> Thanks in advance
> --
> Christian Weber
Re: ASN1 <-> DER encoding with application tag
The data is not correct if it supposed to match RFC 2743.
The first byte is [APPLICATION 0]. That seems fine.
The second byte provides a length for the full SEQUENCE. It says there are 126
bytes, but you do not have that many.
Russ
> On Nov 4, 2021, at 10:18 AM, Max Larsson wrote:
>
> Hi Russ,
>
> do you mean that the DER data
>
> 0x60 0x7e 0x06 0x06 0x2b 0x06 0x01 0x05 0x05 0x02 0xa0 0x74
>
> is wrong?
>
> If so, that DER data have I captured with wireshark from an smb2 session
> setup request.
> and that’s even I try to decode with help of openssl. If the case is that
> that data is wrongly,
> is there a way to get decode with openssl anyway?
>
> Max
>
> From: Russ Housley mailto:hous...@vigilsec.com>>
> Date: Thursday, 4. November 2021 at 15:08
> To: Max Larsson <mailto:max.lars...@facilityboss.biz>>
> Cc: openssl-users@openssl.org <mailto:openssl-users@openssl.org>
> mailto:openssl-users@openssl.org>>
> Subject: Re: ASN1 <-> DER encoding with application tag
>
> RFC 2743 shows this structure:
> MechType ::= OBJECT IDENTIFIER
> -- data structure definitions
> -- callers must be able to distinguish among
> -- InitialContextToken, SubsequentContextToken,
> -- PerMsgToken, and SealedMessage data elements
> -- based on the usage in which they occur
>
> InitialContextToken ::=
> -- option indication (delegation, etc.) indicated within
> -- mechanism-specific token
> [APPLICATION 0] IMPLICIT SEQUENCE {
> thisMech MechType,
> innerContextToken ANY DEFINED BY thisMech
> -- contents mechanism-specific
> -- ASN.1 structure not required
> }
> The encoded data that you provided dies begin with the [APPLICATION 0] tag,
> then it if followed by by the { 1 3 6 1 5 5 2 } object identifier.
>
> Russ
>
>
> On Nov 4, 2021, at 9:58 AM, Max Larsson <mailto:max.lars...@facilityboss.biz>> wrote:
>
> Hi everyone,
>
> I’m trying to decode and encode Der structure. In my case that are DER
> encoded GSSAPI structure.
>
> My DER encoded data looks like this (stripped the pending bytes):
>
> 0x60 0x7e 0x06 0x06 0x2b 0x06 0x01 0x05 0x05 0x02 0xa0 0x74
>
> My ANS1 definition in my source look like this:
>
> typedef struct ContextToken_st {
> ASN1_OBJECT *mech;
> ASN1_OCTET_STRING *innerContextToken;
> } GSSAPI_CONTEXTTOKEN;
>
> DECLARE_ASN1_FUNCTIONS( GSSAPI_CONTEXTTOKEN )
>
> ASN1_SEQUENCE( GSSAPI_CONTEXTTOKEN ) = {
> ASN1_SIMPLE( GSSAPI_CONTEXTTOKEN, mech, ASN1_OBJECT ),
> ASN1_SIMPLE( GSSAPI_CONTEXTTOKEN, innerContextToken, ASN1_OCTET_STRING )
> } ASN1_SEQUENCE_END( GSSAPI_CONTEXTTOKEN )
>
> IMPLEMENT_ASN1_FUNCTIONS( GSSAPI_CONTEXTTOKEN )
>
> Parsing the above DER data fails, so I decided to encode a own Der structure,
> to see where the difference is with my setup:
>
> . . .
> negToken = GSSAPI_CONTEXTTOKEN_new();
> if( negToken != NULL ) {
> negToken->mech = OBJ_txt2obj( "1.3.6.1.5.5.2",0 );
> negToken->innerContextToken = ASN1_OCTET_STRING_new();
>
> const unsigned char mechToken[] = "\xa0\x74\x30 // … stripped for
> readability
>
> const size_t mechTokenSize = sizeof( mechToken ) - 1;
> printf( "Size of inner token: %zu\n",mechTokenSize );
> ASN1_OCTET_STRING_set(
> negToken->innerContextToken,mechToken,mechTokenSize );
>
> buffer = NULL;
> size_t bufferSize = i2d_GSSAPI_CONTEXTTOKEN( negToken,NULL );
>
> printf( "Required buffer size for DER encoding of ASN1 structure:
> %zu\n",bufferSize );
>
> unsigned char *buffer = malloc( bufferSize );
> unsigned char *p = buffer;
> i2d_GSSAPI_CONTEXTTOKEN( negToken,&p );
>
> for( int len = 0;len < bufferSize;len++ ) {
> if( ( len % 8 ) == 0 )
> printf( " " );
> if( ( len % 16 ) == 0 )
> printf( "\n\t\t" );
> printf( " 0x%02x",(short)buffer[ len ] );
> }
> printf( "\n" );
> . . .
>
> The code above output the following DER encoded structure (the difference
> marled in bold):
>
> 0x30 0x81 0x80 0x06 0x06 0x2b 0x06 0x01 0x05 0x05 0x02 0x04 0x76 0xa0 0x74
>
> The google result, which I found seems to point into the direction to use
> application tags to encode.
>
> But I haven’t found any example or how to how to achieve this with openssl,
> can an
Re: ASN1 <-> DER encoding with application tag
RFC 2743 shows this structure:
MechType ::= OBJECT IDENTIFIER
-- data structure definitions
-- callers must be able to distinguish among
-- InitialContextToken, SubsequentContextToken,
-- PerMsgToken, and SealedMessage data elements
-- based on the usage in which they occur
InitialContextToken ::=
-- option indication (delegation, etc.) indicated within
-- mechanism-specific token
[APPLICATION 0] IMPLICIT SEQUENCE {
thisMech MechType,
innerContextToken ANY DEFINED BY thisMech
-- contents mechanism-specific
-- ASN.1 structure not required
}
The encoded data that you provided dies begin with the [APPLICATION 0] tag,
then it if followed by by the { 1 3 6 1 5 5 2 } object identifier.
Russ
> On Nov 4, 2021, at 9:58 AM, Max Larsson wrote:
>
> Hi everyone,
>
> I’m trying to decode and encode Der structure. In my case that are DER
> encoded GSSAPI structure.
>
> My DER encoded data looks like this (stripped the pending bytes):
>
> 0x60 0x7e 0x06 0x06 0x2b 0x06 0x01 0x05 0x05 0x02 0xa0 0x74
>
> My ANS1 definition in my source look like this:
>
> typedef struct ContextToken_st {
> ASN1_OBJECT *mech;
> ASN1_OCTET_STRING *innerContextToken;
> } GSSAPI_CONTEXTTOKEN;
>
> DECLARE_ASN1_FUNCTIONS( GSSAPI_CONTEXTTOKEN )
>
> ASN1_SEQUENCE( GSSAPI_CONTEXTTOKEN ) = {
> ASN1_SIMPLE( GSSAPI_CONTEXTTOKEN, mech, ASN1_OBJECT ),
> ASN1_SIMPLE( GSSAPI_CONTEXTTOKEN, innerContextToken, ASN1_OCTET_STRING )
> } ASN1_SEQUENCE_END( GSSAPI_CONTEXTTOKEN )
>
> IMPLEMENT_ASN1_FUNCTIONS( GSSAPI_CONTEXTTOKEN )
>
> Parsing the above DER data fails, so I decided to encode a own Der structure,
> to see where the difference is with my setup:
>
> . . .
> negToken = GSSAPI_CONTEXTTOKEN_new();
> if( negToken != NULL ) {
> negToken->mech = OBJ_txt2obj( "1.3.6.1.5.5.2",0 );
> negToken->innerContextToken = ASN1_OCTET_STRING_new();
>
> const unsigned char mechToken[] = "\xa0\x74\x30 // … stripped for
> readability
>
> const size_t mechTokenSize = sizeof( mechToken ) - 1;
> printf( "Size of inner token: %zu\n",mechTokenSize );
> ASN1_OCTET_STRING_set(
> negToken->innerContextToken,mechToken,mechTokenSize );
>
> buffer = NULL;
> size_t bufferSize = i2d_GSSAPI_CONTEXTTOKEN( negToken,NULL );
>
> printf( "Required buffer size for DER encoding of ASN1 structure:
> %zu\n",bufferSize );
>
> unsigned char *buffer = malloc( bufferSize );
> unsigned char *p = buffer;
> i2d_GSSAPI_CONTEXTTOKEN( negToken,&p );
>
> for( int len = 0;len < bufferSize;len++ ) {
> if( ( len % 8 ) == 0 )
> printf( " " );
> if( ( len % 16 ) == 0 )
> printf( "\n\t\t" );
> printf( " 0x%02x",(short)buffer[ len ] );
> }
> printf( "\n" );
> . . .
>
> The code above output the following DER encoded structure (the difference
> marled in bold):
>
> 0x30 0x81 0x80 0x06 0x06 0x2b 0x06 0x01 0x05 0x05 0x02 0x04 0x76 0xa0 0x74
>
> The google result, which I found seems to point into the direction to use
> application tags to encode.
>
> But I haven’t found any example or how to how to achieve this with openssl,
> can anyone give me sone hints?
>
>
> Best regards
>
> Max Larsson
> Mit freundlichen Grüßen
> Best regards
>
> Dipl.-Inform. Max Larsson
> Geschäftsleitung
>
> phone: +49(0)6151/62908-75
> fax:
> email: max.lars...@facilityboss.biz
> web: http://facilityboss.biz
Re: Encoding of AlgorithmIdentifier with NULL parameters
RFC 4055 says:
The object identifier used to identify the PKCS #1 version 1.5
signature algorithm with SHA-224 is:
sha224WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 14 }
The object identifier used to identify the PKCS #1 version 1.5
signature algorithm with SHA-256 is:
sha256WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 11 }
The object identifier used to identify the PKCS #1 version 1.5
signature algorithm with SHA-384 is:
sha384WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 12 }
The object identifier used to identify the PKCS #1 version 1.5
signature algorithm with SHA-512 is:
sha512WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 13 }
When any of these four object identifiers appears within an
AlgorithmIdentifier, the parameters MUST be NULL. Implementations
MUST accept the parameters being absent as well as present.
So, when generating the certificate, the NULL ought to be there.
Also, when validating, the code should be forgiving about it not being there.
Russ
> On Jan 28, 2021, at 2:07 PM, Thulasi Goriparthi
> wrote:
>
> I am trying to provide a test certificate generated by openssl-3.0.0-alpha10
> to a third party certificate parser/manager. This software expects
> AlgorithmIdentifier to either have parameters or to have null encoded (05 00)
> parameters which seems to be missing in the certificate.
>
> Certificate generated by openssl-3.0.0-alpha10
>
> 0:d=0 hl=4 l=1030 cons: SEQUENCE
> 4:d=1 hl=4 l= 752 cons: SEQUENCE
> 8:d=2 hl=2 l= 3 cons: cont [ 0 ]
>10:d=3 hl=2 l= 1 prim: INTEGER :02
>13:d=2 hl=2 l= 1 prim: INTEGER :01
>16:d=2 hl=2 l= 11 cons: SEQUENCE
>18:d=3 hl=2 l= 9 prim: OBJECT:sha256WithRSAEncryption
>29:d=2 hl=3 l= 143 cons: SEQUENCE
>32:d=3 hl=2 l= 11 cons: SET
>34:d=4 hl=2 l= 9 cons: SEQUENCE
>36:d=5 hl=2 l= 3 prim: OBJECT:countryName
>
> Certificate generated by openssl-1.1.1g
>
> 0:d=0 hl=4 l= 988 cons: SEQUENCE
> 4:d=1 hl=4 l= 708 cons: SEQUENCE
> 8:d=2 hl=2 l= 3 cons: cont [ 0 ]
>10:d=3 hl=2 l= 1 prim: INTEGER :02
>13:d=2 hl=2 l= 1 prim: INTEGER :01
>16:d=2 hl=2 l= 13 cons: SEQUENCE
>18:d=3 hl=2 l= 9 prim: OBJECT:sha256WithRSAEncryption
>29:d=3 hl=2 l= 0 prim: NULL
>31:d=2 hl=3 l= 143 cons: SEQUENCE
>34:d=3 hl=2 l= 11 cons: SET
>36:d=4 hl=2 l= 9 cons: SEQUENCE
>38:d=5 hl=2 l= 3 prim: OBJECT:countryName
>
> From https://tools.ietf.org/html/rfc5280#section-4.1.1.2
> , It isn't clear if NULL
> parameters can be completely omitted or if it should still have NULL encoding.
>
> Is this a too stringent check in the third-party s/w or a miss in
> openss-3.0.0-alpha10?
>
> Thanks,
> Thulasi.
Re: Parsing and generating CBOR certificates?
Uri: > > Unfortunately, there's no ASN.1 -> CBOR codec generator, AFAIK, which is why > I'm asking here. Nope, and if there were, it would not generate the same result as the compressions routines that Ben referenced. Russ
RSA-OAEP Certificate
I am looking a test certificate that contains an RSA-OAEP subject public key (OID = id-RSAES-OAEP from RFC 4055) and is signed with RSA-PSS (OID = id-RSASSA-PSS also from RFC 4055). I have not ben able to find a way to generate such a certificate with OpenSSL. If you have a pointer to such a certificate or a recipe for generating one, I would appreciate the pointer. Russ
