Certificate format question?

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Certificate format question?

Scott Neugroschl-2

I tried googling, but couldn’t find an answer to this…

 

I came across a certificate that had some text garbage before the ---- BEGIN CERTIFICATE ---- line.

 

I know that the cert is defined as the data between the delimiters.  Do the specs say anything about data before the BEGIN delimiter?  Would a certificate with such data be valid?  I know OpenSSL accepts such a cert, but is this an extension, or is it explicitly permitted by the standards/specifications?

 

Thanks

 


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Certificate format question?

Viktor Dukhovni


> On Sep 24, 2018, at 6:25 PM, Scott Neugroschl <[hidden email]> wrote:
>
> I tried googling, but couldn’t find an answer to this…
>  
> I came across a certificate that had some text garbage before the ---- BEGIN CERTIFICATE ---- line.
>  
> I know that the cert is defined as the data between the delimiters.  Do the specs say anything about data before the BEGIN delimiter?  Would a certificate with such data be valid?  I know OpenSSL accepts such a cert, but is this an extension, or is it explicitly permitted by the standards/specifications?

https://tools.ietf.org/html/rfc7468#section-2

--
        Viktor.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Certificate format question?

Scott Neugroschl-2



>On Sept 24, 2018, at 3:55 PM, Viktor Dukhovni wrote:
>> On Sep 24, 2018, at 6:25 PM, Scott Neugroschl <[hidden email]>> wrote:
>>
>> I tried googling, but couldn’t find an answer to this…
>>  
>> I came across a certificate that had some text garbage before the ---- BEGIN CERTIFICATE ---- line.
>>  
>> I know that the cert is defined as the data between the delimiters.  Do the specs say anything about data before the BEGIN
>>delimiter?  Would a certificate with such data be valid?  I know OpenSSL accepts such a cert, but is this an extension, or is it

>>explicitly permitted by the standards/specifications?

>https://tools.ietf.org/html/rfc7468#section-2

Thanks, Viktor, appreciated.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Certificate format question?

Hubert Kario
In reply to this post by Viktor Dukhovni
On Tuesday, 25 September 2018 00:55:16 CEST Viktor Dukhovni wrote:

> > On Sep 24, 2018, at 6:25 PM, Scott Neugroschl <[hidden email]> wrote:
> >
> > I tried googling, but couldn’t find an answer to this…
> >
> > I came across a certificate that had some text garbage before the ----
> > BEGIN CERTIFICATE ---- line.
> >
> > I know that the cert is defined as the data between the delimiters.  Do
> > the specs say anything about data before the BEGIN delimiter?  Would a
> > certificate with such data be valid?  I know OpenSSL accepts such a cert,
> > but is this an extension, or is it explicitly permitted by the
> > standards/specifications?
> https://tools.ietf.org/html/rfc7468#section-2
then it looks like the parser used in asn1parse -inform pem is non-
compliant...

https://github.com/openssl/openssl/issues/7317

--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Certificate format question?

Viktor Dukhovni
That particular parser tries to parse an arbitrary single
PEM-encoded object, rather than a first object of a particular
type (as with "pkey", "req", "x509", ...).  The code for that
is more specialized, and does support leading free-form text.

While it could skip to the first boundary, and a well written
pull request would be welcome, it is not critical for asn1parse
to be able to ignore free-form text above the PEM object.

In the meantime:

   $ perl -ne 'print if (/^-----BEGIN/../^-----END/);' foo.pem |
       openssl asn1parse

> On Sep 25, 2018, at 1:15 PM, Hubert Kario <[hidden email]> wrote:
>
> then it looks like the parser used in asn1parse -inform pem is non-
> compliant...
>
> https://github.com/openssl/openssl/issues/7317

--
        Viktor.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Certificate format question?

Steffen Nurpmeso-2
Viktor Dukhovni wrote in <[hidden email]>:
 |That particular parser tries to parse an arbitrary single
 |PEM-encoded object, rather than a first object of a particular
 |type (as with "pkey", "req", "x509", ...).  The code for that
 |is more specialized, and does support leading free-form text.
 |
 |While it could skip to the first boundary, and a well written
 |pull request would be welcome, it is not critical for asn1parse
 |to be able to ignore free-form text above the PEM object.
 |
 |In the meantime:
 |
 |   $ perl -ne 'print if (/^-----BEGIN/../^-----END/);' foo.pem |
 |       openssl asn1parse

The RFC 7468 term "parsers SHOULD ignore whitespace and other non-
base64 characters" makes me wonder.  I know (or used to know) that
the OpenSSL base64 decoder is (or was) pretty bad in doing so.
But this RFC is about PKIX specifics, of course, yet i (as a MUA
maintainer) struggled with how to deal with embedded data in
base64 encodings, and this RFC seems to explicitly allow them.
And i struggled because i have seen mail messages with data
embedded in base64; the rewrite of the MIME encoder (MUA commit
[d91a4bd0]), necessary to deal with those sequences. says a. o.:

    In both cases: except that we, due to lack of a context, cannot
    give an error message, say, once per handled message.  I.e., we
    cannot provide any error logging in order to avoid a possibly
    infinite amount of such messages.
   
    Regarding the garbage in base64 parts that we now simply skip.
    I mean, it is possible to embed abuse porn or similar shit in
    between the valid data, and now we _also_ simply skip over the
    "garbage", silently extraditing our users to automatic parsers
    which may gobble that s..t!

Also because the mutt(1) MUA is pretty good in skipping over
things.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Certificate format question?

Scott Neugroschl-2
Steffen Nurpmeso, Tuesday, September 25, 2018 11:57 AM


> The RFC 7468 term "parsers SHOULD ignore whitespace and other non-
>base64 characters" makes me wonder.  

The relevant clause is a few sentences up: "Data before the encapsulation boundaries are
permitted, and parsers MUST NOT malfunction when processing such data.


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Certificate format question?

Dr. Matthias St. Pierre
In reply to this post by Viktor Dukhovni


> -----Ursprüngliche Nachricht-----
> In the meantime:
>
>    $ perl -ne 'print if (/^-----BEGIN/../^-----END/);' foo.pem |
>        openssl asn1parse
>
> > On Sep 25, 2018, at 1:15 PM, Hubert Kario <[hidden email]> wrote:
> >
> > then it looks like the parser used in asn1parse -inform pem is non-
> > compliant...
> >
> > https://github.com/openssl/openssl/issues/7317

Starting with version 1.1.0, the asn1parse has the -strictpem option to deal
with exactly this case.

I just submitted a pull request on GitHub which attempts to make RFC compliance
the default behavior and introduces a new '-inform b64' option for raw base64
parsing.

        https://github.com/openssl/openssl/pull/7320

I would be interested in your (the users) opinion about whether this should
become the new default in the future, or whether raw base64 parsing should
remain the default.

Matthias

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Certificate format question?

Steffen Nurpmeso-2
In reply to this post by Scott Neugroschl-2
Scott Neugroschl wrote in <MWHPR18MB140782617FE4CBB9BD21330897160@MWHPR1\
8MB1407.namprd18.prod.outlook.com>:
 |Steffen Nurpmeso, Tuesday, September 25, 2018 11:57 AM
 |> The RFC 7468 term "parsers SHOULD ignore whitespace and other non-
 |>base64 characters" makes me wonder.  
 |
 |The relevant clause is a few sentences up: "Data before the encapsulation \
 |boundaries are
 |permitted, and parsers MUST NOT malfunction when processing such data.

Ok i thought a day, but now i came to the conclusion that it would
make sense to admit that i fail to see any interrelation between
the two sentences, nor the problem (what methinks) as such.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users