New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problem with parsing validity times #499

Closed
brueggemann opened this Issue Jun 3, 2016 · 2 comments

Comments

Projects
None yet
3 participants
@brueggemann

I figured out a problem with the algorithm that checks the validity times of certificates. I got a certificate with the following UTCTime format:
1606010000Z
As you can see, the format is YYMMDDHHmmZ. This possibility seems not to be considered in x509.c mbedtls_x509_get_time() function, as it only checks, if the length of the timestamp is > 10 and then tries to parse it as seconds.

Same (but not tested) on GeneralizedTime Format.

@ciarmcom ciarmcom added the mirrored label Jun 3, 2016

@ciarmcom

This comment has been minimized.

Show comment
Hide comment
@ciarmcom

ciarmcom Jun 3, 2016

Member

ARM Internal Ref: IOTSSL-806

Member

ciarmcom commented Jun 3, 2016

ARM Internal Ref: IOTSSL-806

@pjbakker

This comment has been minimized.

Show comment
Hide comment
@pjbakker

pjbakker Jun 6, 2016

Contributor

Hi Jan-Marten,

The RFC on X.509/CRLs (https://tools.ietf.org/html/rfc5280#section-4.1.2.5) explicitly demands the use of seconds (MUST) for certificates and CRLs.

So please let us know if you see another reason that makes you think the current implementation is wrong, we will consider this issue closed.

Relevant part

   For the purposes of this profile, UTCTime values MUST be expressed in
   Greenwich Mean Time (Zulu) and MUST include seconds (i.e., times are
   YYMMDDHHMMSSZ), even where the number of seconds is zero.  Conforming
   systems MUST interpret the year field (YY) as follows:

and

   For the purposes of this profile, GeneralizedTime values MUST be
   expressed in Greenwich Mean Time (Zulu) and MUST include seconds
   (i.e., times are YYYYMMDDHHMMSSZ), even where the number of seconds
   is zero.  GeneralizedTime values MUST NOT include fractional seconds.
Contributor

pjbakker commented Jun 6, 2016

Hi Jan-Marten,

The RFC on X.509/CRLs (https://tools.ietf.org/html/rfc5280#section-4.1.2.5) explicitly demands the use of seconds (MUST) for certificates and CRLs.

So please let us know if you see another reason that makes you think the current implementation is wrong, we will consider this issue closed.

Relevant part

   For the purposes of this profile, UTCTime values MUST be expressed in
   Greenwich Mean Time (Zulu) and MUST include seconds (i.e., times are
   YYMMDDHHMMSSZ), even where the number of seconds is zero.  Conforming
   systems MUST interpret the year field (YY) as follows:

and

   For the purposes of this profile, GeneralizedTime values MUST be
   expressed in Greenwich Mean Time (Zulu) and MUST include seconds
   (i.e., times are YYYYMMDDHHMMSSZ), even where the number of seconds
   is zero.  GeneralizedTime values MUST NOT include fractional seconds.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment