Anders Rundgren wrote:
> Dear Kai,
> I think I misunderstood your complaint a bit.
> Apparently Bob and Nelson think I'm wrong as well.
>
> So here we go again...
>
> Serial number + Issuer MUST indeed be unique within a CA.
The requirement is unique combination of (Issuer NAME, Serial Number).
Dear Kai,
I think I misunderstood your complaint a bit.
Apparently Bob and Nelson think I'm wrong as well.
So here we go again...
Serial number + Issuer MUST indeed be unique within a CA.
Therefore the following was interpreted as incorrect:
Issuer: Root
Serial: 1
Subject: Root
Issuer: Root
Ser
> Ironically, it is exactly the people who have maintained software
> that give the advice "if it ain't broke, don't fix it."
Never doubted this...
> The spirit of the advice is that changes, including bug fixes,
> sometimes introduce bugs. As the complexity of software grows,
> few people have
Nelson wrote:
>>> NSS (and therefor mozilla products) do not do automatic fetching of
>>> certificates at this point in time.
>
>>> Currently all protocols have a way of transmitting the necessary
>>> intermediate certificates, and mozilla products depends on these protocols.
>> In theory yes, in
>Any two certs with the same issuer must have different serial numbers.
I have never claimed anything else.
>This is a basic X509 requirement, violating this will cause you
>interoperability problems. If you reissue your CA cert, it must have a
>new number. If you spin up another CA with th
Anders Rundgren wrote:
Both your root.cert and cacert.cert seem to have same serial number and
issuer. That is forbidden.
AFAIK each CA has its own serial number space. This should make it OK
to reuse a serial number even within a CA hierachy. I would be an error if
I let the root sign
Kyle Hamilton wrote:
Converse: If it's confusing, it's broken. Maintenance is a primary
concern, and transparency is a primary concern in maintainable code.
If someone's digging deeply enough to get confused by it, and there's
inconsistency (aka obscurity) in the code that is examined when they
Neither RFC2511 or PKCS10 (Certificate Request specifications) mention
the use of SPKAC. I'm pretty sure that SPKAC doesn't fit within PKCS10
but I've only cursorily looked at RFC2511 so I'm not positive that a
SPKAC couldn't be hammered in there somewhere. I know that many toolkits
handle the
NSS 3.11.2 also enforces the FIPS password "quality" requirements.
Wan-Teh
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Alex wrote:
Thanks for your help. The problem has been solved by adding extern "C"
block. I'm very grateful. :-)
Glad to hear that's indeed the problem. All the NSS
headers should contain (the equivalent of)
#ifdef __cplusplus
extern "C" {
#endif
...
#ifdef __cplusplus
}
#en
Nelson,
I completely agree with you about this not having to be a priority.
Code transparency is definitely important, ambivalent/outdated code can
cause the introduction of new bugs down the road, but it's eventually
up to the NSS maintainers/contributors to decide what has higher
priority. This
Nelson B wrote:
So, at this point, the only remaining untested hypothesis I have is that
this is a difference between 3.11.2 and 3.11.3.
Or that Dave is an idiot...
I was running through all the commands here on a brand new set of db
files and it wouldn't let me change the password to "passwo
> Alex wrote:
>> I compiled nss on FreeBSD platform, and wrote a program .
>> My program use function SECU_ReadDERFromFile, like this
>>
>> #include "secutil.h"
>> ..
>> rv = SECU_ReadDERFromFile(&certDER, inFile, PR_TRUE);
>> ..
>>
>>
>> This function is in libsectool.a
>>
>> #nm libsectoo
On 9/26/06, Bob Relyea <[EMAIL PROTECTED]> wrote:
The only hard issue I see is getting a PKCS #11 mechanism for CFB mode.
Once that exists it should be realitively easy to add such a mechanism.
The primary changes would be in softoken, pk11wrap, and possibly adding
an OID in util/secoid.[ch].
I
14 matches
Mail list logo
