Subject: RE: Pkinit-23 comments: InitialVerifiedCAs

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Wed, 9 Feb 2005 12:29:35 -0800

Sam Hartman wrote:
> I find this argument compelling.

Me too.

 draft -24 was submitted earlier today, and changes were made to make
issuerAndSerial and subjectKeyIdentifier optional.

Draft -24 should give us a good base line, please review -24 when it
comes out. 

Thanks,

-- Larry

-----Original Message-----
From: Sam Hartman [mailto:[email-masked]] 
Sent: Wednesday, February 09, 2005 12:27 PM
To: [email-masked]
Cc: Liqiang(Larry) Zhu; [email-masked]; [email-masked]
Subject: Re: Pkinit-23 comments: InitialVerifiedCAs

>>>>> "Martin" == Martin Rex <[email-masked]> writes:

    Martin> Unless the PKINIT spec wants to make PKI and CMS mandatory
    Martin> to implement for *ALL* kerberized applications through the
    Martin> back door, it should stick to a list of plain and simple
    Martin> DNames for the list of TrustedCAs, which is something that
    Martin> Applications may be able to handle with a fairly small
    Martin> amount of changes, in case they do handle transited realms
    Martin> today.

    Martin> I can not see how a kerberized application could handle
    Martin> issuerAndSerial or subjectKeyIdentifier without getting
    Martin> intimate with PKI/CMS.

I find this argument compelling.

Also keep in mind that it is the named entity that is being trusted, not
some particular key.

--Sam

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Fri, 18 Feb 2005 08:43:51 -0800

The client is able to re-construct all the information Martin you are
asking for because the client has the invalid certificate locally. It is
beyond the scope of this document how the client computes the error
message and deals with I10N implications.

No change will be made with regarding to this thread.

-- Larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Sam Hartman
Sent: Friday, February 11, 2005 11:49 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: Pkinit-23 comments: InitialVerifiedCAs

    >>  >>>>> "Martin" == Martin Rex <[email-masked]> writes:
    Martin> Coming back to my first/other related concern about the
    Martin> contents of TD-INVALID-CERTIFICATES.
    Martin> I would like to see a requirement to include the
    Martin> subjectDName of the offending certificate (or each
    Martin> certificate if the KDC complains about more than one).  I
    Martin> don't mind if there are additional identifiers for a
    Martin> certificate included.
    >>  I have no objection to this provided that we give advice for
    >> what to do if there is no SubjectDName.

    Martin> You mean if it is an End Entity ("Leaf") certificate that
    Martin> has an empty SubjectDName?

Ah, good point.  IT would not tend to be an end entity cert.

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Mon, 21 Feb 2005 15:14:11 -0800

Martin, the text in -25 restricts TD-INVALID-CERTIFICATES to identify
certificates sent by the clients.

   If, while processing the certification path, the KDC determines that
   the signature on one of the certificates in the signedAuthPack field
   is invalid, it returns a KRB-ERROR [CLAR] message with the code
   KDC_ERR_INVALID_CERTIFICATE.  The accompanying e-data for this error
   message is a TYPED-DATA that contains an element whose data-type is
   TD_INVALID_CERTIFICATES, and whose data-value contains the DER
   encoding of the type TD-INVALID-CERTIFICATES:

       TD-INVALID-CERTIFICATES ::= SEQUENCE OF OCTET STRING
                   -- Each OCTET STRING contains a CMS type
                   -- IssuerAndSerialNumber encoded according to
                   -- [RFC3852].
                   -- Each IssuerAndSerialNumber identifies a
                   -- certificate (sent by the client) with an invalid
                   -- signature. 

Let's me know if this is not clear enough or if so, please suggest the
improvement.

If there is an error process certificate the KDC has but the client does
not, there is no point to display an error message to the client and
tell the client which certificate was at fault, since the client won't
be able to make corrective actions.

On the other hand, the KDC should log an event locally and
administrators should be able to act upon that event alone.

-- Larry

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Monday, February 21, 2005 2:39 PM
To: Liqiang(Larry) Zhu
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: Pkinit-23 comments: InitialVerifiedCAs

Liqiang wrote:
> 
> Martin wrote:
> > In case there is a validation error with one of those certs that the

> > KDC supplied, which error is the KDC going to send?
> 
> Presumably the KDC won't use/have this invalid cert to start with.

Just a side note:  How come a certificate may suddenly fail signature
verification?  That may happen if there's broken CA that issues
X.509 certs which are not correct ASN.1 DER encoded, and store it in a
database in unparsed form.  After recreating the cert from its elements
according to ASN.1 DER rules, the signature will no longer match.

Example: The GlobalSign RootCA (you'll find their incorrect DER-cert
preloaded in your nearest Browser)

-Martin

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Tue, 22 Feb 2005 12:06:03 -0800

The current text is sufficiently clear that TD-INVALID-CERTIFICATES is
only used to identify the certificates sent by the client, but I can
further clarify that for the error KDC_ERR_REVOKED_CERTIFICATE and the
error KDC_ERR_REVOCATION_STATUS_UNKNOWN.

Martin, If this working group supports your proposal, I am open to
allowing TD-INVALID-CERTIFICATES to include certificates not sent by the
client, in which case, we can also include the subject name, or even the
whole certificate itself. I personally believe that we do not need to
tell the client information about the certificates internally used by
the KDC.

> (1) reduced code complexity on the KDC side in that it always reports
>    the subject DName of a cert in TD_INVALID_CERTIFICATES when
>    path validation fails, independent whether it received the
>    offending cert from the client or not

The KDC should not use an invalid certificate not sent by the client to
start with. 

> (2) significantly reduced code complexity of KDC client software to
>    issue an error message to the user when one of the three
>    errors occur: KDC_ERR_INVALID_CERTIFICATE,  
>    KDC_ERR_REVOKED_CERTIFICATE or KDC_ERR_REVOCATION_STATUS_UNKNOWN

It is not applicable. Such extraordinary events can be logged on the
KDC.

Comments from others please?

-- Larry

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Tuesday, February 22, 2005 10:46 AM
To: Liqiang(Larry) Zhu
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: Pkinit-23 comments: InitialVerifiedCAs

> certificates sent by the clients.

Yes, I saw that "(sent by the client)", and I'm wondering how it did get
there, because it is inappropriate there.

You forgot this paragraph:

   Based on local policy, the KDC may also check whether any X.509
   certificates in the certification path validating the client's
   certificate have been revoked.  If any of them have been revoked, the
   KDC MUST return an error message with the code
   KDC_ERR_REVOKED_CERTIFICATE; if the KDC attempts to determine the
   revocation status but is unable to do so, it SHOULD return an error
   message with the code KDC_ERR_REVOCATION_STATUS_UNKNOWN.  The
   certificate or certificates affected are identified exactly as for
   the error code KDC_ERR_INVALID_CERTIFICATE (see above).

where it says that this includes the same TD-INVALID-CERTIFICATES to
identify which certificates failed verification.

You just confirmed in your last EMail that the KDC is allowed to fill up
the certification path for path validation with certificates that the
client didn't send.  So now we have a KDC that receives an error from
path validation because (a) a signature verification failed,
(b) a certificate in the path was revoked or (c) the revocation status
of a certificate in the path couldn't be checked.

Now it would be extremely awkward (actually I'd call it broken) if the
KDC would (have to) remove those certs from the list of "offending"
certs returned by the path validation that the client didn't send,
because such a reduced list would be incorrect and misleading!

For robustness and in accordance to the KISS principle, the KDC should
report (at least) one offending certificate, no matter whether the
client sent it or not.  And because it is not sure that the client has
that offending cert, the subjectDName MUST always be sent.

As a plus, a client can use this information to easily provide clue to
the end user which certificate(s) was(were) rejected, in every esoteric
non-connected situation.

Is there any good reason why the KDC should make a secret of this info?

I say "Power to the people"!  Give everyone (in particular the
Power-Users) a chance to fast-track the resolution of the problem with a
meaningful error message.  The others will be more annoyed by the fact
that they cannot use the system, than by a error message that they don't
understand (but which enables the help desk to process their complaint
MUCH faster).

> 
> If there is an error process certificate the KDC has but the client 
> does not, there is no point to display an error message to the client 
> and tell the client which certificate was at fault, since the client 
> won't be able to make corrective actions.

Sorry, but you seem to have little experience with software and end user
support (in large companies).

And you seem to confuse two entirely seperate issues:

(1) reduced code complexity on the KDC side in that it always reports
    the subject DName of a cert in TD_INVALID_CERTIFICATES when
    path validation fails, independent whether it received the
    offending cert from the client or not

(2) significantly reduced code complexity of KDC client software to
    issue an error message to the user when one of the three
    errors occur: KDC_ERR_INVALID_CERTIFICATE,  
    KDC_ERR_REVOKED_CERTIFICATE or KDC_ERR_REVOCATION_STATUS_UNKNOWN

> administrators should be able to act upon that event alone.

Only in very small or academic environments the power to administrate
the KDC and view&understand KDC logs and the user helpdesk will be
united in a few or a single person.

In case of a web of kerberos realms with seperate CAs and an
KDC_ERR_REVOCATION_STATUS_UNKNOWN it is quite possible that the local
KDC admin can not do anything, but the User can call the help desk for
the User Management of his own company/department and tell them that
there seems to be something wrong with their CA's CRL distribution
point.

From what I can tell you about the support of complex multi-tie
applications, if the end user gets at least some of the important
low-level info, the resolution of the support call involves only
(1) the affected end user, (2) the application developer whose
scenario/app fails, and (3) one low-level expert that can describe to
the application developer what the error message supplied by the end
user means and what may have caused it -- and actually there's some sort
of a "knowledge base" which both (1) and (2) can access and where they
can learn how to read the error message without getting a low-level
expert involved.

If the end user can not provide any detail whatsoever about the kind of
error that happened, then the overhead is significantly greater.  Then a
low-level expert needs to get in contact with an customers admin (who
has the necessary authorizations to view the low-level logs on the
server), and then the low-level expert has to tell the admin which error
to look for.

-Martin