383601 - Need some method for validating certificates used for PKINIT

Status: RESOLVED WONTFIX

(NSS :: Libraries, enhancement, P3)

Description

[Nalin Dahyabhai]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.4) Gecko/20070603 Fedora/2.0.0.4-2.fc8 Firefox/2.0.0.4
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)]

>  my routines are rejecting client certificates 
Questions:
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]

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)]

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]

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]

Nalin,

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

Comment 6

[Nalin Dahyabhai]

Attachment: My test CA certificate, binary format.

Comment 7

[Nalin Dahyabhai]

Attachment: My test client certificate, binary format.

Comment 8

[Nalin Dahyabhai]

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]

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)]

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.