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

webpki/cert: extend `verify_is_valid_for` to iPAddress SAN #54

Open
lucab opened this Issue Jul 15, 2017 · 10 comments

Comments

Projects
None yet
4 participants
@lucab
Copy link

lucab commented Jul 15, 2017

I currently have some certificates from a private CA where the subject identity is established via an iPAddress subject alternative name. I just checked that this crate only tries to match a dNSName against a CN or a SAN, which is the reason why validation fails. This is a feature request to add support for such SAN validation.

As I (or somebody else) may want to tackle this in the future, I'd like to get some input on the expected API for this:

  • should a new dedicated is_valid_for_ip be introduced?
  • should the current is_valid_for_dns be renamed/overloaded to accept more than one SAN types?
  • should the consumer call is_valid_for multiple times, or just once with all DNSs/IPs/etc?
  • should the Ok return type be amended to return back the matching entry?

What's the API of other TLS library in this regard? Should this crate stick to prior art?

(I was personally thinking about a single is_valid_for which takes a slice of subject names, and returns back the matching one on success)

@dignan

This comment has been minimized.

Copy link

dignan commented Jul 25, 2017

I ran into the same issue and started going down the road of trying to find relevant RFCs for this. It looks like the DNS-based verification follows https://tools.ietf.org/html/rfc6125. However, that document explicitly marks IP-based verification as out-of-scope. It'd be useful to get input on what a "good" implementation would look like. It looks like nss converts the input string to a netaddr, and then does byte comparisons.

@lucab

This comment has been minimized.

Copy link

lucab commented Jul 25, 2017

@dignan section 3.1.3.2 of that RFC define the decoding and comparison rules (but, that is out of scope according to the preamble, duh). Anyway, the ASN type of that OID is "octet string" so the only valid comparison I can think of is full byte-by-byte equality in network order. Did you have any more specific doubt/concern?

@briansmith

This comment has been minimized.

Copy link
Owner

briansmith commented Jul 25, 2017

I probably own at least some of the copyright for the mozilla::pkix IP address handling code so it might be easiest for me to transliterate it. Otherwise we'd need to write all-new code.

@lucab

This comment has been minimized.

Copy link

lucab commented Jul 25, 2017

@briansmith do you have any input/insight on my original API questions? I see that CheckCertHostname in pkix takes a single non-specialized input and fallback-try multiple parsers, do you want to stick to that? (I didn't put this option in my initial list as I don't consider it safe/idiomatic)

@briansmith

This comment has been minimized.

Copy link
Owner

briansmith commented Jul 25, 2017

@lucab There are two questions:

  1. Should webpki continue on its original intended trajectory, where it was intentionally limited in functionality (e.g. we intentionally omitted adding IP address support), or should we expand its scope?

  2. If we should expand the scope, what should the API look like.

I won't have time to ponder either issue for a couple of weeks.

@briansmith

This comment has been minimized.

Copy link
Owner

briansmith commented Aug 18, 2017

I'm going to work on some things related to client auth support, which I think will help inform the work to extend webpki to other kinds of names, including IP addresses. In particular I want to add support for some non-dNSName forms for client auth purposes.

@djc

This comment has been minimized.

Copy link

djc commented Jan 6, 2019

@briansmith have you made up your mind as to whether you want to have support for this in webpki? We think this would be important for the kind of peer-to-peer connections that would be more common with QUIC's use of TLS.

@lucab

This comment has been minimized.

Copy link

lucab commented Jan 6, 2019

Additionally, in the meanwhile I've found a public website with a trust chain to a well-known root CA and an iPAddress SAN: https://1.1.1.1/

@briansmith

This comment has been minimized.

Copy link
Owner

briansmith commented Jan 7, 2019

Update on my comment from August 2017: Back then, I was going to do some work along these lines but ultimately that project decided to use DNS names after considering all the factors.

If you are going to be at RWC this year, please email me @ brian@briansmith.org and let's set up a time to chat about this.

@djc

This comment has been minimized.

Copy link

djc commented Jan 7, 2019

Not sure if that was directed at me, but I won't be at RWC. Happy to do some video chat though, if that helps.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment