Subject: Re: What's in a Name?

From: Martin Rex <[email-masked]>
Date: Tue, 12 Jul 2005 19:09:35 +0200 (MET DST)

d019080 wrote:
> 
> I don't know whether your PKI-aware software, admins and end users
> knows pretty well how to obtain a VeriSign End-entity certificate
> for which you're given Issuer&serial -- for all of my company it's 3x NO.

What I forgot:  In the European Union might be illegal for a CA to
offer a service that returns you end-entity certificates of human
users given issuer&serial because of our data protection laws.

This is one reason why you hardly find public X.500 directories
here in Germany.

And when I consider what efforts Microsoft seems to be undertaking in
preventing user enumeration of Windows Domains, then I don't see how
a client which is faced with a PKINIT authentication failure could
make sense from issuer&serial (with the exception that it already
has this particular certificate -- but in that case the subject
DName should be equally sufficient!).

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 12 Jul 2005 12:14:50 -0500

> DName should be equally sufficient!).

But these are CA certificate issuer&serial, no?  Are CAs' names private?
I suppose they could be...

I agree that the Names are useful for UI reasons, but for servers
interested in doing their own CRL checking of a PKINIT client's cert
chain the issuer&serial is needed (and still shorter than the whole cert
chain itself).

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Tue, 12 Jul 2005 19:21:53 +0200 (MET DST)

> I suppose they could be...

Publishing the CA's name (=issuer) and a serial number as part of CRLs
is no problem, as long as this information can not be linked to
human individuals based on the published information.

> chain the issuer&serial is needed (and still shorter than the whole cert

Which scenario do you have in mind that involves CRL lookup (which
requires only the issuer&serial), and would not require the entire
certificate (chain) for proper certificate path validation?

And where do you think such a necessity would arise in the
particular situations that we're discussing (i.e. after receiving
that particular protocol message), and for what particular purpose?

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 12 Jul 2005 12:30:46 -0500

> certificate (chain) for proper certificate path validation?

The idea is that PKINIT should not take away something that Kerberos V
servers have now: the ability to see the path taken by a client and make
decisions about trust in intermediate nodes and possibly reject any
given path.

Given this, Name ought to suffice, since no pre-PKINIT server can do the
Kerberos equivalent (if you wish) of CRL checking for intermediate
cross-realm keys.

So I suppose that Name should be enough (and for me, it is, but I forget
the argument for using IssuerAndSerial instead).

IOW, I don't have such a scenario, though I can't preclude one either.

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 12 Jul 2005 15:11:06 -0400

> DName should be equally sufficient!).

Except I've already told you why the DN is not sufficient -- in a rollover 
situation, the same chain may contain multiple certificates with the same 
Name.  In this case it may be important to tell which one failed validation.

Earlier you wrote:
> When identifying trust anchors by name rather than by issuer&serial then
> certificate rollover is transparent.

Not entirely true.  Trust anchors are specific keys, not names.  We're not 
talking about configuration here; we're talking about the KDC telling the 
client which CA's are trusted, so the client can build a proper chain.  In 
a rollover situation, the correct certificate chain depends on whether the 
KDC's trust anchor is the new key or the old one.  If the trust anchor is 
the old key, the the client needs to include a rollover cert.

Speaking as an individual, I think Martin makes a strong case for including 
distinguished names in all three contexts.  This is why I proposed making 
the Name field be REQUIRED in InitialVerifiedCAs and at least RECOMMENDED 
in the other cases.  I'm fine with making it REQUIRED in all three cases, 
if that's what the WG prefers.  However, both TD-TRUSTED-CERTIFIERS and 
TD-INVALID-CERTIFICATES need the ability to uniquely identify a particular 
certificate, so for these cases the IssuerAndSerialNumber needs to be 
REQUIRED.

-- Jeff

---

From: Martin Rex <[email-masked]>
Date: Tue, 12 Jul 2005 23:23:20 +0200 (MET DST)

> Name.  In this case it may be important to tell which one failed validation.

Except for a end-entity certificate without SubjectDN (which means
that it must have a unique altSubjectName extension), the DN alone
is vital for an admin to be able to find the certificate, and probably
sufficient for 99% to locate the "invalid" certificate should more than
one certificate exist for the named certificate.

Without the subjectDN, it might be quite difficult to find the certificate
in the first place, because the only thing that you can use issuer&serial
for is performing a CRL check--but that still doesn't tell you to whom
this certificate was issued and where you're likely to find the software
or storage which requires human intervention to update/replace the
invalid certificate.  The serial will help to distuinguish the certificates
should one find more than one certificate with the same subjectDN and
without where the reason for its rejection is not directly obvious.
But if there's more than one certificate, one should really check them
all, not just the one that caused this particular protocol exchange
to fail.  ;-)

The "roll-over" situation that I had in mind used the same key for the
old and new certificate, and with the same "notbefore" but an extended
"notafter" validity date.

This is what VeriSign did with their
"Class 3 Public Primary Certification Authority" and what I expect
several other CAs to do when their certs expire. 

> Not entirely true.  Trust anchors are specific keys, not names.

For the "I extended the validity of my certificate" rootCAs,
one could handle newer certs in a certification path as in ones
own trust anchor store as a transparent update -- and Web Browser
seem to be actually doing this, whereas a re-key of a trust-anchor
can not be distinguished from an entirely new trust-ancher,
which means it can not be done "transparently".

> We're not 

By having the KDC send the issuer&serial of the trusted CAs instead of
the name of the trusted CA, were *NOT* fixing the error case, where
the client only has a CA cert which the KDC doesn't yet know,
but we may change the error message at the client in a way that
could make resolution of the problem (between end user, help desk and admin)
more difficult.

It may be obvious to >>us engineers<< that there may be more than
a single certificate for a particular subject DName, but I know
from experience with customers that they will not understand this
difference at all.

When the client has a valid certificate from one of the KDCs CAs,
just not one of the particular CA cert(s) which the KDC happens
to have, then this error with its details will only show up on
the client, and in the most general case, the error will have to
be reported by the user through helpdesk/support to (sys)admin,
with whatever little information that the end user decides/understands
and considers meaningful.

If the KDC sends just the CA names, then the client software can
use the CA cert it has for that CA.  It will cause a failure on the
KDC, but there the error message should be visible with all the
gory details to the sysadmin (maybe the errorlog of the KDC
is even visible to helpdesk/support), and one does not have to rely
on the user to forward the relevant information.

Similar for automated clients (that do not show error to users,
but instead simply don't work).  There it might be helpful if the
log on the KDC showed that there actually is a client trying to connect
and one can directly see why that fails, and that diagnosis is possible
even when the (end) user is unwilling or incapable of finding the
error message from the automated client.  And it still works even if
the automated client is as broken as a lot of software these days
and does not write out any useful error message(s) at all, just doesn't work.

Experience shows that if you have to debug failures in client/server
communication, it really helps if the server can log as many details
about problems as possible, because it often proves quite difficult
to retrieve (sufficiently detailed) error information from the client
software, and very often the recovery of error information from the
client requires involvement and cooperation from novice end-users.

-Martin

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 12 Jul 2005 20:16:32 -0400

On Tuesday, July 12, 2005 11:23:20 PM +0200 Martin Rex <[email-masked]> 
wrote:

> in the first place,

These are arguments for including the Name.  If you're trying to convince 
me, you're wasting your time, because I already agree with you on that 
point.  However, these are not arguments for including _only_ the Name.  Do 
you have some objection to also including something that is actually a 
unique identifier for the certificate, such as an IssuerAndSerialNumber? 
This is something I would expect to be particularly valuable to GUI 
applications, which might want to show the invalid cert to the user, let 
them look at it in detail, etc.  There's no guarantee you can do that with 
just a Name, because there might be more than one cert with the same name.

You do bring up another issue, though.  Some certificates may not _have_ a 
subject DN.  I'm not sure whether this is legitimate for a CA certificate, 
but it certainly is for a leaf.  In these cases, how can we identify the 
cert?  Is an IssuerAndSerialNumber sufficient?  Do we need to include all 
the possible SubjectAltName choices?

> But if there's more than one certificate, one should really
> check them all, not just the one that caused this particular protocol
> exchange to fail.  ;-)

Indeed.

> several other CAs to do when their certs expire.

Hm; that's useful, as long as you don't change the key.  The one I'm 
thinking of allows you to change the key, and have the old CA issue a 
certificate signing the new key, with the same DN.  That way, verifiers 
which have only the old trust anchor can still verify new certificates, at 
least until the old CA expires.

> which means it can not be done "transparently".

Sure.  You can do that if you identify the trust anchor by DN or by keyid, 
but not if you use IssuerAndSerialNumber, since the new cert will have the 
same key but a new serial number.

Unfortunately, a Name is still not enough to pick out a cert that will 
work, because it is possible the key _has_ changed.  If that has happened 
and you don't have the new key, you're better off picking a certification 
path involving another CA than one using the "right" CA with the wrong key.

I think I am coming to the conclusion that for TD-TRUSTED-CERTIFIERS, you 
really need to have a keyid in order to allow the client to pick out the 
right cert from multiple available ones.  Of course, you also want a Name 
so that if it can't find a usable cert, it can show the user a list of DN's 
of CA's that can help him.

> could make resolution of the problem (between end user, help desk and
> admin) more difficult.

There's a key phrase here which could make all the difference.  You said 
"instead of".  I never said or intended "instead of".  My proposal was to 
REQUIRE sending IssuerAndSerialNumber always, and RECOMMEND also sending 
the subject DN.

Since then, I've come to the conclusion that for the case where the client 
does have the right cert, an IssuerAndSerialNumber is not what you need to 
find it.  It is too precise for the rollover case you described, and 
probably not unique enough for the case of a self-signed cert.  Instead, I 
think you really need a SubjectKeyIdentifier here.

I've also come to the conclusion that for the error case, you really need 
the Name, because only human intervention is going to fix the error, and a 
Name is likely to be the only thing a human can process.

So, for TD-TRUSTED-CERTIFIERS, I now thing the right requirement is to 
REQUIRE that both SubjectKeyIdentifier and Name be sent, and RECOMMEND that 
the IssuerAndSerialNumber also be sent.

> on the user to forward the relevant information.

The error log on the KDC is almost certainly _not_ going to be visible to 
support.  As much as possible, clients should have enough information to 
try to track down and fix authentication problems without access to logs 
from any server.  Among other things, at least some of the time the "user" 
is going to be the admin who can't look at the KDC log because this damn 
authentication problem is preventing him from logging in to the KDC!

As I said above, I now believe that for TD-TRUSTED-CERTIFIERS, it is 
essential to send both a Name and a SubjectKeyIdentifier.

I've come to a similar conclusion about TD-INVALID-CERTIFICATES, except 
here it is actual certificates and not trust anchors we are identifying, so 
the correct unique identifier is in fact IssuerAndSerialNumber.  So in this 
case, I believe it is essental to send both an IssuerAndSerialNumber and a 
Name.

As for AD-INITIAL-VERIFIED-CAS, I continue to believe that the DN itself is 
the most useful thing here, probably even for automated use, because it 
seems that the most common use applications servers will make of this field 
is to check it against a list of DN's of trusted CA's.  So here, I think I 
would make only the Name required.

A new proposal, then:

Field                    Name      IssuerAndSerial  SubjectKeyIdentifier
TD-TRUSTED-CERTIFIERS    REQUIRED  RECOMMENDED      REQUIRED
TD-INVALID-CERTIFICATES  REQUIRED  REQUIRED         OPTIONAL
AD-INITIAL-VERIFIED-CAS  REQUIRED  OPTIONAL         OPTIONAL

Again, we'd use a single SEQUENCE type containing all three fields, and 
normative text saying which ones are required in which situations.
Comments?

> client requires involvement and cooperation from novice end-users.

This is also true.  In general, both ends should record as much as is 
feasible, because you often only have access to one end.

-- Jeff

---

From: Martin Rex <[email-masked]>
Date: Wed, 13 Jul 2005 23:48:50 +0200 (MET DST)

Jeffrey Hutzelman wrote:
> 
> Do you have some objection to also including something that is actually a 

No, I don't have any objections.

> just a Name, because there might be more than one cert with the same name.

The amount of ambiguity for the name is likely to be small or none,
because CAs are prohibited from issuing certificates with the same
subject name to distinct entities and CAs make an identification of
themselves part of the subject DName in the end-entity certs they issue.

Some CAs even do not issue certificates with the same subject name
more than once, even to the same entity -- wasn't VeriSign denying
this for S/Mime certificates?  And the way around was making a
kind of serial number or enumerator part of the subject DName.

> subject DN.

Yup, this is a problem.  So we can only require the (subject) name
for certificates that have one.  For the Subject alternative names,
it would be IMHO to complex to carry any of them (let alone all of
them) along in their raw/original form.

Anything non-complex which I can think of here, would be usable only
for presentation to a human end user, e.g. like an unformatted
UTF8-string, which an implementation could fill with whatever
information it considers helpful for manual fixing of the problem.

> I'm not sure whether this is legitimate for a CA certificate, 
> but it certainly is for a leaf.

I think not.

This would probably void the purpose of the CA, because if a CA had
an empty Subject DN, all of the certs it signs would get an emtpy
issuer field, which would make them unusable/invalid.

> In these cases, how can we identify the cert?
> Is an IssuerAndSerialNumber sufficient?  Do we need to include all 

IssuerAndSerial is probably mandatory, because this is what goes
into CRLs.  (whereas the REQUIRED status for SubjectKeyIdentifier
for CA certs is an obvious stupid flaw of rfc3280).

> of CA's that can help him.

I do NOT think it is reasonable to exclude the majority of installed
base PKI software and CAs by requiring a subjectKeyIdentifier,
no matter what rfc3280 says about this, and for end entity certificates
the subjectKeyIdentifier is only a SHOULD in rfc3280.

> AD-INITIAL-VERIFIED-CAS  REQUIRED  OPTIONAL         OPTIONAL

We should account for end-entity certs with empty subject name
and CA certs without subjectKeyIdentifier and therefore
say "REQUIRED if present in the certificate".

Although subjectKeyIdentifier is sufficient to distinguish among
multiple certificates of the same entity (i.e. those with same subject name),
it is useless if you do not have the certificate.

IssuerAndSerial will at least always give you the starting point
where to start looking--although it may require human involvement
and administrative overhead to actually obtain a certificate with
just that information. :-)

Since IssuerAndSerial are omni-present, it shouldn't be a burden to
send it in the TD- cases, and I would suggest to require this information
(which would make it impossible that the container is empty).

However I would appreciate if we put some words into the spec about
the purpose of the information and how it is expected to be used
by the receiver of the protocol unit/message.

-Martin

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 13 Jul 2005 18:08:26 -0400

> kind of serial number or enumerator part of the subject DName.

I'm not sure about the specific case you cite, but yes, I'm aware there are 
CA's that behave this way.

> the subjectKeyIdentifier is only a SHOULD in rfc3280.

I agree.

> say "REQUIRED if present in the certificate".

Yes.

> multiple certificates of the same entity (i.e. those with same subject
> name), it is useless if you do not have the certificate.

Right.  But in the TD-TRUSTED-CERTIFIERS case, you might actually have a 
case where the keyid is the most useful identifier (because IssuerAndSerial 
is too specific).  The point several have made about certs not always 
having a SubjectKeyIdentifier is well-taken; obviously this also needs to 
become "... if present in the certificate".  I still think this should be 
at least RECOMMENDED, but let's hear from the rest of the group.

> (which would make it impossible that the container is empty).

That sounds good.

OK, so now we're at this state:
Field                    Name       IssuerAndSerial  SubjectKeyIdentifier
TD-TRUSTED-CERTIFIERS    REQUIRED*  REQUIRED         RECOMMENDED*
TD-INVALID-CERTIFICATES  REQUIRED*  REQUIRED         OPTIONAL
AD-INITIAL-VERIFIED-CAS  REQUIRED   OPTIONAL         OPTIONAL
(*) If present in certificate

In the AD- case I think we can safely assume the name is non-empty; if not 
we need to make some change to keep the container from being empty.

> by the receiver of the protocol unit/message.

I agree.  Does someone want to propose specific text?

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 13 Jul 2005 18:10:01 -0400

On Wednesday, July 13, 2005 11:48:50 PM +0200 Martin Rex 
<[email-masked]> wrote:

>> You do bring up another issue, though.  Some certificates may not _have_
>> a  subject DN.
>

I'm inclined to agree.

> information it considers helpful for manual fixing of the problem.

Should we do something like this?

-- Jeff