Subject: [pkix] Possible new work item: additional methods for generating key identifiers

From: Sean Turner <[email-masked]>
Date: Wed, 16 Jun 2010 10:17:22 -0400

Greetings.  Steve and I have whipped up a short I-D that specifies 
additional methods for generating key identifiers from a public key. 
The draft can be found at:

http://datatracker.ietf.org/doc/draft-turner-additional-methods-4kis/

I'd like to ask the WG to consider adopting this as a WG item.

Cheers,

spt*

* (with no hat on)

---

From: "Henry B. Hotz" <[email-masked]>
Date: Wed, 16 Jun 2010 10:17:49 -0700

Since some vendors (*ahem* name starts with A) use the SKI unqualified by Issuer or anything else, it might be nice if there were a standards-track algorithm which munged in the ancillary information to get something that really characterized the entire cert, not just the public key.

I notice you specify the LSB of the hash.  Is that preferable to the center bits?  (I suppose if these hashes are as good as they're supposed to be then there shouldn't be any edge effects.)

On Jun 16, 2010, at 7:17 AM, Sean Turner wrote:

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

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: Sean Turner <[email-masked]>
Date: Wed, 16 Jun 2010 13:35:21 -0400

Henry,

Thanks for reading it.  Responses below.

spt

> Since some vendors (*ahem* name starts with A) use the SKI unqualified by Issuer or anything else, it might be nice if there were a standards-track algorithm which munged in the ancillary informati…

I'm not sure what you mean here.  I'm not sure how you're qualify the 
OCTET STRING.

> I notice you specify the LSB of the hash.  Is that preferable to the center bits?  (I suppose if these hashes are as good as they're supposed to be then there shouldn't be any edge effects.)

This was the one interesting question in my mind was whether or not 
the outputs should be truncated.  I erred on the side of some loose 
backward compatibility benefit of keeping the 160-bit hash.  Then we 
had to pick where from.  The second method in 5280 used the LSBs so I 
  went with that.

I'm also going with the thoughts that they are as good as they say 
they are and we only really need them to provide a high probability 
(but not a guarantee) of uniqueness.

---

From: "Miller, Timothy J." <[email-masked]>
Date: Wed, 16 Jun 2010 14:27:17 -0400

In general, if the SKI or AKI is a hash, qualification by issuer is unnecessary.  Keys are more than unique enough, and implementations of path discovery are supposed to handle bifurcations already..

I think both SKI and AKI need syntax qualifiers in all cases.  E.g., a vendor whose name begins with M presumes that SKI is always a hash, which in some places would lead to really bad security decisions.  Would it be better to generalize this work into qualifying AKI and SKI with syntax flags?

The problem with this is how to deal with backward compatibility.

-- Tim 
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Henry B. Hotz [[email-masked]]
Sent: Wednesday, June 16, 2010 12:17 PM
To: Sean Turner
Cc: [email-masked]
Subject: Re: [pkix] Possible new work item: additional methods for      generating key identifiers

---

From: "Henry B. Hotz" <[email-masked]>
Date: Wed, 16 Jun 2010 12:25:19 -0700

> The problem with this is how to deal with backward compatibility.

If vendors don't implement the required qualifications as it is, I suspect that making the type even more complex risks making the situation worse rather than better.  (Not saying you're wrong, just griping in general.)

---

From: "Kemp, David P." <[email-masked]>
Date: Wed, 16 Jun 2010 15:55:55 -0400

To be fair to "M", there are no "required qualifications".  A spec that
says "you can create SKI any way you want, but FYI here are a couple of
examples to consider"* is not normative.   In contrast, ISO 9834 and
RFC4122 contain definite syntax requirements, so there is some
reasonable expectation that they will be followed.

A normative standard for AKI/SKI could not possibly make things worse.
But as Tim says, backward compatibility is an issue because it is
impossible to reliably transition from an unconstrained OCTET STRING to
a qualified one without assigning new extension OIDs.

Dave

--------------------------
* RFC 5280 says:

    subject key identifiers SHOULD be derived from
    the public key or a method that generates unique values.  Two common
    methods for generating key identifiers from the public key are:
    (1) ...
    (2) ...
    Other methods of generating unique numbers are also acceptable.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Henry B. Hotz
Sent: Wednesday, June 16, 2010 3:25 PM
To: Miller, Timothy J.
Cc: [email-masked]
Subject: Re: [pkix] Possible new work item: additional methods
forgenerating key identifiers

On Jun 16, 2010, at 11:27 AM, Miller, Timothy J. wrote:

> In general, if the SKI or AKI is a hash, qualification by issuer is
unnecessary.  Keys are more than unique enough, and implementations of
path discovery are supposed to handle bifurcations already..
> 
> I think both SKI and AKI need syntax qualifiers in all cases.  E.g., a
vendor whose name begins with M presumes that SKI is always a hash,
which in some places would lead to really bad security decisions.  Would
it be better to generalize this work into qualifying AKI and SKI with
syntax flags?
> The problem with this is how to deal with backward compatibility.

If vendors don't implement the required qualifications as it is, I
suspect that making the type even more complex risks making the
situation worse rather than better.  (Not saying you're wrong, just
griping in general.)

---

From: "Miller, Timothy J." <[email-masked]>
Date: Wed, 16 Jun 2010 17:48:17 -0400

(To be further fair to M, they did what they did based on an incomplete recommendation--but then again they didn't think it through either, so the recommender who shall remain similarly nameless refuses to take all the blame too.  :)

Since it's an unconstrained OCTET STRING, we can literally shove a syntax inside it; that's the easy bit.  
I mean, I can slap together a simple SKI type in seconds; e.g.:

proposedSKI ::= SEQUENCE {
	type-id	OBJECT IDENTIFIER, 
	value		[0] EXPLICIT ANY DEFINED BY type-id }

Then you pick an new OID parent for SKI syntaxes, and start listing requirements.  E.g.:

id-ki				OBJECT IDENTIFIER ::= { id-pkix X }
id-ki-sha1			OBJECT IDENTIFIER ::= { id-ki 1 }
id-ki-sha256		OBJECT IDENTIFIER ::= { id-ki 2 }
id-ki-uuidType3binary	OBJECT IDENTIFIER ::= { id-ki 3 }
id-ki-timsOwnBitTwiddle	OBJECT IDENTIFIER ::= { id-ki 4 }
... and so on.

The hard bit is how do you instruct implementers adequately on how to parse the keyIdentifier and when not to parse it?   

E.g., if I'm a validation engine and I've just yanked a 20-byte keyIdentifier value from a cert and I need to know how to use it--what do I do?  We could tell implementers "test it for proposedSKI encoding, and if you find the proper encoding there obey it, and if you don't treat it like OCTET STRING."  But that's butt-ugly and wouldn't get past the WG (rightly so, IMHO).  In fact, what you end up with in code is an *exception* execution path, which is not the kind of thing I'd like to rely on for normal processing.  Exception processing is for exceptions!

If I had a good answer to this I could fix a number of other problems, and not just in this standard.  :)

-- Tim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kemp, David P.
Sent: Wednesday, June 16, 2010 3:56 PM
To: [email-masked]
Subject: Re: [pkix] Possible new work item: additional methods forgenerating key identifiers

Dave

---

From: "Henry B. Hotz" <[email-masked]>
Date: Wed, 16 Jun 2010 15:54:40 -0700

I thought there was a requirement that the SKI be unique for an issuer?  Or is that only for the serial number?

---

From: Sean Turner <[email-masked]>
Date: Thu, 17 Jun 2010 09:14:45 -0400

> I thought there was a requirement that the SKI be unique for an issuer?  Or is that only for the serial number?

There's a requirement that it be unique for CA keys:

  For CA certificates, subject key identifiers SHOULD be derived from
  the public key or a method that generates unique values. Two common
  methods for generating key identifiers from the public key are:

For EE's certs it says:

  For end entity certificates, the subject key identifier extension
  provides a means for identifying certificates containing the
  particular public key used in an application.  Where an end entity
  has obtained multiple certificates, especially from multiple CAs, the
  subject key identifier provides a means to quickly identify the set
  of certificates containing a particular public key.  To assist
  applications in identifying the appropriate end entity certificate,
  this extension SHOULD be included in all end entity certificates.

  For end entity certificates, subject key identifiers SHOULD be
  derived from the public key.  Two common methods for generating key
  identifiers from the public key are identified above.

>> reasonable expectation that they will be followed.

This is true, but when people read the bits about the CA keys, I've 
heard people more than once quote the 1st sentence about it being a 
SHOULD and saying we've only got two choices.

They'll back it up by quoting this:

  Where a key identifier has not been previously established, this
  specification RECOMMENDS use of one of these methods for generating
  keyIdentifiers or use of a similar method that uses a different hash
  algorithm.

So all I  want to do is expand the number of options that are 
documented in that section.  And, they're using a "similar method" to 
the ones already there.  Many times implementers aren't going to make 
these additional methods up, they want to see them in the standard 
even as examples.  That's the point of this I-D.

---

From: Stephen Kent <[email-masked]>
Date: Fri, 18 Jun 2010 08:34:05 -0400

I appreciate the benefits that would accrue from typed key IDs.  But, 
backward compatibility seems to be critically important here.

Would a new extension that included a key ID generation ID, and that 
was used to qualify the existing AKI/SKI extension values be of any 
use? That would allow a knowledgeable RP to recognize the key ID alg 
that was used, when this extension was present. If knowledge of the 
key ID generation alg was critical to its interpretation (vs, what 
Sean and I have suggested), we would allow the extension  to be 
marked critical.

Not sure of that would help, but thought I would mention it anyway.

Steve

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 18 Jun 2010 12:08:26 -0600

Sean and Steve,

I would take issue with the statement:

The plethora of options does not impact interoperability because key 
   identifiers are unilaterally generated by Certification Authorities 
   (CAs).

I disagree with the term "unilaterally generated".  I believe the SKIs can
also be generated by the certificate requester as well as the certificate
issuer.  Otherwise getting a cross certificate for a CA that contained the
same value for the SKI would be impossible.

Jim

> Sean Turner
> Sent: Wednesday, June 16, 2010 8:17 AM
> To: [email-masked]
> Subject: [pkix] Possible new work item: additional methods for
> generating key identifiers
>

---

From: Tom Gindin <[email-masked]>
Date: Mon, 21 Jun 2010 08:21:44 -0400

Tim:

        The new syntax has the first four bytes of the current KI are 30, 
x, 06, N (assuming KI length under 200 bytes and normal OID's).  The easy 
way to make it backward compatible with existing 20-and-under binary KI's 
and string KI's is to require that the value be between 16 and 200 bytes 
long.  The algorithm then becomes: if Length > 22, first byte 0x30, and 
third byte 0x06, it's the new syntax.
        Does anybody currently generate non-UTF-8 KI's which are more than 
20 bytes long?

Tom Gindin

From:
"Miller, Timothy J." <[email-masked]>
To:
"[email-masked]" <[email-masked]>
Date:
06/16/2010 05:51 PM
Subject:
Re: [pkix] Possible new work item: additional methods   forgenerating key 
identifiers
Sent by:
[email-masked]

(To be further fair to M, they did what they did based on an incomplete 
recommendation--but then again they didn't think it through either, so the 
recommender who shall remain similarly nameless refuses to take all the 
blame too.  :)

Since it's an unconstrained OCTET STRING, we can literally shove a syntax 
inside it; that's the easy bit. 
I mean, I can slap together a simple SKI type in seconds; e.g.:

proposedSKI ::= SEQUENCE {
                 type-id                 OBJECT IDENTIFIER, 
                 value                           [0] EXPLICIT ANY DEFINED 
BY type-id }

Then you pick an new OID parent for SKI syntaxes, and start listing 
requirements.  E.g.:

id-ki                                                            OBJECT 
IDENTIFIER ::= { id-pkix X }
id-ki-sha1                                               OBJECT IDENTIFIER 
::= { id-ki 1 }
id-ki-sha256                             OBJECT IDENTIFIER ::= { id-ki 2 }
id-ki-uuidType3binary            OBJECT IDENTIFIER ::= { id-ki 3 }
id-ki-timsOwnBitTwiddle          OBJECT IDENTIFIER ::= { id-ki 4 }
... and so on.

The hard bit is how do you instruct implementers adequately on how to 
parse the keyIdentifier and when not to parse it? 

E.g., if I'm a validation engine and I've just yanked a 20-byte 
keyIdentifier value from a cert and I need to know how to use it--what do 
I do?  We could tell implementers "test it for proposedSKI encoding, and 
if you find the proper encoding there obey it, and if you don't treat it 
like OCTET STRING."  But that's butt-ugly and wouldn't get past the WG 
(rightly so, IMHO).  In fact, what you end up with in code is an 
*exception* execution path, which is not the kind of thing I'd like to 
rely on for normal processing.  Exception processing is for exceptions!

If I had a good answer to this I could fix a number of other problems, and 
not just in this standard.  :)

-- Tim

-----Original Message-----
Kemp, David P.

Dave

---

From: "Miller, Timothy J." <[email-masked]>
Date: Mon, 21 Jun 2010 09:43:11 -0400

The thing is, IMO this violates how ASN.1 encoding is supposed to be parsed.  I shouldn't be running tests against values in order to decide what's in it--that's what the tag is for.

-- Tim

>From: Tom Gindin [mailto:[email-masked]]
>Sent: Monday, June 21, 2010 7:22 AM
>To: Miller, Timothy J.
>Cc: [email-masked]; [email-masked]

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 21 Jun 2010 09:54:26 -0400

Key Identifier is an Octet string.  It will have nothing to do with UTF
8.

> Sent: Monday, June 21, 2010 8:22 AM
> To: Miller, Timothy J.
> id-ki
OBJECT

---

From: Stephen Kent <[email-masked]>
Date: Tue, 22 Jun 2010 09:35:32 -0400

>same value for the SKI would be impossible.

Good point, re the mutual cross-certification case

Steve

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 23 Jun 2010 11:26:03 +0200

Sean,

I'm not convinced that we need more specified ways to calculate SKI and AKI.
On the contrary I think we may need less.

Basically I think this conclusion is false:

   The plethora of options does not impact interoperability because key
   identifiers are unilaterally generated by Certification Authorities
   (CAs). Relying parties only compare and copy these values and thus
   are insulated (for the most part) from the specific mechanisms used
   to generate them.

So here is a real life example.

Acrobat reader is one example of an application which, despite what RFC 5280
suggests, requires SKI/AKI match in order to recognize a path.
A perfectly valid path with mismatching AKI/SKI values will not be accepted.

Combining this with the fact that lots of common CA implementations doesn't
give you the choice to select SKI algorithm, neither allows you to set an
arbitrary value. OpenSSL is one of the few that allows you to set an
arbitrary value composed from an external calculation, but that seems to be
the exception.

This creates problem for cross certification where the generated SKI in the
cross certificate is getting less and less likely to match AKI of issued
certificates of the cross certified CA.

Such paths will be rejected e.g. by acrobat reader.

Since we do not require cryptographic strength, I would much rather make a
strong recommendation to pick and use the most common SKI calculation
defined in RFC 5280 rather than defining a whole bunch of new ways to
calculate SKI/AKI.

This is simply yet one of the areas where theory and practice don't really
align perfectly. Hence we should pick the option that creates least
problems.

/Stefan

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 23 Jun 2010 22:13:18 +1200

>On the contrary I think we may need less.

Not necessarily.  If you have half-a-dozen more or less arbitrary ways of
doing it, it'll reinforce the message that an sKID/aKID doesn't have any magic
defined format, which is a misconception I've run into a number of times
(including on this list).  So having many ways mentioned isn't necessarily a
bad thing.

Peter.

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 23 Jun 2010 09:42:13 -0400

Stefan,

While I do not see a need for separate RFC, most of material in the I-D
is not objectionable.  It is useful to augment 5280 (or modify it) to
permit other hash algorithms as they become available in place of a new
RFC.  In that regard, I would rather revise 5280 and simply replace SHA1
with any hash to accommodate hashes other than SHA 1 and SHA 256.
Truncation of hash output is also a good idea.

Some guidance in 5280 on honoring SKID in P10 or CSR of any form is also
good.

I do not agree with your assertion about I-D conclusion being false.
I-D statement is accurate.

I also do not like the idea of achieving interoperability by defining a
or very few method for KID calculation.  I rather CAs honor SKID in CSR
extensions and most CAs do.  For the activities I am involved with, for
the Bridge environments they had to add the capability to their products
to be considered as meeting the requirements.

> Stefan Santesson
> Sent: Wednesday, June 23, 2010 5:26 AM
> To: Sean Turner; [email-masked]
> I'm not convinced that we need more specified ways to calculate SKI
and
> AKI.
> Acrobat reader is one example of an application which, despite what
RFC
> 5280
> This creates problem for cross certification where the generated SKI
in
> the

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 23 Jun 2010 16:02:15 +0200

Santosh,

It's not debatable whether mismatching AKI/SKI is an interop issue. It
simply is.

I can agree, that it should not be an issue, but it is. I have first hand
practical experience with exactly this issue.

> For the activities I am involved with, for

That is good news. I have encountered products/libraries where this was not
possible. I hope this will change.

/Stefan

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 23 Jun 2010 10:29:10 -0400

Stefan,

How do you derive from my post that I debate the AKID/SKID matching
point?

Actually, both the I-D and I recognize that point as immutable and that
is why the suggestions.

> From: Stefan Santesson [mailto:[email-masked]]
> Sent: Wednesday, June 23, 2010 10:02 AM
> To: Santosh Chokhani; Sean Turner; [email-masked]
> That is good news. I have encountered products/libraries where this
was
> not
> > I also do not like the idea of achieving interoperability by
defining
> a
> >> From: [email-masked] [mailto:[email-masked]] On
Behalf
> > Of
> >> give you the choice to select SKI algorithm, neither allows you to
> set
> >> an
> >> arbitrary value composed from an external calculation, but that
> seems
> >> to be
> >> the exception.
> >>

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 23 Jun 2010 16:51:27 +0200

> How do you derive from my post that I debate the AKID/SKID matching

Your statement: "I do not agree with your assertion about I-D conclusion
being false."

The debated I-D conclusion is: "The plethora of options does not impact
interoperability"

> Actually, both the I-D and I recognize that point as immutable and that

Still not sure how more standardized ways to calculate AKI/SKI improves
interop.

/Stefan

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 23 Jun 2010 10:56:58 -0400

Stefan,

They do not impact interoperability since the CA will honor the SKID
requested, specially by another CA.

Relying parties and issuers do not need to worry about the method used.
Relying parties just match the values and issuers just the value.

> Sent: Wednesday, June 23, 2010 10:51 AM
> >> I can agree, that it should not be an issue, but it is. I have
first
> >> hand
> >>> While I do not see a need for separate RFC, most of material in
the
> >> I-D
> >>> permit other hash algorithms as they become available in place of
a
> >> new
> >>> RFC.  In that regard, I would rather revise 5280 and simply
replace
> >> SHA1
> >>> Some guidance in 5280 on honoring SKID in P10 or CSR of any form
is
> >> also
> >>> or very few method for KID calculation.  I rather CAs honor SKID
in
> >> CSR
> >>> extensions and most CAs do.  For the activities I am involved
with,
> >> for
for
> >>>>    The plethora of options does not impact interoperability
> because
> >>> key
> >>>> A perfectly valid path with mismatching AKI/SKI values will not
be
> >>>> accepted.
> >>>>
> >>>> Combining this with the fact that lots of common CA
> implementations
> >>>> doesn't
> >>>> Since we do not require cryptographic strength, I would much
> rather
> >>>> make a
> >>>> defined in RFC 5280 rather than defining a whole bunch of new
ways
> >> to
> >>>> calculate SKI/AKI.
> >>>>
> >>>> This is simply yet one of the areas where theory and practice
> don't
> >>>> really

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 23 Jun 2010 17:09:38 +0200

Santosh,

> requested, specially by another CA.

It does impact interoperability since not all CA products and CA capable
libraries allow SKID to be set to an arbitrary value.

> Relying parties just match the values and issuers just the value.

The relying party is affected if the certificate path he tries to use is
rejected in his application due to AKI/SKI mismatch.

So it MAY actually affect interoperability.

Now let me clarify:

1) I do NOT defend any company or product that enforces AKI/SKI match
2) I'm not saying that we should NOT define the new SKI/AKI algorithms as
suggested.

I'm just recognizing the facts of reality and want to discuss the best way
to deal with them.

/Stefan

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 23 Jun 2010 17:15:41 -0400

Stefan,

The KID is not being set to an arbitrary value.  You are honoring
extensions in P10 and CSR.  These structures have extensions precisely
for that purpose.

A better approach would be to survey CA vendors to see if they do or do
not honor SKID in P10 and CSR request.

I do not agree with the premise that CA products do not honor SKID in
P10, especially those from another CA's P10/CSR.  There may be some who
do not honor KID, but the widely used ones do honor KID.

We should focus on recommending or mandating that CAs honor the KID
requested as opposed to limiting number of KID options.

> Sent: Wednesday, June 23, 2010 11:10 AM
for
> >>>> It's not debatable whether mismatching AKI/SKI is an interop
> issue.
> >> It
> >>>> simply is.
> >>>>
> >>>>> is not objectionable.  It is useful to augment 5280 (or modify
> it)
> >>> to
> >>>>>>    (CAs). Relying parties only compare and copy these values
and
> >>>> thus
> >>>>>>    are insulated (for the most part) from the specific
> mechanisms
> >>>> used
> >>>>>>    to generate them.
> >>>>>>
> >>>>>> arbitrary value. OpenSSL is one of the few that allows you to
> set
> >>> an
> >>>>>> This creates problem for cross certification where the
generated
> >>> SKI
> >>>>> in
> >>>>>> the
> >>>>>> cross certificate is getting less and less likely to match AKI
> of
> >>>>>> issued
> >>>>>>> additional methods for generating key identifiers from a
public
> >>>> key.

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 24 Jun 2010 01:01:13 +0200

Santosh, 

CSR and P10 is not the only valid input source, especially not in the case
of cross certification.

I may for example want/need to cross certify a CA based on an existing
certificate, not a CSR.

In such case I will validate the subject name (CA name) and PoP by trusting
the original certificate and whatever other evidence I have that the CA
certificate is valid, such as a signed Trust service Status List (TSL) as
defined in the ETSI standard TS 102 231 which use is mandated by the
European commission for EU member states.

>From the perspective of the cross certifying CA I will then have to inject
the SKI of the original CA certificate into the cross certification process
to make sure that there will be a SKI/AKI match when using that cross
certificate.

This is not generally supported (even though OpenSSL do). Other tools insist
on calculating the SKI using a fixed internal algorithm.
In my case the following command will issues a cross certificate using
openSSL:.

openssl x509 -in certToBeXcertified.pem -CAkey private/cakey.pem -out
newCert.pem -CA cacert.pem -extfile extensions.cfg -clrext -days 365 -sha256

Where extensions.cfg in this example contains:

subjectKeyIdentifier=11982722E04AD543969AF3703D21D37085EACA9D #org SKI
authorityKeyIdentifier=keyid:always,issuer:always
basicConstraints = CA:true
keyUsage         = critical, cRLSign, keyCertSign
certificatePolicies    = ia5org,@xpolicy

[xpolicy]
policyIdentifier = 2.5.29.32.0  #anyPolicy

Other libraries I have tested do not allow setting the SKI value to the one
obtained form the original CA certificate.

In case further information is of interest I have made a demo video
available from: http://aaa-sec.com/tsltrust/videos/demovideo.html

/Stefan

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 24 Jun 2010 16:33:07 +1200

"Santosh Chokhani" <[email-masked]> writes:

>We should focus on recommending or mandating that CAs honor the KID requested
>as opposed to limiting number of KID options.

Why would you want to do this? It should be up to the CA, I specifically don't
allow them because I have no idea what sort of gibberish sKIDs users will
request (well, actually I do, which is why I don't honour them). So far I've
only ever found one case in which the EE wants control over the sKID, and that
was purely to work around some brokenness in someone else's PKI software.

Peter.

---

From: "Miller, Timothy J." <[email-masked]>
Date: Thu, 24 Jun 2010 10:20:00 -0400

IMHO the problem is KID is misunderstood.  I've seen implementations that *presume* that a KID is globally unique (hash-derived) rather than unique to the issuer, and so don't make the additional path check that would be necessary to catch shenanigans.  While global uniqueness is practically true for hash-derived KIDs, because non-hash-derived KIDs are allowed it's not a safe assumption to make.  (Note that a key generator can of course submit the same key to multiple CAs and get back the same SKID in each cert, but this isn't the same problem.)

As a result, honoring a requested SKID can exacerbate security vulnerabilities--i.e., I request a cert with a SKID that matches the hash-derived SKID in your cert, but from a different PKI.  I can then potentially authenticate as you to a system that trusts both PKIs but erroneously understands the current scope of SKID.

By itself, this at least deserves a security note in sec 8.  IMHO, CAs should be instructed to create their own EE SKIDs in all cases, unless there are specific requirements for particular SKIDs to be used for interoperability purposes.  RPs should be instructed to not rely on global uniqueness of a KID unless they check to make sure that it's actually a hash-derived KID by calculating the hash itself.  This latter case would be helped by having a KID syntax extension so the RP knows which hash algorithm to use.

-- Tim

>Peter Gutmann
>Sent: Wednesday, June 23, 2010 11:33 PM
>To: [email-masked]; [email-masked]; [email-masked];
>[email-masked]
>requested

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 24 Jun 2010 17:07:51 +0200

I agree with both Tim and Peter that it may be problematic to blindly accept
an SKI provided in a request.

Primary because it requires special caution for the CA to ensure that the
granted SKI is unique among all issued certificates.

I totally agree with Peter that it must be up to the CA to decide whether to
accept a suggested SKI or whether to generate it's own.

/Stefan

On 10-06-24 4:20 PM, "Miller, Timothy J." <[email-masked]> wrote:

> IMHO the problem is KID is misunderstood.  I've seen implementations that
> *presume* that a KID is globally unique (hash-derived) rather than unique to
> the issuer, and so don't make the additional path check that would be
> necessary to catch shenanigans.  While global uniqueness is practically true
> for hash-derived KIDs, because non-hash-derived KIDs are allowed it's not a
> safe assumption to make.  (Note that a key generator can of course submit the
> same key to multiple CAs and get back the same SKID in each cert, but this
> isn't the same problem.)
> 
> As a result, honoring a requested SKID can exacerbate security
> vulnerabilities--i.e., I request a cert with a SKID that matches the
> hash-derived SKID in your cert, but from a different PKI.  I can then
> potentially authenticate as you to a system that trusts both PKIs but
> erroneously understands the current scope of SKID.
> 
> By itself, this at least deserves a security note in sec 8.  IMHO, CAs should
> be instructed to create their own EE SKIDs in all cases, unless there are
> specific requirements for particular SKIDs to be used for interoperability
> purposes.  RPs should be instructed to not rely on global uniqueness of a KID
> unless they check to make sure that it's actually a hash-derived KID by
> calculating the hash itself.  This latter case would be helped by having a KID
> syntax extension so the RP knows which hash algorithm to use.
> 
> -- Tim
> 
>

---

From: "Carl Wallace" <[email-masked]>
Date: Thu, 24 Jun 2010 11:51:33 -0400

Stefan,

Please explain the utility of a SKID extension in a CA certificate where
the SKID does not match the AKID extension included in certificates with
signatures that can be verified using the public key in the CA
certificate.  

> Sent: Thursday, June 24, 2010 11:08 AM
> To: Miller, Timothy J.; 'Peter Gutmann'; [email-masked];
> [email-masked]; [email-masked]
> > for hash-derived KIDs, because non-hash-derived KIDs are allowed
it's
> not a
> > same key to multiple CAs and get back the same SKID in each cert,
but
> this
> > be instructed to create their own EE SKIDs in all cases, unless
there
> are
Behalf
> >> Why would you want to do this? It should be up to the CA, I
> specifically
> >> don't
> >> allow them because I have no idea what sort of gibberish sKIDs
users
> >> will
> >> request (well, actually I do, which is why I don't honour them). So
> far
> >> I've
> >> only ever found one case in which the EE wants control over the
> sKID,
> >> and that
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 24 Jun 2010 11:53:07 -0400

Stefan,

CA should and the ones I know do permit you to enter a SKID.

Since there is no specific method mandated by 5280 and CAs vary in their
approach, best thing is for the CA to put the requested SKID from other
CA.

> Sent: Wednesday, June 23, 2010 7:01 PM
> Other libraries I have tested do not allow setting the SKI value to
the
> one
> >> The relying party is affected if the certificate path he tries to
> use
> >> is
> >> 2) I'm not saying that we should NOT define the new SKI/AKI
> algorithms
> >> as
> >> suggested.
> >>
> >> I'm just recognizing the facts of reality and want to discuss the
> best
> >> way
> >> to deal with them.
> >>
> >> /Stefan
> >>
> >>
> >>
for
> >>>>> Actually, both the I-D and I recognize that point as immutable
> and
> >>>> that
> >>>>> is why the suggestions.
> >>>>>
> >>>>
> >>>>>>> the Bridge environments they had to add the capability to
their
> >>>>>> products
> >>>>>> On 10-06-23 3:42 PM, "Santosh Chokhani"
<[email-masked]>
> >>>>> wrote:
> >>>>>>> the Bridge environments they had to add the capability to
their
> >>>>>> products
> >>>>>>>> I'm not convinced that we need more specified ways to
> calculate
> >>>> SKI
> >>>>>>> and
> >>>>>>>> AKI.
> >>>>>>>> Acrobat reader is one example of an application which,
despite
> >>>> what
> >>>>>>>> give you the choice to select SKI algorithm, neither allows
> you
> >>> to
> >>>>>> set
> >>>>>>>> an

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 24 Jun 2010 11:53:12 -0400

Peter,

We are talking about certificate request from other CAs.

Also, without the ability for a CA to honor the request, how would we
have interoperability.  I do not think a single calculation method is
the answer.

> From: Peter Gutmann [mailto:[email-masked]]
> Sent: Thursday, June 24, 2010 12:33 AM
> To: [email-masked]; Santosh Chokhani; [email-masked];
> [email-masked]
> specifically don't
far

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 24 Jun 2010 11:53:17 -0400

Tim,

If you authenticated based on a KID match or use a KID as an
authorization check, you deserve to be compromised.  KID is solely a
path development and validation performance enhancer and not a security
attribute of a certificate.

> From: Miller, Timothy J. [mailto:[email-masked]]
> Sent: Thursday, June 24, 2010 10:20 AM
> To: 'Peter Gutmann'; [email-masked]; Santosh Chokhani; stefan@aaa-
> sec.com; [email-masked]
> Subject: RE: [pkix] Possible new work item: additional methods
> IMHO the problem is KID is misunderstood.  I've seen implementations
> that *presume* that a KID is globally unique (hash-derived) rather
than
> unique to the issuer, and so don't make the additional path check that
> would be necessary to catch shenanigans.  While global uniqueness is
> practically true for hash-derived KIDs, because non-hash-derived KIDs
> are allowed it's not a safe assumption to make.  (Note that a key
> generator can of course submit the same key to multiple CAs and get
> back the same SKID in each cert, but this isn't the same problem.)
> 
> By itself, this at least deserves a security note in sec 8.  IMHO, CAs
> should be instructed to create their own EE SKIDs in all cases, unless
> there are specific requirements for particular SKIDs to be used for
> interoperability purposes.  RPs should be instructed to not rely on
> global uniqueness of a KID unless they check to make sure that it's
> actually a hash-derived KID by calculating the hash itself.  This
> latter case would be helped by having a KID syntax extension so the RP
> knows which hash algorithm to use.
> 
> -- Tim
> 
>

---

From: "Miller, Timothy J." <[email-masked]>
Date: Thu, 24 Jun 2010 12:22:11 -0400

>attribute of a certificate.

That may be the WG's intent, but IMHO the text isn't clear on the point.  That's why I said it deserves a security note.

-- Tim

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 24 Jun 2010 18:30:58 +0200

> signatures that can be verified using the public key in the CA

Sorry Carl,

Such certificate would be valid in many situations but has no particular
utility that I know of?

That does not change the fact that the CA is the one to decide. E.g. if two
different requested certificates has the same requested SKI, it must decide
what to do.

Ideally it should be evident what algorithm that has been involved when
generating an AKI. The SKI is more or less redundant. Knowing the algorithm
of the AKI would make it a viable tool to aid path discovery by generating
SKIs on the fly (using the identified algorithm) for all CA certificate
candidates.

Of course this is only possible for transformation algorithms and not for
things like sequence numbers.

But I guess this is too late...

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 24 Jun 2010 18:33:27 +0200

Tim,

I'm not sure I understand what text that is unclear.

/Stefan

On 10-06-24 6:22 PM, "Miller, Timothy J." <[email-masked]> wrote:

> That may be the WG's intent, but IMHO the text isn't clear on the point.
> That's why I said it deserves a security note.
> 
> -- Tim
> 
>

---

From: "Carl Wallace" <[email-masked]>
Date: Thu, 24 Jun 2010 12:48:33 -0400

> Such certificate would be valid in many situations but has no

That the certificate is valid is not in question.  The discussion is
about values of the SKID extension with several folks appearing to
advocate for the usage of SKID values that do not match the AKID
included in certificate generated by the CA requesting a given SKID.
I'm trying to understand the use of these values that result in
mismatched KIDs.  
 
> That does not change the fact that the CA is the one to decide. E.g.
if
> two

Omitting the SKID might be a better approach if the requested SKID is
too distasteful and facilitating path discovery is not a concern.

Behalf
> >> I agree with both Tim and Peter that it may be problematic to
> blindly
> >> accept
> >> Primary because it requires special caution for the CA to ensure
> that
> >> the
> >>> purposes.  RPs should be instructed to not rely on global
> uniqueness
> >> of a KID
> >>> unless they check to make sure that it's actually a hash-derived
> KID
> >> by
for

---

From: Michael StJohns <[email-masked]>
Date: Thu, 24 Jun 2010 14:31:24 -0400

>granted SKI is unique among all issued certificates.

Umm...

I think that's wrong.    The SKI differentiates among all keys for a specific SubjectName, and need not be unique among all certs issued by a CA.  Simple counter example is a re-issued certificate where name, key, etc all stay the same, only the serial and validity dates (and of course signature) change.

I can use the same public key in multiple certificates issued by the same CA each with a different SubjectName (or SubAltName).  E.g. multiple email addresses.  And use the same SKI for all of these certs.

What you don't want is SKI(Subj A, Key 1) to equal SKI(Subj A, Key 2) because that confuses the path builder logic.

Mike

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 24 Jun 2010 16:53:56 -0400

I am not sure where Stefan want to go with this.  5280 already says in
4.2.1.2:

  "In conforming CA certificates, the value of the
   subject key identifier MUST be the value placed in the key identifier
   field of the authority key identifier extension (Section 4.2.1.1) of
   certificates issued by the subject of this certificate."

We need to make sure the above 5280 requirement is met in both
subordination and cross certified environments.

I also do not know why an RFC is needed.  5280 two methods could be
revised as follows:  

      (1) The keyIdentifier is composed of the hash of the
           value of the BIT STRING subjectPublicKey (excluding the tag,
           length, and number of unused bits).  The hash function is the
one selected by the CA (e.g., SHA-1, SHA 256, etc.).  If the hash
function output is greater than 160 bits, all the bits or 160 least
significant bits may be used.

      (2) The keyIdentifier is composed of a four-bit type field with
           the value 0100 followed by 60 least significant bits of the
hash of the value of the BIT STRING
           subjectPublicKey (excluding the tag, length, and number of
           unused bits).  The hash function is the one selected by the
CA (e.g., SHA-1, SHA 256, etc.).

> From: Michael StJohns [mailto:[email-masked]]
> Sent: Thursday, June 24, 2010 2:31 PM
> To: Stefan Santesson; Miller, Timothy J.; 'Peter Gutmann';
> [email-masked]; Santosh Chokhani; [email-masked]
> I think that's wrong.    The SKI differentiates among all keys for a
> specific SubjectName, and need not be unique among all certs issued by
> a CA.  Simple counter example is a re-issued certificate where name,
> key, etc all stay the same, only the serial and validity dates (and of
> course signature) change.
> 
> I can use the same public key in multiple certificates issued by the
> same CA each with a different SubjectName (or SubAltName).  E.g.
> multiple email addresses.  And use the same SKI for all of these
certs.
> 
> What you don't want is SKI(Subj A, Key 1) to equal SKI(Subj A, Key 2)
> because that confuses the path builder logic.
> 
> Mike
> 
> 
>

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 24 Jun 2010 23:22:48 +0200

>    certificates issued by the subject of this certificate."

I absolutely agree with this. I really don't want to promote anything else,

> subordination and cross certified environments.

I also absolutely agree with this.
The only question I wanted to ask this group is whether more defined methods
to calculate AKI/SKI is an advantage or disadvantage to achieve this goal.
I'm now leaning towards that it does not really matter.

---

From: Tom Gindin <[email-masked]>
Date: Thu, 24 Jun 2010 22:24:43 -0400

Perhaps I'm reading the standard poorly, but I find it strange 
that there's literally no reference to subject Key ID in section 6 of RFC 
5280.  Shouldn't there be KID references in section 6 somewhere, whether 
the top subsection or 6.2?  Putting them in 6.1.4 has some drawbacks.  In 
the top section, it could be made advisory (e.g., "if a path is built by 
software which has multiple certificates with the same subject available, 
and the prior certificate in the path has the Authority Key Identifier 
extension present, it should usually be assumed that those certificates 
whose SubjectKeyIdentifier extensions match the keyIdentifier field of the 
Authority Key Identifier should be used in preference to those whose 
SubjectKeyIdentifier extensions do not match").
        Isn't the proper note for section 8 something like "A given SKID 
is expected to refer to a key unique among those certified for its 
subject, but Key Identifiers are not guaranteed to be unique for any wider 
scope of keys, and thus RP software should never consider that a 
certificate whose SKID matches the AKID of another certificate (B) is 
intended as the issuing certificate of B unless the subject of the 
certificate containing the SKID also matches the issuer name corresponding 
to the AKID"?

                Tom Gindin

From:
"Miller, Timothy J." <[email-masked]>
To:
"'Santosh Chokhani'" <[email-masked]>, Peter Gutmann 
<[email-masked]>, "[email-masked]" <[email-masked]>, 
"[email-masked]" <[email-masked]>, "[email-masked]" 
<[email-masked]>
Date:
06/24/2010 12:22 PM
Subject:
Re: [pkix] Possible new work item: additional methods forgenerating key 
identifiers
Sent by:
[email-masked]

-- Tim

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 25 Jun 2010 18:40:43 +1200

"Carl Wallace" <[email-masked]> writes:

>Please explain the utility of a SKID extension in a CA certificate where the
>SKID does not match the AKID extension included in certificates with
>signatures that can be verified using the public key in the CA certificate.

I don't know about the utility but I can confirm the *reality* of all manner
of certs where the keyIDs don't match, including ones where the CA memcpy()s
the sKID to the aKID, ones where the keyID has zero length, ones where aKID ==
sKID, ones where they're set to random values ("no-one looks at those anyway
so we can set them to whatever we want", according to the CA), ones where
they're set to a constant value, and so on.  So in practice the keyIDs are, at
best, a vague hint in the right direction, but shouldn't be relied on (unless
you're Adobe, but their PKI stuff is so broken in general that (mis-)use of
the keyID is the least of your worries).

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 25 Jun 2010 18:44:15 +1200

"Santosh Chokhani" <[email-masked]> writes:

>Also, without the ability for a CA to honor the request, how would we have
>interoperability.

Well, managed it so far...

(This isn't just meant as the usual wisecrack, it's also a serious
observation.  I'm sure you can construct special-case scenarios where you need
to allow EE-defined keyIDs if you try really hard, but by and large everyone
seems to be getting by just fine without it).

Peter.

---

From: Stephen Kent <[email-masked]>
Date: Fri, 25 Jun 2010 03:50:21 -0400

>granted SKI is unique among all issued certificates.

The SKI is designed to differentiate among multiple certs issued to 
the same entity, by different issuers, and containing  different 
keys.  There is not a uniqueness requirement imposed by 5280. Only if 
a PKI profile mandates a specific KI generation method  (as does the 
RPKI) might there be some reasonable assumption of uniqueness.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 25 Jun 2010 04:01:47 -0400

At 10:20 AM -0400 6/24/10, Miller, Timothy J. wrote:
>than unique to the issuer, and so don't make the additional path 
>check that would be necessary to catch shenanigans.  While global 
>uniqueness is practically true for hash-derived KIDs, because 
>non-hash-derived KIDs are allowed it's not a safe assumption to 
>make.  (Note that a key generator can of course submit the same key 
>to multiple CAs and get back the same SKID in each cert, but this 
>isn't the same problem.)

a presumption of this sort, absent a mandate in a CP or in a 
PKI-enabled application context, is a foolish assumption :-).

>hash-derived SKID in your cert, but from a different PKI.  I can 
>then potentially authenticate as you to a system that trusts both 
>PKIs but erroneously understands the current scope of SKID.

It would be inappropriate for PKIX to prohibit a behavior to protect 
folks from bad, local design decisions.

>By itself, this at least deserves a security note in sec 8.  IMHO, 
>CAs should be instructed to create their own EE SKIDs in all cases, 
>unless there are specific requirements for particular SKIDs to be 
>used for interoperability purposes.  RPs should be instructed to not 
>rely on global uniqueness of a KID unless they check to make sure 
>that it's actually a hash-derived KID by calculating the hash 
>itself.  This latter case would be helped by having a KID syntax 
>extension so the RP knows which hash algorithm to use.

I think it is fair to remind CAs that they SHOULD honor KID requests 
in cross-certification contexts, to ensure interoperability. Based on 
what other have said, it also may help to remind folks that KID are 
not guaranteed to be unique, in general.  Finally. as one expect fro 
the co-author of the subject I-D, I think there is merit in having an 
optional,  explicit declaration of the means used to compute the KID, 
to help RPs.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 25 Jun 2010 03:54:22 -0400

>the keyID is the least of your worries).

Well, the SKI/AKI fields are not critical extensions, and are used 
only for path building (unless otherwise mandated by a PKI CP). So, 
if the AKI/SKi don't match it just means that the heuristic these 
fields are intended to support will not work, and the RP will have to 
fall back to trying each candidate cert to see which one works. 
Unfortunate, not consistent with 5280, but also should not  be fatal.

Steve

---

From: "Carl Wallace" <[email-masked]>
Date: Fri, 25 Jun 2010 06:34:49 -0400

> the keyID is the least of your worries).

That's all fine and I agree with you that these fields are simply hints
and with Steve that having a mismatch is not a fatal problem.  There's
still no particularly good reason for this group to advocate for CAs
using values that create mismatched SKID/AKID extensions.  The right of
the CA to choose the value is less compelling than the useful life of a
matched SKID/AKID pair.

---

From: "Santosh Chokhani" <[email-masked]>
Date: Fri, 25 Jun 2010 07:41:58 -0400

It is both a bad idea and 5280 non-compliant as the text from 5280 I
posted illustrates.

> Sent: Friday, June 25, 2010 2:44 AM
> To: [email-masked]; [email-masked]; Santosh Chokhani;
> [email-masked]; [email-masked]
> have

---

From: Stephen Kent <[email-masked]>
Date: Fri, 25 Jun 2010 07:45:59 -0400

At 6:34 AM -0400 6/25/10, Carl Wallace wrote:
>...

+1

Steve

---

From: "Santosh Chokhani" <[email-masked]>
Date: Fri, 25 Jun 2010 07:56:17 -0400

Tom See below

> Sent: Thursday, June 24, 2010 10:25 PM
> To: Miller, Timothy J.
> Cc: Peter Gutmann; [email-masked]; [email-masked]; Santosh
> Chokhani; [email-masked]; [email-masked]
5280 does not address certificate path construction.  Certificate path
construction is addressed by an informational RFC written by Matt Cooper
et. al.  5280 could reference that RFC and provide some general
background as opposed to KID stuff only.

> certificate containing the SKID also matches the issuer name
Name chaining and signature chaining is already part of path validation
logic in Section 6.  Also note that KID need not be unique at all for
any scope.  It helps the performance when they are unique for a given
subject DN scope or for wider scope.  Also, if you added something about
KID in section 8, you may need to address security ramifications of
several fields.  Sections  4 and 5 already explain fields and their
purposes adequately.

---

From: "Miller, Timothy J." <[email-masked]>
Date: Fri, 25 Jun 2010 09:00:14 -0400

OK, that's three variant interpretations.  Can I get a fourth?  :)

-- Tim

>Sent: Thursday, June 24, 2010 1:31 PM
>[email-masked]; [email-masked]; [email-masked]
>specific SubjectName, and need not be unique among all certs issued by a
>CA.  Simple counter example is a re-issued certificate where name, key,
>etc all stay the same, only the serial and validity dates (and of course
>signature) change.
>
>multiple email addresses.  And use the same SKI for all of these certs.
>

---

From: "Miller, Timothy J." <[email-masked]>
Date: Fri, 25 Jun 2010 09:10:35 -0400

>CA (e.g., SHA-1, SHA 256, etc.).

Can we expand on the type field and use it to signal the hash function used?  If I have this I can verify the SKID without guessing, and that would open up more uses for SKID than just path building.

-- Tim

---

From: "Miller, Timothy J." <[email-masked]>
Date: Fri, 25 Jun 2010 09:20:17 -0400

>only for path building (unless otherwise mandated by a PKI CP).

ITYM "intended only for path building."  Application programmers apparently had different ideas.

I'm not convinced that those ideas are necessarily bad ones, if reasonable accommodations can be made for the practice.

-- Tim

---

From: "Miller, Timothy J." <[email-masked]>
Date: Fri, 25 Jun 2010 09:25:37 -0400

>optional,  explicit declaration of the means used to compute the KID,

I (obviously?) concur.

-- T

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 26 Jun 2010 01:33:03 +1200

>OK, that's three variant interpretations.  Can I get a fourth?  :)

I think the meta-result from this is that you can expect pretty much anything 
in an sKID and aKID, meaning that your code shouldn't rely on them (although 
it can use them as an optional disambiguating hint).  My code has a bunch of 
condition variables that control how I chain, the general scheme is to chain 
by DN and then if that fails, fall back to the keyID.  In recent releases I've 
been disabling keyID chaining to simplify the code, and am waiting to see if I 
get any user complaints about this (none so far).

Peter.

---

From: "Kemp, David P." <[email-masked]>
Date: Fri, 25 Jun 2010 10:34:50 -0400

At 6:34 AM -0400 6/25/10, Carl Wallace wrote:

> +1 (Steve)

+1 (Dave)

From: Stephen Kent
> in cross-certification contexts, to ensure interoperability.
> Based on what other have said, it also may help to remind folks
> that KID are not guaranteed to be unique, in general.  Finally.
> as one expect fro the co-author of the subject I-D, I think there
> is merit in having an optional,  explicit declaration of the means
> used to compute the KID, to help RPs.

CAs SHOULD honor SKID requests.  CAs MUST NOT honor AKID requests, they
MUST ensure that the AKID in a certificate being signed matches the SKID
of the CA's cert-signing certificate.  This, Santosh points out, is
already required by (the very poorly-worded) 5280 section 4.2.1.2.

An optional, explicit declaration of the means used to compute the KID
cannot be created without defining new extension(s) with new OIDs. The
current AKI/SKI extensions do not preclude any pattern of bits, so a
randomly-generated or deliberately-chosen KID value could erroneously
match whatever "method" indicator might be imbedded in the current
extensions.  If the semantics of an extension is changed in an
incompatible manner (such as imposing content restrictions where none
previously existed), a new extension OID must be assigned.

An I-D (such as the current Turner-Kent draft) that adds four methods to
the two existing SUGGESTED (not required) methods is of no help to RPs
because an RP cannot reliably do anything with the information.  If it
independently tries to compute or validate a KID from a public key using
the indicated method, the computation/validation will fail if the
indicated method was not used by the creator of the KID.

Dave

---

From: Stephen Kent <[email-masked]>
Date: Fri, 25 Jun 2010 12:38:47 -0400

>apparently had different ideas.

yes, but they were in error :-).

>I'm not convinced that those ideas are necessarily bad ones, if 
>reasonable accommodations can be made for the practice.

depends on what sort of accommodation you are looking for.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 25 Jun 2010 12:42:11 -0400

>already required by (the very poorly-worded) 5280 section 4.2.1.2.

agreed.

>previously existed), a new extension OID must be assigned.

agreed.  I prefer a new, optional extension, that allows one to 
signal the method used to generate the SKI.

>indicated method was not used by the creator of the KID.

I suggested a refinement of the text, based on the discussion we have 
had on the list (and having not coordinated by suggestion with my 
co-author :-).)

Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 25 Jun 2010 12:37:37 -0400

At 9:10 AM -0400 6/25/10, Miller, Timothy J. wrote:
>Can we expand on the type field and use it to signal the hash 
>function used?  If I have this I can verify the SKID without 
>guessing, and that would open up more uses for SKID than just path 
>building.
>
>-- Tim
My suggestion in a msg earlier this week was to create a new 
extension that signals what hash function was used to generate the 
SKI in the cert.  We could expand that to include an indication of 
other, non-hash SKI generation methods too, if folks want.

Steve