RE: Other certs extension

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

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: owner-ietf-pkix@xxxxxxxxxxxx [mailto:owner-ietf-pkix@xxxxxxxxxxxx]
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




Kemp, David P. wrote:
> (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.  

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.

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

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

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

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

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

S.