Subject: Comment on RFC 2459

From: [email-masked]
Date: Fri, 15 Feb 2002 08:54:18 +0100

Comment on RFC 2459 Internet X.509 Public Key Infrastructure Certificate
and CRL Profile.

In Appendix D3 End-Entity Certificate Using RSA the encoding of the
critical key usage extension at offset 464 is the following:

0464 30 19         25: . . . . SEQUENCE
0466 06 03          3: . . . . . OID 2.5.29.15: keyUsage
                     : 55 1d 0f
0471 01 01          1: . . . . . TRUE
0474 04 04          4: . . . . . OCTET STRING
                     : 03 02 07 80
0480 30 19         25: . . . . SEQUENCE

The correct encoding should be:

0464 30 0e         14: . . . . SEQUENCE
0466 06 03          3: . . . . . OID 2.5.29.15: keyUsage
                     : 55 1d 0f
0471 01 01          1: . . . . . TRUE
                     : ff
0474 04 04          4: . . . . . OCTET STRING
                     : 03 02 07 80
0480 30 19         25: . . . . SEQUENCE

Regards
Dieter Schomaker
_________________________________________________________________
GAD eG, Weseler Str. 500, 48163 Münster   [email-masked]
Tel.: 0251/ 7133-1648                     FAX: 0251/ 7133-1616
_________________________________________________________________

---

From: "Housley, Russ" <[email-masked]>
Date: Fri, 15 Feb 2002 10:23:27 -0500

Dieter:

Please review 
http://www.ietf.org/internet-drafts/draft-ietf-pkix-new-part1-12.txt.

This document will obsolete RFC 2459 very shortly. It is in the RFC Editor 
queue right now, so publication will likely occur in the next few weeks.

Russ

---

From: "Roberto Opazo Gazmuri" <[email-masked]>
Date: Fri, 15 Feb 2002 20:09:53 -0300

Russ,

It is a little detail, but may be you could consider an equivalent treat of
issuer v/s subject and issuerAltName v/s subjectAltName fields.

In the PI discussion I said than the scope of the new syntax should be for
subjectAltName and for issuerAltName. I believe this attributes are plenty
equivalent, not only for their type, but for their purpose.

1.- A certificate has no meaning if you do not know the issuer and the
subject, so they are both equally critical information.

2.- In practice, naming an entity is equivalent than naming the special type
of entity that is the issuer.

At this time, it is difficult to imagine a certificate with an empty issuer
field (as it is with an empty subject field), but I think in the future PI
could be a better way to name entities when you are not interested in
building a directory tree. So it could be used for chaining purpose too.

At this time, the only clear is there is no reason to treat in different
ways issuer and subject fields, to see the future we have some time (I
hope).

Best regards,

Opazo, Roberto ([email-masked])
CEO - www.acepta.com
Certification Authority for Chile

Notes:

Page 19
The issuer field MUST contain a non-empty distinguished name (DN)

Page 24
The subject name MAY be carried in the subject field and/or the
subjectAltName extension.

---

From: "Housley, Russ" <[email-masked]>
Date: Tue, 19 Feb 2002 10:42:03 -0500

Roberto:

Many years ago, PKIX rejected the idea of empty issuer distinguished 
names.  This was done for two reasons.  There may be more reasons.  Since 
we found these two compelling, we did not look for any more.

First, CRLs identify revoked certificates using issuer DN and serial 
number.  If the issuer DN is empty, then the CRL processing would have to 
consider issuer alt names, adding undesirable complexity.

Second, S/MIMEv2 encryption identifies the recipient public key using 
issuer DN and serial number.  SMIMEv3 continues to support this convention 
for backward compatibility, and it also supports the use of subject key 
identifiers.  The second approach was added because it is significantly 
shorter than most cases of issuer DN and serial number.

Russ