Subject: Re: Other certs extension

From: "Denis Pinkas" <[email-masked]>
Date: Mon, 7 Apr 2008 17:52:09 +0200

Stepen,

Since you said that "comments on the content are, of course, also much appreciated" ...

The document should explain under which circumstances the Permanent Identifier extension (RFC 4043) 
would fullfil the goal.

The next question would then be: are the additional features provided by the proposal really important and necessary ?
If yes, this should be argumented.

Denis 

>We briefly discussed this draft [1] in Philadelphia where
>there was some support for taking it on as a WG item, as
>well as some concern. I've just posted an update to the
>draft that I hope might mitigate some of the concerns
>expressed.
>
>At the meeting, we agreed to discuss it on the list,
>i.e. to discuss whether or not to make it a PKIX WG item,
>and if so, whether it ought be experimental track or
>whatever.
>
>FWIW, I think it'd be a fine PKIX draft, and reckon
>experimental is right unless its adopted for some
>interesting application, which I don't see happening
>right now.
>
>So - should this be a PKIX draft? And if so, aiming
>at what kind of RFC?
>
>Cheers,
>Stephen.
>
>PS: Comments on the content are, of course, also much
>appreciated. (And its still only 7 pages, incl. cruft:-)
>
>[1] 
>http://www.ietf.org/internet-drafts/draft-farrell-pkix-other-certs-02.txt

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 08 Apr 2008 13:35:45 +0100

Hi Denis,

(Sorry, I'd meant to include something on PI based on your earlier
comments, but I forgot. It'll go into a -03 version if/when that
gets done.)

> The document should explain under which circumstances the Permanent Identifier extension (RFC 4043) 

My earlier response on this was (and still is):

"
- I don't think there's a technical need for a permanent identifier for
   this purpose (as I understand it N-R is the main motivator for 4043)
- I'm not sure that there are any real assigner authorities and
   depending on a new name space might just make the problem at hand
   worse
- I've no idea whether 4043 is widely supported or not (mind you, the
   proposed new extension isn't even implemented so that's less of a
   concern)

However, I do agree that were 4043 used, it could solve the problem
at hand, so even if the new extension does go ahead, the spec should
call that out."

> If yes, this should be argumented.

Is "important/necessary" a gating factor for an experimental RFC?
In any case, I'd argue that the other certs extension does fulfill
a particular need that crops up sometimes, and is worth specifying
so that if it becomes important, then there's a clear way to do it.

Stephen.

---

From: "Kemp, David P." <[email-masked]>
Date: Tue, 8 Apr 2008 15:48:47 -0400

(never post before reading the entire thread :-) ...

- The technical need articulated in the I-D is for a permanent
identifier, i.e. a reference that doesn't change even if an entity
providing a service such as a web form field database gets a new DNS
name.  PI isn't just about N-R.

- If you cannot rely on DNS to link multiple instances of a single
entity, and you cannot rely on some other assigner authority to provide
that linkage, then you cannot have a service that will safely allow
state to be shared among those instances.  If you offer such a service
using the new I-D or any other extension (SAN or PI), I'd be happy to
request a cert linking myself to your service, and with no CA or other
assigner authority to stop me, I'd succeed.

In short, the new I-D, if it goes forward, should present a new use case
for existing extensions.  It should not define a new extension.

Dave

-----Original Message-----
From: Stephen Farrell

"

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 10 Apr 2008 09:03:34 +0100

I'd say that PI and the OC extension serves 2 different scenario.

In the first scenario the RP system makes a full match of the certificate against validations policies, extract all naming information and determines the suitability of the certificate along with the matching of the identity to the accessed account.

In the second scenario only basic validation is done to make sure the cert is valid, but beyond that the RP system simply configure certificates of various kinds to represent users in their claimed capacity. In this scenario, name matching can be omitted or very limited.

In the first scenario PI works nicely, but so does a lot of other possible solutions. OC Extensions are not needed here.
But in scenario 2 where the RP system know their users by their certificates, then OC could be very useful.

One might think that all use of PKI should follow scenario 1, but in practice that is not the case. Quite some situations exist where applications are forced to accept existing certificates from legacy PKIs. As they don't always meet naming conventions of the app, learning/registering existing certificates (that do not contain an PI) is a realistic option. Recently RFC4680 and RFC4681 were developed to support such approach over TLS authentication.

In this capacity, OC extensions can be deployed reactively, while PI needs to be in place in existing certificates to work.

I have not yet decided if I want to support this draft, but I do recognize some benefits.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Stephen Farrell
> Sent: den 8 april 2008 14:36
> To: Denis Pinkas
> Cc: pkix
> Subject: Re: Other certs extension
>
>
>
> Hi Denis,
>
> > The next question would then be: are the additional features provided
> by the proposal really important and necessary ?

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 10 Apr 2008 10:17:00 +0100

> In this capacity, OC extensions can be deployed reactively, while PI needs to be in place in existing certificates to work.

Actually, that's a good point. I should add it to the -03 version
if/when I make one.

S.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 10 Apr 2008 10:13:04 +0100

Kemp, David P. wrote:
> name.  

I don't agree with you there. If there is a PI, then that can be
used for the use-cases here. However, a PI is not required. For
example, a PI is presumably "permanent" whereas for the other
certs stuff, one could have no identifiers at all that match in
the two certs.

 > PI isn't just about N-R.

That wasn't my impression, but fair enough.

> state to be shared among those instances.  

I don't thing an "other assigner authority" is needed for the use-cases
in question. The CA can do it nicely IMO.

(BTW - are there any PI assigner authorities operating now?)

 > If you offer such a service

I don't follow that last bit. A CA is still in the loop so I don't
see how you'd succeed unless its in collusion with you (when all bets
are off).

> for existing extensions.  It should not define a new extension.

Disagree. (But you probably knew that already:-)

S.

---

From: "Kemp, David P." <[email-masked]>
Date: Thu, 10 Apr 2008 11:29:53 -0400

Stephen,

1) Yes, CAs will do nicely as assigner authorities.  PI says that the CA
is the assigner authority by default unless another party is designated
in the extension.

2) Yes, "Permanent" is in the name of the extension, but that may be too
strong a word.  The identifier needs to persist as long as necessary to
support the intended applications, where N-R applications may require
longer persistence than others.

3) Yes, name assigners exist.  SAML uses the NameQualifier attribute to
"contain the unique ID of the identity provider that generated the [end
entity] identifier."  My bank, my employer, eBay, PayPal, every forum
I've ever created an account on, yada yada yada, is a name assigner.
Every DHCP server that leases out IP addresses is a name assigner.
Every RFC 822 name has a name assigner (the hostname part) as well as
the userid part.  Presumably any organization that stands up devices to
provide the "shared state" service envisioned in the I-D will have some
way of naming those devices, perhaps recording the barcode of the
chassis to identify each separate machine, and perhaps creating a UUID
to be used in a UDDI to identify the single service provided by the
collection of shared-state machines.  The X.520 attribute id-at 55 (UUID
pair) could be used in SAN to designate that service, where:
   "The initial UUID in the pair represents the issuer, and the
   trailing UUID in the pair represents the subject of the
   issuer/subject relationship. An example of such a relationship
   is a user account."
Another example is obviously a service identifier issued (assigned) by
the service provider.

Stefan,

I don't understand the distinction you make between "full match of the
certificate against validation policies and determining suitability" and
"basic validation to ensure the cert is valid".  Regardless of the
contents of the certificate (OC extension or SAN containing a service
identifier), the RP will do whatever it feels is necessary, which should
include at least basic validation.  Any other "suitability" validation
is gravy, and applies equally to OC processing or SAN processing.

For the case of issuing a new certificate that references an existing
legacy certificate, why wouldn't SAN containing the DN of the legacy
subject be sufficient?

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Stephen Farrell
Sent: Thursday, April 10, 2008 5:13 AM
To: Kemp, David P.
Cc: Denis Pinkas; pkix
Subject: Re: Other certs extension

S.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 10 Apr 2008 17:53:38 +0100

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.

---

From: "Kemp, David P." <[email-masked]>
Date: Mon, 14 Apr 2008 16:06:35 -0400

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
"[email-masked]").  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:[email-masked]] 
Sent: Thursday, April 10, 2008 12:54 PM
To: Kemp, David P.
Cc: pkix
Subject: Re: Other certs extension

Hi David,

Regards,
Stephen.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 14 Apr 2008 22:32:32 +0100

Hiya,

I guess we've batted this around enough for folks who care (if
there're any) to make a call whenever the chairs think thats
timely. But some quick reactions to maybe wrap up this thread
below.

> with a cross-reference to a bunch of other certs.

I guess that's where our approaches here differ in the end.

> *non-reusable* identifiers, a property satisfied by both OIDs and UUIDs

I don't see an absolute need for non-reusable identifiers for all
uses of the other certs stuff, web server certs mainly, which are
essentially DNS dependent in any case.

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

We could quibble, but let's not:-) The other certs I-D doesn't
say what the application might do with the certs.

> number with IANA if he does not already have a suitable OID subtree.

I disagree that identifier registries are trivial.

> SAN extension and PI type, or reusing SAN and creating a new otherName

I don't see any difference in the cost of a new extension vs. that
foe a new otherName & pointed out the problem with SAN here before.

> links to cert A, OR cert C links to certs A and B.  But it is inelegant.

I don't see a need for a forward linkage - the new I-D is about
something an application has cached and finding something equivalent
to that, which is inherently a backwards linkage. No (in)elegance there
at all IMO.

> expires, they ALL have to be re-issued.

Not sure I get that, but if the I-D progresses, we can revisit the
point.

> certs and, poof, you are an assigner authority.

Makes me wonder why there aren't any in existence for 4043. (An
honest query - has anyone thought about setting on up?)

> based on on-demand user accounts.  As a result, PKI is not even

I agree with you. But I'd assert that making PKI less reliant
on (new) identifier registries helps things along in the right
direction.

> to be.  

Completely agree.

 > Give your service some sort of non-reusable unique name and
> stick it in a cert.

We disagree that that's easier. Linking via a hash is IMO simpler,
when the new identifier has no other purpose. Again, I guess this
is really where our approaches differ.

Cheers,
Stephen.

---

From: Michael Ströder <[email-masked]>
Date: Mon, 21 Apr 2008 11:41:02 +0200

Kemp, David P. wrote:
> 
> But if one is going to create a new

Wouldn't it be more appropriate to use attribute certificates for 
sharing the state (if the public-key itself is not an essential part of 
the state)?

Ciao, Michael.