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

From: Sean Leonard <[email-masked]>
Date: Mon, 01 Mar 2010 12:46:31 -0800

That's a great idea, Russ! (Also Stephen Farrell, for suggesting the 
Targets extension.) One of the attribute certificate structures might 
actually be more appropriate for the proposed linkage.

I am looking into that, and will post results after I analyze it a bit more.

Best regards,

Sean

On 2/24/2010 8:13 AM, Russ Housley wrote:
> 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: Sean Leonard <[email-masked]>
Date: Tue, 02 Mar 2010 12:45:05 -0800

Thank you for the comments, both public and private, regarding the 
CertID and KeyID proposal.

On review of the structures, it appears that repurposing the Holder 
field of an attribute certificate will give us what we need, because the 
Holder field can identify a certificate, public key, or other entity. 
The Target field is a close match but is not exact because there is no 
way to identify a public key (or all certificates containing a public 
key) directly, short of specifying such a thing in the GeneralName.

Peer review frequently helps and I think that in this case, the review 
was successful in identifying redundant parts of the proposal compared 
with the existing uses of GeneralName.

Nevertheless, I think that the CertID and KeyID proposal remains viable 
for its original purpose, as there is a fair amount of confusion out 
there about things like SubjectKeyIdentifier (and how it is not 
guaranteed to be universally unique). I would therefore like to revise 
the document in the following ways:

* Remove GeneralName proposals (section 4).
* Refocus the proposal to standardizing on a single structure for 
uniquely identifying certificates on a going-forward basis. Namely:
   PKIXCertID ::= ESSCertIDv2
  ,
   PKIXCertID ::= SCVPCertID
  ,
   or a new structure (although I think that using one of the existing 
structures is better, as the whole point is to reduce complexity, not 
add to it).
* State that new protocols SHOULD use PKIXCertID when uniquely 
identifying an existing certificate. Existing protocols are not 
modified, as they are already set in stone. New protocol designers need 
to decide first whether it is necessary to uniquely identify a 
certificate, or whether it is sufficient to identify certificates 
non-uniquely. If uniqueness is required, then PKIXCertID SHOULD/MUST be 
used. If not, another method is appropriate, such as issuer + serial 
number, subject name matching, etc.

* Provide clearer guidance about how existing structures do not uniquely 
identify certificates or keys (beef up the sentence/paragraph in Section 
1 on this topic).

* I would like to hear other use cases for identifying a single key, or 
"all certificates containing a single key", alone. If there are use 
cases, I think that the KeyID proposal is still viable.

In our use case, it is desirable to identify "something by a 
GeneralName, or something by a certificate [and therefore a single key], 
or something by a key inside of any number of certificates." As stated 
above, the Holder field is the most appropriate for this use case.

If we are talking about just identifying a key inside of any number of 
certificates alone, RFC 5755's ObjectDigestInfo is okay, but is less 
than ideal. The reason why is because you can identify a key with the 
ENUMERATED publicKey (0) option, but ObjectDigestInfo alone does not 
provide pointer information on how to locate the key. You can use the 
other fields of Holder for this purpose (baseCertificateID to find a 
certificate with that key, for example), but Holder may be seen as 
unnecessarily complicated if you do not care about all the generality.

If a use case cannot be found, it would be fine to eliminate the KeyID 
structure as-proposed, and make that section a non-normative section of 
how to identify keys using various methods (namely, reproducing the 
paragraphs above).

Regards,

Sean

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 02 Mar 2010 22:46:38 +0100

Sean,

On this particular issue:

>    PKIXCertID ::= ESSCertIDv2

What is the point of defining PKIXCertID?
Why not just refer to ESSCertIDv2?

As we have done in RFC 3161 update. See:
http://tools.ietf.org/html/draft-ietf-pkix-rfc3161-update-09

/Stefan

---

From: Sean Leonard <[email-masked]>
Date: Tue, 02 Mar 2010 14:13:23 -0800

On 3/2/2010 1:46 PM, Stefan Santesson wrote:
> On 10-03-02 9:45 PM, "Sean Leonard"<[email-masked]>  wrote:
>
>    

For BER/CER/DER-encoded data, there is no practical difference. Which is 
the point, because I think it's undesirable to design a new structure.

For other encodings and for actual implementations, the name may make a 
difference (e.g., XER encoding, Java foo.pkix.types.PKIXCertID, C/C++ 
struct/class PKIXCertID, etc.).

The main advantage of naming it that way, as an alias, is the same as 
naming any structure by its intended purpose rather than some random 
word like F$mal. ESSCertIDv2 suggests that the structure is associated 
with S/MIME Enhanced Security Services. But by making it an alias rather 
than redefining PKIXCertID, the same code paths can be (mostly) reused. 
That's all.

Sean