It would be nice if all the parts of asn1js/pkijs could be used easily with the webpack module loader. Currently I am having to manually splice together asn1/common, asn1, pki/x509_simpl, and pki/x509_schema into one giant file, which is not particularly sustainable. I see the documentation about using node.extend to solve what appears to be a similar problem when running on Node.js, but I don't think that technique would work with webpack.

WebCrypto will support these curves we should also support them.

In PKCS#10 example we have

            var typemap = {
                "2.5.4.6": "C",
                "2.5.4.10": "OU",
                "2.5.4.11": "O",
                "2.5.4.3": "CN",

But here we have wrong OIDs for "O" and "OU". Must be like this:

            var typemap = {
                "2.5.4.6": "C",
                "2.5.4.11": "OU",
                "2.5.4.10": "O",
                "2.5.4.3": "CN",

Thanks our user Dmitry for the good finding.

Basic Constraints, Key Usage, Extended Key Usage, CRLdp are all supper common would be great to have a array and/ or helper in common.js to help people go from OIDs to strings.

I've been developing a web project and some API.
Can I use the library on my project for my safety operations?

While javascript based cryptography is questionable it would be interesting to be able to validate signatures produced with these algorithms in browser. The scenarios in which we can rely in the implementations would need some thought and maybe it would be nothing more than an experiment but it would be interesting.

PKCS#1 the following PEM headers:
-----BEGIN PRIVATE KEY----
-----END PRIVATE KEY----

While PKCS8 uses:
-----BEGIN RSA PRIVATE KEY-----
-----END RSA PRIVATE KEY-----

It would be nice to have a helper smart enough to figure this out for people and go to and from these formats without having to know these details.

See: https://polarssl.org/kb/cryptography/asn1-key-structures-in-der-and-pem

I started digging a bit into PKI.js, I'm not a crypo guy but I like to understand the libraries I'm using.

One thing that makes the code very hard to follow, is that it uses the argumnets object somewhat excessively.

For example, take org.pkijs.simpl.GENERAL_NAME which has one optional arguments, which could be expressed in the function declaration.

Is there a reason for this or would you accept a (or multiple) pull request(s) to change it?

For CMS Signed Data newly created signatures sometimes not verified by external programs. At the same time these signs successfully verified inside the lib. Also lib may successfullt verify any data from external programs. Need to figure out and solve the issue.

http://en-us.sysadmins.lv/Lists/Posts/Post.aspx?List=332991f0-bfed-4143-9eea-f521167d287c&ID=104

As promised (@YuryStrozhevsky, @rmhrisk) I just prepared some things based on jsPDF:

• A simple plugin for jsPDF which allows you to create signature fields.
• A simple signature plugin which simply misses the magic of PKIjs to create the CMS signature.

I had to make some more changes to the main jsPDF in view to dynamic object number generation but after all it should work as an experimental basis for you.

The fork/branch is available: https://github.com/Setasign/jsPDF/tree/PKI.js-integration

If you have any question or need further support, feel free to contact me/us!

Cheers,
Jan

[vps@palladin]~$ node
> require('pkijs/org/pkijs/cms_schema');
TypeError: Cannot set property 'RSAES_OAEP_params' of undefined
    at .../node_modules/pkijs/org/pkijs/cms_schema.js:292:55
    at Object.<anonymous> (.../node_modules/pkijs/org/pkijs/cms_schema.js:1177:2)
    at Module._compile (module.js:435:26)
    at Object.Module._extensions..js (module.js:442:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:311:12)
    at Module.require (module.js:366:17)
    at require (module.js:385:17)
    at repl:1:1
    at REPLServer.defaultEval (repl.js:248:27)
> 
[vps@palladin]~$ npm list pkijs
<...>
└── [email protected] 

I don't have enough understanding about this to submit a pull request, but it does't seem that RSAES-OAEP-params is used in CMS, so it can just all be removed, or may be it is, so it just needs to be attached to cms, not x509.

The same problem exists in cms_schema.js, in a tad more places.
Thank you :)

Hello,

just wondered if this project is still being developed on. Would really like to have the creation of CMS enveloped data functionality.

E.g. this PKCS10 contains a BitString that is a Sequence and an OctetString that is also a Sequence:

-----BEGIN CERTIFICATE REQUEST-----
MIIBnzCCAQgCAQAwITEfMB0GA1UEAxMWa2VyY2tob2Zmcy5nMTBjb2RlLmNvbTCB
nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA5h+uKRenpvbe+BnMY6siPO50LVyg
HtB7kr+YISlPJ5JAFO12yQFz9Y0sBLHbjR+V+TOawwP1dZhGjlgnEBkMdWKuEBlS
wFTALLX78GAyvAYAmPqSPDEYXkMECyUXVX/bbGI1bY8Y2OGy4w4D+v7e+xD2NBkm
Bj5cNy+YMbGVldECAwEAAaA+MDwGCSqGSIb3DQEJDjEvMC0wKwYDVR0RBCQwIoIP
d3d3LmcxMGNvZGUuY29tgg9mdHAuZzEwY29kZS5jb20wDQYJKoZIhvcNAQEFBQAD
gYEAzBRIi8KTfKyebOlMtDN6oDYBOv+r9A4w3u/Z1ikjffaiN1Bmd2o9Ez9KXKHA
IezLeSEA/rGUPN5Ur5qIJnRNQ8xrS+iLftr8msWQSZppVnA/vnqMrtqBUpitqAr0
eYBmt1Uem2Y3UFABrKPglv2xzgGkrKX6AqmFoOnJWQ0QcTw=
-----END CERTIFICATE REQUEST-----

See the structure here:

http://lapo.it/asn1js/#3082019F308201080201003021311F301D060355040313166B6572636B686F6666732E673130636F64652E636F6D30819F300D06092A864886F70D010101050003818D0030818902818100E61FAE2917A7A6F6DEF819CC63AB223CEE742D5CA01ED07B92BF9821294F27924014ED76C90173F58D2C04B1DB8D1F95F9339AC303F57598468E582710190C7562AE101952C054C02CB5FBF06032BC060098FA923C31185E43040B2517557FDB6C62356D8F18D8E1B2E30E03FAFEDEFB10F6341926063E5C372F9831B19595D10203010001A03E303C06092A864886F70D01090E312F302D302B0603551D1104243022820F7777772E673130636F64652E636F6D820F6674702E673130636F64652E636F6D300D06092A864886F70D010105050003818100CC14488BC2937CAC9E6CE94CB4337AA036013AFFABF40E30DEEFD9D629237DF6A2375066776A3D133F4A5CA1C021ECCB792100FEB1943CDE54AF9A8826744D43CC6B4BE88B7EDAFC9AC590499A6956703FBE7A8CAEDA815298ADA80AF4798066B7551E9B6637505001ACA3E096FDB1CE01A4ACA5FA02A985A0E9C9590D10713C

As far as I know Web Crypto API allows usage of local private keys (.p12 of pkcs#12-formatted files). But in the examples page I found only generate-key-on-the-fly or read-binary-.cer methods. Does PKI.js support loading local .p12 file?

Thanks!

Though the library supports encoding and decoding CMS Enveloped Data there is no support for key agreement and encryption this is needed to implement S/MIME amongst a few other formats.

The goal for this library is not only to make is possible for people to build X.509 aware applications but to make it easy and have the natural behavior when using the library be the "safe" and "correct" behavior.

That said we want the library to allow advanced scenarios as well; to accommodate this we should consider creating a higher-level API construct that are built on the current SIMPL classes that abstract out the ASN.1 concepts and leaves the caller with simpler calls that make it easy to do the right thing.

For example today to get the length of a RSA you would do something like this:
var asn1 = org.pkijs.fromBER(buffer);
var cert_simpl = new org.pkijs.simpl.CERT({ schema: asn1.result });

var asn1_publicKey = org.pkijs.fromBER(cert_simpl.subjectPublicKeyInfo.subjectPublicKey.value_block.value_hex);
var rsa_publicKey_simple = new org.pkijs.simpl.x509.RSAPublicKey({ schema: asn1_publicKey.result });

var modulus_bit_length = rsa_publicKey_simple.modulus.value_block.value_hex.byteLength * 8;
var publicExponent_bit_length = rsa_publicKey_simple.publicExponent.value_block.value_hex.byteLength * 8;

This only works for RSA keys and not all the time since "rsa_publicKey_simple.modulus.value_block.value_hex.byteLength" has values not a 2^N but (2^N + 1) - this is because "modulus" stores inside ASN.1 INTEGER type and accordingly to rule the integer value should not a negative. That is why as a first byte for such integer we have 0x00.

A higher level class structure would expose a .bitLength field that was smart enough to find the right answer for bitlength for ECC, RSA and the variations that exist.

There is a problem with the name constraints validation algorithm. In particular, if a name constraint exists for a certain type (e.g. dNSName), but the certificate does not contain such a name (there is no subject alternative name with dNSName type), then the validation fails even if it should have succeeded. This happens for example when there is a sub CA which is technically constrained using rfc822Name and dNSName constraints, and there is an end entity certificate which doesn't have both an rfc822Name and a dNSName.
The problem is at the x509_simpl.js file, at in_window.org.pkijs.simpl.CERT_CHAIN.prototype.verify, at the region 'Check name constraints groupped by type, one-by-one'. For example, at the subregion dNSName you should check if there is no subject_alt_names with subject_alt_names[i].NameType equal to 2, and if so then set group_permitted equal to true.

It would be good to see improved error handling so that programatic handling and debugging of encoding problems can be handled better.

One concern I have is how we help people who use the library expose themselves to as little risk as possible, while we can advise people to only use the library over SSL you do not have the ability to authenticate who served the content from within Javascript.

To address this one approach that can be taken is to have a very small kernel of code whose role is simply to authenticate PKIjs/ASN1js with a public key. The libraries would be signed by this public key, as would the root certificates it would use. This small kernel would still be exposed to the regular browser sandbox issues but the surface area of exposure would be limited to this small kernel. This combined with leveraging some HTML5 segmentation approaches is probably the best you can get outside of a pre-installed plug-in like Chrome.

Hello,

I'm currently trying to send a csr to a Microsoft PKI.
For some reason when I set the attribute this way:

pkcs10_simpl.attributes.push(new org.pkijs.simpl.ATTRIBUTE({type: "1.3.6.1.4.1.311.13.2.1", values: [new org.pkijs.asn1.UNIVERSALSTRING({ value: "CertificateTemplate" }), new org.pkijs.asn1.UNIVERSALSTRING({ value: "AL_WIFI_Users_NotWindows" })]}));

when I run the code in debug mode the schema contains this list of SID value block:
43,6,1,4,1,311,13,2,1

Is this normal?

seems like requestExtensions should be extensions_array vs contain it

Signing and verifying a signature is a very common case, providing an example of doing this using https://github.com/thomasjbradley/signature-pad or https://github.com/szimek/signature_pad would be useful.

For example:
// function to convert certificate serial from buffer array if needed
function toHexCodes(input_buffer) {
var result = "";
var int_buffer = new Uint8Array(input_buffer);

            for(var i = 0; i < int_buffer.length; i++){
                var str = int_buffer[i].toString(16).toUpperCase();
                result = result + ((str.length === 1) ? " 0" : " ") + str;
            }
            return result;
        };

        // function to convert string to b64
        function str2ab(str) {
            var buf = new ArrayBuffer(str.length*2); // 2 bytes for each char
            var bufView = new Uint8Array(buf);
            for (var i=0, strLen=str.length; i<strLen; i++) {
                bufView[i] = str.charCodeAt(i);
            }
            return buf;
        };

Seems like org.pkijs.simpl.OCSP_REQUEST should be tbsRequest vs contain it?

When generating a CSR with the subject alternative name extension the "id-ce-subjectAltName" extension shows up but the extension value is empty when the CSR is parsed. Here is the code for adding the extension:

pkcs10_simpl.attributes.push(new org.pkijs.simpl.ATTRIBUTE({
    type:"1.2.840.113549.1.9.14",
    values:[(new org.pkijs.simpl.EXTENSIONS({
        extensions_array:[
            new org.pkijs.simpl.EXTENSION({
                extnID:"2.5.29.17",
                critical:false,
                extnValue:(new org.pkijs.asn1.UTF8STRING({value:'DNS:example.org,DNS:www.example.org'})).toBER(false)
            })
        ]
    })).toSchema()]
}));

Is there a simple way to encapsulate a ASN1 SEQUENCE in a OCTETSTRING in a PKCS10 csr?

I'm actually creating a PKCS10 csr from scratch.

Thanks in advance,

When we have an interop target (browser that supports necessary bits of WebCrypto) we should also add support for creating and importing PKCS #12 files.

A review of the sample included in the readme shows it doesnt include sign, would be nice if it was a complete sample.

Currently the chain engine does pure path building and is satisfied if the chain ends in any self signed certificate included in the initial passed in bag. For this to be useful by applications it will need to take in another array of certificates that contains a list of trusted CAs, if this is specified and no intersection found it needs to return an error so the application can know this isnt issued by a trusted CA. Without this the application has to pre validate the certificate bag it passes to the chain to make sure it doesnt have a self signed certificate in it.

In a perfect world this bag of trusted certs could contain non-self-signed certs also, I trust this specific intermediate vs this root certificate but this is not strictly necessary.

Hi.

I'm not sure if I'm doing something wrong, or this really should be documented.

Often times, one PKIJS module uses another (i.e. cms_simpl uses x509_simpl). To access the other module, 'in_window' object is used, which is passed in to the closure function when module is initialized. For Node, it's 'module.exports' object.

If I called x509 = require('pkijs/org/pkijs/x509_simpl'), NodeJS will create a new module object, and x509_simpl will attach its implementation to its export property. When I later call cms = require('pkijs/org/pkijs/cms_simpl'), a new module object is created, and cms_simpl will attach itself to that module's export property. Now, the contents of an export property is what returned from require() call.

I can, of course, merge results of require() calls together (i.e. with node.extend). But the reference to the original export property is "stuck" in the corresponding module implementation, and there is no way to influence this for the loaded modules code, because that reference is accessed using scope, not object property.

The good news, is that the code always looks up properties chain from the in_window, starting from org. Those can be easily overwritten, forcing the module to "use" newer version of it, if provided. So, I ended up having this as a loading code for PKIJS module:

    var PKI;

    (function() {
        let asn1js = require('asn1js');
        let asn1common = require('asn1js/org/pkijs/common');
        let pkijs = require('pkijs');
        let x509Schema = require('pkijs/org/pkijs/x509_schema');
        let cmsSchema = require('pkijs/org/pkijs/cms_schema');
        let cmsSimple = require('pkijs/org/pkijs/cms_simpl');
        let x509Simple = require('pkijs/org/pkijs/x509_simpl');

        // merge them togther

        let merger = merge(true, asn1js, asn1common);
        merger = merge(true, merger, pkijs);
        merger = merge(true, merger, x509Schema);
        merger = merge(true, merger, cmsSchema);
        merger = merge(true, merger, cmsSimple);
        merger = merge(true, merger, x509Simple);

        asn1js.org = merger.org;
        asn1common.org = merger.org;
        pkijs.org = merger.org;
        x509Schema.org = merger.org;
        cmsSchema.org = merger.org;
        cmsSimple.org = merger.org;
        x509Simple.org = merger.org;

        PKI = merger;

    })();

So far, seems to be working fine :)

I don't know if browser/WebCrypto supports necessary, but... can you add support to smartcards in PKI.js?

Thanks

We should do this based on http://emailjs.org/

Whats is a CA bundle file?

What format is acceptable?

Something like this encapsulated into a helper is needed for revocation reason:

                // Get the revocation reason from the crlEntryExtensions array
                //ReasonFlags ::= BIT STRING {
                //    unused                  (0),
                //    keyCompromise           (1),
                //    cACompromise            (2),
                //    affiliationChanged      (3),
                //    superseded              (4),
                //    cessationOfOperation    (5),
                //    certificateHold         (6),
                //    privilegeWithdrawn      (7),
                //    aACompromise            (8) }

                var revokedReason = "Not specified";
                for (var j = 0; j < crl_simpl.revokedCertificates[i].crlEntryExtensions.extensions_array.length; j++) {
                    if (crl_simpl.revokedCertificates[i].crlEntryExtensions.extensions_array[j].extnID === "2.5.29.21")
                    {
                        var revocationReasonPresent = true;
                        var aACompromise = false;
                        var privilegeWithdrawn = false;
                        var cessationOfOperation = false;
                        var superseded = false;
                        var affiliationChanged = false;
                        var cACompromise = false;
                        var keyCompromise = false;

                        var view = new Uint8Array(crl_simpl.revokedCertificates[i].crlEntryExtensions.extensions_array[j].extnValue.value_block.value_hex);

                        if((view[2] & 0x00) === 0x00) // Set flag "unused"
                            var unused = true;

                        if((view[2] & 0x01) === 0x01) // Set flag "keyCompromise"
                            var keyCompromise = true;

                        if((view[2] & 0x02) === 0x02) // Set flag "cACompromise"
                            var cACompromise = true;

                        if((view[2] & 0x03) === 0x03) // Set flag "affiliationChanged"
                            var affiliationChanged = true;

                        if((view[2] & 0x04) === 0x04) // Set flag "superseded"
                            var superseded = true;

                        if((view[2] & 0x05) === 0x05) // Set flag "cessationOfOperation"
                            var cessationOfOperation = true;

                        if((view[2] & 0x06) === 0x06) // Set flag "certificateHold"
                            var certificateHold = true;

                        if((view[2] & 0x07) === 0x07) // Set flag "privilegeWithdrawn"
                            var privilegeWithdrawn = true;

                        if((view[2] & 0x08) === 0x08) // Set flag "aACompromise"
                            var aACompromise = true;


                        if (aACompromise === true)
                            revokedReason="aACompromise";
                        if (privilegeWithdrawn === true)
                            revokedReason="privilegeWithdrawn";
                        if (cessationOfOperation === true)
                            revokedReason="cessationOfOperation";
                        if (superseded === true)
                            revokedReason="superseded";
                        if (affiliationChanged === true)
                            revokedReason="affiliationChanged";
                        if (cACompromise === true)
                            revokedReason="cACompromise";
                        if (keyCompromise === true)
                            revokedReason="keyCompromise";

                    };
                }

I'm trying to get pkijs working, in the browser, using the npm module and the custom instructions needed to load pkijs:

// See https://www.npmjs.com/package/pkijs
var merge = require("node.extend");
var common = require("asn1js/org/pkijs/common");
var _asn1js = require("asn1js");
var _pkijs = require("pkijs");
var _x509schema = require("pkijs/org/pkijs/x509_schema");
// #region Merging function/object declarations for ASN1js and PKIjs
var asn1js = merge(true, _asn1js, common);
var x509schema = merge(true, _x509schema, asn1js);
var pkijs_1 = merge(true, _pkijs, asn1js);
var pkijs = merge(true, pkijs_1, x509schema);

pkijs.org.pkijs exists, however pkijs.org.pkijs.getAlgorithmParameters is missing.

It looks like getAlgorithmParameters itself is missing from ./node_modules/asn1js/org/pkijs/common.js. Whereas https://pkijs.org/examples/org/pkijs/common.js includes it.

Perhaps this was from back in the day when only node used npm?

For example something like this would help build UIs without applications having to know what each OID means:

algomap = {
"1.2.840.113549.2.1": "MD2",
"1.2.840.113549.1.1.2": "MD2 with RSA",
"1.2.840.113549.2.5": "MD5",
"1.2.840.113549.1.1.4": "MD5 with RSA",
"1.3.14.3.2.26": "SHA1",
"1.2.840.10040.4.3": "SHA1 with DSA",
"1.2.840.10045.4.1": "SHA1 with ECDSA",
"1.2.840.113549.1.1.5": "SHA1 with RSA",
"2.16.840.1.101.3.4.2.4": "SHA224",
"1.2.840.113549.1.1.14": "SHA224 with RSA",
"2.16.840.1.101.3.4.2.1": "SHA256",
"1.2.840.113549.1.1.11": "SHA256 with RSA",
"2.16.840.1.101.3.4.2.2": "SHA384",
"1.2.840.113549.1.1.12": "SHA384 with RSA",
"2.16.840.1.101.3.4.2.3": "SHA512",
"1.2.840.113549.1.1.13": "SHA512 with RSA"
};

and

var typemap = {
"2.5.4.6": "C",
"2.5.4.10": "OU",
"2.5.4.11": "O",
"2.5.4.3": "CN",
"2.5.4.7": "L",
"2.5.4.8": "S",
"2.5.4.12": "T",
"2.5.4.42": "GN",
"2.5.4.43": "I",
"2.5.4.4": "SN"
},

Need to remove using of EXTENSIONS object and instead introduce an array of EXTENSION objects directly.

There are cases where certificates may have several signers, this is called cross certification.

There are variations of this scenario where there may be multiple version of a certificate.

The chain engine should be made smart enough to build multiple chains and pick the best one as to deal with these cases.

All applications will need a list of trusted certificates we need to do a sample of dynamically loading the mozilla trusted roots based on this file: http://mxr.mozilla.org/mozilla/source/security/nss/lib/ckfw/builtins/certdata.txt

So that the library can be quickly benchmarked and verified in different browsers the tests should be pulled into a page similar to this one: http://bitcore.io/test/index.html so that they can be verified easily cross-browser.

Loading an existing private key from a .KEY file throws me this error:

DataError: Data provided to an operation does not meet requirements

I'm passing the arraybuffer to the recipientPrivateKey parameter at the moment of opening the envelop,

http://stackoverflow.com/questions/36075081/read-private-key-in-key-format-with-pki-js-for-cms-envelopeddata

I don't know near enough of the details of how x509 and ASN.1 are supposed to work, but I am having a problem with subject and issuer names in certificates built in PKI.js not being read properly by other x509 parsers (specifically, golang's). When more than one attribute is added to the RDN object in the subject or issuer, using the syntax recommended in your documentation:

       cert.subject.types_and_values.push(new pkijs.org.pkijs.simpl.ATTR_TYPE_AND_VALUE({
            type: "2.5.4.6", // countryCode
            value: new pkijs.org.pkijs.asn1.PRINTABLESTRING({value: 'JP'})
        }));
        cert.subject.types_and_values.push(new pkijs.org.pkijs.simpl.ATTR_TYPE_AND_VALUE({
            type: "2.5.4.3", // commonName
            value: new pkijs.org.pkijs.asn1.UTF8STRING({value: cn})
        }));

On the receiving end, only the countryCode is visible. The commonName is not. If I reverse the order of the pushes, the commonName becomes visible and we lose the countryCode.

Again, apologies if I mess up the terminology here, but as I understand it, you are generating a SEQUENCE containing a single SET value that in turn contains all of the attribute/value pairs (as embedded SEQUENCEs). If I look at other certificates generated by CAs, I see instead that a subject or issuer is a SEQUENCE of SETs, each SET containing a single attribute/value pair. BouncyCastle also seems to be expecting a subject or issuer to be an array of RDN objects, not a single one with multiple attributes in a SET. So, in order to get things to interoperate, I changed RDN's toSchema function as follows:

var output_array = new Array();
                var setelem;

                for (var i = 0; i < this.types_and_values.length; i++) {
                    setelem = new in_window.org.pkijs.asn1.SET({value: [this.types_and_values[i].toSchema()]});
                    output_array.push(setelem);
                }

                return (new in_window.org.pkijs.asn1.SEQUENCE({
                    value: output_array
                }));

This makes both attributes visible on the other side. I do not know if this is a bug in PKI.js, a problem with the way I am building the certificate, or merely an inconsistency in the way PKI.js and other x509 implementations handle distinguished names, in which case I have no idea what the right answer is. If anybody else is having trouble with parsing out names from PKI.js-generated certificates in other implementations, maybe this will help.

Before this code is used in production systems a code and security audit should be performed.

I was testing (node.js env) some alternatives to the region check method and came up with the function bellow:

    function createPackage(name) {
        var packageNames = name.split('.');
        var parent = in_window;
        var fullLoadedPackage = '';
        for (var i = 0; i<packageNames.length; i++) {
            if(typeof parent[packageNames[i]] === "undefined")
                parent[packageNames[i]] = {};
            else
            {
                if(typeof parent[packageNames[i]] !== "object") 
                {

                    throw new Error("Name " + fullLoadedPackage + packageNames[i] + " already exists and it's not an object");
                }
            }
            parent = parent[packageNames[i]];
            fullLoadedPackage += packageNames[i] + '.';
        }
        return fullLoadedPackage.substr(0, fullLoadedPackage.length - 1);
    }

also add the checking of the x509 packages into those files (for node, it only worked after adding those packages):

• cms_simpl.js

    createPackage('org.pkijs.simpl.cms');
    createPackage('org.pkijs.simpl.x509');

• cms_schema.js

    createPackage('org.pkijs.schema.cms');
    createPackage('org.pkijs.schema.x509');

Also, a quick tip to import all the required libs (I've added common and asn1 into pkijs folders):

var extend = require("extend");

var pkijs_libs = [
  "pkijs/org/pkijs/common"
  ,"pkijs/org/pkijs/asn1"
  ,"pkijs/org/pkijs/x509_schema"
  ,"pkijs/org/pkijs/x509_simpl"
  ,"pkijs/org/pkijs/cms_schema"
  ,"pkijs/org/pkijs/cms_simpl"
];


// #region Merging function/object declarations for ASN1js and PKIjs
var pkijs = {};
for (var i = 0, len = pkijs_libs.length; i < len; i++) {
  extend(true, pkijs, require(pkijs_libs[i]));
};
// #endregion

Hi there. You recently fixed the in_window usage in pkcs12_simpl.js via 0cd8a5f, however this commit/fix isn't on NPM.

Would you mind publishing this? Thanks!

Hello,

Above all, I want to say 'thank you for these useful tools'.

I've looked at CreateNewX509Certificate example.
I'm trying to understand. I couldn't see any imported a CA key and a cert :)

When using OpenSSL, firstly a private key is generated, secondly a CSR is generated and thirdly a certificate is generated using CA key and certificate.

I would like to know, how to generate a certificate using a CA key and certificate?

Hello,

Is it possible to add a custom attribute named "CertificateTemplate" in a csr before signing?
It would be so that a Microsoft PKI would agree to create a certificate..
If it is possible, could you show me how?

Thanks in advance for your answer,