Skip to content
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

Parse embedded SCTs #10

Open
RufusJWB opened this issue Jan 29, 2019 · 5 comments
Open

Parse embedded SCTs #10

RufusJWB opened this issue Jan 29, 2019 · 5 comments
Labels
wontfix The behavior is by design, or we don't have an ability to fix this due to API restrictions.

Comments

@RufusJWB
Copy link
Contributor

It would be great, if the tool could parse SCT log entries as described here: https://letsencrypt.org/2018/04/04/sct-encoding.html . Probably doing so has the same problems as solving this issue #5 ?

@Crypt32
Copy link
Collaborator

Crypt32 commented Jan 29, 2019

I believe, SCT data decoding is out of ASN.1 Editor scope. A different tool that supports SCT data types shall be used to decode SCT data.

@Crypt32 Crypt32 added the wontfix The behavior is by design, or we don't have an ability to fix this due to API restrictions. label Jan 29, 2019
@RufusJWB
Copy link
Contributor Author

Well, SCT data is ASN1 data included in the certificate.

In this case, as described by the spec, those bytes happen to contain more DER. This is a fairly common pattern in X.509 to deal with parameterized data. For instance, this allows defining a structure for extensions without knowing ahead of time all the structures that a future extension might want to carry in its value.

https://letsencrypt.org/2018/04/04/sct-encoding.html

As this is a fairly common patterns I still think this would a valuable add on to your lovely little tool. If you would give me an indication that you would accept a Pull Request, I would implement it by my self and send you a PR.

@Crypt32
Copy link
Collaborator

Crypt32 commented Jan 29, 2019

SignedCertificateTimestampList is not encoded using DER

so..how it is related to ASN editor? Don't get me wrong, I would like to allow the editor to determine decoded message type and provide more details, but it is a hell of work to make every single X.509 data type recognizable. So I'm positioning the tool as a general-purpose ASN viewer/editor which may or may not be strictly X.509 or whatever else.

@RufusJWB
Copy link
Contributor Author

Got it - you were right. The SCTs are not encoded in ASN1 :-( https://tools.ietf.org/html/rfc5246#section-4

@RufusJWB
Copy link
Contributor Author

Never the less, it would be great, if there would be a way to decode like SAN entries or SCTs. Any idea how this could be implemented in a way that doesn't break the design of you tool?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
wontfix The behavior is by design, or we don't have an ability to fix this due to API restrictions.
Projects
None yet
Development

No branches or pull requests

2 participants