| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
to key_constraints.{h,cpp} in cert/x509. Move the X509_Encoding enum
to x509_key.h
Constify argument to X509_Object::check_signature, accidental ommision
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
restrictions on the validation process. Currently these are if
revocation information (CRL or hypothetically OCSP) is required, and
what hashes to trust. Default trusted hashes are SHA-1 and SHA-2. This
will also be used for policy restrictions, likely other things.
The result enum is now a member of Path_Validation_Result
Remove the usage restrictions enum. It is easier, for applications
that actually care about one of these, to just check the extended
constraint attribute on the final result, if everything else
validates.
|
|
|
|
|
| |
would be fixed but it's quite hard to do, makes more sense for now to
merge then back into one big x509 blog.
|
|
|
|
|
| |
got the answer wrong before. Still no policy or name constraints
support, though.
|
|\
| |
| |
| |
| |
| | |
78a772f3855abc89c3eed2fe8735e8438463399c)
to branch 'net.randombit.botan.x509-path-validation' (head 9e678a8bc141087439a1238783006e9892a98450)
|
| |\
| | |
| | |
| | |
| | |
| | | |
8efb138f9a7c0b02429372a9c4e4f6614c5a6b87)
to branch 'net.randombit.botan.x509-path-validation' (head af3daa43e17054ae367c02de09f77ab9e5f8136f)
|
| | | |
|
| | |\
| | | |
| | | |
| | | |
| | | |
| | | | |
8453f801979d78b448a2aff80d2042715a42e843)
to branch 'net.randombit.botan.x509-path-validation' (head 084e8139f4b131b5aab6b6359e59324d7681488f)
|
| | |\ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
a4ea4629f9caa98bd72b87de6050d9e52190d09a)
to branch 'net.randombit.botan.x509-path-validation' (head 6217561bf05ef77a49ab2ebe39f16bf7133a005a)
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
certificate policies extension, though it's really not supported
at all.
Remove test code from secmem.h
Fix building the examples
|
|/ / / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Fix BigInt::get_substring when length is equal to 32 - an overflow
would cause the mask to be equal to 0 thus producing nothing at all.
Disable CVC by default, it's not ready for prime time in any sense.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
and a random number generator, and the other taking a group and a
preset private key value. The DL private keys instead have on
constructor for this; if the x value is zero, then a new random key is
created. For consistency, do this with ECC as well.
ECDH actually didn't have one of these constructors, forcing you to
either load from PKCS #8 or else use a random key.
Rename EC_Domain_Params to EC_Group, with a typedef for compatability.
More doc updates.
Update mtn ignores for Sphinx output
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Reduce size of serial numbers of new certs from 256 to 128 bits;
2**64 certs is _probably_ sufficient, given that it would take hundreds
of exabytes of storage to hold that many certificates. :)
|
| |_|/
|/| |
| | |
| | | |
Make comment clearer on how to enable stlport4 in Sun C++
|
| |/
|/| |
|
| | |
|
| |
| |
| |
| | |
Avoid using auto_ptr in the CVC headers.
|
| | |
|
| |
| |
| |
| | |
integer values. Update callers.
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| | |
collide. One might, theoretically, generate 2^64 certificates with a
single CA (say, for each particle in a planet wide cloud of smart
dust), but 2^128 does not seem possible.
|
| |
| |
| |
| | |
The x509info example now just calls that
|
| | |
|
| |
| |
| |
| | |
deprecation warnings (at least for GCC and VC++). Use in some places.
|
|/
|
|
|
| |
Remove version of search_map that returns two distinguishing results;
only used in one place, and that can be replaced by a call to count()
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
returns the hash function that was used to create the
signature. Useful for a future X509 path validator that inform the
user which hash(es) they are relying on and/or allowing the ability to
reject hashes which are undesirable (MD2, MD5, etc)
|
|
|
|
|
| |
particular is precious. Really these could probably just as easily be
std::vectors since even zeroizing the memory isn't relevant here.
|
|
|
|
|
| |
easier to implement without requiring in-memory linear searching (eg a
flatfile store or SQL database with indexes).
|
| |
|
| |
|
|
|
|
| |
dependent right now.
|
| |
|
| |
|
|
|
|
|
| |
representation (rather than in an interator context), instead use &buf[0],
which works for both MemoryRegion and std::vector
|
| |
|