I go for a) but also agree that b) would be better for people outside this list. Could we have some kind of mixing, having the old and new interface together, a warning on old interface and then on the next version it could be removed (or throw..).
-- Diogo Resende On Tuesday, October 9, 2012 at 8:30 , Paddy Byers wrote: > Hi, > > > a) Go for it. This won't affect me, and if by chance it does, I don't > > mind putting 'binary' args here and there. > > I definitely support (a). Might I make a plea also for a proper > X509Certificate class to be supported in addition to PEM and other encodings > of certificates in the factory methods for Credentials, Signer and Verifier? > > We have a glimpse of a certificate class in the tls module with > cleartextStream.getPeerCertificate(); but this is the only place in the API > where fields of a certificate are exposed. There are also use-cases in > signing and verifying where you want to know about certificate details, and > details also about non-trivial certificate paths that were constructed in the > course of verifying a signature. An example would be knowing whether or not > your validated path qualifies as a valid EV path, or verifying the signature > on in an XML signature document. > > I know the argument is always that this functionality can go in user land in > an independent module, instead of in core; and there are modules that do some > of this such as dcrypt [1]. The problem is that when you do that you have to > re-implement all of the core functionality as well on top of your external > certificate library, just because you're unable to pass a certificate object > into the APIs in the core. > > So my suggestion would be to include X509Certificate and X509CRL classes that > wrap native OpenSSL X509 structures, and for these to be supported as well as > strings in the relevant APIs. Once that is in place, I think the more > esoteric use cases can be supported in userland without lots of duplication > of code. > > I'm happy to contribute to the work, and some time ago started implementing > support for this [2] based on dcrypt. You can see from the amount of code in > there that's simply cut+paste from core that it really would be a fairly > modest delta; much of the functionality is already there, but disorganised. > > Thanks - Paddy > > [1]: https://github.com/dekz/dcrypt > [2]: https://github.com/paddybyers/dcrypt > > > -- > Job Board: http://jobs.nodejs.org/ > Posting guidelines: > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > You received this message because you are subscribed to the Google > Groups "nodejs" group. > To post to this group, send email to [email protected] > (mailto:[email protected]) > To unsubscribe from this group, send email to > [email protected] > (mailto:[email protected]) > For more options, visit this group at > http://groups.google.com/group/nodejs?hl=en?hl=en -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
