[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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.



Kemp, David P. wrote:

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.