Re: What's in a Name?

classic Classic list List threaded Threaded
71 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Re: What's in a Name?

Jeffrey Hutzelman
> My main concern is that it is hard for me to tell who was arguing for or
> against what changes, which makes it nigh impossible to figure out
> whether we have consensus for any of these changes, let alone all of
> them.  To that end, I'd like to get comments from members of the working
> group on several questions:

There hasn't been anything resembling consensus on this, and we really do
need to resolve this before we can go forward.  I'm going to postulate some
answers to my own questions, based in part on recent discussions and in
part on some of my own experiences (some of which are fairly recent).

First, I think I phrased this slightly wrong.  In the first three
questions, I should not have asked about "SEQUENCE OF TrustedCA", but
instead about "SEQUENCE OF <what pkinit-25 defined as TrustedCA>".  And I
shouldn't have asked question (d) at all -- the answer depends entirely on
the answers to the other three.  So, here goes...


First, it is necessary to note that a Name does _not_ uniquely identify a
certificate, because a CA may issue more than one cert with the same DN.
One common example of this is what happens when a certificate is renewed.
On the other hand, a Name _is_ supposed to uniquely identify a particular
entity; CA's are not supposed to issue certificates to more than one entity
with the same Name.

However, IssuerAndSerialNumber _is_ supposed to uniquely identify a
certificate.  This is based on the assumptions that no two entities,
including CA's, have the same Name, and that no CA will issue two
certificates with the same serial number, whether or not they are signed by
the same key.





> (a) What should InitialVerifiedCAs be?
>     SEQUENCE OF OCTET STRING wrapping Name?
>     SEQUENCE OF TrustedCA?
>     Something else?
>     This is ticket #836

This is used to allow applications to do their own check that the trust
path is acceptable to them.  To do this, applications will need to know the
names of the CA's along the certification path; I agree with Martin that
the Name is essential in this usage.

Nico has suggested that in this case we may additionally want an
IssuerAndSerialNumber, which would potentially provide applications with
enough information to obtain the certificates involved and validate the
certificates on their own.  This is slightly extreme, but does fit with
Kerberos's end-to-end authorization model, allowing applications to do as
much checking as possible.


> (b) What should TD-INVALID-CERTIFICATES be?
>     SEQUENCE OF OCTET STRING wrapping IssuerAndSerialNumber?
>     SEQUENCE OF TrustedCA?
>     Something else?
>     This is ticket #864

This is used to tell the client which certificate(s) failed validation.
Brian suggests that perhaps all we need here is a Name, because the client
already has the certificates.  However, a Name is not sufficient to
uniquely identify a certificate, and it is even moderately likely that you
will see multiple certificates with the same Name in a single chain.  PKIX
explicitly allows for a model which eases the transition when a CA changes
keys or has its certificate renewed, by allowing the CA to issue a new
certificate signed by the old one.  This allows verifiers which trust the
old certificate to verify leaf certs signed by the new certificate.  In
this case, the special rollover certificate must have the same issuer and
subject DN's, which means the chain will have more than one cert with the
same Name.

So, I think we definitely need to report an IssuerAndSerialNumber here, so
that a client can correctly identify the invalid certificate.  However, I
also agree with Martin's comment that we need a Name here, to provide the
client with a DN for the offending certificate which it can present to the
user (note that the client might _not_ have the offending certificate,
especially by the time it reports a problem).



> (c) What should TD-TRUSTED-CERTIFIERS be a SEQUENCE of?
>     SEQUENCE OF OCTET STRING wrapping Name?
>     SEQUENCE OF TrustedCA?
>     Something else?
>     This is ticket #865

Chaskiel points out that in this case, you absolutely need something better
than just a Name.  This is a list of trust anchors, and for a certificate
to work, it must have the right key, not just the right name.

Brian suggests that some form of IssuerAndSerialNumber is right for this
purpose.  I don't think he's said it yet, but I assume that Martin will
argue that a Name is also useful here, as it allows a client to tell the
user who he needs to go get a certificate from.



So, based on this, I think it is desirable in all three cases to be able to
include both a Name and an IssuerAndSerialNumber.  In the case of
InitialVerifiedCAs, the Name is the key piece of information that
applications are expected to want; in the others, the IssuerAndSerialNumber
is critical and the Name merely informational.  I don't see any need for a
subjectKeyIdentifier in any of these cases, and I haven't even heard anyone
argue for keeping a raw serial number.  Finally, I think it is a good idea
to allow for future changes in the protocol, in case we turn out to be
wrong.



So, now I think I'm ready to answer my own questions, all at once.  I
believe that all three of these cases should be able to use a common type,
defined as follows:

TrustedCA ::= SEQUENCE {
  caName          [0] IMPLICIT OCTET STRING OPTIONAL,
                      -- wraps Name
  issuerAndSerial [1] IMPLICIT OCTET STRING OPTIONAL,
                      -- wraps IssuerAndSerial
  ...
}


For InitialVerifiedCAs, the caName field MUST be provided and the
issuerAndSerial field MAY be provided.

For TD-INVALID-CERTIFICATES and TD-TRUSTED-CERTIFIERS, the caName field
SHOULD be provided and the issuerAndSerial field MUST be provided.



Modifying pkinit-26 to meet this proposal would require changing the
TrustedCA type to the one shown above (but with better comments), and
adding requirements language in each of the three places where it is
referenced.


Comments on this proposal?


-- Jeff


Reply | Threaded
Open this post in threaded view
|

Re: What's in a Name?

Martin Rex
Jeffrey Hutzelman wrote:

>
> First, I think I phrased this slightly wrong.  In the first three
> questions, I should not have asked about "SEQUENCE OF TrustedCA", but
> instead about "SEQUENCE OF <what pkinit-25 defined as TrustedCA>".  And I
> shouldn't have asked question (d) at all -- the answer depends entirely on
> the answers to the other three.  So, here goes...
>
> First, it is necessary to note that a Name does _not_ uniquely identify a
> certificate, because a CA may issue more than one cert with the same DN.
> One common example of this is what happens when a certificate is renewed.
> On the other hand, a Name _is_ supposed to uniquely identify a particular
> entity; CA's are not supposed to issue certificates to more than one entity
> with the same Name.
>
> However, IssuerAndSerialNumber _is_ supposed to uniquely identify a
> certificate.  This is based on the assumptions that no two entities,
> including CA's, have the same Name, and that no CA will issue two
> certificates with the same serial number, whether or not they are signed by
> the same key.

A quick resume why I think that the subject DName is very important:

Who or what will normally have to "process" the information and
act upon it?

1) non-PKI-aware kerberized apps
   InitialVerifiedCAs is expected to be processed by a kerberized
   application servers that care about this information, but these
   servers may not know anything about PKI or PKINIT (keep in mind
   that the base Kerberos spec doesn't mandate available of a full
   blown PKI).

2) fully PKI-aware PKINIT servers or clients
   TD-TRUSTED-CERTIFIERS are expected to be processed programmatically
   by a fully PKI-aware PKINIT client or PKINIT server (=KDC).

3) human (end) users and admins
   TD-INVALID-CERTIFICATES will almost always result in an error
   which an end user or admin will have to fix. (An implementation
   that can programmatically overcome this error is broken, because
   it should have been able to prevent it from happening.)

If you look around at the UIs of common implementations of PKI-Software,
you'll see that "issuer and serial" is among the hidden details,
and in particular long serial numbers (like those in VeriSign RootCAs)
can not be easily recognized memorized by a human user.

It is common practice to list Certificates by either their Subject DName
or by an alias derived or related to their subject DName -- and not
by their Issuer or serial number.  Given enough certificates, it is
a royal PITA to locate a certificate based on Issuer and serial number.

RootCAs have the same isser and subject DName, so they're easier to
locate by issuer&serial, but they're also less likely to be invalid
(expired, revoked, whathaveyou) than end-entity or intermediate-CA
certificates ...

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.


And everywhere where an Admin configures trust or ACLs or looks up
a certificate manually, he refers to and recognizes the certificate
by it's subject name, NOT by issuer&serial.  The software may internally
use issuer&serial for certain functions, including certificate validation,
but that's hidden from the admin and end user.


Ultimately, the most universal approach would be to use the
plain name(s), for visualizing error messages and for processing
by software with limited ASN.1 and not PKI-capabilities, plus
the certificate(s) for processing by PKI-aware software and
for less confusion in case of PKI-related errors (invalid certs,
lack of trust, policy issues, whathaveyou).  ;-)


And a final STRONG word of caution about issuer&serial, because
it will create serious problems with many kinds of certificate roll-over,
both end-entity and CA-certificate rollover, where one side has the
new certificate and the other side has it not yet.  When identifying trust
anchors by name rather than by issuer&serial then certificate rollover
is transparent.  The actual certificate path validation uses a real
certificate/key and a real signature verification, so there's no
security problem with calling a trust anchor by its name.

Some PKI-fanciers see it as a big advantage that you can revoke
and existing certificate and re-issue a new one without having to
update your infrastructure configuration when a user's PKI credentials
need to be replaced (lost, defective or stolen hardware token),
so one should be really careful not to use issuer&serial information
in all the wrong places.


-Martin


Reply | Threaded
Open this post in threaded view
|

Re: What's in a Name?

Martin Rex
In reply to this post by Jeffrey Hutzelman
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


Reply | Threaded
Open this post in threaded view
|

Re: What's in a Name?

Nicolas Williams
On Tue, Jul 12, 2005 at 07:09:35PM +0200, Martin Rex wrote:

> 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!).

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


Reply | Threaded
Open this post in threaded view
|

Re: What's in a Name?

Martin Rex
Nicolas Williams wrote:

>
> On Tue, Jul 12, 2005 at 07:09:35PM +0200, Martin Rex wrote:
> > 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!).
>
> But these are CA certificate issuer&serial, no?  Are CAs' names private?
> 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.

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

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


Reply | Threaded
Open this post in threaded view
|

Re: What's in a Name?

Nicolas Williams
On Tue, Jul 12, 2005 at 07:21:53PM +0200, Martin Rex wrote:

> Nicolas Williams wrote:
> > But these are CA certificate issuer&serial, no?  Are CAs' names private?
> > 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.
>
> >
> > 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).
>
> 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?

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


Reply | Threaded
Open this post in threaded view
|

Re: What's in a Name?

Jeffrey Hutzelman
In reply to this post by Martin Rex


On Tuesday, July 12, 2005 07:09:35 PM +0200 Martin Rex <[hidden email]>
wrote:

> 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!).

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


Reply | Threaded
Open this post in threaded view
|

RE: What's in a Name?

Larry Zhu
In reply to this post by Jeffrey Hutzelman
Jeffrey Hutzelman wrote:
> 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.

subjectKeyIdentifier is sufficient to identify the cert for all
practical purposes.


-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Jeffrey
Hutzelman
Sent: Tuesday, July 12, 2005 12:11 PM
To: [hidden email]
Cc: [hidden email]
Subject: Re: What's in a Name?



On Tuesday, July 12, 2005 07:09:35 PM +0200 Martin Rex
<[hidden email]>
wrote:

> 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!).

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




Reply | Threaded
Open this post in threaded view
|

RE: What's in a Name?

Jeffrey Hutzelman


On Tuesday, July 12, 2005 12:20:18 PM -0700 "Liqiang(Larry) Zhu"
<[hidden email]> wrote:

> Jeffrey Hutzelman wrote:
>> 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.
>
> subjectKeyIdentifier is sufficient to identify the cert for all
> practical purposes.

Are you suggesting adding a subjectKeyIdentifier to the SEQUENCE?
Should this be REQUIRED instead of IssuerAndSerialNumber?
Or should both be REQUIRED?
Or should the requirement be "MUST have at least one"?

Or are you suggesting that IssuerAndSerialNumber be removed entirely?


-- Jeff


Reply | Threaded
Open this post in threaded view
|

RE: What's in a Name?

Larry Zhu
In reply to this post by Jeffrey Hutzelman

The TD-TRUSTED-CERTIFIERS in -26 uses simply TrustedCA, which contains
the CA's DN, you can optionally include the serial #, or
subjectKeyIdentifier if you want to avoid using serial #s in Martin's
scenarios.

The TD-INVALID-CERTIFICATES contains only IssuerAndSerialNumber, and I
agree with you this is required.




-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Jeffrey
Hutzelman
Sent: Tuesday, July 12, 2005 12:53 PM
To: Liqiang(Larry) Zhu; [hidden email]
Cc: [hidden email]
Subject: RE: What's in a Name?



On Tuesday, July 12, 2005 12:20:18 PM -0700 "Liqiang(Larry) Zhu"
<[hidden email]> wrote:

> Jeffrey Hutzelman wrote:
>> 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.
>
> subjectKeyIdentifier is sufficient to identify the cert for all
> practical purposes.

Are you suggesting adding a subjectKeyIdentifier to the SEQUENCE?
Should this be REQUIRED instead of IssuerAndSerialNumber?
Or should both be REQUIRED?
Or should the requirement be "MUST have at least one"?

Or are you suggesting that IssuerAndSerialNumber be removed entirely?


-- Jeff




Reply | Threaded
Open this post in threaded view
|

RE: What's in a Name?

Jeffrey Hutzelman


On Tuesday, July 12, 2005 01:01:51 PM -0700 "Liqiang(Larry) Zhu"
<[hidden email]> wrote:

>
> The TD-TRUSTED-CERTIFIERS in -26 uses simply TrustedCA, which contains
> the CA's DN, you can optionally include the serial #, or
> subjectKeyIdentifier if you want to avoid using serial #s in Martin's
> scenarios.
>
> The TD-INVALID-CERTIFICATES contains only IssuerAndSerialNumber, and I
> agree with you this is required.



We're not talking about -26.  These types have changed several times in the
last several versions of the document, and not as the result of any WG
consensus.  We are trying to determine what they _should_ look like, and
then we'll update the document to match.


I don't care what TrustedCA looks like.  I care what TD-TRUSTED-CERTIFIERS,
and TD-INVALID-CERTIFICATES, and ADInitialVerifiedCAs need to look like.
Not what they look like in your latest reaction to an isolated comment, but
what they need to look like based on a real consensus.

Personally, I think we can end up defining all of these the same way, and
that it will be a lot more convenient to do so.  TrustedCA is a tool for
doing that, but it is only a tool.  If it doesn't do what we need, we'll
change it.  If it turns out we don't want to define all three lists the
same way, then we may end up punting TrustedCA entirely.



So, let's go back a step...
I'm going to try to ask questions in more detail.  Answers from all parties
are encouraged...


For TD-INVALID-CERTIFICATES:
- Do you agree that IssuerAndSerialNumber needs to be REQUIRED?
- Do you also agree with Martin that having a Name here can be useful?
- Does anyone object to making the Name at least RECOMMENDED?
- Does anyone object to making the Name be REQUIRED?
- Martin (or others), is making the Name RECOMMENDED sufficient?
- Does anyone believe this case needs some additional type, besides an
  IssuerAndSerialNumber or a Name?


For TD-TRUSTED-CERTIFIERS:
- Do you agree that we need to identify a specific trust anchor, and not
  just the DN of some root CA?  If we don't have agreement on this, then
  we need to resolve it before we can usefully talk about the rest.
- Do you agree one of IssuerAndSerialNumber or SubjectKeyIdentifier needs
  to be REQUIRED?
- Do you have a preference for which one is REQUIRED?  Why?
- Should the not-required one be RECOMMENDED or OPTIONAL or not present?
- Do you agree with Martin that having a Name here can be useful?
- Does anyone object to making the Name at least RECOMMENDED?
- Does anyone object to making the Name be REQUIRED?
- Martin (or others), is making the Name RECOMMENDED sufficient?
- Does anyone see a reason for a raw serial number?
- Does anyone believe this case needs some additional type, besides Name,
  IssuerAndSerialNumber, or SubjectKeyIdentifier?


For AD-INITIAL-VERIFIED-CAS:
- Do you agree a Name is sufficient, and should be REQUIRED?
- Do you agree with Nico that having an IssuerAndSerialNumber would be
  useful, in order to allow applications to do their own CRL lookups(*)?
- Should IssuerAndSerialNumber be REQUIRED, RECOMMENDED, OPTIONAL, ???
- Does anyone believe this case needs some additional type, besides Name,
  IssuerAndSerialNumber, or SubjectKeyIdentifier?



Given some answers to these questions, maybe we can reach convergence.

-- Jeff


Reply | Threaded
Open this post in threaded view
|

Re: What's in a Name?

Martin Rex
In reply to this post by Jeffrey Hutzelman
Jeffrey Hutzelman wrote:

>
> On Tuesday, July 12, 2005 07:09:35 PM +0200 Martin Rex <[hidden email]>
> wrote:
>
> > 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!).
>
> 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.

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.

>
> 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.

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
> 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.


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



Reply | Threaded
Open this post in threaded view
|

Re: What's in a Name?

Nicolas Williams
In reply to this post by Jeffrey Hutzelman
On Tue, Jul 12, 2005 at 04:50:47PM -0400, Jeffrey Hutzelman wrote:
> So, let's go back a step...
> I'm going to try to ask questions in more detail.  Answers from all parties
> are encouraged...
>
>
> For TD-INVALID-CERTIFICATES:
> - Do you agree that IssuerAndSerialNumber needs to be REQUIRED?

That or SubjectKeyIdentifier.  Note though that leaf certs may not have
a SubjectKeyIdentifier.

> - Do you also agree with Martin that having a Name here can be useful?

Yes (where the client doesn't have the whole cert chain).

> - Does anyone object to making the Name at least RECOMMENDED?

No.

> - Does anyone object to making the Name be REQUIRED?

No.

> - Martin (or others), is making the Name RECOMMENDED sufficient?

I think so, but see no reason not to make it REQUIRED, and it should be
present where the client did not send the whole cert chain, which means
it's just as well to make it REQUIRED.

> - Does anyone believe this case needs some additional type, besides an
>  IssuerAndSerialNumber or a Name?

SubjectKeyIdentifier will do as well as IssuerAndSerialNumber, for CA
certs.

>
> For TD-TRUSTED-CERTIFIERS:
> - Do you agree that we need to identify a specific trust anchor, and not
>  just the DN of some root CA?  If we don't have agreement on this, then
>  we need to resolve it before we can usefully talk about the rest.

Agreed.

> - Do you agree one of IssuerAndSerialNumber or SubjectKeyIdentifier needs
>  to be REQUIRED?

One, the other or both.  I don't care.

I assume that IssuerAndSerialNumber will typically be as unique as
SubjectKeyIdentifier, I also assume (correct me if I'm wrong) that in
practice it's isn't always possible to get a guarantee of uniqueness for
either, which is why I don't care.  But maybe I should care -- may it be
that self-signed CA trust anchor certs are more likely to have a unique
SubjectKeyIdentifier than a unique IssuerAndSerialNumber?

> - Do you have a preference for which one is REQUIRED?  Why?

Both?

> - Should the not-required one be RECOMMENDED or OPTIONAL or not present?

Don't know.

> - Do you agree with Martin that having a Name here can be useful?

Yes.

> - Does anyone object to making the Name at least RECOMMENDED?

No.

> - Does anyone object to making the Name be REQUIRED?

No.

> - Martin (or others), is making the Name RECOMMENDED sufficient?

I think so.

> - Does anyone see a reason for a raw serial number?

No.

> - Does anyone believe this case needs some additional type, besides Name,
>  IssuerAndSerialNumber, or SubjectKeyIdentifier?

No.

>
> For AD-INITIAL-VERIFIED-CAS:
> - Do you agree a Name is sufficient, and should be REQUIRED?

Yes.

> - Do you agree with Nico that having an IssuerAndSerialNumber would be
>  useful, in order to allow applications to do their own CRL lookups(*)?

I'm not sure that I agree :)  (see a post from me today on that).

> - Should IssuerAndSerialNumber be REQUIRED, RECOMMENDED, OPTIONAL, ???

Not present (see above).

> - Does anyone believe this case needs some additional type, besides Name,
>  IssuerAndSerialNumber, or SubjectKeyIdentifier?

No.


> Given some answers to these questions, maybe we can reach convergence.

That's a lot of questions...

Cheers,

Nico
--


Reply | Threaded
Open this post in threaded view
|

Re: What's in a Name?

Jeffrey Hutzelman
In reply to this post by Martin Rex


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

> 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,

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.

> 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.

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.


> 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".

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.


> 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.

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.



> 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.

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?



> 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.

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


Reply | Threaded
Open this post in threaded view
|

Re: What's in a Name?

Love Hörnquist Åstrand
In reply to this post by Jeffrey Hutzelman

Jeffrey Hutzelman <[hidden email]> writes:

> So, let's go back a step...
> I'm going to try to ask questions in more detail.  Answers from all
> parties are encouraged...

REQUIRE SubjectKeyIdentifier would be unwise given the use of today CA's.

IssuerAndSerialNumber or SubjectKeyIdentifier should be the items that is
used, any of those two uniquely indentifies the certificate. Name might be
used to be friendly to the user/sysadmin, but have not real use for the
protocol/implementations given its non-uniqueness.

Love


attachment0 (487 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: What's in a Name?

Larry Zhu
In reply to this post by Jeffrey Hutzelman
The SubjectKeyIdentifier extension is actually REQUIRED for CA certificates. Here is the text in RFC3280. (Martin, RFC3280 is the IETF version of X.509).

   <<cut>> "this extension MUST
   appear in all conforming CA certificates" <<cut>>

I also looped in Stefan to help us interpret the text in RFC3280.

-- Larry

-----Original Message-----
From: Love Hörnquist Åstrand [mailto:[hidden email]]
Sent: Wednesday, July 13, 2005 12:32 AM
To: Jeffrey Hutzelman
Cc: Liqiang(Larry) Zhu; [hidden email]; [hidden email]
Subject: Re: What's in a Name?


Jeffrey Hutzelman <[hidden email]> writes:

> So, let's go back a step...
> I'm going to try to ask questions in more detail.  Answers from all
> parties are encouraged...

REQUIRE SubjectKeyIdentifier would be unwise given the use of today CA's.

IssuerAndSerialNumber or SubjectKeyIdentifier should be the items that is
used, any of those two uniquely indentifies the certificate. Name might be
used to be friendly to the user/sysadmin, but have not real use for the
protocol/implementations given its non-uniqueness.

Love



Reply | Threaded
Open this post in threaded view
|

RE: What's in a Name?

Chaskiel Grundman-3
--On Wednesday, July 13, 2005 09:34:16 AM -0700 "Liqiang(Larry) Zhu"
<[hidden email]> wrote:

> The SubjectKeyIdentifier extension is actually REQUIRED for CA
> certificates. Here is the text in RFC3280. (Martin, RFC3280 is the IETF
> version of X.509).

Standards say lots of things. That doesn't mean the deployed
implementations we have to work with actually follow them. None of the CA
root certificates from verisign/thawte that are shipped with recent mozilla
(at least, as extracted by debian into the 'ca-certificates' package. I
didn't check the actual mozilla sources) include SubjectKeyIdentifier
extensions.

attachment0 (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: What's in a Name?

Larry Zhu
In reply to this post by Jeffrey Hutzelman
It would to be fine to include the serial # in order to support the
deployed non-IEF-conforming implementations.

-- Larry

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Chaskiel M
Grundman
Sent: Wednesday, July 13, 2005 10:26 AM
To: [hidden email]
Subject: RE: What's in a Name?

--On Wednesday, July 13, 2005 09:34:16 AM -0700 "Liqiang(Larry) Zhu"
<[hidden email]> wrote:

> The SubjectKeyIdentifier extension is actually REQUIRED for CA
> certificates. Here is the text in RFC3280. (Martin, RFC3280 is the
IETF
> version of X.509).

Standards say lots of things. That doesn't mean the deployed
implementations we have to work with actually follow them. None of the
CA
root certificates from verisign/thawte that are shipped with recent
mozilla
(at least, as extracted by debian into the 'ca-certificates' package. I
didn't check the actual mozilla sources) include SubjectKeyIdentifier
extensions.


Reply | Threaded
Open this post in threaded view
|

RE: What's in a Name?

Jeffrey Hutzelman


On Wednesday, July 13, 2005 10:42:21 AM -0700 "Liqiang(Larry) Zhu"
<[hidden email]> wrote:

> It would to be fine to include the serial # in order to support the
> deployed non-IEF-conforming implementations.

It is worth noting again that a serial number alone is meaningless.
Given current practice, is is reasonable to say "MUST include at least one
of IssuerAndSerialNumber or SubjectKeyIdentifier; SHOULD include
SubjectKeyIdentifier if the cert has one" ?



Reply | Threaded
Open this post in threaded view
|

Re: What's in a Name?

Nicolas Williams
On Wed, Jul 13, 2005 at 01:49:19PM -0400, Jeffrey Hutzelman wrote:

>
>
> On Wednesday, July 13, 2005 10:42:21 AM -0700 "Liqiang(Larry) Zhu"
> <[hidden email]> wrote:
>
> >It would to be fine to include the serial # in order to support the
> >deployed non-IEF-conforming implementations.
>
> It is worth noting again that a serial number alone is meaningless.
> Given current practice, is is reasonable to say "MUST include at least one
> of IssuerAndSerialNumber or SubjectKeyIdentifier; SHOULD include
> SubjectKeyIdentifier if the cert has one" ?

To me it seems reasonable.  A CHOICE perhaps?  Anyways, we may want
advice on this from Russ.


1234