Subject: draft-ietf-pkix-ipki-pkalgs-02.txt: ECDSA

From: Bodo Moeller <[email-masked]>
Date: Mon, 12 Mar 2001 10:38:19 +0100

According to draft-ietf-pkix-ipki-pkalgs-02.txt, section 2.2.3,

   When the ecdsa-with-SHA1 algorithm identifier is used the parameters
   MUST be NULL.

However section 2.3.5 specifies what the parameters should look like:

   ECDSA and ECDH require use of certain parameters with the public key.
   The parameters may be inherited from the issuer, implicitly included
   through reference to a "named curve," or explicitly included in the
   certificate.

      ecpkParameters ::= CHOICE {
        ecParameters  ECParameters,
        namedCurve    OBJECT IDENTIFIER,
        implicitlyCA  NULL }

Presumably 2.2.3 was meant to say that parameters are not OPTIONAL
for ecdsa-with-SHA1, and that hence they must be NULL if there
is no explicit value.

-- 
Bodo Möller <[email-masked]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036

---

From: Bodo Moeller <[email-masked]>
Date: Mon, 12 Mar 2001 11:04:15 +0100

> for ecdsa-with-SHA1, and that hence they must be NULL if there

As the introduction to section 2.2 makes clear, the quote from 2.2.3
is intended to only apply to 'parameters' fields of
'AlgorithmIdentifier's used in 'signatureAlgorithm' fields of
certificate, but not to the 'subjectPublicKeyInfo' case.
Similarly to 2.2.3, section 2.2.2 states that

   When the id-dsa-with-sha1 algorithm identifier appears as the algo-
   rithm field in an AlgorithmIdentifier, the encoding SHALL omit the
   parameters field.  That is, the AlgorithmIdentifier shall be a
   SEQUENCE of one component: the OBJECT IDENTIFIER id-dsa-with-sha1.

This too is misleading because AlgorithmIdentifiers appear not only
in 'signatureAlgorithm' fields, but also in 'subjectPublicKeyInfo' fields.

So the paragraph in section 2.2.2 should say something like

   When the id-dsa-with-sha1 algorithm identifier appears as the algo-
   rithm field in a signatureAlgorithm field, the encoding SHALL omit the
   parameters field.  That is, the signatureAlgorithm field shall be a
   SEQUENCE of one component: the OBJECT IDENTIFIER id-dsa-with-sha1.

Similarly, the above quote from section 2.2.3 could be changed to

    When the ecdsa-with-SHA1 algorithm identifier appears as the
    algorithm field in a signatureAlgorithm field, the parameters
    MUST be NULL.

---

From: Tim Polk <[email-masked]>
Date: Thu, 15 Mar 2001 12:29:47 -0500

Bodo,

The parameter specifications in these sections are not actually related, as 
we are performing different functions

In section 2.2.3, we are specifying an ECDSA *signature*.  As with DSA, the 
public key and parameters used to verify the signature may be obtained in 
three different ways:
(1) the parameters and public key may be in the subjectPublicKeyInfo in the 
end certificate in a certification path;
(2) the public key may be in the end certificate and the parameters may be 
obtained through parameter inheritance (from an intermediate certificate in 
the certification path); or
(3) through an out-of-band mechanism.

In this case, the ecdsa-with-SHA1 OID algorithm identifier is used in the 
algorithm identifier field.  Since the parameters MUST be obtained 
separately from the signature, the parameters field associated with the 
signature cannot contain useful information.  As a result, the parameters 
field is required to be NULL.

In section 2.3.5, we are specifying an ECDSA *public key* in the 
subjectPublicKeyInfo field.  (Note that we use a different OID, 
id-ecPublicKey.)  In this case, the parameters field may contain the EC 
paramters or indicate that parameters are to be obtained through parameter 
inheritance.  There are two mechanisms to specify parameters for EC: (1) 
directly by specifying the value of each parameter or (2) indirectly by 
specifying a named curve through an object identifier.  The second option 
may be encoded in a smaller number of bytes.  These mechanisms correspond 
to ecParameters and namedCurve, respectively, in the list of choices for 
parameters.   The third choice, implicitlyCA, is used to indicate that 
parameters are to be obtained through parameter inheritance.

Hope that helps.

Tim Polk

At 10:38 AM 3/12/01 +0100, Bodo Moeller wrote:
>PGP 
>http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 16 Mar 2001 00:22:19 +0100

In last PKIX meeting in San Diego I presented some thoughts on creating a 
new extension for inclusion of logotype information in certificates.

Last in this mail I include a primary suggested outline for such extension.

But first a short summary of the rationale:

At a first glance it may seem irrelevant to include logotype information in 
certificates and a natural first reaction is "OH NO... NOT ANOTHER THING TO 
INCLUDE!! DON'T WE HAVE ENOUGH?!!!"

The fact is though that at the ETSI meeting this week (In the group that 
handles European standards related to electronic signatures). IT WAS 
GENERALLY RECOGNIZED THAT INCLUSION OF LOGOTYPE DATA WOULD BE VERY USEFUL.

Why is that so?

The answer is that logotypes are carriers of trust and are widely 
recognized tools for trust recognition. Have you ever thought why EVERY 
physical instrument of trust, from loyalty cards, credit cards to 
Passports, contain trust symbols in the form of logotypes.

Are certificates different? ABSOLUTELY NOT!!

If PKI is to take off in the private market, the certificates must be user 
friendly and carry the same functionality (in electronic form) as ID-cards, 
passports and other physical ID:s do in physical form. And logotypes are a 
FUNDAMENTAL part of that.

Without logotypes, certificates can only be handled and presented as 
textual information for technically oriented users. This is the reality I see.

What is your observation?

How can we then do this?

Technically speaking, we don't have to include the actual logotype image 
and we don't have to destroy legacy applications.
I would suggest that we use the same mechanism that we specified for 
biometric data in RFC 3039 where a non-critical extension can include for 
each logotype:

-  type of logo
-  type of hash algorithm
-  hash of logotype data
-  URI to location of data

This will only take a few bytes but will allow new applications to import 
relevant logotypes, signed by the issuer of the certificate, to be 
displayed to the user.

So... What to do with this?

If this is to be proceeded at all, It could be part of son of RFC 2459, it 
could be part of a new RFC 3039 and it could be a new draft or merged with 
some other work. I'm open for suggestions.

I hope to be able to meet with many of you and discuss this in Minneapolis 
next week.

/Stefan Santesson

logotypeInfo  EXTENSION ::= {
           SYNTAX             LogotypeSyntax
           IDENTIFIED BY      id-pe-logotypeInfo }

       id-pe-logotypeInfo OBJECT IDENTIFIER  ::= {id-pe XX}

       LogotypeSyntax ::= SEQUENCE OF LogotypeData

       LogotypeData ::= SEQUENCE {
           typeOfLogotype       TypeOflogotype,
           hashAlgorithm        AlgorithmIdentifier,
           logotypeDataHash     OCTET STRING,
           sourceDataUri        IA5String OPTIONAL }

       TypeOflogotype ::= CHOICE {
           predefinedLogotypeType    PredefinedLogotypeType,
           LogotypeTypeID            OBJECT IDENTIFIER }

       PredefinedLogotypeType ::= INTEGER {
           subject-organization-logotype(0),
           issuer-organization-logotype(1)
           CA-network-logotype(2)}
           (subject-organization-logotype|
            issuer-organization-logotype|
             CA-network-logotype,...)

The predefined logotype types are

subject-organization-logotype, if used, SHALL be used to include a logotype 
of the subject organization. The logotype SHALL be consistent with, and 
require the presence of, an organization name stored in the organization 
attribute in the subject field.

issuer-organization-logotype, if used, SHALL be used to include a logotype 
of the issuer organization. The logotype SHALL be consistent with, and 
require the presence of, an organization name stored in the organization 
attribute in the issuer field.

CA-network-logotype, if used, SHALL be used to include a logotype used by a 
network of CA services, provided by one or several independent CA's, within 
which the issuer claims to issue this certificate.