Skip to content

Add wrappers for Time-Stamp Protocol (RFC 3161) implementation of OpenSSL #1336

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

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

krisztian-kovacs
Copy link
Contributor

The aim of these patch set is to cover enough functionality to implement a client interfacing with a time-stamping authority to request and verify timestamps.

This pull request is more of a request to review -- I'm a first time contributor to rust-openssl. It has only been tested with OpenSSL 1.1.0.

@sfackler
Copy link
Owner

sfackler commented Sep 1, 2020

CI is unhappy with the use of TryFrom.

@krisztian-kovacs
Copy link
Contributor Author

Indeed, I've seen the CI issue yesterday evening -- will come up with a fix today. Just to confirm: is 1.31 the MSRV rust-openssl is targeting?

@krisztian-kovacs krisztian-kovacs force-pushed the timestamping branch 7 times, most recently from 718c43c to 64f106c Compare September 3, 2020 09:57
@krisztian-kovacs
Copy link
Contributor Author

It took me some time to get the FFI bindings right for all versions of OpenSSL and LibreSSL, but hopefully it's OK now.

@krisztian-kovacs
Copy link
Contributor Author

Does the code look reasonable? Or is there something I could make to improve it?

/// A builder used to construct a `TsMsgImprint`
pub struct TsMsgImprintBuilder(TsMsgImprint);

impl TsMsgImprintBuilder {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TS_MSG_IMPRINT isn't reference counted, so there's no need for a separate builder type.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed, thanks!

/// Sets the algorithm identifier of the message digest algorithm.
///
/// This corresponds to `TS_MSG_IMPRINT_set_algo`.
pub fn set_algo(&mut self, digest: &MessageDigest) -> Result<(), ErrorStack> {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems like this should take an X509Algorithm rather than a MessageDigest.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, in that case I think it should be possible to easily construct an X509Algorithm from a MessageDigest. Now there's no public interface for constructing an X509Algorithm at all.
Also, according to RFC 3161 only message digest algorithms are valid here: "The hash algorithm indicated in the hashAlgorithm field SHOULD be a known hash algorithm (one-way and collision resistant)." -- that's why I thought that using a MessageDigest on this interface would be more precise and useful.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, and OpenSSL is inconsistent here: TS_MSG_IMPRINT_set_algo() uses X509_ALGOR, but its counterpart on the server side, TS_RESP_CTX_add_md() takes an EVP_MD. The server-side only accepts imprints with digest algorithms explicitly added via TS_RESP_CTX_add_md().


pub struct TsReqBuilder(TsReq);

impl TsReqBuilder {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similarly, no need for a builder.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed, thanks!

/// Corresponds to `TS_REQ_to_TS_VERIFY_CTX`.
pub fn from_req(request: &TsReqRef) -> Result<TsVerifyContext, ErrorStack> {
unsafe {
ffi::init();
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This isn't necessary since a TsReqRef already exists.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed, thanks!

unsafe {
ffi::init();
let ctx: *mut ffi::TS_VERIFY_CTX = cvt_p(ffi::TS_VERIFY_CTX_new())?;
let ctx = cvt_p(ffi::TS_REQ_to_TS_VERIFY_CTX(request.as_ptr(), ctx))?;
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The TS_VERIFY_CTX is leaked if this fails.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed, thanks. It seems there's no point in constructing a verify context and passing it to TS_REQ_to_TS_VERIFY_CTX() anyway and we're better off with passing in NULL.


pub struct TsRespContextBuilder(TsRespContext);

impl TsRespContextBuilder {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably same here WRT not needing a builder.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed, thanks for the review!

@krisztian-kovacs
Copy link
Contributor Author

I've rebased these changes to the latest master.
@sfackler do you see any outstanding issues that prevent merging this PR?

These are required by the timestamping code.
This change adds a partial wrapper for the Time-Stamp Protocol (RFC 3161)
implementation in OpenSSL. The aim is to have enough coverage to create a client
that can interact with a Time Stamp Authority by creating time-stamp requests
and verifying responses returned by the authority.
This change adds the missing wrappers to be able to generate a minimally
functional Time Stamp Authority, signing time stamp requests and generating
time stamp responses.
@Kijewski
Copy link

Kijewski commented Jan 31, 2022

Hi, can you tell me what the state of the PR is? I'd like to use this feature in a project of mine. (No rush, of course! :) )

@dfintha
Copy link

dfintha commented Feb 10, 2022

Hi, I'm also interested, when this PR might get merged, it would be pretty useful. :)

@JM4ier
Copy link

JM4ier commented Aug 3, 2024

@sfackler does this PR still have work that needs to be done before it can be merged? (apart from the merge conflict I mean)

If so, I'll gladly implement it on a separate PR, as timestamping is a feature I need.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants