Closed Bug 271585 Opened 20 years ago Closed 20 years ago

Add UTN root CA certs to NSS

Categories

(NSS :: Libraries, enhancement, P2)

enhancement

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: hecker, Assigned: nelson)

References

Details

(Keywords: fixed-aviary1.0.2, fixed1.7.6)

Attachments

(5 files)

Per my comments in bug 242610 I'm approving addition of the UTN root CA
certificates to Mozilla. For more information, including the certs themselves
and their SHA-1 fingerprints, see bug 242610.
No longer blocks: 242610
Blocks: 242610
Added "CA" to bug summary so that it will show up in searches for "Add CA"
Priority: -- → P2
Summary: Add UTN root certs to NSS → Add UTN root CA certs to NSS
Target Milestone: --- → 3.10
I am about to attach two patches to this bug, one for NSS 3.9 branch,
one for the trunk.  Each of the patches will add all the root CA certs 
that are presently approved by Frank.  
Status: NEW → ASSIGNED
This patch should also be directly applicable to any othet mozilla
branches that contain copies of NSS derived from NSS 3.9.
This patch adds the same certs as the previous patch, but this patch 
is for the NSS trunk.
Comment on attachment 167308 [details] [diff] [review]
Add all remaining approved root CA certs to NSS 3.9 branch

Wan-Teh, please review
Attachment #167308 - Flags: review?(wchang0222)
Comment on attachment 167309 [details] [diff] [review]
Add all remaining approved root CA certs to NSS trunk

Wan-Teh please review
Attachment #167309 - Flags: review?(wchang0222)
Nelson, I had a recent email from the Comodo/UTN folks. All is unchanged from
before *except* that they would like the trust bits on *all* the certs set to
'all'. IIRC I previously had indicated that one of them was to be marked trusted
for S/MIME only. (My apologies for forgetting about this previously.)
Now, frank, why should a CA whose explicit purpose is to issue email 
certs be trusted to issue code signing certs?  
Do we want all email certs to also be code signing certs?
Do we want to erase any ability to distinguish among certs for 
different purposes?  
If we wish to continue to have separate certs for separate purposes,
and if this CA already has separate roots for separate purposes, 
then the justification for giving code signing trust to an email CA
cert is what, exactly?
There are several ways that a CA organization can segregate purposeful
trust among the certs that they issue.  Here are some of the ways they 
can do it:

1. have separate root CA certs, one for each purpose, each one of which
is trusted for a single purpose.  Those root CAs then issue certs that
have no extensions that further limit their purpose.  The leaf certs
appear to be good for everything, but when you go look at their issuer
you find that the issuer is only trusted for one thing, ergo the leaf
cert is also only good for one thing.

2. Have one root CA that is trusted for all purposes, that issues
intermediate CA certs, each of which has exntensions that limit the 
purposes for which it is trusted.  The intermediate CAs may then issue
certs that appear to have no restriction on purpose, but (as with case 1
above), when validating the chain, the relying party finds that the issuer
(intermediate) is only trusted for limited purposes, and so the leaf cert 
is only good for those limited purposes also.

3. Have one (or more) issuing CAs that are trusted for all purposes, but
those issuers all put extensions in every leaf cert they issue stating
exactly what purpose the leaf is for.  

Now, suppose, under case 1 above, that a CA has a cert that says it is 
only good for email, and it issues certs that have no extensions that 
further restrict their abilities.  But the root CA cert's trust flags 
get set to trust that cert for ALL capabilities, not just for email.
The consequence of this is that the certs issued by that CA are all 
useable as code signing certs.  

The moral of this story is this: we should not mark root CA certs as 
trusted for code signing UNLESS we know that the CA's audited CPS says
that the CA will take adequate steps, through extensions in intermediate
and/or leaf certs, to distinguish code signing certs from non-code-signing
certs.  In other words, we should give code signing ability to CAs in 
cases 2 and 3 above, not in case 1.  And I interpret the content of the 
UTN email root cert as suggesting that it is case 1.

OK, I realize that this comment probably really belongs in bug 233453.
I think that our policy should state that, before we will give a single
root CA cert more than one kind of trust (SSL, email, code signing), we 
will require the CA to demonstrate that they are properly segregating
capabilities through the use of extensions in intermediate and/or leaf
certs, and/or that their audited CPS states that they will do so, and
how they will do it.  Otherwise, someday we're going to find that some
CA's email certs are also all code signing certs, and our code signing
story will be dead.
The comments above appear to concern only code signing, but they are also
applicable to SSL service trust and email trust.  Generally, however,
the amount of verification of identity done by CAs is the greatest for 
code signing, and the least for email.  So, IMO, we should take special
care to ensure that we do not allow certs that were intended to be email
certs only to also work as SSL server or code signing certs.  One way 
we could fail to take that care is to give SSL server trust or code
signing trust to a root CA cert whose own extensions clearly identify
it as not being intended for those purposes.  
Per comments above, and in private email, I have revised the above 
patch to correct the spelling and capitalization of the nicknames,
and to alter the trust flags for some of the CAs.  

Except for the trust flags and nicknames, the rest of the large 
patch is computer generated, so rather than repeat the entire large
patch to show these changes, I will instead show below the output
of certutil -L with my latest patch in place.  This shows the nicknames
and trust flags.  

Builtin Object Token:QuoVadis Root CA                        C,C,C
Builtin Object Token:Security Communication Root CA          C,C,C
Builtin Object Token:Sonera Class 1 Root CA                  C,C,C
Builtin Object Token:Sonera Class 2 Root CA                  C,C,C
Builtin Object Token:Staat der Nederlanden Root CA           C,C,C
Builtin Object Token:TDC Internet Root CA                    C,C,C
Builtin Object Token:TDC OCES Root CA                        C,C,C
Builtin Object Token:UTN DATACorp SGC Root CA                C,p,p
Builtin Object Token:UTN USERFirst Email Root CA             p,C,p
Builtin Object Token:UTN USERFirst Hardware Root CA          C,p,p
Builtin Object Token:UTN USERFirst Object Root CA            p,p,C

Frank, since the AOL folks are out for a few days, I'm going to 
let you approve (or not) the changes based on the above certutil 
output.  If you approve, then I will checkin tonight when I get home.
I'm sorry, I won't be able to review this in time for you to check it in
tonight. I'll look at it tomorrow morning. One question: could you please
explain the representation of the trust bits (e.g., "C,p,C")?  (I guess I could
look at the certuil docs -- please feel free to provide a URL and tell me to RTFM.)
Nelson, thanks for the explanation via email re the "C" and "p". For the rest of
the world, here's what's going on: The 'p's are somewhat spurious; in this
context they simply mean that the trust bit for a particular purpose is not set.
The 'C' is the important bit (pardon the pun). A setting of 'C,C,C' means the
root CA certificate is "trusted" (in a NSS/Mozilla/etc. context) for all
purposes. 'C,p,p' means trusted for SSL server purposes only, 'p,C,p' means
trusted for S/MIME email purposes only, and 'p,p,C' means trusted for object
signing only.

Now on to the certs themselves. All names look OK, the only remaining question
is the trust bits on the UTN certs. This is a balance between the technical
considerations of limiting trust to the types of certificate that the CA has
traditionally issued and is likely to issue in the furure, and the more
marketing consideration of giving CAs the latitude to expand the types of certs
they issue without having to go back to us to have trust bits changed.

We've been relatively liberal in the past in marking trust bits as requested by
CAs, often setting trust bits to 'all' as requested even in cases where it was
apparent that the CA never had issued a particular type of cert and never was
likely to. I believe we need to tighten this up, but I also think it's unfair to
Comodo/UTN to make them the test case on this, in large part I've never been
that explicit in what our policy actually was, nor have I been rigorous in
enforcing a policy. Also, Comodo/UTN has been more helpful than most CAs in
providing the detailed information about their CAs' uses needed to set trust
bits, and thus somewhat perversely they're being held to a tighter standard than
CAs who are not so forthcoming.

So, Nelson, in the short-term I'm approving this patch, with the exception that
I'd like you to set the trust bits for the UTN CAs to 'all' ('C,C,C') as is
being done for the other CAs.

In the longer-term I want us to tighten up our policy on trust bits, and make
our policy more explicit. I think this entails at least two things:

First, I will make a concerted effort up-front to determine the purposes for
which a CA is being used, and then recommend setting trust bits to the minimum
necessary to match those purposes. If a CA isn't providing enough information to
make this determination then I will hold up approval until it does.

Second, we need to plan how we're going to quickly change trust bits as needed
in order to reflect new circumstances. This might include turning trust bits off
to address potential security issues, or turning them on to reflect expansion in
the types of certs issued by a CA. For the foreseeable future we'll need to do
this via new releases of NSS and update releases of Mozilla, et.al., but maybe
we can do better than that at some point, e.g., through some sort of dynamic
update mechanism. (I've already mentioned this in relation to speeding the
addition of new CA certs.)

One point brought up by the Comodo/UTN folks was that for an organization
running multiple root CAs, it might be necessary for one of the CAs to take over
functions for another of the CAs, e.g., in the event that one of the root CA
certs had to be revoked; thus it would be better it set trust bits to 'all' for
all the organization's CAs. Notwithstanding my recommendation above re the UTN
root certs, I don't really accept this argument: If a CA has problems sufficient
to revoke its root cert, then we'd presumably treat this like other potential
security vulnerabilities and release an updated version of NSS and then Mozilla,
etc., to correct the problem, and we could update trust bits for an
organization's other CAs at the same time.

The major counter-argument I can see is that it might take some time to do the
update, and in the meantime the other CAs wouldn't be able to fully take over
the revoked CA's functions as far as Mozilla users were concerned. This
reinforces the idea of planning for quick updating of CA-related information.
Frank, UTN certs all have extensions in them that say precisely what they're
valid for.  MOST PKI software in the world will honor those self-imposed 
limitations.  That's a safety feature of X.509 PKI hierarchies.  It means
that if the CA ever issued a cert and forgot to limit the uses of that 
cert with an EKU, the abilities of that cert will nonetheless be limited
according to the STATED PURPOSE of the issuing CA.  

Our trust flags are capable of being overrides.  They can give a cert 
abilities that are not listed on its face.  In this case, you're asking
me to override the limitations that are built into all the UTN root CA
certs themselves.

As I explained in comment 9 above, if UTN has published ANY EE (leaf, 
end-user) certs that do NOT have EKU extensions that explicitly prohibit
their use as code signing certs, and we apply the requested trust flags
to their roots, then we will have just turnd all those (say) email 
certs (that lack EKUs) into code signing certs.  That would be a disaster.
It would make code signing meaningless for every user of a browser that
trusts that email root CA.  (I'm picking on the email CA, but the issue
is also valid for other CAs that are not code signing CAs.)  

At this point, we haven't even established that UTN routinely puts EKUs
into those email certs.  Maybe they do, maybe they don't.  Given that 
the roots have EKUs, they wouldn't need to (with normal PKI software that
honors a CA cert's own EKUs).  Maybe they never have.  

IMO, it would be irresponsible of us to override the EKUs in these 
apparently carefully crafted root CA certs, until we know that (a)
the already issued certs have EKUs and (b) the audited CPS says that
the EE certs will continue to have EKUs.  

AFAIK, we have never before had a case where a CA sent us a root cert
that said, on its face, that it was limited to a certain purpose, or 
set of purposes, and then asked us to override those purposes, 
enabling all purposes -- especially not for a root CA cert that had
already been used (was not a brand new CA).  I do not that that what
we've done in the past is equivalent to such overrides, and I think 
it sets a bad precedent to start doing such overrides now without any
better reason than has been given to me to date.
I have one modification to the cert processing that nelson describes above:

  For historical reasons, code signing privellege does not automatically flow to
subordinates. When code signing was added, there wasn't a well defined way to
limit trust on subordinate CA certificates. At that time there were netscape
specific ways of specifying a particular cert was a subordinate CA, and some
CA's that wanted to issue Signing certs had already issued such subordinate.
Because of this Jeff Weinstein required the code signing extension on each and
every subordinate. Unless we have changed that semantic, Code Signing still
follows that semantic.

Another bit of history to explain why trust is an override:

In the early days some very popular CA's had very old root certs which had not
extensions labelling them as CA certs. Because of this we needed to override the
processing of those certs when determining trust. (this also allows us to
override trust at from a subordinate rather than a whole chain).

bob
Bob what you say is true for Netcape's old "object signing", but IINM,
not for "code signing" (different OID).  Please double check.
Attachment #167309 - Flags: review?(wtchang) → review+
Comment on attachment 167308 [details] [diff] [review]
Add all remaining approved root CA certs to NSS 3.9 branch

Both approvals are assuming it's OK to distinguish the trust on the UNC certs.

It seems to me that getting this patch in at this point is preferable to
waiting on the final disposition of setting all the trust bits on the UNC
tokens.
Attachment #167308 - Flags: review?(wtchang) → review+
Thanks, I expect to checkin tonight, unless I hear "stop" before then.
Nelson, I don't claim to be an expert on the EKU issue, so I will defer to your
technical judgement on this point. Let's go ahead and do the patch with CA names
and trust bits as you outlined originally; if this proves to be a problem we can
update things later.

(In any case these certs won't show up in a client release immediately; given
release schedules and the closed window for TB 1.0 changes my current plan is to
file bugs to get the CA cert patch into Mozilla 1.8 and post-1.0 releases of
Firefox and Thunderbird.)
Thanks, Frank.
We can certainly come back and add more trust flags in a later release.  
I think it's best to add the certs with conservative trust flags that 
match the capabilities stated in the certs themselves.  Then if we later
decide that we really do want to override and extend those capabilities
with trust flags, we can do that.  
Trunk checkin:
mozilla/security/nss/lib/ckfw/builtins/certdata.c,v  <--  certdata.c
new revision: 1.30; previous revision: 1.29
mozilla/security/nss/lib/ckfw/builtins/certdata.txt,v  <--  certdata.txt
new revision: 1.31; previous revision: 1.30
mozilla/security/nss/lib/ckfw/builtins/nssckbi.h,v  <--  nssckbi.h
new revision: 1.12; previous revision: 1.11

NSS 3.9 branch checkin:
mozilla/security/nss/lib/ckfw/builtins/certdata.c,v  <--  certdata.c
new revision: 1.27.16.2; previous revision: 1.27.16.1
mozilla/security/nss/lib/ckfw/builtins/certdata.txt,v  <--  certdata.txt
new revision: 1.28.16.2; previous revision: 1.28.16.1
mozilla/security/nss/lib/ckfw/builtins/nssckbi.h,v  <--  nssckbi.h
new revision: 1.6.16.3; previous revision: 1.6.16.2

For testing purposes, for a short time (weeks), a copy of a debug build
of nssckbi.dll with these certs added, built from the NSS 3.9 branch,
may be obtained for testing at http://nelson.bolyard.com/mozilla/nssckbi.dll

I invite the representatives of the various CAs to download it and test it.
Please add any comments (reflecting success or failure) to this bug.
It passes my tests.  

I will add another attachment to this bug, which is a zip file containing
the CA certs and the shell script that I used to add them to nssckbi.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Target Milestone: 3.10 → 3.9.5
This zip file contains all the DER certs that I added to the trunk
and to the 3.9 branch.	It also contains the shell script that I
ran to add them.  The same files and same script were used on both
trunk and branch.  The only difference was the addbuiltin program
used by the script, which was the 3.9 version for the branch, and
the trunk version for the trunk.
Attachment #167308 - Flags: approval1.7.5?
Attachment #167308 - Flags: approval-aviary?
We (ICTU) tested the "Staat der Nederlanden Root CA" in Firefox 1.0 and
Thunderbird 1.0 (original bug
https://bugzilla.mozilla.org/show_bug.cgi?id=243424). In Firefox we tried to
make a SSL connection with a website that uses the "Staat der Nederlanden Root
CA". In Thunderbird we tried to verify a signed e-mail. The results are as follows:

I.
Firefox: There where no problems while establishing an SSL connection with Firefox. 


II.
Thunderbird: An error message in the Thunderbird client showed up saying "Could
not verify this certificate because the issuer is not trusted." We had to import
the "Staat der Nederlanden Root CA" manually (and other intermediate
certificates) in Thunderbird. The certificate viewer in Firefox says: "This
certificate has been verified for the following uses: SSL Certificate
Authority." We want ALL the certificate uses to be present (i.e. websites,
e-mail users and software developers). 


III.
With regard to the Extensions fields in the certificate viewer:

1. Basic constrains: shows a hexadecimal value, i.e. not human readable
2. Certificate Policies: shows a hexadecimal value, i.e. not human readable
3. Certificate key usage: shows only "Certificate Signing". Key usage "CRL
Signing" should also be present. 
4. Subject key identifier: should only show
A8:7D:EB:BC:63:A4:74:13:74:00:EC:96:E0:D3:34:C1:2C:BF:6C:F8, but Firefox shows: 
04:14:A8:7D:EB:BC:63:A4:74:13:74:00:EC:96:E0:D3:34:C1:2C:BF:6C:F8

These extension fields should show something like this (results with OpenSSL):

1. Basic Constraints:
   CA:TRUE
2. Certificate Policies:
   Policy: Any Policy
   CPS: http://www.pkioverheid.nl/policies/root-policy
3. Certificate Key Usage: critical
   Certificate Sign, CRL Sign
4. Subject Key Identifier:
A8:7D:EB:BC:63:A4:74:13:74:00:EC:96:E0:D3:34:C1:2C:BF:6C:F8


IV.
Some more general questions:

a. Why don't Thunderbird and Firefox use the same (shared) certificate store?
Now both applications have their own nssckbi.dll file.
 
b. It was not possible to verify a signature in Thunderbird after importing the
"Staat der Nederlanden Root CA", because no intermediate certificate authorities
where in the certificate store. After manually importing them, the signature
could be succesfully verified. Is there a possibility to automatically add these
intermediate authorities when you sign an e-mail in Thunderbird?

I hope the above is clear to you. Thanks for your actions. In case you have any
questions, please let us know.
> I. Firefox: There where no problems while establishing an SSL connection 
> with Firefox. 

Thanks for testing and confirming that.  

> II. Thunderbird: An error message in the Thunderbird client showed up 
> saying "Could not verify this certificate because the issuer is not 
> trusted." 

Perhaps you replaced the nssckbi.dll file in your Firefox installation,  
but not in your TBird installation?  That would be my guess.  
Perhaps TBird was still running when the DLL was replaced, so it was
still using the old one?  That's another possibility.  
If both FF and TB have their nssckbi.dll file updated, and are both 
restarted, they should both see the new roots in them.  

> III. With regard to the Extensions fields in the certificate viewer:

There are lots of issues with the mozilla/TB/FF cert viewer.  
They are generic issues that apply to all certs with the relevant
cert extensions, and are not specific to the Nederlands cert.  
They would be the subject of another bug report.

In any case, the code in Moz/TB/FF that decides on cert validity does 
not depend on the cert viewer, so even if the cert viewer cannot 
satisfactorily display all the parts of the cert, that does not mean
that mozilla will not properly use those parts.

> IV. Some more general questions:
> 
> a. Why don't Thunderbird and Firefox use the same (shared) certificate store?
> Now both applications have their own nssckbi.dll file.
>  
> b. It was not possible to verify a signature in Thunderbird after 
> importing the "Staat der Nederlanden Root CA", because no intermediate 
> certificate authorities where in the certificate store. After manually 
> importing them, the signature could be successfully verified. 

Those intermediate CA certs should be part of the messages whose signatures
are being verified.  

The sender of a signed message needs those certs in his cert store, so that
he can send them along with the signed message.   The sender should get
those certs when he gets his own cert from the CA.  The CA that issues his 
own cert should also download the intermediate CAs to him when he gets his 
own cert.

The recipient of a signed message does not need the intermediate CA certs
in his cert store, because they should be in the signed message.   If 
they are not in the signed message, the sender has erred.  Perhaps the
sender's CA did not download the intermediate CA certs when it downloaded
the user's own email cert.

Thanks for your quick reply.

> > II. Thunderbird: An error message in the Thunderbird client 
> showed up 
> > saying "Could not verify this certificate because the issuer is not 
> > trusted." 
> 
> Perhaps you replaced the nssckbi.dll file in your Firefox 
> installation,  
> but not in your TBird installation?  

A. No, the problem is that TBird does not validate the certificate chain. We
have a certificate hierarchy that consists of four CA certificates. When I
import the CA certificate that issued the end-user certificate TBird validates
the signature, even without a Root CA in the certificate store! Maybe you could
reproduce this and after you have confirmed, we will make a seperate bug report
for this.

> > III. With regard to the Extensions fields in the certificate viewer: 
> 
> There are lots of issues with the mozilla/TB/FF cert viewer.  
> They are generic issues that apply to all certs with the relevant 
> cert extensions, and are not specific to the Nederlands cert.  
> They would be the subject of another bug report. 
  
B. OK, we will make a new bug report with the certificate viewer issues on the
extension fields. Or are you aware of an existing bug report on this?

Can we consider the message on verification in the cert viewer as a bug too?
Because, although the Dutch root cert is verified for all uses, the cert viewer
only shows: "This certificate has been verified for the following uses: SSL
Certificate Authority." (see attachment "Staat der Nederlanden.jpg"). Strangely
enough, for other certs, like Thawte, the cert viewer shows verification for all
uses (see attachment "Thawte.jpg"). 


C. Besides the above issues we experienced problems with importing a pkcs#7
file. Firefox and Tbird seem to randomly import just one cert instead of the
whole chain. Would you recommend to file a seperate bug for this too?

D. Finally, we are wondering why the Mozilla apps don't use the same (shared)
certificate store? Is there any particular reason? We believe it would be a good
idea to have one cert store that is used by all Mozilla apps and that can be
used by other applications too. Please, let us know if we are wrong.

Thanks again for your reply and actions.
Just as a comparison with the information the cert viewer shows for the Dutch
Root cert.
The issues with TBird's UI reported above are WAY outside the scope of this 
completed NSS bug (enhancement) report/request.  They are probably important 
issues, but this bug report isn't the place to discuss them.  
I suggest you raise your concerns in 
news://news.mozilla.org:119/netscape.public.mozilla.crypto 
Comment on attachment 167308 [details] [diff] [review]
Add all remaining approved root CA certs to NSS 3.9 branch

1.7.5 has shipped. Moving request to 1.7.6.
Attachment #167308 - Flags: approval1.7.5? → approval1.7.6?
Mass re-assign of 3.9.5 fixed bugs to 3.9.6 , since we built 3.9.5 with the same
source tree as 3.9.4 .
Target Milestone: 3.9.5 → 3.9.6
Comment on attachment 167308 [details] [diff] [review]
Add all remaining approved root CA certs to NSS 3.9 branch

Too late for 1.7.6, and removing obsoleted approval-aviary request (aviary
approvals now need to use aviary1.0.x flags)
Attachment #167308 - Flags: approval1.7.6?
Attachment #167308 - Flags: approval1.7.6-
Attachment #167308 - Flags: approval-aviary?
Chris, the patch was checked in, and this bug marked resolved in December 2004.
There have been two NSS releases made since then that included it.
So, just how, exactly, was it too late?
Comment on attachment 167308 [details] [diff] [review]
Add all remaining approved root CA certs to NSS 3.9 branch

Chris, Frank,

You two need to discuss these new root CA certs
before the Mozilla Foundation releases Mozilla 1.7.6
and Firefox 1.0.1.

These root CA certs missed the Firefox 1.0 deadline.
I remember that we told the CAs that we will add
their certs to the next Firefox update.

These root CA certs have been tested on the Mozilla
trunk for a while as Nelson pointed out.
Attachment #167308 - Flags: approval-aviary1.0.1?
Comment on attachment 167308 [details] [diff] [review]
Add all remaining approved root CA certs to NSS 3.9 branch

Firefox 1.0.1 shipped last week.  Minusing.
Attachment #167308 - Flags: approval-aviary1.0.1? → approval-aviary1.0.1-
The certs in question (for this particular bug report) have been in 
the NSS 3.9 branch and on the trunk since December.  I believe
NSS_CLIENT_TAG includes them.  (not sure though.)  
It's completely unclear to me in what way they were "too late".

If firefox shipped without them, then someone in firefox land 
apparently didn't take them.  IIRC, Frank filed a bug about this 
against firefox months ago, and someone from firefox closed it saying
that no work needed to be done for it.  WTF?
Attachment #167308 - Flags: approval-aviary1.0.2?
Comment on attachment 167308 [details] [diff] [review]
Add all remaining approved root CA certs to NSS 3.9 branch

> It's completely unclear to me in what way they were "too late".

Basically, Firefox 1.0.1 is already out, Mozilla 1.7.6 is about to go out.  We
can get this into 1.7.7 and firefox 1.0.2.  I will approve this for aviary
1.0.2.	Please hold off on checking into the 1.7 branch for now though until
1.7.6 is done.
Attachment #167308 - Flags: approval-aviary1.0.2? → approval-aviary1.0.2+
Ah HA!  Your answer reveals the problem, I think. You wrote:
> Please hold off on checking into the 1.7 branch 

The NSS team supports the NSS trunk and the NSS branches, only.
For other branches, it is the responsibility of those branch owners
maintainers to keep their branches in sync with NSS.
NSS folks do not, as a rule, checkin on those other branches.

If the NSS changes were "too late" because you were waiting for an NSS 
developer to checkin on some non-NSS branch, they will always be too late.  
(haven't we had this discussion before?)
The problem was the failure to use the appropriate
tools in Bugzilla to get this on mozilla.org drivers'
radar.

Chris, please advise how to get this patch into
"aviary 1.0.2" and "aviary 1.1".  (which cvs
branches, etc.)  You can consider me a Mozilla
developer.
Flags: blocking-aviary1.1?
Flags: blocking-aviary1.0.2?
Wan-Teh, I believe this is the wrong bug to be marked blocking aviary*.
Bug 272901 appears to me to be the right one.
Comment on attachment 167308 [details] [diff] [review]
Add all remaining approved root CA certs to NSS 3.9 branch

Approval flags shouldn't have been migrated with the blocking flags.
Attachment #167308 - Flags: approval-aviary1.0.3+ → approval-aviary1.0.2+
Comment on attachment 167308 [details] [diff] [review]
Add all remaining approved root CA certs to NSS 3.9 branch

a=dveditz for 1.7.6, released delayed and will now match 1.0.2
Attachment #167308 - Flags: approval1.7.6- → approval1.7.6+
*** Bug 272901 has been marked as a duplicate of this bug. ***
Comment on attachment 167308 [details] [diff] [review]
Add all remaining approved root CA certs to NSS 3.9 branch

I checked in the new root CA certs (nssckbi module
version 1.42) on the AVIARY_1_0_1_20050124_BRANCH
(Aviary 1.0.2) and the MOZILLA_1_7_BRANCH (Mozilla
1.7.6).
Flags: blocking-aviary1.1?
Flags: blocking-aviary1.0.3?
Flags: blocking-aviary1.0.2+
Verified with Firefox 1.0.2 that the UTN root CA
certs are in the "Builtin Object Token" with the
following trust settings:

The UTN root CA certs have been added with the following
trust settings.

UTN-USERFirst-Client Authentication and Email:
  This certificate can identify mail users.

UTN-USERFirst-Hardware:
  This certificate can identify web sites.

UTN - DATACorp SGC:
  This certificate can identify web sites.

UTN-USERFirst-Object:
  This certificate can identify software makers.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.