Subject: Re: X.509 ACs vs. SPKI?

From: "Aram Perez" <[email-masked]>
Date: Tue, 01 Jun 1999 09:51:48 -0700

Hi Steve,

>>> I see the structure that raised your concern, and we'll clearly have to do
>>> something in our context to ensure that the ambiguity does not persist.  (I
>>> assume that this was not an issue in the context where the structure was
>>> used initially, due to the hash alg being identified elsewhere.)
>>>
>>> We relly love algorithm independence here in the IETF, so I will not try to
>>> spend time on the list justifying it.
>>
>>If I'm not mistaken, the definition for ESSCertID came from *IETF's S/MIME*
>>effort, so is appears that someone else at IETF does not "love algorithm
>>independence".
>
> Have you looked at the larger context in S/MIME where it is used?  if not,
> then this statement seems premature.

Its been a while since I read "the larger context in S/MIME". I'm just
basing my comments on what Denis Pinkas wrote. He stated "there is the
following structure which unambigously references an certificate" and then
provided the ASN.1 definition of ESSCertID. This is the context that I'm
making my contents: how to identify a certificate.

>
>>>  Clearly it has been important in the
>>> encryption algorithm arena, where independence is making it possible to
>>> transition from DES to 3DES or AES, or whatever.  Similar arguments apply
>>> to hash algorithms as well.
>>
>>Believe me, I'm a strong believer is algorithm independence but only where
>>it makes sense. And in the case of using the hash to identify a certificate
>>I don't believe it makes sense. I agree with the current definition of
>>ESSCertID. My objection was to Denis Pinkas comment about allowing more hash
>>algorithms to be used as the identifier of a certificate.
>
> I would find it most convenient to use the same hash here as the one used
> in signing the cert, since that hash alg is, by definition, one that both
> the CA and any relying party must implement.  But, since we don't mandate
> any single algorithm for that purpose, why do so for this hash?
>

I disagree that "we don't mandate any single algorithm" (and I'm assuming
'we' refers to IETF). S/MIME Version 3 Message Specification
(draft-ietf-smime-msg-06.txt) states in Section 2.1: "Sending and receiving
agents MUST support SHA-1."

>>>
>>> Finally, an Issuer name and serial number SHOULD uniquely identify a cert,
>>> but in reality there is insufficient control over Issuer names to guarantee
>>> uniqueness.  Use of the hash as a backpointer is more secure, though by
>>> itself a hash is not a great way to ID a cert, due to searching
>>> limitations, as discussed previously.
>>
>>You seem to agree that there will be "searching limitations" by having
>>algorithm independence. So why should PKIX impose these "searching
>>limitations" if there is no security risk/extra cost/Y10K/etc issue with
>>having one hash algorithm used to help identify a certificate?
>
> No, the seacrching problem I refer to is due to the use of ANY hash as an ID.

I'm confused by what you mean the the searching problem. I didn't get a
chance to finish this response on Friday and today I read Moshe Letvin's
posting on the uses for unique certficate ID. I think he very clearly
summarizes what I see as a problem when searching for a certificate.

Regards,
Aram

---

From: Stephen Kent <[email-masked]>
Date: Tue, 1 Jun 1999 13:20:55 -0400

Aram,

>making my contents: how to identify a certificate.

I may have misspoken here, if I interpret Russ's message correctly.
Generally we try to ensure that our protocols are algorithm independent,
but it may be that S/MIME was not so careful in this case.  Nonetheless,
that one exception does not detract from the general theme of algorithm
independence.

>agents MUST support SHA-1."

Again, I apologize for not being clear enough.  We do sometimes mandate a
set of MUST implement algorithms as defaults for interoperability, but we
try not to  design protocols to depend on these.  IPsec and SSL and S/MIME
do this. PKIX has not yet gone so far as to mandate specific algorithms,
hence my comment should hav been that "in the context we are discussing,
PKIX standards, we have not chosen to go this route so far."

>summarizes what I see as a problem when searching for a certificate.

I saw Moshe's message, and it does not address this issue I raised.  Local;
searching for a cert based on a hash is fine, but searching for someone's
cert in a large, distributed database environment is different, and not so
easily supported.  I have a private message from someone suggesting that it
is not so hard as I suggest, but I'll have to think about the proposal
before I am convinced that it is feasible.  Even if feasible, it may not be
especially attractive, vs. use of structured names as search keys.

Steve

---

From: "Peter Williams" <[email-masked]>
Date: Tue, 1 Jun 1999 16:53:04 -0500

> especially attractive, vs. use of structured names as search keys.

As I remember, RFC 1422, authored by one Steve Kent, used a hash-
based list mechanism to perform a DN membership test, as used by a (small
number of) authorities who were required to perform a distributed,
security-critical, uniqueness test.

There is also a hash-based http-proxying specification making
its way through the IETF - a version allows for distributed/segmented
http page caching.  Its deployed world-wide in Netscape and Microsoft
products - so its seems to work, in practice, world-wide, in
interoperable fashion, and largely documented by IETF.

http://search.ietf.org/internet-drafts/draft-melve-clientcache-com-00.txt

Another approach is to use URL caching, where the URL
value is composed of the URL-encoded hash value of the
entire cert.

http://search.ietf.org/internet-drafts/draft-lovric-icp-ext-01.txt

The ICP technique now works in combination with
PKIX ftp://ftp.isi.edu/in-notes/rfc2585.txt as part of
the id field.

Id say, PKIX related hash-based distributed searching for
certs is already a reality. It comes free with the
already deployed (ssl-ised) web infrastructure. RFC 2585 nicely
profiles the web to suit PKIX cert discovery/searching/caching.

   "This specification is part of a multi-part standard for the Internet
   Public Key Infrastructure (PKI) using X.509 certificates and
   certificate revocation lists (CRLs).  This document specifies the
   conventions for using the File Transfer Protocol (FTP) and the
   Hypertext Transfer Protocol (HTTP) to obtain certificates and CRLs
   from PKI repositories.  Additional mechanisms addressing PKI
   repository access are specified in separate documents."

Profiling CARP (see melve) and RFC 2585 means today one
can use http to not only access certificates from
a PKI repository, but that repository can be highly
distributed - where the resource (cert) id is a hash.

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 02 Jun 1999 16:18:40 +0200

All,

We have had a long discussion about how to include support for "reliance
limit" in Qualified Certificates.

My understanding is that this should be handled by a policy qualifier and a
qualifier could easily be defined using an existing ISO defined ASN.1
structure for monetary value.

But before deciding this we have to understand how the installed base of
software react if they encounter a policy OID with a qualifier. Will they
just ignore the qualifier if they are set up to accept the policy but don't
understand the qualifier, or will they reject the certificate.

And what is the situation if the policy extension is set to critical.

X.509 defines the policy qualifier as an extension of the policy. i.e. the
policy defines the use and meaning of the qualifier. No criticality bit
change that fact.

So my understanding is that if a policy is defined as accepted, then that
includes any qualifier value  unless it's explicitly defined that some
qualifier values are not accepted.

Is this also how it works out there in practical implementations????

Any comment on this is highly welcomed.

/Stefan
 
-------------------------------------------------------------------
Stefan Santesson                <[email-masked]>
Accurata Systemsäkerhet AB      http://www.accurata.se
Slagthuset                      Tel. +46-40 108588              
211 20  Malmö                   Fax. +46-40 150790              
Sweden                        Mobile +46-70 5247799

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------

---

From: Stephen Kent <[email-masked]>
Date: Wed, 2 Jun 1999 12:07:10 -0400

Stefan,

I don't think it is appropriate to cast the question in terms of a "typical
client.'  Most clients today do not process policies, much less policies
with qualifiers.  But, those clients also are not representative of the
sort of sophisticated applications that we are talking about.

steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 2 Jun 1999 11:45:49 -0400

Peter,

I am not familiar with the other examples you cite, but for RFC 1422, I
know that the author considered the hash lookup to be the best thing
available at the time, absent a ubiquitous directory mechanism.  Also, in
hindsight, while we do have some examples of PKI structures that look a lot
like the one proposed in 1422, that aspect of 1422 didn't pan out, and it
is clear that it would have had scaling problems over time.

Steve