Subject: Straw poll for Algorithm Identifiers in Subject Public Key Info.

From: Stefan Santesson <[email-masked]>
Date: Wed, 6 Dec 2006 14:47:44 +0000

I'm requesting a straw poll on the future direction of specifying algorithm identifiers in the Subject Public Key Info field in X.509 certificates.

Background
----------
The draft http://www.ietf.org/internet-drafts/draft-ietf-pkix-ecc-pkalgs-03.txt defines algorithm OIDs for ECC to be included in the Subject Public Key Info field. One of these OIDs (specified by ANSI X9.62/2005) allow a list of supported algorithmic modes to be specified with the parameters of the public key.

Concerns about this approach has been raised on the list, primary because it presents a new approach for the same problem as adapted by RFC 4055, where new algorithm OIDs have been defined for some modes of RSA. Another concern raised is that the deployed products today are not deigned to handle usage restrictions provided in the Subject Public Key Info field, and doing so would require updates of crypto library API's in a way that would severely harm deployment and interoperability. Finally, it was exposed that the structured OID from the ECC algs draft is limited to the use of the public key with SHA-1, which is a quite unacceptable restriction.

The defenders of the ECC algorithm draft has pointed at the fact that the algorithm OIDs of this draft is defined by ANSI X9.62/2005 and should be valid also for PKIX, and the fact that problems related to mode restrictions in the subject public key info field, also apply to RFC 4055.

Recently a design team was formed under the leadership of Tim Polk, which provided a report and a proposed way forward, presented at the PKIX meeting during the San Diego IETF in November 2006.
The slides from this presentation is available from:  http://www3.ietf.org/proceedings/06nov/slides/pkix-7.ppt

The design team concluded that both the approach of RFC 4055 and the approach of the current ECC algorithms draft are problematic. They also concluded that implementation of RFC 4055 is almost non-existent, except a few experimental environments. As a result, the design team  suggested a 3rd approach.

The proposal from the Design team
---------------------------------
The proposal from the design team is to revert back to the algorithm OIDs defined in RFC 3279, using a single OID for ECC, and to defer mode restrictions to a future certificate extension to be specified in a new PKIX draft.

In addition, Russ Housley has stated that the use of different approaches for RSA keys and EC keys is unacceptable to him.  Therefore, this straw poll assumes that RFC 4055 will also be revised to align with the Design Team recommendation.  That is, the new extension will be designed to cover the algorithms and modes listed in RFC 4055 as well as the EC algorithms and modes studied by the Design Team.

The straw poll
--------------
I would like to make a simple straw poll if this group can accept the proposal of the design team, with the amended task to also align RFC 4055 with this approach.

Please reply with a YES, or a NO.
Optionally provide a short motivation for your vote.

Thank you.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

---

From: Russ Housley <[email-masked]>
Date: Thu, 07 Dec 2006 09:38:16 -0500

As I said at the microphone in San Diego, I can support this approach 
if and only if the PKIX WG uses it for all public key types.  This 
means that 4055bis would need to begin now, and that the ECC document 
would be developed to use the same extension.

Russ

At 09:47 AM 12/6/2006, Stefan Santesson wrote:

>I'm requesting a straw poll on the future direction of specifying 
>algorithm identifiers in the Subject Public Key Info field in X.509 
>certificates.
>
>Background
>----------
>The draft 
>http://www.ietf.org/internet-drafts/draft-ietf-pkix-ecc-pkalgs-03.txt 
>  defines algorithm OIDs for ECC to be included in the Subject 
>Public Key Info field. One of these OIDs (specified by ANSI 
>X9.62/2005) allow a list of supported algorithmic modes to be 
>specified with the parameters of the public key.
>
>Concerns about this approach has been raised on the list, primary 
>because it presents a new approach for the same problem as adapted 
>by RFC 4055, where new algorithm OIDs have been defined for some 
>modes of RSA. Another concern raised is that the deployed products 
>today are not deigned to handle usage restrictions provided in the 
>Subject Public Key Info field, and doing so would require updates of 
>crypto library API's in a way that would severely harm deployment 
>and interoperability. Finally, it was exposed that the structured 
>OID from the ECC algs draft is limited to the use of the public key 
>with SHA-1, which is a quite unacceptable restriction.
>
>The defenders of the ECC algorithm draft has pointed at the fact 
>that the algorithm OIDs of this draft is defined by ANSI X9.62/2005 
>and should be valid also for PKIX, and the fact that problems 
>related to mode restrictions in the subject public key info field, 
>also apply to RFC 4055.
>
>Recently a design team was formed under the leadership of Tim Polk, 
>which provided a report and a proposed way forward, presented at the 
>PKIX meeting during the San Diego IETF in November 2006.
>The slides from this presentation is available 
>from:  http://www3.ietf.org/proceedings/06nov/slides/pkix-7.ppt
>
>The design team concluded that both the approach of RFC 4055 and the 
>approach of the current ECC algorithms draft are problematic. They 
>also concluded that implementation of RFC 4055 is almost 
>non-existent, except a few experimental environments. As a result, 
>the design team  suggested a 3rd approach.
>
>
>The proposal from the design team is to revert back to the algorithm 
>OIDs defined in RFC 3279, using a single OID for ECC, and to defer 
>mode restrictions to a future certificate extension to be specified 
>in a new PKIX draft.
>
>In addition, Russ Housley has stated that the use of different 
>approaches for RSA keys and EC keys is unacceptable to 
>him.  Therefore, this straw poll assumes that RFC 4055 will also be 
>revised to align with the Design Team recommendation.  That is, the 
>new extension will be designed to cover the algorithms and modes 
>listed in RFC 4055 as well as the EC algorithms and modes studied by 
>the Design Team.
>
>
>The straw poll
>--------------
>I would like to make a simple straw poll if this group can accept 
>the proposal of the design team, with the amended task to also align 
>RFC 4055 with this approach.
>

---

From: "Kemp, David P." <[email-masked]>
Date: Thu, 7 Dec 2006 11:48:02 -0500

A question for the authors of the recommendation:

The certificate extension proposal contains the following description:

  o Define an optionally critical certificate extension
     - Sequence of Algorithm Identifiers, as in X9.62 parameters
     - Reuse X9 algorithm Identifiers
         . Deprecating "with recommended"? 
     - Add three "family" OIDs (ECDSA, ECDH, ECMQV)

The usual practice for signature public key certificates is to
use a family OID (dsa, rsa, ecdsa) in SubjectPublicKeyInfo
and to use a hash-specific OID (rsa-with-md5, rsa-with-sha1)
as the algorithm of a particular signature (including the
signature over the certificate itself).

For key establishment certificates, is it the authors' intent
to use kdf-specific algorithm ids (dhSinglePass-stdDH-sha1kdf,
mqvFull-sha1kdf, etc) in the proposed extension, or to say
that only family OIDs may be used in the extension and
the kdf-specific OIDs are defined solely for the convenience
of protocols that consume ECDH or ECMQV public key certificates?

In either case I believe PKIX should also define "sub-family"
OIDs that do not specify a KDF (e.g. dhSinglePass-stdDH,
mqvFull, etc).  A sub-family OID could be used in a critical
extension to specify an algorithm mode without forcing the
certificate to constrain the KDF that could be used.

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Stefan Santesson

The straw poll
--------------
I would like to make a simple straw poll if this group can accept the
proposal of the design team, with the amended task to also align RFC
4055 with this approach.

---

From: Tolga Acar <[email-masked]>
Date: Thu, 7 Dec 2006 11:15:21 -0800

I am not in favor of specifying KDFs in a certificate. Such an extension should limit itself to the immediate algorithm usage of the key pair, and not to further usages of the key pair.
In one extreme, specifying a KDF in such a extension might also suggest a list of symmetric algorithms the derived key can be used with. As I see it, that belongs to a protocol, and not to the certificate.

- Tolga

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kemp, David P.
Sent: Thursday, December 07, 2006 8:48 AM
To: [email-masked]
Subject: RE: Straw poll for Algorithm Identifiers in Subject Public Key Info.

Dave

-----Original Message-----

The straw poll
--------------

---

From: "Kemp, David P." <[email-masked]>
Date: Thu, 7 Dec 2006 15:37:27 -0500

Poll response: NO as proposed, but a simple change would get YES

Rationale:  Security and Simplicity are my most important design
criteria.  Other listed criteria  are also important, but design
team missed the mark on Ease of Deployment.

1) For the most common case of interest (a certificate that
supports ECDH but not MQV, or vice versa), simplicity is paramount.
A combination of 3279 ecPublicKey OID plus key usage extension
cannot express this case.  Using a family OID (ECDSA, ECDH, ECMQV)
in subjectPublicKeyInfo is the simplest way to express this
common case.

2) For ease of deployment, agree that a new OID is like an
unrecognized critical extension.  But there is a major difference
in migration impact between developing crypto libraries to support
a new algorithm technology (e.g. ecc) and developing the code
to parse a new OID.  The fact that critical mass is finally
emerging on 3279 OID/parameters (after n years) is related to
ecc processing support, not OID parsing.  Given an application
capable of handling 3279 signing and encryption, modifying
that application to parse 3 family OIDs is a trivial task.
Communities that would choose the proposed non-critical extension
would get the same effect with the 3279 OID, whereas communities
that would make the proposed extension critical would get the same
effect using family OIDs without the extension.  It is easier
to modify an application to recognize family OIDs than to
make it capable of parsing and taking hints from a new
non-critical extension.

Modified Proposal:
  * Retain 3279 OID/parameters in subjectPublicKeyInfo (as is)
  * Specify certificate extension as SHOULD implement
    for CAs and clients (as is, to accommodate applications
    with complex requirements like mode OID lists)
  * Specify 3 family OIDs/3279 parameters as SHOULD implement
    for CAs and clients in subjectPublicKeyInfo (*** NEW ***)

I would change response from NO to YES if the proposal included
this new recommendation.

Dave

-----Original Message-----

The straw poll
--------------

---

From: Tolga Acar <[email-masked]>
Date: Thu, 7 Dec 2006 15:05:54 -0800

Inline.
> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Kemp, David P.
> Sent: Thursday, December 07, 2006 12:37 PM
> To: [email-masked]
> Subject: Qualified NO (was RE: Straw poll for Algorithm Identifiers in
> Subject Public Key Info.)

<snip>

> that application to parse 3 family OIDs is a trivial task.

Perhaps it is trivial to write the code to do that. Releasing and deploying that code is not a trivial task.

> make it capable of parsing and taking hints from a new

The difference between the two in terms of coding work is not that great. It is not necessarily the parsing effort that takes the big chunk of the time; it is the entire release & deployment cycle. And in either case, there isn't much difference between the two. I can see that deployment in a rather smallish and closed/semi-closed networks would not present as many challenges. Nonetheless, in an environment where there are mixed bags of capabilities spread across your clients, deployment is a big deal. You can't roll out the SPKI changes till the majority of your clients can process that information, or they are simply broken.

>     for CAs and clients in subjectPublicKeyInfo (*** NEW ***)

In principal, that sounds fine. Nit-picking: why SHOULD instead of MAY? Perhaps, it doesn't make much difference in the end.

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 8 Dec 2006 11:36:37 +0000

I missed to set a deadline for this straw poll. Please give your vote no later than next Wednesday (December 13)

Also, unfortunately the link to the design team presentation slides was wrong/old.
The correct URL is: http://www3.ietf.org/proceedings/06nov/slides/pkix-7/pkix-7.ppt

Stefan Santesson
Senior Program Manager

> [email-masked]] On Behalf Of Stefan Santesson
> Sent: den 6 december 2006 15:48
> To: [email-masked]
> Subject: Straw poll for Algorithm Identifiers in Subject Public Key
> Info.
>
>
> The draft http://www.ietf.org/internet-drafts/draft-ietf-pkix-ecc-
> pkalgs-03.txt defines algorithm OIDs for ECC to be included in the
> Subject Public Key Info field. One of these OIDs (specified by ANSI
> X9.62/2005) allow a list of supported algorithmic modes to be specified
> with the parameters of the public key.
>
> because it presents a new approach for the same problem as adapted by
> RFC 4055, where new algorithm OIDs have been defined for some modes of
> RSA. Another concern raised is that the deployed products today are not
> deigned to handle usage restrictions provided in the Subject Public Key
> Info field, and doing so would require updates of crypto library API's
> in a way that would severely harm deployment and interoperability.
> Finally, it was exposed that the structured OID from the ECC algs draft
> is limited to the use of the public key with SHA-1, which is a quite
> unacceptable restriction.
>
> The defenders of the ECC algorithm draft has pointed at the fact that
> the algorithm OIDs of this draft is defined by ANSI X9.62/2005 and
> should be valid also for PKIX, and the fact that problems related to
> mode restrictions in the subject public key info field, also apply to
> RFC 4055.
>
> The slides from this presentation is available from:
> http://www3.ietf.org/proceedings/06nov/slides/pkix-7.ppt
>
> approach of the current ECC algorithms draft are problematic. They also
> concluded that implementation of RFC 4055 is almost non-existent,
> except a few experimental environments. As a result, the design team
> suggested a 3rd approach.
>
>
> OIDs defined in RFC 3279, using a single OID for ECC, and to defer mode
> restrictions to a future certificate extension to be specified in a new
> PKIX draft.
>
> approaches for RSA keys and EC keys is unacceptable to him.  Therefore,
> this straw poll assumes that RFC 4055 will also be revised to align
> with the Design Team recommendation.  That is, the new extension will
> be designed to cover the algorithms and modes listed in RFC 4055 as
> well as the EC algorithms and modes studied by the Design Team.
>
>
> The straw poll
> --------------

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 8 Dec 2006 12:21:26 +0000

Taking pkix chair hat off, I vote YES to the design team proposal.

Stefan Santesson
Senior Program Manager

> From: Stefan Santesson
> Sent: den 8 december 2006 12:37
> To: Stefan Santesson; [email-masked]
> I missed to set a deadline for this straw poll. Please give your vote
> no later than next Wednesday (December 13)
>
> also
> mode

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 8 Dec 2006 12:26:58 +0000

I appreciate the design discussion, but would like to ask you to keep it clear from the straw poll thread.
Possibly it would be good to wait with the detailed design discussion until we have a decision on direction from the straw poll.

Stefan Santesson
Senior Program Manager

> [email-masked]] On Behalf Of Tolga Acar
> Sent: den 7 december 2006 20:15
> To: Kemp, David P.; [email-masked]
> I am not in favor of specifying KDFs in a certificate. Such an
> extension should limit itself to the immediate algorithm usage of the
> key pair, and not to further usages of the key pair.
> In one extreme, specifying a KDF in such a extension might also suggest
> a list of symmetric algorithms the derived key can be used with. As I
> see it, that belongs to a protocol, and not to the certificate.
>
> - Tolga
>

---

From: "Kemp, David P." <[email-masked]>
Date: Fri, 8 Dec 2006 10:09:12 -0500

Tolga,

Thanks for the feedback.  I didn't intend to minimize the
logistics involved in the product development / testing /
release / deployment cycle in an absolute sense.  The intent
was to categorize the delta between deploying a fully-tested
new cryptographic engine algorithm including application
support and deploying a fully-tested update to the certificate
parser.

If there are ecc applications today that handle the 3279 OID
and have configuration or negotiation ability to establish the
algorithm/parameters/mode/kdf required to operate at all,
then a new development/release cycle is required to put any
of that algorithm/parameters/mode/kdf information into a
certificate, regardless of the approach chosen.  So again, my
intent is to discuss deltas.  We can assume that the delta between
implementing family OIDs in subjectPublicKeyInfo and implementing
the full new extension is zero (doing just the family OIDs is
certainly not *more* difficult).  The design goal I'm concerned
with is simplicity - certificates are definitely smaller
without the extension, and it is arguably easier to implement
algorithm-specific public key OIDs than the full functionality
of a list of allowed modes using the extension.

Regarding SHOULD vs MAY, I'd like to see the single OID and
the family OIDs on an equal footing with regard to the standard.

I'd suggest that CA products and consuming applications SHOULD
support both the 3279 OID and family OIDs in subjectPublicKeyInfo,
and SHOULD support the extension.

I'd suggest that operating CAs MAY* label ecc public keys with either
the 3279 OID or an algorithm-specific OID, and in either case the
CA MAY use the extension when more fine-grained control (e.g.
a list of more than one but not all algorithms/modes) is desired.

Dave

* logically speaking, a CA MUST do one or the other if it is
issuing an ecc certificate, but the standard is neutral on
which to use.

-----Original Message-----
From: Tolga Acar [mailto:[email-masked]] 
> [dpk] Given an application

Perhaps it is trivial to write the code to do that. Releasing and
deploying that code is not a trivial task.

> [dpk] Modified Proposal:

In principal, that sounds fine. Nit-picking: why SHOULD instead of MAY?
Perhaps, it doesn't make much difference in the end.

---

From: Tolga Acar <[email-masked]>
Date: Fri, 8 Dec 2006 09:29:05 -0800

I vote YES to the design team proposal.

Disclosure: I am part of the design team.

- Tolga

-----Original Message-----
From: Stefan Santesson
Sent: Friday, December 08, 2006 4:27 AM
To: Tolga Acar; Kemp, David P.; [email-masked]
Subject: Design discussion for Algorithm mode restriction extension

Stefan Santesson
Senior Program Manager

---

From: "Kemp, David P." <[email-masked]>
Date: Fri, 8 Dec 2006 14:38:49 -0500

Then I vote YES on the design team proposal since it provides
a basis for discussion, and will discuss modifications later.

Dave

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]] 
Sent: Friday, December 08, 2006 7:27 AM
To: Tolga Acar; Kemp, David P.; [email-masked]
Subject: Design discussion for Algorithm mode restriction extension

I appreciate the design discussion, but would like to ask you to keep it
clear from the straw poll thread.
Possibly it would be good to wait with the detailed design discussion
until we have a decision on direction from the straw poll.

Stefan Santesson
Senior Program Manager

---

From: "Michael Myers" <[email-masked]>
Date: Fri, 8 Dec 2006 11:30:35 -0800

Yes.

Mike

> From: Stefan Santesson
> Sent: Wednesday, December 06, 2006 6:48 AM
>
> . . .
>
> The proposal from the design team is to revert back to the
> algorithm OIDs defined in RFC 3279, using a single OID for
> ECC, and to defer mode restrictions to a future certificate
> extension to be specified in a new PKIX draft.

---

From: Nils Larsch <[email-masked]>
Date: Tue, 12 Dec 2006 08:43:09 +0100

Kemp, David P. wrote:
...
>     for CAs and clients in subjectPublicKeyInfo (*** NEW ***)

your proposal would require me to change the parsing of the
subjectPublicKeyInfo and additionally implement support for a new
extension giving more detailed restriction on the key usage. I
think it would be better to have only one place, an extension
or the subjectPublicKeyInfo structure, for this kind of information.

Cheers,
Nils

---

From: Nils Larsch <[email-masked]>
Date: Wed, 13 Dec 2006 09:17:15 +0100

Stefan Santesson wrote:
...
> The straw poll

YES, implementing different ways to restrict the key usage
for different key types (RFC 4055 vs. X9.62) is certainly
less than optimal and should be avoided. Putting such restrictions
in a new extension might be the most flexible way to do this.

Cheers,
Nils

---

From: "Dieter Bratko" <[email-masked]>
Date: Wed, 13 Dec 2006 15:36:25 +0100

> with the amended task to also align RFC 4055 with this approach.
We vote NO to change RFC 4055

because:

> implementation of RFC 4055 is almost non-existent, except a few
> experimental environments
That is not really true. For instance, RFC4055-style RSAES-OAEP keys (OID 
1.2.840.113549.1.1.7, parameters included) are used in TC endorsement 
credentials in millions of TPM chips that are already shipped onto the 
market (you may look at the Infineon Endorsement certificates for an 
example: http://www.infineon.com/TPM --> certificates --> TPM 1.2 EK 
certificate).
We have already implemented RFC 4055 (on user requests) for our Java crypto 
toolkit and will have to continue to support it in any case. Since RFC 4055 
includes the parameters into the key, it was possible to implement it 
without almost any API changes. Of course, internal changes were necessary 
to support the new key types, however, for implementation and usage, it is 
simpler and more straightforward to have the parameters inside the key than 
to maintain them separatly .
With the extension based approach, it would be necessary to distinguish 
between keys from certificates without the new extension, keys from 
certificates with the new extension which could be critical or not critical, 
and could contain parameters or not. We must check if validation must be 
done, must not be done or may have to be done. Maybe applications that are 
already using RFC4055 keys would put them into certificates with the new 
extension and finally we might have all possible combinations of keys
with/without parameters and certificates with/without critical/non critical 
extension with/without parameters which would not interoperate anymore.

Before a specification becomes a standard RFC it has to go through a certain 
development cycle where it is discussed, reviewed and -- if necessary --  
revised serveral times. If you now start to withdraw and incompatibly change 
standard RFCs (wihout the absolute necessity to, for instance, fix some 
critical security hole), how in future shall we know when it is time to rely 
on a standard RFC to implement and use it (or built other standards upon 
it)? Should anyone wait until the standard maybe used by someone other? This
practice would not be suitable for increasing usage of and putting trust 
into future PKIX standards. There are not that big advantages in the 
extension based approach to therefore change an existing standard.

Regards,
Dieter

----- Original Message ----- 
From: Stefan Santesson
To: Stefan Santesson ; [email-masked]
Sent: Friday, December 08, 2006 12:36 PM
Subject: RE: Straw poll for Algorithm Identifiers in Subject Public Key
Info.

I missed to set a deadline for this straw poll. Please give your vote no
later than next Wednesday (December 13)

Also, unfortunately the link to the design team presentation slides was
wrong/old.
The correct URL is:
http://www3.ietf.org/proceedings/06nov/slides/pkix-7/pkix-7.ppt

Stefan Santesson
Senior Program Manager

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 14 Dec 2006 10:13:59 +1100

The TPM 1.2 EK certificate is a bad example -- as it is invalid.  [http://www.infineon.com/upload/Document/tpm/EKCertificate.crt]
It uses UTF8String for the countryName in the issuer field and in the authorityKeyIdentifier extension.  The countryName MUST be a PrintableString (not a DirectoryString, which includes UTF8String as a choice).
And you have already shipped millions of these… yikes!

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dieter Bratko
Sent: Thursday, 14 December 2006 1:36 AM
To: pkix
Subject: Re: Straw poll for Algorithm Identifiers in Subject Public Key Info.

Regards,
Dieter

----- Original Message ----- 
From: Stefan Santesson
To: Stefan Santesson ; [email-masked]
Sent: Friday, December 08, 2006 12:36 PM
Subject: RE: Straw poll for Algorithm Identifiers in Subject Public Key
Info.

Stefan Santesson
Senior Program Manager

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 14 Dec 2006 10:36:40 +1100

Actually it is the TPM 1.1 EK certificate that incorrectly uses UTF8String for the countryName attribute.  The TPM 1.2 EK certificate uses PrintableString (for all the issuer name components, even those that could be UTF8String). [http://www.infineon.com/upload/Document/tpm/IFX%20TPM%20EK%20Cert%20.crt]

_____________________________________________
From: Manger, James H 
Sent: Thursday, 14 December 2006 10:14 AM

---

From: "Karl Scheibelhofer" <[email-masked]>
Date: Thu, 14 Dec 2006 14:52:13 +0100

the subject was "Algorithm Identifiers in Subject Public Key Info".
UTF8String and PrintableString is a different story. moreover, as on can
easily see, these certificates were issued by Infineon and not by IAIK -
Graz University of Technology.

anyway, it is evidence that there are not only a few experimental RFC 4055
implementations out there. it's been implemented and shipped in quantities
and this should not be downplayed. any manufacturer who implemented RFC 4055
and shipped products will have to support it for many years, no matter if
PKIX decides to deprecate it and try a different approach. for these
vendors, RFC 4055 is reality and there is no way back. another RFC that
obsoletes 4055 will be just another way to do similar (or the same) things,
and they will have to support them in addition in parallel. from this point
of view, it is too late to replace RFC 4055.

regards

  Karl

--

Karl Scheibelhofer, IAIK - Graz University of Technology
Inffeldgasse 16a, 8010 Graz, Austria
Fax: +43 316 873 5520
http://jce.iaik.tugraz.at

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Manger, James H
> Sent: Thursday, December 14, 2006 12:37 AM
> To: pkix
> Cc: Dieter Bratko
> Actually it is the TPM 1.1 EK certificate that incorrectly 
> uses UTF8String for the countryName attribute.  The TPM 1.2 
> EK certificate uses PrintableString (for all the issuer name 
> components, even those that could be UTF8String). 
> [http://www.infineon.com/upload/Document/tpm/IFX%20TPM%20EK%20
Cert%20.crt]
> The TPM 1.2 EK certificate is a bad example -- as it is 
> invalid.  
> [http://www.infineon.com/upload/Document/tpm/EKCertificate.crt]
> It uses UTF8String for the countryName in the issuer field 
> and in the authorityKeyIdentifier extension.  The countryName 
> MUST be a PrintableString (not a DirectoryString, which 
> includes UTF8String as a choice).
> And you have already shipped millions of these. yikes!
> 
>

---

From: "Kemp, David P." <[email-masked]>
Date: Thu, 14 Dec 2006 10:06:23 -0500

Hi Nils,

The intent was to avoid changing the parsing of subjectPublicKeyInfo
(since new OID values would be allowed, but they are still just OIDs and
the associated parameters structure for all is identical to
ecPublicKey).
This avoids having to implement the extension at all while still
addressing 99.94% of the application space.  If subjectPublicKeyInfo
contains a single algorithm OID (generic ECC, family, or family+mode),
then the *only* time an extension would be needed is to support
complex certificate-enforced policies* where more than one KDF,
but not all the KDFs in a family/mode, are permitted.  That seems
like so extraordinary a circumstance that most applications would
never need to implement the extension.  For families where two or
fewer modes exist** (which includes all of the currently-defined
families) the extension is never needed except to specify KDF
subsets.

One of the design team members is on record opposing restricting
KDFs in certificates.  If this view prevails then the extension
would never be needed at all.

Regards,
Dave

* an example of a complex policy where the extension is needed:

subjectPublicKeyInfo: ECMQV (family - all modes and KDFs)

extension: {mqvSinglePass-sha1kdf, mqvSinglePass-specifiedKDF,
   mqvFull-sha1kdf}  -- these three modes/kdfs are allowed, but
                     -- mqvFull-specifiedKDF is not allowed.

A simpler policy would be to permit mqvFull but not mqvSinglePass,
with no certificate restrictions on KDFs.  In this case the
extension is *not* be needed - subjectPublicKeyInfo would contain
an mqvFull "family+mode" OID.

** Note that ecdsa has only one mode, ecdh has two
(dhSinglePass-stdDH and dhSinglePass-cofactorDH), and
mqv has two (mqvSinglePass and mqvFull).

-----Original Message-----
From: Nils Larsch [mailto:[email-masked]] 

Cheers,
Nils

---

From: Russ Housley <[email-masked]>
Date: Thu, 14 Dec 2006 10:55:01 -0500

This is important information.  In light of this information, I 
cannot support the Design Team recommendation.

I unified approach is needed.  Given that the approach in RFC 4055 is 
being used in real RSA implementations, then we should employ this 
same approach for EC too.

Russ

At 09:36 AM 12/13/2006, Dieter Bratko wrote:

>That is not really true. For instance, RFC4055-style RSAES-OAEP keys 
>(OID 1.2.840.113549.1.1.7, parameters included) are used in TC 
>endorsement credentials in millions of TPM chips that are already 
>shipped onto the market (you may look at the Infineon Endorsement 
>certificates for an example: http://www.infineon.com/TPM --> 
>certificates --> TPM 1.2 EK certificate).
>We have already implemented RFC 4055 (on user requests) for our Java 
>crypto toolkit and will have to continue to support it in any case. 
>Since RFC 4055 includes the parameters into the key, it was possible 
>to implement it without almost any API changes. Of course, internal 
>changes were necessary to support the new key types, however, for 
>implementation and usage, it is simpler and more straightforward to 
>have the parameters inside the key than to maintain them separatly .
>With the extension based approach, it would be necessary to 
>distinguish between keys from certificates without the new 
>extension, keys from certificates with the new extension which could 
>be critical or not critical, and could contain parameters or not. We 
>must check if validation must be done, must not be done or may have 
>to be done. Maybe applications that are already using RFC4055 keys 
>would put them into certificates with the new extension and finally 
>we might have all possible combinations of keys
>with/without parameters and certificates with/without critical/non 
>critical extension with/without parameters which would not 
>interoperate anymore.
>
>Before a specification becomes a standard RFC it has to go through a 
>certain development cycle where it is discussed, reviewed and -- if 
>necessary --
>revised serveral times. If you now start to withdraw and 
>incompatibly change standard RFCs (wihout the absolute necessity to, 
>for instance, fix some critical security hole), how in future shall 
>we know when it is time to rely on a standard RFC to implement and 
>use it (or built other standards upon it)? Should anyone wait until 
>the standard maybe used by someone other? This
>practice would not be suitable for increasing usage of and putting 
>trust into future PKIX standards. There are not that big advantages 
>in the extension based approach to therefore change an existing standard.
>
>Regards,
>Dieter
>
>----- Original Message ----- From: Stefan Santesson

---

From: Daniel Brown <[email-masked]>
Date: Thu, 14 Dec 2006 11:34:27 -0500

> same approach for EC too.

For what it's worth: my ID aimed to provide a unified approach as RFC 
4055, modulo some minor necessary differences.  These differences stem 
from the fact ECC is the not same as RSA.  For example, most ECC schemes 
are key agreement schemes whereas RSA is an encryption (key transport) 
scheme.  More problematically, ECC depends on KDFs, and everybody has 
their own KDFs, and doesn't seem like anybody else's KDFs.  That is why I 
include a high degree of granularity, so users to choose which KDFs they 
liked and which they didn't, to their heart's content.  I'm quite happy to 
add to my ID a syntax that allows any-KDF, either by means of new OID to 
that effect (i.e. family OIDs) or re-use the existing OID and omitting the 
KDF parameter (which is the way RFC 4055 works: omitted parameters mean 
any method is okay).  By the way, if somebody is capable of implementing 
RFC 4055, then surely they can implement my ID.

Also, for what little it's worth: I really like the Design Team's idea of 
using extensions, and indeed, perhaps would have used such an approach, if 
I hadn't instead tried to follow the RFC 4055 precedent of specifying all 
the algorithm details completely inside the subject public key info.

Regards,

Dan

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 14 Dec 2006 18:04:11 +0000

This is crypto toolkit development and does not support that OIDs actually are being used in any certificates.

I think this forces us to support those OIDs already defined, but I don't think it prevents us from taking a more reasonable direction for all new modes that are coming to the table with ECC. This new approach could also support RSA and we could recommend against using the RFC 4055 OIDs in new certificates.

I think we would have been forced to do this anyway, without this knowledge.

The alternative here is to define a jungle of new OIDs for ECC, and that can't possibly be a better solution.

Stefan Santesson
Senior Program Manager

> [email-masked]] On Behalf Of Russ Housley
> Sent: den 14 december 2006 16:55
> To: [email-masked]

---

From: Russ Housley <[email-masked]>
Date: Thu, 14 Dec 2006 14:57:50 -0500

Stefan:

I disagree.  I'll try to summarize my though process, hopefully 
without rehashing all of the previous traffic.

RFC 4055 defines a way of specifying that an RSA public key is used 
only for a particular algorithm (for example OAEP).  We need this 
capability for ECC, and to first order this is easily accomplished 
with the same mechanism that is employed in RFC 4055.

The issue is granularity (for example ECDH uses a KDF, so one might 
want to limit the public key to a specific KDF).  I do not see much 
value in this level of granularity.  Diffie-Hellman also makes use of 
a KDF, but we saw no reason to limit this in the 
certificate.  Instead, we left this to applications that make use of 
the certificate.  RFC 2631 is an example where certificates 
containing Diffie-Hellman keys were used.  By picking the appropriate 
granularity to be constrained in the certificate, the "jungle of new 
OIDs" is avoided.

The security considerations for RFC 4055 say:

    Generally, good cryptographic practice employs a given RSA key pair
    in only one scheme.  This practice avoids the risk that vulnerability
    in one scheme may compromise the security of the other, and may be
    essential to maintain provable security.

The same advice seems appropriate for ECC.  However, I would not 
expect the use of ECDH with two different KDFs to lead to a 
cryptographic vulnerability for the Elliptic Curve private keys.  So, 
the certificate does not need to carry this type of constraint.

Russ

At 01:04 PM 12/14/2006, Stefan Santesson wrote:
>This is crypto toolkit development and does not support that OIDs 
>actually are being used in any certificates.
>
>I think this forces us to support those OIDs already defined, but I 
>don't think it prevents us from taking a more reasonable direction 
>for all new modes that are coming to the table with ECC. This new 
>approach could also support RSA and we could recommend against using 
>the RFC 4055 OIDs in new certificates.
>
>The alternative here is to define a jungle of new OIDs for ECC, and 
>that can't possibly be a better solution.
>
>
>Stefan Santesson
>Senior Program Manager

---

From: Russ Housley <[email-masked]>
Date: Thu, 14 Dec 2006 15:13:41 -0500

Dan:

I think my reply to Stefan also covers the points that you have
raised.

Russ

At 11:34 AM 12/14/2006, Daniel Brown wrote:

Russ Housley wrote on 12/14/2006
10:55:01 AM:

For what it's worth: my ID
aimed to provide a unified approach as RFC 4055, modulo some minor
necessary differences.  These differences stem from the fact ECC is
the not same as RSA.  For example, most ECC schemes are key
agreement schemes whereas RSA is an encryption (key transport)
scheme.  More problematically, ECC depends on KDFs, and everybody
has their own KDFs, and doesn't seem like anybody else's KDFs.  That
is why I include a high degree of granularity, so users to choose which
KDFs they liked and which they didn't, to their heart's content.
I'm quite happy to add to my ID a syntax that allows any-KDF, either by
means of new OID to that effect (i.e. family OIDs) or re-use the existing
OID and omitting the KDF parameter (which is the way RFC 4055 works:
omitted parameters mean any method is okay).  By the way, if
somebody is capable of implementing RFC 4055, then surely they can
implement my ID.

Also, for what little it's
worth: I really like the Design Team's idea of using extensions, and
indeed, perhaps would have used such an approach, if I hadn't instead
tried to follow the RFC 4055 precedent of specifying all the algorithm
details completely inside the subject public key info.

Regards,

Dan

---

From: "Kemp, David P." <[email-masked]>
Date: Thu, 14 Dec 2006 16:59:15 -0500

Stefan,

I haven't seen an I-D containing the syntax of the proposed
extension, but the presentation says:

   * reuse X9 algorithm identifiers
        - deprecating 'with recommended'?

If this is the "jungle of new OIDs" you are referring to, then
the proposed extension lives in the same jungle as the other
two approaches.

However, a subjectPublicKeyInfo field that can contain one of eight
possible ECC OIDs:
 * the 3279 OID (ecPublicKey)
 * 3 family OIDs (ecDSA, ecDH, ecMQV)
 * 4 family-mode OIDs (ecDH-std, ecDH-cofactor, ecMQV-single,
ecMQV-full)

all with the same parameters structure, does not seem particularly
complex or jungle-like.

Including hash functions into combined family-mode-kdf OIDs
(as in X9.62 and the proposed new extension) does result in a
jungle, but that is not a differentiator between any of the
alternatives.

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Stefan Santesson
Sent: Thursday, December 14, 2006 1:04 PM
To: Russ Housley; [email-masked]
Subject: RE: Straw poll for Algorithm Identifiers in Subject Public Key
Info.

I think this forces us to support those OIDs already defined, but I
don't think it prevents us from taking a more reasonable direction for
all new modes that are coming to the table with ECC. This new approach
could also support RSA and we could recommend against using the RFC 4055
OIDs in new certificates.

I think we would have been forced to do this anyway, without this
knowledge.

The alternative here is to define a jungle of new OIDs for ECC, and that
can't possibly be a better solution.

Stefan Santesson
Senior Program Manager

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 15 Dec 2006 01:31:33 +0000

Sorry if I was unclear. The problem is not the number of OIDs.

The problem that was emphasized by the design team is the problem of having subject public key info used as a source of constraining information as opposed to just be a source of public key material.

This introduce a new dependency graph for a module using the private key that is not easily implementable unless this has been planned for in the basic design with APIs supporting it.

It seems that this conclusion of the design team, which has been supported by a majority of voices in the straw poll, is forgotten.
To me this is a major problem that needs to be solved.

Stefan Santesson
Senior Program Manager

> From: Russ Housley [mailto:[email-masked]]
> Sent: den 14 december 2006 20:58
> > > Subject: Re: Straw poll for Algorithm Identifiers in Subject Public
> Key
> > > Info.
> > >
> > >
> > > >Subject: RE: Straw poll for Algorithm Identifiers in Subject
> Public
> > > Key
> > > >Info.
> > > >
> > > >
> > > >
> > > >Also, unfortunately the link to the design team presentation
> slides
> > > was
> > > >wrong/old.
> > > >The correct URL is:
> > > >>RFC 4055, where new algorithm OIDs have been defined for some
> modes
> > > of
> > > >>RSA. Another concern raised is that the deployed products today
> are
> > > not
> > > >>deigned to handle usage restrictions provided in the Subject
> Public
> > > Key
> that
> algorithm
> > > >>restrictions to a future certificate extension to be specified in
> a
> > > new
> > > >>PKIX draft.
> > > >>
> the

---

From: Nils Larsch <[email-masked]>
Date: Fri, 15 Dec 2006 09:41:15 +0100

Hi David,

Kemp, David P. wrote:
> never need to implement the extension.  

well, the libraries / applications I'm interested in will, sooner
or later, need to support such an extension as well (once something
is specified in a public document some people have the strange
urge to require this in their cert profiles ...)

> For families where two or

if the extension could be used for one key type I need to
implement the logic to handle this extension and in this case
it doesn't really matter anymore how often this extension is
actually used for other key types.

Cheers,
Nils

---

From: Nils Larsch <[email-masked]>
Date: Fri, 15 Dec 2006 10:11:12 +0100

> that application to parse 3 family OIDs is a trivial task.

although it might be simple to change the parsing to recognize
the new OIDs you still need to change the way how the information
is processed (and this is not necessarily trivial).
Btw: I guess a lot of x509 capable applications must already
support a plethora of strange cert extension, adding support for
yet another shouldn't be too difficult ;-)

Cheers,
Nils

---

From: Russ Housley <[email-masked]>
Date: Fri, 15 Dec 2006 14:26:24 -0500

>Sorry if I was unclear. The problem is not the number of OIDs.

I do not know how else to interpret you statement about a "jungle of OIDs."

>The problem that was emphasized by the design team is the problem of 
>having subject public key info used as a source of constraining 
>information as opposed to just be a source of public key material.

I really need a lot more explanation here.  If this is the case, why 
didn't anyone raise it when we were discussing RFC 4055.  That was 
over four years ago!  We have now been told that at least one 
implementor has embraced this approach.  I am unwilling to pull the 
rug out from under them without a compelling reason.

>This introduce a new dependency graph for a module using the private 
>key that is not easily implementable unless this has been planned 
>for in the basic design with APIs supporting it.

Please explain.  The use of common math routines to implement many 
different crypto algorithms is common.  The fact that more than one 
algorithm identifier will ultimately be associated with RSA 
operations or EC operations does not seem unusual.  In fact, we see 
this all the time with AES.

>It seems that this conclusion of the design team, which has been 
>supported by a majority of voices in the straw poll, is forgotten.

No. Here is how I recall the history:
- RFC 4055 was published after significant discussion and consensus.
- PKIX learned of the X9.62 structure, which lead to a long discussion.
- Design Team was formed to suggest a way forward.
- Design Team chose a third approach (neither RFC 4055 nor X9.62).
- Design Team was asked if RFC 4055 was implemented by anyone,
   and they reported that there were not any implementations that were
   discovered during their investigation.  This was an important point for
   me (and I suspect many others) to support the Design Team proposal.
- Straw Poll begins.
- One response to the Straw Poll makes it clear that the Design Team
   was unaware of at least one RFC 4055 implementation.
- This new information caused me (and I suspect many others) to reject
   the Design Team proposal.

Russ

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 15 Dec 2006 19:57:24 +0000

Russ,

I can only guess why nobody complained 4 years ago, but problems have been overlooked before. I can only analyze the situation from what we understand today.

We have to live with RFC 4055 and we should not pull the plug for anyone.
But we are facing a major question when it comes to the ECC algorithms which are getting more and more important and where different modes of operation is more common. And we have to choose a direction.

I don't believe the existence of 4055 with some but very limited usage should dictate a future direction if there is reasons to believe that another approach is much better for the industry.

I respect the need for clarification. In short, when the function of OIDs not only instructions to the key import functions, but also a constraining mechanism for the signing module, this poses an architectural challenge. I will get back with more elaborate information. It seems that this would not only be a problem for us so others may also contribute with more elaborate description of the problems.

Stefan Santesson
Senior Program Manager

> Sent: den 15 december 2006 20:26
> To: Stefan Santesson
> Cc: [email-masked]

---

From: Russ Housley <[email-masked]>
Date: Fri, 15 Dec 2006 15:13:22 -0500

Stefan:

>I respect the need for clarification. In short, when the function of 
>OIDs not only instructions to the key import functions, but also a 
>constraining mechanism for the signing module, this poses an 
>architectural challenge. I will get back with more elaborate 
>information. It seems that this would not only be a problem for us 
>so others may also contribute with more elaborate description of the problems.

As you know, I have been insistent since the X9.62 approach was 
revealed that the PKIX WG provide one way to handle this issue, not 
one way for RSA and another way for ECC.  Since RFC 4055 has been 
implemented, I think that a compelling argument is needed to make a 
change.  So far, I have not seen one.  I look forward to a more 
complete description of the implementation concerns with the approach 
used in RFC 4055.

Russ

---

From: "Kemp, David P." <[email-masked]>
Date: Mon, 18 Dec 2006 11:05:56 -0500

Stefan,

<... see below ...>

-----Original Message-----
> From: Stefan Santesson
>
> I don't believe the existence of 4055 with some but very limited
> usage should dictate a future direction if there is reasons to
> believe that another approach is much better for the industry.

I agree with this statement.  But the posted information ("millions
of hardware chips already produced") indicates 1) somewhat more
than very limited usage, and 2) the 4055 approach to RSA options
is reasonable to implement even in very constrained chip-level
environments.

> I respect the need for clarification. In short, when the function
> of OIDs not only instructions to the key import functions, but
> also a constraining mechanism for the signing module, this poses
> an architectural challenge.

Clarification would be good.  As I understand it,
1) every signing module has an API
2) API parameters are populated by calling applications
3) applications can obtain API values from certificates and
    elsewhere, e.g. configuration data or protocol negotiation
4) each of the 3 alternatives uses the same OID values to express
    combinations of algorithms, modes, and (hopefully not) KDFs

So I see no difference between the key import function:
1) getting an OID from subjectPublicKeyInfo and passing it
  (possibly translating the OID to a #define constant or
  set of constants) to a signing module through an API
  call, and
2) getting the identical OID from an extension and doing
  the identical translation and API call.

Please clarify why an OID from subjectPublicKeyInfo is
different in concept from the same OID from an extension, and
why a signing/crypto module would be affected in any way by
where the calling application obtained the values supplied in
the crypto API calls.  In particular, if a hypothetical crypto
module required the ecPublicKey OID to be used in a
particular call, then why could applications not obtain
an ECC family OID from subjectPublicKeyInfo and translate
that to ecPublicKey before calling the module, passing
the specific algorithm in a different parameter?

In the absence of differences in agility, security,
and ease of implementation/transition, then the 4th design
goal, simplicity, wins.  With appropriate choice of OIDs,
the simplest alternative (4055/subjectPublicKeyInfo) is
capable of expressing both policy and implementation
constraints.  The simplest alternative should be best
for industry moving forward, even disregarding prior
successful hardware implementation of the 4055 approach
for RSA.

Dave

P.S. You requested that straw poll responses be
separated from technical discussion of the design
team proposal.  Based on those groundrules, a YES
vote in the straw poll is a vote to discuss, not
necessarily a vote to accept unchanged, the proposed
solution.  And the proposal is, to quote:

  * Design team added a third
    - Certificate extension
       . In conjunction with current RFC 3279
         or RFC 4055-style solution

The fact that there was an amazing lack of consensus
even among co-authors and co-workers indicates to me
that the certificate format issue had not previously
been considered in depth.  Based on the excellent
work of the design team and the subsequent discussion
on this list, I believe everyone's understanding
has deepened.  I know mine has.  And I support the
proposal of an optional extension in conjunction
with a 4055-style solution because I believe that
with appropriate choice of OIDs, in 99-100% of
cases the extension will not be needed or used
in certificates.  

Good design dictates a simple solution that addresses
80% (or 99%) of application requirements, along with
an optionally-implemented compatible extended solution
that addresses whatever is left.  The proposal quoted
above permits exactly that.

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 20 Dec 2006 15:26:06 +0000

Since last IETF a new draft was posted:
http://www.ietf.org/internet-drafts/draft-santesson-pkix-vccrl-00.txt

There is a request to add this draft to the PKIX work and I would encourage to start the discussion about this decision in this thread.

Stefan Santesson
Senior Program Manager

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 20 Dec 2006 15:22:55 +0000

David,

I still haven't seen any evidence that Certificates are being issued with the 4055 OIDs for RSA keys. If that is so, it would be very useful to know.

In general applications depend on simplified API calls (in multiple layers) to implement security and won't in general understand the difference between algorithmic modes. When moving from subject public key info from being a source of keying material to be a source of usage constraints, there will be challenges. Especially in transition from an installed base to a new way of using this field as we are using an existing field in a new way. Yes, this border was crossed by 4055 4 years ago, but as this was not implemented, in practice the field is still reduced to a source of keying data.

In general transition is much easier if you don't change semantics of old fields, but add new ones, such as an extension.

At the moment I can't give you a detailed description of the API challenge, I can only confirm that there is one. I hope to provide more information as soon as possible.

Stefan Santesson
Senior Program Manager

> Sent: den 18 december 2006 17:06
> To: [email-masked]

---

From: "Kemp, David P." <[email-masked]>
Date: Wed, 20 Dec 2006 12:08:38 -0500

Stefan,

In the Cryptoki API the C_Verify function takes an ECDSA
public key (type CKK_ECDSA) and the C_DeriveKey function
takes an EC public key (type CKK_EC).  So if you were to
take the RFC 3279 approach of using a single OID in
subjectPublicKeyInfo, then applications would be FORCED
to look in the extension before they could import a key
and store it with the appropriate type.
I don't know with certainty that there is a difference
between EC and ECDSA key pairs, but Cryptoki defines two
different generation mechanisms (CKM_EC_KEY_PAIR_GEN and
CKM_ECDSA_KEY_PAIR_GEN) which implies that there might
be a difference.  Regardless of whether the bits from one
key type differ from the bits of the other type, applications
must know enough to label a public key from a certificate
properly before it can be used to verify a signature or
derive a shared key.  And if applications are forced to
look in an extension to gain that knowledge, then you are
certainly changing the way subjectPublicKeyInfo has been
used in the past.

I contend that it is much less of a change in semantics/approach
to define family OIDs (ECDSA, ECDH, and ECMQV) as the
design team suggests, use those family OIDs in
subjectPublicKeyInfo as 4055 suggests, and allow
applications to import keys with the proper type
(CKK_ECDSA or CKK_EC) based solely on the subjectPublicKeyInfo
OID without needing to parse an extension.

Dave

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]] 
Sent: Wednesday, December 20, 2006 10:23 AM
To: Kemp, David P.; [email-masked]
Subject: RE: Straw poll for Algorithm Identifiers in Subject Public Key
Info.

David,

I still haven't seen any evidence that Certificates are being issued
with the 4055 OIDs for RSA keys. If that is so, it would be very useful
to know.

In general applications depend on simplified API calls (in multiple
layers) to implement security and won't in general understand the
difference between algorithmic modes. When moving from subject public
key info from being a source of keying material to be a source of usage
constraints, there will be challenges. Especially in transition from an
installed base to a new way of using this field as we are using an
existing field in a new way. Yes, this border was crossed by 4055 4
years ago, but as this was not implemented, in practice the field is
still reduced to a source of keying data.

In general transition is much easier if you don't change semantics of
old fields, but add new ones, such as an extension.

At the moment I can't give you a detailed description of the API
challenge, I can only confirm that there is one. I hope to provide more
information as soon as possible.

Stefan Santesson
Senior Program Manager

---

From: Tolga Acar <[email-masked]>
Date: Wed, 20 Dec 2006 10:25:58 -0800

David,

There is no difference between an ECDSA and an ECDH key in terms of bits/format, both with public or private keys.

It is my understanding and past experience that a P#11 application needs to look at the certificate extensions to at least determine key usages with the key, regardless of the key type? Typical example is RSA. Otherwise, by just looking at SPKI, you would use a public key marked with keyUsage=DigitalSignature for keyEncipherment purpose, for instance, with S/MIME; and that would be wrong.

The CKM_* in P#11 represents the mechanism (i.e., algorithm), not the key type in the SPKI, and P#11 uses that to determine what algorithm you would use the key with, but not to determine the type/format of the key.

- Tolga

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kemp, David P.
Sent: Wednesday, December 20, 2006 9:09 AM
To: [email-masked]
Subject: RE: Straw poll for Algorithm Identifiers in Subject Public Key Info.

Stefan,

Dave

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]]
Sent: Wednesday, December 20, 2006 10:23 AM
To: Kemp, David P.; [email-masked]
Subject: RE: Straw poll for Algorithm Identifiers in Subject Public Key
Info.

David,

Stefan Santesson
Senior Program Manager