Subject: [pkix] Proposal to review and adopt CertID and KeyID proposal

From: Sean Leonard <[email-masked]>
Date: Fri, 05 Feb 2010 11:30:23 -0800

To the PKIX WG:

Greetings. I wrote an Internet-Draft titled "Syntaxes for Unambiguous
Naming of Certificates and Public Keys". I would like to ask the WG to
review this document and consider adopting it as a workgroup item. This
e-mail covers what the document is all about and why the WG should
consider adopting it.

http://www.ietf.org/internet-drafts/draft-ietf-pkix-certid-keyid-00.txt

I have already received some valuable feedback from Stephen Kent, so I
am including some notes and responses on those topics as well.

**What's this about?**
When working with certificates and keys, it is frequently desirable to
refer to another certificate or public key directly and unambiguously.
Unfortunately, the issuer name and serial number are not universally
unique for a certificate. Multiple CAs can have the same issuer name,
for example.

There are several different syntaxes for "unambiguously" identifying
certificates: ESSCertID, ESSCertIDv2, SCVPCertID, and CertID from OCSP,
to name a few. Having a single syntax promotes uniformity and allows
reuse of the same code paths.

Additionally, it is desirable to "name" (and by name, I just mean
"identify") certificates and keys in the GeneralName structure. A
project that I am working on has a specific need to do this in the
GeneralName structure, and since you can name all sorts of resources
using GeneralName, it makes sense to identify a certificate this way as
well.

**Why ESSCertIDv2?**
ESSCertIDv2 (RFC 5035) seems to have the most useful properties and in
the right order. Certificate equivalence is based on the cryptographic
hash. The AlgorithmIdentifier should precede the hash value, since an
implementation does not care what the hash value is if it doesn't
process that algorithm. For robust implementations, the hash should be
sufficient to locate any certificate. But older implementations can only
locate certificates by issuer and serial number, and there are many
protocols that refer to a certificate by issuer and serial number. So,
adding the issuerSerial and making it OPTIONAL facilitates lookup.

**Why identify keys? This is PKIX; we only identify certificates.**
In an implementation that I am working with, we have a need to identify
specific certificates. We also have a need to identify specific keys,
"irrespective of whatever certificates they are in".

Every key is contained in a certificate in the PKIX world. But, PKIX
also provides that a key can be reused in different certificates.
Therefore, identifying the key, I think, is compatible with the focus of
PKIX standards while preserving that alternative. It helps that in the
proposed KeyID structure, there is an option to specifically name one
certificate where the key is present.

One can think of the proposed KeyID structure not as a pointer to a raw
public key, but rather as a mechanism to "identify any and all
certificates that contain the key."

**Ok, but how is identifying keys this way useful to others?**
At least two examples.

#1 An end user can obtain multiple certificates for different purposes,
but use the same smart card or USB token, which only accommodates one
key. If you want to restrict or grant access "by user", restricting
access based on the key may make more sense than based on the
certificate. Note that the user must still present a valid
certificate--so if the user's certificate is revoked due to
privilegeWithdrawn, that certificate won't work.

#2 You might say that if a user's private key is compromised, you should
"just" revoke all the certs with keyCompromise. And yes, all certs
should be revoked. But software or a protocol that figures out whether
to revoke some cert needs to find all the certs with the same key. That
is exactly where KeyID can help--it facilitates the lookup of multiple
certificates containing the same key. A sender can send an instruction
to a CA receiver in a protocol, where the message is "revoke all the
certs containing this key." KeyID is unambiguous and useful in that case.

Thanks for your consideration,

Sean

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 22 Feb 2010 11:38:00 +0100

Hi Sean,

I have now reviewed your proposed draft (which not yet is a WG accepted
document despite it's name)

I have some problems with this document that I hope you can sort out for me.

1) Lack of scope and motivation:
This draft points out that there is no standardized names in inside
certificates that identifies the certificate or the public key. And that is
correct. But why and for what purpose do we need these names, and why do we
need a standard?

Both the certID and the KeyID are values that are derived from the
certificate, so I don't need to find these values in the certificate itself.
I can simply calculate them from the certificate and store them as an
external index in my database. Why does it need to be a name inside the
certificate.

2) Design flaw?
It appears to me that you have incorporated a catch22 problem which makes it
impossible to implement.

Both the keyID and certID names may contain a hash of the certificate.
Consequently, I can't generate these values before the certificate is
signed.

.... but when the certificate is signed, it is to late to add these names
inside the certificate..

How do you implement this in practice?

3) Editorial stuff
There are some editorial stuff that can await until we sorted the larger
issues.

/Stefan 

On 10-02-05 8:30 PM, "Sean Leonard" <[email-masked]> wrote:

> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

---

From: Sean Leonard <[email-masked]>
Date: Mon, 22 Feb 2010 12:37:32 -0800

Hi Stefan (et. al.):

Thank you for your comments; allow me to address them.

> correct. But why and for what purpose do we need these names, and why do we

There are three practical answers (in order of the most practical).

First, my organization has a need to uniquely identify certificates, and 
all certificates containing the same keys, in a GeneralName structure. 
Some of the GeneralName structures will appear in X.509 certificates, 
and others will appear in other protocols and formats that happen to use 
GeneralName.

Hence we are faced with several options: a) create a CHOICE where one 
choice is a GeneralName and the others uniquely identify certs/keys, b) 
create an OtherName within the GeneralName framework but with a 
proprietary definition, or c) create an OtherName within the GeneralName 
framework with a standardized definition. I suppose there is a d) as 
well, petition ITU-T to add another CONTEXT-SPECIFIC tag in the 
GeneralName for such things. d) is not going to happen. We would like to 
contribute to the standards process, and therefore are pursuing c). This 
makes the most technical sense anyway, since we are identifying 
standardized structures, i.e., certificates and keys, not proprietary 
structures.

Second, there are already several proposals for identifying other 
certificates inside an X.509 certificate. One example is 
draft-ietf-pkix-other-certs (also draft-farrell-pkix-other-certs). In 
that I-D, Stephen Farrell makes the case for identifying other 
certificates inside a certificate. Therefore, identifying other 
certificates uniformly will help interoperability and decrease 
implementation costs.

Third, there are other protocols that uniquely identify certificates, 
such as OCSP, SCVP, various S/MIME/CMS standards, and so on.

The net result of #2 and #3 is that we now have a proliferation of 
structures to uniquely identify certificates. This is an implementation 
headache, hinders interoperability, and reduces security. As stated in 
my introductory e-mail, I can find at least ESSCertID, ESSCertIDv2, 
SCVPCertID, and CertID from OCSP as distinct methods for 
cryptographically identifying a certificate.

The security reduction is practical. Having different structures means 
more code paths to write and test, where more bugs can be introduced and 
exploited. Some of the structures (namely OCSP's CertID and the original 
ESS S/MIME's ESSCertID) lack algorithm agility, a point that I believe 
is being grappled with elsewhere. All these reasons motivate 
standardization.

> external index in my database. Why does it need to be a name inside the

The answer here is related to your question 2) below. The use case is to 
identify other certificates than the certificate in question, namely as 
a "See Also" kind of usage, but with the semantics associated with 
wherever GeneralName appears.

GeneralName is a super-URI. A service or thing at a GeneralName has a 
type and a specific identification or access method. GeneralName with 
dNSName tends to mean "anybody who responds to a query associated with 
this DNS resolution request." This proposal makes it effective to say 
"anybody who responds to a query associated with this certificate," 
which in many security-conscious implementations will mean proof of 
possession of the private key associated with that certificate.

As to "just storing them as an external index," the point is to promote 
interoperability when the use case comes up. So you're not just storing 
them in "your database"--you're sending parts of that database for 
others to interpret. One way to send parts of that database to others, 
of course, is to name things in signed structures like X.509 
certificates, OCSP requests/responses, the CMS, and so forth.

> How do you implement this in practice?

A certificate cannot refer to itself using this structure by design. The 
CertID structure is useful for referring to certificates other than the 
one in question. One could reflexively identify the same certificate by 
its serial number, or by a GeneralName registeredID that means "this 
certificate", but I do not see any point in doing so.

I thought of calculating the hash over other structures, such as the 
TBSCertificate. For a general purpose cryptographic hash, that won't 
work in the reflexive case. But the choice to calculate over the entire 
DER encoding of the certificate is practical. That is how most 
implementations index certificates anyway, and that is how it is already 
done for SCVPCertID, ESSCertID, and ESSCertIDv2.

It is technically possible to refer to a key reflexively using KeyID. I 
do not see much of a point in doing so, but I can imagine use cases (in 
contrast to reflexive CertID) because reflexive KeyID can mean "all 
other certificates that match this key, which also happens to be my own 
key," speaking from the standpoint of the certificate.

> There are some editorial stuff that can await until we sorted the larger

OK.

-Sean

---

From: Sean Leonard <[email-masked]>
Date: Mon, 22 Feb 2010 13:02:14 -0800

Report on CertID and KeyID Proposal Feedback

Hello:

I am providing a brief summary of the feedback I have received, which 
will make it into draft -01 of the CertID and KeyID document, whatever 
it happens to be named.

Substantive Feedback
Other than the comments that have already been circulated on the list, I 
do not think that there is any other substantive feedback to mention. 
(Please see the 2/5/2010 e-mail and the most recent e-mail from Stefan 
etc. on the substantive points.)

Editorial/Procedural

Several parts say "must/may" without capitalization. Those are meant to 
be informative statements, not the MUST/MAY of RFC 2119. To reduce 
ambiguity, the lowercase words "must", "may", and so on will be changed 
to other phrases like "an implementeter can choose to" or "an 
implementer needs to consider that" so that RFC 2119 is not invoked.

Section 3, "found" will be added in a place that a commenter noted.

Section 4.2, paragraph 2, s/extenison/extension/.

As stated before obliquely (but to reiterate), the document uses the 
term "name" frequently when it probably should not. This is because of 
the use case of GeneralName. "Identify" is probably the better word 
choice in several parts.

References: a suggestion was made to change "[PKIX]" back to 
"[RFC5280]". Unless I hear objections otherwise, I will switch it back 
to [RFC5280].

Thanks,

-Sean

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 23 Feb 2010 01:13:00 +0100

Sean,

I didn't find the draft very clear on the fact that this is a mechanism for
storing an identifier inside a certificate which identifies another
certificate.

The draft is neither clear on the exact relationship between the certificate
where the identifier is stored and the identified certificate.

I don't find your motivation for this work very descriptive, nor convincing.
All I understand is that you need this for some not very clear reason. But
why would I need this? Can you provide a simple use case that someone who
knows nothing about your environment can understand?

Intuitively it feels wrong to store a reference to another certificate or
key as a subject name. An extension seems much more appropriate.

Which leads to my final question. In light of your description here, it
appears to me that you more or less are duplicating the functionality of RFC
5697 which provides the same functionality based on an extension (Other
Certs Extension). Why can't you simply use This RFC?

/Stefan

---

From: "Miller, Timothy J." <[email-masked]>
Date: Tue, 23 Feb 2010 08:22:50 -0500

> done for SCVPCertID, ESSCertID, and ESSCertIDv2.

Reflexive referral is supported via SubjectKeyIdentifier using a hash over SubjectPublicKey.  In my experience, SKI and AKI are both regularly used by implementations to index and search keystores.  How is your proposal different?

-- Tim

---

From: Sean Leonard <[email-masked]>
Date: Tue, 23 Feb 2010 09:39:16 -0800

> Reflexive referral is supported via SubjectKeyIdentifier using a hash over SubjectPublicKey.  In my experience, SKI and AKI are both regularly used by implementations to index and search keystores.…

SKI and AKI are only defined by the issuing CA to disambiguate different 
certificates (specifically, different keys). They have no global 
uniqueness guarantees. They also do not even have "issuer-uniqueness" 
guarantees, because a CA may reuse the same SKI for different 
certificates. In fact, there are crypto stacks that (correctly according 
to the standards) allow users and applications to change the subject key 
identifiers that certificates are indexed under.

Even if you could use SKI and AKI as a global identifier--which you 
cannot--the only suggestion for cryptographic uniqueness is using a 
SHA-1 hash. This is inadequate in this day and age.

See RFC 5280 sec. 4.2.1.2 and X.509-200508 sec. 8.2.2.2.

Sean

---

From: Sean Leonard <[email-masked]>
Date: Tue, 23 Feb 2010 11:02:28 -0800

Hi Stefan,

Thanks again for your informative comments.

It sounds like there are no technical objections to the structures, or 
the motivation to standardize on structures for identifiers for 
certificates and keys. So the main concerns are around using these 
structures in the context of GeneralName.

So first, here's a hypothetical (but straightforward) example. A 
certificate is a end-entity client SSL/TLS certificate, but you want it 
to only be used with login.foo.com and you are concerned that the user 
will try to use it to login to login.foo.com.evil.ru, or that the user 
is going to be subject to a lot of DNS cache poisoning attacks. The 
client SSL certificate has a "subjectAltName" of id-on-certID, which 
identifies a specific SSL/TLS server certificate. Then, when the client 
contacts login.foo.com, it will only communicate with the server using 
the client certificate when the server presents the certificate 
identified in id-on-certID.

There are several unresolved questions in this example (namely, why 
should subjectAltName be used when it should be more like 
associatedServerAltName), but it gets the basic point that when you 
identify the server, you want to do so with GeneralName, and identify 
the certificate specifically, not an indirect method like the dNSName.

The reason why the draft is "not very clear" about the 
GeneralName/OtherName in a certificate is because GeneralName is not 
limited to certificates; furthermore, GeneralName is not limited to 
methods of accessing resources.

There are many standards that use GeneralName to name (identify) 
different entities. As examples: RFC 5055 (SCVP), RFC 5272 (CMC). 
GeneralName is just that: a general way of identifying a resource. What 
GeneralName means is context-dependent. In a certificate, the meaning of 
GeneralName changes between subjectAltName and accessLocation, but it is 
technically permissible to use all GeneralName possibilities in those 
positions (even though some may not make sense to the application--in 
which case, they will be skipped). Nothing prevents you from running an 
OCSP request over XMPP, even though doing so is not standardized. If you 
wanted to do it, the natural way to identify the server would be an 
accessLocation of GeneralName/OtherName/id-on-xmppAddr [RFC3920].

However, it sounds like you want the document to provide a specific use 
case for inclusion in certificates, as opposed to other places. I 
avoided discussing that possibility in draft 00 because I felt it would 
be contentious or not well thought out. I should make it clearer, and we 
should discuss it.

I re-reviewed RFC 5697 and the RFCs that it references. I think these 
RFCs bolster my point.

Specifically, RFC 5697 refers to RFC 4043, "PKIX Permanent Identifier," 
which is a Standards Track document. 4043 defines a new 
GeneralName/OtherName with id-on-permanentIdentifier, which is an 
identifier defined by a (named) authority that is supposed to be 
globally unique. The authority ("assigner") is named by OID; the 
identifier ("identifierValue") is named by a UTF8String or by the 
serialNumber INTEGER.

RFC 4043 shows that a GeneralName does not have to be a method of 
accessing resources, in contrast to dNSName, iPAddress, 
uniformResourceIdentifier, and so on. (Technically, an X.500 Name can be 
used as a method of accessing resources, at least in the DAP/LDAP 
space.) GeneralName is just a vessel for identifying things. 
id-on-permanentIdentifier does not define an access method, but it is 
still good for identifying things.

Neither RFC 4043 nor RFC 5697 provide a way to identify different 
certificates (or certificates containing the same keys) in GeneralName 
where the subjects are different. RFC 4043 attempts to link two 
certificates to the same subject using a globally unique blob. RFC 5697 
attempts to link the subject in a second certificate to the subject in a 
prior certificate. "When this extension is present, the CA is asserting 
that the same end entity is the subject of the relevant certificates." 
RFC 5697 sec. 3.

But in the example I provided,  you can use id-on-certID to identify a 
certificate that is related to the subject in some way (the SSL server 
that is supposed to be used with this SSL client certificate), but is 
not the subject. The precise relationship is defined by the context in 
which the GeneralName appears.

The point here is that id-on-certID and id-on-keyID are proposed as 
building blocks to better things and better thinking. A short, < 12 page 
RFC that defines these name types can be used as a basis for building 
more sophisticated protocol definitions.

Does this response address your concerns?

Best regards,

Sean

PS For the curious, I found a CertificateScopeOfUse extension which 
constraints the use of a client SSL/TLS certificate to servers named 
using GeneralName. Apparently it was defined in 
draft-thayes-cert-scope-00 in the late '90s, which has long disappeared 
from the Internet. However, the code remains active to this day in the 
Mozilla codebase.

On 2/22/2010 4:13 PM, Stefan Santesson wrote:
> On 10-02-22 9:37 PM, "Sean Leonard"<[email-masked]>  wrote:
>
>    
>> Hi Stefan (et. al.):
>>

---

From: "Miller, Timothy J." <[email-masked]>
Date: Tue, 23 Feb 2010 14:45:45 -0500

> identifiers that certificates are indexed under.

Can you show me *any* collision between two randomly generated key pairs of any cryptographically meaningful key length--let's say, of a key length equivalent to RSA1024 or longer--in any algorithm?  By my back-of-the-envelope estimation, the probability is so vanishingly small that this *is* a guarantee in and of itself.

> SHA-1 hash. This is inadequate in this day and age.

If I hold multiple certifications of the same key, insofar as *authentication* goes all of them point to me, the keyholder, because  I can complete a private key proof with any of them (or all of them at once).  

To perform *authorization*, yes, you need to map that key to an identity--but I don't personally care which certificate you actually use.  That's entirely your choice.

I'm not sure why you think a SHA-1 hash of a public key is inadequate to uniquely identify a key.  

-- Tim

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 23 Feb 2010 21:24:40 +0100

Sean,

Thanks for your effort to explain.

The lack of comments on technical structures by me is not because they are
fine (or bad). I'm just trying to focus on the most important point of
discussion to make this communication as effective as possible.

Before we go to deep into this I still need to understand the use cases (I
sense there are many more you have in mind). You provided one use case here
that isn't enough to motivate the whole draft.

It does for example not explain why I need to identify certificates with
identical public keys.

To your choice of General Name as structure inside subject alternative name.

The problem is not the choice of GeneralName. The problem is where you want
to store the general name in the certificate. If it is to be included in a
subject alternative name extension, then it has to carry a name/identity of
the subject. Your identifiers does not provide a name/identity of the
subject and thus breaks the semantics of the extension.

The very beginning of 4.2.1.6 of RFC 5280 states:

   The subject alternative name extension allows identities to be bound
   to the subject of the certificate.  These identities may be included
   in addition to or in place of the identity in the subject field of
   the certificate.

For your work to be considered by this working group I recommend that you do
the following:

1) Provide use cases that motivates ALL the identifiers you want to create.
This includes also why they need to be carried inside a certificate as
opposed to all options to manage such information outside of the
certificates.

2) Define the exact relationship between the certificate/key being
identified by your identifiers and the certificate where the identifiers are
stored. Motivate why this relationship is important to certify/include
inside a certificate

3) propose a technical approach which does not violate the semantics of
existing certificate fields and extensions.

/Stefan

---

From: Patrick Patterson <[email-masked]>
Date: Tue, 23 Feb 2010 15:25:36 -0500

A couple of comments from me:

Your solution isn't really scalable... let's take your example:

A client software that only completes the handshake if the identifier for the 
certificate of the server matches the identifier embedded in the client's own 
certificate.

Unless you do this REALLY carefully, then you essentially make the server's 
certificate non-revocable. 

If you simply stamp the server's hostname or some other piece of information 
that isn't tied to a unique certificate there, then why use a certificate 
extension at all? Since you appear to be able to control the client so well 
that you can prevent it from ignoring whatever is in the certificate, why not 
just hard code the allowable server identifier into the application some other 
way (config option??). If you are using certificates for configuration 
control, then you are doing something that they were never meant to do.

However, if you are embedding in some identifier that uniquely identifies that 
particular server's particular certificate, then you have the problem of 
having to change all of your clients' certificates if ever you need to change 
the server's certificate (such as when you rekey, when/if it is ever revoked) 
etc.  Which means that if you have more than a couple of certs with that 
identifier baked in, you have a serious problem of re-issuing certs to all of 
your users.

Do you have another use case that perhaps better explains why this draft is 
necessary?

-- 
Patrick Patterson
President and Chief PKI Architect,
Carillon Information Security Inc.
http://www.carillon.ca

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 23 Feb 2010 21:36:27 +0100

I share these concerns.

/Stefan

---

From: Sean Leonard <[email-masked]>
Date: Tue, 23 Feb 2010 13:04:52 -0800

> To your choice of General Name as structure inside subject alternative name.

Before we go any further, did you read the whole e-mail?

As I said very clearly, I picked "subject alternative name" as an 
arbitrary example. Please don't focus on id-on-certID appearing in 
subject alternative name. I think that changes your analysis.

Sean

---

From: Sean Leonard <[email-masked]>
Date: Tue, 23 Feb 2010 13:11:43 -0800

> I'm not sure why you think a SHA-1 hash of a public key is inadequate to uniquely identify a key.

The cryptographic hash of a public key is adequate to uniquely identify 
a key when that cryptographic hash has no known weaknesses. That is the 
purpose of KeyID, which is a structure defined in the draft.

SHA-1, although not completely broken, is on its way out. For long-term 
identification, SHA-1 is inadequate to uniquely identify a key or 
anything else. That is why there is a push for "algorithm agility" in 
more recent standards.

A "subject key identifier" value is NOT the cryptographic hash of a 
public key. It is whatever the issuer decides to put in a certificate. 
It is an opaque identifier. Outside of a certificate, an implementation 
can index certificates using whatever subject key identifiers it chooses.

CA #1 can choose subject key identifiers as follows:
Arbitrary Cert #1: "01"
Arbitrary Cert #2: "02"
Arbitrary Cert #3: "01"

Any other CA #2 can choose subject key identifiers as follows:
Arbitrary Cert #1bis: "01"
Arbitrary Cert #2bis: "02"
Arbitrary Cert #3bis: "30945203592039"

Effectively the Subject Key Identifier is useless except to distinguish 
between two certificates issued by the same CA.

Even then, nothing in RFC 5280 actually prohibits setting all 
certificates to use the same subject key identifier in a set of 
end-entity certificates. A conforming CA can also issue subject key 
identifiers that vary for every certificate, even if the subject public 
keys are identical.

There are a lot of SHOULD and RECOMMENDED, but no MUST or MUST NOT in 
RFC 5280 sec. 4.2.1.2. Furthermore: "Applications are not required to 
verify that key identifiers match when performing certification path 
validation." Subject key identifiers are purely advisory.

If you don't believe me, please quote exactly from RFC 5280 sec. 4.2.1.2 
to prove your point.

Sean

---

From: Sean Leonard <[email-masked]>
Date: Tue, 23 Feb 2010 13:25:16 -0800

> stored. Motivate why this relationship is important to certify/include

Is it necessary to provide a use case specifically for including 
GeneralName in certificates under RFC 5280 alone? Or, is it sufficient 
to provide use cases for other protocols under the PKIX umbrella, including:
SCVP
CRMF/CMC
OCSP

?

Sean

---

From: Stephen Kent <[email-masked]>
Date: Tue, 23 Feb 2010 13:36:20 -0500

At 9:39 AM -0800 2/23/10, Sean Leonard wrote:
>O
>>...
>
>SKI and AKI are only defined by the issuing CA to disambiguate 
>different certificates (specifically, different keys). They have no 
>global uniqueness guarantees. They also do not even have 
>"issuer-uniqueness" guarantees, because a CA may reuse the same SKI 
>for different certificates. In fact, there are crypto stacks that 
>(correctly according to the standards) allow users and applications 
>to change the subject key identifiers that certificates are indexed 
>under.

SKI/AKI are not guaranteed to be unique cert IDs, even if based on 
key hashes from the best possible hash algorithm. Not only is there a 
collision opportunity, but re-use of the same key in different certs 
(e.g., an overlapping, renewed cert for the same subject) is allowed.

>SHA-1 hash. This is inadequate in this day and age. See RFC 5280 
>sec. 4.2.1.2 and X.509-200508 sec. 8.2.2.2.

4.1.2.2 has a SHOULD for a method that trues to be unique, but the 
specific use of a SHA-1 hash are just examples. As you noted, the 
only requirement is that the SKI/AKI match between certs. So, let's 
ignore the hash collision debate here and a CA could choose to use 
another hash function.

Sean,

I too would like a clearer motivation for this work.  As you noted, 
we already have ways to refer to one cert from another cert, although 
these are imperfect. I'd like to hear from tbe authors of the docs 
which use such pointers (e.g., the AC profile, Other Certs, etc.) as 
to whether they feel a need for another form of pointer. Also, if 
they do want such a pointer, do they need it to be a GeneralName 
instance? (GeneralName is not intended to name certs, but to name 
subjects and issuers, so it is not clear to me why this would be a 
good choice.)

Steve

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 23 Feb 2010 22:01:02 -0800

Tim,

One reason why it might be inadequate is the question of including the
algorithm parameters in the hash.  Should an RSA key have the same key id if
in one place you say it is for use with RSA v1.5 and in another place it
should only be used with RSA-PSS?  One can argue either way.

Additionally, I would not say that the SKI has any uniqueness.  There is
nothing that says the user cannot define the SKI and do so in a
non-cryptographic, but locally unique manner.  (i.e.  "JIMSCH-0001")

Jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Miller, Timothy J.
> Sent: Tuesday, February 23, 2010 11:46 AM
> To: Sean Leonard
> Cc: Stefan Santesson; [email-masked]
> Subject: Re: [pkix] Proposal to review and adopt CertID and KeyID
> proposal
> 
> different
> Can you show me *any* collision between two randomly generated key
> pairs of any cryptographically meaningful key length--let's say, of a
> key length equivalent to RSA1024 or longer--in any algorithm?  By my
> back-of-the-envelope estimation, the probability is so vanishingly
> small that this *is* a guarantee in and of itself.
> 
> If I hold multiple certifications of the same key, insofar as
> *authentication* goes all of them point to me, the keyholder, because
> I can complete a private key proof with any of them (or all of them at
> once).
> 
> To perform *authorization*, yes, you need to map that key to an
> identity--but I don't personally care which certificate you actually
> use.  That's entirely your choice.
>

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 24 Feb 2010 09:13:58 +0100

> to provide use cases for other protocols under the PKIX umbrella, 
Why don't you just start with use cases in the context of these 
protocols? Or any other...

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 24 Feb 2010 10:04:40 +0100

OK, point taken.

Then where are you going to store this identifier carried in a GeneralName?
Is it going to be stored in a certificate at all or elsewhere?

If it is going to be stored in a certificate using any of the existing
extensions, the choices are:

Authority Key Identifier (describing AuthorityCertIssuer)
Subject Alternative Name
Issuer Alternative Name
Name Constraints
CRL Distribution Points (cRLIssuer or fullName)
Authority Information Access (accessLocation)
Subject Information Access (accessLocation)

I don't see a natural fit in any of those locations.
It might help if I understood your use case better.

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 24 Feb 2010 10:23:09 +0100

Sean,

I think I'm learning new things about your intentions so here is what I
suggest:

If you want these identifiers to be stored in a certificate, then you should
provide information on where it would be included and the semantics of it.
I.e. The exact relation between the identified certificate and the one
carrying the identifier.

For use in other protocols I simply want you to show how it adds value to
those protocols. Other IETF/PKIX protocol already have identifiers like
yours such as ESSCertIDv2 and SCVPCertID. How would those protocols benefit
from your new identifiers inside GeneralName.

/Stefan

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 24 Feb 2010 13:33:11 +0000

Hi,

> structures in the context of GeneralName.

My main concern would be: why bother? AFAIK there's zero to not
much implementation of 4043 and for 5697 the only code (so far)
that I know of was done by a student of mine, so I've got a hard
time seeing the huge pent-up demand for this. I think that's also
why other folks were asking about use-cases, so I don't believe
its correct to say that there are no objections to this or parts
of this I-D, since that'd be premature until people have accepted
that there's a problem to solve.

> So first, here's a hypothetical (but straightforward) example. 

Hypothethetical use-cases aren't very convincing for something
intended for the standards track IMO, but ignoring that for now...

Why not use the Targets extension in rfc5755 if you really need
this? Assuming that there's demand for this kind of restriction,
(which I don't accept at this point), it might need an RFC to
say that its ok to put Targets in a PKC (though I guess X.509
probably allows it), but I think that particular spanner is
already in PKIX's voluminous toolbox.

If there's really more to all this (I'd need convincing about "better
things and better thinking") in terms of these kinds of structure
being generally better than X.509/5280, then that sounds more like
a discussion to be had in the PKRG (I don't mean proposing this I-D
to PKRG, but rather discussing on that list why you think these
structures are so much better).

Regards,
S.

> A

---

From: "Kemp, David P." <[email-masked]>
Date: Wed, 24 Feb 2010 11:09:43 -0500

Not only is the example hypothetical, but I don't understand it.

1) Certificates are used by relying parties, not by subjects (which use
private keys).  If the user tries to connect with login.foo.com.evil.xy
("evil"), and evil wants to attack the user, then evil will ignore
whatever restrictions are contained in the certificate.

2) If the user's organization wants to blacklist evil for certain users
and not for others, there are far better ways of managing access lists
than by putting them in user certificates (or OCSP or CMP protocol
messages).  There is no way I'm going to get a new Common Access Card
every time a new associatedServer pops up in the DoD.

3) The fact that GeneralName is used by many protocols is irrelevant.
Any nameform must be embedded in a structure (such as subjectAltName in
certificates, or CVRequest.responderName in SCVP) that communicates the
semantics of the name.  A subjectAltName means something different than
an issuerAltName even though they both use GeneralName syntax.  An SCVP
requestorName means something different than a responderName.  Creating
a certID or keyID nameform accomplishes nothing with respect to
associating a server with a user.  PKIX would need to define an
"associatedServerName" certificate extension or an SCVP
"associatedServerName" request, and applications would need to be
modified to support those new extensions or requests in order to
accomplish anything.

4) RFC 4043 (Permanent Identifier) is not the only example of
GeneralName as an identifier; all nameforms can be used that way.
UniformResourceIdentifiers even have two different names for the two
usages: URN for an identifier and URL for an access location, but rfc822
names, IP addresses, and DNS names can all be used to identify things
without accessing them.  A directoryName is used only to identify - a
user can never be contacted at his DN (well, at least I haven't run
across anyone with X.500 email recently).

In short, you need a use case that a) makes sense, and b) shows how some
PKIX protocol or structure would make use of the certID or keyID
nameforms.  This is in addition to addressing others' objections
regarding why existing cert references such as ESSCertIDv2 are
insufficient.  It seems *more* confusing to use GeneralName as a certID:

CVRequest ::= SEQUENCE {
        cvRequestVersion        INTEGER DEFAULT 1,
        query                   Query,
        requestorRef        [0] GeneralNames OPTIONAL,
        requestNonce        [1] OCTET STRING OPTIONAL,
        requestorName       [2] GeneralName OPTIONAL,
        responderName       [3] GeneralName OPTIONAL,
        requestExtensions   [4] Extensions OPTIONAL,
        signatureAlg        [5] AlgorithmIdentifier OPTIONAL,
        hashAlg             [6] OBJECT IDENTIFIER OPTIONAL,
        requestorText       [7] UTF8String (SIZE (1..256)) OPTIONAL,
	  serverCert          [8] GeneralName OPTIONAL
-- <----- New
}

rather than a straightforward certificate reference:

CVRequest ::= SEQUENCE {
        cvRequestVersion        INTEGER DEFAULT 1,
        query                   Query,
        requestorRef        [0] GeneralNames OPTIONAL,
        requestNonce        [1] OCTET STRING OPTIONAL,
        requestorName       [2] GeneralName OPTIONAL,
        responderName       [3] GeneralName OPTIONAL,
        requestExtensions   [4] Extensions OPTIONAL,
        signatureAlg        [5] AlgorithmIdentifier OPTIONAL,
        hashAlg             [6] OBJECT IDENTIFIER OPTIONAL,
        requestorText       [7] UTF8String (SIZE (1..256)) OPTIONAL,
	  serverCert          [8] ESSCertIDv2 OPTIONAL
-- <----- New
}

Dave

-----Original Message-----
Stephen Farrell

---

From: Russ Housley <[email-masked]>
Date: Wed, 24 Feb 2010 11:13:55 -0500

Sean:

RFC 3281 includes structures in an attribute certificate that point back
to a particular certificate.  Can those same structures be used here to
provide the same linkage?

Russ

---

From: "Kemp, David P." <[email-masked]>
Date: Wed, 24 Feb 2010 17:24:48 -0500

-----Original Message-----
From: Sean Leonard

> Nothing prevents you from running an OCSP request over
> XMPP, even though doing so is not standardized. If you 
> wanted to do it, the natural way to identify the server
> would be an accessLocation of
> GeneralName/OtherName/id-on-xmppAddr [RFC3920].

And the natural way for an OCSP client to protect itself from DNS
spoofing or other impersonation attacks would be to check the server's
certificate subjectAltName for the intended xmppAddr.  If the OCSP
responder is offering service over XMPP, then it should have a server
certificate containing the responder's XMPP identifier.

It would be bizarre and unnatural for the client to obtain a client
certificate containing a CertID reference to a particular OCSP
responder's certificate.  How many certificates would a client need if
it wanted to connect to 100 web servers, and validate the web server
certificates using 100 different OCSP responders?

Dave

---

From: "Miller, Timothy J." <[email-masked]>
Date: Thu, 25 Feb 2010 13:11:59 -0500

I'm aware that the use of a hash in SKI is a recommendation and not a requirement.  I used this as a concrete example because SKI is commonly implemented this way, but in the end it's immaterial because it's not particularly difficult for an implementation to derive the value on the fly.  

The essential point is that when it comes to unique identifiers, the best possible identifier (or source for deriving one) is already in the cert--the public key.

-- Tim

---

From: Stephen Kent <[email-masked]>
Date: Thu, 25 Feb 2010 13:29:06 -0500

At 1:11 PM -0500 2/25/10, Miller, Timothy J. wrote:
>I'm aware that the use of a hash in SKI is a recommendation and not 
>a requirement.  I used this as a concrete example because SKI is 
>commonly implemented this way, but in the end it's immaterial 
>because it's not particularly difficult for an implementation to 
>derive the value on the fly. 
>
>The essential point is that when it comes to unique identifiers, the 
>best possible identifier (or source for deriving one) is already in 
>the cert--the public key.
>
>-- Tim

Tim,

In general I agree, but we need to be clear that the public key (or a 
hash thereof) is not a unique cert ID. For example, it would not be 
unreasonable to encounter two certs with the same key, associated 
with the same subject, with different (but overlapping) validity 
intervals.

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 25 Feb 2010 14:05:04 -0500

And a very simple example of what Steve is saying is OCSP certificate
with no-check.

Many implementations use the same Responder DN and key and use manual or
automated means to issue the Responder several short life certificates. 

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Stephen Kent
> Sent: Thursday, February 25, 2010 1:29 PM
> To: Miller, Timothy J.
> Cc: Stefan Santesson; Sean Leonard; [email-masked]
> Subject: Re: [pkix] Proposal to review and adopt CertID and 
> KeyID proposal
> 
> >I'm aware that the use of a hash in SKI is a recommendation 
> and not a 
> >requirement.  I used this as a concrete example because SKI 
> is commonly 
> >implemented this way, but in the end it's immaterial because 
> it's not 
> >particularly difficult for an implementation to derive the 
> value on the 
> >fly.
> >
> >best possible identifier (or source for deriving one) is 
> already in the 
> >cert--the public key.
> >
> >-- Tim
> 
> Tim,
> 
> In general I agree, but we need to be clear that the public 
> key (or a hash thereof) is not a unique cert ID. For example, 
> it would not be unreasonable to encounter two certs with the 
> same key, associated with the same subject, with different 
> (but overlapping) validity intervals.