Beginning on October 25th, 2016, Persona will no longer be an option for authentication on BMO. For more details see Persona Deprecated.
Last Comment Bug 383601 - Need some method for validating certificates used for PKINIT
: Need some method for validating certificates used for PKINIT
Status: NEW
Product: NSS
Classification: Components
Component: Libraries (show other bugs)
: unspecified
: All All
: -- enhancement (vote)
: ---
Assigned To: nobody
Depends on:
  Show dependency treegraph
Reported: 2007-06-07 07:33 PDT by Nalin Dahyabhai
Modified: 2015-01-12 09:11 PST (History)
2 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---

My test CA certificate, binary format. (771 bytes, application/octet-stream)
2007-06-20 12:18 PDT, Nalin Dahyabhai
no flags Details
My test client certificate, binary format. (845 bytes, application/octet-stream)
2007-06-20 12:18 PDT, Nalin Dahyabhai
no flags Details

Description Nalin Dahyabhai 2007-06-07 07:33:49 PDT
User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20070603 Fedora/ Firefox/
Build Identifier: nss-3.11.7

I'm implementing PKINIT using NSS, and am attempting to use CERT_VerifyCertificate() to verify client and KDC certificates.

RFC4556 doesn't require that client and KDC certificates also be SSL
or email certificates -- it only specifies that the certificate be
somehow bound to a Kerberos principal name, but leaves a large portion
of the rest of requirements up to local policy.

In order to use NSS to verify the certifying path, I currently need
to pass a non-zero requiredUsage value to CERT_VerifyCertificate(),
though an acceptable PKINIT certificate might not match any of the
defined usages, so my routines are rejecting client certificates which
are supposed to be accepted.

Can some facility be added to make this possible?

Reproducible: Always
Comment 1 Nelson Bolyard (seldom reads bugmail) 2007-06-07 20:04:36 PDT
>  my routines are rejecting client certificates 
1) what cert usage(s) are you telling CERT_VerifyCertificate() to look for?
2) What are the values of the Key Usage (KU) and Extended Key Usage (EKU) 
extensions (if any) in the "rejected' certificates?
Comment 2 Nalin Dahyabhai 2007-06-08 07:48:32 PDT
When I'm verifying a client certificate, I'm using certUsageSSLClient, and
for a KDC I'm using certUsageSSLServer.  A typical rejected certificate contains key usage with only the digitalSignature bit set and the PKINIT client EKU, though my reading of the RFC suggests that PKINIT doesn't strictly require either of those, and should be capable of accepting a certificate with neither.
Comment 3 Nelson Bolyard (seldom reads bugmail) 2007-06-08 10:25:06 PDT
What is the error code from CERT_VerifyCertificate()?
I'll bet it has nothing to do with KU or EKU.
I'll bet it is untrusted issuer (or unknown issuer).
Comment 4 Nalin Dahyabhai 2007-06-08 11:59:01 PDT
The verify log shows an error at the client certificate with error SEC_ERROR_INADEQUATE_CERT_TYPE.  The root certificate has been imported
with trust flags "CT,,", so I think it's properly marked.
Comment 5 Julien Pierre 2007-06-13 14:56:13 PDT

Can you attach  the cert chain ? Individual DER files for each cert would be fine.
Comment 6 Nalin Dahyabhai 2007-06-20 12:18:02 PDT
Created attachment 269111 [details]
My test CA certificate, binary format.
Comment 7 Nalin Dahyabhai 2007-06-20 12:18:26 PDT
Created attachment 269112 [details]
My test client certificate, binary format.
Comment 8 Nalin Dahyabhai 2007-06-20 12:19:45 PDT
Sorry for the delay, I wanted to double-check that these were acceptable to at least one other PKINIT implementation (in this case, Heimdal's) before attaching
them as data.
Comment 9 Julien Pierre 2007-06-21 17:53:08 PDT
Thanks for the certs, Nalin.
Indeed, we trip on KU/EKU errors with all usages.

From RFC4556 :

 The KDC MAY require the presence of an Extended Key Usage (EKU)
   KeyPurposeId [RFC3280] id-pkinit-KPClientAuth in the extensions field
   of the client's X.509 certificate:

       id-pkinit-KPClientAuth OBJECT IDENTIFIER ::=
         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
           pkinit(3) keyPurposeClientAuth(4) }
              -- PKINIT client authentication.
              -- Key usage bits that MUST be consistent:
              -- digitalSignature.

 The digitalSignature key usage bit [RFC3280] MUST be asserted when
   the intended purpose of the client's X.509 certificate is restricted
   with the id-pkinit-KPClientAuth EKU.

So, it seems we would need some new NSS certificate usage that would map to digitalSignature only.
Comment 10 Nelson Bolyard (seldom reads bugmail) 2007-06-21 18:15:14 PDT
IMO, the text quoted in comment 9 says (boiled down here):
  When the cert contains a EKU with the special id-pkinit-KPClientAuth OID,
  then it must also contain KU that is consistent with digitalSignature.
  (that is, it must not contain KU that is inconsistent with digitalSignature).

So, I think this identifies the need for a new NSS cert usage that specifies
the EKU id-pkinit-KPClientAuth.  This would be a usage parallel to NSS's
existing usages of SSL, EMAIL, and object signing, IINM.

Note You need to log in before you can comment on or make changes to this bug.