RE: Other certs extension

["Kemp, David P." <DPKemp@xxxxxxxxxxxxxx>]

Stephen,

I understand that there are use cases for identifying a specific
certificate (from among many) held by an entity as opposed to
identifying the entity itself.  But if one is going to create a new
mechanism for sharing state among multiple devices that make up a single
service/application, it seems more elegant to give that service a unique
identifier (such as an RFC 4122 UUID) rather than to create a new cert
with a cross-reference to a bunch of other certs.

1. There isn't a particular need to use the PI othername format defined
in 4043, but during the creation of 4043 there was a lot of discussion
over whether to identify assigner authorities by OID or allow a choice
of more general namespaces, including DNS.  The key reason for not
permitting DNS assigner names in PI is the same reason you cite for not
using DNS -- domain names can be re-registered.  The word "permanent"
implies some sort of ongoing support from the assigner, which is too
strong a requirement.  The actual requirement is for unique and
*non-reusable* identifiers, a property satisfied by both OIDs and UUIDs
but not by DNS names.

2. I understood the I-D to be about access control to shared state
information.

3/4. Again, somebody needs to make a decision that two certs with
different names actually should be linked together.  That somebody
(presumably the entity that operates the shared-state service) is by
definition an assigner authority.  The service operator could offload
that function to the CA or perform it himself when requesting certs.
It's trivial for the service operator to register a private enterprise
number with IANA if he does not already have a suitable OID subtree.

If the N-R related baggage of 4043 is excessive, one could create a new
otherName format with a different type ID but identical syntax: OID
assigner authority + arbitrary subject identifier (which could carry a
UUID or anything else).   I don't think a new type is necessary, except
perhaps to offer a CHOICE of OID or UUID for the assigner name.

Disadvantages of using the other certs extension:
1) it is a completely new extension, rather than reusing the existing
SAN extension and PI type, or reusing SAN and creating a new otherName
type.
2) it imposes an ordering on the linkage - an existing cert cannot
contain a reference to a new cert.  That's not a fatal flaw; application
logic could say A is linked to B iff cert A links to cert B, OR cert B
links to cert A, OR cert C links to certs A and B.  But it is inelegant.
3) if the application logic does not permit third-party links (cert C is
accepted by B as evidence of B's linkage to A), then when any cert
expires, they ALL have to be re-issued.

I don't want to continue to beat this horse, but I did want to make one
more attempt to convey the idea that assigner authorities can be
lightweight processes that already exist everywhere, they are not some
big mysterious corporations that don't yet exist.  If you are requesting
a set of linked certs, you can get an OID from IANA and put it in those
certs and, poof, you are an assigner authority.

<rant>This is peripherally related to my frustration that PKI is
perceived to be so complicated and difficult to use that the TLS WG
feels compelled to develop password-based encryption methods.  If you
sign up for any account-based website (e.g. eBay), instead of asking you
to create a username/password, it could ask you to pick a username and
generate a cert for you (with a null DN and an rfc822 othername like
"SonicFred99@xxxxxxxxxxxxxx").  Or allow you to link the account to any
cert you already have.  No revocation infrastructure is required, no
identity proofing beyond what's already required for the account, no
cross-certification and policy mapping, and no Vista and CardSpace.  But
people see everything that has been developed to permit PKI to address
complicated applications and jump to the conclusion that all that cruft
is needed for even the simplest and most common applications - those
based on on-demand user accounts.  As a result, PKI is not even
considered an option.
</rant>

The analogy: don't make shared-state any more complicated than it needs
to be.  Give your service some sort of non-reusable unique name and
stick it in a cert.



-----Original Message-----
From: Stephen Farrell [mailto:stephen.farrell@xxxxxxxxx] 
Sent: Thursday, April 10, 2008 12:54 PM
To: Kemp, David P.
Cc: pkix
Subject: Re: Other certs extension


Hi David,

So, I've just re-read 4043 and still don't see that it
meets the need here.

Problems that I see with using 4043 for the use cases
in question:

1. A PI isn't necessary, (as I said before:-) I guess
I just find it more elegant to not have to invent a
new identifier value when its not needed. It also seems odd
to say that the word "permanent" is too strong. I guess
PIs also imply uniqueness, which causes unnecessary overhead
(in this case) if a separate assigner authority is involved.

2. 4043 says "A permanent identifier may be useful in
three contexts: access control, non-repudiation and audit
records." which doesn't match the use case here.

3. 4043 defines how PIs match. If there is no assigner
authority, then they only match if the issuers are the
same. That's probably right for the use-cases above, but
is different from whats intended with the OC stuff.

4. As far as I know there are no assigner authorities
operating that have issued PIs that have been used by
a "well-known" CA. (I'd be interested were such a service
to exist.) Its certainly true that names and identifiers
are allocated in many contexts, but I don't know of
anywhere a CA could go to get a PI to include in certs
it issues, for example to web servers. So, if PI were to
be used for these use-cases, someone'd have to create
such a service.

As to the suggestion to just include the name from the
earlier cert in the later one, I think that's a bit
broken. For example, if a DNS name has actually changed
then it'd be wrong for a CA to include the old name
in a new cert, e.g. the old name may now belong to
someone else.

Regards,
Stephen.