Hiroyuki Sakakibara | 1 Aug 05:10 2000

RE: Dual-signed certificates

Mr. Tony Bartoletti
Thank you for your comments.

Date: Fri, 28 Jul 2000 14:57:39 -0700 Mr. Tony Bartoletti wrote

>However, this method involves a near-duplication of information that
>"must be preserved", and would seem to require the relying party
>retrieve/check the "Issuance Agreement" against the actual elements
>of the certificate, in order to preclude some claim by the subject
>that they (plausibly) never agreed to the certificate terms.

Yes, RP needs to check that "signed Issuance Agreement" extension 
which includes public key value, issuer name, subject name, and other
indicate the actual elements of certificates.
Therefore, as Mr. Bartoletti commented, it is near-duplication of
but it could be in X.509 ver3 certifcate as an extension.
Or applying a hash function, it might be reduced ?

>A protocol that provided the subject "sign first" seems very elegant,
>in that you get POP on the key, and POA (proof of acceptance) on the
>(pre)certificate, all in one shot.  And no duplication of the data.

"sign first", a certificate can include the "subject sign" as an extension,
however, a new protocol may be needed ... 

Hiroyuki Sakakibara
(Continue reading)

Hiroyuki Sakakibara | 1 Aug 05:18 2000

RE: Dual-signed certificates

I have two questions related to this topic.

[Question 1]

May "issuance agreement or receipt of certificate
included in or attached to a public key certificate"
be used for protecting against following attack ?

Because a CA publishes his certificate, someone can know the
profile of it, and create the CA's certificates including the
same public key, same issuer/serialnumber, subject and
same or different extension values, "fake certs", and publishes 
them to a public repository or attaches to protocol messages etc...
Also he can create not only CA's fake certs but also fake long pathes.
If an attacker sends these fake pathes with many messages to a server
( i.e a shopping server, a validation server etc ... ),
this strengthens a Denial Of Service attack against the server, 
because the server will validate the fake pathes.

Of course, the server would notice that those fake certs, and fake pathes
are invalid, because verification of the signatures are failed at his
trust anchor.

If a top down path construction is applied, with checking
signatures, the attack will be defeated immediately, but, bottom up path
construction ... RP will not notice it fake until the path
reaches to his trust anchor.

[Question 2]

(Continue reading)

Robert Moskowitz | 1 Aug 16:13 2000

Company OIDs for free for PIs?

I have often thought about how little companies can get OIDs for 
free.  After all, a few thousand bills for a small company can be a lot of 

What I have seen is every company can have an EDI identifier.  X.435 
(EDIFACT) has defined over 300 EDI identifier namespaces (DUNS being the 
most common, supposedly).

I **THINK** this is the EDIFACT UNB IdentificationCode

X.435 has its own arc:

If we can get the EDI arc registered this way (probably is and only 
documented in X.435), the PRESTO!  Any company that has an EDI  identifier 
has an OID arc.

Can anyone fill in the missing parts of this and then perhaps Denis can add 
this as a recommendation for company PIs.

Robert Moskowitz
Security Interest EMail: rgm-sec <at> htt-consult.com

David P. Kemp | 1 Aug 18:33 2000

Re: Company OIDs for free for PIs?


Have you considered using Private Enterprise codes

True, the arc is a little shorter than the IETF's,
but that shouldn't be a big deal.  They're both free.


> Date: Tue, 01 Aug 2000 10:13:57 -0400
> To: ietf-pkix <at> imc.org
> From: Robert Moskowitz <rgm-sec <at> htt-consult.com>
> Subject: Company OIDs for free for PIs?
> I have often thought about how little companies can get OIDs for 
> free.  After all, a few thousand bills for a small company can be a lot of 
> money...
> What I have seen is every company can have an EDI identifier.  X.435 
> (EDIFACT) has defined over 300 EDI identifier namespaces (DUNS being the 
> most common, supposedly).
> I **THINK** this is the EDIFACT UNB IdentificationCode
> X.435 has its own arc:
> If we can get the EDI arc registered this way (probably is and only 
> documented in X.435), the PRESTO!  Any company that has an EDI  identifier 
(Continue reading)

Robert Moskowitz | 1 Aug 19:00 2000

Re: Company OIDs for free for PIs?

At 12:33 PM 8/1/2000 -0400, David P. Kemp wrote:

>Have you considered using Private Enterprise codes

Actually,  I have.  I got one for the AIAG (Automotive Industry Action 
Group) a couple of years ago  :)

>True, the arc is a little shorter than the IETF's,
>but that shouldn't be a big deal.  They're both free.

We would need to educate small businesses and IANA would have to get ready 
for a flood of 10Ks of company requests.

My little DBA, HTT Consulting, already has a DUNs #.  Once I know  how this 
arc would work (eg, I would then have a defacto arc.

In Europe, WIPO assigns company #s, they have over 25000 such companies 
registered already.  Again, instant arc.

Robert Moskowitz
Security Interest EMail: rgm-sec <at> htt-consult.com

tgindin | 1 Aug 21:04 2000

Re: Company OIDs for free for PIs?

     IANA even publishes their OID assignments at that location, which
neutralizes the major advantage of using a URI of the approximate format
http://domain/EmployeeAssignments?DateOfFirstUse.  In view of that, that
alternative is no longer necessary, although I'm sorry to have missed the
meeting in Pittsburgh.
     The application form for new assignments in IANA's OID list is at IANA
proper: http://www.iana.org/cgi-bin/enterprise.pl.  My only remaining
question is whether IANA will continue to provide a free service if every
company with > 100 employees asks for this.  I suppose they could charge a
SMALL fee instead.

               Tom Gindin

"David P. Kemp" <dpkemp <at> missi.ncsc.mil> on 08/01/2000 12:33:32 PM

Please respond to "David P. Kemp" <dpkemp <at> missi.ncsc.mil>

To:   ietf-pkix <at> imc.org
Subject:  Re: Company OIDs for free for PIs?


Have you considered using Private Enterprise codes

True, the arc is a little shorter than the IETF's,
but that shouldn't be a big deal.  They're both free.

(Continue reading)

Stefan Richards | 2 Aug 02:02 2000

RE: OCSP, SCVP vendors

ValiCert Inc. actively tests ValiCert partner products for interoperability
with OCSP.  ValiCert and RSA Data Security Inc. will soon be hosting an OCSP
interoperability testing site to provide a testbed for OCSP-enabled
applications to achieve interoperability

ValiCert would like to premote the same sort of intiatives for SCVP and is
interested in working with a partner or partners on such efforts.

For more information on the subject, please feel free to contact me

Stefan Richards                                           (650)567-5604
ValiCert Inc.                                      stefanr <at> valicert.com
Securing e-Transactions(tm)

--- Mohamed A. Elissa wrote:

Hi all,

I need to know if there are any vendors doing interoperability tests for
OCSP and SCVP, and where to get more information about the products passed
the tests.

Mohamed A. Eissa

Intel of Canada, Ltd.
(Continue reading)

FRousseau | 2 Aug 04:11 2000

RE: I-D ACTION:draft-ietf-pkix-ipki-pkalgs-00.txt

Hi Tim,

Here are some minor comments on this draft:

a.  Section 3.3, the description and presentation of what key usage extensions may optionally appear in a CA and/or an end entity certificate should be made consistent between the different algorithms. For example, the draft does not distinguish between a CA and an end entity certificate for ECDSA. The draft only mentions for ECDSA that if the keyCertSign and cRLSign values may only be asserted if the basicConstraints extension is present and cA is TRUE, but not for other algorithms. The draft mentions for KEA that the encipherOnly and decipherOnly values may only be asserted if the keyAgreement value is also asserted, but not Diffie-Hellman.

b.  Section 3.3.4, you refer to sections 3.1.1 and 3.1.2 in many instances, however these two sections have nothing to do with KEA.


Francois Rousseau
Director of Standards and Conformance
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
frousseau <at> chrysalis-its.com      Tel. (613) 723-5076 ext. 419
http://www.chrysalis-its.com     Fax. (613) 723-5078

Stephen Kent | 2 Aug 04:24 2000

draft WG meeting minutes

The draft minutes for today's WG meeting are reproduced below.  I'll 
accept  corrections until 8/11.



PKIX WG Meeting 8/1/00
Edited by Steve Kent (WG co-chair)

The PKIX WG met once during the 48th IETF and a total of 
approximately 180 individuals participated in this meeting.

The meeting began with the announcement that Tim Polk of NIST will 
take over from Warwick Ford as a co-chair of the WG. Warwick received 
a round of applause from the audience, for his service to the Wg 
since its inception.

Tim began the meeting with a review of the status of all of the WG 
documents. The following text summarizes the status of the documents:


PKIX Cert/CRL Profile (RFC 2459)
HTTP/FTP Operations (RFC 2585)
LDAP V2 Operational Protocols (RFC 2559)
LDAP V2 Schema (RFC 2587)
OCSP (RFC 2560)
CMP (RFC 2510)
CRMF (RFC 2511)
CMC (RFC 2797)
Diffie-Hellman POP (RFC 2875)
Certificate Policy/Practices Guideline (RFC 2527)
KEA Algorithms for Profile (RFC 2528)


Revised Profile (draft-ietf-pkix-new-part1-02.txt)
Algorithms for Profile (draft-ietf-pkix-ipki-pkalgs-00.txt)
Qualified Certificates (draft-ietf-pkix-qc-05.txt)
Time Stamp (draft-ietf-pkix-time-stamp-09.txt)
PKIX Roadmap (draft-ietf-pkix-roadmap-05.txt)
Revised CMP (draft-ietf-pkix-rfc2510bis.01)
CMP Transports (draft-ietf-pkix-cmp-transport-protocols-01.txt)
Operational Protocols - LDAPv3 (draft-ietf-pkix-ldap-v3-02.txt)
Additional LDAP Schema (draft-ietf-pkix-ldap-schema-00.txt)
Attribute Certificate Profile for Authorization 
Limited Attribute Cert Acquisition Prot (draft-ietf-pkix-laap-01.txt)
DCS (draft-ietf-pkix-dcs-05.txt)
Simple Certificate Validation Protocol (SCVP) (draft-ietf-pkix-scvp-03.txt)
Permanent Identifier (draft-ietf-pkix-pi-00.txt)
Repository Locator Service (draft-ietf-pkix-pkixrep-00.txt)
Tech. Rqmts. For Non-Repudiation (draft-ietf-pkix-technr-01.txt)


LDAP v3 Profile  (D. Chadwick-U. of Salford)
Split profile into two pieces: protocol vs. schema. The protocol 
parts should be completed in the next 6-8 weeks and be ready for WG 
last call. (Suggestion that the LDAP WG also be included in this last 
call.) The schema work will take longer, as it is a new topic. A 
major change for the schema is to allow searching on certificate 
fields, rather than searching on the directory attributes extracted 
from the certificate.  For now, plan to keep the schema work related 
to certificates in PKIX, not in an LDAP WG, with David acting as 
principal liaison between the two groups.

RFC 2459 evolution  (T. Polk-NIST)
2459 has been split into algorithm profiles vs. certificate & CRL 
syntax and processing. This allows the algorithms document to be 
revised as algorithms change, without affecting the syntax and 
processing standard. There is little new material here, mostly 
clarifications, editorial revisions, etc. We will hold a straw poll 
on the list on naming mandatory algorithms, e.g., RSA and SHA-1. With 
the end of the RSA patent period, many other security WGs are taking 
similar steps. Also, if the WG decides to identify mandatory 
algorithms, we need to decide whether they are specified in the 
certificate and CRL processing document, or in the algorithms 
document. (See slides for more details.) We should be able to go to 
WG last call very soon on these documents.

Qualified Certificates  (S. Santesson-AddTrust)
Discussions at this IETF meeting have resolved the few remaining 
points of contention with regard to this draft. Minor changes in 
wording will result in a new draft by the end of this week and this 
draft will be forwarded to the security area directors to proceed 
with the IESG last call.

Permanent Identifiers (D, Pinkas-Bull)
To be used only in certificates issued to individuals. Designed to 
track real world identity in the face of name changes, e.g., marriage 
or job changes within an organization.  The ID is expressed as a new 
name type, with two components; an assigner authority and a name. The 
first component may be omitted, in which case the certificate Issuer 
is presumed to be the assigner authority. Note that a registered ID 
(from general name form) has the necessary property that it is 
globally unique, and permanent (although not directly meaningful). 
Thus, depending on which general name form is employed, one can 
compare names either within a CA domain, or globally, across all CAs. 
Plan for now is to proceed with it as a separate document, not merged 
with the QC or son-of-RFC-2459 documents. (See slides for more 

Time Stamping Protocol  (D. Pinkas-Bull)
Now on version 9. Several changes made after last call completed. 
Changes include definition of the serial number consistent with 2459 
(can even be a hash of up to 160 bits!), change to SIA from AIA, etc. 
A number of minor wording changes were made, but the restriction on 
exclusive use of the TSA private key for signing responses has been 
preserved.  Ready for forwarding to the IESG.

Preface to OCSPX and SCVP discussions: As proposed at the Adelaide 
meeting, a small group was formed and generated a requirements 
document to characterize the motivations for remote validation 
services, to define the requirements for such services. The group did 
not compare the candidate protocols relative to these requirements.

OCSP Extensions  (M. Myers-VeriSign)
Previous ID has expired, expunged from IETF web site. Mike argues 
that OCSP is the right choice for remote path processing (RPP), via 
the addition of extensions. Proposal is to revise RFC 2560, to fix 
minor problems, clarify OCPS role as a framework for remote 
validation services.  Then, create separate documents to define 
extensions for remote path validation, remote path discovery, etc. 
So, there would not be an OCSPX document, but rather definitions for 
syntax and processing for standard extensions. (See slides for more 

D. Pinkas provided some slides addressing the parameters of remote 
path processing, e.g., how the requestor constrains the path 
processing or path construction operation. So, the format needs to be 
able to indicate whether the requestor wants CRLs or OCSP responses, 
what security policy to use in evaluating a certificate path, other 
constraints, etc.  Denis argues that the requirements document needs 
to cover more of these details. However, Paul Hoffman noted that the 
group was not able to agree to a larger set of "requirements." (See 
slides for more details.)

SCVP  (A. Malpani-ValiCert)
The speaker reviewed RPP requirements and what OCSP does to support 
part of the process. Ambarish argues that changes to OCSP to meet 
these extended requirements may break existing OCSP implementations, 
and that the code base for OCSP is small, so there is not much to 
leverage in building an RPP protocol. SCVP will support both ASN.1 
and XML, consistent with perceived client requirements to retain data 
in this format. (See slides for more details.)

Attribute Certificates (S. Farrell-Baltimore)
Profile has been updated, synchronized with latest X.509 version, and 
has completed WG last call. It is suggested that this document 
reference the successor to 2459, which clears up the residual 
reference issues.

CMP (C. Adams-Entrust)
CMP RFC is being revised to reflect minor changes. Plan is to wait 
until completion of interoperability testing (in the PKI forum) to 
finalize changes to this document, to reflect any further 
clarifications that arise from this testing.

Repository Locator (P. Hallem-Baker-Verisign)
Goal of this document is to specify a means by which one can map an 
RFC822 name for a user to the LDAP server where the user's 
certificates are stored.  The proposed approach is to use the SRV 
record in the DNS to provide the necessary pointer.  The SRV record 
is analogous to an MX record, but more general, supporting a list of 
services and matching addresses. Open questions include the 
internationalization of DNS (which the DNS WG will address), plus 
communicating conventions for access protocols (LDAP, HTTP, ...). The 
base document is a very small work item, because it is merely 
profiling the existing SRV record. Separate documents will be 
generated to describe each access protocol convention, e.g., LDAP, 
OCSP, and HTTP. Need to coordinate with LDAP WG and maybe DNS WGs on 
their plans for using SRV records for LDAP directory location. (See 
slides for more details.)

CMP Interoperability testing (B. Moskowitz-ICSA)
ICSA is working with PKI Forum to coordinate these interoperability 
tests. Three workshops have been conducted to date, with more 
scheduled for August and September.  Various algorithms, transport 
protocols, POP mechanisms have been tested. A number vendors have 
participated. Planned public demo at NISSC in October. Experience 
shows that variants in CA-side implementations do cause 
interoperability problems, and further clarifications are needed in 
RFC 2510 to help resolve ambiguities. CMC interoperability testing 
may also be pursued in the future.
freesupport6 | 2 Aug 02:47 2000

FREE Computer Support & Consulting for your Business - to remove Send a Blank Reply