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

Missing formats #1

Open
8 tasks done
tarcieri opened this issue Sep 14, 2021 · 14 comments
Open
8 tasks done

Missing formats #1

tarcieri opened this issue Sep 14, 2021 · 14 comments

Comments

@tarcieri
Copy link
Member

tarcieri commented Sep 14, 2021

Please post a comment to request additional formats

@jklong
Copy link
Contributor

jklong commented Sep 15, 2021

#3 will also require a PKCS#7 implementation so I'll start work on that as well. I've created PKCS#7 support #28 to track.

@franziskuskiefer
Copy link
Contributor

Do you want to stick to the big ones or are you also interested in things like the "TLS codec". It's not really a standard but it's being used quite a bit by now. I have a version here https://github.com/openmls/tls-codec/

@tarcieri
Copy link
Member Author

@franziskuskiefer if you so happen to be looking for another home for it I'd say that would be a great thing to have here

@jonasbb
Copy link

jonasbb commented Dec 30, 2021

The new ssh-key crate does not seem to support ssh-keys backed by security keys, which contain the sk suffix in the name. There is ecdsa_sk which uses [email protected] in the .pub file and ed25519_sk using [email protected] as the identifier.
It would be great to have support for these newer key types too, but it is not clear to me if that is currently on the todo list.

@tarcieri
Copy link
Member Author

@jonasbb yes, it would be good to add support for those. Likewise it would be nice to have support for OpenSSH certificates.

I will try to get these items added to the TODO list in the README, or otherwise would merge a PR to add them.

@tarcieri tarcieri pinned this issue Oct 11, 2022
baloo added a commit to baloo/formats that referenced this issue Jan 3, 2023
The naming of the `to_owned` method was a bit unfortunate as it
triggered conflicts with the `alloc::borrow::ToOwned` method. When used,
this would make for compiler messages asking things like:
```
error[E0034]: multiple applicable items in scope
   --> certval/src/validator/name_constraints_set.rs:748:34
    |
748 |                         value: a.to_owned(),
    |                                  ^^^^^^^^ multiple `to_owned` found
    |
    = note: candidate RustCrypto#1 is defined in an impl of the trait `RefToOwned` for the type `AnyRef<'a>`
    = note: candidate RustCrypto#2 is defined in an impl of the trait `ToOwned` for the type `T`
help: disambiguate the associated function for candidate RustCrypto#1
    |
748 |                         value: RefToOwned::to_owned(&a),
    |                                ~~~~~~~~~~~~~~~~~~~~~~~~
help: disambiguate the associated function for candidate RustCrypto#2
    |
748 |                         value: ToOwned::to_owned(&a),
    |                                ~~~~~~~~~~~~~~~~~~~~~
```
tarcieri pushed a commit that referenced this issue Jan 3, 2023
The naming of the `to_owned` method was a bit unfortunate as it
triggered conflicts with the `alloc::borrow::ToOwned` method. When used,
this would make for compiler messages asking things like:

```
error[E0034]: multiple applicable items in scope
   --> certval/src/validator/name_constraints_set.rs:748:34
    |
748 |                         value: a.to_owned(),
    |                                  ^^^^^^^^ multiple `to_owned` found
    |
    = note: candidate #1 is defined in an impl of the trait `RefToOwned` for the type `AnyRef<'a>`
    = note: candidate #2 is defined in an impl of the trait `ToOwned` for the type `T`
help: disambiguate the associated function for candidate #1
    |
748 |                         value: RefToOwned::to_owned(&a),
    |                                ~~~~~~~~~~~~~~~~~~~~~~~~
help: disambiguate the associated function for candidate #2
    |
748 |                         value: ToOwned::to_owned(&a),
    |                                ~~~~~~~~~~~~~~~~~~~~~
```
@enri1196
Copy link
Contributor

enri1196 commented Jun 4, 2023

Do you think RFC3161 TimeStamp Protocol would be a good addition to the formats?

reference: https://www.rfc-editor.org/rfc/rfc3161

@carl-wallace
Copy link
Contributor

I think RFC3161 would be a good addition and have thought about implementing it before but had not gotten around to it. It's referenced in some new work, for example, draft-birkholz-rats-epoch-markers.

@enri1196
Copy link
Contributor

enri1196 commented Jun 4, 2023

I'd like to help, can I just open a PR once I've got some basic implementation of the structures? Maybe a new folder under formats/tsp?

@tarcieri
Copy link
Member Author

tarcieri commented Jun 4, 2023

We'd need a crate name we actually control, although you can use that name temporarily until we pick one we do control

@leotaku
Copy link

leotaku commented Nov 13, 2023

I would potentially be interested in contributing an implementation of RFC5544. Is that something the project would benefit from?

@enri1196
Copy link
Contributor

Hey @leotaku I've actually created an issue for this format and I have most of the work done locally, the blocking issue for me is that I get an indefinite length error which seems to come from a BER/DER mixed encoding. #1198 I was waiting to get some feedback, but I could definitely open a PR for you to test for your self, maybe you can spot something i missed.

@leotaku
Copy link

leotaku commented Nov 13, 2023

@enri1196 That sounds great. If you open a PR or direct me to your fork I'd love to take a look.

@enri1196
Copy link
Contributor

@leotaku check out PR #1258 hopefully we can get this to work

@dishmaker
Copy link

PKCS#15
ISO/IEC 7816-15
Version 2016 with amd. 2018
https://github.com/monai/node-passport/blob/master/lib/pkcs15/cryptographic_information_framework.asn1

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

No branches or pull requests

8 participants