Skip to content

Externalize hashing and certificate logic to enable alternative implementations #12

@jaxley

Description

@jaxley

The implementation currently hard-codes three things that would be ideal to enable a way to provide alternate implementations based on differing needs to deviate from the default behavior in the library:

  1. Hard-codes hashing of the public key (vs. entire certificate). Would be better to allow this to be configurable by inverting the dependencies and enabling injection of a different implementation (e.g. one that ). One reason for this would be if you wanted to achieve cross-platform parity in the definition of a PIN and how it's done. iOS doesn't make it easy in all cases to get the SubjectPublicKeyInfo, for example.
  2. Hard-codes SHA1 hashing of the certificate information (SubjectPublicKeyInfo currently). Organizations will have varying standards for approved hashing algorithms so would be nice to make this configurable without having to fork and modify the code.
  3. Requires comparing hashes of the certificate information. Would be nice if the certificate retrieval/hasher was a class that could be swapped out, e.g. if I wanted to avoid the hashing impact on every HTTPS request, I may want to compare raw bits rather than a hash (via a NullCertificateHasher implementation, for example). Then the comparison logic could compare what the class provides to the pins without caring what the bits are.

Wanted to see if there's interest in these changes as I may just make these tweaks if I get some spare time and provide them as I think they would be useful (if they're not already in the works).

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions