Need some method for validating certificates used for PKINIT



10 years ago
3 years ago


(Reporter: Nalin Dahyabhai, Unassigned)


Firefox Tracking Flags

(Not tracked)



(2 attachments)



10 years ago
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
>  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

10 years ago
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.
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

10 years ago
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

10 years ago

Can you attach  the cert chain ? Individual DER files for each cert would be fine.

Comment 6

10 years ago
Created attachment 269111 [details]
My test CA certificate, binary format.

Comment 7

10 years ago
Created attachment 269112 [details]
My test client certificate, binary format.

Comment 8

10 years ago
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

10 years ago
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.
Ever confirmed: true


10 years ago
OS: Linux → All
Hardware: PC → All
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.
You need to log in before you can comment on or make changes to this bug.