Subject: Re: PKIX-1 - use of UTF8
From: "Bob Jueneman" <[email-masked]>
To: [email-masked], [email-masked]
Date: Tue, 30 Jun 1998 19:36:04 -0600

All good points, Chris. But in our case, at least, the directory and all of the other 
Novell server and client code have been Unicode enabled for many years, and 
UTF-8 was relatively recent. So no one is rushing to BMPString -- we've been using
it for some time, at least as far as I know.

Whether in the past we emitted pure Unicode or perhaps BMPString before it was 
standardized, I don't know.

In our PKIS product, we store the certificates in NDS using the native NDS interface, i.e., 
in Unicode, as I understand it.

I'm told that our LDAP 3  implementation will handle UTF-8, but I don't yet know 
whether that is for storage or retrieval, or whether there are any options. You certainly
know LDAP3 better than I do -- is UTF-8 the only option allowed?i

The cost or availability of the conversion code is of course the least of the issues, 
at least to us. Whether Bill Gates lies awake wondering if he can afford it, I
don't know. :-)

Bob
>
>
>>>> Chris Newman <[email-masked]> 06/30 8:40 AM >>>
>There seems to be some confusion surrounding BMPString, UTF-8 and Unicode.
>
>BMPString is purportedly the 16-bit subset of Unicode (full Unicode is
>represented in UTF-16).  It's less expressive than UTF-8.  Technically, a
>Unicode to BMPString converter would lose data.  This could become a
>serious issue when less frequently used CJK characters are assigned in
>plane 1 of Unicode (outside the BMP). 
>
>The conversion between Unicode (UTF-16) and UTF-8 is simple, and free code
>is available at <ftp://ftp.unicode.org/Public/PROGRAMS/CVTUTF/>.  While
>UTF-8 is more expressive than Unicode, it's unlikely that codepoints will
>be assigned outside the overlap between the two (on the flip side, there
>are already numerous proposals to assign codepoints outside the BMP).
>
>I will also point out that UTF-8 support in LDAPString DNs is a mandatory
>part of the LDAPv3 spec.  Was there some other directory you were planning
>on storing certificates in? 
>
>So I question why people are rushing towards BMPString when it's different
>from the predominant future directory technology and less expressive than
>the IETF preferred charset. 
>
>		- Chris
>

Date: Tue, 30 Jun 1998 19:14:45 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: RE: PKIX-1 - use of UTF8
Sender: [email-masked]

Brian LaMacchia (of Microsoft, or at least of microsoft.com) said:

>To provide another datapoint concerning BMPString support, we introduced
>client-side support for BMPString-encoded DirectoryString components in IE
>4.01.  All client-side code released since then (including IE 4.01 SP1,
>Windows 98 and the IE 5.0 Developer Preview) uses BMPString encodings for
>strings that contain characters not in the PrintableString character set.
>(Internally, everything is kept in Unicode.)  MS Certificate Server follows
>the same encoding rules for certs it issues.   

Unfortunately, perhaps, in the Novell Public Key Infrastructure Services 
component about to be released, we followed the PKIX draft instead of 
what would have arguably have been the more reasonable position, i.e., 
Microsoft's.

That is, we test a given character string character by character. If it will fit in 
Printable String, that's what we use. If it will fit in teletext, that's what we use,
archane escape characters and all. Otherwise, we output BMPString.

It wouldn't break my heart to abandon teletext in the next release, and probably
(hopefully) no one would be impacted terribly.  If we (collectively) were to decide 
to do so in the next few weeks, we _might_ even be able to delete teletext prior to 
shipping the internationalized versions of the software, but that is not a committment.

However, as of today it appears that given the appropriate input we will output a 
string which the Microsoft browser, Windows 98(??), etc., could not accept, i.e., 
teletext.

Whether the Netscape browser will accept teletext (or BMPString, for that matter),
I'm not entirely sure. We are in the process of testing those kinds of compatiblity 
issues right now.

One thing does appear reasonably clear, however, and that is that no CA product that
I am aware of currently emits UTF-8. Moreover, it appears highly doubtful that with 
the possible exception of SET code (of which there isn't a vast quantity, certainly),
there are no browsers or other certificate consumers that would be capable of
displaying UTF-8.

On the other hand, it appears that there is a considerable amount of support
for BMPString, namely to support products which use Unicode internally,
for what other option would they have had until very recently?

My conclusions are that:

1.   We could probably abandon teletext and substitute BMPString without 
much pain, especially since it appears that there might not be much browser
support for it, whereas there is more support for BMPString. (This is perhaps 
a US-centric vendor view.  Some European vendors who aren't concerned 
with the Asian market might very well see the issue differently.)

2.  Browser vendors should be encouraged to support UTF-8 as soon as possible,
if that is the way we are going to go. (Personally, given the BMPString support, I 
am NOT entirely convinced that is the correct direction, but I'll go along with 
whatever the majority of vendors decide, more or less independently of what 
the IESG/IETF decides. In other words, interoperability is _far_ more important
than standards compliance, at this point.)

3.  There is no chance that the CA products are going to lead the pack in 
implementing UTF-8. If they don't have it already, they are going to have 
to implement BMPString to compete in the Asian market, since that is what the 
existing browsers support.  And once BMPString is widely supported, UTF-8
becomes a much more difficult sell, IMHO.  But clearly emitting UTF-8 strings
as a mandatory encoding for Asian characters and maybe even the accented 
European characters when there ar no consumers for such strings is
the Dr. Kevorkian option.  

Exactly where Russian and Greek fit into this equation I'm not quite sure.

bob
>
>					--bal
>
>-----Original Message-----
>From: Brian Korver [mailto:[email-masked]] 
>Sent: Monday, June 29, 1998 4:12 PM
>To: [email-masked] 
>Cc: [email-masked]; [email-masked]; [email-masked];
>[email-masked] 
>Subject: Re: PKIX-1 - use of UTF8
>
>Bob,
>
>I'm certainly not telling anyone "simply speak English", or suggesting
>that anyone else do that.  Maybe I haven't been clear.
>
>Let me restate my point:  I don't know that implementations that support
>BMPString are any more common than implementations that support UTF8String.
>(by "support", I mean that they do not merely treat DNs (et al.) as
>opaque data.)  
>
>BMPString is a recent addition to DirectoryString.  I'd like to know
>if there are any non-SET implementations that actually support
>BMPString (again, don't confuse "support BMPString" with "support for
>UNICODE").  I believe there aren't many (any?) non-SET implementations that
>actually support BMPString, but please correct me if I'm wrong.
>
>If support for BMPString is widespread, then backwards compatibility is
>an issue.  If support for BMPString is not widespread, then backwards
>compatibility may not be an issue.
>
>brian
>[email-masked]

Date: Tue, 30 Jun 1998 18:54:26 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: Proposed Resolution of Comments (LONG!)
Sender: [email-masked]

Russ,

I think that several of these issues have been clarified to my satisfaction.

(1) So long as we are not required to prefix the 4-bit identifier in the keyIdentifier
for certificates which include both subject and authority key ID, I'm satisfied.
Whether or not we should more or less automatically be aligning with other
(primarily US) standards groups is an issue we could talk about some other time.

(2) I don't care which way the DN= issue goes. At present, we encode
DNS names in the commonName, which is distasteful, and I would be happy to 
change to something else as soon as we decide what to do.

(3) I would strongly recommend we add the X.520 definition of streetAddress 
to the list of RDN types that constitute the minimal schema for certificate 
processing code, including directory/respositories.  Implementing it within 
a CA should be optional, but recommended.

(4) If the only aspects of KEA that are included are the OID and parameter list,
then I suppose I could withdraw my objection.  But on the other hand, 
shouldn't we then give elliptic curves the same status?  What about 
Redpike (UK), GOST(Russian), and other algorithms? What are the support 
considerations?  If KEA is included in the spec, will CA vendors be expected to 
generate KEA certs as well as DSS, yada, yada, yada?  where will it all end?
Will the various browsers, etc, now be expected to support it, just because 
it is in "the standard"? In other words, just because the US government is 
going to use it, why should it necessarily be imposed on all vendors via 
the PKIX spec?  BTW, did the US government release it free and clear of 
patent encumbrances, and will they agree to defend at USG expense any 
patent claims that might be brought by anyone claiming infringement?  I 
doubt that the various patent attorneys have had time to review this yet. 
I just hate to see us rush to judgment on this without a full airing of possible 
issues.

Bob

>
>>>> Russ Housley <[email-masked]> 06/30 8:49 AM >>>
>Bob:
>
>>(1) Could you explain the motivation for including the 4-bit identifier in 
>>the keyIdentifier?  Since it hasn't even been defined yet, we 
>>clearly aren't using it. And we had a hard enough time getting 
>>just the Netscape and IE browsers to accept the same
>>kind of certificates that I would be very reluctant to change 
>>anything at this point.
>>
>>But perhaps more to the point, does it matter a whit to anyone that is 
>>processing a certificate what particular algorithm was used to 
>>generate a key ID, or why?  Suppose I want to include 
>>some other information, such as the identity of the server on 
>>which the key was created, or a customer ID, etc., etc?  
>>Why does this matter to anyone's software other than the CA's?
>>
>>So long as the keyID is one-to-one with a public key (which is 
>>what I believe the underlying requirement to be, what difference 
>>does it make how it is encoded (at least within reason)?
>
>This has been answered before.  Here it is again.  The key identifier was
>selected to align with documents from US Government, ANSI X9, and Draft ISO
>TC68.  The four-bit prefix permits the definition of other schemes.  However,
>clients don't care since they simply do exact match comparisons.
>
>>(2) On the issue of the proposed schema for DN components, I agree with 
>>those that have said that decomposing and DNS name is mostly 
>>a waste of time, and I doubt the efficacy of using name subordination 
>>on those fields, but I don't feel terribly strongly on the subject.
>
>There are some people using DN= as a component of a distinguished name.  I
>have
>no problem adding this to the PKIX list.
>
>>(3) On the other hand I believe that not including support for the 
>>residentialPerson type of user is unacceptable.  Not all applications 
>>are going to involve e-mail, and a street address is a pretty 
>>fundamental construct for most business and social usage.
>>
>>Why would you even care what country someone lived in 
>>(other than mere curiosity), much less locality or state, if you 
>>couldn't refer to the individual's (or organization's)
>>physcial delivery address?  It is necessary for disambiguating 
>>the name, in general, in addition to its other uses.
>>
>>StreetAddress should be included.in the minimal set of attributes
>>which CA software would be expected to handed when issuing 
>>certificates, and relying party software should be able to display, IMHO.
>
>X.520 defines street address as follows:
>
> streetAddress ATTRIBUTE ::= {
> WITH SYNTAX DirectoryString {ub-street-address}
> EQUALITY MATCHING RULE caseIgnoreMatch
> SUBSTRINGS MATCHING RULE caseIgnoreSubstringsMatch
> ID id-at-streetAddress }
>
>I do not think that X.500 generally includes this as a potential distinguished
>name component.  However, if many people see a need, then we should look at
>it.
>
>>(4) And finally, I have to object on prinicple to including support for
>>KEA at this late date. It has only been declassified a very short time, 
>>I daresay very few of us have even read it in any detail, and there 
>>has not been the time for detailed scrutiny that ought to be provided a
>>new algorithm, regardless of its origins.  Remember, Clipper came from
>>the same group, but was later found to have significant protocol flaws.
>>with respect to what it was attempting to do.  That's why we have 
>>peer reviews.
>
>The KEA definition is not new.  It was in a separate document because we were
>told that the standards track document could only reference publicly available
>algorithms.  KEA is now publicly available.  I do not want to turn this thread
>into a discussion of KEA.
>
>PKIX Part 1 simply states the algorithm identifier and parameter syntax public
>keys that appear in certificates.  There is a large community of US
>Governement
>users that will have KEA public keys in their key management certificates.
>Now
>that KEA is publicly available, why not include the algorithm identifiers and
>parameter syntax in PKIX Part 1?  I think that making this information widely
>available is a good thing to do.
>
>Russ 

Date: Tue, 30 Jun 1998 10:49:01 -0400
To: "Bob Jueneman" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Proposed Resolution of Comments (LONG!)
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Bob:

>(1) Could you explain the motivation for including the 4-bit identifier in 
>the keyIdentifier?  Since it hasn't even been defined yet, we 
>clearly aren't using it. And we had a hard enough time getting 
>just the Netscape and IE browsers to accept the same
>kind of certificates that I would be very reluctant to change 
>anything at this point.
>
>But perhaps more to the point, does it matter a whit to anyone that is 
>processing a certificate what particular algorithm was used to 
>generate a key ID, or why?  Suppose I want to include 
>some other information, such as the identity of the server on 
>which the key was created, or a customer ID, etc., etc?  
>Why does this matter to anyone's software other than the CA's?
>
>So long as the keyID is one-to-one with a public key (which is 
>what I believe the underlying requirement to be, what difference 
>does it make how it is encoded (at least within reason)?

This has been answered before.  Here it is again.  The key identifier was
selected to align with documents from US Government, ANSI X9, and Draft ISO
TC68.  The four-bit prefix permits the definition of other schemes.  However,
clients don't care since they simply do exact match comparisons.

>(2) On the issue of the proposed schema for DN components, I agree with 
>those that have said that decomposing and DNS name is mostly 
>a waste of time, and I doubt the efficacy of using name subordination 
>on those fields, but I don't feel terribly strongly on the subject.

There are some people using DN= as a component of a distinguished name.  I
have
no problem adding this to the PKIX list.

>(3) On the other hand I believe that not including support for the 
>residentialPerson type of user is unacceptable.  Not all applications 
>are going to involve e-mail, and a street address is a pretty 
>fundamental construct for most business and social usage.
>
>Why would you even care what country someone lived in 
>(other than mere curiosity), much less locality or state, if you 
>couldn't refer to the individual's (or organization's)
>physcial delivery address?  It is necessary for disambiguating 
>the name, in general, in addition to its other uses.
>
>StreetAddress should be included.in the minimal set of attributes
>which CA software would be expected to handed when issuing 
>certificates, and relying party software should be able to display, IMHO.

X.520 defines street address as follows:

 streetAddress ATTRIBUTE ::= {
 WITH SYNTAX DirectoryString {ub-street-address}
 EQUALITY MATCHING RULE caseIgnoreMatch
 SUBSTRINGS MATCHING RULE caseIgnoreSubstringsMatch
 ID id-at-streetAddress }

I do not think that X.500 generally includes this as a potential distinguished
name component.  However, if many people see a need, then we should look at
it.

>(4) And finally, I have to object on prinicple to including support for
>KEA at this late date. It has only been declassified a very short time, 
>I daresay very few of us have even read it in any detail, and there 
>has not been the time for detailed scrutiny that ought to be provided a
>new algorithm, regardless of its origins.  Remember, Clipper came from
>the same group, but was later found to have significant protocol flaws.
>with respect to what it was attempting to do.  That's why we have 
>peer reviews.

The KEA definition is not new.  It was in a separate document because we were
told that the standards track document could only reference publicly available
algorithms.  KEA is now publicly available.  I do not want to turn this thread
into a discussion of KEA.

PKIX Part 1 simply states the algorithm identifier and parameter syntax public
keys that appear in certificates.  There is a large community of US
Governement
users that will have KEA public keys in their key management certificates.
Now
that KEA is publicly available, why not include the algorithm identifiers and
parameter syntax in PKIX Part 1?  I think that making this information widely
available is a good thing to do.

Russ 

Date: Tue, 30 Jun 1998 14:57:42 -0700
To: "Arsenault, Al W." <[email-masked]>, "[email-masked]" <[email-masked]>
From: Michael Myers <[email-masked]>
Subject: Re: Comments on OCSP draft
Cc: "Arsenault, Al W." <[email-masked]>
Sender: [email-masked]

Al,

Good to hear from you, and thanks much for the detailed read.

At 12:02 PM 6/30/98 -0400, Arsenault, Al W. wrote:
>
>(Apologies if any of these are outdated; I've been wrapped up with other
>things for a while and am just catching up to PKIX, etc.)
>
>A few semi-random comments on the June 1998 OCSP draft
>(draft-ietf-pkix-ocsp-04.txt):
>
>1.  To support words Dave Solo has often spoken, the purpose of this
>protocol can probably be made more clear by inserting between the first
>and second paragraphs of section 2:
>
>	"This protocol serves to provide as current an answer as possible to
>the question, 'if I looked at the current CRL right now, would this
>certificate be on it?'
>It should be noted, however, that there are other
>questions that the application will have to provide answers to in
>deciding whether or not to accept a certificate, such as 'Has this
>certificate expired?', 'Is this certificate correctly signed?', etc.
>Providing this information is beyond the scope of OCSP."

Section 2.2 already states that:

"A notRevoked state by an OCSP responder DOES NOT absolve the application
of the responsibility of checking that the certificate is in its validity
period and has been correctly signed."

>
>2.  Section 2.2, "A definitive response message is composed of:..." -
>the first bullet says "version of the response".  Shouldn't this really
>be "version of OCSP?"  As worded now, it looks like the responder could
>put out something like "answer, version 1: revoked"; "answer, version 2:
>unknown", "answer, version 3:  revoked", etc.
>

Request and response versioning is purposefully decoupled.  There are no
plans to change anything, but this will enable downline flexibility should
there be a need to do so.

Implementations SHOULD return the same semantic content regardless of
response syntax version.

>3.  Section 2.3:  Will one or more of the authors please enlighten me as
>to the usefulness of the error type "internalError"?  In what case does
>this provide more useful information to the client than the response
>"unknown"?  I'm generally not a big fan of having a server send error
>messages back to the client that the client can't do anything about,
>anyway.  Certainly, the responder's System Administrator should be
>notified of the internal error, and possibly also a CA or two, but it
>seems to me that if a responder is working well enough to determine that
>it can't make a decision, it should just reply with "unknown".

The general notion was that the following set likely is not exhaustive of
all possible exception conditions:

- malformedRequest
- tryLater
- certRequired
- sigRequired

The problem is that many errors are implementation-specific.  Depending on
design, one could experience connectivity problems between a frontend
server and a backend database, somebody misconfigured the OCSP server and
the "signer" process died although the "receiver", "lookup" and "send"
processes are running, somebody pulled the card out of the reader, etc.

We didn't want to sign these responses (in the last case we might not be
able to), as implied by use of the "unknown" value of OCSPResponse, since
the response may differ in the absence of such an error.  Yet we wanted to
provide some conclusion to the protocol so that blocking clients wouldn't
block indefinitely.

>4.  Section 3.2:  you probably should specify that it's a
>"malformedRequest" error message.  (I know, I'm being somewhat retentive
>here, but let's be clear where we can.)

Yes.

>
>5.  Section 4.1, TBSRequest definition:  again, to what is this
>"version" referring?  If it's to "OCSP, version1", then it's fine - you
>should just say that.  If it means version of something else, then
>please clarify.

See prior response re: versioning.

>
>6.  Section 4.2.1 and 4.4.3 both say "OCSP responders SHALL be capable
>of recognizing and responding to the id-pkix-ocsp-basic response type."
>This wording seems wrong - I think it should be "OCSP responders SHALL
>be capable of recognizing requests and responding with the
>id-pkix-ocsp-basic response type."

Agreed.

>
>7.  Section 4.2.2.2, Time:  The fourth sentence seems to be wrong.  It
>says "Responses whose thisUpdate time is earlier than the local system
>time SHOULD be considered unreliable."  Those responses are generally
>reliable, it's when the thisUpdate time is LATER than the local system
>time that something may be wrong.  

Agreed.  Good catch.

>
>8.  Section 4.2.2.3.1:  It seems to me that allowing a CA to prevent a
>client from checking the validity of an Authorized Responder's
>certificate is wrong and should be dropped from the spec.  First of all,
>there doesn't seem to me to be any purpose for the CA to select this
>option.  If the check is unnecessary, then the clients can be told that
>their local policy can be set to not check - thus, the current third
>choice adequately covers the situation.  Second, if the client WANTS to
>make this check, it doesn't seem to me correct to allow the CA to tell
>it not to check.

On a personal note, I agree.  The prefatory note to this section is mine.
So there's my position.

As the lead instigator/editor of this thing though (it looked so simple 1
1/2 years ago!), I'm looking for the group's consensus on this point.  I
would note that this is an optional mechanism.  PKI designers are free to
choose whether or not to include this value in the certificate of an
authorized responder.

>
>9.  Section 5, fourth paragraph, last sentence:  insert "with" between
>"costs associated" and "its successful execution."

OK.

>
>				Al Arsenault
>
>-  speaking only for myself.  My views do not necessarily represent
>those of my employer.

Mike

Date: Tue, 30 Jun 1998 10:56:40 -0700
From: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
To: "Arsenault, Al W." <[email-masked]>
CC: "[email-masked]" <[email-masked]>, "Arsenault, Al W." <[email-masked]>
Subject: Re: Comments on OCSP draft
Sender: [email-masked]

Hi Al,
    Great comments!!! Thanks for the great review.

Only have a response to your 8th point:

> 8.  Section 4.2.2.3.1:  It seems to me that allowing a CA to prevent a
> client from checking the validity of an Authorized Responder's
> certificate is wrong and should be dropped from the spec.  First of all,
> there doesn't seem to me to be any purpose for the CA to select this
> option.  If the check is unnecessary, then the clients can be told that
> their local policy can be set to not check - thus, the current third
> choice adequately covers the situation.  Second, if the client WANTS to
> make this check, it doesn't seem to me correct to allow the CA to tell
> it not to check.

The issue here is that a CA designates another entity to issue OCSP
responses for it - for example, if the CA wants to keep its private
key off line. In this case, it might not provide relying parties
with any way of checking the designated responder's certificate
for revocation and be willing to accept the consequences of the
responder's private key being compromised (just as it already accepts
the consequences of its own private key being compromised).

The ability to issue a certificate with a "doesn't need to be
checked for revocation" extension, is the way for the CA
to "tell the clients not to check" the responder's cert for revocation.
We are trying to address the situation where a CA doesn't have full
control over the software running on every client's machine and no easy
way of setting the security policy on every client machine,
but still wants to tell the client it is okay
not to check the responder's cert for revocation (note: it should
still be checked for expiration).

If a client still WANTS to make the check, sure, nobody can stop the
client from doing so.

Regards,
Ambarish

-- 
---------------------------------------------------------------------
Ambarish Malpani
Architect					       (650) 849-9880
ValiCert, Inc.				        [email-masked]
3160 W. Bayshore Road		              http://www.valicert.com
Palo Alto, CA 94303

From: Brian Korver <[email-masked]>
Subject: Re: PKIX-1 - use of UTF8
To: [email-masked] (Chris Newman)
Date: Tue, 30 Jun 1998 10:03:34 -0700 (PDT)
Cc: [email-masked]
Sender: [email-masked]

Chris,

Did the definition of UNICODE change (with v2.0)?  I seem to remember
UNICODE being defined as approx. 2^16 characters encoded in 2 bytes.
When I see "supports UNICODE" being used, I normally assume that it's
this definition.  The documents I've seen that define BMPString also
use this definition.

However, I understand that the UNICODE standard also allows for the
use of UTF-16 encoding, which allows for the encoding of over a million
characters.  See:

    http://www.unicode.org/unicode/standard/principles.html

brian
[email-masked]

Chris Newman writes:
> 
> There seems to be some confusion surrounding BMPString, UTF-8 and Unicode.
> 
> BMPString is purportedly the 16-bit subset of Unicode (full Unicode is
> represented in UTF-16).  It's less expressive than UTF-8.  Technically, a
> Unicode to BMPString converter would lose data.  This could become a
> serious issue when less frequently used CJK characters are assigned in
> plane 1 of Unicode (outside the BMP). 
> 
> The conversion between Unicode (UTF-16) and UTF-8 is simple, and free code
> is available at <ftp://ftp.unicode.org/Public/PROGRAMS/CVTUTF/>.  While
> UTF-8 is more expressive than Unicode, it's unlikely that codepoints will
> be assigned outside the overlap between the two (on the flip side, there
> are already numerous proposals to assign codepoints outside the BMP).
> 
> I will also point out that UTF-8 support in LDAPString DNs is a mandatory
> part of the LDAPv3 spec.  Was there some other directory you were planning
> on storing certificates in? 
> 
> So I question why people are rushing towards BMPString when it's different
> from the predominant future directory technology and less expressive than
> the IETF preferred charset. 
> 
> 		- Chris

Date: Tue, 30 Jun 1998 09:57:34 -0700
To: <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Comments on OCSP draft
Sender: [email-masked]

At 12:02 PM 6/30/98 -0400, Arsenault, Al W. wrote:
>	"This protocol serves to provide as current an answer as possible to
>the question, 'if I looked at the current CRL right now, would this
>certificate be on it?'

I would strongly object to this kind of language in the document. OCSP
tells you the latest status of a certificate, not the status of the
certificate in the latest CRL. There is a huge difference. If a CA issues a
CRL once a week and revokes a cert on the first day of that week, I expect
a "revoked" response from an OCSP request.

>2.  Section 2.2, "A definitive response message is composed of:..." -
>the first bullet says "version of the response".  Shouldn't this really
>be "version of OCSP?"  As worded now, it looks like the responder could
>put out something like "answer, version 1: revoked"; "answer, version 2:
>unknown", "answer, version 3:  revoked", etc.

You are right that the wording needs to be changed, but I would propose
"version of OCSPResponse" because there is no version number for all of
OCSP, and the version of the OCSPRequest might be different.

Please note that there is a new draft available, and some of your comments
had been addressed in it (but others had not). The structure changed a
great deal, so the section numbering was different.

--Paul Hoffman, Director
--Internet Mail Consortium

From: "Arsenault, Al W." <[email-masked]>
To: "[email-masked]" <[email-masked]>
Cc: "Arsenault, Al W." <[email-masked]>
Subject: Comments on OCSP draft
Date: Tue, 30 Jun 1998 12:02:58 -0400
Sender: [email-masked]

(Apologies if any of these are outdated; I've been wrapped up with other
things for a while and am just catching up to PKIX, etc.)

A few semi-random comments on the June 1998 OCSP draft
(draft-ietf-pkix-ocsp-04.txt):

1.  To support words Dave Solo has often spoken, the purpose of this
protocol can probably be made more clear by inserting between the first
and second paragraphs of section 2:

	"This protocol serves to provide as current an answer as possible to
the question, 'if I looked at the current CRL right now, would this
certificate be on it?' It should be noted, however, that there are other
questions that the application will have to provide answers to in
deciding whether or not to accept a certificate, such as 'Has this
certificate expired?', 'Is this certificate correctly signed?', etc.
Providing this information is beyond the scope of OCSP."

2.  Section 2.2, "A definitive response message is composed of:..." -
the first bullet says "version of the response".  Shouldn't this really
be "version of OCSP?"  As worded now, it looks like the responder could
put out something like "answer, version 1: revoked"; "answer, version 2:
unknown", "answer, version 3:  revoked", etc.

3.  Section 2.3:  Will one or more of the authors please enlighten me as
to the usefulness of the error type "internalError"?  In what case does
this provide more useful information to the client than the response
"unknown"?  I'm generally not a big fan of having a server send error
messages back to the client that the client can't do anything about,
anyway.  Certainly, the responder's System Administrator should be
notified of the internal error, and possibly also a CA or two, but it
seems to me that if a responder is working well enough to determine that
it can't make a decision, it should just reply with "unknown".

4.  Section 3.2:  you probably should specify that it's a
"malformedRequest" error message.  (I know, I'm being somewhat retentive
here, but let's be clear where we can.)

5.  Section 4.1, TBSRequest definition:  again, to what is this
"version" referring?  If it's to "OCSP, version1", then it's fine - you
should just say that.  If it means version of something else, then
please clarify.

6.  Section 4.2.1 and 4.4.3 both say "OCSP responders SHALL be capable
of recognizing and responding to the id-pkix-ocsp-basic response type."
This wording seems wrong - I think it should be "OCSP responders SHALL
be capable of recognizing requests and responding with the
id-pkix-ocsp-basic response type."

7.  Section 4.2.2.2, Time:  The fourth sentence seems to be wrong.  It
says "Responses whose thisUpdate time is earlier than the local system
time SHOULD be considered unreliable."  Those responses are generally
reliable, it's when the thisUpdate time is LATER than the local system
time that something may be wrong.  

8.  Section 4.2.2.3.1:  It seems to me that allowing a CA to prevent a
client from checking the validity of an Authorized Responder's
certificate is wrong and should be dropped from the spec.  First of all,
there doesn't seem to me to be any purpose for the CA to select this
option.  If the check is unnecessary, then the clients can be told that
their local policy can be set to not check - thus, the current third
choice adequately covers the situation.  Second, if the client WANTS to
make this check, it doesn't seem to me correct to allow the CA to tell
it not to check.

9.  Section 5, fourth paragraph, last sentence:  insert "with" between
"costs associated" and "its successful execution."

				Al Arsenault

-  speaking only for myself.  My views do not necessarily represent
those of my employer.

>

Date: Tue, 30 Jun 1998 08:46:41 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Re: KeyIdentifier Algorithm
Sender: [email-masked]

After talking to Mike off-line, I now understand the rationale better. 
I was only considering the case where the CA had created the certificate 
containing the key Id, and coudln't understand why the algorithm would 
matter.

The key IDs we are creating will be 160 bit SHA-1, but without any tag or 
prefix.  I would agree with Tolga Acar, that if knowledge of the algorithm is
important, that perhaps a full fledged OID would be the way to go.

But I hope, at least, that the our present scheme won't cause any 
interoperability problems, as we don't have time to re-do the testing with 
the various browsers. This scheme at least works with MSIE and Netscape.

Bob

>>> Michael Myers <[email-masked]> 06/29 3:13 PM >>>
Bob,

At 01:21 PM 6/29/98 -0600, Bob Jueneman wrote:
> . . .
>But perhaps more to the point, does it matter a whit to anyone that is 
>processing a certificate what particular algorithm was used to 
>generate a key ID, or why?

I believe it matters for interoperability planning.

Application developers wanting to use AKI-SKI mapping as a means around
naming issues and also planning a wide interoperability base might need to
consider the case where a CA certificate does not have a value for
subjectKeyIdentifier but for some reason the end-entity certificate has a
value for AuthorityKeyIdentifier.  In this case it's necessary to implement
the algorithm in the application to produce a value for
SubjectKeyIdentifier as input to one's find-ca-cert-by-ski() function
(which in turn references a table mapping SKI to the index of a CA cert in
a local cert store.)

There is also the case of cross-certification.  Assume a CA issuing an
end-entity certificate (CA1) uses a different keyID algorithm than that
used by the CA that cross-certifies that CA's public key (CA2).

A value for AKI in those end-entity certificates may not map to the
cross-certificate if its SKI value differs.  True, CA2 could just copy out
the value of SKI in CA1's cert if it's there, but the policies governing
CA2 may mandate a keyID value generation algorithm different from that of CA1.

Mike

Date: Tue, 30 Jun 1998 07:46:30 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: Re: PKIX-1 - use of UTF8
To: Bob Jueneman <[email-masked]>
Cc: [email-masked]
Originator-Info: login-id=chris; server=THOR.INNOSOFT.COM
Sender: [email-masked]

On Mon, 29 Jun 1998, Bob Jueneman wrote:
> We have to support at least 12 languages, certainly including Japanese and Chinese.
> I don't know about Korean and Arabic.  All of the Novell software is Unicode based,
> but precisely how that translates to BMPString I confess I don't exactly know.

You can perform a lossy conversion from Unicode to BMPString, or a
lossless conversion to UTF-8.  UTF-8 is just an encoding of Unicode.
BMPString is a subset of Unicode (which might exclude characters important
to CJK customers in the future).

> But the most rpessing problem from our perspective is that we will have to support
> UTF-8 in not only our certificate processing software, but in SSL, and an in our NDS 
> directory, and in the administrative tools, etc.  Right now, I don't believe that we have
> the UTF-8 to Unicode routines or vice versa, so it will be a while before we could 
> do that.

If you're doing LDAPv3, you already support UTF-8 in the directory.
Unicode has UTF-8 <-> Unicode (UTF-16) routines:
    <ftp://ftp.unicode.org/Public/PROGRAMS/CVTUTF/>

> But unfortunately, I don't think we are in a position to tell our customers, almost 
> 50% of which are outside the US, to simply speak English.  So we've got
> to do something, and that something starts in about three weeks. BMPString
> is our only option, as far as I know.

Read RFC 2251, the LDAPv3 standard.

		- Chris

Date: Tue, 30 Jun 1998 07:40:43 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: Re: PKIX-1 - use of UTF8
To: [email-masked]
Originator-Info: login-id=chris; server=THOR.INNOSOFT.COM
Sender: [email-masked]

There seems to be some confusion surrounding BMPString, UTF-8 and Unicode.

BMPString is purportedly the 16-bit subset of Unicode (full Unicode is
represented in UTF-16).  It's less expressive than UTF-8.  Technically, a
Unicode to BMPString converter would lose data.  This could become a
serious issue when less frequently used CJK characters are assigned in
plane 1 of Unicode (outside the BMP). 

The conversion between Unicode (UTF-16) and UTF-8 is simple, and free code
is available at <ftp://ftp.unicode.org/Public/PROGRAMS/CVTUTF/>.  While
UTF-8 is more expressive than Unicode, it's unlikely that codepoints will
be assigned outside the overlap between the two (on the flip side, there
are already numerous proposals to assign codepoints outside the BMP).

I will also point out that UTF-8 support in LDAPString DNs is a mandatory
part of the LDAPv3 spec.  Was there some other directory you were planning
on storing certificates in? 

So I question why people are rushing towards BMPString when it's different
from the predominant future directory technology and less expressive than
the IETF preferred charset. 

		- Chris

From: Brian LaMacchia <[email-masked]>
To: "'Brian Korver'" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: PKIX-1 - use of UTF8
Date: Tue, 30 Jun 1998 01:13:24 -0700
Sender: [email-masked]

To provide another datapoint concerning BMPString support, we introduced
client-side support for BMPString-encoded DirectoryString components in IE
4.01.  All client-side code released since then (including IE 4.01 SP1,
Windows 98 and the IE 5.0 Developer Preview) uses BMPString encodings for
strings that contain characters not in the PrintableString character set.
(Internally, everything is kept in Unicode.)  MS Certificate Server follows
the same encoding rules for certs it issues.   

					--bal

-----Original Message-----
From: Brian Korver [mailto:[email-masked]]
Sent: Monday, June 29, 1998 4:12 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: Re: PKIX-1 - use of UTF8

Bob,

I'm certainly not telling anyone "simply speak English", or suggesting
that anyone else do that.  Maybe I haven't been clear.

Let me restate my point:  I don't know that implementations that support
BMPString are any more common than implementations that support UTF8String.
(by "support", I mean that they do not merely treat DNs (et al.) as
opaque data.)  

BMPString is a recent addition to DirectoryString.  I'd like to know
if there are any non-SET implementations that actually support
BMPString (again, don't confuse "support BMPString" with "support for
UNICODE").  I believe there aren't many (any?) non-SET implementations that
actually support BMPString, but please correct me if I'm wrong.

If support for BMPString is widespread, then backwards compatibility is
an issue.  If support for BMPString is not widespread, then backwards
compatibility may not be an issue.

brian
[email-masked]

From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: subjectAltName example differences
Date: Mon, 29 Jun 1998 22:06:49 -0700
Sender: [email-masked]

Section D.3 has an example RSA certificate with a subjectAltName
extension:

04 36
   30 34
      rfc822name
      a1 1a
         IA5String "[email-masked]"
         16 18 65 73 63 65 72 74 2d 75 70 63 40 65 73
         63 65 72 74 2e 75 70 63 2e 65 73

Am I wrong, or is the IA5String EXPLICITly tagged in this example?  a1
is the constructed(?!?), context-specific tag 1, 1a bytes long, 16 is
the UNIVERSAL tag for IA5String, 18 is the length, and 65 ... 73 is the
IA5String content "[email-masked]"

Section D.2.1 has an example of a DSA certificate with a subjectAltName
extension:

0617 04 12         18: . . . . . OCTET STRING
                     : 30 10 81 0e 77 70 6f 6c 6b 40 6e 69 73 74 2e 67
                     : 6f 76

Which can be rewritten to look like section D.3 as follows:

04 12
   30 10
      rfc822Name
      81 0e
      77 70 6f 6c 6b 40 6e 69 73 74 2e 67 6f 76

Where 81 is the non-constructed, context-specific tag 1, 0e bytes long,
and the implicitly tagged IA5String content is 77 ... 76 which is
"[email-masked]"

Is my mind gone, or is the RSA example incorrect (it should be using
IMPLICIT tagging)?

My apologies if this has been covered.

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Proposed Resolution of Comments (LONG!)
Reply-To: [email-masked]
Date: Tue, 30 Jun 1998 15:43:36 (NZST)
Sender: [email-masked]

>(1) Could you explain the motivation for including the 4-bit identifier in the
>keyIdentifier?  Since it hasn't even been defined yet, we clearly aren't using
>it. And we had a hard enough time getting just the Netscape and IE browsers to
>accept the same kind of certificates that I would be very reluctant to change
>anything at this point.
>
>But perhaps more to the point, does it matter a whit to anyone that is
>processing a certificate what particular algorithm was used to generate a key
>ID, or why?  Suppose I want to include some other information, such as the
>identity of the server on which the key was created, or a customer ID, etc.,
>etc? Why does this matter to anyone's software other than the CA's?
 
If people really do require a keyID to be a 160-bit string, perhaps the profile
could recommend something like:
 
  if keyID != 160 bits
    keyID = SHA1-hash( keyID );
 
This way even if a cert contains a keyID as defined by whatever other standard
people are trying to comply with, you can still construct from it a meta-keyID
which complies with PKIX, which allows chaining from PKIX-compliant
issuer/subject and ISO-compliant subject/issuer.
 
[How tolerant are the other standards/profiles about keyID's?  Will the ISO
 police come after you if they see a 160-bit keyID?]
 
>(4) And finally, I have to object on prinicple to including support for KEA at
>this late date. It has only been declassified a very short time, I daresay
>very few of us have even read it in any detail, and there has not been the
>time for detailed scrutiny that ought to be provided a new algorithm,
>regardless of its origins.  Remember, Clipper came from the same group, but
>was later found to have significant protocol flaws. with respect to what it
>was attempting to do. That's why we have peer reviews.
 
Just a random data point, I'm not aware of anyone who's managed to implement
KEA in a manner which produces results consistent with the supplied test
vectors.  Although I don't have any objections to including KEA, it looks like
the currently published information on it may contain errors.
 
Peter.

From: [email-masked]
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Subject: RE: PKIX-1 - use of UTF8
Date: Tue, 30 Jun 1998 11:15:36 +1000
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------ =_NextPart_001_01BDA3C4.98E93450
Content-Type: text/plain

-----Original Message-----
From: Brian Korver [mailto:[email-masked]]
Sent: Tuesday, 30 June 1998 9:12
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: Re: PKIX-1 - use of UTF8

>snip

Bob,

I'm certainly not telling anyone "simply speak English", or suggesting
that anyone else do that.  Maybe I haven't been clear.

Let me restate my point:  I don't know that implementations that support
BMPString are any more common than implementations that support
UTF8String.
(by "support", I mean that they do not merely treat DNs (et al.) as
opaque data.)  

BMPString is a recent addition to DirectoryString.  I'd like to know
if there are any non-SET implementations that actually support
BMPString (again, don't confuse "support BMPString" with "support for
UNICODE").  I believe there aren't many (any?) non-SET implementations
that
actually support BMPString, but please correct me if I'm wrong.

If support for BMPString is widespread, then backwards compatibility is
an issue.  If support for BMPString is not widespread, then backwards
compatibility may not be an issue.

cm> Agreed, Perhaps the question should be, if UTF8 was implemented
today, is there any existing application that would break ?. If not then
UTF8, seems a better choice for implementors due to its evolutionary
approach.

brian
[email-masked]

------ =_NextPart_001_01BDA3C4.98E93450
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.1960.3">
<TITLE>RE: PKIX-1 - use of UTF8</TITLE>
</HEAD>
<BODY>
<BR>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Brian Korver [<A =
HREF=3D"mailto:[email-masked]" =
TARGET=3D"_blank">mailto:[email-masked]</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, 30 June 1998 9:12</FONT>
<BR><FONT SIZE=3D2>To: [email-masked]</FONT>
<BR><FONT SIZE=3D2>Cc: [email-masked]; [email-masked]; =
[email-masked];</FONT>
<BR><FONT SIZE=3D2>[email-masked]</FONT>
<BR><FONT SIZE=3D2>Subject: Re: PKIX-1 - use of UTF8</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt;snip</FONT>
</P>

<P><FONT SIZE=3D2>Bob,</FONT>
</P>

<P><FONT SIZE=3D2>I'm certainly not telling anyone &quot;simply speak =
English&quot;, or suggesting</FONT>
<BR><FONT SIZE=3D2>that anyone else do that.&nbsp; Maybe I haven't been =
clear.</FONT>
</P>

<P><FONT SIZE=3D2>Let me restate my point:&nbsp; I don't know that =
implementations that support</FONT>
<BR><FONT SIZE=3D2>BMPString are any more common than implementations =
that support UTF8String.</FONT>
<BR><FONT SIZE=3D2>(by &quot;support&quot;, I mean that they do not =
merely treat DNs (et al.) as</FONT>
<BR><FONT SIZE=3D2>opaque data.)&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2>BMPString is a recent addition to =
DirectoryString.&nbsp; I'd like to know</FONT>
<BR><FONT SIZE=3D2>if there are any non-SET implementations that =
actually support</FONT>
<BR><FONT SIZE=3D2>BMPString (again, don't confuse &quot;support =
BMPString&quot; with &quot;support for</FONT>
<BR><FONT SIZE=3D2>UNICODE&quot;).&nbsp; I believe there aren't many =
(any?) non-SET implementations that</FONT>
<BR><FONT SIZE=3D2>actually support BMPString, but please correct me if =
I'm wrong.</FONT>
</P>

<P><FONT SIZE=3D2>If support for BMPString is widespread, then =
backwards compatibility is</FONT>
<BR><FONT SIZE=3D2>an issue.&nbsp; If support for BMPString is not =
widespread, then backwards</FONT>
<BR><FONT SIZE=3D2>compatibility may not be an issue.</FONT>
</P>

<P><FONT SIZE=3D2>cm&gt; Agreed, Perhaps the question should be, if =
UTF8 was implemented today, is there any existing application that =
would break ?. If not then UTF8, seems a better choice for implementors =
due to its evolutionary approach.</FONT></P>
<BR>
<BR>

<P><FONT SIZE=3D2>brian</FONT>
<BR><FONT SIZE=3D2>[email-masked]</FONT>
</P>

</BODY>
</HTML>
------ =_NextPart_001_01BDA3C4.98E93450--

From: Brian Korver <[email-masked]>
Subject: Re: PKIX-1 - use of UTF8
To: [email-masked] (Bob Jueneman)
Date: Mon, 29 Jun 1998 16:11:51 -0700 (PDT)
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

Bob Jueneman writes:
[snip]
> We have to support at least 12 languages, certainly including Japanese and =
> Chinese.
> I don't know about Korean and Arabic.  All of the Novell software is =
> Unicode based,
> but precisely how that translates to BMPString I confess I don't exactly =
> know.
> 
> I'm rhight now trying to make sure that we have actually generated DNs in =
> Japanese
> (either katakana or kanji, I don't know which), and Chinese and other =
> languages to
> the extent possible.  Exactly what will happen when we run those certificat=
> es through
> the various browsers I don't know yet.
> 
> I assume that VeriSign Japan has faces some of these problme, although it =
> may be=20
> that they are only processing printableString.
> 
> But the most rpessing problem from our perspective is that we will have to =
> support
> UTF-8 in not only our certificate processing software, but in SSL, and an =
> in our NDS=20
> directory, and in the administrative tools, etc.  Right now, I don't =
> believe that we have
> the UTF-8 to Unicode routines or vice versa, so it will be a while before =
> we could=20
> do that.
> 
> But unfortunately, I don't think we are in a position to tell our =
> customers, almost=20
> 50% of which are outside the US, to simply speak English.  So we've got
> to do something, and that something starts in about three weeks. BMPString
> is our only option, as far as I know.
> 
> Bob

Bob,

I'm certainly not telling anyone "simply speak English", or suggesting
that anyone else do that.  Maybe I haven't been clear.

Let me restate my point:  I don't know that implementations that support
BMPString are any more common than implementations that support UTF8String.
(by "support", I mean that they do not merely treat DNs (et al.) as
opaque data.)  

BMPString is a recent addition to DirectoryString.  I'd like to know
if there are any non-SET implementations that actually support
BMPString (again, don't confuse "support BMPString" with "support for
UNICODE").  I believe there aren't many (any?) non-SET implementations that
actually support BMPString, but please correct me if I'm wrong.

If support for BMPString is widespread, then backwards compatibility is
an issue.  If support for BMPString is not widespread, then backwards
compatibility may not be an issue.

brian
[email-masked]

Date: Mon, 29 Jun 1998 17:03:53 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: PKIX-1 - use of UTF8
Sender: [email-masked]

>Bob,
>
>I agree with everything you say.  Perhaps you have more information
>than I do.
>
>It was my impression (please correct me if I'm wrong) that BMPString
>was not yet widely deployed for any of the types of implementations
>you list.  SET uses BMPString, but I thought it was an anomaly.
>Also, I don't interpret "supports UNICODE" and "is `BMPString aware'"
>as equivalent.
>
>Anyhow, the point I was trying to make was that _if_ BMPString isn't
>widely deployed, then "backward compatibility" with BMPString is a
>non-issue and thus the usage rules can be simplified.   Maybe that's
>too much wishful thinking.  ;)
>
>brian

We have to support at least 12 languages, certainly including Japanese and Chinese.
I don't know about Korean and Arabic.  All of the Novell software is Unicode based,
but precisely how that translates to BMPString I confess I don't exactly know.

I'm rhight now trying to make sure that we have actually generated DNs in Japanese
(either katakana or kanji, I don't know which), and Chinese and other languages to
the extent possible.  Exactly what will happen when we run those certificates through
the various browsers I don't know yet.

I assume that VeriSign Japan has faces some of these problme, although it may be 
that they are only processing printableString.

But the most rpessing problem from our perspective is that we will have to support
UTF-8 in not only our certificate processing software, but in SSL, and an in our NDS 
directory, and in the administrative tools, etc.  Right now, I don't believe that we have
the UTF-8 to Unicode routines or vice versa, so it will be a while before we could 
do that.

But unfortunately, I don't think we are in a position to tell our customers, almost 
50% of which are outside the US, to simply speak English.  So we've got
to do something, and that something starts in about three weeks. BMPString
is our only option, as far as I know.

Bob

Date: Mon, 29 Jun 1998 15:58:49 -0600
From: "Tolga Acar" <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: KeyIdentifier Algorithm
Sender: [email-masked]

--Tolga

>>> Michael Myers <[email-masked]> 6/29/98 15:13:35 >>> wrote:
[snip]

>Application developers wanting to use AKI-SKI mapping as a means around
>naming issues and also planning a wide interoperability base might need to
>consider the case where a CA certificate does not have a value for
>subjectKeyIdentifier but for some reason the end-entity certificate has a
>value for AuthorityKeyIdentifier.  In this case it's necessary to implement
>the algorithm in the application to produce a value for
>SubjectKeyIdentifier as input to one's find-ca-cert-by-ski() function
>(which in turn references a table mapping SKI to the index of a CA cert in
>a local cert store.)

Then, if the concern is ineroperability, there already is a interoperability problem with the existing V3 certificates.

If the idea is correctly chaining the certificates to their issuers, then such an implicit and to-be-changed definiton of key identifier doesn't seem to a good solution, since there are applications running, and applications being implemented as of today.

If such a definition of Key-ID computation is really necessary, then i'd suggest adding an OID to the key identifier as done with the SIGNED macro. However, this would either require e new extension id (ce-id) or an addition to the existing authorityKeyIdentifier and to the subjectKeyIdentifier SEQUENCEs (probably with another context-specific tag).
Then, the computation of the key-ID can be dynamically read from the certificate.

Date: Mon, 29 Jun 1998 14:13:35 -0700
To: "Bob Jueneman" <[email-masked]>, [email-masked], [email-masked]
From: Michael Myers <[email-masked]>
Subject: KeyIdentifier Algorithm
Sender: [email-masked]

Bob,

At 01:21 PM 6/29/98 -0600, Bob Jueneman wrote:
> . . .
>But perhaps more to the point, does it matter a whit to anyone that is 
>processing a certificate what particular algorithm was used to 
>generate a key ID, or why?

I believe it matters for interoperability planning.

Application developers wanting to use AKI-SKI mapping as a means around
naming issues and also planning a wide interoperability base might need to
consider the case where a CA certificate does not have a value for
subjectKeyIdentifier but for some reason the end-entity certificate has a
value for AuthorityKeyIdentifier.  In this case it's necessary to implement
the algorithm in the application to produce a value for
SubjectKeyIdentifier as input to one's find-ca-cert-by-ski() function
(which in turn references a table mapping SKI to the index of a CA cert in
a local cert store.)

There is also the case of cross-certification.  Assume a CA issuing an
end-entity certificate (CA1) uses a different keyID algorithm than that
used by the CA that cross-certifies that CA's public key (CA2).

A value for AKI in those end-entity certificates may not map to the
cross-certificate if its SKI value differs.  True, CA2 could just copy out
the value of SKI in CA1's cert if it's there, but the policies governing
CA2 may mandate a keyID value generation algorithm different from that of CA1.

Mike

From: Brian Korver <[email-masked]>
Subject: Re: PKIX-1 - use of UTF8
To: [email-masked] (Bob Jueneman)
Date: Mon, 29 Jun 1998 12:47:56 -0700 (PDT)
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

Bob Jueneman writes:
[snip]
> I think it is very important to differentiate as to the different types=20
> of "implementations" here.  there are at leaast three: =20
> (1) Certificate creation software,
> (2) Software which displays certificates, either to end-users or for=20
>      admninstrative purposes,
> (3) Software which has to follow certificate chains, but can do so =
> blindly,
>      one DN "blob" at a time,
> (3) Directory/repository software which has to store and retrieve the=20
>      certificates.
> 
> It has to be understood that all of these kinds of implementations will
> have to change, generally speaking, before UTF-8 can be successfully=20
> deployed.
> 
> For those applications that have to support internationalization right =
> out=20
> of the box, dropping BMPString simply isn't an option.  It is (to the best =
> of my=20
> knowledge) the only solution presently available for systems which are
> based on Unicode and are shipping today.
> 
> Clearly certificate creation software can't treat DNs as blobs, for the=20
> very essence of a certificate is to bind the public key to the user.
> If the CA can't even read the contents of the certificate, the binding=20
> isn't worth much.
> 
> Likewise, software that has to display the contents of the certificate =
> to=20
> a human consumer has to worry about the format of thge DN.  So does=20
> an application such as SSL V3 that is validating the client. Presumably=20
> it is doing so against the name that is contained in the certificate.
> 
> Also, storage and retrieval software has be be name-format aware.  =
> Directories
> and other repositories represent a large established code base that=20
> generally existed long before the emergence of X.509 certificates, and=20
> long before UTF-8.  Changes that potentially impact such database =
> structures
> involve more than just the vendors -- the users will have a substantial =
> say=20
> in how rapidly any conversion takes place.
[snip]

Bob,

I agree with everything you say.  Perhaps you have more information
than I do.

It was my impression (please correct me if I'm wrong) that BMPString
was not yet widely deployed for any of the types of implementations
you list.  SET uses BMPString, but I thought it was an anomaly.
Also, I don't interpret "supports UNICODE" and "is `BMPString aware'"
as equivalent.

Anyhow, the point I was trying to make was that _if_ BMPString isn't
widely deployed, then "backward compatibility" with BMPString is a
non-issue and thus the usage rules can be simplified.   Maybe that's
too much wishful thinking.  ;)

brian
[email-masked]

Date: Mon, 29 Jun 1998 13:42:16 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: PKIX-1 - use of UTF8
Sender: [email-masked]

Brian,
>
>>>> Brian Korver <[email-masked]> 06/28 12:25 PM >>>
>Russ Housley writes:
>> We must have a solution that permits different codesets for each attribute
>> in a name.
>
I agree with Russ, here.  We have to worry about bi- and multi-lingual 
countries, India being the outstanding example, with 14 official languages,
many of which use entirely different alphabets. but that brings up a whole 
host of additional issues that we have to address, such as whether alt 
names are "official" or "unofficial/advisory".
>> 
>> I am reluctant to support the incorrect tagging of things as T.61 that in
>> fact are not T.61.
>
The reluctance is understandable.  I even get upset at people using commonName
to means something entirely different, so I guess I agree.
>> 
>> Can folks live with the following:
>> 1.  Country must be represented in PrintableString.
>> 2.  Other name components are represented using either 2a or 2b.
>> 2a.  If can be represented at PrintableString, do so; otherwise use BMPString.
>> 2b.  Represent as UTF8String.
>> 
>> Russ

I don't see muchother choice, unfortunately.
>
>Russ,
>
>I'm only commenting on your #2, not the rest of your proposal. 
>
>BMPString is a relatively recent addition to DirectoryString and I
>don't believe it is being used much.  I would also guess that few
>implementations exist that even deal with BMPString as such (rather 
>than treating it merely as opaque data).  So if the point is to 
>transition to UTF8String gracefully, I would drop 2a.

I think it is very important to differentiate as to the different types 
of "implementations" here.  there are at leaast three:  
(1) Certificate creation software,
(2) Software which displays certificates, either to end-users or for 
     admninstrative purposes,
(3) Software which has to follow certificate chains, but can do so blindly,
     one DN "blob" at a time,
(3) Directory/repository software which has to store and retrieve the 
     certificates.

It has to be understood that all of these kinds of implementations will
have to change, generally speaking, before UTF-8 can be successfully 
deployed.

For those applications that have to support internationalization right out 
of the box, dropping BMPString simply isn't an option.  It is (to the best of my 
knowledge) the only solution presently available for systems which are
based on Unicode and are shipping today.

Clearly certificate creation software can't treat DNs as blobs, for the 
very essence of a certificate is to bind the public key to the user.
If the CA can't even read the contents of the certificate, the binding 
isn't worth much.

Likewise, software that has to display the contents of the certificate to 
a human consumer has to worry about the format of thge DN.  So does 
an application such as SSL V3 that is validating the client. Presumably 
it is doing so against the name that is contained in the certificate.

Also, storage and retrieval software has be be name-format aware.  Directories
and other repositories represent a large established code base that 
generally existed long before the emergence of X.509 certificates, and 
long before UTF-8.  Changes that potentially impact such database structures
involve more than just the vendors -- the users will have a substantial say 
in how rapidly any conversion takes place.

>
>(an extra $.02: I think DirectoryString already has too many choices)
>
>brian
>[email-masked]

I agree with you on that one. It's just too bad that we can't redefine the world 
retroactively.

Bob

Date: Mon, 29 Jun 1998 12:26:59 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Making UTF8 palatable and keeping backwards compatibility
Sender: [email-masked]

At 11:27 AM 6/29/98 -0600, Bob Jueneman wrote:
>Are you under the impression that no one is yet issuing V3 certs??
Certainly that
>is NOT the case.  We are generating a bundle of five V3 certs at the rate
of one 
>bundle every 10 seconds, with somewhere between 80,000 and 200,000 
>bundles to be generated by the end of July.

You're right here, and I made a dumb mistake in my suggestion. Please
ignore what I said on this thread, and let's just go with Tim's latest
proposal. <skulking sheepishly into the corner>

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Mon, 29 Jun 1998 13:21:57 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Proposed Resolution of Comments (LONG!)
Sender: [email-masked]

Tim, four points:

(1) Could you explain the motivation for including the 4-bit identifier in 
the keyIdentifier?  Since it hasn't even been defined yet, we 
clearly aren't using it. And we had a hard enough time getting 
just the Netscape and IE browsers to accept the same
kind of certificates that I would be very reluctant to change 
anything at this point.

But perhaps more to the point, does it matter a whit to anyone that is 
processing a certificate what particular algorithm was used to 
generate a key ID, or why?  Suppose I want to include 
some other information, such as the identity of the server on 
which the key was created, or a customer ID, etc., etc?  
Why does this matter to anyone's software other than the CA's?

So long as the keyID is one-to-one with a public key (which is 
what I believe the underlying requirement to be, what difference 
does it make how it is encoded (at least within reason)?

(2) On the issue of the proposed schema for DN components, I agree with 
those that have said that decomposing and DNS name is mostly 
a waste of time, and I doubt the efficacy of using name subordination 
on those fields, but I don't feel terribly strongly on the subject.

(3) On the other hand I believe that not including support for the 
residentialPerson type of user is unacceptable.  Not all applications 
are going to involve e-mail, and a street address is a pretty 
fundamental construct for most business and social usage.

Why would you even care what country someone lived in 
(other than mere curiosity), much less locality or state, if you 
couldn't refer to the individual's (or organization's)
physcial delivery address?  It is necessary for disambiguating 
the name, in general, in addition to its other uses.

StreetAddress should be included.in the minimal set of attributes
which CA software would be expected to handed when issuing 
certificates, and relying party software should be able to display, IMHO.

(4) And finally, I have to object on prinicple to including support for
KEA at this late date. It has only been declassified a very short time, 
I daresay very few of us have even read it in any detail, and there 
has not been the time for detailed scrutiny that ought to be provided a
new algorithm, regardless of its origins.  Remember, Clipper came from
the same group, but was later found to have significant protocol flaws.
with respect to what it was attempting to do.  That's why we have 
peer reviews.

Bob

Date: Mon, 29 Jun 1998 11:02:52 -0700
To: Irene Gassko <[email-masked]>, Mike Smith <[email-masked]>
From: Michael Myers <[email-masked]>
Subject: Re: New OCSP draft
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

Irene,

At 09:43 AM 6/29/98 -0400, Irene Gassko wrote:
. . .
>We discussed this issue with Ambarish and came to the conclusion that
>historical queries that had been mentioned on this list before can solve this
>problem. That is, the application that finds out that the CA's key is revoked
>should be able to find out if it was revoked at a certain point in the past,
>and then make its own decisions.

Most needs can be met using the revocationTime field in RevokedInfo:

CertStatus ::= CHOICE {
    notRevoked   [0] IMPLICIT NULL,
    revoked      [1] IMPLICIT RevokedInfo,
    unknown      [2] IMPLICIT UnknownInfo }

RevokedInfo ::= SEQUENCE {
    revocationTime         GeneralizedTime,
    revocationReason	[0]    EXPLICIT CRLReason OPTIONAL }

This will give applications a before/after threshold to compare against
prior status obtained on an end-entity certificate.

The suspend/reinstate and suspend/revoke scenarios require a time-based
request extension to enable indexing against a certificate's state history.

>A more complex situation can arise when the key is compromised. When
>we find out that our credit card is missing, it can mean that it was lost or
>stolen, say, during the preceding week. Usual procedure in such cases is
>to revoke it absolutely at the day it's absence was discovered and also to
>go through purchases of the preceding week one by one and cancel them
>selectively. If we want to be able to implement such mechanism for
>certificates,
>I see two possible approaches:
>
>1. To add one more attribute TimeOfPossibleCompromise

The current OCSP draft reads:

"4.4.4 Other Extensions

CRL Entry Extensions - specified in Section 5.3 of PKIX part I - are 
also supported as singleExtensions."

So I believe this case is covered by the invalidityDate CRL Entry
extension, which addresses the same need. It's an OID and a GeneralizedTime
and has the advantage in that it maps directly onto CRLs.

The only simplification possible is to put TimeOfPossibleCompromised in as
an OPTIONAL to the RevokedInfo and some tag clean up as a result:

RevokedInfo ::= SEQUENCE {
    revocationTime           [0] GeneralizedTime,
    timeOfPossibleCompromise [1] GeneralizedTime, OPTIONAL
    revocationReason         [2] EXPLICIT CRLReason OPTIONAL }

One advantage of the extension-based mechanism is that it allows us to
build a stable request/response base syntax while accomondating new and
evolving requirements.

>2. Have an index that will allow CA to find certificates it issued during
>    given time and either reissue them automatically with a new key,
>    or contact their owners before reissuing for confirmation. This
>    decision should be application dependent (e.g. for a music site
>    it probably makes sense to let unauthorized people listen to
>    their music for a while rather than make their customers unhappy, 
>    while for a military site it could the opposite situation).

This seems more like the next phase in CA compromise recovery: generate a
new key pair and resign some subset of currently valid certificates.  I
agree that there's no way to specify a single rule or principle regarding
which of the set of questionable certificates to resign.  This is very much
a practices issue.

Mike

Date: Mon, 29 Jun 1998 11:27:44 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Making UTF8 palatable and keeping backwards compatibility
Sender: [email-masked]

Paul,

I must be missing something. I reread Chris Newman's posting of 6/22, 
but I don't see anything in his note that would substantiate your position.

Why is it that you believe that there is no backward-compatibility issue
with respect to version 3 certificates?

Are you under the impression that no one is yet issuing V3 certs?? Certainly that
is NOT the case.  We are generating a bundle of five V3 certs at the rate of one 
bundle every 10 seconds, with somewhere between 80,000 and 200,000 
bundles to be generated by the end of July.

All of those foundation certs will use printableString.  I'm more than willing to 
move to UTF-8 for everything, as soon as see solid evidence that the Microsoft and 
Netscape browsers, any S/MIME packages, etc., will support it.  But they have to
go first, and so far I see no commitment from them.

The issue of whether some implementors keep ISSUING certificates that
do not contain UTF-8 is of no consequence at all -- the IETF police will
issue them a summons and haul them before the IESG Court, and presumably
their punishment will be severe indeed. Ignore the IESG's mandate?? 
How dare they! Off with their heads! :-)

The only real question is when will all of the CONSUMERS of certificates accept
UTF-8 uniformly.  I'd certainly hope that code will be widely available by 2003,
but I'm not very confident that the user community will have purchased and installed 
the necessary upgrades by then.

Bob

>
>>>> Paul Hoffman / IMC <[email-masked]> 06/28 11:40 AM >>>
>I agree with Tim's recent posting (labelled "Proposed Resolution of
>Comments (LONG!)"). However, I think that some implementors will be tempted
>to keep issuing non-UTF8 after the cutoff date due to inertia. Also, the
>more people are using UTF8 strings early on, the more experience we will
>have with subtle problems.
>
>Chris Newman earlier pointed out something that I think most of us missed:
>that we only need to worry about backwards compatibility with version 1 and
>version 2 certs. For version 3 certs, there's no backward-compatibility
>issue, so we can go to UTF8 immediately for those certs. Doing this will
>give more implementors experience with UTF8 and will flesh out any
>remaining internationalization issues early.
>
>Therefore, I propose the following changes to the central part of 4.1.2.4
>from Tim's posting:
>
>. . .
>The DirectoryString type is defined as a choice of PrintableString,
>TeletexString, BMPString UTF8String and UniversalString. The UTF8String
>encoding is the preferred encoding in the IETF. All certificates whose
>version is 3 (value is 2), and all certificates issued after Dec. 31, 2003
>must use the UTF8String encoding of DirectoryString (except as noted
>below). Until that date, conforming CAs shall choose from the following
>options when creating a distinguished name, including their own, for
>version 1 (value is omitted) and version 2 (value is 1) certificates:
>. . .
>
>--Paul Hoffman, Director
>--Internet Mail Consortium

Date: Mon, 29 Jun 1998 10:07:59 -0400 (EDT)
From: Anne Anderson - Sun Microsystems <[email-masked]>
Reply-To: Anne Anderson - Sun Microsystems <[email-masked]>
Subject: Re: Proposed Resolution of Comments (LONG!)
To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

The modifications made to support use of
the RFC2247 domainComponent (DC=) attribute satisfy
my objections.

Anne Anderson                 Email: [email-masked]
Sun Microsystems Laboratories   Tel: (978) 442-0928
2 Elizabeth Drive, UCHL03-205   Fax: (978) 250-5067
Chelmsford, MA 01824 USA

Date: Mon, 29 Jun 1998 09:43:06 -0400
To: Mike Smith <[email-masked]>
From: Irene Gassko <[email-masked]>
Subject: Re: New OCSP draft
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

At 04:03 PM 6/26/98 -0600, Mike Smith wrote:
>Ambarish:
>
>Your comments raised/revitalized some thoughts on two topics that I would
like to address:  Revocation/Chain validation and Risk/Trust.
>
>Actually, there should be a chain of revocation down from the cert being
revoked if a CA.  A CA cert being expired or revoked should cause a system
to revoke all certs issued under that CA cert, including all
cross-refenced/cross certified certs. 

I respectfully disagree with this. I believe that this decision (whether to
revoke
certificates that were issued under the revoked key of a CA while that key was
valid) should be implementation dependent. 

Consider this example: you buy a certificate that allows you to listen
to the music on the site of ABC Music Corporation for a month. Two
days later a salesman who sold you this certificate quits because his
contract has expired. You should be able to have access to your music
for the whole month, because it's none of your business what personnel
changes happen at this corporation and your certificate should be legitimate
under the circumstances. It could be different if the key was compromised
or in some other situation. Of course, if this guy used his keys to issue
certificates after he resigned, those should be invalid.

We discussed this issue with Ambarish and came to the conclusion that
historical queries that had been mentioned on this list before can solve this
problem. That is, the application that finds out that the CA's key is revoked
should be able to find out if it was revoked at a certain point in the past,
and then make its own decisions.

A more complex situation can arise when the key is compromised. When
we find out that our credit card is missing, it can mean that it was lost or
stolen, say, during the preceding week. Usual procedure in such cases is
to revoke it absolutely at the day it's absence was discovered and also to
go through purchases of the preceding week one by one and cancel them
selectively. If we want to be able to implement such mechanism for
certificates,
I see two possible approaches:

1. To add one more attribute TimeOfPossibleCompromise;

2. Have an index that will allow CA to find certificates it issued during
    given time and either reissue them automatically with a new key,
    or contact their owners before reissuing for confirmation. This
    decision should be application dependent (e.g. for a music site
    it probably makes sense to let unauthorized people listen to
    their music for a while rather than make their customers unhappy, 
    while for a military site it could the opposite situation).

Irene

 >Naturally, the revocation in lateral  chains of CAs in a
cross-certification schema becomes quite complex, and needs to rely on the
integrity of all CAs in that web of trust to operate seemlessly across each
other's ARL, CRL, CKL or whatever lists they use to indicate revocation,
suspension or compromise according to their rules.

>
>Then, of course, the problem always exists for the CA that may have been
cross-certified into other trust hierarchies (policy mapped, even) that
decides to simply abandon its CA business - how does one and when does one
check their cross-certified CAs' actual existence or status?
>
>Anyway, these are observations I've made in the past to some on this list,
and some of the reasons that cause us in the banking community to look at
building trusted PKI based on our business relationships, not on a new
trust model where we do not know with whom we are doing business without
someone we do have a business relationship backing up the third party's
claim of identity (and indemnifying us from their errors).  The PKI trust
models can reflect the trust models banks have used successfully for the
last couple centuries and these new models will probably have more success
and wider acceptance if they build on existing trust models, rather than
new, untrusted models of trust.  
>
>The mechanics of the PKI structures we are all working on in the IETF are
very important and can be adapted to fit within many trust models,
including those already in place in businesses, governments and financial
institutions, as well as in a new paradigm of technologically sophisticated
trust models.  Building standards to meet such diverse implementation goals
can lead to different groups trying to build in trust technologically to
try and outwit those that would use such systems in no-risk-assumed, no
trust needed environments.  I mean, would anyone expect a bank to honor a
self-authenticated (maybe even self issued) cert from a company or
individual unless there 
>
>I do believe that the market will be divided into the no-risk-assumed and
risk-assumed models, with the risk-assumed models being used in business
and government systems, and the no-risk-assumed models used more for social
context systems.
>
>Michael
>
>Michael
>
>>>> Dan Geer <[email-masked]> 06/26 3:05 PM >>>
>
>the physics of revocation include two perverse rules
>
>1. all revocations are retroactive
>
>2. the cost of revocation checking increases with the distance
>   the entity is from the root yet the value of the check decreases
>   with that same distance
>
>so at some scale of hierarchy, you will have to overcome the
>costs of hierarchy (such as by wildcarding and/or processing

>a validity check top down only so far as you care to bother)
>or you will have to treat this all as an exercise in buying
>and selling risk
>
>--dan
> 
Irene Gassko                                     Bell Laboratories
Lucent Technologies                          Secure Technologies Dept.
300 Brickstone Square                       voice:   (978) 691-3270
6-th Floor                                          e-mail: [email-masked]
Andover, MA 01845                            fax:      (978) 691-3186

Date: Mon, 29 Jun 1998 09:27:33 -0400
From: Paul Koning <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: SV: Last Call - Profile
Sender: [email-masked]

>>>>> "Nilsson" == Nilsson Hans <[email-masked]> writes:

 Nilsson> Peter, As you suspected, the Swedish SEIS specifications,
 Nilsson> also used in Finland, requires Givenname and Surname in the
 Nilsson> subject name. In addition, the CA may anything it wants
 Nilsson> according to the specification, and the CA product currently
 Nilsson> being used allows for input of Title and CommonName.

 Nilsson> I think we want to stick with that, and not treat the whole
 Nilsson> name as one blob. For example, you want to search for also
 Nilsson> persons with the Surname = "Nilsson" without knowing the
 Nilsson> Givenname. Also, different countries have different
 Nilsson> conventions for forming a Commonname from (Givenname,
 Nilsson> Surname).

Does this setup allow DNs that contain a given name but no surname?
That's necessary for some countries (Indonesia, for example).

Also, is a patronymic a "surname" (for Iceland)?

I think Peter is right.  The decomposition of names, starting with the 
notion that they can be decomposed at all to the granularity and
naming of the components, is very country/culture specific and is best 
left out.

If you want to search for all Nilssons, what's wrong with searching
for "CN contains Nilsson"?

	paul

Date: Mon, 29 Jun 1998 08:48:47 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: CRL Reason Code
Sender: [email-masked]

X.509 defines this extension as:

reasonCode EXTENSION ::= {
 SYNTAX CRLReason
 IDENTIFIED BY id-ce-reasonCode }

CRLReason ::= ENUMERATED {
 unspecified (0),
 keyCompromise (1), 
 cACompromise (2), 
 affiliationChanged (3), 
 superseded (4),
 cessationOfOperation (5),
 certificateHold (6),
 removeFromCRL (8) }

PKIX Part 1 refers to this extension as CRLReason,. but the extension name is
reasonCode.  Because the EXTENSION macro is not used in PKIX Part 1, it may be
confusing that these two are the same extension.

Anyone have a suggestion for making this clear?

Russ

From: Brian Korver <[email-masked]>
Subject: Re: PKIX-1 - use of UTF8
To: [email-masked] (Russ Housley)
Date: Sun, 28 Jun 1998 11:25:04 -0700 (PDT)
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Russ Housley writes:
> We must have a solution that permits different codesets for each attribute
> in a name.
> 
> I am reluctant to support the incorrect tagging of things as T.61 that in
> fact are not T.61.
> 
> Can folks live with the following:
> 1.  Country must be represented in PrintableString.
> 2.  Other name components are represented using either 2a or 2b.
> 2a.  If can be represented at PrintableString, do so; otherwise use BMPString.
> 2b.  Represent as UTF8String.
> 
> Russ

Russ,

I'm only commenting on your #2, not the rest of your proposal. 

BMPString is a relatively recent addition to DirectoryString and I
don't believe it is being used much.  I would also guess that few
implementations exist that even deal with BMPString as such (rather 
than treating it merely as opaque data).  So if the point is to 
transition to UTF8String gracefully, I would drop 2a.

(an extra $.02: I think DirectoryString already has too many choices)

brian
[email-masked]

Date: Sun, 28 Jun 1998 10:40:18 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Making UTF8 palatable and keeping backwards compatibility
Sender: [email-masked]

I agree with Tim's recent posting (labelled "Proposed Resolution of
Comments (LONG!)"). However, I think that some implementors will be tempted
to keep issuing non-UTF8 after the cutoff date due to inertia. Also, the
more people are using UTF8 strings early on, the more experience we will
have with subtle problems.

Chris Newman earlier pointed out something that I think most of us missed:
that we only need to worry about backwards compatibility with version 1 and
version 2 certs. For version 3 certs, there's no backward-compatibility
issue, so we can go to UTF8 immediately for those certs. Doing this will
give more implementors experience with UTF8 and will flesh out any
remaining internationalization issues early.

Therefore, I propose the following changes to the central part of 4.1.2.4
from Tim's posting:

. . .
The DirectoryString type is defined as a choice of PrintableString,
TeletexString, BMPString UTF8String and UniversalString. The UTF8String
encoding is the preferred encoding in the IETF. All certificates whose
version is 3 (value is 2), and all certificates issued after Dec. 31, 2003
must use the UTF8String encoding of DirectoryString (except as noted
below). Until that date, conforming CAs shall choose from the following
options when creating a distinguished name, including their own, for
version 1 (value is omitted) and version 2 (value is 1) certificates:
. . .

--Paul Hoffman, Director
--Internet Mail Consortium

Subject: Specifying Naming attribute types (was: Last Call - Profile)
To: [email-masked]
Reply-to: [email-masked]
From: [email-masked]
Date: Sun, 28 Jun 1998 02:39:13 -0700
Sender: [email-masked]

I am curious as to why pkix-ipki-part1-08 makes any assertions about what 
attribute types implementations should be prepared to accept in DNs. I suppose 
I wonder what the breadth of "implementations" is in this context.

In any case, a DN can be essentially considered the primary key of an entry in 
a directory someplace (where finding that directory is outside of the scope of 
pkix-ipki-part1-08). Besides needing specification of particular matching 
rules for DNs due to character encoding possibilities, I'm not sure I see any 
reason for a PKIX implementation (of some sort) needing to care about the 
attribute types used to construct any given DN. AFAICS, a PKIX impl is only 
going to be comparing DNs and/or using them to retrieve their respective 
directory entries (at which point there might be attributes within the entry 
that it would reasonably expect to be there).

Conventions on DN construction are in flux -- there's RFC2247 for instance. 
There's the msg below from Harald from a thread on DNs on the IDS list a while 
back. And there's also draft-hodges-ldap-dir-dn-reqs-00.txt and 
draft-ietf-lsd-nandi-00.txt. I expect that DN conventions will remain in flux 
and that the safest thing for relying implementations to do is to treat them 
as much as possible as opaque pointers to directory entries from whence one 
extracts the truly useful info -- like what the human-meaningful "name" of the 
subject of the directory entry is.

For example, here's a test directory server that sports DNs similar to the 
ones we'll be moving our directory to...

  server:	director.stanford.edu
  base:		dc=stanford,dc=edu

  example search:

    ldapsearch -h director.stanford.edu -b dc=stanford,dc=edu "cn=*entry*" dn

These DNs aren't anything like what section 4.1.2.4 and 4.1.2.6 and such 
discuss, but I'd expect them to work just as well in the wide world as DNs 
based on "o=Stanford University, c=US" (given that the machinery is in place 
to find the appropriate server to talk to in each case -- and that's an 
orthogonal topic).

Jeff

ps: I'll be out of town and out of touch this coming week, so if this sparks 
comments, it'll be after the 6th 'fore I can get to following up.
------------------------------------------------------------------------------
From: [email-masked]
To: [email-masked]
Subject: The 3 purposes of a Distinguished Name
Date: Wed, 09 Apr 1997 09:56:54 -0500

This came up during the IDS meeting, and I wanted to share my thoughts
with the mailing list:

At the moment, an X.500/LDAP Distinguished Name has 3 different
purposes:

- To give uniqueness to entries
- To give a way to specify a search space
- To add information (commonly Organization or Country) to an entry

My thought at the moment is that the current DN practice in Paradise
et al, and the suggested DNS-based DN scheme, perform all 3 purposes badly.

I think a naming plan should deprecate at least 1 and possibly 2 of the
purposes; things performing a single purpose usually are MUCH better than
things serving many incompatible purposes.

Details:

- Uniqueness of names is most easily done with more-or-less random
  name assignment, using appropriate delegation. An OID-based namespace
  might be the Right Thing for this.

- Search space setup is very dependent on how people think. And given
  our current technology, search algorithms HAVE to know the structure
  of the searchspace, because "whole subtree from root" is an unrealistic
  search space.

- Using the DN to give information like country or organization is an
  evil practice and should be abandoned. Put the attributes in each entry
  instead.

That's my opinions. Comments?

                   Harald A

Date: Sat, 27 Jun 1998 15:58:05 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Editorial changes for PKIX part 1 last call
Sender: [email-masked]

I found three small things that I'd like to see changed as part of last call.

In 4.2.1.7, first paragraph, fifth sentence, remove the parenthetical "(or
issuer alternative name)" because this section is only on the subject
alternative name.

In section 9's subsections, all patent numbers should say "US patent
number" since these are for the US only and we should be clear on that.
Let's be a tad US-centric, eh?

In appendic C, sixth paragraph, remove the reference to RFC 2044 and leave
the reference to RFC 2279. 2279 is complete and the reference to the older
(and incorrect) RFC could confuse implementors.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Sat, 27 Jun 1998 17:55:47 -0400
To: [email-masked]
From: Tim Polk <[email-masked]>
Subject: Proposed Resolution of Comments (LONG!)
Sender: [email-masked]

Folks,

In a case of very bad timing, I will be out of the office for the second
week of Last Call.  (My family frowned on canceling vacation.)  As a
result, I am posting my attempt at "resolution of comments" to the list
before I go...

Given the various and conflicting opinions, not one will be particularly
pleased with the changes (including me!)  This is standards, folks!  The
question should be "Can I live with this?", not "Is it exactly what I
want?"  It's Last Call, and we'll all have to compromise.  If you get a
funny feeling in the pit of your stomach, but don't actually become
nauseous, then I've hit the happy medium.

(Sorry.  I get cranky when I work on Saturdays.)

>> Abbreviated Highlights

There are five sections that I have modified.

4.1.2.4 Issuer

I added a Dec. 31, 2003 cutover to UTF8.  Exceptions: name rollover certs
and CA certificates issued to (non-compliant) CAs.

Until then:  CAs can always choose UTF8 encoding for names; otherwise use
the smallest of {PrintableString, BMPString} that includes the required
characters.

Implementations are encouraged to handle Latin1String characters in
TeletexString for backward compatability.

The domainComponent attribute, as defined in [RFC 2247], has been added
to the set of naming attributes that implementations should handle.

Implementation of the ISO name comparison rules is explicitly permitted
as an alternative to the specified algorithm.

4.1.2.6 Subject

The domainComponent attribute, as defined in [RFC 2247], has been added
to the set of naming attributes that implementations should handle.

4.2.1.2  Subject Key Identifier

In a move sure to please no one, I added a second key generation
technique (the whole SHA-1 hash) to the mix.  The idea with the 4-bit
type was to accomodate other key id generation algorithms over time.  Why
wait?  Let's define two up front.

The profile does not require any particular algorithm for generating
subject key identifiers! It describes one or two algorithms that would
have the desired properties - low collisions.  I personally think 60 bits
will do, but if a CA wants more confidence, use the whole hash. 

4.2.1.11 Name Constraints

A paragraph has been added stating that the name comparison rules from
4.1.2.4 apply here as well.

10 Security Considerations

Three paragraphs have been added at the end of the section to describe
all the bad things that happen when a CA assumes ISO-style DN comparison
but implementations use binary matching instead.

I also added one section:

7.3.4 KEA keys 

KEA was a classified algorithm, so we could not include it in a standards
track document. This text existed as a separate document intended for
Informational RFC status. Since the KEA algorithm has been declassified,
it makes sense to merge the two documents. (BTW, if you are interested
see the URL

	 http://csrc.nist.gov/encryption/skipjack-kea.htm

for the specifications for KEA and Skipjack, which was also
declassified.)

There is no new information in this section. I just cut the meat out of
the KEA draft and pasted into the profile.

Sorry to be so brief, but I'm out of time.  See you in a week.

Tim Polk

>>  Proposed "Resolution" Of Comments

<bigger>

4.1.2.4  Issuer

   The issuer field identifies the entity who has signed and issued the

   certificate.  The issuer field shall contain a non-null 
distinguished

   name (DN).  The issuer field is defined as the X.501 type Name.  
Name

   is defined by the following ASN.1 structures:

   Name ::= CHOICE {

     RDNSequence }

   RDNSequence ::= SEQUENCE OF RelativeDistinguishedName

   RelativeDistinguishedName ::=

     SET OF AttributeTypeAndValue

   AttributeTypeAndValue ::= SEQUENCE {

     type     AttributeType,

     value    AttributeValue }

   AttributeType ::= OBJECT IDENTIFIER

   AttributeValue ::= ANY DEFINED BY AttributeType

   DirectoryString ::= CHOICE {

         teletexString           TeletexString (SIZE (1..MAX)),

         printableString         PrintableString (SIZE (1..MAX)),

         universalString         UniversalString (SIZE (1..MAX)),

         utf8String              UTF8String (SIZE (1.. MAX)),

         bmpString               BMPString (SIZE (1..MAX)) }

   The Name describes a hierarchical name composed of attributes, such

   as country name, and corresponding values, such as US.  The type of

   the component AttributeValue is determined by the AttributeType; in

   general it will be a DirectoryString.

   The DirectoryString type is defined as a choice of PrintableString,

   TeletexString, BMPString UTF8String and UniversalString.  The

   UTF8String encoding is the preferred encoding in the IETF, and all

   certificates issued after Dec. 31, 2003 must use the UTF8String

   encoding of DirectoryString (except as noted below).  Until that

   date, conforming CAs shall choose from the following options when

   creating a distinguished name, including their own:

      (a) if the character set is sufficient, the string may be

      represented as a PrintableString;

      (b) failing (a), if the BMPString character set is sufficient the

      string may be represented as a BMPString; and

      (c) failing (a) and (b), the string shall be represented as a

      UTF8String.  If (a) or (b) is satisified, the CA may still choose

      to represent the string as a UTF8String.

   Exceptions to the Dec. 31, 2003 UTF8 encoding requirements are as

   follows:

      (a) CAs may issue "name rollover" certificates to support an ord-

      erly migration to UTF8 encoding.  Such certificates would include

      the CA's UTF8 encoded name as issuer and and the old name 
encoding

      as subject, or vice-versa.

      (b) As stated in section 4.1.2.6, the subject field must be popu-

      lated with a non-null distinguished name matching the contents of

      the issuer field in all certificates issued by the subject CA

      regardless of encoding.

   The TeletexString and UniversalString are included for backward com-

   patibility, and should not be used for certificates for new 
subjects.

   However, these types may be used in certificates where the name was

   previously established.  Certificate users should be prepared to

   receive certificates with these string types.

   In addition, many legacy implementations support strings encoded in

   the ISO 8859-1 character set (Latin1String) but tag them as Teletex-

   String.  The Latin1String includes many of the characters used in

   Western European countries which are omitted by TeletexString.

   Implementations that wish to display TeletexString should be 
prepared

   to handle the entire ISO 8859-1 character set.

   Standard sets of attributes have been defined in the X.500 series of

   specifications.  This specification recommends that issuer names 
con-

   tain only the following attribute types: country, organization,

   organizational-unit, distinguished name qualifier, title, locality,

   state or province name, common name (e.g., "Susan Housley"), 
surname,

   given name, initials, and generationqualifier (e.g., "Jr." or "IV").

   The syntax and associated object identifiers (OIDs) for these attri-

   bute types are provided in the ASN.1 modules in Appendices A and B.

   In addition, implementations of this specification should be 
prepared

   to receive the domainComponent attribute, as defined in [RFC 2247].

   The Domain (Nameserver) System (DNS) provides a hierarchical 
resource

   labeling system.  This attribute provides is a convenient mechanism

   for organizations that wish to use DNs that parallel their DNS 
names.

   (This is not a replacement for the dNSName component of the alterna-

   tive name field. Implementations are not required to convert such

   names into DNS names.) The syntax and associated object identifiers

   (OIDs) for this attribute type is provided in the ASN.1 modules in

   Appendices A and B.

   Certificate users must be prepared to process the issuer dis-

   tinguished name and subject distinguished name (see sec. 4.1.2.6)

   fields to perform name chaining for certification path validation

   (see section 6). Name chaining is performed by matching the issuer

   distinguished name in one certificate with the subject name in

   another.

   This specification requires only a subset of the name comparison

   functionality specified in X.501. The requirements for conforming

   implementations are as follows:

      (a) attribute values encoded in different string types (e.g.,

      PrintableString and BMPString) may be assumed to represent dif-

      ferent strings;

      (b) attribute values in string types other than PrintableString

      are case sensitive (this permits matching of attribute values as

      binary objects);

      (c) attribute values in PrintableString are not case sensitive

      (e.g., "Marianne Swanson" is the same as "MARIANNE SWANSON"); and

      (d) attribute values in PrintableString are compared after remov-

      ing leading and trailing white space and converting internal

      strings of one or more consecutive white space characters to a

      single space.

   These name comparison rules permit a certificate user to validate

   certificates issued using languages or encodings unfamiliar to the

   certificate user.

   Note that the ISO rules of DN comparison indicate that the character

   sets used to encode data in DNs are irrelevant.  The characters 
them-

   selves must be compared without regard to encoding.  Implementations

   of the profile are permitted to use the ISO DN comparison algorithm.

   Such an implementation will recognize a superset of name matches

   recognized by the algorithm specified above.

4.1.2.6  Subject

   The subject field identifies the entity associated with the public

   key stored in the subject public key field.  The subject name may be

   carried in the subject field and/or the subjectAltName extension.  
If

   the subject is a CA (e.g., the basic constraints extension, as dis-

   cussed in 4.2.1.10, is present and the value of cA is TRUE,) then 
the

   subject field must be populated with a non-null distinguished name

   matching the contents of the issuer field (see sec. 4.1.2.4) in all

   certificates issued by the subject CA.  If subject naming 
information

   is present only in the subjectAltName extension (e.g., a key bound

   only to an email address or URI), then the subject name must be an

   empty sequence and the subjectAltName extension must be critical.

   Where it is non-empty, the subject field shall contain an X.500 dis-

   tinguished name (DN). The DN must be unique for each subject entity

   certified by the one CA as defined by the issuer name field. (A CA

   may issue more than one certificate with the same DN to the same 
sub-

   ject entity.)

   The subject name field is defined as the X.501 type Name, and shall

   follow the encoding rules for the issuer name field (see sec.

   4.1.2.4). When encoding strings as the type PrintableString, 
conform-

   ing CAs should use mixed case but should not include leading or

   trailing white space and should limit internal white space to sub-

   strings of a single space.

   Implementations of this specification should be prepared to receive

   the following X.501 attribute types: country, organization,

   organizational-unit, distinguished name qualifier, title, locality,

   state or province name, common name (e.g., "Susan Housley"), 
surname,

   given name, initials, and generationqualifier (e.g., "Jr." or "IV").

   The syntax and associated object identifiers (OIDs) for these attri-

   bute types are provided in the ASN.1 modules in Appendices A and B.

   In addition, implementations of this specification should be 
prepared

   to receive the domainComponent attribute, as defined in [RFC 2247].

   The Domain (Nameserver) System (DNS) provides a hierarchical 
resource

   labeling system.  This attribute provides is a convenient mechanism

   for organizations that wish to use DNs that parallel their DNS 
names.

   (This is not a replacement for the dNSName component of the alterna-

   tive name field. Implementations are not required to convert such

   names into DNS names.) The syntax and associated object identifiers

   (OIDs) for this attribute type is provided in the ASN.1 modules in

   Appendices A and B.

   Legacy implementations exist where an RFC 822 name is embedded in 
the

   subject distinguished name as a PKCS #9 EmailAddress attribute [PKCS

   #9].  Conforming implementations generating new certificates with

   electronic mail addresses must use the rfc822Name in the subject

   alternative name field (see sec. 4.2.1.7) to describe such identi-

   ties.  Simultaneous inclusion of the EmailAddress attribute in the

   subject distinugished name to support legacy implementations is

   deprecated but permitted.

   The ASN.1 syntax for EmailAddress and the corresponding OID are sup-

   plied below.

   EmailAddress ::= IA5String

   pkcs-9 OBJECT IDENTIFIER ::=

          { iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) 9 }

   emailAddress OBJECT IDENTIFIER ::= { pkcs-9 1 }

4.2.1.2  Subject Key Identifier

   The subject key identifier extension provides a means of identifying

   the particular public key used in an application. This extension

   should be included in all certificates.

   To facilitate chain building, this extension MUST appear in all

   conforming CA certificates, that is, all certificates including the

   basic constraints extension (see sec. 4.2.1.10) where the value of 
cA

   is TRUE.  The value of the subject key identifier shall be the value

   placed in the key identifier field of the Authority Key Identifier

   extension (see sec. 4.2.1.1) of certificates issued by the subject 
of

   this certificate.

   Where a key identifier has not been previously established, this

   specification recommends the following method for generating 
keyIden-

   tifiers:  the keyIdentifier is composed of a four bit type field 
with

   the value 0100 followed by the least significant 60 bits of the 
SHA-1

   hash of the BIT STRING subjectPublicKey.

   Where a CA requires more than 60 bits in the keyIdentifier, the fol-

   lowing alternative is recommended:  the keyIdentifier is composed of

   a four bit type field with the value xxxx followed by the complete

   SHA-1 hash of the BIT STRING subjectPublicKey.

   This extension should be marked non-critical.

   id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::=  { id-ce 14 }

   SubjectKeyIdentifier ::= KeyIdentifier

4.2.1.11  Name Constraints

   The name constraints extension, which shall be used only in a CA 
cer-

   tificate, indicates a name space within which all subject names in

   subsequent certificates in a certification path must be located.

   Restrictions may apply to the subject distinguished name or subject

   alternative names.  Restrictions apply only when the specified name

   form is present. If no name of the type is in the certificate, the

   certificate is acceptable.

   Restrictions are defined in terms of permitted or excluded name sub-

   trees.  Any name matching a restriction in the excludedSubtrees 
field

   is invalid regardless of information appearing in the permittedSub-

   trees.  This extension must be critical.

   Within this profile, the minimum and maximum fields are not used 
with

   any name forms, thus minimum is always zero, and maximum is always

   absent.

   Restriction of DN name forms, the constraint shall be compared to

   DNs, the

   Restrictions for the rfc822 and uri name forms are all expressed in

   terms of strings with wild card matching.  An "*" is the wildcard

   character.

   For URIs, the constraint applies to the host part of the name.  
Exam-

   ples would be foo.bar.com; www*.bar.com; and *.xyz.com.  When a 
wild-

   card appears as the leftmost subdomain, it may be matched with one 
or

   more subdomains.  That is, the constraint "*.xyz.com" is satisfied 
by

   both abc.xyz.com and abc.def.xyz.com.  However, the constraint

   "*.xyz.com" is not satisfied by "xyz.com". Otherwise, the wildcard

   may only be expanded within a single subdomain. That is, 
www*.bar.com

   is satisfied by www1.bar.com but not www.foo.bar.com.

   To indicate all Internet mail addresses on a particular host, the 
"*"

   character is used. For example, "[email-masked]" indicates all mail

   addresses at the host "xyz.com". Note that although "*" is a valid

   character in Internet mail addresses, it is very rarely used on the

   Internet, and thus is appropriated by this specification for the

   email wildcard.

   Internet mail addresses may also be constrained by the host part of

   the name, as with URIs.  For example, "root@*.xyz.com" indicates all

   the Internet mail addresses root in the domain "xyz.com".  As above,

   "*" is a valid character in the host part of the name, but it is 
very

   rarely used on the Internet, and thus is appropriated by this 
specif-

   ication for the mail address wildcard.

   To indicate all Internet mail addresses in a particular domain, 
these

   mechanisms may be combined.  For example, "*@*.xyz.com" indicates 
all

   email addresses in the domain "xyz.com".

   DNS name restrictions are expressed as foo.bar.com. Any DNS name 
that

   can be constructed by simply adding to the left hand side of the 
name

   satisfies the name constraint. For example, www.foo.bar.com would

   satisfy the constraint but foo1.bar.com would not.

   Legacy implementations exist where an RFC 822 name is embedded in 
the

   subject distinguished name as a PKCS #9 e-mail attribute, which has

   the ASN.1 type EmailAddress [PKCS #9] (see sec. 4.1.2.6). When 
rfc822

   names are constrained, but the certificate does not include a 
subject

   alternative name, the rfc822 name constraint must be applied to PKCS

   #9 e-mail attributes in the subject distinguished name.  The ASN.1

   syntax for EmailAddress and the corresponding OID are supplied in

   4.1.2.6.

   Restrictions of the form directoryName shall be applied to the sub-

   ject field in the certificate and to the subjectAltName extensions 
of

   type directoryName. Restrictions of the form x400Address shall be

   applied to subjectAltName extensions of type x400Address.

   When applying restrictions of the form directoryName, an implementa-

   tion must compare DN attributes.  At a minimum, implementations 
shall

   perform the DN comparison rules specified in Section 4.1.2.4.  CAs

   issuing certificates with a restriction of the form directoryName

   should not rely on implementation of the full ISO DN name comparison

   algorithm.  This implies name restrictions must be stated 
identically

   to the encoding used in the subject field or subjectAltName exten-

   sion.

   The syntax of iPAddress shall be as described in section 4.2.1.7 
with

   the following additions specifically for Name Constraints.  For IPv4

   addresses, the ipAddress field of generalName shall contain eight 
(8)

   octets, encoded in the style of RFC 1519 (CIDR) to represent an

   address range.  For IPv6 addresses, the ipAddress field shall 
contain

   32 octets similarly encoded.  For example, a name constraint for

   "class C" subnet 10.9.8.0 shall be represented as the octets 0A 09 
08

   00 FF FF FF 00, representing the CIDR notation

   10.9.8.0/255.255.255.0.

   The syntax and semantics for name constraints for otherName,

   ediPartyName, and registeredID are not defined by this 
specification.

      id-ce-nameConstraints OBJECT IDENTIFIER ::=  { id-ce 30 }

      NameConstraints ::= SEQUENCE {

           permittedSubtrees       [0]     GeneralSubtrees OPTIONAL,

           excludedSubtrees        [1]     GeneralSubtrees OPTIONAL }

      GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree

      GeneralSubtree ::= SEQUENCE {

           base                    GeneralName,

           minimum         [0]     BaseDistance DEFAULT 0,

           maximum         [1]     BaseDistance OPTIONAL }

      BaseDistance ::= INTEGER (0..MAX)

7.3.4 KEA Keys

   The Key Exchange Algorithm (KEA) is an algorithm for exchanging

   keys[KEA].  A KEA "pairwise key" may be generated between two users

   if their KEA public keys were generated with the same KEA 
parameters.

   The KEA parameters are not included in a certificate; instead a

   "domain identifier" is supplied in the parameters field.

   When the subjectPublicKeyInfo field contains a KEA key, the 
algorithm

   identifier and parameters shall be as defined in [sdn.701r]:

      id-keyExchangeAlgorithm  OBJECT IDENTIFIER   ::=

             { 2 16 840 1 101 2 1 1 22 }

      KEA-Parms-Id     ::= OCTET STRING

   CAs shall populate the parameters field of the AlgorithmIdentifier

   within the subjectPublicKeyInfo field of each certificate containing

   a KEA public key with an 80-bit parameter identifier (OCTET STRING),

   also known as the domain identifier. The domain identifier will be

   computed in three steps: (1) the KEA parameters are DER encoded 
using

   the Dss-Parms structure (see Section 7.3.3); (2) a 160-bit SHA-1 
hash

   is generated from the parameters; and (3) the 160-bit hash is 
reduced

   to 80-bits by performing an "exclusive or" of the 80 high order bits

   with the 80 low order bits.  The resulting value is encoded such 
that

   the most significant byte of the 80-bit value is the first octet in

   the octet string.

   A KEA public key, y, is conveyed in the subjectPublicKey BIT STRING

   such that the most significant bit (MSB) of y becomes the MSB of the

   BIT STRING value field and the least significant bit (LSB) of y

   becomes the LSB of the BIT STRING value field.  This results in the

   following encoding: BIT STRING tag, BIT STRING length, 0 (indicating

   that there are zero unused bits in the final octet of y), BIT STRING

   value field including y.

   The key usage extension may optionally appear in a KEA certificate.

   If a KEA certificate includes the keyUsage extension, only the fol-

   lowing values may be asserted:  keyAgreement; encipherOnly; and 
deci-

   pherOnly.

   The encipherOnly and decipherOnly values may only be asserted if the

   keyAgreement value is also asserted.  At most one of encipherOnly 
and

   decipherOnly shall be asserted in keyUsage extension

10  Security Considerations

   The majority of this specification is devoted to the format and con-

   tent of certificates and CRLs.  Since certificates and CRLs are 
digi-

   tally signed, no additional integrity service is necessary. Neither

   certificates nor CRLs need be kept secret, and unrestricted and

   anonymous access to certificates and CRLs has no security implica-

   tions.

   However, security factors outside the scope of this specification

   will affect the assurance provided to certificate users.  This sec-

   tion highlights critical issues that should be considered by imple-

   mentors, administrators, and users.

   The procedures performed by CAs and RAs to validate the binding of

   the subject's identity of their public key greatly affect the

   assurance that should be placed in the certificate.  Relying parties

   may wish to review the CA's certificate practice statement.  This 
may

   be particularly important when issuing certificates to other CAs.

   The use of a single key pair for both signature and other purposes 
is

   strongly discouraged. Use of separate key pairs for signature and 
key

   management provides several benefits to the users. The ramifications

   associated with loss or disclosure of a signature key are different

   from loss or disclosure of a key management key. Using separate key

   pairs permits a balanced and flexible response.  Similarly, 
different

   validity periods or key lengths for each key pair may be appropriate

   in some application environments. Unfortunately, some legacy 
applica-

   tions (e.g., SSL) use a single key pair for signature and key 
manage-

   ment.

   The protection afforded private keys is a critical factor in main-

   taining security.  On a small scale, failure of users to protect

   their private keys will permit an attacker to masquerade as them, or

   decrypt their personal information. On a larger scale, compromise of

   a CA's private signing key may have a catastrophic effect.  If an

   attacker obtains the private key unnoticed, the attacker may issue

   bogus certificates and CRLs.  Existence of bogus certificates and

   CRLs will undermine confidence in the system. If the compromise is

   detected, all certificates issued to the CA must be revoked, 
prevent-

   ing services between its users and users of other CAs. Rebuilding

   after such a compromise will be problematic, so CAs are advised to

   implement a combination of strong technical measures (e.g., tamper-

   resistant cryptographic modules) and appropriate management pro-

   cedures (e.g., separation of duties) to avoid such an incident.

   Loss of a CA's private signing key may also be problematic.  The CA

   would not be able to produce CRLs or perform normal key rollover.

   CAs are advised to maintain secure backup for signing keys.  The

   security of the key backup procedures is a critical factor in avoid-

   ing key compromise.

   The availability and freshness of revocation information will affect

   the degree of assurance that should be placed in a certificate.

   While certificates expire naturally, events may occur during its

   natural lifetime which negate the binding between the subject and

   public key.  If revocation information is untimely or unavailable,

   the assurance associated with the binding is clearly reduced.  Simi-

   larly, implementations of the Path Validation mechanism described in

   section 6 that omit revocation checking provide less assurance than

   those that support it.

   The path validation algorithm depends on the certain knowledge of 
the

   public keys (and other information) about one or more trusted CAs.

   The decision to trust a CA is an important decision as it ultimately

   determines the trust afforded a certificate. The authenticated dis-

   tribution of trusted CA public keys (usually in the form of a "self-

   signed" certificate) is a security critical out of band process that

   is beyond the scope of this specification.

   In addition, where a key compromise or CA failure occurs for a

   trusted CA, the user will need to modify the information provided to

   the path validation routine.  Selection of too many trusted CAs will

   make the trusted CA information difficult to maintain.  On the other

   hand, selection of only one trusted CA may limit users to a closed

   community of users until a global PKI emerges.

   The quality of implementations that process certificates may also

   affect the degree of assurance provided.  The path validation algo-

   rithm described in section 6 relies upon the integrity of the 
trusted

   CA information, and especially the integrity of the public keys 
asso-

   ciated with the trusted CAs.  By substituting public keys for which

   an attacker has the private key, an attacker could trick the user

   into accepting false certificates.

   The binding between a key and certificate subject cannot be stronger

   than the cryptographic module implementation and algorithms used to

   generate the signature.  Short key lengths or weak hash algorithms

   will limit the utility of a certificate.  CAs are encouraged to note

   advances in cryptology so they can employ strong cryptographic tech-

   niques.  In addition, CAs should decline to issue certificates to 
CAs

   or end entities that generate weak signatures.

   Finally, inconsistent application of name comparison rules may 
result

   in acceptance of invalid X.509 certification paths, or rejection of

   valid ones.  The ISO rules for comparing distinguished names require

   comparison of strings without regard to case, character set, multi-

   character white space sequences, or leading and trailing white 
space.

   This specification relaxes these requirements, requiring support for

   binary comparison at a minimum.

   CAs must encode the subject DN of a CA certificate identically to 
the

   issuer DN in certificates issued by the latter CA.  If CAs use dif-

   ferent encodings, implementations of this specification may fail to

   recognize name chains for paths that include this certificate.  As a

   consequence, valid paths could be rejected.

   In addition, name constraints for DNs must be stated identically to

   the encoding used in the subject field or subjectAltName extension.

   If not, (1) name constraints stated as excludedSubTrees will not

   match and invalid paths will be accepted and (2) name constraints

   expressed as permittedSubtrees will not match and valid paths will 
be

   rejected.  To avoid acceptance of invalid paths, CAs should state

   name constraints for DNs as permittedSubtrees whereever possible.

</bigger>

Date: Fri, 26 Jun 1998 15:20:02 -0400
To: Nada Kapidzic Cicovic <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: SV: new profile submitted
Cc: Paul Hoffman / IMC <[email-masked]>, [email-masked]
Sender: [email-masked]

As stated on the list, the is for alignment with US Government, ANSI, and
Draft ISO TC68 documents.

Russ

At 12:08 PM 6/24/98 +0200, Nada Kapidzic Cicovic wrote:
>I do not understand the point of changing the key id calculation algorithm
>this late in pkix part 1 last call. 
>
>Is the size of the resulting key id the only problem with the old algorithm
>definition?
>
>Is this size really an issue for S/MIME messages?
>
>I would prefer changing the definition back to what it was, since we have
>already released the software implementing it in the old way, and we are
>probably not the only one.
>
>Regards,
>
>Nada
>
>
>At 20:55 6/23/98 -0400, Russ Housley wrote:
>>The PKIX Part 1 key identifier will be used in S/MIME to identify the
>>per-recipient information necessary for a recipient to perform decryption.
>>As stated in a previous message, collisions are not a problem here.
>>However, this key identifier will not be used to identify a particular
>>certificate used by an originator to sign a message content.  Collisions
>>could cause significant confusion in this circumstance.
>>
>>Russ
>>
>>
>>At 12:11 PM 6/23/98 -0700, Paul Hoffman / IMC wrote:
>>>I think the question here is whether or not it is useful to have the same
>>>key identifier for both PKIX part 1 and OCSP. If it is, then we need to
>>>choose one that works for both. Ambarish says that 60 bits, with the
>>>possibility of collision, is not strong enough for OCSP. If that's true, we
>>>need to decide if the two key identifiers have to be the same, or whether
>>>we can use a shorter one for PKIX part 1 and a longer one for OCSP.
>>>
>>>--Paul Hoffman, Director
>>>--Internet Mail Consortium
>>> 
>>
> 

Date: Fri, 26 Jun 1998 15:56:23 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: Last Call - Profile
Cc: [email-masked]
Sender: [email-masked]

Anne:

Thanks for your comments.  Let me repond to each.

>Objection 1: PKIX should not mandate use of X501 names for chaining.
>Not all PKI's store certificate information in an X500 directory.

I agree that X.500 Directory deployment will not be ubiqutious for many
years to come.  That is why I wrote the Internet-Draft dealing with the
distribuion of Certificates and CRLs using FTP and HTTP.

The use of X.501 names does not imply the existance of a Directory.  This
name format can be used without deploying a Directory.

S/MIME (and other protocols) as well as CRL entries identify certificates
by the combination of the issuer Distinguished Name and Serial Number.
This is the reaon that the population of the Issuer filed with a non-empty
name is important.

>Objection 2: If PKIX does mandate X501 names for chaining, then the
>RFC2247 "DC=" attribute should be added to the list of recommended
>name attributes to be used in section 4.1.2.4.

I have no objection to the inclusion of the "DC=" attribute as a name
component.

>Objection 3: If the intent is indeed to mandate use of X501 names for
>chaining, section 4.1.2.6 "Subject" is ambiguous with respect to this mandate
>and section 6.1 "Basic Path Validation" contradicts this mandate.  Locations
>and suggested changes follow.

Names can be used for path development.  However, the SubjectKeyIdentifier
and AuthorityKeyIdentifer extensions can also be used for path development.

Once the path is developed, the path validation includes the checking of
the parent subject name and the child issuer name at each link in the path.

Russ

Date: Fri, 26 Jun 1998 15:26:19 -0400
To: Harald Alvestrand <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: PKIX-1 - use of UTF8
Cc: [email-masked]
Sender: [email-masked]

All:

>>In the following, I'm going to call a system that implements the current
>>PKIX-1 rules an "Old" system, and one that emits certificates in UTF-8 a
>>"New" system (under the assumption that UTF-8 is where we'd like to get
>>to).  Similarly, "Old Certificates" contain names using the current PKIX-1
>>codeset selection rules, and "New Certificates" use UTF-8.
>
>You are making the assumption here that the same codeset is used for
>all attributes of all names within a certificate.
>Is this a requirement of the infrastructure?

We must have a solution that permits different codesets for each attribute
in a name.

I am reluctant to support the incorrect tagging of things as T.61 that in
fact are not T.61.

Can folks live with the following:
1.  Country must be represented in PrintableString.
2.  Other name components are represented using either 2a or 2b.
2a.  If can be represented at PrintableString, do so; otherwise use BMPString.
2b.  Represent as UTF8String.

Russ

From: Nilsson Hans <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: SV: Last Call - Profile
Date: Sat, 27 Jun 1998 08:32:26 +0100
Sender: [email-masked]

Peter,

As you suspected, the Swedish SEIS specifications, also used in Finland,
requires Givenname and Surname in the subject name. In addition, the CA may
anything it wants according to the specification, and the CA product
currently being used allows for input of Title and CommonName.

I think we want to stick with that, and not treat the whole name as one
blob. For example, you want to search for also persons with the Surname =
"Nilsson" without knowing the Givenname. Also, different countries have
different conventions for forming a Commonname from (Givenname, Surname).

Hans

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Last Call - Profile
Reply-To: [email-masked]
Date: Sat, 27 Jun 1998 15:51:04 (NZST)
Sender: [email-masked]

>>  Standard sets of attributes have been defined in the X.500 series of
>>  specifications.  This specification recommends that issuer names con-
>>  tain only the following attribute types: country, organization,
>>  organizational-unit, distinguished name qualifier, title, locality,
>>  state or province name, common name (e.g., "Susan Housley"), surname,
>>  given name, initials, and generationqualifier (e.g., "Jr." or "IV").
>>  The syntax and associated object identifiers (OIDs) for these attri-
>>  bute types are provided in the ASN.1 modules in Appendices A and B.
>>
>>[Insert: "domain component (i.e. RFC2247)" in the list of recommended
>>name attributes.]
 
The addition of name detritus looks like a late change in the most recent draft
(I can't find it in the previous drafts).  I think this is a bad move, because
all it does is add unnecessary confusion and complication without providing any
noticeable benefit (by "name detritus" I mean DN qualifier, title, surname,
given name, initials, generationqualifier, hair colour,
distinguishingmarksorfeatures, and God knows what else).
 
Currently almost all certs in existence use C, O, OU, L, SP, and CN.  I've
never seen any use of name detritus, so when making a change like this you need
to look at two issues:
 
  1. What benefits does this change bring?
  2. What drawbacks does this change have?
 
I can't see any benefits at all, since everything you can specify as name
detritus, as far as anyone not versed in X.500 theology is concerned (and that
covers 99.999% of the user base) is already possible in a DN.
 
As for the drawbacks, forcing people to break up names into their component
atoms and scattering them across half a dozen attributes will cause nothing but
confusion - give 20 different non-X.500-theologists the listed selection of
attributes and you'll get 20 different interpretations of how to use them, and
this doesn't even touch on the problems which are caused by the mostly US (or
at least north-american)-specific nature of the name detritus.  How this will
fly in localities where you may or may not be committing a mortal offence by
ommitting "Herr Doktor Professor" as a title, or where the concept of a
"surname" and "given name" (and other bits and pieces) are very mutable, or
where everyone is called Singh or (to a lesser extent) Kim, or where you have a
multitude of names and use different ones in different circumstances, or ...
(can anyone here outline the Swedish(?) use of situational names to give list
members an example of this problem?  I can remember partial details of how they
work, but it's been awhile since I read about them).
 
As far as I can see this change has no benefit at all (I can't see any
identifiable problem which it fixes), but has the potential to cause endless
complications once you move outside north american (and common european) naming
conventions.  CN's have worked fine so far, I can't see any reason to replace
them.
 
>Anne's note jogged my memory in this area.  One of the major problems with
>"locality" is that the semantics are exceptionally poorly defined in X.521.
>Is it a city or town, a real estate subdivision within a town, a county, the
>Washington Metropolitan Area, Europe, the Internet, the solar system, or what?
>What purpose is it intended to serve?
 
>In particular, does it serve as a reasonable name qualifier for the sake of
>uniqueness?  Does it serve as a geographical or geopolitical region that is
>sufficiently small that I might actually be able to find someone there? Is it
>a substitute for stateOrProvince, for those countries that don't have states,
>cantons, territories, parishes, etc., etc.?
 
[...]
 
>But while locality is so poorly defined as to be nearly useless, the list also
>omits the obviously necessary qualifier of streetAddress or postAddress, in
>addition to what I believe is Anne's concern, the need for cyberspace
>addresses, either in place of or in addition to physical addresses.
 
I think locality is another item which has been proven in the field to work
fine, and for which there's no need for change.  Sure, it's only vaguely
defined, but I've never seen anyone who has any problems with it.  A loose
definition of "locality" (as far as the rest of the world is concerned) is "the
bit of your address which appears just before your state or province, or before
your country if you don't have states or provinces".  Going to my cert
menagerie, I can't see any instances of people having problems with this - it
may not be what the ITU intended, but everyone who uses it seems to be able to
set "locality" to a sensible value.
 
[Looking through the menagerie, which represents certs harvested from all over
 the world, I can't find a single use of a DN attribute which isn't in the list
 {C, O, OU, L, SP, and CN}.  Like BMPStrings, there may be billions of
 potential possibilities there, but noone seems to feel any need for them]
 
Taking the menagerie as being representative of current usage, I would suggest
that PKIX recommend the traditional C, O, OU, L, SP, and CN, and mention that
others are possible but not recommended (a lot of commonly-used software won't
be able to do much with anything else - the last I saw, the likes of MSIE and
IIS only allowed the attributes listed above when you generated a cert request,
and I don't recall Netscape allowing much else either, although it's been
awhile since I looked at it).  If it ain't broken, I don't see any compelling
reason to try to "fix" it.
 
Peter.

Date: Fri, 26 Jun 1998 16:03:40 -0600
From: Mike Smith <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Cc: [email-masked]
Subject: Re: New OCSP draft
Sender: [email-masked]

Ambarish:

Your comments raised/revitalized some thoughts on two topics that I would like to address:  Revocation/Chain validation and Risk/Trust.

Actually, there should be a chain of revocation down from the cert being revoked if a CA.  A CA cert being expired or revoked should cause a system to revoke all certs issued under that CA cert, including all cross-refenced/cross certified certs.  Naturally, the revocation in lateral  chains of CAs in a cross-certification schema becomes quite complex, and needs to rely on the integrity of all CAs in that web of trust to operate seemlessly across each other's ARL, CRL, CKL or whatever lists they use to indicate revocation, suspension or compromise according to their rules.

Then, of course, the problem always exists for the CA that may have been cross-certified into other trust hierarchies (policy mapped, even) that decides to simply abandon its CA business - how does one and when does one check their cross-certified CAs' actual existence or status?

Anyway, these are observations I've made in the past to some on this list, and some of the reasons that cause us in the banking community to look at building trusted PKI based on our business relationships, not on a new trust model where we do not know with whom we are doing business without someone we do have a business relationship backing up the third party's claim of identity (and indemnifying us from their errors).  The PKI trust models can reflect the trust models banks have used successfully for the last couple centuries and these new models will probably have more success and wider acceptance if they build on existing trust models, rather than new, untrusted models of trust.  

The mechanics of the PKI structures we are all working on in the IETF are very important and can be adapted to fit within many trust models, including those already in place in businesses, governments and financial institutions, as well as in a new paradigm of technologically sophisticated trust models.  Building standards to meet such diverse implementation goals can lead to different groups trying to build in trust technologically to try and outwit those that would use such systems in no-risk-assumed, no trust needed environments.  I mean, would anyone expect a bank to honor a self-authenticated (maybe even self issued) cert from a company or individual unless there 

I do believe that the market will be divided into the no-risk-assumed and risk-assumed models, with the risk-assumed models being used in business and government systems, and the no-risk-assumed models used more for social context systems.

Michael

Michael

>>> Dan Geer <[email-masked]> 06/26 3:05 PM >>>

the physics of revocation include two perverse rules

1. all revocations are retroactive

2. the cost of revocation checking increases with the distance
   the entity is from the root yet the value of the check decreases
   with that same distance

so at some scale of hierarchy, you will have to overcome the
costs of hierarchy (such as by wildcarding and/or processing
a validity check top down only so far as you care to bother)
or you will have to treat this all as an exercise in buying
and selling risk

--dan

To: [email-masked], [email-masked]
Cc: IETF PKIX <[email-masked]>
Subject: Re: New OCSP draft 
Date: Fri, 26 Jun 1998 17:05:22 -0400
From: Dan Geer <[email-masked]>
Sender: [email-masked]

the physics of revocation include two perverse rules

1. all revocations are retroactive

2. the cost of revocation checking increases with the distance
   the entity is from the root yet the value of the check decreases
   with that same distance

so at some scale of hierarchy, you will have to overcome the
costs of hierarchy (such as by wildcarding and/or processing
a validity check top down only so far as you care to bother)
or you will have to treat this all as an exercise in buying
and selling risk

--dan

Date: Fri, 26 Jun 1998 11:24:18 -0700
From: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
To: Irene Gassko <[email-masked]>
CC: IETF PKIX <[email-masked]>
Subject: Re: New OCSP draft
Sender: [email-masked]

Hi Irene,
    I am not sure you actually want to distinugish between the cases
where a cert was issued before/after the CA's key was compromised.

You need to know whether you can trust the cert or not. If any
cert in the chain from that cert to a trusted root is revoked, you
can't trust that cert (unless you can create another path that can
be trusted), independent of when that cert was issued.

Did you have a situation where you are willing to trust a cert
even though the CA that issued the cert had its key compromised?

Regards,
Ambarish

Irene Gassko wrote:
> 
> At 10:33 AM 6/26/98 -0700, Ambarish Malpani wrote:
> >Hi Irene,
> >    OCSP returns the status of the certificate. If you are trying to
> >check a whole
> >chain, you should also query for the status of the CA of the
> >certificate, at
> >which point you will find out the the CA has been compromised.
> >
> >CA1 issues CA cert to CA2
> >CA2 issues regular cert to EU (end user)
> >
> >If CA2's key is compromised, then any application that only trusts
> >CA1 and is trying to verify the status of EU, should also, at the
> same
> >time, verify the status of CA2.
> >
> >Query { statusOf(EU), statusOf(CA2) }
> >Response { EU-notRevoked, CA2-revoked }
> 
> This is ambiguous, IMO. How do we distinguish two different cases:
> 
> 1. CA2 was revoked after the certificate was created (which for many
> applications will be fine).
> 2. CA2 was revoked before the certificate was created (which makes
> certificate useless, because it most probably was forged).
> 
> >
> >Would this solve the problem? I would prefer not trying to make
> >statements
> >about two different certs/levels of hierarchy at one time.
> 
> Agreed.
> 
> >
> >Regards,
> >Ambarish
> >
> >
> >Irene Gassko wrote:
> >>
> >> >> >3. CertStatus
> >> >> >I would really love to see the addition of notIssued to the
> list of
> >> >> >result codes. This would mean "I know about the CA and all the
> >> >> >certificates it has ever issued, but the certificate presented
> is *not*
> >> >> >on my list".
> >> >>
> >> >> This request has come up before.  The primary reason it's not in
> the
> >> >> list of result codes is that it seems unlikely an OCSP requester
> would
> >> >> be querying on a certificate it was not already handling and
> therefore
> >> >> had conclusive proof that the certificate was issued.
> >> >
> >> >
> >> If a CA key was revoked and a certificate a user is checking has
> been
> >> issued after  this revocation what status should be returned?
> Revoked
> >> does not look right - it is not in the CRL. Thus, notIssued seems
> one
> >> logical possibility.
> >>
> >> Irene

-- 
---------------------------------------------------------------------
Ambarish Malpani
Architect					       (650) 849-9880
ValiCert, Inc.				        [email-masked]
3160 W. Bayshore Road		              http://www.valicert.com
Palo Alto, CA 94303

Date: Fri, 26 Jun 1998 14:10:38 -0400
To: Michael Myers <[email-masked]>
From: Irene Gassko <[email-masked]>
Subject: Re: New OCSP draft
Cc: IETF PKIX <[email-masked]>
Sender: [email-masked]

At 09:34 AM 6/26/98 -0700, Michael Myers wrote:
>Irene,
>
>At 11:32 AM 6/26/98 -0400, Irene Gassko wrote:
>>
>>If a CA key was revoked and a certificate a user is checking has been 
>>issued after  this revocation what status should be returned? Revoked 
>>does not look right - it is not in the CRL. Thus, notIssued seems one 
>>logical possibility.
>
>
>Good catch.  It would be more appropriate however to add a cARevoked value
>to the RevokedInfo syntax of CertStatus.  This will ensure that the logic
>used to handle a "revoked" CertStatus is activated.  I would expect this
>logic to be more critical of accepting a certificate than that which might
>be written to handle notIssued.  This would be important in the event of
>compromised CA key.
>
>CertStatus ::= CHOICE {
>   notRevoked   [0]  IMPLICIT NULL,
>   revoked      [1]  IMPLICIT RevokedInfo,
>   unknown      [2]  IMPLICIT UnknownInfo }
>
>RevokedInfo ::= { . . . amend to provide a cARevoked reason code . . . }

I like this. I guess we need to provide enough info (e.g. which CA is
revoked) to enable the user to check when CA was revoked and why.
For example, if the key was compromised and the certificate was
created with this key after its revocation, we want to always reject
such a certificate. However, if the key was changed because an
employee left and someone purchased a certificate from him while
he still worked, this certificate may be perfectly legitimate.
>
>Mike
>
Irene
 
Irene Gassko                                     Bell Laboratories
Lucent Technologies                          Secure Technologies Dept.
300 Brickstone Square                       voice:   (978) 691-3270
6-th Floor                                          e-mail: [email-masked]
Andover, MA 01845                            fax:      (978) 691-3186

Cc: Andreas Berger <[email-masked]>, Michael Myers <[email-masked]>, IETF PKIX <[email-masked]>
Original-Cc: Andreas Berger <[email-masked]>, Michael Myers <[email-masked]>, IETF PKIX <[email-masked]>
Date: Fri, 26 Jun 1998 14:01:26 -0400
To: Ambarish Malpani <[email-masked]>
From: Irene Gassko <[email-masked]>
Subject: Re: New OCSP draft
Original-Cc: Andreas Berger <[email-masked]>, Michael Myers <[email-masked]>, IETF PKIX <[email-masked]>
Sender: [email-masked]

<html>
At 10:33 AM 6/26/98 -0700, Ambarish Malpani wrote:<br>
&gt;Hi Irene,<br>
&gt;=A0=A0=A0 OCSP returns the status of the certificate. If you are trying
to<br>
&gt;check a whole<br>
&gt;chain, you should also query for the status of the CA of the<br>
&gt;certificate, at<br>
&gt;which point you will find out the the CA has been compromised.<br>
&gt;<br>
&gt;CA1 issues CA cert to CA2<br>
&gt;CA2 issues regular cert to EU (end user)<br>
&gt;<br>
&gt;If CA2's key is compromised, then any application that only
trusts<br>
&gt;CA1 and is trying to verify the status of EU, should also, at the
same<br>
&gt;time, verify the status of CA2.<br>
&gt;<br>
&gt;Query { statusOf(EU), statusOf(CA2) }<br>
&gt;Response { EU-notRevoked, CA2-revoked }<br>
<br>
This is ambiguous, IMO. How do we distinguish two different cases:<br>
<br>
1. CA2 was revoked <b><i>after</i> </b>the certificate was created (which
for many<br>
applications will be fine).<br>
2. CA2 was revoked <b><i>before</b></i> the certificate was created
(which makes<br>
certificate useless, because it most probably was forged).<br>
<br>
&gt;<br>
&gt;Would this solve the problem? I would prefer not trying to make<br>
&gt;statements<br>
&gt;about two different certs/levels of hierarchy at one time.<br>
<br>
Agreed.<br>
<br>
&gt;<br>
&gt;Regards,<br>
&gt;Ambarish<br>
&gt;<br>
&gt;<br>
&gt;Irene Gassko wrote:<br>
&gt;&gt; <br>
&gt;&gt; &gt;&gt; &gt;3. CertStatus<br>
&gt;&gt; &gt;&gt; &gt;I would really love to see the addition of
notIssued to the list of<br>
&gt;&gt; &gt;&gt; &gt;result codes. This would mean &quot;I know about
the CA and all the<br>
&gt;&gt; &gt;&gt; &gt;certificates it has ever issued, but the
certificate presented is *not*<br>
&gt;&gt; &gt;&gt; &gt;on my list&quot;.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; This request has come up before.=A0 The primary reason
it's not in the<br>
&gt;&gt; &gt;&gt; list of result codes is that it seems unlikely an OCSP
requester would<br>
&gt;&gt; &gt;&gt; be querying on a certificate it was not already
handling and therefore<br>
&gt;&gt; &gt;&gt; had conclusive proof that the certificate was
issued.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; If a CA key was revoked and a certificate a user is checking has
been<br>
&gt;&gt; issued after=A0 this revocation what status should be returned?
Revoked<br>
&gt;&gt; does not look right - it is not in the CRL. Thus, notIssued
seems one<br>
&gt;&gt; logical possibility.<br>
&gt;&gt; <br>
&gt;&gt; Irene<br>
&gt;&gt; <br>
&gt;&gt; Irene Gassko=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Bell
Laboratories<br>
&gt;&gt; Lucent Technologies=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0 Secure Technologies
Dept.<br>
&gt;&gt; 300 Brickstone Square=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0 voice:=A0=A0 (978)
691-3270<br>
&gt;&gt; 6-th Floor=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 e-mail:
[email-masked]<br>
&gt;&gt; Andover, MA 01845=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 fax:=A0=A0=A0=A0=A0 (978)
691-3186<br>
&gt;<br>
&gt;-- <br>
&gt;---------------------------------------------------------------------<br=
>
&gt;Ambarish Malpani<br>
&gt;Architect     =A0=A0=A0=A0=A0=A0 (650) 849-9880<br>
&gt;ValiCert, Inc.    =A0=A0=A0=A0=A0=A0=A0 [email-masked]<br>
&gt;3160 W. Bayshore Road  =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
<a href=3D"http://www.valicert.com/"=
 eudora=3D"autourl">http://www.valicert.com</a><br>
&gt;Palo Alto, CA 94303<br>
&gt;=20
<BR>
<div>Irene
Gassko&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Bell Laboratories</div>
<div>Lucent
Technologies&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;
Secure Technologies Dept.</div>
<div>300 Brickstone
Square&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
voice:&nbsp;&nbsp; (978) 691-3270</div>
<div>6-th
Floor&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;
e-mail: [email-masked]</div>
Andover, MA
01845&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;
fax:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (978) 691-3186
</html>

Date: Fri, 26 Jun 1998 10:55:03 -0700
To: Paul Koning <[email-masked]>, [email-masked]
From: Tony Bartoletti <[email-masked]>
Subject: Re: Last Call - Profile (altName Chaining)
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

At 10:41 AM 6/26/98 -0400, Paul Koning wrote:
>
>So did we settle that alternate names CAN be used for chaining?  The
>outcome of that debate wasn't clear to me...

It was not clear to me either.  As I recall, arguments revolved
around (possibly) conflicted overloading of the poor and abused
critical extension bit.  Clarification is in order.

___tony___

Tony Bartoletti                                             LL
SPI-NET GURU                                             LL LL
Computer Security Technology Center                   LL LL LL
Lawrence Livermore National Lab                       LL LL LL
PO Box 808, L - 303                                   LL LL LLLLLLLL
Livermore, CA 94551-9900                              LL LLLLLLLL
email: [email-masked]   phone: 510-422-3881             LLLLLLLL

Date: Fri, 26 Jun 1998 10:46:41 -0700
From: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
To: Peter Sylvester <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: New OCSP draft
Sender: [email-masked]

Hi Peter, Andreas,

Peter Sylvester wrote:
> 
> > Problem is: I do not want to ask for the validity of a key, I have to
> > ask for the validity of a specific certificate, which is identified by
> > issuer and serial. Perhaps we could add:
> >
> >       serialNumber    CertificateSerialNumber OPTIONAL
> >       certificateHash CertificateHash         OPTIONAL
> >
> > Then we might need an additional response code: certificateHashRequried
> I can live with that.
> 
> Anyway, it seems to me that Certificatehash for identification is sufficient:
> - If ever there would be a duplicate, an issuer can easily avoid that
> - If ever there would be a duplicate, we probably have a problem with hashing?

Yes, the Certificatehash is sufficient for identifying a certificate,
however,
it assumes that an OCSP responder somehow has access to the hashes of
all
certificates issued by a CA. That is not necessarily true. It is quite
reasonable for an OCSP responder to be something that basically has
access to
the latest CRLs from certain CAs and that issues responses for those CAs
to
parties that trust that responder. Trying to identify certificates by
their
hashes would break that model.

Also, having a bunch of different ways of identifying a certificate will
either
make writing OCSP responders quite difficult, or result in a bunch of
non-interoperable implementations.

> 
> >
> > > I would like to propose another transport protocol:
> > > OCSP over UPD:
> > >
> > > The idea is to put an OCSP request into one UDP request.
> > > In order to identify results one need a sequence number. This
> > > can be done in the follonwg way: The UDP packet is filled using
> > > an sequence of an INTEGER containing the seuence number, the OCSPrequest.
> > > Similar for the response. (Where is my DNS and BIND handbook :-)
> >
> > Good idea, but we should mandate: SHOULD only be used in local
> > environments.
> 
> Why that?
>

I don't think I have a strong opinion on the UDP issue (I stopped using
it
when I found out about TCP :-)). If enough people in this group feel
that
UDP is important to support and if Peter is willing to write up
the UDP spec :-), we can put it in.

Regards,
Ambarish

-- 
---------------------------------------------------------------------
Ambarish Malpani
Architect					       (650) 849-9880
ValiCert, Inc.				        [email-masked]
3160 W. Bayshore Road		              http://www.valicert.com
Palo Alto, CA 94303

Date: Fri, 26 Jun 1998 10:33:39 -0700
From: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
To: Irene Gassko <[email-masked]>
CC: Andreas Berger <[email-masked]>, Michael Myers <[email-masked]>, IETF PKIX <[email-masked]>
Subject: Re: New OCSP draft
Sender: [email-masked]

Hi Irene,
    OCSP returns the status of the certificate. If you are trying to
check a whole
chain, you should also query for the status of the CA of the
certificate, at
which point you will find out the the CA has been compromised.

CA1 issues CA cert to CA2
CA2 issues regular cert to EU (end user)

If CA2's key is compromised, then any application that only trusts
CA1 and is trying to verify the status of EU, should also, at the same
time, verify the status of CA2.

Query { statusOf(EU), statusOf(CA2) }
Response { EU-notRevoked, CA2-revoked }

Would this solve the problem? I would prefer not trying to make
statements
about two different certs/levels of hierarchy at one time.

Regards,
Ambarish

Irene Gassko wrote:
> 
> >> >3. CertStatus
> >> >I would really love to see the addition of notIssued to the list of
> >> >result codes. This would mean "I know about the CA and all the
> >> >certificates it has ever issued, but the certificate presented is *not*
> >> >on my list".
> >>
> >> This request has come up before.  The primary reason it's not in the
> >> list of result codes is that it seems unlikely an OCSP requester would
> >> be querying on a certificate it was not already handling and therefore
> >> had conclusive proof that the certificate was issued.
> >
> >
> If a CA key was revoked and a certificate a user is checking has been
> issued after  this revocation what status should be returned? Revoked
> does not look right - it is not in the CRL. Thus, notIssued seems one
> logical possibility.
> 
> Irene
> 
> Irene Gassko                                     Bell Laboratories
> Lucent Technologies                          Secure Technologies Dept.
> 300 Brickstone Square                       voice:   (978) 691-3270
> 6-th Floor                                          e-mail: [email-masked]
> Andover, MA 01845                            fax:      (978) 691-3186

-- 
---------------------------------------------------------------------
Ambarish Malpani
Architect					       (650) 849-9880
ValiCert, Inc.				        [email-masked]
3160 W. Bayshore Road		              http://www.valicert.com
Palo Alto, CA 94303

Date: Fri, 26 Jun 1998 10:28:23 -0700
To: Paul Koning <[email-masked]>, [email-masked]
From: Tony Bartoletti <[email-masked]>
Subject: Re: Last Call - Profile
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

At 10:41 AM 6/26/98 -0400, Paul Koning wrote:
>>>>>> "Bob" == Bob Jueneman <[email-masked]> writes:
>
> Bob> Anne Anderson wrote:

[tony snips]

> >> Objection 2: If PKIX does mandate X501 names for chaining, then
> >> the RFC2247 "DC=" attribute should be added to the list of
> >> recommended name attributes to be used in section 4.1.2.4.
>
> Bob> I would have no objection to that, although personally I think
> Bob> that decomposing all of the domains into individual components
> Bob> is unnecessary. But if someone needs that ability, that's OK
> Bob> with me.
>
>So did we settle that alternate names CAN be used for chaining?  The
>outcome of that debate wasn't clear to me...  Because that's what you
>need for DNS names if you don't want to decompose them into DC pieces
>(right)?
>
>	paul

I don't believe that decomposition was a hard requirement.  An e-mail
or DNS name could be used as a "blob" DN component, but (twas argued)
this would make directory searches inefficient.  Listing DNS components
individually would lend itself to hierarchical structuring of directory 
searches.  (IMO, this is a marginal argument against "blob" DN entries.)

___tony___

Tony Bartoletti                                             LL
SPI-NET GURU                                             LL LL
Computer Security Technology Center                   LL LL LL
Lawrence Livermore National Lab                       LL LL LL
PO Box 808, L - 303                                   LL LL LLLLLLLL
Livermore, CA 94551-9900                              LL LLLLLLLL
email: [email-masked]   phone: 510-422-3881             LLLLLLLL

Date: Fri, 26 Jun 1998 09:34:08 -0700
To: Irene Gassko <[email-masked]>, Andreas Berger <[email-masked]>
From: Michael Myers <[email-masked]>
Subject: Re: New OCSP draft
Cc: Michael Myers <[email-masked]>, Ambarish Malpani <[email-masked]>, IETF PKIX <[email-masked]>
Sender: [email-masked]

Irene,

At 11:32 AM 6/26/98 -0400, Irene Gassko wrote:
>
>If a CA key was revoked and a certificate a user is checking has been 
>issued after  this revocation what status should be returned? Revoked 
>does not look right - it is not in the CRL. Thus, notIssued seems one 
>logical possibility.

Good catch.  It would be more appropriate however to add a cARevoked value
to the RevokedInfo syntax of CertStatus.  This will ensure that the logic
used to handle a "revoked" CertStatus is activated.  I would expect this
logic to be more critical of accepting a certificate than that which might
be written to handle notIssued.  This would be important in the event of
compromised CA key.

CertStatus ::= CHOICE {
   notRevoked   [0]  IMPLICIT NULL,
   revoked      [1]  IMPLICIT RevokedInfo,
   unknown      [2]  IMPLICIT UnknownInfo }

RevokedInfo ::= { . . . amend to provide a cARevoked reason code . . . }

Mike

Cc: Michael Myers <[email-masked]>, Ambarish Malpani <[email-masked]>, IETF PKIX <[email-masked]>
Original-Cc: Michael Myers <[email-masked]>, Ambarish Malpani <[email-masked]>, IETF PKIX <[email-masked]>
Date: Fri, 26 Jun 1998 11:32:25 -0400
To: Andreas Berger <[email-masked]>
From: Irene Gassko <[email-masked]>
Subject: Re: New OCSP draft
Original-Cc: Michael Myers <[email-masked]>, Ambarish Malpani <[email-masked]>, IETF PKIX <[email-masked]>
Sender: [email-masked]

>> >3. CertStatus
>> >I would really love to see the addition of notIssued to the list of
>> >result codes. This would mean "I know about the CA and all the
>> >certificates it has ever issued, but the certificate presented is *not*
>> >on my list".
>> 
>> This request has come up before.  The primary reason it's not in the
>> list of result codes is that it seems unlikely an OCSP requester would
>> be querying on a certificate it was not already handling and therefore
>> had conclusive proof that the certificate was issued.
>
>
If a CA key was revoked and a certificate a user is checking has been 
issued after  this revocation what status should be returned? Revoked 
does not look right - it is not in the CRL. Thus, notIssued seems one 
logical possibility.

Irene

Irene Gassko                                     Bell Laboratories
Lucent Technologies                          Secure Technologies Dept.
300 Brickstone Square                       voice:   (978) 691-3270
6-th Floor                                          e-mail: [email-masked]
Andover, MA 01845                            fax:      (978) 691-3186

From: "Paul Lambert" <[email-masked]>
To: "Bob Jueneman" <[email-masked]>
cc: [email-masked]
Date: Fri, 26 Jun 1998 11:10:26 -0400
Subject: Re: Last Call - Profile
Sender: [email-masked]

Bob,

I strongly disagree with your advocacy of the mandatory use of X501 names
in PKIX:

>we ought to at least support the means for creating unambiguous names.

This is not necessary.  Obviously DNS and e-mail addresses are much better
names.  We should not force the mandatory use ofX501 names just to support
the systems that use X500 and LDAP directories.  There are are other better
approaces that we should allow to evolve.

Paul

"Bob Jueneman" <[email-masked]> on 06/25/98 06:13:08 PM

To:   [email-masked], [email-masked]
cc:   [email-masked] (bcc: Paul Lambert/Certicom)
Subject:  Re: Last Call - Profile

Anne Anderson wrote:

>Objection 1: PKIX should not mandate use of X501 names for chaining.
>Not all PKI's store certificate information in an X500 directory.

I would respectfully disagree with Anne's objection number 1.  Although
not all PKI's will store certificate information in X.500 or X.500-like
(e.g., LDAP)
directories, I would expect that many will do so. If we do not settle on
some form of acceptable schema for storing certificates, we won't have
any kind of interoperability at all.  We've been using and assuming the
use of DNs in certificates for at least five years now, so it seems a bit
late
to change such a basic assumption.  But if you have something that for
some reason I don't understand cannot be formed into an attribute that
X.500 will accept, you are free to use an alternate subject name.
>
>--------------------------------------------------------------------
>Objection 2: If PKIX does mandate X501 names for chaining, then the
>RFC2247 "DC=" attribute should be added to the list of recommended
>name attributes to be used in section 4.1.2.4.

I would have no objection to that, although personally I think that
decomposing
all of the domains into individual components is unnecessary. But if
someone needs that ability, that's OK with me.
>
>4.1.2.4 Issuer
>..
>   Standard sets of attributes have been defined in the X.500 series of
>   specifications.  This specification recommends that issuer names con-
>   tain only the following attribute types: country, organization,
>   organizational-unit, distinguished name qualifier, title, locality,
>   state or province name, common name (e.g., "Susan Housley"), surname,
>   given name, initials, and generationqualifier (e.g., "Jr." or "IV").
>   The syntax and associated object identifiers (OIDs) for these attri-
>   bute types are provided in the ASN.1 modules in Appendices A and B.
>
>[Insert: "domain component (i.e. RFC2247)" in the list of recommended
>name attributes.]
>

Anne's note jogged my memory in this area.  One of the major problems
with "locality" is that the semantics are exceptionally poorly defined
in X.521.  Is it a city or town, a real estate subdivision within a town,
a county, the Washington Metropolitan Area, Europe, the Internet,
the solar system, or what?  What purpose is it intended to serve?

In particular, does it serve as a reasonable name qualifier for the sake of
uniqueness?  Does it serve as a geographical or geopolitical region that
is sufficiently small that I might actually be able to find someone there?
Is it a substitute for stateOrProvince, for those countries that don't have
states, cantons, territories, parishes, etc., etc.?

I think that locality is essentially useless and will remain so until the
semantics are clarified. Since ISO has not seen fit to do so, I would
suggest that the IETF find another qualirifier that is more useful,
if necessary making up its own and registering it under a new OID.
Or we might want to go back and dredge through the NADF archives
to find their definition, which was quite specific -- down to the level of
unincorporated areas and even trailer parks, so long as they were on the
NIST tape listing such areas, at least within the US.

But while locality is so poorly defined as to be nearly useless, the list
also
omits the obviously necessary qualifier of streetAddress or postAddress,
in addition to what I believe is Anne's concern, the need for cyberspace
addresses, either in place of or in addition to physical addresses.

But in any case, whether we insist on globally unambiguous names or not,
we ought to at least support the means for creating unambiguous names.
And as long as at least some people believe that there is some purpose for
having a physical address of record for digitally signed transactions, in
order
to send the sheriff there if necessary, omitting a street address is an
egregious
oversight.

Bob

Robert R. Jueneman
Security Architect
Novell, Inc.
Network Products Group
122 East 1700 South
Provo, UT 84604
801/861-7387
[email-masked]

"Architects, like prophets and saints, are
usually years ahead of their time. For this
reason they are often difficult to live with
at home, especially if they turn out to be
right."

Date: Fri, 26 Jun 1998 10:41:57 -0400
From: Paul Koning <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call - Profile
Sender: [email-masked]

>>>>> "Bob" == Bob Jueneman <[email-masked]> writes:

 Bob> Anne Anderson wrote:
 >> Objection 1: PKIX should not mandate use of X501 names for
 >> chaining.  Not all PKI's store certificate information in an X500
 >> directory.

 Bob> I would respectfully disagree with Anne's objection number 1.
 Bob> Although not all PKI's will store certificate information in
 Bob> X.500 or X.500-like (e.g., LDAP) directories, I would expect
 Bob> that many will do so. If we do not settle on some form of
 Bob> acceptable schema for storing certificates, we won't have any
 Bob> kind of interoperability at all.  We've been using and assuming
 Bob> the use of DNs in certificates for at least five years now, so
 Bob> it seems a bit late to change such a basic assumption.  But if
 Bob> you have something that for some reason I don't understand
 Bob> cannot be formed into an attribute that X.500 will accept, you
 Bob> are free to use an alternate subject name.
 >>
 >> --------------------------------------------------------------------
 >> Objection 2: If PKIX does mandate X501 names for chaining, then
 >> the RFC2247 "DC=" attribute should be added to the list of
 >> recommended name attributes to be used in section 4.1.2.4.

 Bob> I would have no objection to that, although personally I think
 Bob> that decomposing all of the domains into individual components
 Bob> is unnecessary. But if someone needs that ability, that's OK
 Bob> with me.

So did we settle that alternate names CAN be used for chaining?  The
outcome of that debate wasn't clear to me...  Because that's what you
need for DNS names if you don't want to decompose them into DC pieces
(right)?

	paul

-- 
!-----------------------------------------------------------------------
! Paul Koning, NI1D, D-20853
! Xedia Corporation, 119 Russell Street, Littleton, MA 01460, USA
! phone: +1 978 952 6000 ext 115, fax: +1 978 952 6090
! email: [email-masked]
! Pgp:   27 81 A9 73 A6 0B B3 BE 18 A3 BF DD 1A 59 51 75
!-----------------------------------------------------------------------
! "The only purpose for which power can be rightfully exercised over 
!  any member of a civilized community, against his will, is to prevent
!  harm to others.  His own good, either physical or moral, is not
!  a sufficient warrant."    -- John Stuart Mill, "On Liberty" 1859

From: Peter Sylvester <[email-masked]>
Date: Fri, 26 Jun 1998 12:46:58 +0200
To: [email-masked]
Subject: Re: New OCSP draft
Cc: [email-masked]
Sender: [email-masked]

> Problem is: I do not want to ask for the validity of a key, I have to
> ask for the validity of a specific certificate, which is identified by
> issuer and serial. Perhaps we could add:
> 
> 	serialNumber    CertificateSerialNumber OPTIONAL
> 	certificateHash CertificateHash         OPTIONAL
> 
> Then we might need an additional response code: certificateHashRequried
I can live with that.

Anyway, it seems to me that Certificatehash for identification is sufficient: 
- If ever there would be a duplicate, an issuer can easily avoid that
- If ever there would be a duplicate, we probably have a problem with hashing?

> 
> > I would like to propose another transport protocol:
> > OCSP over UPD:
> > 
> > The idea is to put an OCSP request into one UDP request.
> > In order to identify results one need a sequence number. This
> > can be done in the follonwg way: The UDP packet is filled using
> > an sequence of an INTEGER containing the seuence number, the OCSPrequest.
> > Similar for the response. (Where is my DNS and BIND handbook :-)
> 
> Good idea, but we should mandate: SHOULD only be used in local
> environments.

Why that? 
 
> 

Date: Fri, 26 Jun 1998 10:43:03 +0200
From: Andreas Berger <[email-masked]>
To: Peter Sylvester <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: New OCSP draft
Sender: [email-masked]

> > 3. CertStatus
> > I would really love to see the addition of notIssued to the list of
> > result codes. This would mean "I know about the CA and all the
> > certificates it has ever issued, but the certificate presented is *not*
> > on my list".
> This might give you a possibility to recover ALL certificates in a CA
> by using iteration through the serialnumbers, once you have guessed
> some pattern, thus doing something like a list operation in directory.
> 
> one can avoid the problem by allocating non-consecutive serial numbers
> for exemple, but why should one add restrictions to implementators of
> the CA about how to choose serial numbers in order to avoid this
> possible attack.
> 
> In fact I don't like the serialnumber in the CertID.
> Why not a hash of the key? If you HAVE a cert, THEN you can get
> make a request, but not if you DO NOT have it. Iterating to
> hashes of public keys is not that easy.
Problem is: I do not want to ask for the validity of a key, I have to
ask for the validity of a specific certificate, which is identified by
issuer and serial. Perhaps we could add:

	serialNumber    CertificateSerialNumber OPTIONAL
	certificateHash CertificateHash         OPTIONAL

Then we might need an additional response code: certificateHashRequried

> I would like to propose another transport protocol:
> OCSP over UPD:
> 
> The idea is to put an OCSP request into one UDP request.
> In order to identify results one need a sequence number. This
> can be done in the follonwg way: The UDP packet is filled using
> an sequence of an INTEGER containing the seuence number, the OCSPrequest.
> Similar for the response. (Where is my DNS and BIND handbook :-)

Good idea, but we should mandate: SHOULD only be used in local
environments.

Andreas
-- 
Microsoft -- definitly needs Viagra

Date: Fri, 26 Jun 1998 10:34:25 +0200
From: Andreas Berger <[email-masked]>
To: Michael Myers <[email-masked]>
CC: Ambarish Malpani <[email-masked]>, IETF PKIX <[email-masked]>
Subject: Re: New OCSP draft
Sender: [email-masked]

Mike,

> >1. OCSPResponseStatus:
> >certRequired: How are situations handled when status for multiple
> >certificates is requested and for just on the certificate is required.
> >This result code should probably be moved to "CertStatus" so that an
> >OCSP responder can produce this answer for each requested certificate
> >individually.
> 
> We did put in some syntax to provide per-cert granularity in the event of
> multi-cert requests.  The expectation regarding certRequired was that this
> would apply globally to all certs in a multi-cert request.
Considering the comment from Peter, this could perhaps be changed to:

successful, malformed request (optional), internal error, tryLater,
sigRequired

with certRequired moved to CertStatu (not nice). Perhaps:

SingleResponse ::= SEQUENCE {
	certID		certID,
	responseStatus	responseStatus,
	CertStatus	certStatus
... (unchanged)
}

ResponseStatus ::= CHOICE {
	tryLater
	certRequired
}

caReferral could be added here as well, altough this would add the whole
GeneralName syntax to OCSP.

> Would something along the following lines meet your need?
> 
> 4.4.5 CA Referral
> 
> To simply configuration management of OCSP requesters, OCSP responders
> may respond with a referral response extension in responseExtensions.
> The referral value will be identified by the object identifier
> id-pkix-ocsp-referral, while the extnValue provides a value the client
> should use in acquiring a response.
> 
> id-pkix-ocsp-referral     OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 }
> --value of syntax GeneralName
This is fine with me.

> >3. CertStatus
> >I would really love to see the addition of notIssued to the list of
> >result codes. This would mean "I know about the CA and all the
> >certificates it has ever issued, but the certificate presented is *not*
> >on my list".
> 
> This request has come up before.  The primary reason it's not in the
> list of result codes is that it seems unlikely an OCSP requester would
> be querying on a certificate it was not already handling and therefore
> had conclusive proof that the certificate was issued.

Just an explanation:

The idea behind "not issued" is that certificates can remain valid even
after a key compromise of the CA since the OCSP/Directory services
serves as a second source of trust (that does not mean I like this
concept, it is just mentioned and described in the Law). So what we will
probably specify is that we give a Status of unknown (or revoked, to be
semantically compatible with the rest of the world) and a private
extension specifying the "not issued" (or can we specify such an
extension here?).

> 
> >4. OCSPRequest
> >Addition of an extension that allows a requester to specify the point in
> >time it wants information for. Then it is possible to ask: "I have a
> >signature produced last week, was the certificate used in that process
> >valid then?".
> 
> This requirement has been considered in earlier drafts of the protocol.
> It was dropped out in favor of simplicity, prior to the establishment
> of the extension mechanism.  However, it does seem a general enough
> requirement to establish a standard OCSP extension for those with a need.
> 
> Would something along the lines of the following text meet your need?
> 
> 4.4.6 Archive Reference
> 
> OCSP clients may be required to establish the validity of a signature
> when it was produced.  OCSP responders that are intended to support
> such a capability SHOULD recognize the ArchiveReference extension.
> This request extension is recognized as id-pkix-ocsp-archiveReference
> and its value will be of type GeneralizedTime.
> 
> id-pkix-ocsp-archiveReference    OBJECT IDENTIFIER ::= { id-pkix-ocsp 6 }
> --value of syntax GeneralizedTime
> 
> The producedAt value of the resulting response will be the current time
> (i.e. the time when the response was produced). Values for thisUpdate
> and nextUpdate will be as specified in section 2.4.
This seems to solve that issue. Question is: Should we allow that
per-Cert or per-Request (or both?).

Andreas
-- 
Microsoft -- definitly needs Viagra

Date: Thu, 25 Jun 1998 16:13:08 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: Re: Last Call - Profile
Sender: [email-masked]

Anne Anderson wrote:

>Objection 1: PKIX should not mandate use of X501 names for chaining.
>Not all PKI's store certificate information in an X500 directory.

I would respectfully disagree with Anne's objection number 1.  Although 
not all PKI's will store certificate information in X.500 or X.500-like (e.g., LDAP)
directories, I would expect that many will do so. If we do not settle on
some form of acceptable schema for storing certificates, we won't have
any kind of interoperability at all.  We've been using and assuming the
use of DNs in certificates for at least five years now, so it seems a bit late
to change such a basic assumption.  But if you have something that for
some reason I don't understand cannot be formed into an attribute that 
X.500 will accept, you are free to use an alternate subject name.
>
>--------------------------------------------------------------------
>Objection 2: If PKIX does mandate X501 names for chaining, then the
>RFC2247 "DC=" attribute should be added to the list of recommended
>name attributes to be used in section 4.1.2.4.

I would have no objection to that, although personally I think that decomposing 
all of the domains into individual components is unnecessary. But if 
someone needs that ability, that's OK with me.
>
>4.1.2.4 Issuer
>..
>   Standard sets of attributes have been defined in the X.500 series of
>   specifications.  This specification recommends that issuer names con-
>   tain only the following attribute types: country, organization,
>   organizational-unit, distinguished name qualifier, title, locality,
>   state or province name, common name (e.g., "Susan Housley"), surname,
>   given name, initials, and generationqualifier (e.g., "Jr." or "IV").
>   The syntax and associated object identifiers (OIDs) for these attri-
>   bute types are provided in the ASN.1 modules in Appendices A and B.
>   
>[Insert: "domain component (i.e. RFC2247)" in the list of recommended
>name attributes.]
>

Anne's note jogged my memory in this area.  One of the major problems 
with "locality" is that the semantics are exceptionally poorly defined
in X.521.  Is it a city or town, a real estate subdivision within a town, 
a county, the Washington Metropolitan Area, Europe, the Internet, 
the solar system, or what?  What purpose is it intended to serve?

In particular, does it serve as a reasonable name qualifier for the sake of
uniqueness?  Does it serve as a geographical or geopolitical region that
is sufficiently small that I might actually be able to find someone there?
Is it a substitute for stateOrProvince, for those countries that don't have 
states, cantons, territories, parishes, etc., etc.?

I think that locality is essentially useless and will remain so until the 
semantics are clarified. Since ISO has not seen fit to do so, I would 
suggest that the IETF find another qualirifier that is more useful,
if necessary making up its own and registering it under a new OID.
Or we might want to go back and dredge through the NADF archives
to find their definition, which was quite specific -- down to the level of 
unincorporated areas and even trailer parks, so long as they were on the
NIST tape listing such areas, at least within the US.

But while locality is so poorly defined as to be nearly useless, the list also
omits the obviously necessary qualifier of streetAddress or postAddress,
in addition to what I believe is Anne's concern, the need for cyberspace 
addresses, either in place of or in addition to physical addresses.

But in any case, whether we insist on globally unambiguous names or not,
we ought to at least support the means for creating unambiguous names.
And as long as at least some people believe that there is some purpose for
having a physical address of record for digitally signed transactions, in order
to send the sheriff there if necessary, omitting a street address is an egregious 
oversight.

Bob

Robert R. Jueneman
Security Architect
Novell, Inc.
Network Products Group
122 East 1700 South
Provo, UT 84604
801/861-7387
[email-masked]

"Architects, like prophets and saints, are 
usually years ahead of their time. For this
reason they are often difficult to live with
at home, especially if they turn out to be 
right."

Date: Thu, 25 Jun 1998 12:49:52 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Cc: [email-masked]
Subject: Re: SV: new profile submitted
Sender: [email-masked]

I absolutely and vociferously agree with Nada.

Changing the size of the key ID this late in the game is ABSOLUTELY 
UNACCEPTABLE for anything less than an end-of-the-world kind of problem.

As part of the effort to ramp up for the release of Novell's NetWare 5.0 next month,
we are in the process of generating Foundation Key Sets containing 7 certificates 
each, with an initial run of over 200,000 Foundation Key Sets. Running flat out
on our Wang XTS B3 machine, it will take about a month to complete this
process. Since we sent out over 200,000 copies of the beta alone, I would 
expect that by the end of the year, there will probably be on the order of 
3.5 million certificates out there and presumably in use, with people starting to 
generate their own certificates using our CA product.

All of the keyIDs in those certificates use a 160 bit SHA-1 hash.

I can only imagine what will happen if this impacts Windows 98.
The IETF will suddenly have become irrelevant.

If this is last call, I will have to vote a strenuous NO unless this is changed.  
It's simply too late in the game.

Bob

Robert R. Jueneman
Security Architect
Novell, Inc.
Network Products Group
122 East 1700 South
Provo, UT 84604
801/861-7387
[email-masked]

"Architects, like prophets and saints, are 
usually years ahead of their time. For this
reason they are often difficult to live with
at home, especially if they turn out to be 
right."

>>> Nada Kapidzic Cicovic <[email-masked]> 06/24 4:08 AM >>>
I do not understand the point of changing the key id calculation algorithm
this late in pkix part 1 last call. 

Is the size of the resulting key id the only problem with the old algorithm
definition?

Is this size really an issue for S/MIME messages?

I would prefer changing the definition back to what it was, since we have
already released the software implementing it in the old way, and we are
probably not the only one.

Regards,

Nada

At 20:55 6/23/98 -0400, Russ Housley wrote:
>The PKIX Part 1 key identifier will be used in S/MIME to identify the
>per-recipient information necessary for a recipient to perform decryption.
>As stated in a previous message, collisions are not a problem here.
>However, this key identifier will not be used to identify a particular
>certificate used by an originator to sign a message content.  Collisions
>could cause significant confusion in this circumstance.
>
>Russ
>
>
>At 12:11 PM 6/23/98 -0700, Paul Hoffman / IMC wrote:
>>I think the question here is whether or not it is useful to have the same
>>key identifier for both PKIX part 1 and OCSP. If it is, then we need to
>>choose one that works for both. Ambarish says that 60 bits, with the
>>possibility of collision, is not strong enough for OCSP. If that's true, we
>>need to decide if the two key identifiers have to be the same, or whether
>>we can use a shorter one for PKIX part 1 and a longer one for OCSP.
>>
>>--Paul Hoffman, Director
>>--Internet Mail Consortium
>> 
>

From: [email-masked]
To: Tim Polk <[email-masked]>
cc: [email-masked]
Date: Thu, 25 Jun 1998 08:23:38 -0400
Subject: Re: PKIX-1 - use of UTF8
Sender: [email-masked]

Tim Polk <[email-masked]> wrote:

>Consider the same chain CA0, CA1, CA2, and EE.  Let {x,y} mean a
>certificate issued by x with subject y.
>
>Case 1:  CA0 "switches" to UTF8
>
>CA0 issues two certificates {CA0(T61),CA0(UTF8)} and {CA0(UTF8),
>CA0(T61)}.  New users trusting CA0(UTF8) can now trust old paths;
>old users trusting CA0(T61).
>
>Case 2: CA2 "switches" to UTF8
>
>CA2 issues two certificates {CA2(T61),CA2(UTF8)} and {CA2(UTF8),
>CA2(T61)}.  The path from CA0 to the EE cert is still valid.
>
>CA2 requests a new cert from CA1 for its UTF8 encoded name.
>CA1 issues the cert {CA1,CA2(UTF8)} with the UTF8 name constraints.
>
>At this point, the path from CA0 to the EE certificate does not use ANY
>of the new certificates.
>
>The EE cert expires.  CA2 issues {CA2(UTF8), EE(UTF8)}.
>
>There are two paths from CA0 to the EE certificate.  The first path is
>the "old" path with the name rollover certificate.  It is NOT VALID
>becasue of the name constraints.  The second path uses {CA1,CA2(UTF8)}
>and does not use the name rollover certificate.  This path satisfies
>the name constraints and is valid.

This is basically saying that whenever the first entity changes over to
UTF8, everything above it in a trust chain will have to change over
immediately in order for the new name can be recognized.  Since CA2 doesn't
know which trust chain a verifier is going to want to use when trying to
determine EE's key, it'll have to request new certs from every CA that has
issued one for it, not just from CA1. That's not a migration - that's a
stampede :-)

How do the CAs know that a name encoded in T61 is the same as a name
encoded
in UTF8 (so they will just simply OK the new certificate request)?  Is this
expected to require manual approval, or is it automatic?  If it's
automatic,
it means they can do codeset conversion, so why not build that same ability
now into end-systems and avoid the requirement for a sudden switch-over?

John

From: Nilsson Hans <[email-masked]>
To: Russ Housley <[email-masked]>, [email-masked]
Subject: Subject Key Id algorithm
Date: Thu, 25 Jun 1998 07:11:14 +0100
Sender: [email-masked]

Regarding the question of how to compute subject Key Identifier:

I have just seen that the "ISO draft 15782: Banking - certificate Management
- Part 1: Public Key Certificates" also recommends 60 bits hash as follows:

"When this extension is populated, CAs may use a 60 bit SHA-1 hash of the
subject's public key as the subjectKeyIdentifier" (and then a reference to
ISO 10118-3: Information Technology - Security techniques - Hashfunctions -
Part 3: Dedicated hash functions)

The only difference is then the leading 0100.

Hans

Date: Wed, 24 Jun 1998 15:15:07 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: RE: PKIX-1 - use of UTF8
Sender: [email-masked]

I agree with Tim here. The character set issue is unbounded and is very
likely to change over time. Case matching and composition is only easy for
Latin-based characters, and even then has wrinkles that typical
implementors are sure to get wrong (such as locale-based sorting and
capitalization rules). I think the best thing to do is to tell people not
to rely on exclusion rules that are based on ranges of non-ASCII characters
and be done with it, since trying to over-specify now will still lead to
changes in the future when the Unicode folks change the rules, which they
might.

--Paul Hoffman, Director
--Internet Mail Consortium

From: William Bellamy <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: draft-ietf-pkix-ipki-part1-08.txt
Date: Wed, 24 Jun 1998 13:12:32 -0700
Sender: [email-masked]

> Hi,
> 
> In section 4.1.2.6 Subject I read:
> Implementations of this specification should be prepared to receive the
> following X.501 attribute types: country, organization,
> organizational-unit, distinguished name qualifier, title, locality, state
> or province name, common name (e.g., "Susan Housley"), surname, given
> name, initials, and generationqualifier (e.g., "Jr." or "IV").
> I take this to mean that one of each of these attributes may be present.
> It is not clear if more than one organizational-units are permitted. My
> interpretation is that only one could be present. Can you confirm this
> reading?
> Thanks,
> William Bellamy
> Microsoft Critical Problem Resolution
> 

Date: Wed, 24 Jun 1998 15:03:07 -0400
To: Peter Whittaker <[email-masked]>, "[email-masked]'" <[email-masked]>
From: Tim Polk <[email-masked]>
Subject: RE: PKIX-1 - use of UTF8
Cc: [email-masked]
Sender: [email-masked]

Peter,

Technically, you are correct.  As you say, "the rules of DN comparison
indicate that the character sets used to encode data in DNs are irrelevant,
that it is the characters themselves that must be compared." These rules
are reasonable to implement for PrintableString and T61, but quickly become
very difficult when you add BMPString, UniversalString, or UTF8 to the mix.
 Constructed characters and undefined case make this really hard.

The IESG, and PKIX profile in turn, is commited to support for UTF8.  On
the other hand, implementers in the PKIX group have indicated the full
range of codeset comparison is unreasonable.  If they are going to support
UTF8, the problem must be bounded.

The current draft of the PKIX profile explicitly permits case-sensitive
comparison of names encoded in UTF8 or BMPString, without resolution of
constructed characters or compacting white space. It also permits an
implementation to assume that names encoded in different codesets are
different.

As a result, a PKIX compliant implementation meeting these minimal
requirements might not recognize all paths that a "full" implementation
(one that means all the X.5xx rules) would recognize. However, the PKIX
compliant implementation wouldn't accept invalid ones, either.

John Wray has identified a shortcoming in this approach.  In some cases,
the excluded subtrees mechanism might result in acceptance of a path by a
PKIX implementation that would be rejected by a "full" implementation.
This could happen if the excluded subtrees definition used different case,
uncompacted whitespace, or constructed characters that did not appear in
the certificate DNs.

(This also implies that "full" implementations must reject any
certification path with an unrecognized codeset in the excluded subtrees
field!  You can't be sure what it maps to, so you can't be sure that its
satisfied.)

As I understand it, a lot of care went into the certificate and CRL design
so that there was only one way to encode it. Even if you unroll it, store
it in a database, and reconstruct it later, the signature should validate.
Of course, that only works if you store the DN as a binary blob!  The X.5xx
name comparison rules are incompatible with that premise since white space,
code set choice, constructed characters, etc. all result in different
encodings of equivalent names.  Worse yet, I'm afraid that we haven't
discovered all the complications.

Stating that names encoded differently *are different* seems faithful to
the original intent.  Of course, I wasn't there so I may be wrong.  Could
just be wishful thinking.

Regardless of the X.509 authors' intent, I believe that it is useful to
bound the name comparison problem.  Let's set the bar at a reasonable
height so we know what we can count on.

Sorry for ranting on like this, but character sets have become the bane of
my existence!  Seriously, they are one of the thorniest issues remaining.
I am afraid that we'll build a global PKI and have zero interoperability
because of character set issues.  (I can see myself trying to explain to
the lab director why he can't validate certification paths from Singapore
or Japan.  And I don't like what I see!) 

Tim

At 11:13 AM 6/24/98 -0400, Peter Whittaker wrote:
>> Consider a trust-path CA0 -> CA1 -> CA2 -> EE, using current PKIX
>> certificates (i.e. names expressed using printable or 
>> T61/Latin-1 strings), being evaluated by an end-entity that follows
>> the current matching rules.
>> Each CA cert specifies permitted subtree name constraints.  
>> On January 1, 2003, the rollover starts.  Let's say the cert issued
>> by CA1 for CA 2 is the first to expire.  According to the above, CA1
>> is supposed to create a new certificate for CA2 using UTF8 strings.
>> OK, it goes ahead and does that.  Now, an end-entity tries to
>> evaluate the trust chain - it'll fail, because the permitted subtree
>> constraints imposed on CA1 by the CA0->CA1 cert don't allow for the
>> subtree containing CA2's UTF8 name, only its T.61 name.  I think
>> everything stays broken until all the certs are replaced.
>> Name rollover certs don't help this case.
>
>Shouldn't the rules of DN comparison apply in this case?  And don't the
>rules of DN comparison indicate that the character sets used to encode
>data in DNs are irrelevant, that it is the characters themselves that
>must be compared?
>
>If the certificate verifier must DER-encode the certificate prior to
>performing signature validation, they must take into account character
>sets while performing the encoding.  Once they have verified a
>certificate, that is, they have verified that the signature is valid,
>they extract whatever data is pertinent and use it appropriately.
>
>In the case of extracting and comparing DNs, one in the subject field
>of one certificate, the other in the subtree field of another, the rules
>of DN comparison would apply, and it would be legitimate for the
>user to convert a character representation from one set (say, T.61) to
>that of another set (say, BMPString), in order to verify that the
>characters represented are the same.  Or, the user could convert both
>encodings, that is, the representations of characters in the two DNs,
>to a third encoding (their local character table) in order to compare
>the strings.
>
>The important thing is that when comparing DNs, character data in the
>DNs are compared on a character-by-character basis, not on the basis
>of the encoding that results from representing those characters in any
>particular character set.
>
>An 'a' is an 'a' is 'a', be it manipulated in ASCII, T.61, EBCDIC, or
>sign language.
>
>pww
>
>
>Attachment Converted: "c:\program files\eudora\attach\Peter Whittaker
(E-mail).vcf"
>

From: Peter Sylvester <[email-masked]>
Date: Wed, 24 Jun 1998 19:48:24 +0200
To: [email-masked], [email-masked]
Subject: Re: New OCSP draft
Cc: [email-masked]
Sender: [email-masked]

> First of all, I like the new draft better then the previous version, a
> lot of the issues that I had problems with were resolved. I would like
> to make some comments on the protocol.
Fully agree, we also would like to make some comments:

The following paragraph may include something like: 
"Some legislation requires online checking of a certificate status. This
can be achieved by this protocol;" 

" In lieu of or as a supplement to checking against a periodic CRL, it
  may be necessary to obtain timely status regarding a certificate's
  revocation state (cf. PKIX Part 1, Section 3.3). Examples include
  high- value funds transfer or large stock trades.

> 
> As a preface, we try to specify a profile for OCSP for use in the
> on-line revocation check mandated in the German Signature Law. So some
> of the comments I make are with that application in mind.
> 
> 1. OCSPResponseStatus:
> certRequired: How are situations handled when status for multiple
> certificates is requested and for just on the certificate is required.
> This result code should probably be moved to "CertStatus" so that an
> OCSP responder can produce this answer for each requested certificate
> individually.
Or: when during the checking of the cert one cert information is 
temporarily not available. 

> 
> 2. SingleResponse/CertStatus
> Shouldn't possibility of "I do know the CA but I am unable to answer the
> request, pls. ask here" be added to a response? This would minimize the
> configuration on the client.
I second that. if the request is for a single cert this might be done
by an HTTP redirect, but it should be generalized inside OCSP.

Even with an AuthorityInfoAccess extension, the service provider 
may change. 

One might also consider some value added service provider that knows
where to look up.

> 
> 3. CertStatus
> I would really love to see the addition of notIssued to the list of
> result codes. This would mean "I know about the CA and all the
> certificates it has ever issued, but the certificate presented is *not*
> on my list".
This might give you a possibility to recover ALL certificates in a CA
by using iteration through the serialnumbers, once you have guessed
some pattern, thus doing something like a list operation in directory. 

one can avoid the problem by allocating non-consecutive serial numbers
for exemple, but why should one add restrictions to implementators of
the CA about how to choose serial numbers in order to avoid this
possible attack.

In fact I don't like the serialnumber in the CertID.
Why not a hash of the key? If you HAVE a cert, THEN you can get
make a request, but not if you DO NOT have it. Iterating to
hashes of public keys is not that easy.

In case of a request with a certificate, a response of notIssued may
make sense. 

   KeyHash ::= OCTET STRING --SHA-1 hash of responder's public key

Once we might discover that SHA-1 is not a good ? 

   The value for responseBytes consists of an OBJECT IDENTIFIER and a 
   response syntax identified by that OID encoded as an OCTET STRING:

   ResponseBytes ::=	SEQUENCE {
        responseType   OBJECT IDENTIFIER,
        response       OCTET STRING }

Do you really want encapsulation?  

=====    3.3 Signed Response Acceptance Requirements

One should be explicit: The validation may involve interaction with
the user. Attention: Recursion may occur. I want to validate a
signers cert, thus I may ask someone else and so on.

I would like to propose another transport protocol:
OCSP over UPD:

The idea is to put an OCSP request into one UDP request.
In order to identify results one need a sequence number. This
can be done in the follonwg way: The UDP packet is filled using
an sequence of an INTEGER containing the seuence number, the OCSPrequest.
Similar for the response. (Where is my DNS and BIND handbook :-)

The usage of the word   'SHALL' seems to be the ISO like one in
all cases. Wouldn't be MUST the better word? 

Peter Sylvester -- EdelWeb France 

Date: Wed, 24 Jun 1998 10:17:48 -0700
To: Andreas Berger <[email-masked]>, Ambarish Malpani <[email-masked]>
From: Michael Myers <[email-masked]>
Subject: Re: New OCSP draft
Cc: IETF PKIX <[email-masked]>
Sender: [email-masked]

Andreas,

Thanks for taking the time to read through the new draft.  It's taken us
longer than we would've like to get to this point.

Some responses on your comments below.

Mike

At 12:40 PM 6/24/98 +0200, Andreas Berger wrote:
>First of all, I like the new draft better then the previous version, a
>lot of the issues that I had problems with were resolved. I would like
>to make some comments on the protocol.
>
>As a preface, we try to specify a profile for OCSP for use in the
>on-line revocation check mandated in the German Signature Law. So some
>of the comments I make are with that application in mind.
>
>1. OCSPResponseStatus:
>certRequired: How are situations handled when status for multiple
>certificates is requested and for just on the certificate is required.
>This result code should probably be moved to "CertStatus" so that an
>OCSP responder can produce this answer for each requested certificate
>individually.

We did put in some syntax to provide per-cert granularity in the event of
multi-cert requests.  The expectation regarding certRequired was that this
would apply globally to all certs in a multi-cert request.

>
>2. SingleResponse/CertStatus
>Shouldn't possibility of "I do know the CA but I am unable to answer the
>request, pls. ask here" be added to a response? This would minimize the
>configuration on the client.

Would something along the following lines meet your need?

4.4.5 CA Referral

To simply configuration management of OCSP requesters, OCSP responders
may respond with a referral response extension in responseExtensions.
The referral value will be identified by the object identifier
id-pkix-ocsp-referral, while the extnValue provides a value the client
should use in acquiring a response.

id-pkix-ocsp-referral     OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 }
--value of syntax GeneralName

>3. CertStatus
>I would really love to see the addition of notIssued to the list of
>result codes. This would mean "I know about the CA and all the
>certificates it has ever issued, but the certificate presented is *not*
>on my list".

This request has come up before.  The primary reason it's not in the 
list of result codes is that it seems unlikely an OCSP requester would
be querying on a certificate it was not already handling and therefore
had conclusive proof that the certificate was issued.

>4. OCSPRequest
>Addition of an extension that allows a requester to specify the point in
>time it wants information for. Then it is possible to ask: "I have a
>signature produced last week, was the certificate used in that process
>valid then?".

This requirement has been considered in earlier drafts of the protocol.
It was dropped out in favor of simplicity, prior to the establishment
of the extension mechanism.  However, it does seem a general enough
requirement to establish a standard OCSP extension for those with a need.

Would something along the lines of the following text meet your need?

4.4.6 Archive Reference

OCSP clients may be required to establish the validity of a signature
when it was produced.  OCSP responders that are intended to support
such a capability SHOULD recognize the ArchiveReference extension.
This request extension is recognized as id-pkix-ocsp-archiveReference
and its value will be of type GeneralizedTime.

id-pkix-ocsp-archiveReference    OBJECT IDENTIFIER ::= { id-pkix-ocsp 6 }
--value of syntax GeneralizedTime

The producedAt value of the resulting response will be the current time
(i.e. the time when the response was produced). Values for thisUpdate
and nextUpdate will be as specified in section 2.4.

>
>THNX
>Andreas
>-- 
>Microsoft -- definitly needs Viagra
>
>

Date: Wed, 24 Jun 1998 11:13:31 -0400
To: [email-masked]
From: Hal Lockhart <[email-masked]>
Subject: Re: PKIX-1 - use of UTF8
Sender: [email-masked]

At 03:04 PM 6/23/98 -0400, [email-masked] wrote:

>I don't think that's true.  Under the assumption that the stated name
>comparison rules would be applied when evaluating name constraints as well
>as when chaining issuer and subject names, a system that implemented the
>PKIX matching rules might fail to enforce an excluded subtree constraint
>that a codeset-converting implementation would catch.  This would result in
>a system that implemented the PKIX-1 rules verifying a chain against the
>expressed intentions of one of the CAs in that chain, whereas a system that
>performed codeset conversion would correctly refuse to accept the chain.

Sigh.  I keep running into this general problem in different guises. I am
becoming increasingly convinced that any security mechanism of the sort
"allow everything except for ..." will eventually break.  At the very
least, it is on my list of things to avoid in software engineering, along
with implied acknowledgements and global variables. Yes, I know this is
X.509 and cannot be (quickly) changed.

Hal

====================================================================
Harold W. Lockhart Jr.               PLATINUM technology
Chief Technical Architect            8 New England Executive Park
Email: [email-masked]  Burlington, MA 01803 USA
Voice: (781)273-6406                 Fax: (781)229-2969
====================================================================

From: Peter Whittaker <[email-masked]>
To: "[email-masked]'" <[email-masked]>, Tim Polk <[email-masked]>
Cc: [email-masked]
Subject: RE: PKIX-1 - use of UTF8
Date: Wed, 24 Jun 1998 11:13:39 -0400
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------ =_NextPart_000_01BD9F82.AAA9D0A4
Content-Type: text/plain

> Consider a trust-path CA0 -> CA1 -> CA2 -> EE, using current PKIX
> certificates (i.e. names expressed using printable or 
> T61/Latin-1 strings), being evaluated by an end-entity that follows
> the current matching rules.
> Each CA cert specifies permitted subtree name constraints.  
> On January 1, 2003, the rollover starts.  Let's say the cert issued
> by CA1 for CA 2 is the first to expire.  According to the above, CA1
> is supposed to create a new certificate for CA2 using UTF8 strings.
> OK, it goes ahead and does that.  Now, an end-entity tries to
> evaluate the trust chain - it'll fail, because the permitted subtree
> constraints imposed on CA1 by the CA0->CA1 cert don't allow for the
> subtree containing CA2's UTF8 name, only its T.61 name.  I think
> everything stays broken until all the certs are replaced.
> Name rollover certs don't help this case.

Shouldn't the rules of DN comparison apply in this case?  And don't the
rules of DN comparison indicate that the character sets used to encode
data in DNs are irrelevant, that it is the characters themselves that
must be compared?

If the certificate verifier must DER-encode the certificate prior to
performing signature validation, they must take into account character
sets while performing the encoding.  Once they have verified a
certificate, that is, they have verified that the signature is valid,
they extract whatever data is pertinent and use it appropriately.

In the case of extracting and comparing DNs, one in the subject field
of one certificate, the other in the subtree field of another, the rules
of DN comparison would apply, and it would be legitimate for the
user to convert a character representation from one set (say, T.61) to
that of another set (say, BMPString), in order to verify that the
characters represented are the same.  Or, the user could convert both
encodings, that is, the representations of characters in the two DNs,
to a third encoding (their local character table) in order to compare
the strings.

The important thing is that when comparing DNs, character data in the
DNs are compared on a character-by-character basis, not on the basis
of the encoding that results from representing those characters in any
particular character set.

An 'a' is an 'a' is 'a', be it manipulated in ASCII, T.61, EBCDIC, or
sign language.

pww

------ =_NextPart_000_01BD9F82.AAA9D0A4
Content-Type: application/octet-stream;
	name="Peter Whittaker (E-mail).vcf"
Content-Disposition: attachment;
	filename="Peter Whittaker (E-mail).vcf"

BEGIN:VCARD
VERSION:2.1
N:Whittaker;Peter;;;
FN:Peter Whittaker (E-mail)
ORG:Entrust Technologies;
TITLE:
TEL;WORK;VOICE:+1 613 247 3485
TEL;HOME;VOICE:
TEL;WORK;FAX:+1 613 247 3401
ADR;WORK:;;750 Heron Road;Ottawa;Ontario;K1V 1A7;Canada
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:750 Heron Road=0D=0AOttawa, Ontario K1V 1A7=0D=0ACanada
ADR;HOME:;;;;;;Canada
LABEL;HOME;ENCODING=QUOTED-PRINTABLE:=0D=0A,  =0D=0ACanada
EMAIL;PREF;INTERNET:[email-masked]
REV:19980601T154022Z
END:VCARD

------ =_NextPart_000_01BD9F82.AAA9D0A4--

From: [email-masked]
To: Tim Polk <[email-masked]>
cc: [email-masked]
Date: Wed, 24 Jun 1998 10:51:28 -0400
Subject: Re: PKIX-1 - use of UTF8
Sender: [email-masked]

Tim Polk <[email-masked]> wrote:

>>Basically, the current rules appear to force us to retain today's
>>multiplicity of codesets indefinitely.  Mandating codeset-conversions
prior
>>to comparison lets us prepare for a future migration to a single codeset.
>>
>
>I don't think this is true.  I proposed the following solution to support
a hard
>cutover to UTF8 encodings in 2003 on a different thread:
>
>I think a hard cutover in 2003 could be managed, though. Certificates
*issued*
>after January 1, 2003 could be required to use the UTF8String encodings.
>The one exception would be "name rollover" certificates for CAs changing
>their own names to the UTF8String encodings.  (This sounds ugly, but we'll
>be doing it for key rollover anyway.  CAs can just do them both at the
same time.)
>
>Key rollover certificates are self-signed certificates (issuer = subject)
where the
>new signing key is certified by the old signing key, or vice-versa.   A
name rollover
>certificate would have the issuer name in the old (e.g., T61) encoding and
subject
>name in UTF8, or vice-versa.  I expect CAs to perform key rollover
regularly. A
>small amount of planning will allow the CA to combine the two functions -
that is
>name and key rollover can be performed together.
>
>I think this resolves the problem of codeset migration.  Am I missing
something?

Consider a trust-path CA0 -> CA1 -> CA2 -> EE, using current PKIX
certificates (i.e. names expressed using printable or T61/Latin-1 strings),
being evaluated by an end-entity that follows the current matching rules.
Each CA cert specifies permitted subtree name constraints.  On January 1,
2003, the rollover starts.  Let's say the cert issued by CA1 for CA 2 is
the first to expire.  According to the above, CA1 is supposed to create a
new certificate for CA2 using UTF8 strings.  OK, it goes ahead and does
that.  Now, an end-entity tries to evaluate the trust chain - it'll fail,
because the permitted subtree constraints imposed on CA1 by the CA0->CA1
cert don't allow for the subtree containing CA2's UTF8 name, only its T.61
name.  I think everything stays broken until all the certs are replaced.
Name rollover certs don't help this case.

John

Date: Wed, 24 Jun 1998 10:34:22 -0400 (EDT)
From: Anne Anderson - Sun Microsystems <[email-masked]>
Reply-To: Anne Anderson - Sun Microsystems <[email-masked]>
Subject: Re: Last Call - Profile
To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

Objection 1: PKIX should not mandate use of X501 names for chaining.
Not all PKI's store certificate information in an X500 directory.

--------------------------------------------------------------------
Objection 2: If PKIX does mandate X501 names for chaining, then the
RFC2247 "DC=" attribute should be added to the list of recommended
name attributes to be used in section 4.1.2.4.

4.1.2.4 Issuer
...
   Standard sets of attributes have been defined in the X.500 series of
   specifications.  This specification recommends that issuer names con-
   tain only the following attribute types: country, organization,
   organizational-unit, distinguished name qualifier, title, locality,
   state or province name, common name (e.g., "Susan Housley"), surname,
   given name, initials, and generationqualifier (e.g., "Jr." or "IV").
   The syntax and associated object identifiers (OIDs) for these attri-
   bute types are provided in the ASN.1 modules in Appendices A and B.
   
[Insert: "domain component (i.e. RFC2247)" in the list of recommended
name attributes.]

--------------------------------------------------------------------
Objection 3: If the intent is indeed to mandate use of X501 names for
chaining, section 4.1.2.6 "Subject" is ambiguous with respect to this mandate
and section 6.1 "Basic Path Validation" contradicts this mandate.  Locations
and suggested changes follow.

4.1.2.4  Issuer

   Certificate users must be prepared to process the issuer dis-
   tinguished name and subject distinguished name (see sec. 4.1.2.6)
   fields to perform name chaining for certification path validation
   (see section 6). Name chaining is performed by matching the issuer
   distinguished name in one certificate with the subject name in
   another.
   
[Is this the only way name chaining may be performed?

If so,

  change

    "Name chaining is performed..."
  
  to
  
    "Name chaining must be performed...".

If not,

  change
  
  "Name chaining is performed by matching the issuer distinguished name
  in one certificate with the subject name in another."
  
  to
  
  "Name chaining is performed by matching the non-null issuer distinguished name
  or (if issuer is null) the critical instance of issuerAltName in one certificate
  with the non-null subject distinguished name or (if subject is null) the
  critical instance of subjectAltName in another."
]

4.1.2.6  Subject
...
   If
   the subject is a CA (e.g., the basic constraints extension, as dis-
   cussed in 4.2.1.10, is present and the value of cA is TRUE,) then the
   subject field must be populated with a non-null distinguished name
   matching the contents of the issuer field (see sec. 4.1.2.4) in all
   certificates issued by the subject CA.  If subject naming information
   is present only in the subjectAltName extension (e.g., a key bound
   only to an email address or URI), then the subject name must be an
   empty sequence and the subjectAltName extension must be critical.

[If chaining may be done using issuerAltName and subjectAltName, then

  remove first sentence
  
if not, then

  change second sentence to
  
  "If subject is not a CA and subject naming information is present only
  in the subjectAltName extension..."
]

6.1 Basic Path Validation

...
         (4) the subject and issuer names chain correctly (that is, the
         issuer of this certificate was the subject of the previous cer-
         tificate.)  If the certificate has an empty sequence in the
         name field, name chaining will use the critical subjectAltNames
         and issuerAltNames fields.

[If chaining may be done using issuerAltName and subjectAltName, then leave
as is.

If not, then remove second sentence.
]   

Anne Anderson                 Email: [email-masked]
Sun Microsystems Laboratories   Tel: (978) 442-0928
2 Elizabeth Drive, UCHL03-205   Fax: (978) 250-5067
Chelmsford, MA 01824 USA

From: [email-masked]
To: Harald Alvestrand <[email-masked]>
cc: [email-masked]
Date: Wed, 24 Jun 1998 09:57:09 -0400
Subject: Re: PKIX-1 - use of UTF8
Sender: [email-masked]

harald Alvestrand <[email-masked]> writes:

>>In the following, I'm going to call a system that implements the
>>current PKIX-1 rules an "Old" system, and one that emits certificates
>>in UTF-8 a "New" system (under the assumption that UTF-8 is where
>>we'd like to get to).  Similarly, "Old Certificates" contain names
>>using the current PKIX-1 codeset selection rules, and "New
>>Certificates" use UTF-8.
>
>You are making the assumption here that the same codeset is used for
>all attributes of all names within a certificate.
>Is this a requirement of the infrastructure?

I don't think anything I said assumes that every attribute is encoded the
same way.  PKIX-1 currently specifies codeset selection rules for each
attribute value individually.  I'm assuming that in the future we would
like to migrate to UTF-8, or at least a smaller and simpler set of syntaxes
than the five we have today.

>>I think the big implementation problem with name comparisons isn't
>>codeset conversion, but instead concerns how to compare strings in an
>>"extended" codeset.  For example, the ability to encode characters with
>>accents as either "accent"+"character" or as "accented character".  Also
>>the problems of case-insensitive comparison.  I'm quite happy to punt on
>>those issues and simply mandate a byte-for-byte equivalence, as it's a
>>hard problem, and we don't have a answer that we'd like to migrate to.
>>The case of codeset conversion is different though, since it's fairly
>>trivial to do (particularly if we decide that teletexString is really
>>just a mis-labelled IA5String).
>
>Correction: You mean mis-labelled ISO-8859-1 string, not IA5String.
>An IA5String is limited to the ASCII character range.

You're right - I meant 8859-1.

>This seems attractive for the [UTF-8, PrintableString, BMPString] camp;
>less so for the T61String quagmire. You always have the risk of someone
>*really* using the capabilities of T61String.....

PKIX has to decide how it wants to interpret a string that claims to be a
T61string.  Whichever way we go on that issue, I believe that we have to
require codeset widening before comparing attributes, at least if the
attributes are encoded using different syntaxes.

John

Date: Wed, 24 Jun 1998 09:53:11 -0400
To: [email-masked]
From: Tim Polk <[email-masked]>
Subject: Re: PKIX-1 - use of UTF8
Cc: [email-masked]
Sender: [email-masked]

John,

You wrote:

>I don't think that's true.  Under the assumption that the stated name

>comparison rules would be applied when evaluating name constraints as
well

>as when chaining issuer and subject names, a system that implemented
the

>PKIX matching rules might fail to enforce an excluded subtree
constraint

>that a codeset-converting implementation would catch.  This would result
in

>a system that implemented the PKIX-1 rules verifying a chain against
the

>expressed intentions of one of the CAs in that chain, whereas a system
that

>performed codeset conversion would correctly refuse to accept the
chain.

>

You are correct.  I hadn't given much thought to the implications of name
matching in the name constraints area.  After brief though, it looks like
included subtrees are "safe", but excluded subtrees could be trouble.  At
the least the name constraints section needs some cautionary words to
convey that.

This may also serve as a lever to encourage vendors to implement codeset
sonversion.

You also wrote:

>

>There are two parts to this issue:

>

>i) The rules for choosing codesets for emitted certificates

>

>ii) The rules for matching names within certificates.

>

>The problem is that choosing rules for (ii) that permits conforming

>implementations to consider the codeset as part of the name pretty 
much

>means that we can't change the rules for (i) without breaking things

>horribly.  This prevents a graceful migration to a different preferred

>codeset.

>

>In the following, I'm going to call a system that implements the
current

>PKIX-1 rules an "Old" system, and one that emits certificates in UTF-8
a

>"New" system (under the assumption that UTF-8 is where we'd like to 
get

>to).  Similarly, "Old Certificates" contain names using the current
PKIX-1

>codeset selection rules, and "New Certificates" use UTF-8.

>

>Old end-systems will be able to chain two certificates only if the names
in

>those certificates are expressed in the same codeset.  This means that,
in

>order to migrate to UTF-8, entire certificate chains will have to be

>replaced in one step, since old systems will not be able to chain old
and

>new certificates together.

>

>Old CAs will only emit old certificates.  Therefore any certificate
chain

>that includes an old CA cannot migrate to new certificates, but must

>continue to use old certificates.

>

>

>Basically, the current rules appear to force us to retain today's

>multiplicity of codesets indefinitely.  Mandating codeset-conversions
prior

>to comparison lets us prepare for a future migration to a single
codeset.

>

I don't think this is true.  I proposed the following solution to support
a hard cutover to UTF8 encodings in 2003 on a different thread:

<paraindent><param>left</param>I think a hard cutover in 2003 could be
managed, though. Certificates *issued* after January 1, 2003 could be
required to use the UTF8String encodings.  The one exception would be
"name rollover" certificates for CAs changing their own names to the
UTF8String encodings.  (This sounds ugly, but we'll be doing it for key
rollover anyway.  CAs can just do them both at the same time.)

</paraindent>

Key rollover certificates are self-signed certificates (issuer = subject)
where the new signing key is certified by the old signing key, or
vice-versa.   A name rollover certificate would have the issuer name in
the old (e.g., T61) encoding and subject name in UTF8, or vice-versa.  I
expect CAs to perform key rollover regularly. A small amount of planning
will allow the CA to combine the two functions - that is name and key
rollover can be performed together.

I think this resolves the problem of codeset migration.  Am I missing
something?

>

>

>>Implementors requested the "minimum" requirements be added because

>>they consider the name conversion an unbounded burden.  It would

>>require constant code maintenance as the character sets are enhanced

>>or modified. I tend to agree.  I think specifying the minimum

>>requirements, and encoding rules to match, will greatly enhance

>>interoperability.

>

>

>I think the big implementation problem with name comparisons isn't
codeset

>conversion, but instead concerns how to compare strings in an
"extended"

>codeset.  For example, the ability to encode characters with accents 
as

>either "accent"+"character" or as "accented character".  Also the
problems

>of case-insensitive comparison.  I'm quite happy to punt on those
issues

>and simply mandate a byte-for-byte equivalence, as it's a hard problem,
and

>we don't have a answer that we'd like to migrate to.  The case of
codeset

>conversion is different though, since it's fairly trivial to do

>(particularly if we decide that teletexString is really just a
mis-labelled

>IA5String).

>

I would certainly agree that constructed characters and case-sensitivity
are difficult problems.  Constructed characters seems an intractable
problem, and upper and lower case is not well defined for some codesets. 
(On the latter point, I'm repeating hearsay.  Hope it was correct!)

I think byte-for-byte comparison is acceptable for the near-term.  It is
something implementors can reasonably implement, and codeset conversion
can always be supported as an added value feature.  I would advocate
keeping the name matching rules, and revisiting the issue when we
progress to Draft RFC.

>

>John

>

>

>

Tim

Date: Wed, 24 Jun 1998 07:57:41 -0400
To: [email-masked], Tim Polk <[email-masked]>
From: Harald Alvestrand <[email-masked]>
Subject: Re: PKIX-1 - use of UTF8
Cc: [email-masked]
Sender: [email-masked]

At 15:04 23.06.98 -0400, [email-masked] wrote:
>
>There are two parts to this issue:
>
>i) The rules for choosing codesets for emitted certificates
>
>ii) The rules for matching names within certificates.
>
>The problem is that choosing rules for (ii) that permits conforming
>implementations to consider the codeset as part of the name pretty much
>means that we can't change the rules for (i) without breaking things
>horribly.  This prevents a graceful migration to a different preferred
>codeset.
>
>In the following, I'm going to call a system that implements the current
>PKIX-1 rules an "Old" system, and one that emits certificates in UTF-8 a
>"New" system (under the assumption that UTF-8 is where we'd like to get
>to).  Similarly, "Old Certificates" contain names using the current PKIX-1
>codeset selection rules, and "New Certificates" use UTF-8.

You are making the assumption here that the same codeset is used for
all attributes of all names within a certificate.
Is this a requirement of the infrastructure?

>Basically, the current rules appear to force us to retain today's
>multiplicity of codesets indefinitely.  Mandating codeset-conversions prior
>to comparison lets us prepare for a future migration to a single codeset.

>I think the big implementation problem with name comparisons isn't codeset
>conversion, but instead concerns how to compare strings in an "extended"
>codeset.  For example, the ability to encode characters with accents as
>either "accent"+"character" or as "accented character".  Also the problems
>of case-insensitive comparison.  I'm quite happy to punt on those issues
>and simply mandate a byte-for-byte equivalence, as it's a hard problem, and
>we don't have a answer that we'd like to migrate to.  The case of codeset
>conversion is different though, since it's fairly trivial to do
>(particularly if we decide that teletexString is really just a mis-labelled
>IA5String).

Correction: You mean mis-labelled ISO-8859-1 string, not IA5String.
An IA5String is limited to the ASCII character range.

This seems attractive for the [UTF-8, PrintableString, BMPString] camp;
less so for the T61String quagmire. You always have the risk of someone
*really* using the capabilities of T61String.....

                      Harald A

-- 
Harald Tveit Alvestrand, Maxware, Norway
[email-masked]
On holiday June 28 to July 17. Expect delays in responses!

Date: Wed, 24 Jun 1998 12:40:26 +0200
From: Andreas Berger <[email-masked]>
To: Ambarish Malpani <[email-masked]>
CC: IETF PKIX <[email-masked]>
Subject: Re: New OCSP draft
Sender: [email-masked]

Ambarish Malpani wrote:
> 
> Hi All,
>     We have put out a new version of the OCSP draft. While we
> wait for it to be put up on the IETF site, it is available at:
> 
> ftp://ftp.valicert.com/pub/draft-ietf-pkix-ocsp-04.txt
> 
> The main changes are:
> 1. Changed the optional signed requests quite a bit.
> 2. Changed the way a certificate is identified to use the hash of the
> issuer's DN, to enable HTTP caching to work better
> 3. Added support for both GET/POST in making OCSP requests over HTTP
> (again, to better support caching)
> 4. Changed the format for the result status
> 5. Added information about how to check/not check an authorized
> OCSP responder for revocation.
> 6. Allow responder to be identified by name/key
> 
> Please let me know about your feedback ASAP.
First of all, I like the new draft better then the previous version, a
lot of the issues that I had problems with were resolved. I would like
to make some comments on the protocol.

As a preface, we try to specify a profile for OCSP for use in the
on-line revocation check mandated in the German Signature Law. So some
of the comments I make are with that application in mind.

1. OCSPResponseStatus:
certRequired: How are situations handled when status for multiple
certificates is requested and for just on the certificate is required.
This result code should probably be moved to "CertStatus" so that an
OCSP responder can produce this answer for each requested certificate
individually.

2. SingleResponse/CertStatus
Shouldn't possibility of "I do know the CA but I am unable to answer the
request, pls. ask here" be added to a response? This would minimize the
configuration on the client.

3. CertStatus
I would really love to see the addition of notIssued to the list of
result codes. This would mean "I know about the CA and all the
certificates it has ever issued, but the certificate presented is *not*
on my list".

4. OCSPRequest
Addition of an extension that allows a requester to specify the point in
time it wants information for. Then it is possible to ask: "I have a
signature produced last week, was the certificate used in that process
valid then?".

THNX
Andreas
-- 
Microsoft -- definitly needs Viagra

Date: Wed, 24 Jun 1998 12:08:40 +0200
To: Russ Housley <[email-masked]>, Paul Hoffman / IMC <[email-masked]>
From: Nada Kapidzic Cicovic <[email-masked]>
Subject: Re: SV: new profile submitted
Cc: [email-masked]
Sender: [email-masked]

I do not understand the point of changing the key id calculation algorithm
this late in pkix part 1 last call. 

Is the size of the resulting key id the only problem with the old algorithm
definition?

Is this size really an issue for S/MIME messages?

I would prefer changing the definition back to what it was, since we have
already released the software implementing it in the old way, and we are
probably not the only one.

Regards,

Nada

At 20:55 6/23/98 -0400, Russ Housley wrote:
>The PKIX Part 1 key identifier will be used in S/MIME to identify the
>per-recipient information necessary for a recipient to perform decryption.
>As stated in a previous message, collisions are not a problem here.
>However, this key identifier will not be used to identify a particular
>certificate used by an originator to sign a message content.  Collisions
>could cause significant confusion in this circumstance.
>
>Russ
>
>
>At 12:11 PM 6/23/98 -0700, Paul Hoffman / IMC wrote:
>>I think the question here is whether or not it is useful to have the same
>>key identifier for both PKIX part 1 and OCSP. If it is, then we need to
>>choose one that works for both. Ambarish says that 60 bits, with the
>>possibility of collision, is not strong enough for OCSP. If that's true, we
>>need to decide if the two key identifiers have to be the same, or whether
>>we can use a shorter one for PKIX part 1 and a longer one for OCSP.
>>
>>--Paul Hoffman, Director
>>--Internet Mail Consortium
>> 
>

Date: Tue, 23 Jun 1998 20:55:42 -0400
To: Paul Hoffman / IMC <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: SV: new profile submitted
Cc: [email-masked]
Sender: [email-masked]

The PKIX Part 1 key identifier will be used in S/MIME to identify the
per-recipient information necessary for a recipient to perform decryption.
As stated in a previous message, collisions are not a problem here.
However, this key identifier will not be used to identify a particular
certificate used by an originator to sign a message content.  Collisions
could cause significant confusion in this circumstance.

Russ

At 12:11 PM 6/23/98 -0700, Paul Hoffman / IMC wrote:
>I think the question here is whether or not it is useful to have the same
>key identifier for both PKIX part 1 and OCSP. If it is, then we need to
>choose one that works for both. Ambarish says that 60 bits, with the
>possibility of collision, is not strong enough for OCSP. If that's true, we
>need to decide if the two key identifiers have to be the same, or whether
>we can use a shorter one for PKIX part 1 and a longer one for OCSP.
>
>--Paul Hoffman, Director
>--Internet Mail Consortium
> 

Date: Tue, 23 Jun 1998 15:40:58 -0400
From: [email-masked]
To: [email-masked]
Reply-To: [email-masked]
Subject: Is Your Web Site Posted?
Sender: [email-masked]

To: [email-masked] 

     Is Your Web Site Posted?
     SitePoster will post your site to 50 search engines for $89. 
     We guarantee your satisfaction, or you pay nothing!

Millions of people every day use search engines to find web sites.
SitePoster makes your site easier to find by posting it to the top 50 search engines.

Here's how it works:

1.  Fill out the form below, and return it to us.

2.  We'll post your site to the top 50 search engines within two business days and send 
you a full promotion report.

3.  Pay nothing now.  We'll send you a bill for $89 with the promotion report.  If you're 
not completely happy, simply write "cancel" on the bill, and you'll owe nothing.

THE SEARCH ENGINES

Here's the list of top search engines to which we'll post your site:

Alta Vista, Excite, Galaxy, HotBot, Infoseek, Lycos, Magellan, Open Text Web Index,
Web Crawler, BizWeb, New Riders WWW Yellow Pages, LinkMonster, True North, 
Northern Light, YelloWWWeb, The Weekly Bookmark, The Galactic Galaxy, TurnPike,
Unlock:The Information Exchange, Your WebScout, Manufacturers Information
Network, Net Happenings, Net Mall, Web World  Internet Directory, WebVenture
Hotlist, What's New, WhatUSeek, JumpLink, Linkcentre Directory, InfoSpace, Jayde
Online Directory, BC Internet, BizCardz Business Directory, Net-Announce, New Page
ListOne World Plaza, PageHost A-Z, PeekABoo, Project Cool, Scrub The Web, Seven
Wonders, Sserv, Starting Point, Web 100, Web Walker, Where2Go, World Wide Business
Yellow Pages, Wow! Web Wonders!, WWW Worm, JumpCity.

ORDER FORM

Hit the REPLY button on your e-mail program and fill out the following information.
 (This information will be posted to the search engines/indexes):

URL:  http://
Site Title: 
Description (250 characters): 

Key words (250 characters, in descending order of importance):

Your name: 
Company Name:
Address:
City:              State/Prov:     Zip/Postal Code: 
Telephone: 
Fax: 
Email address: 

Contact e-mail address (in case we have questions about this order): 

If  billing a different address, please complete the following:

Addressee: 
Company Name:
Address:
City:              State/Prov:     Zip/Postal Code: 
Telephone: 
Fax: 
Email address: 

TERMS

Terms are net 15 days from date of invoice.

______________________________________________________________________
SitePoster, Inc.
1440 Whalley Avenue - Suite 239
New Haven, CT 06515
Phone: (203) 928-9207
Fax:     (203) 389-8074
E-mail: [email-masked]

Date: Tue, 23 Jun 1998 16:50:04 -0700
From: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
To: IETF PKIX <[email-masked]>
Subject: New OCSP draft
Sender: [email-masked]

Hi All,
    We have put out a new version of the OCSP draft. While we
wait for it to be put up on the IETF site, it is available at:

ftp://ftp.valicert.com/pub/draft-ietf-pkix-ocsp-04.txt

The main changes are:
1. Changed the optional signed requests quite a bit.
2. Changed the way a certificate is identified to use the hash of the
issuer's DN, to enable HTTP caching to work better
3. Added support for both GET/POST in making OCSP requests over HTTP
(again, to better support caching)
4. Changed the format for the result status
5. Added information about how to check/not check an authorized
OCSP responder for revocation.
6. Allow responder to be identified by name/key

Please let me know about your feedback ASAP.

Thanks,
Ambarish

-- 
---------------------------------------------------------------------
Ambarish Malpani
Architect					       (650) 849-9880
ValiCert, Inc.				        [email-masked]
3160 W. Bayshore Road		              http://www.valicert.com
Palo Alto, CA 94303

Date: Tue, 23 Jun 1998 13:37:32 -0600
From: Mike Smith <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: SV: new profile submitted
Sender: [email-masked]

Russ, Paul, Ambarish:

SHA-1 is not supposed to be very good at hashing small (in size) objects; SHA-1 ends up being 160 bits; we need to reconcile the two standards: why not use something the size of which does not weaken SHA-1.

Not being a cryptographer, I hesitate to recommend an alternative for key identifier.

Michael
>>> Paul Hoffman / IMC <[email-masked]> 06/23 1:11 PM >>>
I think the question here is whether or not it is useful to have the same
key identifier for both PKIX part 1 and OCSP. If it is, then we need to
choose one that works for both. Ambarish says that 60 bits, with the
possibility of collision, is not strong enough for OCSP. If that's true, we
need to decide if the two key identifiers have to be the same, or whether
we can use a shorter one for PKIX part 1 and a longer one for OCSP.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Tue, 23 Jun 1998 12:11:18 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: SV: new profile submitted
Sender: [email-masked]

I think the question here is whether or not it is useful to have the same
key identifier for both PKIX part 1 and OCSP. If it is, then we need to
choose one that works for both. Ambarish says that 60 bits, with the
possibility of collision, is not strong enough for OCSP. If that's true, we
need to decide if the two key identifiers have to be the same, or whether
we can use a shorter one for PKIX part 1 and a longer one for OCSP.

--Paul Hoffman, Director
--Internet Mail Consortium

From: [email-masked]
To: Tim Polk <[email-masked]>
cc: [email-masked]
Date: Tue, 23 Jun 1998 15:04:34 -0400
Subject: Re: PKIX-1 - use of UTF8
Sender: [email-masked]

Tim Polk <[email-masked]> writes:

>I have a slightly different interpretation of the name comparison
>rules in POKIX-1 than you presented below.  The text was *intended*
>to state the minimum rules for name comparison.  Consider two
>implementations - (a) implements only the PKIX-1 requirements, and
>(b) implements the rules you propose.  Any certificate path whose
>names chain for (a) will chain for (b) as well.

I don't think that's true.  Under the assumption that the stated name
comparison rules would be applied when evaluating name constraints as well
as when chaining issuer and subject names, a system that implemented the
PKIX matching rules might fail to enforce an excluded subtree constraint
that a codeset-converting implementation would catch.  This would result in
a system that implemented the PKIX-1 rules verifying a chain against the
expressed intentions of one of the CAs in that chain, whereas a system that
performed codeset conversion would correctly refuse to accept the chain.

>The converse is *not* true; the implementations translating to the
>great character set in the sky would accept additional paths.  CAs
>that cared about interoperability would issue certs conforming to
>the encoding rules so that both implementations worked.
>
>Anyway, an implementation that converted to a standard syntax prior
>to comparison should be conformant to the specification.  It is an
>upwardly compatible enhancement, and no one intended to rule this out.
>Perhaps an additional paragraph clarifying this would be appropriate.
>

There are two parts to this issue:

i) The rules for choosing codesets for emitted certificates

ii) The rules for matching names within certificates.

The problem is that choosing rules for (ii) that permits conforming
implementations to consider the codeset as part of the name pretty much
means that we can't change the rules for (i) without breaking things
horribly.  This prevents a graceful migration to a different preferred
codeset.

In the following, I'm going to call a system that implements the current
PKIX-1 rules an "Old" system, and one that emits certificates in UTF-8 a
"New" system (under the assumption that UTF-8 is where we'd like to get
to).  Similarly, "Old Certificates" contain names using the current PKIX-1
codeset selection rules, and "New Certificates" use UTF-8.

Old end-systems will be able to chain two certificates only if the names in
those certificates are expressed in the same codeset.  This means that, in
order to migrate to UTF-8, entire certificate chains will have to be
replaced in one step, since old systems will not be able to chain old and
new certificates together.

Old CAs will only emit old certificates.  Therefore any certificate chain
that includes an old CA cannot migrate to new certificates, but must
continue to use old certificates.

Basically, the current rules appear to force us to retain today's
multiplicity of codesets indefinitely.  Mandating codeset-conversions prior
to comparison lets us prepare for a future migration to a single codeset.

>Implementors requested the "minimum" requirements be added because
>they consider the name conversion an unbounded burden.  It would
>require constant code maintenance as the character sets are enhanced
>or modified. I tend to agree.  I think specifying the minimum
>requirements, and encoding rules to match, will greatly enhance
>interoperability.

I think the big implementation problem with name comparisons isn't codeset
conversion, but instead concerns how to compare strings in an "extended"
codeset.  For example, the ability to encode characters with accents as
either "accent"+"character" or as "accented character".  Also the problems
of case-insensitive comparison.  I'm quite happy to punt on those issues
and simply mandate a byte-for-byte equivalence, as it's a hard problem, and
we don't have a answer that we'd like to migrate to.  The case of codeset
conversion is different though, since it's fairly trivial to do
(particularly if we decide that teletexString is really just a mis-labelled
IA5String).

John

Date: Tue, 23 Jun 1998 15:03:41 -0400
To: Ambarish Malpani <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: SV: new profile submitted
Cc: Nilsson Hans <[email-masked]>, "'Tim Polk'" <[email-masked]>, [email-masked]
Sender: [email-masked]

Ambarish:

In my mind, the point of key identifier is to have a short identifier for
the key.  It does not have to be collision free.

S/MIME (and other security protocols) use the key identifier to identify
the their own per-recipient information.  In the unlikely event that two
recipients have the same 60 bit value, then each of the values with the
same 60-bit value can be tried.

The structure that you propose is quite a but longet the 64 bits.  My
personal desire is a realtively short identifier.  Using the first four
bits an a type, allow us to pick some other hash if SHA-1 does not meet the
community's needs in the long run.

Russ

At 04:23 PM 6/22/98 -0700, Ambarish Malpani wrote:
>Hi Tim, Russ,
>    I, too, am concerned about this new definition of KeyIdentifier.
>As you know, we are trying to use the hash of the issuer's public
>key to distinguish between two issuers with the same DN. I was
>hoping that applications that are sensitive to the cost of even
>a hashing operation, be able to use the keyIdentifier in the
>cert if it had the AuthorityKeyIdentifier extension.
>
>2 points:
>
>1. With this new definition, applications can't rely on using
>keyIdentifier at all, since it is only 64 bits and there could
>be a lot more collisions - either deliberate, or accidental.
>
>2. Even with the old definition, it was unclear if the keyIdentifier
>was actually the SHA1 hash or some random number that the CA decided
>to use, since the keyIdentifier was not required to be the SHA1
>hash.
>
>I would prefer something like:
>
>KeyIdentifier ::= SEQUENCE {
>    algorithmIdentifier		AlgorithmIdentifier,
>    data			OCTET STRING }
>
>Regards,
>Ambarish
>
>Russ Housley wrote:
>> 
>> Hans:
>> 
>> >Can you please explain the background for the new writing regarding
>> >subjectKeyIdentifier, using 0100 + 60 bits from the SHA-1 hash of the BIT
>> >STRING subjectPublicKey? Is this in conformance with something else, or a
>> >new invention?
>> 
>> This aligns PKIX with a specification used by the US Government.  Neither
>> Tim not I saw any harm in adopting the format.  Further, the use of a
>> prefix allows PKIX to specify a different means of computing the key
>> identifier if the SHA-1 method should ever be discovered to be deficient.
>> 
>> Russ
>
>-- 
>---------------------------------------------------------------------
>Ambarish Malpani
>Architect					       (650) 849-9880
>ValiCert, Inc.				        [email-masked]
>3160 W. Bayshore Road		              http://www.valicert.com
>Palo Alto, CA 94303
> 

Date: Tue, 23 Jun 1998 14:03:29 -0700
To: [email-masked]
From: Warwick Ford <[email-masked]>
Subject: Last Call - Profile
Sender: [email-masked]

The PKIX Profile is issued for a 2-week WG last call.  Given no major
objections, it will then be forwarded to the IESG with a recommendation for
progression to Proposed Standard.  Thanks to Tim and Russ for their
extensive efforts with the editing.

Warwick

--------
There was a delay at the IETF in getting new drafts into the official draft
directory. The new PKIX part 1 is now there, and is also mirrored at
<http://www.imc.org/draft-ietf-pkix-ipki-part1>.

--Paul Hoffman, Director
--Internet Mail Consortium

>Date: Tue, 16 Jun 1998 17:28:41 -0400
>To: [email-masked]
>From: Tim Polk <[email-masked]>
>Subject: new profile submitted
>Cc: [email-masked], [email-masked], [email-masked]
>
>
>I have submitted the new draft of the profile.  In the interim, you can get
>it via the following URL:
>
>http://csrc.nist.gov/pki/draft-ietf-pkix-ipki-part1-08.txt
>
>It corporates all changes discussed in LA, but CRL distribution points was
>not excised from the draft.  After extensive negotiations, new licensing
>terms were completed THIS MORNING.
>
>(I will not speak to the agreement - I'm leaving that for Jeff Schiller.) 
>
>Brief Notes:
>
>#1 I am asking for Last Call.
>
>#2 If you want something changed, please submit your suggestions to the
>list WITH TEXT.  We want to forward this to the IESG as soon as possible.
>That will not be possible if we discuss abstract changes on the list.
>Concrete text is a MUST.
>
>#3 The document isn't really longer - the ASN.1 in the appendices is simply
>more complete.
>
>Thanks,
>
>Tim Polk
>
>

---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., Tel (781)2456996 x225; Fax (781)2456006
[email-masked];  301 Edgewater Pl, Suite 210, Wakefield, MA 01880
---------------------------------------------------------------------

Date: Tue, 23 Jun 1998 11:46:34 -0400
To: [email-masked]
From: Tim Polk <[email-masked]>
Subject: Re: Limiting non-UTF-8 kludges
Sender: [email-masked]

At 04:17 PM 6/22/98 -0700, Chris Newman wrote:

>Perhaps it would be possible to require UTF8String for all
certificates,

>with a short-term exception permitted for RSA certificates intended 
for

>use on the https port with SSL.  Is there any other significant
installed

>base? 

>

>Since the TLS and S/MIME standards will make DSS certs mandatory to

>implement, why not cut over to UTF8String at the same time?

>

UTF8String will be added to the ISO DirectoryString definition in the
next version, I believe.  There is no installed base, and there will be a
significant lag time to widespread implementation.  "Cutting over" to
UTF8String as the only choice for DirectoryString would, in my opinion,
be a mistake.  In my opinion, the installed base warrants backwards
compatability.

I think a hard cutover in 2003 could be managed, though. Certificates
*issued* after January 1, 2003 could be required to use the UTF8String
encodings.  The one exception would be "name rollover" certificates for
CAs changing their own names to the UTF8String encodings.  (This sounds
ugly, but we'll be doing it for key rollover anyway.  CAs can just do
them both at the same time.)

>Using T61String as a false label for Latin1String makes me nervous. 
I'd

>prefer to forbid generation of T61String in PKIX, even if acceptance 
is

>permitted for backwards compatibility reasons.

>

It makes me nervous as well, but it sounds like we must accomodate it.
Peter and As I see it, we have two options:

<paraindent><param>left</param>(1) The specification remains the same for
name encoding (PrintableString, BMPString, or UTF8String in that order)
but "strongly recommend that implementations be prepared to accept" the
Latin1String character set in the T61String type.  

</paraindent><paraindent><param>left</param>(2) Replace BMPString with T61String as
the second choice for name encoding and specify the the Latin1String
characters be recognized by conforming implementations.

</paraindent>

Since BMPString is not widely implemented, the T61String/Latin1String
kludge is widely implemented, and we would be transitioning to UTF8String
in 2003, choice (2) seems the better choice.

>Using BMPString also makes me nervous.  What byte-order is that?  What

>does it mean if there are characters from the surrogate range -- is it

>really just UTF-16 mislabelled?  Is the BOM required or not?  Is there
a

>version of the charset registered with IANA that's suitable? (I know

>version 1.0 is registered, but that's incompatible with version 2.0)

>

I was not aware of any ambiguities with BMPString.  Maybe this is another
good reason to deprecate its use.

>I'm including the relevant IETF policy from RFC 2277.  If PKIX doesn't

>follow this, then the spec will be booted back to the WG by the IESG. 
In

>particular, a cert using UTF8 MUST be compliant with PKIX regardless 
of

>what other forms are permitted.

I believe the current text satisfies the IESG requirements.  (One
exception: I don't know if BMPString or T61String have been registered in
the IANA character set registry.)  Any changes we contemplate MUST
continue to satisfy those requirements.

>

>   Protocols MUST be able to use the UTF-8 charset, which consists of

>   the ISO 10646 coded character set combined with the UTF-8 character

>   encoding scheme, as defined in [10646] Annex R (published in

>   Amendment 2), for all text.

>

>   Protocols MAY specify, in addition, how to use other charsets or

>   other character encoding schemes for ISO 10646, such as UTF-16, but

>   lack of an ability to use UTF-8 is a violation of this policy; such
a

>   violation would need a variance procedure ([BCP9] section 9) with

>   clear and solid justification in the protocol specification 
document

>   before being entered into or advanced upon the standards track.

>

>   For existing protocols or protocols that move data from existing

>   datastores, support of other charsets, or even using a default 
other

>   than UTF-8, may be a requirement. This is acceptable, but UTF-8

>   support MUST be possible.

>

>   When using other charsets than UTF-8, these MUST be registered in
the

>   IANA charset registry, if necessary by registering them when the

>   protocol is published.

>

>		- Chris

>

>

>

Date: Tue, 23 Jun 1998 11:41:59 -0400
To: [email-masked], [email-masked]
From: Tim Polk <[email-masked]>
Subject: Re: PKIX-1 - use of UTF8
Cc: [email-masked]
Sender: [email-masked]

John,

I have a slightly different interpretation of the name comparison rules in
POKIX-1 than you presented below.  The text was *intended* to state the
minimum rules for name comparison.  Consider two implementations - (a)
implements only the PKIX-1 requirements, and (b) implements the rules you
propose.  Any certificate path whose names chain for (a) will chain for (b)
as well.

The converse is *not* true; the implementations translating to the great
character set in the sky would accept additional paths.  CAs that cared
about interoperability would issue certs conforming to the encoding rules
so that both implementations worked.

Anyway, an implementation that converted to a standard syntax prior to
comparison should be conformant to the specification.  It is an upwardly
compatible enhancement, and no one intended to rule this out.  Perhaps an
additional paragraph clarifying this would be appropriate.

Implementors requested the "minimum" requirements be added because they
consider the name conversion an unbounded burden.  It would require
constant code maintenance as the character sets are enhanced or modified.
I tend to agree.  I think specifying the minimum requirements, and encoding
rules to match, will greatly enhance interoperability.

Another side point - if a CA chooses to use the basic local character set
anyway for end entities, this has only minor consequences.  Some
implementations that might be able to display the subject name in the more
restrictive character set, but not in the user's local character set.  For
example, an implementation might be able to display "Fred", but would not
recognize it in T61String.

A CA cannot choose to "switch" character sets for CA names, though.
Consider a CA certificate issued by a US CA to a Japanese CA.  Switching to
local character sets involves translation, not encoding.  (I realize this
is more radical than what you are thinking of, but it is the logical
extension.) The solution is to use the subject's chosen encoding in the
subject field and the issuer's local encoding/translation in the subject
alternative name field.

Tim Polk

>Interoperability with current code.  Firstly, UTF8 and BMPString are recent
>additions to the permitted syntaxes for directoryString, and certificates
>using either of these syntaxes are unlikely to be understood by deployed
>code.  Also, there's a slightly less serious problem in that PKIX has
>currently adopted a very strict set of rules for comparison of strings (for
>example, during certificate chain processing).  PKIX-1 mandates that two
>strings are considered different if they are encoded using different
>syntaxes, regardless of their contents.  This means that if PKIX issues
>certificates encoded using UTF8 or BMPString, those certificates can never
>be part of the same trust chain as a certificate issued by a system that
>chooses a different syntax.
>
>>Finally, what does it mean to say that a character set is "sufficient"?
>>Does this mean that a given character string has to be examined
>>one character at a time to see whether an accented character just
>>happens to be included in that person's name, for example?
>
>Yes, that's pretty much it.
>
>>Or, as I would prefer, can the decision be made on the basis of the
>>basic code set in use, so  that a user who normally uses German
>>would always their input encoded the same way, regardless of the
>>actual characters used?
>
>Not with the current PKIX string matching rules.  "Fred" encoded as a
>printableString is defined as different to "Fred" encoded as a BMPString,
>or UniversalString, or UTF8String - all of these "Fred"s have to be
>considered as distinct and different names, even though it's trivial to
>convert between those encodings.  Because of this, PKIX has to mandate the
>encoding syntax used, so that certificates have a chance of chaining
>properly.
>
>In another message, I suggested a relaxation of the matching rules to allow
>conversion to a standard syntax prior to comparison.  This would make it
>possible for us to change or relax the rules for picking a syntax to use
>when emitting certificates, if we so desired.  This would allow us to use
>the current arcane rules for a transition period so that PKIX can
>interoperate with current systems, but in the future, when more systems
>understand UTF8, PKIX could switch to specifying that as the prefered
>syntax, without breaking anything.
>
>John
>
>
>

Date: Tue, 23 Jun 1998 08:31:26 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: new profile submitted
Sender: [email-masked]

There was a delay at the IETF in getting new drafts into the official draft
directory. The new PKIX part 1 is now there, and is also mirrored at
<http://www.imc.org/draft-ietf-pkix-ipki-part1>.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Mon, 22 Jun 1998 07:24:07 -0400
To: [email-masked], [email-masked], [email-masked]
From: Harald Tveit Alvestrand <[email-masked]>
Subject: Re: PKIX-1 - use of UTF8
Sender: [email-masked]

At 12:49 19.06.98, Peter Gutmann wrote:
>Actually it's none of the above.  What I meant was:
> 
>    (b) failing (a), if the latin-1 (ISO 8859-1) character set is sufficient
>the string shall be represented as a latin-1 string with a T61String tag.

A sad state of affairs indeed.

>(that may not be the best way to say it, what I mean here is to use straight
>latin-1 but tag it as a T61String).
> 
>Before people start dusting off their flamethrowers, the reason for this is
>twofold:
> 
>1. It codifies existing practice.  I've never found a single certificate in
>   which a T61String really is a T61String - in every case it's latin-1 (if
>   anyone has an example of a cert with a real T.61 string, please send me a
>   copy for my collection).  For all implementations I know of, T61String
>   currently *is* Latin1String.

I can't speak for certificates, but in other usages of a DN, there are
definitely both services running "real" T.61 and "Latin1" T.61.
It's a pain in the posterior, indeed.

>2. T.61 has apparently been withdrawn by the ITU, so it's not even
possible to
>   get a copy of this in order to comply with it.  For people who have seen
>   this or related standards like T.51/52, withdrawing it is probably a good
>   move (IMNSHO any standard which requires diagrams extending into three
>   dimensions in order to explain how to encode an a-umlaut has problems).
>   T61String in itself (without complex escape codes and shifting) is next to
>   useless because there's almost nothing which is common to latin-1 and
>   straight T.61, and once you add the escape codes it's unworkable.
> 

T61String isn't defined in T.61, but in X.680 and X.208 - the ASN.1
standards. It's defined as a profile on unrestricted ISO 2022 character
set switching - you ARE allowed to encode Latin1 into a T61String, but
you have to insert the right escape-sequence gook first.
Naturally, this standard is *somewhat* removed from reality.

>>X.509 doesn't contain an option for an 8-bit Western European codeset. If we
>>want to stay within the standard, we have to go multibyte to get accented
>>characters.
> 
>X.509 doesn't handle latin-1, but (AFAIK) every existing implementation -
tens
>of millions - do by treating T61String as Latin1String.  All you need to
do to
>work with this is add a single sentence to PKIX which codifies this practice.
>There's simply too large an installed base out there to change it now, and
>mandating an immediate unconditional switch to UTF8 for vendors is suicidal
>because any certificates their software issues will be regarded as invalid by
>virtually every application which makes use of certificates.

Actually a requirement that you compare two attributes byte by byte
will effectively nullify the problem - if you compare bytes and not
characters, it doesn't matter what the characters represent.

It's just a "#¤%&/( pain in the user interface.

My thought: This is indeed a good argument for refusing to emit T61
strings at all.

               Harald

-- 
Harald Tveit Alvestrand, Maxware, Norway
[email-masked]

Date: Mon, 22 Jun 1998 16:23:29 -0700
From: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
To: Russ Housley <[email-masked]>
CC: Nilsson Hans <[email-masked]>, "'Tim Polk'" <[email-masked]>, [email-masked]
Subject: Re: SV: new profile submitted
Sender: [email-masked]

Hi Tim, Russ,
    I, too, am concerned about this new definition of KeyIdentifier.
As you know, we are trying to use the hash of the issuer's public
key to distinguish between two issuers with the same DN. I was
hoping that applications that are sensitive to the cost of even
a hashing operation, be able to use the keyIdentifier in the
cert if it had the AuthorityKeyIdentifier extension.

2 points:

1. With this new definition, applications can't rely on using
keyIdentifier at all, since it is only 64 bits and there could
be a lot more collisions - either deliberate, or accidental.

2. Even with the old definition, it was unclear if the keyIdentifier
was actually the SHA1 hash or some random number that the CA decided
to use, since the keyIdentifier was not required to be the SHA1
hash.

I would prefer something like:

KeyIdentifier ::= SEQUENCE {
    algorithmIdentifier		AlgorithmIdentifier,
    data			OCTET STRING }

Regards,
Ambarish

Russ Housley wrote:
> 
> Hans:
> 
> >Can you please explain the background for the new writing regarding
> >subjectKeyIdentifier, using 0100 + 60 bits from the SHA-1 hash of the BIT
> >STRING subjectPublicKey? Is this in conformance with something else, or a
> >new invention?
> 
> This aligns PKIX with a specification used by the US Government.  Neither
> Tim not I saw any harm in adopting the format.  Further, the use of a
> prefix allows PKIX to specify a different means of computing the key
> identifier if the SHA-1 method should ever be discovered to be deficient.
> 
> Russ

-- 
---------------------------------------------------------------------
Ambarish Malpani
Architect					       (650) 849-9880
ValiCert, Inc.				        [email-masked]
3160 W. Bayshore Road		              http://www.valicert.com
Palo Alto, CA 94303

Date: Mon, 22 Jun 1998 16:17:26 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: Limiting non-UTF-8 kludges
To: [email-masked]
Originator-Info: login-id=chris; server=THOR.INNOSOFT.COM
Sender: [email-masked]

Perhaps it would be possible to require UTF8String for all certificates,
with a short-term exception permitted for RSA certificates intended for
use on the https port with SSL.  Is there any other significant installed
base? 

Since the TLS and S/MIME standards will make DSS certs mandatory to
implement, why not cut over to UTF8String at the same time?

Using T61String as a false label for Latin1String makes me nervous.  I'd
prefer to forbid generation of T61String in PKIX, even if acceptance is
permitted for backwards compatibility reasons.

Using BMPString also makes me nervous.  What byte-order is that?  What
does it mean if there are characters from the surrogate range -- is it
really just UTF-16 mislabelled?  Is the BOM required or not?  Is there a
version of the charset registered with IANA that's suitable? (I know
version 1.0 is registered, but that's incompatible with version 2.0)

I'm including the relevant IETF policy from RFC 2277.  If PKIX doesn't
follow this, then the spec will be booted back to the WG by the IESG.  In
particular, a cert using UTF8 MUST be compliant with PKIX regardless of
what other forms are permitted.

   Protocols MUST be able to use the UTF-8 charset, which consists of
   the ISO 10646 coded character set combined with the UTF-8 character
   encoding scheme, as defined in [10646] Annex R (published in
   Amendment 2), for all text.

   Protocols MAY specify, in addition, how to use other charsets or
   other character encoding schemes for ISO 10646, such as UTF-16, but
   lack of an ability to use UTF-8 is a violation of this policy; such a
   violation would need a variance procedure ([BCP9] section 9) with
   clear and solid justification in the protocol specification document
   before being entered into or advanced upon the standards track.

   For existing protocols or protocols that move data from existing
   datastores, support of other charsets, or even using a default other
   than UTF-8, may be a requirement. This is acceptable, but UTF-8
   support MUST be possible.

   When using other charsets than UTF-8, these MUST be registered in the
   IANA charset registry, if necessary by registering them when the
   protocol is published.

		- Chris

From: Amit Kapoor <[email-masked]>
Subject: CertID clarification
To: [email-masked]
Date: Mon, 22 Jun 1998 15:55:10 -0700 (PDT)
Sender: [email-masked]

Hi,

	Needed a clarification on CertID.  In the current
	drafts I see two different ASN.1 structures in
	CRMF and OCSP.  The functionality seems similar
	enough to try and make both of them the same.
	Comments?

	Second, along the above lines maybe it makes
	sense to identify the common ASN.1 structures
	from the drafts and move them to a single
	document to prevent duplicate functionality
	with different structures abd creating implementation
	and interoperability headaches.  Is it too late
	for something like this?  Thoughts?

	Thanks.

Amit

From: "Phillip M Hallam-Baker" <[email-masked]>
To: "Bob Jueneman" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: RE: RE: Certificate Revocation
Date: Mon, 22 Jun 1998 10:34:48 -0400
Importance: Normal
Sender: [email-masked]

Bob,

> But I really like the suggestion that my statement of the requirements
> triggered.  W've often talked about a personal directory, i.e., a subset
> of the corporate and/or Whole Earth, directory, but I'd never
> thought about
> a personalized CRL list.
>
> Neat idea, and compatible with existing technology. I like that a lot.
> I'd like to see you expand on your "scope" question some more.

This could be handled by adding a scope tag 'enumerated set' which
would simply contain a set of certficate serial numbers.

> With respect to the CD-ROM issue, however, I'm not sure that I would blow
> that off quite so quickly....

I think it is a valid solution, but not necessarily for the application
you suggest. I believe that security has to be zero impact is the users
are to be trusted to follow the proceedures.

On the other hand I would guess our legal friends would like a repository
of that type. I still think it is a good idea to partition the CRL since
CDROM has a number of access speed restrictions which will haunt us
for some time - it is only possible to rotate a perspex disk at a certain
speed before the giroscope effect is noticable :-) But the partitions on
a CDROM could be significantly larger, optimised for the medium. 8Kb chunks
are more likely to be optimal.

	Phill

Date: Mon, 22 Jun 1998 10:03:53 -0400
From: Paul Koning <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: PKIX-1 - use of UTF8
Sender: [email-masked]

>>>>> "John" == John Wray <[email-masked]> writes:

 John> Peter Gutmann ([email-masked]) writes:
 >> Bob Jueneman has suggested deprecating the current practice after
 >> a certain date (2005), which is a good approach: Accept both types
 >> of encoding until then to give vendors time to switch over, but
 >> only emit UTF8 after the cutover date.  The ideal solution would
 >> be to take an approach like the cert validity Y2K fix: Provide a
 >> workaround for the current practice, and require a unified format
 >> (UTF8 only) after the cutover date.  Once everything is ready for
 >> the new format, we can finally lay the character set mess to rest.

 John> I'm happy with that solution.  Codifying this in PKIX-1 would
 John> mean three changes to the document:

 John> 1. The ASN.1 needs to be amended to convey the fact that the
 John> teletexString choice within directoryString isn't really a
 John> teletexString, but instead is an IA5String with a teletexString
 John> tag.  I guess that makes it really an IA5String,
 John> implictly-tagged as a UNIVERSAL 20 (It's not legal ASN.1 to use
 John> a Universal-class tag, so it'll need a statement to explain
 John> that this is simply codifying existing practice).

Sounds good.  

>...
 John> 3. The rules for matching names need to require codeset
 John> conversion to UTF8 (or universal string) prior to performing a
 John> comparison.  This will enable a change to UTF8 in the future.
 John> If teletexString is really IA5, the reasons for not doing
 John> caseIgnore matching on this syntax go away, and it should be
 John> treated the same way as printableString for that purpose.

Um, I wonder about caseIgnore applied to Latin-1 strings.  The case
ignore rules are locale dependent.  (For example, in some countries
letters lose their accents when upcased, in others they don't.  So
"e with acute" matches "E" in France but not in Canada. 

	paul

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: PKIX-1 - use of UTF8
Reply-To: [email-masked]
Date: Mon, 22 Jun 1998 12:43:09 (NZST)
Sender: [email-masked]

Paul Hoffman / IMC <[email-masked]> writes:
>At 01:14 AM 6/22/98 +0000, Peter Gutmann wrote:
>>Finding anything which requires BMPString is very difficult.  I've never seen
>>a cert with a BMPString apart from some Microsoft "everything is a BMPString"
>>ones (that is, I've never seen one which really needs a BMPString).  This
>>isn't through lack of trying, I've asked all sorts of people in locations
>>which could use BMPStrings (China, Korea, Malaysia, Hong Kong, Egypt) to try
>>and create a cert like this for me, without success.  There may be billions
>>of names which require BMPStrings, but noone seems to be using any of them at
>>the moment, and I can't even find someone who can be persuaded to use one for
>>testing purposes.
 
>This mystifies me. What kind of personal name or corporate (not email name)
>certs are being generated for people in Japan, China, and Korea? Names spelled
>in Roman characters in a PrintableString?
 
Exclusively.  I've spent ages doing depth-first searches of Asian CA's web
pages full of characters I can't display or understand only to find that, when
I finally locate the certs, they're all PrintableStrings.  For example here's
the DN from a typical cert:
 
  PrintableString 'CN'
  PrintableString 'Guangdong'
  PrintableString 'Shenzhen'
  PrintableString 'China Merchants Bank'
  PrintableString 'Department of Computers'
 
There are many more like that from all over Asia.  I don't know why this is
happening, possibly because users in Asian countries are used to dealing with
non-i18nised software, so they automatically compensate by romanising their
strings.
 
Peter.

Date: Sun, 21 Jun 1998 10:38:47 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: PKIX-1 - use of UTF8
Sender: [email-masked]

Thank you Nilsson and Peter for the quick (but somewhat depressing)
replies. However, I think I did not state my real question succinctly
enough. I don't care what current cert creators are creating: I care what
cert validators do when handed a cert with a BMPString. Could you repeat
your analyses for cert validators? I'm afraid they might be the same, but
want to be sure.

The reason I ask is simple. If cert validators can handle BMPString and
KludgeStrings, then we should mandate BMPString and remind implementors
that they should definitely handle KludgeStrings. However, if many cert
validators break when handed a cert that has a name in BMPString, then I
agree that we need to specify KludgeStrings followed by UTF8Strings.

Said a different way, just because many CA's issue KludgeString certs
doesn't mean we have to mandate it if there is something better.

At 01:14 AM 6/22/98 +0000, Peter Gutmann wrote:
>Finding anything which requires BMPString is very difficult.  I've never
seen a
>cert with a BMPString apart from some Microsoft "everything is a BMPString"
>ones (that is, I've never seen one which really needs a BMPString).  This
isn't
>through lack of trying, I've asked all sorts of people in locations which
could
>use BMPStrings (China, Korea, Malaysia, Hong Kong, Egypt) to try and create a
>cert like this for me, without success.  There may be billions of names which
>require BMPStrings, but noone seems to be using any of them at the moment,
and
>I can't even find someone who can be persuaded to use one for testing
purposes.

This mystifies me. What kind of personal name or corporate (not email name)
certs are being generated for people in Japan, China, and Korea? Names
spelled in Roman characters in a PrintableString?

--Paul Hoffman, Director
--Internet Mail Consortium

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: PKIX-1 - use of UTF8
Reply-To: [email-masked]
Date: Mon, 22 Jun 1998 01:14:15 (NZST)
Sender: [email-masked]

Paul Hoffman / IMC <[email-masked]> writes:
 
>Peter, you seem to have the best information on a variety of cert writers and
>readers here. Are you saying that there many implementations that do
>{T61String that contains ISO 8859-1} but do *not* do {BMPString} ? That means
>that they have no way to create or read certs for billions of names that don't
>fit in ISO 8859-1.
 
Finding anything which requires BMPString is very difficult.  I've never seen a
cert with a BMPString apart from some Microsoft "everything is a BMPString"
ones (that is, I've never seen one which really needs a BMPString).  This isn't
through lack of trying, I've asked all sorts of people in locations which could
use BMPStrings (China, Korea, Malaysia, Hong Kong, Egypt) to try and create a
cert like this for me, without success.  There may be billions of names which
require BMPStrings, but noone seems to be using any of them at the moment, and
I can't even find someone who can be persuaded to use one for testing purposes.
 
Of the certs I've seen with non-7-bit characters, the T61String always seemed
to be latin-1 (that is, when treated as latin-1 the characters came out right).
These mostly appeared in personal names and possibly once or twice in a company
name.
 
[If there's anyone running a CA in Europe who could provide more data here I'd
 be interested in hearing it.  CA certs from Europe seem to deliberately
 restrict themselves to using PrintableStrings because of the problems with
 other string types, and certs from end-users (who aren't aware of the
 pitfalls) are somewhat hard to find in public locations]
 
Of the three most common cert-handling implementations (Netscape, MSIE, and
SSLeay (which is used in large numbers of servers and SSL proxies, especially
outside the US, and by a number of CA's)), support is as follows:
 
MS products: Tends to favour BMPString for everything, skipping T61String.
Netscape: Used to use T61String for everything which wasn't a PrintableString,
          and would apparently crash if it encountered a BMPString (I think
          this was fixed recently - consider what happens when, say, IIS meets
          Navigator to see why this was a problem).
SSLeay: Uses T61String for everything which isn't a PrintableString (that is,
        if it has a high bit set it gets treated as a T61String.  This is where
        some of the T61String = 8859-1 certs came from).
 
Secude (of which I only have the last publicly-available copy, which predates
BMPString) does in fact appear to jump through the T61String hoops, converting
to and from 8859-1, which would make it the only implementation I'm aware of
which uses real T61Strings.  I've got some Secude-generated certs here, but
none contain T61Strings, so I'm not sure if there really are any genuine
T61String certs in existence.
 
[Another problem I've heard about from CA's, many of which have a web-based
 interface, is that you can't get very far with a BMPString in HTML, whereas
 8859-1 comes built in.  Since a lot of cert-handling software doesn't convert
 the strings for you, you run into problems if you find non-8859-1 strings in a
 cert]
 
>If these implementations actually handle both, then we should not perpetuate
>the T61String hack and should go straight to BMPString. I would really prefer
>to go to UTF8, but agree that we can't just not interoperate with current
>implementations. We should have a cutoff date for mandating new certs use
>UTF8String, and I feel comfortable with making that cutoff five years from
>now, not eight.
 
I'd really like to be able to pretend the whole mess doesn't exist and go
straight to UTF8, but I don't think that'll work because of the size of the
existing installed base :-(.  Summarising the details of certs and
implementations I've been able to get at so far:
 
- Almost all certs use PrintableString (but see the note above that this may be
  due to CA's deliberately using a restricted character set for their own
  certs because they know other types will break).
- A small number of certs use Latin1String (fake T61String).
- I've never seen a cert with a real T61String.
- I've never seen a cert with a BMPString which actually required it.
 
For BMPStrings, Microsoft support it (because Unicode is native to their OS),
Netscape presumably support it in the latest releases, and other
implementations don't appear to support it much.
 
>If there are lots of implementations that do the lie and really don't do
>BMPString, and this WG decides to go with the {T61String that contains ISO
>8859-1} lie, we have to describe it in more than one sentence. We have to say
>exactly how to encode the T61String, and we must say that those strings MUST
>NOT contain actual T.61 text. We should then also have the transition direct
>to UTF8String, again in five years.
 
I like John Wray's suggestion of something like:
 
[UNIVERSAL 20] IMPLICIT OCTET STRING    -- Contains an 8859-1 string
 
although I'd rather call it KludgeString than PkixString (well, at least
Latin1String, which is more indicative of what it really is).
 
This use of universal tags has already been applied to add UTF8 into ASN.1
compilers which don't know about it, so it's not totally unprecedented
(although redefining a basic string type is a bit dodgy).
 
There are two things worth considering, because of the extreme scarcity of
non-PrintableStrings in certs:
 
- The apparent prevalence of 8859-1 strings in T61Strings may be entirely due
  to the if( !PrintableString ) -> T61String strategy used in many
  implementations.  Since the only non-PrintableString's being used to any
  degree are 8859-1, you naturally end up seeing 8859-1 strings.
 
- An early changeover to UTF8 may not be as painful as the installed base would
  appear to indicate because they're almost never used - it's only when people
  actually start using the things that you run into problems.
 
Bob Jueneman's calculations for 2005 make a lot of sense, but it may in fact be
possible to move the cutover date forward a bit without causing too many
problems - you need to find some reasonable balance between the followig two
cases:
 
- If you do it too soon, existing implementations will break (this is why I
  argued against an immediate cutover - even if it's mandated, vendors will
  probably be quite reluctant to risk alienating their existing users).
 
- If you leave it too late, many more implementations will perpetuate the
  kludge, making it harder to change later.
 
There are probably three main implementations which are likely to be used in
locations with i18n concerns, Netscape, assorted MS products, and SSLeay (I
realise that there are many others out there, but once these three are
converted you've got almost everything covered - the rest either have only a
small market share and/or are locked inside the ASCII-only US by export
controls).
 
How quickly can these three be switched over to UTF8, and how quickly will that
propagate through the user base?
 
Peter.

From: Nilsson Hans <[email-masked]>
To: [email-masked]
Subject: SV: PKIX-1 - use of UTF8
Date: Sun, 21 Jun 1998 09:01:02 +0100
Sender: [email-masked]

Paul,
Let me add some information on how existing public CAs work today:

* iD2 (CA system market leader in Scandinavia and Finland, where åäö are
very popular) uses exactly the white lie Peter is describing (8859-1 tagged
as T61String)
* BelSign (fast-growing public CA service in Belgium, issuing certificates
all over the world) also uses the same white lie
* Verisign: refuses to issue certificates containing strange characters as
åäö (at least a month ago when I tried it)

Maybe someone can supply information regarding Entrust and GTE/Cybertrust?

Also for your information, we have now decided to include the white lie in
the joint Swedish/Finnish certificate standard.

The only warning flag I would like to raise is the following: ALMOST all
umlaut characters fit well within 8859-1 without conflict with the T61
characters. However, the 8859-1 code for Norwegian OE (i.e. O with a
slash-thru) is the same as a T61 escape character (8859-1 column 12?), and
when you try to put a certificate containing this character into a directory
and make this attribute searchable, the directory refuses to accept it,
since it contains an illegal T61 string.

Regards
Hans

Date: Sat, 20 Jun 1998 17:12:25 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: PKIX-1 - use of UTF8
Sender: [email-masked]

Peter, you seem to have the best information on a variety of cert writers
and readers here. Are you saying that there many implementations that do
{T61String that contains ISO 8859-1} but do *not* do {BMPString} ? That
means that they have no way to create or read certs for billions of names
that don't fit in ISO 8859-1.

If these implementations actually handle both, then we should not
perpetuate the T61String hack and should go straight to BMPString. I would
really prefer to go to UTF8, but agree that we can't just not interoperate
with current implementations. We should have a cutoff date for mandating
new certs use UTF8String, and I feel comfortable with making that cutoff
five years from now, not eight.

If there are lots of implementations that do the lie and really don't do
BMPString, and this WG decides to go with the {T61String that contains ISO
8859-1} lie, we have to describe it in more than one sentence. We have to
say exactly how to encode the T61String, and we must say that those strings
MUST NOT contain actual T.61 text. We should then also have the transition
direct to UTF8String, again in five years.

--Paul Hoffman, Director
--Internet Mail Consortium

From: [email-masked]
Date: Sat, 20 Jun 1998 16:08:08 -0700
To: [email-masked], "Bob Jueneman" <[email-masked]>
Subject: Re[2]: PKIX-1 - use of UTF8
Sender: [email-masked]

--IMA.Boundary.9593838980
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Description: cc:Mail note part

     I agree with Bob, Peter, and John.
     
     First we should go with the little white lie.  Since that is what we 
     are basically doing now it's nice to see it in a standard :}
     
     Second 2005 sounds about right for the cutoff date.  It seems like a 
     long time right now but it will come quickly.  It seems just like the 
     Y2K problem that we all saw 10 years ago but said "oh well I won't be 
     coding by then so it won't matter to me".
     
     David Grawrock

______________________________ Reply Separator _________________________________
Subject: Re: PKIX-1 - use of UTF8
Author:  "Bob Jueneman" <[email-masked]> at Internet
Date:    6/20/98 11:33 AM

Peter and John,
     
My e-mail has been non compos mentis for the last several days, 
so it was a real pleasure to come back and see the responses to 
my two suggestions a couple of days ago.
     
I'll leave the technical details of the ASN.1 and string types to 
you guys, but Peter's suggestion to use straight
latin-1 but tag it as a T61String is very much in the spirit of the 
"white lie" I was suggesting, and I think it has merit. Of course the 
standards purists will have a heart attack, but we all ought to practice 
our CPR every now and then, and who better to practice on than
the people who cooked up T61 in the first place? :-)
     
It appears, that there is a reasonable amount of acceptance for 
the notion of a standardized cut-over date, but at least one person 
expressed a hope that something could be done earlier than 2005.
     
I proposed 2005 off the top of my head, but what would be realistic? 
Let's think this through.
     
Two major factors to consider are the Y2K problem and the 
Euro conversion problem.  I hadn't thought too much about 
the Y2K problem because my work doesn't involve databases,
but when someone mentions all of the various user's spreadsheet 
lying around that might stop working,  I suddenly understood the 
scope better.
     
Likewise, after installing a new version of Adobe Acrobat,  and 
browsing Adobe's web page, I came across a couple of fonts that 
contain only the Euro character in several versions.  So never mind 
the people and programs that have to deal with the currency issues 
directly, even such a relatively mundane thing as a font is probably 
going to have to be updated. Since I personally have almost 600 
different Adobe fonts of different families, and surely that many more 
TrueType and Type 1 fonts from other vendors, plus all of the 
archaic bit-mapped fonts, the scope of this second problem 
suddenly becomes staggering as well, at least for the Europeans 
and those who have routine dealings with them.  (Speaking of fonts, 
do the various character sets we are considering include the 
Euro character, and is that going to be another hit?)
     
Business people I respect have suggested that after about February 
1999, businesses aren't going to be buying ANY new software, 
except as required to fix these two problems. So if it isn't on the shelf 
by the end of this year, forget it, at least until about June of 2000.
     
I submit that it isn't likely that we'll have a reasonably solid agreement 
on this notion for at least another couple of months, the process being 
what it is.
     
In that case, there is virtually no chance that _anyone_ is going to 
implement the new solution, whatever it is, by the end of the year, 
and so at _best_ we are probably talking about mid-2000 for the 
new software to released.  That allows a good 18 to 24 month 
development cycle, which is certainly do-able assuming that there 
aren't any other higher priorities.
     
Unfortunately, some companies undoubtedly _will_ have other, 
higher priorities, and they might not get around to fixing the problem 
until after the first wave of programs convinces their marketeers 
and program management that they are going to have to address the 
problem if they want to stay in that business.  So add another 18 to 
24 months for that process. That's mid-2002 before say 80% of 
the various programs are ready.
     
Realistically, however, the users aren't going to going to rush out 
and replace all of the software that they just bought overnight. Novell is 
in the process of releasing NetWare 5.0, and we still have a significant 
fraction of our users running on NetWare 3. Likewise, although 
Windows 98 is about to come out, and Windows 95 has been 
out for three years, it is estimated that on the order of 
20% of the corporate users are still running Windows 3.1.
     
This isn't just a case of new software costing too much -- it's a question 
of stability, user training, support, other applications which
have to be converted at the same time, and all of the other hidden 
costs. These costs would still be there even if the software upgrades 
were free.
     
So I believe it would be on the order of three years, at a _minimum_, 
before the natural replacement and upgrade cycle would take effect, 
and backwards compatibility would no longer be an issue.
     
Oops, guess what.  That brings us to 2005, just like my first, off-the-cuff, 
no analysis guess predicted. And no, I didn't take that date and work 
backward -- as anyone you knows me could tell, my brain is really in my 
fingers, and I very seldom know how a message is going to come out 
before I've actually written it.
     
What think the rest of ye?
     
Bob

     
Robert R. Jueneman
Security Architect
Novell, Inc.
Network Products Group
122 East 1700 South
Provo, UT 84604
801/861-7387
[email-masked]
     
"Architects, like prophets and saints, are 
usually years ahead of their time. For this 
reason they are often difficult to live with 
at home, especially if they turn out to be 
right."
     
--IMA.Boundary.9593838980
Content-Type: text/plain; charset=US-ASCII; name="RFC822 message headers"
Content-Transfer-Encoding: 7bit
Content-Description: cc:Mail note part
Content-Disposition: inline; filename="RFC822 message headers"

Date: Sat, 20 Jun 1998 11:33:02 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Re: PKIX-1 - use of UTF8
LAA06481
Sender: [email-masked]
Precedence: bulk
--IMA.Boundary.9593838980--

Date: Fri, 19 Jun 1998 15:57:19 -0400
To: Nilsson Hans <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: SV: new profile submitted
Cc: "'Tim Polk'" <[email-masked]>, [email-masked]
Sender: [email-masked]

Hans:

>Can you please explain the background for the new writing regarding
>subjectKeyIdentifier, using 0100 + 60 bits from the SHA-1 hash of the BIT
>STRING subjectPublicKey? Is this in conformance with something else, or a
>new invention?

This aligns PKIX with a specification used by the US Government.  Neither
Tim not I saw any harm in adopting the format.  Further, the use of a
prefix allows PKIX to specify a different means of computing the key
identifier if the SHA-1 method should ever be discovered to be deficient.

Russ

Date: Sat, 20 Jun 1998 11:48:07 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: Re: RE: RE: Certificate Revocation
Sender: [email-masked]

Phill, my e-mail has been down for several days, so I am slow to 
respond. Actually, I had typed a response, but lost it when the 
system crashed, seconds before I was about to hit the send button.

But I really like the suggestion that my statement of the requirements
triggered.  W've often talked about a personal directory, i.e., a subset 
of the corporate and/or Whole Earth, directory, but I'd never thought about
a personalized CRL list.

Neat idea, and compatible with existing technology. I like that a lot.
I'd like to see you expand on your "scope" question some more.

With respect to the CD-ROM issue, however, I'm not sure that I would blow 
that off quite so quickly. I routinely download our entire corporate directory
to my laptop, because among other things it contains telephone 
numbers, e-mail address, and other things I might need, even 
(especially) when I am on the road. But the people I might need 
to call in that case are often NOT the same peole that my most recently 
used cache of e-mail contacts would include.

Novell has about 4000 employees, so the space reuqired isn't all that 
huge. And in all likelyhood, I won't need to know the data for some sales
person in Bangladesh, so I could prune the list a bit. But a CD-ROM 
plus a delta directory would still be convenient, and if I worked for 
say the US government it might be a necessity.  I routinely carry 3 CDs
of phone records for the entire US along with other CDs (including music 
CDs) when I travel, so putting the entire Internet directory on a CD isn't unreasonable.

Because I'd rather go ahead and encrypt any sensitive messages 
as the time I create them, I'm more likely to need the certificates than
I am the CRLs. But if the same mechanism could deliver both, that's
even better.

Regards,

Bob

>>> "Phillip M Hallam-Baker" <[email-masked]> 06/18 1:45 PM >>>
Carlisle,

> Just a quick request for clarification.  Are you really saying 
> "one compact
> CRL of 1Kb for *each* of the 1000 odd certificates", or are you instead
> suggesting a single CRL that might hold up to 1000 entries?

Hmm, if the CRL was created on the fly by a status responder and
contained a series of distinct OCDP scopes I suppose it COULD be 
a single CRL with 1000 scope entries. Interesting thought.

Perhaps there are more efficient methods of encoding such a response.
The query could be hashed and incorporated in the CRL as 
a scope specification... Interesting.

> The former case requires CAs to partition at one cert per 
> distribution point

Or use OCDP scopes and mark the scope extensions critical. This
allows the scopes to be produced in bulk. They are in effect an
validation token of the type proposed by Rivest but conforming 
to existing syntax and are aggregate tokens validating more 
than one certificate.

Returning to Bob's original proposal. It is quite practical to
download 1000 CRLs of 1kb when Bob connects his powerbook to
the ethernet. On the other hand when he is in roaming mode
tethered by a 28.8Kb modem some intelligent means of obtaining
the <20 CRLs he is interested in that _day_ seems appropriate.

Waiting 10 sec to download the CRLs for use that day seems
reasonable. Certainly this seems simpler to me than mucking about
with CDROMs, floppies and so on. Leave the CDROM for what it's
meant for, inflight movies and TombRaider II. Bob's personal
problem is independent of the size of the network he is on. If
we have to resort to 650Mb of information we is probably doing
something wrong.

Essentially all I am suggesting to do with OCDP at this stage is:
let us start putting the scope code into the clients. If it turns
out to be the case that revocation lists are small enough to
cope with without it we have added a few hundred unnecessary bytes 
to the executable. On the other hand if we turn out to need it I
believe we will REALLY need it. It is a high leverage idea that 
could save us all having to panic a couple of years down the road.

		Phill

Date: Sat, 20 Jun 1998 11:33:02 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Re: PKIX-1 - use of UTF8
Sender: [email-masked]

Peter and John,

My e-mail has been non compos mentis for the last several days, 
so it was a real pleasure to come back and see the responses to
my two suggestions a couple of days ago.

I'll leave the technical details of the ASN.1 and string types to 
you guys, but Peter's suggestion to use straight
latin-1 but tag it as a T61String is very much in the spirit of the 
"white lie" I was suggesting, and I think it has merit. Of course the
standards purists will have a heart attack, but we all ought to practice
our CPR every now and then, and who better to practice on than
the people who cooked up T61 in the first place? :-)

It appears, that there is a reasonable amount of acceptance for 
the notion of a standardized cut-over date, but at least one person 
expressed a hope that something could be done earlier than 2005.

I proposed 2005 off the top of my head, but what would be realistic?
Let's think this through.

Two major factors to consider are the Y2K problem and the 
Euro conversion problem.  I hadn't thought too much about
the Y2K problem because my work doesn't involve databases,
but when someone mentions all of the various user's spreadsheet 
lying around that might stop working,  I suddenly understood the 
scope better.

Likewise, after installing a new version of Adobe Acrobat,  and 
browsing Adobe's web page, I came across a couple of fonts that 
contain only the Euro character in several versions.  So never mind
the people and programs that have to deal with the currency issues
directly, even such a relatively mundane thing as a font is probably 
going to have to be updated. Since I personally have almost 600 
different Adobe fonts of different families, and surely that many more
TrueType and Type 1 fonts from other vendors, plus all of the 
archaic bit-mapped fonts, the scope of this second problem 
suddenly becomes staggering as well, at least for the Europeans 
and those who have routine dealings with them.  (Speaking of fonts, 
do the various character sets we are considering include the 
Euro character, and is that going to be another hit?)

Business people I respect have suggested that after about February
1999, businesses aren't going to be buying ANY new software, 
except as required to fix these two problems. So if it isn't on the shelf
by the end of this year, forget it, at least until about June of 2000.

I submit that it isn't likely that we'll have a reasonably solid agreement
on this notion for at least another couple of months, the process being 
what it is.

In that case, there is virtually no chance that _anyone_ is going to 
implement the new solution, whatever it is, by the end of the year,
and so at _best_ we are probably talking about mid-2000 for the 
new software to released.  That allows a good 18 to 24 month 
development cycle, which is certainly do-able assuming that there 
aren't any other higher priorities.

Unfortunately, some companies undoubtedly _will_ have other, 
higher priorities, and they might not get around to fixing the problem 
until after the first wave of programs convinces their marketeers 
and program management that they are going to have to address the
problem if they want to stay in that business.  So add another 18 to 
24 months for that process. That's mid-2002 before say 80% of 
the various programs are ready.

Realistically, however, the users aren't going to going to rush out 
and replace all of the software that they just bought overnight. Novell is
in the process of releasing NetWare 5.0, and we still have a significant 
fraction of our users running on NetWare 3. Likewise, although 
Windows 98 is about to come out, and Windows 95 has been 
out for three years, it is estimated that on the order of
20% of the corporate users are still running Windows 3.1.

This isn't just a case of new software costing too much -- it's a question
of stability, user training, support, other applications which
have to be converted at the same time, and all of the other hidden
costs. These costs would still be there even if the software upgrades
were free.

So I believe it would be on the order of three years, at a _minimum_, 
before the natural replacement and upgrade cycle would take effect,
and backwards compatibility would no longer be an issue.

Oops, guess what.  That brings us to 2005, just like my first, off-the-cuff,
no analysis guess predicted. And no, I didn't take that date and work
backward -- as anyone you knows me could tell, my brain is really in my 
fingers, and I very seldom know how a message is going to come out 
before I've actually written it.

What think the rest of ye?

Bob

Robert R. Jueneman
Security Architect
Novell, Inc.
Network Products Group
122 East 1700 South
Provo, UT 84604
801/861-7387
[email-masked]

"Architects, like prophets and saints, are 
usually years ahead of their time. For this
reason they are often difficult to live with
at home, especially if they turn out to be 
right."

From: [email-masked]
To: [email-masked], [email-masked]
Date: Fri, 19 Jun 1998 10:04:31 -0400
Subject: Re: PKIX-1 - use of UTF8
Sender: [email-masked]

Peter Gutmann ([email-masked]) writes:

>Bob Jueneman has suggested deprecating the current practice
>after a certain date (2005), which is a good approach: Accept
>both types of encoding until then to give vendors time to
>switch over, but only emit UTF8 after the cutover date.
>The ideal solution would be to take an approach like the
>cert validity Y2K fix: Provide a workaround for the current
>practice, and require a unified format (UTF8 only) after the
>cutover date.  Once everything is ready for the new
>format, we can finally lay the character set mess to rest.

I'm happy with that solution.  Codifying this in PKIX-1 would
mean three changes to the document:

1. The ASN.1 needs to be amended to convey the fact that the
teletexString choice within directoryString isn't really a
teletexString, but instead is an IA5String with a teletexString
tag.  I guess that makes it really an IA5String,
implictly-tagged as a UNIVERSAL 20 (It's not legal ASN.1
to use a Universal-class tag, so it'll need a statement to
explain that this is simply codifying existing practice).

2. The rules for choosing a code-set when emitting certificates
can stay as in the current document, but need additional text
saying that these rules are for backwards compatibility, and
are in effect only for a transition period, and that PKIX
systems should be prepared to change to the use of UTF8 in
generated certificate at some time in the future (you mention
2005 as a candidate - I'd hope we could plan for a bit sooner
than that).

3. The rules for matching names need to require codeset
conversion to UTF8 (or universal string) prior to performing
a comparison.  This will enable a change to UTF8 in the future.
If teletexString is really IA5, the reasons for not doing
caseIgnore matching on this syntax go away, and it should be
treated the same way as printableString for that purpose.

Here is some suggested text for the three changes:

1)  Page 19, DirectoryString definition:

|
|DirectoryString ::= CHOICE {
|    pkixString      PkixString(SIZE (1..MAX)),
|    printableString PrintableString(SIZE(1..MAX)),
|    universalString UniversalString(SIZE(1..MAX)),
|    utf8String      UTF8String(SIZE(1..MAX)),
|    bmpString       BMPString(SIZE(1..MAX)) }
|
|
|PkixString ::= [UNIVERSAL 20] IMPLICIT IA5String
|
|-- The use of the [UNIVERSAL 20] tag in the PkixString
|-- type is not legal ASN.1, but serves to codify
|-- existing practice.  It is to be interpreted as a
|-- character string encoded using the IA5 codeset, but
|-- tagged as though it were a TeletexString.

[Similar text needs to go in the ASN.1 appendix]

2)  Top of page 20, after the three rules for choosing
codesets in emitted certificates, add new para:

|These rules document existing certificate practices, and are
|provided for backwards compatibility between certificates
|generated by PKIX systems and consumed by existing applications.
|These rules shall be in effect only until <date>, after which
|time PKIX systems should use the UTF8String syntax for encoding
|all directoryString attribute values.

3)  Bottom of page 20, replace the "requirements for conforming
implementations" clauses a through d with:

|(a) Attribute values encoded using the printableString or pkixString
|    syntaxes shall have any leading or trailing white space removed,
|    any internal consecutive white space characters replaced with a
|    a single space, any uppercase characters converted to lowercase,
|    and their encoding converted to universalString prior to comparison.
|
|(b) Attribute values encoded using utf8String or bmpString syntaxes
|    shall be converted to universalString prior to comparison.
|
|(c) After application of transforms (a) and (b) as appropriate,
|    comparison of two attribute values shall be performed using
|    binary matching of the encoded string data.
|
|    Implementations may use an alternate comparison algorithm,
|    provided the results of the comparison are identical to those
|    given by the algorithm specified here.

John

From: Trevor Freeman <[email-masked]>
To: "Pkix List (E-mail)" <[email-masked]>
Subject: Re: PKIX-1 - use of UTF8
Date: Thu, 18 Jun 1998 18:22:11 -0700
Sender: [email-masked]

Why is it that I am not getting a warm feeling that this issue has been
thought through. 
There is a large installed base out there of systems which understand
encoding such as printable sting and Unicode, but not UTF8. Therefore UTF8
should be the last resort when all else fails. Other consideration like what
I can and cannot do with it in C pale into insignificance compared to the
prospect of not being able to decode the name. And I am sure all of the app
providers code will handle the error gracefully when they encounter the
problem of a UTF8 encoded directory string. The installed base of systems
today are using ACSII and Unicode, so lets try and live with that reality.

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: PKIX-1 - use of UTF8
Reply-To: [email-masked]
Date: Fri, 19 Jun 1998 12:49:47 (NZST)
Sender: [email-masked]

John Wray <[email-masked]> writes:
 
>I think your (b) needs a bit more expansion.
>
>You could mean either:
>
>1)   "... if the string contains characters that may be represented in both
>T.61 and ISO 8859-1, then the string shall be encoded as a T61String", or
>
>2)   "...if the string contains characters that may be represented in both ISO
>8859-1 and ISO 8859-1, and whose encoding under ISO 8859-1 is the same as
>their encoding as T61String characters, the the string shall be encoded as a
>T61 string".
 
Actually it's none of the above.  What I meant was:
 
    (b) failing (a), if the latin-1 (ISO 8859-1) character set is sufficient
the string shall be represented as a latin-1 string with a T61String tag.
 
(that may not be the best way to say it, what I mean here is to use straight
latin-1 but tag it as a T61String).
 
Before people start dusting off their flamethrowers, the reason for this is
twofold:
 
1. It codifies existing practice.  I've never found a single certificate in
   which a T61String really is a T61String - in every case it's latin-1 (if
   anyone has an example of a cert with a real T.61 string, please send me a
   copy for my collection).  For all implementations I know of, T61String
   currently *is* Latin1String.
 
2. T.61 has apparently been withdrawn by the ITU, so it's not even possible to
   get a copy of this in order to comply with it.  For people who have seen
   this or related standards like T.51/52, withdrawing it is probably a good
   move (IMNSHO any standard which requires diagrams extending into three
   dimensions in order to explain how to encode an a-umlaut has problems).
   T61String in itself (without complex escape codes and shifting) is next to
   useless because there's almost nothing which is common to latin-1 and
   straight T.61, and once you add the escape codes it's unworkable.
 
>X.509 doesn't contain an option for an 8-bit Western European codeset. If we
>want to stay within the standard, we have to go multibyte to get accented
>characters.
 
X.509 doesn't handle latin-1, but (AFAIK) every existing implementation - tens
of millions - do by treating T61String as Latin1String.  All you need to do to
work with this is add a single sentence to PKIX which codifies this practice.
There's simply too large an installed base out there to change it now, and
mandating an immediate unconditional switch to UTF8 for vendors is suicidal
because any certificates their software issues will be regarded as invalid by
virtually every application which makes use of certificates.
 
Bob Jueneman has suggested deprecating the current practice after a certain
date (2005), which is a good approach: Accept both types of encoding until then
to give vendors time to switch over, but only emit UTF8 after the cutover date.
The ideal solution would be to take an approach like the cert validity Y2K fix:
Provide a workaround for the current practice, and require a unified format
(UTF8 only) after the cutover date.  Once everything is ready for the new
format, we can finally lay the character set mess to rest.
 
Peter.

From: "Phillip M Hallam-Baker" <[email-masked]>
To: "Carlisle Adams" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: RE: Certificate Revocation
Date: Thu, 18 Jun 1998 15:45:21 -0400
Importance: Normal
Sender: [email-masked]

Carlisle,

> Just a quick request for clarification.  Are you really saying 
> "one compact
> CRL of 1Kb for *each* of the 1000 odd certificates", or are you instead
> suggesting a single CRL that might hold up to 1000 entries?

Hmm, if the CRL was created on the fly by a status responder and
contained a series of distinct OCDP scopes I suppose it COULD be 
a single CRL with 1000 scope entries. Interesting thought.

Perhaps there are more efficient methods of encoding such a response.
The query could be hashed and incorporated in the CRL as 
a scope specification... Interesting.

> The former case requires CAs to partition at one cert per 
> distribution point

Or use OCDP scopes and mark the scope extensions critical. This
allows the scopes to be produced in bulk. They are in effect an
validation token of the type proposed by Rivest but conforming 
to existing syntax and are aggregate tokens validating more 
than one certificate.

Returning to Bob's original proposal. It is quite practical to
download 1000 CRLs of 1kb when Bob connects his powerbook to
the ethernet. On the other hand when he is in roaming mode
tethered by a 28.8Kb modem some intelligent means of obtaining
the <20 CRLs he is interested in that _day_ seems appropriate.

Waiting 10 sec to download the CRLs for use that day seems
reasonable. Certainly this seems simpler to me than mucking about
with CDROMs, floppies and so on. Leave the CDROM for what it's
meant for, inflight movies and TombRaider II. Bob's personal
problem is independent of the size of the network he is on. If
we have to resort to 650Mb of information we is probably doing
something wrong.

Essentially all I am suggesting to do with OCDP at this stage is:
let us start putting the scope code into the clients. If it turns
out to be the case that revocation lists are small enough to
cope with without it we have added a few hundred unnecessary bytes 
to the executable. On the other hand if we turn out to need it I
believe we will REALLY need it. It is a high leverage idea that 
could save us all having to panic a couple of years down the road.

		Phill

From: Carlisle Adams <[email-masked]>
To: "'Phillip Hallam-Baker'" <[email-masked]>
Cc: [email-masked]
Subject: RE: RE: Certificate Revocation
Date: Thu, 18 Jun 1998 14:59:58 -0400
Sender: [email-masked]

Hi Phill,

> ----------
> From: 	Phillip Hallam-Baker[SMTP:[email-masked]]
> Sent: 	Thursday, June 18, 1998 2:02 PM
> To: 	Bob Jueneman; [email-masked]; [email-masked]
> Subject: 	RE: RE: Certificate Revocation
> 
> It seems to me that using OCDP to create one compact CRL of 1Kb
> for each of the 1000 odd certificates Bob is likely to deal with
> on his portable is a good plan.
> 
Just a quick request for clarification.  Are you really saying "one compact
CRL of 1Kb for *each* of the 1000 odd certificates", or are you instead
suggesting a single CRL that might hold up to 1000 entries?

The former case requires CAs to partition at one cert per distribution point
(certainly possible within the standard, but I think it's unlikely that many
CAs will do this).  The latter case, combined with the remainder of your
sentence, requires the CA to partition according to the set of people Bob is
likely to deal with...

> Protecting the sending of encrypted mail suggests that he needs
> a batch SMTP send client that downloads the most up to date CRL 
> and performs a CRL validity check before transmission.
> 
There are existing products that have been doing this for some time, so I
agree with you that it appears that Bob's requirements can be met.

Carlisle.

From: "Phillip Hallam-Baker" <[email-masked]>
To: "Bob Jueneman" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: RE: Certificate Revocation
Date: Thu, 18 Jun 1998 14:02:58 -0400
Importance: Normal
Sender: [email-masked]

> But what about the case where you are about to send off 
> an encrypted message? There I care a little more whether
> the certificate is valid, because although I probably have
> a pretty good reasonableness-filter to detect an imposter 
> independent of the signature, if my correspondent's keys have
> been compromised, or if he is no longer with the same 
> company, I definitely don't want to send the message.

I think this is an important point.

Editing Bob's requirement's down a tad:

1) He has a quasi-offline connection
	In this case he has a notebook which connects to the 
	Internet at irregular intervals.
2) He is going to send email
	Aha! he has to connect to a network before the
	damage is done.

I would also venture that

3) He has limited storage on his machine

4) Regardless of the number of people who obtain a certificate
	Bob is only interested in communicating with a limited 
	number.

These latter two constraints suggest to me that we have a scaling 
constraint, but also a constraint on the fundamental complexity
of the problem.

It seems to me that using OCDP to create one compact CRL of 1Kb
for each of the 1000 odd certificates Bob is likely to deal with
on his portable is a good plan.

The machine can download these into his system each time he
makes a connection.

Protecting the sending of encrypted mail suggests that he needs
a batch SMTP send client that downloads the most up to date CRL 
and performs a CRL validity check before transmission. Alternatively
a module of this type could be built into a mail hub (incidentially
why is it that mail clients insist on sending THROUGH a mail hub
these days rather than directly?).

Another program could perform a periodic spring clean of his
certificate database, checking to see if all his certificates 
were current.

Otherwise Bob's requirements appear pretty easy to meet provided 
he does not insist on being able to base decisions on material
more recent than his last contact with the world at large.

		Phill

Date: Thu, 18 Jun 1998 11:23:59 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: RE: Certificate Revocation
Sender: [email-masked]

Fair enough, Hal. You probably aren't going to make any 
crucial decisions that depend on the CRL at all, never 
mind whether it is completely current.

Just how you go back and revalidate mail you have 
already opened is an interesting question. Maybe, as you 
suggest, you don't bother unless you have some reason
to suspect the message.  After all, it was signed, wasn't it?
That must mean that it is secure, right? Surely no one 
expects me to go get the keys necessary to validate all
the signed PGP mail I get, do they? It looks impressive,
so it must be secure. :-)

But what about the case where you are about to send off 
an encrypted message? There I care a little more whether
the certificate is valid, because although I probably have
a pretty good reasonableness-filter to detect an imposter 
independent of the signature, if my correspondent's keys have
been compromised, or if he is no longer with the same 
company, I definitely don't want to send the message.

So what do you do?  Do you defer the actual encryption 
until transmission time, i.e., when you land and plug in your
laptop and dial up your server? Is the amount of additional 
time that would take of concern?

What happens to the message prior to the time that it is 
encrypted?  Does it sit there in the clear, naked and 
vulnerable to someone who steal my laptop prior to my getting
a successful connection? Or should I encrypt it in my own
private key and hold it that way until I can re-encrypt the 
message key in the public key of the authenticated user?

If I can't access the latest CRL database instantly, should 
I not send the message?

I'm not just asking rhetorical questions -- these are very real 
issues that are presently confronting us.

What to other S/MIME users/vendors do to solve this
disconnected mode of operation question?

Bob

>Warwick Ford <[email-masked]> wrote on 06/17 9:49 PM:
>
>>An example of a state maintenance problem here would be getting your laptop
>>out on the plane and realizing that, while you had been astute enough to
>>pick up the latest diskette, you had brought the wrong CD for that diskette.
>
>At 08:39 PM 6/17/98 -0600, Bob Jueneman wrote:
>>Yup.  Things like that happen, but only to other people, right?
>>
>>But at least you can listen to the Eagles, or play a game, or do 
>>whatever else WAS on the diskette that you brought!
>>
>>Option two, per Dilbert, is to use the CD drawer in your computer as a 
>>handy-dandy coffee cup holder. That will solve several other 
>>problems as well.
>
>Engineers frequently get accused of using technology for its own sake.
>Let's try to get back to reality.  In practice, you are most likely to read
>the message and decide, based on its contents, whether to even bother to
>verify its signature, later on.
>
>Hal
>
>==============================================================
>======
>Harold W. Lockhart Jr.               PLATINUM technology
>Chief Technical Architect            8 New England Executive Park
>Email: [email-masked]  Burlington, MA 01803 USA
>Voice: (781)273-6406                 Fax: (781)229-2969
>==============================================================
>======

Date: Thu, 18 Jun 1998 11:03:04 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: PKIX-1 - use of UTF8
Sender: [email-masked]

John, thanks for your informative reply. Since I suspect 
most of us are not specialists in this rather arcane area,
the education is useful.
>
>>>> <[email-masked]> 06/18 10:37 AM >>>
>Bob Jueneman ([email-masked]) writes:
>
>>John, not having looked at the API implications of UTF-8, I can't say
>>whether it is more implementor friendly than BMPString or not. Frankly,
>>I would be perfectly happy to stick with Unicode universally, as memory0
>>and communications costs continue to decrease, while programmers
>>time, effort, and salaries continue to increase.  And I understand that
>>BMPString, which always uses two bytes, is much easier to parse,
>>since it doesn't necessarily have to be converted into say Unicode for
>>processing. (I may have an incorrect understanding of this, but if it is
>>true,I would have a hard time arguing that UTF-8 is more
>>implementor-friendly.)
>
>The reasons I'm claiming UTF-8 is implementor friendly are:
>
>i)  It is designed such that code that scans a string looking for specific
>7-bit ASCII characters will find them, without having to know that the
>string is actually a UTF-8 string - that is, octet values between 0 and
>0x7f always mean the corresponding ASCII character, and are never a part of
>some other character.  One result of this is that you can use a standard C
>char * object to hold a UTF-8 string, and most standard C string-handling
>routines (e.g. strcmp, strcpy etc) will work just fine.
>
>ii) It is the standard way that Java strings are passed to C code via the
>Java Native Interface, so it's a natural codeset for applications that are
>written part in Java and part in C/C++.
>
>iii) It's an byte-stream oriented encoding, so there are no endian-ness
>issues lurking to trip up unwary programmers.

OK, I guess I'll buy that set of arguments -- they're pretty convincing.
>
>>However, decreasing the options to be considered from three to two is
>>a step in the right direction, but two options still requires a lot of
>>additional and rather useless decision making, testing, etc.
>>
>>If as I understand it, UTF-8 produces one byte encodings for the
>equivalent
>>(at least roughly) for the western European unaccented characters, and
>>other encoding schemes for those characters generally require two bytes
>>in any case, why not use UTF-8 universally?  (This assumes that the
>>universal use of BMPString would not acceptable, presumably for the
>>arguable efficiency considerations.)
>
>That's right.  For 7-bit ASCII characters, UTF-8 encoding is the same as
>ASCII.
>
>>(Obviously for backwards compatibility incoming PrintableString and
>>BMPString,and maybe even Teletex will have to continue to be supported
>>for some period of time, but hopefully they could be strongly deprecated
>>after say 2005.)
>>
>>If the decision is made to support both PrintableString and UTF-8,
>>would an implementation be conforming if it chose to output everything
>>in UTF-8, whether it could have been encoded in a more restrictive
>>character set or not?  (That would be my preference.)
>
>Interoperability with current code.  Firstly, UTF8 and BMPString are recent
>additions to the permitted syntaxes for directoryString, and certificates
>using either of these syntaxes are unlikely to be understood by deployed
>code.  Also, there's a slightly less serious problem in that PKIX has
>currently adopted a very strict set of rules for comparison of strings (for
>example, during certificate chain processing).  PKIX-1 mandates that two
>strings are considered different if they are encoded using different
>syntaxes, regardless of their contents.  This means that if PKIX issues
>certificates encoded using UTF8 or BMPString, those certificates can never
>be part of the same trust chain as a certificate issued by a system that
>chooses a different syntax.

I would defer to Peter Gutmann on this subject, but my impression 
is that the world is pretty well broken in this area.  We've had a hard 
enough time trying to get Netscape and Microsoft browsers to accept
the same certificate string, but as an international company with nearly 40
million users outside the US, we obviously are very concerned about
double-byte encoding.

I like your suggestion of upconverting to a common character set 
for equivalence matching. I'm very concerned that with bowser 
manufacturers all over the world, plus CA toolkit vednors equally 
distributed internationally, plus multinational corporations, nothing is
going to be interoperable.

It certainly seems undesirable to force the subject and issuer name 
to be in two different character sets in order to verify the certificate 
hierarchy, for exmaple.
>
>>Finally, what does it mean to say that a character set is "sufficient"?
>>Does this mean that a given character string has to be examined
>>one character at a time to see whether an accented character just
>>happens to be included in that person's name, for example?
>
>Yes, that's pretty much it.

That seems like a really unfortunate and inefficient requirement.
>
>>Or, as I would prefer, can the decision be made on the basis of the
>>basic code set in use, so  that a user who normally uses German
>>would always their input encoded the same way, regardless of the
>>actual characters used?
>
>Not with the current PKIX string matching rules.  "Fred" encoded as a
>printableString is defined as different to "Fred" encoded as a BMPString,
>or UniversalString, or UTF8String - all of these "Fred"s have to be
>considered as distinct and different names, even though it's trivial to
>convert between those encodings.  Because of this, PKIX has to mandate the
>encoding syntax used, so that certificates have a chance of chaining
>properly.

Obviously the other approach is to mandate the use of a single, universal
encoding syntax.
>
>In another message, I suggested a relaxation of the matching rules to allow
>conversion to a standard syntax prior to comparison.  This would make it
>possible for us to change or relax the rules for picking a syntax to use
>when emitting certificates, if we so desired.  This would allow us to use
>the current arcane rules for a transition period so that PKIX can
>interoperate with current systems, but in the future, when more systems
>understand UTF8, PKIX could switch to specifying that as the prefered
>syntax, without breaking anything.

Is it the case that the characters in 7-bit ASCII are encoded the same way 
in both PrintableString and UTF-8?  I.e.., is PrintableString a strict encoding
subset of UTF-8?

If so, is there some way that we could "lie" and accept 7-bit ASCII 
as though it were UTF-8, and vice versa, so long as no other 
characters were included? That might be an acceptable (temporary) 
operational restriction.

If true, this might be an acceptable answer as to how to get over the interoperability hurdle.  If I'm supposed to output UTF-8 but no one's 
browser can read it, no one will buy my product.  So the market winner 
is the last person who complies with the standard? Doesn't sound like
a recipe for success.

These are hard problems. I'm glad someone is thinking about them.
The "let them eat cake," i.e., "use English" approach isn't going to 
work much longer.

Bob
>
>John
>
>

From: [email-masked]
To: [email-masked]
cc: [email-masked]
Date: Thu, 18 Jun 1998 12:37:48 -0400
Subject: Re: PKIX-1 - use of UTF8
Sender: [email-masked]

Bob Jueneman ([email-masked]) writes:

>John, not having looked at the API implications of UTF-8, I can't say
>whether it is more implementor friendly than BMPString or not. Frankly,
>I would be perfectly happy to stick with Unicode universally, as memory0
>and communications costs continue to decrease, while programmers
>time, effort, and salaries continue to increase.  And I understand that
>BMPString, which always uses two bytes, is much easier to parse,
>since it doesn't necessarily have to be converted into say Unicode for
>processing. (I may have an incorrect understanding of this, but if it is
>true,I would have a hard time arguing that UTF-8 is more
>implementor-friendly.)

The reasons I'm claiming UTF-8 is implementor friendly are:

i)  It is designed such that code that scans a string looking for specific
7-bit ASCII characters will find them, without having to know that the
string is actually a UTF-8 string - that is, octet values between 0 and
0x7f always mean the corresponding ASCII character, and are never a part of
some other character.  One result of this is that you can use a standard C
char * object to hold a UTF-8 string, and most standard C string-handling
routines (e.g. strcmp, strcpy etc) will work just fine.

ii) It is the standard way that Java strings are passed to C code via the
Java Native Interface, so it's a natural codeset for applications that are
written part in Java and part in C/C++.

iii) It's an byte-stream oriented encoding, so there are no endian-ness
issues lurking to trip up unwary programmers.

>However, decreasing the options to be considered from three to two is
>a step in the right direction, but two options still requires a lot of
>additional and rather useless decision making, testing, etc.
>
>If as I understand it, UTF-8 produces one byte encodings for the
equivalent
>(at least roughly) for the western European unaccented characters, and
>other encoding schemes for those characters generally require two bytes
>in any case, why not use UTF-8 universally?  (This assumes that the
>universal use of BMPString would not acceptable, presumably for the
>arguable efficiency considerations.)

That's right.  For 7-bit ASCII characters, UTF-8 encoding is the same as
ASCII.

>(Obviously for backwards compatibility incoming PrintableString and
>BMPString,and maybe even Teletex will have to continue to be supported
>for some period of time, but hopefully they could be strongly deprecated
>after say 2005.)
>
>If the decision is made to support both PrintableString and UTF-8,
>would an implementation be conforming if it chose to output everything
>in UTF-8, whether it could have been encoded in a more restrictive
>character set or not?  (That would be my preference.)

Interoperability with current code.  Firstly, UTF8 and BMPString are recent
additions to the permitted syntaxes for directoryString, and certificates
using either of these syntaxes are unlikely to be understood by deployed
code.  Also, there's a slightly less serious problem in that PKIX has
currently adopted a very strict set of rules for comparison of strings (for
example, during certificate chain processing).  PKIX-1 mandates that two
strings are considered different if they are encoded using different
syntaxes, regardless of their contents.  This means that if PKIX issues
certificates encoded using UTF8 or BMPString, those certificates can never
be part of the same trust chain as a certificate issued by a system that
chooses a different syntax.

>Finally, what does it mean to say that a character set is "sufficient"?
>Does this mean that a given character string has to be examined
>one character at a time to see whether an accented character just
>happens to be included in that person's name, for example?

Yes, that's pretty much it.

>Or, as I would prefer, can the decision be made on the basis of the
>basic code set in use, so  that a user who normally uses German
>would always their input encoded the same way, regardless of the
>actual characters used?

Not with the current PKIX string matching rules.  "Fred" encoded as a
printableString is defined as different to "Fred" encoded as a BMPString,
or UniversalString, or UTF8String - all of these "Fred"s have to be
considered as distinct and different names, even though it's trivial to
convert between those encodings.  Because of this, PKIX has to mandate the
encoding syntax used, so that certificates have a chance of chaining
properly.

In another message, I suggested a relaxation of the matching rules to allow
conversion to a standard syntax prior to comparison.  This would make it
possible for us to change or relax the rules for picking a syntax to use
when emitting certificates, if we so desired.  This would allow us to use
the current arcane rules for a transition period so that PKIX can
interoperate with current systems, but in the future, when more systems
understand UTF8, PKIX could switch to specifying that as the prefered
syntax, without breaking anything.

John

Date: Thu, 18 Jun 1998 09:15:29 -0700
To: [email-masked]
From: Michael Myers <[email-masked]>
Subject: POP in CRMF
Sender: [email-masked]

All,

The POP discussions have immediate relevance to the CRMF work product out
for review.  Consistent with Stefan's observation, there are several
variations of POP for different deployment scenarios:

1. Signature key:
   a) Produce a signature using the private key.
   b) Produce a MAC value which is a function of
      the public signature key and a shared secret. 

2. For encryption keys:
   a) Include an encrypted version of the private in
      the certification request.
   b) Produce a MAC which is a function in part of
      the subscriber's private key and the CA's
      public key (key agreement only).
   c) Engage in a challenge-response protocol.

3. Delegate POP to an RA.

Mike

At 09:45 AM 6/18/98 +0200, Stefan Santesson wrote:
>Thanks Mike for putting this debate into the right perspective.
>
>At 11.01 1998-06-16 -0600, Mike Smith wrote:
>>These operational procedure capabilities must be supported by the technical 
>>requirements at a minimum, but not the requirement to conduct such
>operational 
>>testing itself.  POP and all other operational requirements or best
>practices 
>>should be in the policies and concept of operations efforts and so should 
>>the debate.
>
>Is this debate really about protocols or policies ?
>
>When defining a protocol for certificate request it would be wise to include 
>mechanisms for POP.
>
>But the decision to mandate POP for a specific set of certificates can only
>be made by
>the CA and should then reflect the identified certificate policy where this
>requirement
>should be specified.
>
>Personally, I find that many technical issues discussed in this list really
>are policy 
>issues and policy issues are virtually impossible to discuss without first
>defining the
>type of community and set of applications (with common security
>requirements)in which the
>policy is to be used. 
>
>/Stefan Santesson
>
>
>----------------------------------------------------------------
>Stefan Santesson                <[email-masked]>
>Accurata Systemsäkerhet AB     
>Lotsgatan 27 D                  Tel. +46-40 152211              
>216 42  Malmö                   Fax. +46-40 150790              
>Sweden                        Mobile +46-70 5247799
>----------------------------------------------------------------
>
>

From: Ian Roberts <[email-masked]>
Date: Thu, 18 Jun 1998 17:07:16 +0000
To: [email-masked]
Subject: CRL This/Next Update
Sender: [email-masked]

Can a CRL be issued with a later this update date, but an earlier next   
update date?

For example

Time            t1        t2           t3        t4
CRL1            |--------------------------------|
CRL2                      |------------|

What should happen between time t3 and t4?

I had initially thought that we should specify that no CA should issue   
CRLs with a Next Update Date earlier that any previous CRL, but this   
would make it difficult if a CA wished to start issuing CRLs more   
frequently than it had previously.

I believe that unless CRL3 is issued before t3, that verification should   
fail since CRL2 (the latest) has expired.

Also,

PKIX Part 1 states that the This Update date is the date of issue - I   
presume from this that no CA should post a CRL with a This Update date in   
the future.

If a (valid) CRL is received with a This Update date in the future, what   
action should a validator take?

If one takes the CRL with the latest This Update date, then one must also   
use the CRL date as the expiry date for Certificates (lest a previously   
revoked certificate which expires between now and the This Update date is   
incorrectly accepted since it will not be in the new CRL).

Failing this one should ignore the new CRL until the This Update date is   
reached, but ignoring a newer CRL makes me uncomfortable.

Thoughts?

I think these two issues should be tightened up in the draft.  
--
Zergo Limited, The Square, Basing View, Basingstoke, Hants. RG21 4EG, UK
Tel: + 44 (0) 1442 342 600    Fax: +44 (0) 1256 812 901
Website:  http://www.zergo.com

Date: Thu, 18 Jun 1998 09:08:45 -0400
To: "Bob Jueneman" <[email-masked]>, [email-masked], [email-masked], [email-masked]
From: Hal Lockhart <[email-masked]>
Subject: Re: RE: Certificate Revocation
Sender: [email-masked]

Warwick Ford <[email-masked]> wrote on 06/17 9:49 PM:

>An example of a state maintenance problem here would be getting your laptop
>out on the plane and realizing that, while you had been astute enough to
>pick up the latest diskette, you had brought the wrong CD for that diskette.

At 08:39 PM 6/17/98 -0600, Bob Jueneman wrote:
>Yup.  Things like that happen, but only to other people, right?
>
>But at least you can listen to the Eagles, or play a game, or do 
>whatever else WAS on the diskette that you brought!
>
>Option two, per Dilbert, is to use the CD drawer in your computer as a 
>handy-dandy coffee cup holder. That will solve several other 
>problems as well.

Engineers frequently get accused of using technology for its own sake.
Let's try to get back to reality.  In practice, you are most likely to read
the message and decide, based on its contents, whether to even bother to
verify its signature, later on.

Hal

====================================================================
Harold W. Lockhart Jr.               PLATINUM technology
Chief Technical Architect            8 New England Executive Park
Email: [email-masked]  Burlington, MA 01803 USA
Voice: (781)273-6406                 Fax: (781)229-2969
====================================================================

Date: Thu, 18 Jun 1998 08:59:55 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Re: PKIX-1 - use of UTF8
Sender: [email-masked]

John, not having looked at the API implications of UTF-8, I can't say 
whether it is more implementor friendly than BMPString or not. Frankly,
I would be perfectly happy to stick with Unicode universally, as memory 
and communications costs continue to decrease, while programmers
time, effort, and salaries continue to increase.  And I understand that
BMPString, which always uses two bytes, is much easier to parse,
since it doesn't necessarily have to be converted into say Unicode for
processing. (I may have an incorrect understanding of this, but if it is true,
I would have a hard time arguing that UTF-8 is more implementor-friendly.)

However, decreasing the options to be considered from three to two is 
a step in the right direction, but two options still requires a lot of additional 
and rather useless decision making, testing, etc.

If as I understand it, UTF-8 produces one byte encodings for the equivalent
(at least roughly) for the western European unaccented characters, and 
other encoding schemes for those characters generally require two bytes 
in any case, why not use UTF-8 universally?  (This assumes that the 
universal use of BMPString would not acceptable, presumably for the 
arguable efficiency considerations.)

(Obviously for backwards compatibility incoming PrintableString and BMPString,
and maybe even Teletex will have to continue to be supported for 
some period of time, but hopefully they could be strongly deprecated 
after say 2005.)

If the decision is made to support both PrintableString and UTF-8,
would an implementation be conforming if it chose to output everything
in UTF-8, whether it could have been encoded in a more restrictive
character set or not?  (That would be my preference.)

Finally, what does it mean to say that a character set is "sufficient"?
Does this mean that a given character string has to be examined 
one character at a time to see whether an accented character just 
happens to be included in that person's name, for example?

Or, as I would prefer, can the decision be made on the basis of the 
basic code set in use, so  that a user who normally uses German 
would always their input encoded the same way, regardless of the 
actual characters used?

Bob

Robert R. Jueneman
Security Architect
Novell, Inc.
Network Products Group
122 East 1700 South
Provo, UT 84604
801/861-7387
[email-masked]

"Architects, like prophets and saints, are 
usually years ahead of their time. For this
reason they are often difficult to live with
at home, especially if they turn out to be 
right."
turn out to be right."

>>> <[email-masked]> 06/17 7:49 AM >>>
As requested, here is a change request with suggested text, against the
latest PKIX-1 draft.

Top of page 20.  Current text:

    (a) if the character set is sufficient, the string will be represented
as a PrintableString;

    (b) failing (a), if the BMPString character set is sufficient the
string shall be represented as a BMPString; and

    (c) failing (a) and (b), the string shall be represented as a
UTF8String.

Replacement text:

    (a) if the character set is sufficient, the string will be represented
as a PrintableString;

    (b) failing (a), the string shall be represented as a UTF8String.

Rationale:

As discussed on the list, the current text means that BMPString will be
used for all names that don't fit into the restricted printableString
character-set; UTF8 will never be used.  UTF8 is a much more
implementor-friendly code-set than BMPString, and is the IETF's recommended
international codeset, and we should use it in preference to BMPString.

John

From: [email-masked]
To: [email-masked], [email-masked]
Date: Thu, 18 Jun 1998 10:32:43 -0400
Subject: Re: PKIX-1 - use of UTF8
Sender: [email-masked]

Peter ([email-masked]) writes:

>I disagree with the requirement to jump straight to UTF8String.  This is
going
>to break compatibility with virtually every implementation in existence at
the
>moment, and make any PKIX-compliant cert impossible to verify with any
existing
>software... imagine the nightmare this will pose to anyone who obtains or
>issues a new cert which is going to be rejected as invalid by the existing
>installed base of tens of millions of browsers and whatnot.  I think a
much
>better approach, which retains compatilibity with existing
implementations, is:
>
>    (a) if the character set is sufficient, the string will be represented
as
>a PrintableString;
>
>    (b) failing (a), if the latin-1 (ISO 8859-1) character set is
sufficient
>the string shall be represented as a T61String containing only latin-1
>characters; and
>
>[then either a jump to UTF8 or an optional layover in BMPString, depending
on
> how people feel about this]
>
>Rationale:
>
>Pretty much every implementation and OS in existence supports latin-1
natively.
>This is compatible with (I would hope) all existing implementations - the
only,
>very minor change this makes is that it constrains T61String to contain
only
>latin-1 characters rather than the full menagerie of T.61 characters
(which I
>doubt anyone ever used anyway).

I think your (b) needs a bit more expansion.

You could mean either:

1)   "... if the string contains characters that may be represented in both
T.61 and ISO 8859-1, then the string shall be encoded as a T61String", or

2)   "...if the string contains characters that may be represented in both
ISO 8859-1 and ISO 8859-1, and whose encoding under ISO 8859-1 is the same
as their encoding as T61String characters, the the string shall be encoded
as a T61 string".

(2) would be basically saying if the string doesn't fit in printableString,
but contains only 7-bit ASCII characters, or the handful of currency and
punctuation symbols that are common between T.61 and ISO 8859-1, then
encode it as a T61String.  This wouldn't buy a lot, since the major
omissions from printableString (other than underscore, semicolon and the
"@"-sign) are accented characters, which are also absent from 7-bit ASCII.

Assuming (1) is what you mean, that's a compromise I could live with
(assuming that UTF-8, and not BMPString is what is used if you have to
stray outside ISO 8859-1).  It allows the small number of "important"
accented characters permitted in ISO 8859-1 to be encoded as T.61
accent+character 2-byte sequences.  However, is there a way we can flag
this usage of T.61 as "transitional" or "for backwards compatibility"? T.61
is a horrible codeset, and we really should be looking towards UTF-8 as the
way to represent internationalized strings in the future.  We should at
least write the specs such that a PKIX-compliant system would interoperate
with a system that used UTF-8.  For example, we could adopt your
modification above for transmission of data, but require that PKIX systems
will accept such data encoded in either UTF-8 or T.61, and perform string
comparisons on such data as though they were converted to UTF-8 before
comparison.

The resulting change to PKIX-1 would be:

|    (a) if the character set is sufficient, the string will be represented
|    as a PrintableString;
|
|    (b) failing (a), if the latin-1 (ISO 8859-1) character set would
|    be sufficient, the string shall be represented as a T61String.
|
|    (c) failing (b), the string shall be represented as a UTF8String.

Also, the text at the bottom of page 20 would change to:

|    (a) Attribute values encoded using the printableString syntax
|    shall have any leading or trailing white space removed, any
|    internal consecutive white space characters replaced with a
|    a single space, and any uppercase characters converted to
|    lowercase prior to comparison.
|
|    (b) Attribute values encoded using T61String syntax shall be converted
|    to the UTF8String prior to comparison.
|
|    (c) After application of transforms (a) and (b), comparison of two
|    attribute values encoded using the same syntax shall be performed
|    using binary matching of the encoded string data; attribute values
|    encoded using different syntaxes may be assumed to represent different
|    strings.
|
|    Implementations may use an alternate comparison algorithm, provided
the
|    results of the comparison are identical to those given by the
algorithm
|    specified here.

If we really want to foster interoperation with what's out there today,
we should make rule (a) also convert to UTF-8, and extend rule (b) to
require conversion of BMPString and UniversalString to UTF-8 prior to
comparison too.

John

Date: Thu, 18 Jun 1998 08:25:31 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: proof-of-possession for DH keys
Sender: [email-masked]

Adam,

Whenever I am involved in this kind of analysis, I tend to reach 
for the "bigger hammer," i.e., a tool that I know will get the job 
done, rather then trying to finesse the issue with the least 
possible constraint.
>
>Carlisle writes:
>> > You assume that I am holding the corresponding private decryption key.
>> > If I don't, I am unable to decrypt. That case might happen if, when
>> > performing my certification request, I provided garbage data instead of
>> > a real public key or if I *willingly* gave the value of the public key
>> > from someone else. 
>> > 
>> 
>> This is the whole purpose of doing POP: precisely to prevent such
>> pointless actions on the part of the requester.
>
>Preventing against the "pointless action" attack is kind of hard --
>normally parties are expected to be acting in their own interests.

Well, yes, honest parties presumably do. But here are a lot of 
subtle issues that lurk on the fringes, and that are quite easy to miss.

For example, it is reasonably well understood why it is important
to insist on POP in the case of a digital signature key, since someone 
might include someone else's public key in their certificate, and later 
falsely claim attribution of that person's work, if it turned out to be valuable.

Given that problem, and Carlisle's quite reasonable, IMHO, argument 
against creating useless, if not provably dangerous, certificates, I would 
certainly opt for the more conservative position.

I don't know, and don't have time to think about, all of the possible 
ramifications of not requiring POP. I do think it would be necessary to 
analyze almost all protocols that might ever use certificates, including those such as SSL that use a single certificate and key for both encryption and 
authentication.

Certainly we ought to consider every possible combination and use of the keyUsage bits in that analysis (and that alone is enough to make my head hurt),
together with all of the popular algorithms and variants, to make sure that 
no harm is even potentially lurking there.

After all, even the public key substitution attack surprised a number of us
(followed by a head-slapping, "of course").  And there have been far, FAR,
too many cryptographic protocols and schemes that looked sound when 
first proposed but later turned out to be flawed. I've broken a few myself,
and unfortunately had some of mine broken by people that were more 
perspicacious than myself. It's a humbling experience that teaches you a 
lesson.

I am sympathetic to the argument that as protocol designers we should not 
unduly constrain the developers. But not, I believe, at the possible expense of
introducing unanalyzed flaws. And although I hate to disagree with my 
friend Mike Smith , although there may be some CAs who will have the 
considerable technical expertise to deal with these issues within their 
Certification Practice Statement, the VAST majority of CAs will NOT have 
anywhere near the assembled talent represented by this body, and may 
make serious mistakes if not adequately guided.

So my position is that if someone can construct a fully worked out 
logical PROOF (not just arm-waving or proof by example) that not 
requiring POP, although harmful in case A, is completely harmless 
in all other cases, I will read it with interest.  But until then, and certainly 
at Last Call, I believe we should stick to the more conservative, safer 
position.

Bob

From: [email-masked]
To: [email-masked]
cc: [email-masked]
Date: Thu, 18 Jun 1998 10:20:16 -0400
Subject: Re: PKIX-1 - use of UTF8
Sender: [email-masked]

Paul Koning ([email-masked]) writes:

>I agree with Peter and Stefan.
>
>The rule has to support Western European names in an encoding with 8
>bits per character, as 8859-1 does.  Forcing multibyte representations
>on such strings is not good.

That's not what Peter is saying.  He is (unless I've misunderstood him)
advocating the use of T61String to encode strings that fall within the
ISO 8859-1 character set.  T.61 encodes accented characters as
double-byte sequences (one byte for the base character, and one byte
for the accent).

X.509 doesn't contain an option for an 8-bit Western European codeset.
If we want to stay within the standard, we have to go multibyte to
get accented characters.

John

Date: Thu, 18 Jun 1998 09:44:04 -0400
From: Paul Koning <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: PKIX-1 - use of UTF8
Sender: [email-masked]

I agree with Peter and Stefan.

The rule has to support Western European names in an encoding with 8
bits per character, as 8859-1 does.  Forcing multibyte representations 
on such strings is not good.

On the BMP vs. UTF8 question, could this be a place for the "strict
when sending, lenient when receiving" theory?  I.e., require UTF8 in
new certs but accept BMP for backward compatibility?

	paul

Date: Thu, 18 Jun 1998 11:39:59 +0200
To: [email-masked], [email-masked], [email-masked]
From: Stefan Santesson <[email-masked]>
Subject: Re: PKIX-1 - use of UTF8
Sender: [email-masked]

Could someone explain to me why we can't use ISO 8859-1

Being from Sweden, one of the many European countries who
use characters outside of the 7-bit PrintableString format but
still being able to use the ISO 8859-1 8 bit format, I still 
wonder why there is no place for defining a working 8 bit code.

There was T-61 string but using this, many programs (like MS IE
and Netscape) still interpret it as ISO 8859-1.

I think we share this problem with countries like Norway, Denmark
Finland, Germany, France, etc.

We have many times been faced with the fact

a) Printable string is not enough
b) 8-bit coding like T-61 string is not treated
   correct by applications on the market.
c) complex coding (like BMPsting) is rejected by
   many applications. 

Will UTF8String solve this problem ?

I guess there must be a reason for not having a valid option
of defining ISO 8859-1 (such as lack of definitions in X.509) 
but I'm still puzzled about this. Could someone help me out.

/Stefan Santesson

At 09.49 1998-06-17 -0400, [email-masked] wrote:
>As requested, here is a change request with suggested text, against the
>latest PKIX-1 draft.
>
>Top of page 20.  Current text:
>
>    (a) if the character set is sufficient, the string will be represented
>as a PrintableString;
>
>    (b) failing (a), if the BMPString character set is sufficient the
>string shall be represented as a BMPString; and
>
>    (c) failing (a) and (b), the string shall be represented as a
>UTF8String.
>
>Replacement text:
>
>    (a) if the character set is sufficient, the string will be represented
>as a PrintableString;
>
>    (b) failing (a), the string shall be represented as a UTF8String.
>
>Rationale:
>
>As discussed on the list, the current text means that BMPString will be
>used for all names that don't fit into the restricted printableString
>character-set; UTF8 will never be used.  UTF8 is a much more
>implementor-friendly code-set than BMPString, and is the IETF's recommended
>international codeset, and we should use it in preference to BMPString.
>
>John
>
>
>
>
>
----------------------------------------------------------------
Stefan Santesson                <[email-masked]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. +46-40 152211              
216 42  Malmö                   Fax. +46-40 150790              
Sweden                        Mobile +46-70 5247799
----------------------------------------------------------------

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: PKIX-1 - use of UTF8
Reply-To: [email-masked]
Date: Thu, 18 Jun 1998 20:19:57 (NZST)
Sender: [email-masked]

>Top of page 20.  Current text:
>
>    (a) if the character set is sufficient, the string will be represented as
>a PrintableString;
>
>    (b) failing (a), if the BMPString character set is sufficient the string
>shall be represented as a BMPString; and
>
>    (c) failing (a) and (b), the string shall be represented as a UTF8String.
>
>Replacement text:
>
>    (a) if the character set is sufficient, the string will be represented as
>a PrintableString;
>
>    (b) failing (a), the string shall be represented as a UTF8String.
 
I disagree with the requirement to jump straight to UTF8String.  This is going
to break compatibility with virtually every implementation in existence at the
moment, and make any PKIX-compliant cert impossible to verify with any existing
software... imagine the nightmare this will pose to anyone who obtains or
issues a new cert which is going to be rejected as invalid by the existing
installed base of tens of millions of browsers and whatnot.  I think a much
better approach, which retains compatilibity with existing implementations, is:
 
    (a) if the character set is sufficient, the string will be represented as
a PrintableString;
 
    (b) failing (a), if the latin-1 (ISO 8859-1) character set is sufficient
the string shall be represented as a T61String containing only latin-1
characters; and
 
[then either a jump to UTF8 or an optional layover in BMPString, depending on
 how people feel about this]
 
Rationale:
 
Pretty much every implementation and OS in existence supports latin-1 natively. 
This is compatible with (I would hope) all existing implementations - the only,
very minor change this makes is that it constrains T61String to contain only
latin-1 characters rather than the full menagerie of T.61 characters (which I
doubt anyone ever used anyway).
 
Since few implementations currently use, or possibly even support,
BMPString, it may be possible to avoid this in favour of UTF8, although it'd be
better to leave it in for compatibility.  But I think going straight to UTF8 is
a definite mistake.
 
Peter.

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: new profile submitted
Reply-To: [email-masked]
Date: Thu, 18 Jun 1998 20:18:39 (NZST)
Sender: [email-masked]

(I can't really submit concrete text for this, unless you'd like me to send in
 a dump of a certificate which really is a CA cert).
 
>#2 If you want something changed, please submit your suggestions to the list
>WITH TEXT.  We want to forward this to the IESG as soon as possible. That will
>not be possible if we discuss abstract changes on the list. Concrete text is a
>MUST.
 
The NIST certificate in the examples is *still* broken: It doesn't mark
basicConstraints as critical, and is marked as a non-CA certificate while the
text claims it's a CA certificate.
 
Peter.

Date: Thu, 18 Jun 1998 09:45:56 +0200
To: Mike Smith <[email-masked]>, [email-masked], [email-masked]
From: Stefan Santesson <[email-masked]>
Subject: Re: RE: proof-of-possession for DH keys
Cc: [email-masked]
Sender: [email-masked]

Thanks Mike for putting this debate into the right perspective.

At 11.01 1998-06-16 -0600, Mike Smith wrote:
>These operational procedure capabilities must be supported by the technical 
>requirements at a minimum, but not the requirement to conduct such
operational 
>testing itself.  POP and all other operational requirements or best
practices 
>should be in the policies and concept of operations efforts and so should 
>the debate.

Is this debate really about protocols or policies ?

When defining a protocol for certificate request it would be wise to include 
mechanisms for POP.

But the decision to mandate POP for a specific set of certificates can only
be made by
the CA and should then reflect the identified certificate policy where this
requirement
should be specified.

Personally, I find that many technical issues discussed in this list really
are policy 
issues and policy issues are virtually impossible to discuss without first
defining the
type of community and set of applications (with common security
requirements)in which the
policy is to be used. 

/Stefan Santesson

----------------------------------------------------------------
Stefan Santesson                <[email-masked]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. +46-40 152211              
216 42  Malmö                   Fax. +46-40 150790              
Sweden                        Mobile +46-70 5247799
----------------------------------------------------------------

To: [email-masked]
Subject: On line document for X509v3 extention ?
Date: Thu, 18 Jun 1998 14:16:59 +0900
From: Ryu Inada <[email-masked]>
Lines: 11
Sender: [email-masked]

Dear PKIX wizards.

I'm new in the list sorry for out of date and faq
questions.
I'm seeking for X.509v3 extentiond ocument for create CA's code.

Please point me out, where I can get.

Thanks in advance.

Ryu Inada <[email-masked]>

Date: Wed, 17 Jun 1998 20:39:42 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Re: RE: Certificate Revocation
Sender: [email-masked]

Yup.  Things like that happen, but only to other people, right?

But at least you can listen to the Eagles, or play a game, or do 
whatever else WAS on the diskette that you brought!

Option two, per Dilbert, is to use the CD drawer in your computer as a 
handy-dandy coffee cup holder. That will solve several other 
problems as well.

Bob

>>> Warwick Ford <[email-masked]> 06/17 9:49 PM >>>
Bob:

How about Uncle Bob, who helped shape the youngster in its early toddler
days?  (I'll bet you guys are real pleased that people are now considering
offering it its first job.)

An example of a state maintenance problem here would be getting your laptop
out on the plane and realizing that, while you had been astute enough to
pick up the latest diskette, you had brought the wrong CD for that diskette.

Warwick

At 05:19 PM 6/17/98 -0600, Bob Jueneman wrote:
>Warwick,
>
>Re fathers, mothers, aunts and uncles, etc., for certificate revocation,
>you may recall that I suggested essentially the delta CRL concept
>in terms of a CRL-CD-of-the-month club, where a CD containing
>the base information would be supplemented with a floppy disk
>of containing the day's or week's latest updates.
>
>What I was talking about then is still a problem -- how do you authenticate
>either the addressee of an encrypted e-mail, or the originator of a 
>digital signature, when you are sitting in an airplane at 30,000 feet
>and don't have connectivity to a network?
>
>OFCSP and lots of other protocols, including insurance and/or notarization
>protocols may be absolutely needed, or at least highly useful in an 
>environment where everyone is on-line, but that isn't always the case.
>
>I don't want to have to download the entire CRL database in order to get the
>5% that might have changed most recently -- hence, delta CRLs.
>
>Bob
>
>
>>>> Warwick Ford <[email-masked]> 06/16 9:07 PM >>>
>Hi, Carlisle:
>
>At 11:25 AM 6/15/98 -0400, Carlisle Adams wrote:
>>Hi Warwick,
>>
>>> ----------
>>> From: 	Warwick Ford[SMTP:[email-masked]] 
>>> Sent: 	Saturday, June 13, 1998 5:27 PM
>>> To: 	Robert Zuccherato; [email-masked]; 'Jessica Hymowitz'
>>> Subject: 	RE: Certificate Revocation
>>> 
>>> I read with interest Robert and Carlisle's "White Paper".  It provides
>>> some
>>> helpful discussion of the indirection mechanism ("CRL List" mechanism)
>>> developed in OCDP, and contains some interesting refinement ideas.  
>>> 
>>> The thought of using delta CRLs in conjubction with the CRL List mechanism
>>> is interesting, although I suspect client implementors will not embrace
>>> that, given the implementation complexities.  Back in the X.509 v3 design
>>> days, Hoyt and I spent hours discussing the pros and cons of delta CRLs
>>> and
>>> we concluded that they may well be an attractive option for large servers
>>> (for performance reasons) but not appropriate for clients (because of
>>> state
>>> maintenance problems).  I tend to think that same analysis will apply to
>>> using delta CRLs with CRL Lists.
>>> 
>>Perhaps you could give some more detail regarding the "hours of discussion"
>>you and Hoyt had on delta CRLs (feel free to copy him on the response, if
>>you like, so he can join in if he wishes), because I don't understand your
>>summary above at all.  Why would deltas have any more "state maintenance"
>>than CRLs themselves?  Few people have built or will build a client that
>>pulls down an entire CRL every time it wants to check revocation; rather, it
>>typically pulls down a CRL once per period and caches it until its
>>nextUpdate date.  Deltas don't in any way add to this state maintenance.
>>All they do is allow a relying party to get fresher information (if they
>>want it) between CRL updates.
>
>Yes, I would welcome Hoyt's views (I consider Hoyt to be the father of
>delta CRLs).  The volume of discussion was largely because the two concepts
>of delta CRLs and CRL partitions were themselves being designed at the time
>and we were trying to be sure we understood the rationale for having both
>mechanisms.  I won't try to go through all the paths here, but rather shall
>try to spell out the bottom line.  The complicating factor with deltas is
>that someone checking revocation is no longer able to process a single data
>item to be certain that the cert is not revoked.  Rather he/she/it needs to
>obtain, validate, and scan at least two separate data items (the delta and
>the base CRL), and maybe more depending on your delta regime.  Deltas are
>inherently state-oriented, in that it only makes sense to deploy them in an
>environment in which you have a general expectation that, when you fetch
>the delta CRL, you already hold, from some prior activity, the base CRL or
>contents thereof.  This is likely true in a busy server but more
>questionable in a small client system which does only very sporadic
>revocation checks with any given CA.  The reason for using deltas is to
>keep down the size of items retrieved.  An alternative means of keeping
>down size is partitioning, and if partitioning if done sufficiently
>intelligently (note that, with Scopes, we now have some interesting new
>options for intelligent partitioning), the use of deltas may not be
>warranted, especially in small clients.  That said, let me make clear that
>I am not opposed to deltas -- I have always supported having them as an
>option, and I think your proposal for using them in CRL lists is a good
>idea -- as an option.  
>
>>> One deficiency in Robert and Carlisle's analysis is their lack of
>>> recognition of one of the most important underlying concepts of OCDP.  If
>>> unsigned pointers indeed have denial of service implications, the solution
>>> offered by Robert and Carlisle, that is to have the CA sign the pointer,
>>> is
>>> just not the general answer.  The point is that, in many spheres of
>>> application of certificates, the issue of revocation or status checking is
>>> considered a relying-party-domain-control issue -- not a
>>> certificate-issuer-domain-control issue.  In other words, the relying
>>> party's enterprise will decide where, and under what policy conditions,
>>> its
>>> relying parties will go to check certificate status.  This could very well
>>> be a local server or directory -- not back at the CA.
>>> 
>>> Financial industry applications, for example, generally reflect this model
>>> (for good business reasons).  For example, with credit cards, the merchant
>>> goes to its acquirer for a card authorization -- not directly to the
>>> issuer.  The credit card equivalent of a CDP would be for the issuer to
>>> include its contact details (for card authorization purposes) on the card
>>> -- this is not the practice. 
>>> 
>>> For this reason (among others) we saw it important to move away from the
>>> model in which the revocation mechanism is rigidly tied to an embedded
>>> revocation pointer in the certificate itself.  I feel that any work to
>>> further develop the OCDP ideas should definitely preserve this aspect of
>>> the OCDP model.
>>> 
>>You claim above that we have not recognized one of the most important
>>underlying concepts of OCDP.  On the contrary, I suggest that you seem not
>>to have recognized *the* most important underlying concept of CDP:  it is
>>OPTIONAL (and when it is used, it is NON-CRITICAL).  Thus, there is no
>>standard anywhere in which "the revocation mechanism is rigidly tied to an
>>embedded revocation pointer in the certificate itself".  CAs can put
>>distribution points in certificates, or not.  If they happen to do so,
>>relying parties can go to the location pointed to for revocation
>>information, or can go somewhere else of their own choosing (note that since
>>the extension is non-critical, a relying party may not have software that
>>understands the extension while still being perfectly conformant with X.509
>>and PKIX).
>
>You need to clarify something in your paper.  In your early material you
>appeared to dismiss OCDP with the comment "The use of unsigned pointers,
>however, leaves the proposal open to denial-of-service attacks."  While I
>don't understand or subscribe to that comment, I read into it that you were
>similarly dismissing all mechanisms that did not use CDPs.  I welcome the
>new assurance that that is not the case, and suggest you clarify that you
>recognize the need for non-CDP mechanisms (such as OCDP) as well as the CDP
>mechanism, dependent on needs.
>
>Warwick 
>
>
>
>---------------------------------------------------------------------
>Warwick Ford, VeriSign, Inc., Tel (781)2456996 x225; Fax (781)2456006
>[email-masked];  301 Edgewater Pl, Suite 210, Wakefield, MA 01880
>---------------------------------------------------------------------
> 
>
>

---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., Tel (781)2456996 x225; Fax (781)2456006
[email-masked];  301 Edgewater Pl, Suite 210, Wakefield, MA 01880
---------------------------------------------------------------------

Date: Wed, 17 Jun 1998 20:49:07 -0700
To: "Bob Jueneman" <[email-masked]>, [email-masked], [email-masked]
From: Warwick Ford <[email-masked]>
Subject: Re: RE: Certificate Revocation
Sender: [email-masked]

Bob:

How about Uncle Bob, who helped shape the youngster in its early toddler
days?  (I'll bet you guys are real pleased that people are now considering
offering it its first job.)

An example of a state maintenance problem here would be getting your laptop
out on the plane and realizing that, while you had been astute enough to
pick up the latest diskette, you had brought the wrong CD for that diskette.

Warwick

At 05:19 PM 6/17/98 -0600, Bob Jueneman wrote:
>Warwick,
>
>Re fathers, mothers, aunts and uncles, etc., for certificate revocation,
>you may recall that I suggested essentially the delta CRL concept
>in terms of a CRL-CD-of-the-month club, where a CD containing
>the base information would be supplemented with a floppy disk
>of containing the day's or week's latest updates.
>
>What I was talking about then is still a problem -- how do you authenticate
>either the addressee of an encrypted e-mail, or the originator of a 
>digital signature, when you are sitting in an airplane at 30,000 feet
>and don't have connectivity to a network?
>
>OFCSP and lots of other protocols, including insurance and/or notarization
>protocols may be absolutely needed, or at least highly useful in an 
>environment where everyone is on-line, but that isn't always the case.
>
>I don't want to have to download the entire CRL database in order to get the
>5% that might have changed most recently -- hence, delta CRLs.
>
>Bob
>
>
>>>> Warwick Ford <[email-masked]> 06/16 9:07 PM >>>
>Hi, Carlisle:
>
>At 11:25 AM 6/15/98 -0400, Carlisle Adams wrote:
>>Hi Warwick,
>>
>>> ----------
>>> From: 	Warwick Ford[SMTP:[email-masked]] 
>>> Sent: 	Saturday, June 13, 1998 5:27 PM
>>> To: 	Robert Zuccherato; [email-masked]; 'Jessica Hymowitz'
>>> Subject: 	RE: Certificate Revocation
>>> 
>>> I read with interest Robert and Carlisle's "White Paper".  It provides
>>> some
>>> helpful discussion of the indirection mechanism ("CRL List" mechanism)
>>> developed in OCDP, and contains some interesting refinement ideas.  
>>> 
>>> The thought of using delta CRLs in conjubction with the CRL List mechanism
>>> is interesting, although I suspect client implementors will not embrace
>>> that, given the implementation complexities.  Back in the X.509 v3 design
>>> days, Hoyt and I spent hours discussing the pros and cons of delta CRLs
>>> and
>>> we concluded that they may well be an attractive option for large servers
>>> (for performance reasons) but not appropriate for clients (because of
>>> state
>>> maintenance problems).  I tend to think that same analysis will apply to
>>> using delta CRLs with CRL Lists.
>>> 
>>Perhaps you could give some more detail regarding the "hours of discussion"
>>you and Hoyt had on delta CRLs (feel free to copy him on the response, if
>>you like, so he can join in if he wishes), because I don't understand your
>>summary above at all.  Why would deltas have any more "state maintenance"
>>than CRLs themselves?  Few people have built or will build a client that
>>pulls down an entire CRL every time it wants to check revocation; rather, it
>>typically pulls down a CRL once per period and caches it until its
>>nextUpdate date.  Deltas don't in any way add to this state maintenance.
>>All they do is allow a relying party to get fresher information (if they
>>want it) between CRL updates.
>
>Yes, I would welcome Hoyt's views (I consider Hoyt to be the father of
>delta CRLs).  The volume of discussion was largely because the two concepts
>of delta CRLs and CRL partitions were themselves being designed at the time
>and we were trying to be sure we understood the rationale for having both
>mechanisms.  I won't try to go through all the paths here, but rather shall
>try to spell out the bottom line.  The complicating factor with deltas is
>that someone checking revocation is no longer able to process a single data
>item to be certain that the cert is not revoked.  Rather he/she/it needs to
>obtain, validate, and scan at least two separate data items (the delta and
>the base CRL), and maybe more depending on your delta regime.  Deltas are
>inherently state-oriented, in that it only makes sense to deploy them in an
>environment in which you have a general expectation that, when you fetch
>the delta CRL, you already hold, from some prior activity, the base CRL or
>contents thereof.  This is likely true in a busy server but more
>questionable in a small client system which does only very sporadic
>revocation checks with any given CA.  The reason for using deltas is to
>keep down the size of items retrieved.  An alternative means of keeping
>down size is partitioning, and if partitioning if done sufficiently
>intelligently (note that, with Scopes, we now have some interesting new
>options for intelligent partitioning), the use of deltas may not be
>warranted, especially in small clients.  That said, let me make clear that
>I am not opposed to deltas -- I have always supported having them as an
>option, and I think your proposal for using them in CRL lists is a good
>idea -- as an option.  
>
>>> One deficiency in Robert and Carlisle's analysis is their lack of
>>> recognition of one of the most important underlying concepts of OCDP.  If
>>> unsigned pointers indeed have denial of service implications, the solution
>>> offered by Robert and Carlisle, that is to have the CA sign the pointer,
>>> is
>>> just not the general answer.  The point is that, in many spheres of
>>> application of certificates, the issue of revocation or status checking is
>>> considered a relying-party-domain-control issue -- not a
>>> certificate-issuer-domain-control issue.  In other words, the relying
>>> party's enterprise will decide where, and under what policy conditions,
>>> its
>>> relying parties will go to check certificate status.  This could very well
>>> be a local server or directory -- not back at the CA.
>>> 
>>> Financial industry applications, for example, generally reflect this model
>>> (for good business reasons).  For example, with credit cards, the merchant
>>> goes to its acquirer for a card authorization -- not directly to the
>>> issuer.  The credit card equivalent of a CDP would be for the issuer to
>>> include its contact details (for card authorization purposes) on the card
>>> -- this is not the practice. 
>>> 
>>> For this reason (among others) we saw it important to move away from the
>>> model in which the revocation mechanism is rigidly tied to an embedded
>>> revocation pointer in the certificate itself.  I feel that any work to
>>> further develop the OCDP ideas should definitely preserve this aspect of
>>> the OCDP model.
>>> 
>>You claim above that we have not recognized one of the most important
>>underlying concepts of OCDP.  On the contrary, I suggest that you seem not
>>to have recognized *the* most important underlying concept of CDP:  it is
>>OPTIONAL (and when it is used, it is NON-CRITICAL).  Thus, there is no
>>standard anywhere in which "the revocation mechanism is rigidly tied to an
>>embedded revocation pointer in the certificate itself".  CAs can put
>>distribution points in certificates, or not.  If they happen to do so,
>>relying parties can go to the location pointed to for revocation
>>information, or can go somewhere else of their own choosing (note that since
>>the extension is non-critical, a relying party may not have software that
>>understands the extension while still being perfectly conformant with X.509
>>and PKIX).
>
>You need to clarify something in your paper.  In your early material you
>appeared to dismiss OCDP with the comment "The use of unsigned pointers,
>however, leaves the proposal open to denial-of-service attacks."  While I
>don't understand or subscribe to that comment, I read into it that you were
>similarly dismissing all mechanisms that did not use CDPs.  I welcome the
>new assurance that that is not the case, and suggest you clarify that you
>recognize the need for non-CDP mechanisms (such as OCDP) as well as the CDP
>mechanism, dependent on needs.
>
>Warwick 
>
>
>
>---------------------------------------------------------------------
>Warwick Ford, VeriSign, Inc., Tel (781)2456996 x225; Fax (781)2456006
>[email-masked];  301 Edgewater Pl, Suite 210, Wakefield, MA 01880
>---------------------------------------------------------------------
> 
>
>

---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., Tel (781)2456996 x225; Fax (781)2456006
[email-masked];  301 Edgewater Pl, Suite 210, Wakefield, MA 01880
---------------------------------------------------------------------

Date: Wed, 17 Jun 1998 17:19:58 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: RE: Certificate Revocation
Sender: [email-masked]

Warwick,

Re fathers, mothers, aunts and uncles, etc., for certificate revocation,
you may recall that I suggested essentially the delta CRL concept
in terms of a CRL-CD-of-the-month club, where a CD containing
the base information would be supplemented with a floppy disk
of containing the day's or week's latest updates.

What I was talking about then is still a problem -- how do you authenticate
either the addressee of an encrypted e-mail, or the originator of a 
digital signature, when you are sitting in an airplane at 30,000 feet
and don't have connectivity to a network?

OFCSP and lots of other protocols, including insurance and/or notarization
protocols may be absolutely needed, or at least highly useful in an 
environment where everyone is on-line, but that isn't always the case.

I don't want to have to download the entire CRL database in order to get the
5% that might have changed most recently -- hence, delta CRLs.

Bob

>>> Warwick Ford <[email-masked]> 06/16 9:07 PM >>>
Hi, Carlisle:

At 11:25 AM 6/15/98 -0400, Carlisle Adams wrote:
>Hi Warwick,
>
>> ----------
>> From: 	Warwick Ford[SMTP:[email-masked]] 
>> Sent: 	Saturday, June 13, 1998 5:27 PM
>> To: 	Robert Zuccherato; [email-masked]; 'Jessica Hymowitz'
>> Subject: 	RE: Certificate Revocation
>> 
>> I read with interest Robert and Carlisle's "White Paper".  It provides
>> some
>> helpful discussion of the indirection mechanism ("CRL List" mechanism)
>> developed in OCDP, and contains some interesting refinement ideas.  
>> 
>> The thought of using delta CRLs in conjubction with the CRL List mechanism
>> is interesting, although I suspect client implementors will not embrace
>> that, given the implementation complexities.  Back in the X.509 v3 design
>> days, Hoyt and I spent hours discussing the pros and cons of delta CRLs
>> and
>> we concluded that they may well be an attractive option for large servers
>> (for performance reasons) but not appropriate for clients (because of
>> state
>> maintenance problems).  I tend to think that same analysis will apply to
>> using delta CRLs with CRL Lists.
>> 
>Perhaps you could give some more detail regarding the "hours of discussion"
>you and Hoyt had on delta CRLs (feel free to copy him on the response, if
>you like, so he can join in if he wishes), because I don't understand your
>summary above at all.  Why would deltas have any more "state maintenance"
>than CRLs themselves?  Few people have built or will build a client that
>pulls down an entire CRL every time it wants to check revocation; rather, it
>typically pulls down a CRL once per period and caches it until its
>nextUpdate date.  Deltas don't in any way add to this state maintenance.
>All they do is allow a relying party to get fresher information (if they
>want it) between CRL updates.

Yes, I would welcome Hoyt's views (I consider Hoyt to be the father of
delta CRLs).  The volume of discussion was largely because the two concepts
of delta CRLs and CRL partitions were themselves being designed at the time
and we were trying to be sure we understood the rationale for having both
mechanisms.  I won't try to go through all the paths here, but rather shall
try to spell out the bottom line.  The complicating factor with deltas is
that someone checking revocation is no longer able to process a single data
item to be certain that the cert is not revoked.  Rather he/she/it needs to
obtain, validate, and scan at least two separate data items (the delta and
the base CRL), and maybe more depending on your delta regime.  Deltas are
inherently state-oriented, in that it only makes sense to deploy them in an
environment in which you have a general expectation that, when you fetch
the delta CRL, you already hold, from some prior activity, the base CRL or
contents thereof.  This is likely true in a busy server but more
questionable in a small client system which does only very sporadic
revocation checks with any given CA.  The reason for using deltas is to
keep down the size of items retrieved.  An alternative means of keeping
down size is partitioning, and if partitioning if done sufficiently
intelligently (note that, with Scopes, we now have some interesting new
options for intelligent partitioning), the use of deltas may not be
warranted, especially in small clients.  That said, let me make clear that
I am not opposed to deltas -- I have always supported having them as an
option, and I think your proposal for using them in CRL lists is a good
idea -- as an option.  

>> One deficiency in Robert and Carlisle's analysis is their lack of
>> recognition of one of the most important underlying concepts of OCDP.  If
>> unsigned pointers indeed have denial of service implications, the solution
>> offered by Robert and Carlisle, that is to have the CA sign the pointer,
>> is
>> just not the general answer.  The point is that, in many spheres of
>> application of certificates, the issue of revocation or status checking is
>> considered a relying-party-domain-control issue -- not a
>> certificate-issuer-domain-control issue.  In other words, the relying
>> party's enterprise will decide where, and under what policy conditions,
>> its
>> relying parties will go to check certificate status.  This could very well
>> be a local server or directory -- not back at the CA.
>> 
>> Financial industry applications, for example, generally reflect this model
>> (for good business reasons).  For example, with credit cards, the merchant
>> goes to its acquirer for a card authorization -- not directly to the
>> issuer.  The credit card equivalent of a CDP would be for the issuer to
>> include its contact details (for card authorization purposes) on the card
>> -- this is not the practice. 
>> 
>> For this reason (among others) we saw it important to move away from the
>> model in which the revocation mechanism is rigidly tied to an embedded
>> revocation pointer in the certificate itself.  I feel that any work to
>> further develop the OCDP ideas should definitely preserve this aspect of
>> the OCDP model.
>> 
>You claim above that we have not recognized one of the most important
>underlying concepts of OCDP.  On the contrary, I suggest that you seem not
>to have recognized *the* most important underlying concept of CDP:  it is
>OPTIONAL (and when it is used, it is NON-CRITICAL).  Thus, there is no
>standard anywhere in which "the revocation mechanism is rigidly tied to an
>embedded revocation pointer in the certificate itself".  CAs can put
>distribution points in certificates, or not.  If they happen to do so,
>relying parties can go to the location pointed to for revocation
>information, or can go somewhere else of their own choosing (note that since
>the extension is non-critical, a relying party may not have software that
>understands the extension while still being perfectly conformant with X.509
>and PKIX).

You need to clarify something in your paper.  In your early material you
appeared to dismiss OCDP with the comment "The use of unsigned pointers,
however, leaves the proposal open to denial-of-service attacks."  While I
don't understand or subscribe to that comment, I read into it that you were
similarly dismissing all mechanisms that did not use CDPs.  I welcome the
new assurance that that is not the case, and suggest you clarify that you
recognize the need for non-CDP mechanisms (such as OCDP) as well as the CDP
mechanism, dependent on needs.

Warwick 

---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., Tel (781)2456996 x225; Fax (781)2456006
[email-masked];  301 Edgewater Pl, Suite 210, Wakefield, MA 01880
---------------------------------------------------------------------

From: Robert Zuccherato <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "'Frank Acker'" <[email-masked]>
Subject: RE: Time Stamp and "Notary" Drafts
Date: Wed, 17 Jun 1998 16:41:02 -0400
Sender: [email-masked]

Frank;

Thank you for your interest in our work.  I don't think that the changes you
suggested are needed however, and may introduce a flaw in the protocol.  Let
me explain.  You write:

> ----------
> From: 	Frank Acker[SMTP:[email-masked]]
> Sent: 	Wednesday, June 17, 1998 2:32 PM
> To: 	Robert Zuccherato; [email-masked]'
> Subject: 	Re: Time Stamp and "Notary" Drafts
> 
> In section 5 of "Data Certification Server Protocols", the data to be
> certified is defined as follows:
> 
> "The Data type is defined to be either the message itself, a hash of 
> the message (this allows a signature indicating possession of private 
> data to be certified) or the certificate to be verified.  
> 
> Data ::= CHOICE  {
>      message                [0]  Message,
>      messageimprint         [1]  MessageImprint,
>      certs                  [2]  SEQUENCE SIZE (1..MAX) OF "
> 
> Ignoring the 'certs' type for the sake of this discussion, the type of
> data
> can be *either* a message *or* a messageImprint (a hash of the message).
> One or the other.  But not both.
> 
> I suggest that the choice should be a (required) messageImprint *and*
> (optionally) the message (from which the hash was computed). 
> 
> Furthermore, I suggest that the message (if present) be unsigned.  Since
> the messageImprint is signed, it is not necessary to include (and
> redundantly hash) the message in the signature.
> 
So, if I understand you correctly, the hash of the message would be included
in the signed part, and the message would be sent unsigned.  Is this
correct?

> The reason I make these suggestions is two-fold: DCS server performance
> improvement and bandwidth reduction.
> 
> If a DCS client includes the message in the request, the message must be
> hashed by the client with either approach, so there is no gain on the
> client side. 
> 
Agreed.

> However, by including the hash of the message in the request
> (and not signing the message component), the DCS server has less work to
> do
> to verify the signature on the request (i.e. it does not have to hash the
> message).  
> 
Here is where I have a problem.  If the server does not hash the unsigned
message, and just verifies the signature on the message imprint, an attacker
could replace the unsigned message with anything.  Assume we are in the
situation where the message has data type id-signedData and the server is
verifying the signature in that message.  That message could be replaced
with anything and the server would never know because it never hashed the
message to compare it with the message imprint in the signed part of the
request.  Thus, the server must always hash everything and therefore has no
less work to do.

> The only extra overhead here is small amount of memory for the
> hash of the message.
> 
> Now, since both the message and the messageImprint have been sent to the
> DCS server, both the client and the server have a copy of that message.
> 
Under your proposal, they might not if the message wasn't hashed and
compared with that in the signature.

> Since the server is not signing the message component, I suggest that the
> message be removed from the DCSReqInfo that is encapsulated in the
> DCSInfo.
> This would reduce the bandwidth requirements because the token returned to
> the client would not contain the (optional) message...only the (required)
> hash of it.
> 
Actually, if you look at page 5 of the draft, DCSReqInfo does not contain
the message.  The message is bound to the token in DCSInfo by including its
message imprint.  Thus, the draft already does what you ask for here.

	Robert.

Date: Wed, 17 Jun 1998 11:32:54 -0700
To: Robert Zuccherato <[email-masked]>, "[email-masked]'" <[email-masked]>
From: Frank Acker <[email-masked]>
Subject: Re: Time Stamp and "Notary" Drafts
Sender: [email-masked]

Robert:

Thank you for your work in defining the Data Certification Server
Protocols.  I have a couple of suggestions that might improve the
robustness of the protocol.

In section 5 of "Data Certification Server Protocols", the data to be
certified is defined as follows:

"The Data type is defined to be either the message itself, a hash of 
the message (this allows a signature indicating possession of private 
data to be certified) or the certificate to be verified.  

Data ::= CHOICE  {
     message                [0]  Message,
     messageimprint         [1]  MessageImprint,
     certs                  [2]  SEQUENCE SIZE (1..MAX) OF "

Ignoring the 'certs' type for the sake of this discussion, the type of data
can be *either* a message *or* a messageImprint (a hash of the message).
One or the other.  But not both.

I suggest that the choice should be a (required) messageImprint *and*
(optionally) the message (from which the hash was computed). 

Furthermore, I suggest that the message (if present) be unsigned.  Since
the messageImprint is signed, it is not necessary to include (and
redundantly hash) the message in the signature.

The reason I make these suggestions is two-fold: DCS server performance
improvement and bandwidth reduction.

If a DCS client includes the message in the request, the message must be
hashed by the client with either approach, so there is no gain on the
client side. However, by including the hash of the message in the request
(and not signing the message component), the DCS server has less work to do
to verify the signature on the request (i.e. it does not have to hash the
message).  The only extra overhead here is small amount of memory for the
hash of the message.

Now, since both the message and the messageImprint have been sent to the
DCS server, both the client and the server have a copy of that message.
Since the server is not signing the message component, I suggest that the
message be removed from the DCSReqInfo that is encapsulated in the DCSInfo.
This would reduce the bandwidth requirements because the token returned to
the client would not contain the (optional) message...only the (required)
hash of it.

The benefits are increased DCS server performance and reduced network
traffic, particularly for large messages.

Regards,

Frank

------------------------------------------------------
Frank Acker	                 [email-masked]
Senior Member Technical Staff
Coastek, Inc.                  www.coastek.com
5550 Scotts Valley Drive       408-440-0180 X408
Scotts Valley, CA  95066

Date: Wed, 17 Jun 1998 13:50:06 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: proof-of-possession for DH keys
Sender: [email-masked]

> From: Denis Pinkas <[email-masked]>
> 
> [Tony writes]
> 
> Is the "key" issue here (sorry about that) that by requiring POP for
> encypherment/agreement key certification, one gets authentication "for
> free" when message encryption is employed?  Otherwise, a protocol would
> require that the encrypted data be, in addition, signed?
> 
> [Denis writes]
> 
> Yes, Tony, this is the key point.  :-) 
> 
> More precisely, the key usage bits shall/should indicate what kind of
> SERVICE can be handled with the key, instead of the kind of MECHANISM
> that may be supported with the key. We already tackled the issue when
> taken about non repudiation (which is a service and not a mechanism). We
> have another case here.
> 
> Now let me try to answer the question from Nada, and let us restrict the
> discusssion for the next two lines to keys only able to encrypt/decrypt.
> 
> If the key is used to support a confidentiality service, then POP is NOT
> required.
> If the key is used to support an authentication service, then POP is
> required.

Which leads to:

  If the key is not used to support an authentication service, then
  neither POP nor a certificate is required.

The first case above is incorrect, since KEA keys are used to support
both confidentiality and authentication.  D-H keys may be used in both
authenticating and ephemeral protocols.

I agree with Carlisle that if the PKI is being invoked to certify a
keypair, then POP is required.  And I agree with Adam that a PKI cannot
prevent "auto-DoS" :-).  The way forward is for the PKI specification
to remain as it is, with POP required for every certified keypair.
If POP does not make sense for a particular application, then the
way to not use it is to not invoke the PKI (request or rely upon
a certificate) in the first place.

Date: Wed, 17 Jun 1998 10:50:24 -0700
To: <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject: RE: PKIX-1 - use of UTF8
Sender: [email-masked]

I'll add a "me too" to Phill and John. We have a stable UTF-8 definition in
the IETF (RFC 2279), and it is the recommended charset in the BCP document
on i18n (RFC 2277). There's no need to emit BMPString in PKIX.

--Paul Hoffman, Director
--Internet Mail Consortium

From: "Phillip M Hallam-Baker" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: PKIX-1 - use of UTF8
Date: Wed, 17 Jun 1998 12:33:54 -0400
Importance: Normal
Sender: [email-masked]

> Rationale:
> 
> As discussed on the list, the current text means that BMPString will be
> used for all names that don't fit into the restricted printableString
> character-set; UTF8 will never be used.  UTF8 is a much more
> implementor-friendly code-set than BMPString, and is the IETF's 
> recommended
> international codeset, and we should use it in preference to BMPString.

I think John's point is entirely right. UTF8 is the standard folk
are building their O/S arround. We should use it.

		Phill

From: Carlisle Adams <[email-masked]>
To: "'Adam Back'" <[email-masked]>
Cc: [email-masked]
Subject: RE: proof-of-possession for DH keys
Date: Wed, 17 Jun 1998 12:27:42 -0400
Sender: [email-masked]

Hi Adam,

> ----------
> From: 	Adam Back[SMTP:[email-masked]]
> Sent: 	Tuesday, June 16, 1998 8:31 PM
> To: 	[email-masked]
> Cc: 	[email-masked]; [email-masked]
> Subject: 	Re: proof-of-possession for DH keys
> 
> 
> Carlisle writes:
> > > You assume that I am holding the corresponding private decryption key.
> > > If I don't, I am unable to decrypt. That case might happen if, when
> > > performing my certification request, I provided garbage data instead
> of
> > > a real public key or if I *willingly* gave the value of the public key
> > > from someone else. 
> > > 
> > 
> > This is the whole purpose of doing POP: precisely to prevent such
> > pointless actions on the part of the requester.
> 
> Preventing against the "pointless action" attack is kind of hard --
> normally parties are expected to be acting in their own interests.
> 
> You are proposing that we instead consider that parties are trying to
> act in as obtuse a manner as they are able, by creating random public
> keys (which will result in their receiving messages which they will
> not be able to decrypt).  
> 
> You would then be proposing that our task is to detect and prevent
> this behaviour within the protocol.  It seems that the particular
> pointless action attack you are interested to prevent is self
> inflicted DoS.
> 
We are in agreement that you can't really stop people from doing dumb (or at
least pointless) things if they really want to.  However, if you can avoid
having a CA authoritatively put its stamp of approval on this "pointless
thing", thereby causing people to trust it, it seems to me that this is
worth doing.  I honestly can't understand why you would argue otherwise.

> Earlier I gave an example of how Mary (the Masochist, our self
> destructive party) can still perform a self inflicted DoS attack even
> in the presence of POPs which claim to defend against this: (1) delete
> her private key immediately after creating the POP.
> 
> Another attack Mary might perform (2) is to post her private key to
> USENET, destroying your expectation of privacy in using her public
> key.
> 
> Or Mary might (3) post the plaintext all of your encrypted emails sent
> to her to USENET more immediately destroying your expectation of
> privacy.
> 
Presumably Mary might do all sorts of other things as well, but that's
hardly the point.  The point is that when the CA creates the certificate, it
authoritatively asserts a binding between the entity and a key pair (having
done its due diligence to ensure that the binding is valid).  Any future
action, subsequent to the creation of the certificate, may break the
validity of that binding (e.g., any of Mary's actions above, or legitimate
key compromise, etc.)  --  that's what revocation is for.  But if we allow
the situation in which even the initial binding asserted by the CA cannot be
trusted, then certificates are meaningless and there is, in effect, no
useful PKI.  Is this really what we want PKIX to define?

> You can actually do things to reduce the risk of and/or increase the
> costs to Mary of performing all of these attacks, the question really
> though is does the utility gained justify the added complexity.
> 
In PKIX-CMP, the "added complexity" is one encryption of a small quantity on
the CA side and one decryption of that quantity on the client side; there
need not even be any extra messages in the exchange.  [CMP also allows the
case in which POP is done by some out-of-band means (i.e., outside the
protocol).]  This seems pretty insignificant considering that it can help
make the difference between useful and useless certificates.

--------------------------------------------
Carlisle Adams
Entrust Technologies
[email-masked]
--------------------------------------------

From: [email-masked]
To: [email-masked], [email-masked]
Date: Wed, 17 Jun 1998 09:49:30 -0400
Subject: PKIX-1 - use of UTF8
Sender: [email-masked]

As requested, here is a change request with suggested text, against the
latest PKIX-1 draft.

Top of page 20.  Current text:

    (a) if the character set is sufficient, the string will be represented
as a PrintableString;

    (b) failing (a), if the BMPString character set is sufficient the
string shall be represented as a BMPString; and

    (c) failing (a) and (b), the string shall be represented as a
UTF8String.

Replacement text:

    (a) if the character set is sufficient, the string will be represented
as a PrintableString;

    (b) failing (a), the string shall be represented as a UTF8String.

Rationale:

As discussed on the list, the current text means that BMPString will be
used for all names that don't fit into the restricted printableString
character-set; UTF8 will never be used.  UTF8 is a much more
implementor-friendly code-set than BMPString, and is the IETF's recommended
international codeset, and we should use it in preference to BMPString.

John

From: Nilsson Hans <[email-masked]>
To: "'Tim Polk'" <[email-masked]>, [email-masked]
Subject: SV: new profile submitted
Date: Wed, 17 Jun 1998 13:47:46 +0100
Sender: [email-masked]

Tim,
Can you please explain the background for the new writing regarding
subjectKeyIdentifier, using 0100 + 60 bits from the SHA-1 hash of the BIT
STRING subjectPublicKey? Is this in conformance with something else, or a
new invention?

Thanks

Hans Nilsson

Date: Wed, 17 Jun 1998 17:57:01 +1000
From: Michael Warner <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: proof-of-possession for DH keys
Cc: [email-masked]
Sender: [email-masked]

Carlisle Adams wrote:
> 
> Thank you, Denis.  I couldn't possibly have put the argument more succinctly
> than that!  You clearly agree that without POP I have no reason to use the
> public key in the certificate to encrypt for you.  Therefore, your
> encryption certificate is of no value whatsoever to me.

This is just not true... the certification authority has verified my
identity and I have given it the public key with which I want messages
for me to be encrypted.   So if anyone wants to encrypt message for
me they should use that key.   How I process the messages when they 
get to me is my business.

> 
> Why in the world would PKIX define protocols that allow such worthless
> certificates to be created?  PKIX is trying to create a usable PKI.  The PKI
> is not "usable" if I can't know which certificates I can use and which ones
> I can't.

Every protocol in the world allows useless activity to occur using it.   If 
you try to design protocols to prevent it, you invariably make them more 
complex than they need to be, and also prevent some useful activity 
that you haven't considered.   

The whole argument for mandating POP seems to be to allow broken 
security protocols to work in some specific imagined application.
I still haven't seen a realistic threat which is prevented by POP.

> 
> Carlisle.
> 
> 

Cheers,

Michael Warner
Telstra Research Laboratories

Date: Tue, 16 Jun 1998 17:35:47 -0700
To: Tim Polk <[email-masked]>, [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: new profile submitted
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

At 05:28 PM 6/16/98 -0400, Tim Polk wrote:
>It corporates all changes discussed in LA, but CRL distribution points was
>not excised from the draft.  After extensive negotiations, new licensing
>terms were completed THIS MORNING.
>
>(I will not speak to the agreement - I'm leaving that for Jeff Schiller.) 

<waiting for the other shoe to drop...> 

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Wed, 17 Jun 1998 01:31:32 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: proof-of-possession for DH keys
Sender: [email-masked]

Carlisle writes:
> > You assume that I am holding the corresponding private decryption key.
> > If I don't, I am unable to decrypt. That case might happen if, when
> > performing my certification request, I provided garbage data instead of
> > a real public key or if I *willingly* gave the value of the public key
> > from someone else. 
> > 
> 
> This is the whole purpose of doing POP: precisely to prevent such
> pointless actions on the part of the requester.

Preventing against the "pointless action" attack is kind of hard --
normally parties are expected to be acting in their own interests.

You are proposing that we instead consider that parties are trying to
act in as obtuse a manner as they are able, by creating random public
keys (which will result in their receiving messages which they will
not be able to decrypt).  

You would then be proposing that our task is to detect and prevent
this behaviour within the protocol.  It seems that the particular
pointless action attack you are interested to prevent is self
inflicted DoS.

Earlier I gave an example of how Mary (the Masochist, our self
destructive party) can still perform a self inflicted DoS attack even
in the presence of POPs which claim to defend against this: (1) delete
her private key immediately after creating the POP.

Another attack Mary might perform (2) is to post her private key to
USENET, destroying your expectation of privacy in using her public
key.

Or Mary might (3) post the plaintext all of your encrypted emails sent
to her to USENET more immediately destroying your expectation of
privacy.

You can actually do things to reduce the risk of and/or increase the
costs to Mary of performing all of these attacks, the question really
though is does the utility gained justify the added complexity.

The (marginal) utility that I see POP provides is early detection of
implementation flaws where the implementation erroneously submits
random data, garbled data, or malformed ASN.1 in place of a public key
(for example if it was written by Microsoft).

Adam

For the curious, mechanisms to reduce risks/increase costs are
respectively:

For attack (1) do as Denis Pinkas argued against on grounds of
practicality: demand a POP prior to sending encrypted message, or have
the CA demand fresh POPs periodically.  Or financially penalise Mary
if she fails to answer periodic POP challenges from the CA with funds
held in escrow.

For attack (2) use a ZKP to ensure that if Mary reveals her private
key she will be financially penalised, for example by including in the
certificate electronic cash encrypted with the private key.

For attack (3) use public key watermarking on your document prior to
encrypting and sending it to Mary.  (Public key watermarking prevents
against the obvious false accusation problem).  Present proof of
Mary's posting to the CA to have CA financially penalise Mary.

Date: Tue, 16 Jun 1998 20:07:58 -0700
To: Carlisle Adams <[email-masked]>, Robert Zuccherato <[email-masked]>, [email-masked], "'Jessica Hymowitz'" <[email-masked]>
From: Warwick Ford <[email-masked]>
Subject: RE: Certificate Revocation
Sender: [email-masked]

Hi, Carlisle:

At 11:25 AM 6/15/98 -0400, Carlisle Adams wrote:
>Hi Warwick,
>
>> ----------
>> From: 	Warwick Ford[SMTP:[email-masked]]
>> Sent: 	Saturday, June 13, 1998 5:27 PM
>> To: 	Robert Zuccherato; [email-masked]; 'Jessica Hymowitz'
>> Subject: 	RE: Certificate Revocation
>> 
>> I read with interest Robert and Carlisle's "White Paper".  It provides
>> some
>> helpful discussion of the indirection mechanism ("CRL List" mechanism)
>> developed in OCDP, and contains some interesting refinement ideas.  
>> 
>> The thought of using delta CRLs in conjubction with the CRL List mechanism
>> is interesting, although I suspect client implementors will not embrace
>> that, given the implementation complexities.  Back in the X.509 v3 design
>> days, Hoyt and I spent hours discussing the pros and cons of delta CRLs
>> and
>> we concluded that they may well be an attractive option for large servers
>> (for performance reasons) but not appropriate for clients (because of
>> state
>> maintenance problems).  I tend to think that same analysis will apply to
>> using delta CRLs with CRL Lists.
>> 
>Perhaps you could give some more detail regarding the "hours of discussion"
>you and Hoyt had on delta CRLs (feel free to copy him on the response, if
>you like, so he can join in if he wishes), because I don't understand your
>summary above at all.  Why would deltas have any more "state maintenance"
>than CRLs themselves?  Few people have built or will build a client that
>pulls down an entire CRL every time it wants to check revocation; rather, it
>typically pulls down a CRL once per period and caches it until its
>nextUpdate date.  Deltas don't in any way add to this state maintenance.
>All they do is allow a relying party to get fresher information (if they
>want it) between CRL updates.

Yes, I would welcome Hoyt's views (I consider Hoyt to be the father of
delta CRLs).  The volume of discussion was largely because the two concepts
of delta CRLs and CRL partitions were themselves being designed at the time
and we were trying to be sure we understood the rationale for having both
mechanisms.  I won't try to go through all the paths here, but rather shall
try to spell out the bottom line.  The complicating factor with deltas is
that someone checking revocation is no longer able to process a single data
item to be certain that the cert is not revoked.  Rather he/she/it needs to
obtain, validate, and scan at least two separate data items (the delta and
the base CRL), and maybe more depending on your delta regime.  Deltas are
inherently state-oriented, in that it only makes sense to deploy them in an
environment in which you have a general expectation that, when you fetch
the delta CRL, you already hold, from some prior activity, the base CRL or
contents thereof.  This is likely true in a busy server but more
questionable in a small client system which does only very sporadic
revocation checks with any given CA.  The reason for using deltas is to
keep down the size of items retrieved.  An alternative means of keeping
down size is partitioning, and if partitioning if done sufficiently
intelligently (note that, with Scopes, we now have some interesting new
options for intelligent partitioning), the use of deltas may not be
warranted, especially in small clients.  That said, let me make clear that
I am not opposed to deltas -- I have always supported having them as an
option, and I think your proposal for using them in CRL lists is a good
idea -- as an option.  

>> One deficiency in Robert and Carlisle's analysis is their lack of
>> recognition of one of the most important underlying concepts of OCDP.  If
>> unsigned pointers indeed have denial of service implications, the solution
>> offered by Robert and Carlisle, that is to have the CA sign the pointer,
>> is
>> just not the general answer.  The point is that, in many spheres of
>> application of certificates, the issue of revocation or status checking is
>> considered a relying-party-domain-control issue -- not a
>> certificate-issuer-domain-control issue.  In other words, the relying
>> party's enterprise will decide where, and under what policy conditions,
>> its
>> relying parties will go to check certificate status.  This could very well
>> be a local server or directory -- not back at the CA.
>> 
>> Financial industry applications, for example, generally reflect this model
>> (for good business reasons).  For example, with credit cards, the merchant
>> goes to its acquirer for a card authorization -- not directly to the
>> issuer.  The credit card equivalent of a CDP would be for the issuer to
>> include its contact details (for card authorization purposes) on the card
>> -- this is not the practice. 
>> 
>> For this reason (among others) we saw it important to move away from the
>> model in which the revocation mechanism is rigidly tied to an embedded
>> revocation pointer in the certificate itself.  I feel that any work to
>> further develop the OCDP ideas should definitely preserve this aspect of
>> the OCDP model.
>> 
>You claim above that we have not recognized one of the most important
>underlying concepts of OCDP.  On the contrary, I suggest that you seem not
>to have recognized *the* most important underlying concept of CDP:  it is
>OPTIONAL (and when it is used, it is NON-CRITICAL).  Thus, there is no
>standard anywhere in which "the revocation mechanism is rigidly tied to an
>embedded revocation pointer in the certificate itself".  CAs can put
>distribution points in certificates, or not.  If they happen to do so,
>relying parties can go to the location pointed to for revocation
>information, or can go somewhere else of their own choosing (note that since
>the extension is non-critical, a relying party may not have software that
>understands the extension while still being perfectly conformant with X.509
>and PKIX).

You need to clarify something in your paper.  In your early material you
appeared to dismiss OCDP with the comment "The use of unsigned pointers,
however, leaves the proposal open to denial-of-service attacks."  While I
don't understand or subscribe to that comment, I read into it that you were
similarly dismissing all mechanisms that did not use CDPs.  I welcome the
new assurance that that is not the case, and suggest you clarify that you
recognize the need for non-CDP mechanisms (such as OCDP) as well as the CDP
mechanism, dependent on needs.

Warwick 

---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., Tel (781)2456996 x225; Fax (781)2456006
[email-masked];  301 Edgewater Pl, Suite 210, Wakefield, MA 01880
---------------------------------------------------------------------

Date: Tue, 16 Jun 1998 17:28:41 -0400
To: [email-masked]
From: Tim Polk <[email-masked]>
Subject: new profile submitted
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

I have submitted the new draft of the profile.  In the interim, you can get
it via the following URL:

http://csrc.nist.gov/pki/draft-ietf-pkix-ipki-part1-08.txt

It corporates all changes discussed in LA, but CRL distribution points was
not excised from the draft.  After extensive negotiations, new licensing
terms were completed THIS MORNING.

(I will not speak to the agreement - I'm leaving that for Jeff Schiller.) 

Brief Notes:

#1 I am asking for Last Call.

#2 If you want something changed, please submit your suggestions to the
list WITH TEXT.  We want to forward this to the IESG as soon as possible.
That will not be possible if we discuss abstract changes on the list.
Concrete text is a MUST.

#3 The document isn't really longer - the ASN.1 in the appendices is simply
more complete.

Thanks,

Tim Polk

Date: Tue, 16 Jun 1998 11:01:11 -0600
From: Mike Smith <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: Re: RE: proof-of-possession for DH keys
Sender: [email-masked]

There is another important reason for a PKI deployer to require POP, aside from the "I have the private key" assertion of the certificate requestor.  With POP, the deployer/issuer will know that the requestor has in her or his possession a tool that can create a digital signature AND that their own tools (within the PKI that they are issuing the cert) can validate the signature using the signed request and included public key.

This is an operational reeason that would be a best business practice, and separate from a tech spec, but important none the less.  So, POP is a good business practice and a good thing in generla.  The question then becomes< "where should POP be specified".  If the intent is to define a minimum operational specification, then POP, time and date stamping, transaction logging and many more things should be included in such a document.  These operational procedure capabilities must be supported by the technical requirements at a minimum, but not the requirement to conduct such operational testing itself.  POP and all other operational requirements or best practices should be in the policies and concept of operations efforts and so should the debate.

Michael

>>> Carlisle Adams <[email-masked]> 06/16 9:54 AM >>>
Hi Adam,

> ----------
> From:  Adam Back[SMTP:[email-masked]] 
> Sent:  Tuesday, June 16, 1998 7:30 AM
> To:  [email-masked] 
> Cc:  [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked] 
> Subject:  Re: proof-of-possession for DH keys
> 
> 
> Carlisle Adams writes:
> > A certificate [...] is a binding between an entity and a key pair.
> > I think we all recognize that the CA should verify the identity of
> > the requester [...]  However, until we've got [...] operational
> > protocols that verify that the entity named in the certificate has
> > possession of *both* halves of the key pair, the only prudent action
> > is to mandate that the CA must verify this as well.  If this is not
> > done, certificates in the PKI have no meaning and are, for all
> > intents and purposes, worthless.
> 
> Others have used this argument.  I think this line of reasoning is
> suspect.
> 
> A CA's purpose is to certify public key <-> name bindings based on
> some procedure for verifying the identity of the certification request
> originator.
> 
> If a user chooses to supply a public key which he does not have the
> private key for, all he is doing is performing a DoS attack against
> himself.  This is not an interesting class of attack (self inflicted
> DoS), therefore defending against it is also uninteresting.  It is
> impossible to defend against self inflicted DoS -- I could as easily
> destroy the private key immediately creating the proof of possession.
> 
POP is *NOT* done to defend against denial-of-service attacks.  [I'm
beginning to wonder how many times I've said this in the past couple of
years...]  It's primary goal has nothing whatsoever to do with any kind of
attack (although it can coincidentally help to avoid a particular attack in
the case of signing key pairs).

POP is done so that a certificate has meaning, is trustworthy in some sense,
to a relying party.  When I use your certificate (to encrypt for you, to
verify your signature, whatever), it is because I assume that you hold the
private key corresponding to the public key in the certificate.  If I can't
make that assumption, then I have no reason *whatsoever* to use your
certificate (*regardless* of any possible security attack; I simply have no
reason to use your cert.).  This is not a useful PKI by any definition.

> It is an unnecessary restriction to require proof of possession of
> private keys for algorithms which provide only encryption, and do not
> directly provide a signature method.
> 
I can't see why trying to ensure that meaningful certificates are created is
an "unnecessary restriction" in PKIX.

> Separation of concerns suggests that signature keys and signature
> algorithms should be used to delegate trust to encryption keys,
> whether by individuals using signature keys ceritified by CAs, or by
> CAs certifying encryption keys directly.
> 
I don't understand your comment here.  This is precisely what PKIX does,
because certificates are signed by signature keys.  All we're saying is
that, as much as this can be determined,  trust should be delegated to
something trustworthy.

--------------------------------------------
Carlisle Adams
Entrust Technologies
[email-masked] 
--------------------------------------------

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            

From: Carlisle Adams <[email-masked]>
To: "'Adam Back'" <[email-masked]>
Cc: [email-masked]
Subject: RE: proof-of-possession for DH keys
Date: Tue, 16 Jun 1998 11:54:01 -0400
Sender: [email-masked]

Hi Adam,

> ----------
> From: 	Adam Back[SMTP:[email-masked]]
> Sent: 	Tuesday, June 16, 1998 7:30 AM
> To: 	[email-masked]
> Cc: 	[email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: 	Re: proof-of-possession for DH keys
> 
> 
> Carlisle Adams writes:
> > A certificate [...] is a binding between an entity and a key pair.
> > I think we all recognize that the CA should verify the identity of
> > the requester [...]  However, until we've got [...] operational
> > protocols that verify that the entity named in the certificate has
> > possession of *both* halves of the key pair, the only prudent action
> > is to mandate that the CA must verify this as well.  If this is not
> > done, certificates in the PKI have no meaning and are, for all
> > intents and purposes, worthless.
> 
> Others have used this argument.  I think this line of reasoning is
> suspect.
> 
> A CA's purpose is to certify public key <-> name bindings based on
> some procedure for verifying the identity of the certification request
> originator.
> 
> If a user chooses to supply a public key which he does not have the
> private key for, all he is doing is performing a DoS attack against
> himself.  This is not an interesting class of attack (self inflicted
> DoS), therefore defending against it is also uninteresting.  It is
> impossible to defend against self inflicted DoS -- I could as easily
> destroy the private key immediately creating the proof of possession.
> 
POP is *NOT* done to defend against denial-of-service attacks.  [I'm
beginning to wonder how many times I've said this in the past couple of
years...]  It's primary goal has nothing whatsoever to do with any kind of
attack (although it can coincidentally help to avoid a particular attack in
the case of signing key pairs).

POP is done so that a certificate has meaning, is trustworthy in some sense,
to a relying party.  When I use your certificate (to encrypt for you, to
verify your signature, whatever), it is because I assume that you hold the
private key corresponding to the public key in the certificate.  If I can't
make that assumption, then I have no reason *whatsoever* to use your
certificate (*regardless* of any possible security attack; I simply have no
reason to use your cert.).  This is not a useful PKI by any definition.

> It is an unnecessary restriction to require proof of possession of
> private keys for algorithms which provide only encryption, and do not
> directly provide a signature method.
> 
I can't see why trying to ensure that meaningful certificates are created is
an "unnecessary restriction" in PKIX.

> Separation of concerns suggests that signature keys and signature
> algorithms should be used to delegate trust to encryption keys,
> whether by individuals using signature keys ceritified by CAs, or by
> CAs certifying encryption keys directly.
> 
I don't understand your comment here.  This is precisely what PKIX does,
because certificates are signed by signature keys.  All we're saying is
that, as much as this can be determined,  trust should be delegated to
something trustworthy.

--------------------------------------------
Carlisle Adams
Entrust Technologies
[email-masked]
--------------------------------------------

From: Carlisle Adams <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: [email-masked]
Subject: RE: proof-of-possession for DH keys
Date: Tue, 16 Jun 1998 11:29:36 -0400
Sender: [email-masked]

Hi Denis,

> ----------
> From: 	Denis Pinkas[SMTP:[email-masked]]
> Sent: 	Tuesday, June 16, 1998 6:06 PM
> To: 	Carlisle Adams
> Cc: 	[email-masked]
> Subject: 	Re: proof-of-possession for DH keys
> 
> > However, until we've got (in a completely ubiquitous way,
> > without any exceptions whatsoever) operational protocols that verify
> that
> > the entity named in the certificate has possession of *both* halves of
> the
> > key pair, 
> 
> This is the issue. We are now saying that, in the current draft, we
> mandate POP for encryption keys but without a justification for it. If
> there is no justification, then we should not mandate it.
> 
> > the only prudent action is to mandate that the CA must verify this
> > as well.  If this is not done, certificates in the PKI have no meaning
> and
> > are, for all intents and purposes, worthless.
> 
> This is not a justification.
> 
Given that the entire goal of PKIX is to create a usable PKI for the
Internet, it seems clear that avoiding meaningless, worthless certificates
*is* a justification.

> > If I'm going to encrypt for you using your public encryption key, I must
> be
> > confident that you hold the corresponding private decryption key or else
> why
> > would I bother encrypting?  
> 
> You assume that I am holding the corresponding private decryption key.
> If I don't, I am unable to decrypt. That case might happen if, when
> performing my certification request, I provided garbage data instead of
> a real public key or if I *willingly* gave the value of the public key
> from someone else. 
> 
This is the whole purpose of doing POP:  precisely to prevent such pointless
actions on the part of the requester.

> > Perhaps I can go through some sort of on-line
> > protocol with you to see if you have the private key, but clearly this
> is
> > not always practical (not to mention that such (standardized) protocols
> do
> > not currently exist for most environments...).  
> > Consequently, the only course of action is to assume that 
> > the certificate binds the entity to the *pair* of keys.
> > Otherwise, I have no reason to use the public key in the
> > certificate to encrypt for you.
> 
> Fine.
> 
Thank you, Denis.  I couldn't possibly have put the argument more succinctly
than that!  You clearly agree that without POP I have no reason to use the
public key in the certificate to encrypt for you.  Therefore, your
encryption certificate is of no value whatsoever to me.

Why in the world would PKIX define protocols that allow such worthless
certificates to be created?  PKIX is trying to create a usable PKI.  The PKI
is not "usable" if I can't know which certificates I can use and which ones
I can't.

Carlisle.

Date: Tue, 16 Jun 1998 15:06:38 -0700
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: Carlisle Adams <[email-masked]>
CC: [email-masked]
Subject: Re: proof-of-possession for DH keys
Sender: [email-masked]

Carlisle,

It seems that we have different views on this issue.

> A certificate (at least for the purposes of PKIX) is a binding between an
> entity and a key pair.  I think we all recognize that the CA should verify
> the identity of the requester (i.e., that identity = "id of the entity", so
> to speak  :-).  

... but also verify that the request is coming from that entity. As Adam
Back said in a response to you:

" A CA's purpose is to certify public key <-> name bindings based on
some procedure for verifying the identity of the certification request
originator."

> However, until we've got (in a completely ubiquitous way,
> without any exceptions whatsoever) operational protocols that verify that
> the entity named in the certificate has possession of *both* halves of the
> key pair, 

This is the issue. We are now saying that, in the current draft, we
mandate POP for encryption keys but without a justification for it. If
there is no justification, then we should not mandate it.

> the only prudent action is to mandate that the CA must verify this
> as well.  If this is not done, certificates in the PKI have no meaning and
> are, for all intents and purposes, worthless.

This is not a justification. Again, Adam Back gave the right answer:

" If a user chooses to supply a public key which he does not have the
private key for, all he is doing is performing a DoS [Denial of Service]
attack against himself."
 
> If I'm going to encrypt for you using your public encryption key, I must be
> confident that you hold the corresponding private decryption key or else why
> would I bother encrypting?  

You assume that I am holding the corresponding private decryption key.
If I don't, I am unable to decrypt. That case might happen if, when
performing my certification request, I provided garbage data instead of
a real public key or if I *willingly* gave the value of the public key
from someone else. 

> Perhaps I can go through some sort of on-line
> protocol with you to see if you have the private key, but clearly this is
> not always practical (not to mention that such (standardized) protocols do
> not currently exist for most environments...).  

I agree with you that we should not.  :-)

> Consequently, the only course of action is to assume that 
> the certificate binds the entity to the *pair* of keys.

Your assumption is correct, but it is only an assumption, ... not a
proof.
  
> Otherwise, I have no reason to use the public key in the
> certificate to encrypt for you.

Fine.
 
> > [Denis writes]

> > More precisely, the key usage bits shall/should indicate what kind of
> > SERVICE can be handled with the key, instead of the kind of MECHANISM
> > that may be supported with the key. We already tackled the issue when
> > taken about non repudiation (which is a service and not a mechanism). We
> > have another case here.

> > Now let me try to answer the question from Nada, and let us restrict the
> > discusssion for the next two lines to keys only able to encrypt/decrypt.

> > If the key is used to support a confidentiality service, then POP is NOT
> > required.
> > If the key is used to support an authentication service, then POP is
> > required.

> > My conclusion is that the key usage bits shall always indicate the usage
> > of the key for, at least, one security SERVICE. If we still use some
> > bits to indicate a mechanism (like digital signature) then at least one
> > key usage bit for a service should be present. Now, I wonder if we still
> > need bits for mechanisms. If we do, making a clear cut between service
> > bits and mechanism bits, will certainly help to clarify the overall
> > topic.

> > Note : For the difference between a service and a mechanism see ISO
> > 7498-2 (where digital signature is defined as a mechanism, and not as
> > service). See table 1. BTW, ISO 7498-2 is already 10 years old.

> This has nothing whatsoever to do with specific attacks and nothing
> whatsoever to do with services vs. mechanisms (as useful as that distinction
> might be).  

I respectfully disagree with you on this. The distinction is fairly
important. There exists some protocols (that I do not like too much) but
which nevertheless allow to perform per entity authentication while
using encrypting keys (instead of signature keys). In that case it is
mandatory to perform POP.

> It has to do with whether or not it makes sense for me to use
> the public key in your certificate to encrypt for you.  If POP has been
> done, then it makes sense for me to use your certificate.  

... in order to support one of the following services: per entity
authentication, data origin authentication with integrity or data
confidentiality.

> If POP has not been done, 

... then it makes sense to use your certificate, in order to support
only the following service: data confidentiality.

> then I might as well use any arbitrary public key 

No. You won't do this. Will you ?  :-)

> (or, in fact, I might as well not encrypt because I have absolutely 
> no reason to think that you will be able to decrypt the data).

Denis

-- 
      Denis Pinkas     Bull S.A.          mailto:[email-masked]
      Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

Date: Tue, 16 Jun 1998 12:30:55 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: proof-of-possession for DH keys
Sender: [email-masked]

Carlisle Adams writes:
> A certificate [...] is a binding between an entity and a key pair.
> I think we all recognize that the CA should verify the identity of
> the requester [...]  However, until we've got [...] operational
> protocols that verify that the entity named in the certificate has
> possession of *both* halves of the key pair, the only prudent action
> is to mandate that the CA must verify this as well.  If this is not
> done, certificates in the PKI have no meaning and are, for all
> intents and purposes, worthless.

Others have used this argument.  I think this line of reasoning is
suspect.

A CA's purpose is to certify public key <-> name bindings based on
some procedure for verifying the identity of the certification request
originator.

If a user chooses to supply a public key which he does not have the
private key for, all he is doing is performing a DoS attack against
himself.  This is not an interesting class of attack (self inflicted
DoS), therefore defending against it is also uninteresting.  It is
impossible to defend against self inflicted DoS -- I could as easily
destroy the private key immediately creating the proof of possession.

If an imposter manages to fool the CA into thinking that he is Bob,
then it seems likley that the imposter would be able to provide proof
of possession of the corresponding private key -- the attacker would
after all have generated the certificate request.

The authentication of the certificate request _has_ to take place
using other mechanisms anyway, because an attacker can easily replace
a certificate and a POP with an equally valid appearing cert and POP.

It is an unnecessary restriction to require proof of possession of
private keys for algorithms which provide only encryption, and do not
directly provide a signature method.

Separation of concerns suggests that signature keys and signature
algorithms should be used to delegate trust to encryption keys,
whether by individuals using signature keys ceritified by CAs, or by
CAs certifying encryption keys directly.

Adam

Date: Tue, 16 Jun 1998 10:24:24 +0200
To: Carlisle Adams <[email-masked]>, "'Nada Kapidzic Cicovic'" <[email-masked]>
From: Harald Tveit Alvestrand <[email-masked]>
Subject: RE: proof-of-possession for DH keys
Cc: [email-masked]
Sender: [email-masked]

At 10:24 12.06.98 -0400, Carlisle Adams wrote:
>
>The entire promise of public-key cryptography was that two complete
>strangers who had never met or exchanged data before could exchange data
>securely.  Without proof-of-possession, this promise falls apart.
>
I don't quite see this.
I think there are 2 parts to security with public-key cryptography:

- Possession. A self-signed certificate proves that *someone* has that
  key, and is enough for anonymous secure communication (unless there's a man
  in the middle. CA chains prove either that there's no man in the
  middle or that he's caught your other channels too.)
  Successful decryption of an encrypted message is also proof of possession.
- Sole possession. Secrecy depends on me being the *only* holder of my
  private key (or that the other holders are trustworthy too).
  A CA can only sign that I have promised that at one point in time;
  it is not a fact that can be verified.

So what you want the CA to verify with encryption keys is not really POPO,
but POPTTC - Proof of Promise To Take Care.

                            Harald A

-- 
Harald Tveit Alvestrand, Maxware, Norway
[email-masked]

Date: Mon, 15 Jun 1998 10:47:29 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Cc: [email-masked]
Subject: Re: RE: proof-of-possession for DH keys
Sender: [email-masked]

Sorry, Nada, you are quite right.  I guess I was thinking 
more about proving someone's bona fides than simply 
POP of the private key. Must have been
working too hard last week.

Not enforcing POP for encryption certificates potentially leads to a 
denial of service attack against the party named in the certificate, 
but not much else that I can see. But there might be some subtlety
that is escaping me.

Bob

>>> Nada Kapidzic Cicovic <[email-masked]> 06/15 2:42 AM >>>
At 12:36 6/12/98 -0600, Bob Jueneman wrote:
>Tony,
>
>No, the flow is going the other way. Carlisle's well stated 
>point is that whenever you validate a certificate, for 
>whatever purpose at all, you have to ensure that the 
>person whose public key is being bound into the certificate
>actually owns the private key.
>
>I think it is clear in the case of digital signatures -- someone else 
>could claim to have signed your invention disclosure, etc.
>
>But it is even worse if I take MY public key and send it to your CA
>along with a certificate request in your name.  Now someone 
>tries to send you encrypted mail, and you can't read it but I can.

Bob,

This is a problem no matter what type of certificate you want to get
certified, and enforcing POPO on the CA is not helping you get out of it.
You can create the valid POPO with YOUR private key corresponding to the
public key from the certificate and present it to the CA in my name. 

The problem you are describing has to do with having the CA authenticate
the request and prove for the binding between the request and your claimed
identity. POP is not the mechanism for doing that.

Regards,

Nada

>
>Bob
>
>>At 10:24 AM 6/12/98 -0400, Carlisle Adams wrote:
>>>Hi Nada,
>>
>>[Nada writes]
>>
>>>> For digitalSignature keys, proof of possession does make sense. You need
>>>> to
>>>> prove that you have the corresponding private key, so that you cannot get
>>>> a
>>>> certificate issued in your name containing someone else's public key.
>>
>>[Nada continues]
>>
>>>> However, I somehow fail to see the reason for proving POPO for
>>>> keyEncipherment and keyAgreement keys. If you request the
certification of
>>>> a keyEncipherment certificate with someone else's public key, I do not
see
>>>> what would you gain by getting it issued in your name.
>>
>>
>>[Carlisle replies]
>>
>>>After the signature on a cert. has been verified mathematically; after the
>>>cert. has been checked for revocation; after the signature and revocation
>>>status have been checked for all other certs involved in the path; after
>>>validity periods, key usage bits, policy OIDs, etc., etc., etc., have been
>>>confirmed to be acceptable, I *still* have to make the fundamental
>>>assumption that the entity named in the certificate owns the corresponding
>>>private key.  Otherwise, I have no reason whatsoever to use this
certificate
>>>instead of any other certificate or any bare public key.
>>
>>Friends,
>>
>>Is the "key" issue here (sorry about that) that by requiring POP for
>>encypherment/agreement key certification, one gets authentication "for
>>free" when message encryption is employed?  Otherwise, a protocol would
>>require that the encrypted data be, in addition, signed?
>>
>>___tony___
>>
>>Tony Bartoletti                                             LL
>>SPI-NET GURU                                             LL LL
>>Computer Security Technology Center                   LL LL LL
>>Lawrence Livermore National Lab                       LL LL LL
>>PO Box 808, L - 303                                   LL LL LLLLLLLL
>>Livermore, CA 94551-9900                              LL LLLLLLLL
>>email: [email-masked]   phone: 510-422-3881             LLLLLLLL
>
>
>

From: Carlisle Adams <[email-masked]>
To: Bob Jueneman <[email-masked]>, "[email-masked]'" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: RE: proof-of-possession for DH keys
Date: Mon, 15 Jun 1998 12:03:50 -0400
Sender: [email-masked]

Hi Denis,

> ----------
> From: 	Denis Pinkas[SMTP:[email-masked]]
> Sent: 	Monday, June 15, 1998 12:44 PM
> To: 	Bob Jueneman
> Cc: 	[email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: 	Re: proof-of-possession for DH keys
> 
> [Bob continues]
>  
> I think it is clear in the case of digital signatures -- someone else
> could claim to have signed your invention disclosure, etc.
>  
> But it is even worse if I take MY public key and send it to your CA
> along with a certificate request in your name.  Now someone
> tries to send you encrypted mail, and you can't read it but I can.
> 
> [Denis writes]
> 
> Bob, your scenario won't work: the CA should refuse to issue the
> certificate because you cannot authenticate your request to the RA/CA
> under someone else name. The CA shall verify that the name for which you
> request the certificate can be authenticated with your whole request
> (that includes a public key).
> 
Might I suggest that we all look back at the PKIX archives (personal or
public) on this thread?  This was all discussed quite thoroughly some time
ago...

A certificate (at least for the purposes of PKIX) is a binding between an
entity and a key pair.  I think we all recognize that the CA should verify
the identity of the requester (i.e., that identity = "id of the entity", so
to speak  :-).  However, until we've got (in a completely ubiquitous way,
without any exceptions whatsoever) operational protocols that verify that
the entity named in the certificate has possession of *both* halves of the
key pair, the only prudent action is to mandate that the CA must verify this
as well.  If this is not done, certificates in the PKI have no meaning and
are, for all intents and purposes, worthless.

If I'm going to encrypt for you using your public encryption key, I must be
confident that you hold the corresponding private decryption key or else why
would I bother encrypting?  Perhaps I can go through some sort of on-line
protocol with you to see if you have the private key, but clearly this is
not always practical (not to mention that such (standardized) protocols do
not currently exist for most environments...).  Consequently, the only
course of action is to assume that the certificate binds the entity to the
*pair* of keys.  Otherwise, I have no reason to use the public key in the
certificate to encrypt for you.

> [Denis writes]
> 
> More precisely, the key usage bits shall/should indicate what kind of
> SERVICE can be handled with the key, instead of the kind of MECHANISM
> that may be supported with the key. We already tackled the issue when
> taken about non repudiation (which is a service and not a mechanism). We
> have another case here.
> 
> Now let me try to answer the question from Nada, and let us restrict the
> discusssion for the next two lines to keys only able to encrypt/decrypt.
> 
> If the key is used to support a confidentiality service, then POP is NOT
> required.
> If the key is used to support an authentication service, then POP is
> required.
> 
> My conclusion is that the key usage bits shall always indicate the usage
> of the key for, at least, one security SERVICE. If we still use some
> bits to indicate a mechanism (like digital signature) then at least one
> key usage bit for a service should be present. Now, I wonder if we still
> need bits for mechanisms. If we do, making a clear cut between service
> bits and mechanism bits, will certainly help to clarify the overall
> topic.
> 
> Note : For the difference between a service and a mechanism see ISO
> 7498-2 (where digital signature is defined as a mechanism, and not as
> service). See table 1. BTW, ISO 7498-2 is already 10 years old.
> 
This has nothing whatsoever to do with specific attacks and nothing
whatsoever to do with services vs. mechanisms (as useful as that distinction
might be).  It has to do with whether or not it makes sense for me to use
the public key in your certificate to encrypt for you.  If POP has been
done, then it makes sense for me to use your certificate.  If POP has not
been done, then I might as well use any arbitrary public key (or, in fact, I
might as well not encrypt because I have absolutely no reason to think that
you will be able to decrypt the data).

--------------------------------------------
Carlisle Adams
Entrust Technologies
[email-masked]
--------------------------------------------

From: Carlisle Adams <[email-masked]>
To: Robert Zuccherato <[email-masked]>, [email-masked], "'Jessica Hymowitz'" <[email-masked]>, "'Warwick Ford'" <[email-masked]>
Subject: RE: Certificate Revocation
Date: Mon, 15 Jun 1998 11:25:09 -0400
Sender: [email-masked]

Hi Warwick,

> ----------
> From: 	Warwick Ford[SMTP:[email-masked]]
> Sent: 	Saturday, June 13, 1998 5:27 PM
> To: 	Robert Zuccherato; [email-masked]; 'Jessica Hymowitz'
> Subject: 	RE: Certificate Revocation
> 
> I read with interest Robert and Carlisle's "White Paper".  It provides
> some
> helpful discussion of the indirection mechanism ("CRL List" mechanism)
> developed in OCDP, and contains some interesting refinement ideas.  
> 
> The thought of using delta CRLs in conjubction with the CRL List mechanism
> is interesting, although I suspect client implementors will not embrace
> that, given the implementation complexities.  Back in the X.509 v3 design
> days, Hoyt and I spent hours discussing the pros and cons of delta CRLs
> and
> we concluded that they may well be an attractive option for large servers
> (for performance reasons) but not appropriate for clients (because of
> state
> maintenance problems).  I tend to think that same analysis will apply to
> using delta CRLs with CRL Lists.
> 
Perhaps you could give some more detail regarding the "hours of discussion"
you and Hoyt had on delta CRLs (feel free to copy him on the response, if
you like, so he can join in if he wishes), because I don't understand your
summary above at all.  Why would deltas have any more "state maintenance"
than CRLs themselves?  Few people have built or will build a client that
pulls down an entire CRL every time it wants to check revocation; rather, it
typically pulls down a CRL once per period and caches it until its
nextUpdate date.  Deltas don't in any way add to this state maintenance.
All they do is allow a relying party to get fresher information (if they
want it) between CRL updates.

> One deficiency in Robert and Carlisle's analysis is their lack of
> recognition of one of the most important underlying concepts of OCDP.  If
> unsigned pointers indeed have denial of service implications, the solution
> offered by Robert and Carlisle, that is to have the CA sign the pointer,
> is
> just not the general answer.  The point is that, in many spheres of
> application of certificates, the issue of revocation or status checking is
> considered a relying-party-domain-control issue -- not a
> certificate-issuer-domain-control issue.  In other words, the relying
> party's enterprise will decide where, and under what policy conditions,
> its
> relying parties will go to check certificate status.  This could very well
> be a local server or directory -- not back at the CA.
> 
> Financial industry applications, for example, generally reflect this model
> (for good business reasons).  For example, with credit cards, the merchant
> goes to its acquirer for a card authorization -- not directly to the
> issuer.  The credit card equivalent of a CDP would be for the issuer to
> include its contact details (for card authorization purposes) on the card
> -- this is not the practice. 
> 
> For this reason (among others) we saw it important to move away from the
> model in which the revocation mechanism is rigidly tied to an embedded
> revocation pointer in the certificate itself.  I feel that any work to
> further develop the OCDP ideas should definitely preserve this aspect of
> the OCDP model.
> 
You claim above that we have not recognized one of the most important
underlying concepts of OCDP.  On the contrary, I suggest that you seem not
to have recognized *the* most important underlying concept of CDP:  it is
OPTIONAL (and when it is used, it is NON-CRITICAL).  Thus, there is no
standard anywhere in which "the revocation mechanism is rigidly tied to an
embedded revocation pointer in the certificate itself".  CAs can put
distribution points in certificates, or not.  If they happen to do so,
relying parties can go to the location pointed to for revocation
information, or can go somewhere else of their own choosing (note that since
the extension is non-critical, a relying party may not have software that
understands the extension while still being perfectly conformant with X.509
and PKIX).

I would therefore argue that our proposal is the most general, readily
incorporating the credit card model you suggest above, as well as other
models more suited to other environments.

--------------------------------------------
Carlisle Adams
Entrust Technologies
[email-masked]
--------------------------------------------

Date: Mon, 15 Jun 1998 11:13:44 +0200
To: [email-masked], Bob Jueneman <[email-masked]>
From: Nada Kapidzic Cicovic <[email-masked]>
Subject: Re: proof-of-possession for DH keys
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

...

8<--------------------------------

>
>[Tony writes]
>
>Is the "key" issue here (sorry about that) that by requiring POP for
>encypherment/agreement key certification, one gets authentication "for
>free" when message encryption is employed?  Otherwise, a protocol would
>require that the encrypted data be, in addition, signed?
>
>[Denis writes]
>
>Yes, Tony, this is the key point.  :-) 
>
>More precisely, the key usage bits shall/should indicate what kind of
>SERVICE can be handled with the key, instead of the kind of MECHANISM
>that may be supported with the key. We already tackled the issue when
>taken about non repudiation (which is a service and not a mechanism). We
>have another case here.
>
>Now let me try to answer the question from Nada, and let us restrict the
>discusssion for the next two lines to keys only able to encrypt/decrypt.
>
>If the key is used to support a confidentiality service, then POP is NOT
>required.
>If the key is used to support an authentication service, then POP is
>required.
>
>My conclusion is that the key usage bits shall always indicate the usage
>of the key for, at least, one security SERVICE. If we still use some
>bits to indicate a mechanism (like digital signature) then at least one
>key usage bit for a service should be present. Now, I wonder if we still
>need bits for mechanisms. If we do, making a clear cut between service
>bits and mechanism bits, will certainly help to clarify the overall
>topic.
>

Denis,

Thank you for the explanation. I now understand the rationale for having
POP for authentication keys, and I also support your idea of
extending/replacing key usage bits with the actual security services
instead of mechanisms. I feel that the intended usage of keys would be much
more clear, if the key usage bits were specified in this way. 

I wonder if something could be done in that direction. Is it too late to
suggest one such change in part 1 and CMP, and I guess X.509 as well? It
seems to be worth a pain of changing all of them. Key usage should really
carry only definition of the service, since it seems to me that the
mechanism definition is implicit to the key algorithm (with RSA keys you
can both sign and encrypt, but with DSA you can only sign, etc.).
Additionally, the application developers would then be clear on what type
of service can they expect to have implicit in certification protocols, and
what they need to implement themselves.

An alternative to making a distinction between services and mechanisms in
key usage bits is to have keyUsage contain only description of key
mechanisms, and leave the services to application protocols. However, then
I do not see a reason for enforcing POP for encryption and agreement keys.

Regards,

Nada

Date: Mon, 15 Jun 1998 10:42:53 +0200
To: "Bob Jueneman" <[email-masked]>, [email-masked], [email-masked]
From: Nada Kapidzic Cicovic <[email-masked]>
Subject: Re: RE: proof-of-possession for DH keys
Cc: [email-masked]
Sender: [email-masked]

At 12:36 6/12/98 -0600, Bob Jueneman wrote:
>Tony,
>
>No, the flow is going the other way. Carlisle's well stated 
>point is that whenever you validate a certificate, for 
>whatever purpose at all, you have to ensure that the 
>person whose public key is being bound into the certificate
>actually owns the private key.
>
>I think it is clear in the case of digital signatures -- someone else 
>could claim to have signed your invention disclosure, etc.
>
>But it is even worse if I take MY public key and send it to your CA
>along with a certificate request in your name.  Now someone 
>tries to send you encrypted mail, and you can't read it but I can.

Bob,

This is a problem no matter what type of certificate you want to get
certified, and enforcing POPO on the CA is not helping you get out of it.
You can create the valid POPO with YOUR private key corresponding to the
public key from the certificate and present it to the CA in my name. 

The problem you are describing has to do with having the CA authenticate
the request and prove for the binding between the request and your claimed
identity. POP is not the mechanism for doing that.

Regards,

Nada

>
>Bob
>
>>At 10:24 AM 6/12/98 -0400, Carlisle Adams wrote:
>>>Hi Nada,
>>
>>[Nada writes]
>>
>>>> For digitalSignature keys, proof of possession does make sense. You need
>>>> to
>>>> prove that you have the corresponding private key, so that you cannot get
>>>> a
>>>> certificate issued in your name containing someone else's public key.
>>
>>[Nada continues]
>>
>>>> However, I somehow fail to see the reason for proving POPO for
>>>> keyEncipherment and keyAgreement keys. If you request the
certification of
>>>> a keyEncipherment certificate with someone else's public key, I do not
see
>>>> what would you gain by getting it issued in your name.
>>
>>
>>[Carlisle replies]
>>
>>>After the signature on a cert. has been verified mathematically; after the
>>>cert. has been checked for revocation; after the signature and revocation
>>>status have been checked for all other certs involved in the path; after
>>>validity periods, key usage bits, policy OIDs, etc., etc., etc., have been
>>>confirmed to be acceptable, I *still* have to make the fundamental
>>>assumption that the entity named in the certificate owns the corresponding
>>>private key.  Otherwise, I have no reason whatsoever to use this
certificate
>>>instead of any other certificate or any bare public key.
>>
>>Friends,
>>
>>Is the "key" issue here (sorry about that) that by requiring POP for
>>encypherment/agreement key certification, one gets authentication "for
>>free" when message encryption is employed?  Otherwise, a protocol would
>>require that the encrypted data be, in addition, signed?
>>
>>___tony___
>>
>>Tony Bartoletti                                             LL
>>SPI-NET GURU                                             LL LL
>>Computer Security Technology Center                   LL LL LL
>>Lawrence Livermore National Lab                       LL LL LL
>>PO Box 808, L - 303                                   LL LL LLLLLLLL
>>Livermore, CA 94551-9900                              LL LLLLLLLL
>>email: [email-masked]   phone: 510-422-3881             LLLLLLLL
>
>
>

Date: Mon, 15 Jun 1998 09:44:00 -0700
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: Bob Jueneman <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: proof-of-possession for DH keys
Sender: [email-masked]

[Bob Jueneman writes]

Tony,
 
No, the flow is going the other way. Carlisle's well stated
point is that whenever you validate a certificate, for
whatever purpose at all, you have to ensure that the
person whose public key is being bound into the certificate
actually owns the private key.

[Denis writes]

This is precisely what Nada is wondering about, so Carlisle's statement
cannot be taken as an axiome. The question from Nada has to be answered.

[Bob continues]
 
I think it is clear in the case of digital signatures -- someone else
could claim to have signed your invention disclosure, etc.
 
But it is even worse if I take MY public key and send it to your CA
along with a certificate request in your name.  Now someone
tries to send you encrypted mail, and you can't read it but I can.

[Denis writes]

Bob, your scenario won't work: the CA should refuse to issue the
certificate because you cannot authenticate your request to the RA/CA
under someone else name. The CA shall verify that the name for which you
request the certificate can be authenticated with your whole request
(that includes a public key).
 
[Nada writes]

For digitalSignature keys, proof of possession does make sense. 
You need to prove that you have the corresponding private key, 
so that you cannot get a certificate issued in your name containing
someone else's public key.
 
[Nada continues]
 
However, I somehow fail to see the reason for proving POPO for
keyEncipherment and keyAgreement keys. If you request the certification
of
a keyEncipherment certificate with someone else's public key, I do not
see
what would you gain by getting it issued in your name.

[Denis writes]

Yes. This is still the original question to be answered. :-)

[Carlisle replies]

After the signature on a cert. has been verified mathematically; after
the
cert. has been checked for revocation; after the signature and
revocation
status have been checked for all other certs involved in the path; after
validity periods, key usage bits, policy OIDs, etc., etc., etc., have
been
confirmed to be acceptable, I *still* have to make the fundamental
assumption that the entity named in the certificate owns the
corresponding
private key.  Otherwise, I have no reason whatsoever to use this
certificate
instead of any other certificate or any bare public key.

[Denis writes]

However, this does not answer Nada's question. :-(

[Tony writes]

Is the "key" issue here (sorry about that) that by requiring POP for
encypherment/agreement key certification, one gets authentication "for
free" when message encryption is employed?  Otherwise, a protocol would
require that the encrypted data be, in addition, signed?

[Denis writes]

Yes, Tony, this is the key point.  :-) 

More precisely, the key usage bits shall/should indicate what kind of
SERVICE can be handled with the key, instead of the kind of MECHANISM
that may be supported with the key. We already tackled the issue when
taken about non repudiation (which is a service and not a mechanism). We
have another case here.

Now let me try to answer the question from Nada, and let us restrict the
discusssion for the next two lines to keys only able to encrypt/decrypt.

If the key is used to support a confidentiality service, then POP is NOT
required.
If the key is used to support an authentication service, then POP is
required.

My conclusion is that the key usage bits shall always indicate the usage
of the key for, at least, one security SERVICE. If we still use some
bits to indicate a mechanism (like digital signature) then at least one
key usage bit for a service should be present. Now, I wonder if we still
need bits for mechanisms. If we do, making a clear cut between service
bits and mechanism bits, will certainly help to clarify the overall
topic.

Note : For the difference between a service and a mechanism see ISO
7498-2 (where digital signature is defined as a mechanism, and not as
service). See table 1. BTW, ISO 7498-2 is already 10 years old.

Thanks to Nada for daring raising the initial question. :-)

Denis

-- 
      Denis Pinkas     Bull S.A.          mailto:[email-masked]
      Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

Date: Sat, 13 Jun 1998 14:27:55 -0700
To: Robert Zuccherato <[email-masked]>, [email-masked], "'Jessica Hymowitz'" <[email-masked]>
From: Warwick Ford <[email-masked]>
Subject: RE: Certificate Revocation
Sender: [email-masked]

I read with interest Robert and Carlisle's "White Paper".  It provides some
helpful discussion of the indirection mechanism ("CRL List" mechanism)
developed in OCDP, and contains some interesting refinement ideas.  

The thought of using delta CRLs in conjubction with the CRL List mechanism
is interesting, although I suspect client implementors will not embrace
that, given the implementation complexities.  Back in the X.509 v3 design
days, Hoyt and I spent hours discussing the pros and cons of delta CRLs and
we concluded that they may well be an attractive option for large servers
(for performance reasons) but not appropriate for clients (because of state
maintenance problems).  I tend to think that same analysis will apply to
using delta CRLs with CRL Lists.

Also the proposal to use regular CRL syntax to encode a CRL List is
interesting -- we considered that when we drafted OCDP but thought this
might confuse rather than help readers in initially understanding the
special properties of a CRL List.  However, if this syntax would facilitate
implementation, that would be a good change to make.

One deficiency in Robert and Carlisle's analysis is their lack of
recognition of one of the most important underlying concepts of OCDP.  If
unsigned pointers indeed have denial of service implications, the solution
offered by Robert and Carlisle, that is to have the CA sign the pointer, is
just not the general answer.  The point is that, in many spheres of
application of certificates, the issue of revocation or status checking is
considered a relying-party-domain-control issue -- not a
certificate-issuer-domain-control issue.  In other words, the relying
party's enterprise will decide where, and under what policy conditions, its
relying parties will go to check certificate status.  This could very well
be a local server or directory -- not back at the CA.

Financial industry applications, for example, generally reflect this model
(for good business reasons).  For example, with credit cards, the merchant
goes to its acquirer for a card authorization -- not directly to the
issuer.  The credit card equivalent of a CDP would be for the issuer to
include its contact details (for card authorization purposes) on the card
-- this is not the practice. 

For this reason (among others) we saw it important to move away from the
model in which the revocation mechanism is rigidly tied to an embedded
revocation pointer in the certificate itself.  I feel that any work to
further develop the OCDP ideas should definitely preserve this aspect of
the OCDP model.

Certainly more work is needed to fully develop a complete revocation
solution based on OCDP, and Robert and Carlisle's contribution is welcomed.
 I think if we put all our heads together here, we can come up with
something that is a lot better than what was, in 1997, considered the state
of the art.

Warwick

At 02:07 PM 6/12/98 -0400, Robert Zuccherato wrote:
>For a more detailed description of our proposal, please see our white paper.

---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., Tel (781)2456996 x225; Fax (781)2456006
[email-masked];  301 Edgewater Pl, Suite 210, Wakefield, MA 01880
---------------------------------------------------------------------

Date: Fri, 12 Jun 1998 16:11:33 -0700
To: "Bob Jueneman" <[email-masked]>, [email-masked], [email-masked]
From: Tony Bartoletti <[email-masked]>
Subject: Re: RE: proof-of-possession for DH keys
Cc: [email-masked]
Sender: [email-masked]

At 12:36 PM 6/12/98 -0600, Bob Jueneman wrote:
>Tony,
>
>No, the flow is going the other way. Carlisle's well stated 
>point is that whenever you validate a certificate, for 
>whatever purpose at all, you have to ensure that the 
>person whose public key is being bound into the certificate
>actually owns the private key.
>
>I think it is clear in the case of digital signatures -- someone else 
>could claim to have signed your invention disclosure, etc.
>
>But it is even worse if I take MY public key and send it to your CA
>along with a certificate request in your name.  Now someone 
>tries to send you encrypted mail, and you can't read it but I can.

Thanks Bob.  I hadn't considered that scenario.

Question:  (Was I half-right?)  That is, given POP of encypherment/
agreement keys, my successful decryption of a message sent to me
should serve to authenticate the sender.  At least, in the case
I am used to (DSS Keys) each party uses their own secret key and
the other party's public key to generate a common shared secret
(modulo alg-parameters P,Q,G) which is used to convey a disposable
traffic key.

__tony__

Tony Bartoletti                                             LL
SPI-NET GURU                                             LL LL
Computer Security Technology Center                   LL LL LL
Lawrence Livermore National Lab                       LL LL LL
PO Box 808, L - 303                                   LL LL LLLLLLLL
Livermore, CA 94551-9900                              LL LLLLLLLL
email: [email-masked]   phone: 510-422-3881             LLLLLLLL

Date: Fri, 12 Jun 1998 12:36:43 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Cc: [email-masked]
Subject: Re: RE: proof-of-possession for DH keys
Sender: [email-masked]

Tony,

No, the flow is going the other way. Carlisle's well stated 
point is that whenever you validate a certificate, for 
whatever purpose at all, you have to ensure that the 
person whose public key is being bound into the certificate
actually owns the private key.

I think it is clear in the case of digital signatures -- someone else 
could claim to have signed your invention disclosure, etc.

But it is even worse if I take MY public key and send it to your CA
along with a certificate request in your name.  Now someone 
tries to send you encrypted mail, and you can't read it but I can.

Bob

>At 10:24 AM 6/12/98 -0400, Carlisle Adams wrote:
>>Hi Nada,
>
>[Nada writes]
>
>>> For digitalSignature keys, proof of possession does make sense. You need
>>> to
>>> prove that you have the corresponding private key, so that you cannot get
>>> a
>>> certificate issued in your name containing someone else's public key.
>
>[Nada continues]
>
>>> However, I somehow fail to see the reason for proving POPO for
>>> keyEncipherment and keyAgreement keys. If you request the certification of
>>> a keyEncipherment certificate with someone else's public key, I do not see
>>> what would you gain by getting it issued in your name.
>
>
>[Carlisle replies]
>
>>After the signature on a cert. has been verified mathematically; after the
>>cert. has been checked for revocation; after the signature and revocation
>>status have been checked for all other certs involved in the path; after
>>validity periods, key usage bits, policy OIDs, etc., etc., etc., have been
>>confirmed to be acceptable, I *still* have to make the fundamental
>>assumption that the entity named in the certificate owns the corresponding
>>private key.  Otherwise, I have no reason whatsoever to use this certificate
>>instead of any other certificate or any bare public key.
>
>Friends,
>
>Is the "key" issue here (sorry about that) that by requiring POP for
>encypherment/agreement key certification, one gets authentication "for
>free" when message encryption is employed?  Otherwise, a protocol would
>require that the encrypted data be, in addition, signed?
>
>___tony___
>
>Tony Bartoletti                                             LL
>SPI-NET GURU                                             LL LL
>Computer Security Technology Center                   LL LL LL
>Lawrence Livermore National Lab                       LL LL LL
>PO Box 808, L - 303                                   LL LL LLLLLLLL
>Livermore, CA 94551-9900                              LL LLLLLLLL
>email: [email-masked]   phone: 510-422-3881             LLLLLLLL

From: Robert Zuccherato <[email-masked]>
To: [email-masked], "'Jessica Hymowitz'" <[email-masked]>
Subject: RE: Certificate Revocation
Date: Fri, 12 Jun 1998 14:07:57 -0400
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------ =_NextPart_000_01BD962D.0820EE34
Content-Type: text/plain;
	charset="iso-8859-1"

 <<certrev>> 
Jessica;

Revocation is a topic of current interest among many different groups.  It
is for this reason that Carlisle Adams and I have recently prepared a white
paper on the topic.  The paper has been attached to this email and will be
available on our website within a few days  In this paper we discuss an
approach to revocation that provides all the advantages of using different
revocation technologies (OCSP, Open CDP, different flavours of CRLs) in one
simple proposal.  This proposal requires minimal changes to existing
standards.

We propose that one new certificate extension be defined.  This extension,
called the "Freshest Revocation Information Pointer" would be similar to the
CRL Distribution Point (CDP) extension.  It would be used, in addition to a
CDP, to point to a CRL that provides fresher information than the CDP.
Typically this would be a Delta CRL having as its base the CRL fragment
pointed to by the CDP extension.  Thus, applications that require fresher
information can obtain it, at an additional cost.

We also propose a new CRL extension, called a "Redirect Pointer".  This
pointer would allow repartitioning of Distribution Points by redirecting
certificates with particular scopes to other CRLs.  This is similar to the
Open CDP proposal, except that it is less open to denial of service attacks,
and it is based on existing standards.

For a more detailed description of our proposal, please see our white paper.

I would also like to respond to some of the comments made in the BITS
position note:

> ----------
> From: 	Jessica Hymowitz[SMTP:[email-masked]]
> Sent: 	Friday, June 12, 1998 10:26 AM
> To: 	[email-masked]
> Subject: 	Certificate Revocation
> 
> In the current generation of products which make use of public key 
> technology, and in CA products and services, support for revocation 
> processing is inconsistent or non-existent.  This creates potential 
> risk for web server IDs, secure e-mail, code signing, peer-to-peer 
> transactions, and other applications with many relying parties.  In 
> these applications, in the event of a compromise, there would be no 
> reliable way to inform the community at large.  This problem exists 
> no matter how certificate hierarchies and root structures evolve.  In 
> order to address this potential security and risk issue, there needs 
> to be agreement on core standards and profiles to promote interoperability
> 
> and incorporation of these features within commercial products.
> 
The core standards already exist and, as our white paper shows, are
sufficient for meeting the needs of most (all?) application environments.

> There are currently numerous technical alternatives which have been 
> discussed for  handling revocation. Two of the leading options for 
> revocation are certificate revocation lists (periodically issued 
> "hot lists" of revoked certificates, fetched by relying parties) and 
> online certificate status (real time inquiries made by the relying 
> party to the CA or alternative agent).  Each of these mechanisms may 
> be required by the financial services community depending on the 
> circumstances and application.  In particular CRLs are essential for 
> both offline operation and archival information while online status 
> is essential for timely status, large communities, and lightweight 
> client environments.  In combination, these two options provide a solid 
> foundation for meeting the requirements of the financial industry.
> 
I disagree that OCSP is essential for timely status, large communities and
lightweight clients.  It remains to be seen if OCSP can scale to provide
timely status to large communities.  However, our white paper describes how
to meet both requirements using existing CRL structures and the extensions I
mentioned above.  I am also unsure as to whether OCSP can support
lightweight clients.  Remember, certificate revocation status is only one
element in path validation.  Additionally, these lightweight clients won't
exist if they are going to have to process CRLs anyway (as you seem to
imply).

> The current status of products and infrastructure, however, tend to 
> support neither (nor any other alternative) of these mechanism in any 
> consistent, interoperable, deployed manner.  
> 
Again I disagree.  CRLs have been implemented and in use for some time now.

> Consequently, BITS makes 
> the following recommendations:
> 
...Stuff deleted...

I encourage you to read our white paper.  I believe that it might satisfy
your requirements.

Thank you,

	Robert Zuccherato
	Entrust Technologies

------ =_NextPart_000_01BD962D.0820EE34
Content-Type: application/octet-stream;
	name="certrev.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="certrev.pdf"
Content-Description: certrev

------ =_NextPart_000_01BD962D.0820EE34--

Date: Fri, 12 Jun 1998 11:03:33 -0700
To: Carlisle Adams <[email-masked]>, "'Nada Kapidzic Cicovic'" <[email-masked]>
From: Tony Bartoletti <[email-masked]>
Subject: RE: proof-of-possession for DH keys
Cc: [email-masked]
Sender: [email-masked]

At 10:24 AM 6/12/98 -0400, Carlisle Adams wrote:
>Hi Nada,

[Nada writes]

>> For digitalSignature keys, proof of possession does make sense. You need
>> to
>> prove that you have the corresponding private key, so that you cannot get
>> a
>> certificate issued in your name containing someone else's public key.

[Nada continues]

>> However, I somehow fail to see the reason for proving POPO for
>> keyEncipherment and keyAgreement keys. If you request the certification of
>> a keyEncipherment certificate with someone else's public key, I do not see
>> what would you gain by getting it issued in your name.

[Carlisle replies]

>After the signature on a cert. has been verified mathematically; after the
>cert. has been checked for revocation; after the signature and revocation
>status have been checked for all other certs involved in the path; after
>validity periods, key usage bits, policy OIDs, etc., etc., etc., have been
>confirmed to be acceptable, I *still* have to make the fundamental
>assumption that the entity named in the certificate owns the corresponding
>private key.  Otherwise, I have no reason whatsoever to use this certificate
>instead of any other certificate or any bare public key.

Friends,

Is the "key" issue here (sorry about that) that by requiring POP for
encypherment/agreement key certification, one gets authentication "for
free" when message encryption is employed?  Otherwise, a protocol would
require that the encrypted data be, in addition, signed?

___tony___

Tony Bartoletti                                             LL
SPI-NET GURU                                             LL LL
Computer Security Technology Center                   LL LL LL
Lawrence Livermore National Lab                       LL LL LL
PO Box 808, L - 303                                   LL LL LLLLLLLL
Livermore, CA 94551-9900                              LL LLLLLLLL
email: [email-masked]   phone: 510-422-3881             LLLLLLLL

Date: Fri, 12 Jun 1998 09:32:58 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Use of UTF8 in directory strings
Sender: [email-masked]

Passed on from Harald Alvestrand with permission:

>From: [email-masked] 
>X-Internal-ID: 357E1B5E00000666 
>X-Lotus-FromDomain: BULL 
>To: [email-masked] 
>cc: [email-masked], [email-masked] 
>Date: Thu, 11 Jun 1998 01:50:11 -0700 
>Subject: utf8 
> 
>hello all 
> 
>in the phoenix meeting we agreed to support the request from ietf to add 
>utf8 into the choice for directory string. 
> 
>the addition of this has minimal impact on the document, i.e. the one line 
>addition to the choice and supporting text in the conformance clause. 
> 
>i had mentioned that i thought that iso and jtc1 ahd implemented some 
>expedited process minor enhancements. 
> 
>it appears that all we can do is the following 
> 
>1. request a subproject (this can be approved at the sc33 meeting); this a 
>proper subproject of the project that added support for 10646 
> 
>2. request that the text be registed as a final pdam. 
> 
>3. go through one pdam vote and one dam vote (under the new procedures, 
>this is supposed to be a yes/no vote) 
> 
>of course we could consider it in the defect process (although not really a 
>defect, it is a simple alignment to use an additional encoding for the 
>10646 character set. 
> 
>comments? 
> 
> hoyt 
> 
> 
-- 
Harald Tveit Alvestrand, Maxware, Norway 
[email-masked]

From: Carlisle Adams <[email-masked]>
To: "'Nada Kapidzic Cicovic'" <[email-masked]>
Cc: [email-masked]
Subject: RE: proof-of-possession for DH keys
Date: Fri, 12 Jun 1998 10:24:12 -0400
Sender: [email-masked]

Hi Nada,

> ----------
> From: 	Nada Kapidzic Cicovic[SMTP:[email-masked]]
> Sent: 	Friday, June 12, 1998 5:12 AM
> To: 	[email-masked]
> Subject: 	proof-of-possesion for DH keys
> 
> I am not quite clear about the rationale behind mandating POPO for
> keyEncipherment and keyAgreement keys. I wonder if I may get your
> attention
> on this issue.
> 
> For digitalSignature keys, proof of possession does make sense. You need
> to
> prove that you have the corresponding private key, so that you cannot get
> a
> certificate issued in your name containing someone else's public key. If
> you would succeed in that, you could claim that it was you who has signed
> some document that was in reality signed by the actual owner of the
> private
> key (such as a request for patent). This indeed is a real threat and needs
> to be guarded against. 
> 
> However, I somehow fail to see the reason for proving POPO for
> keyEncipherment and keyAgreement keys. If you request the certification of
> a keyEncipherment certificate with someone else's public key, I do not see
> what would you gain by getting it issued in your name. People would
> encrypt
> documents for you by using the public key from the certificate, but you
> will not be able to recover the documents, since you are not in the
> possession of the corresponding private key. Similar logic stands for
> keyAgreement keys.
> 
> Am I missing some point here? Is there some denial of service attack that
> can be made in the latter case? 
> 
There was quite a long thread on this exact topic some time ago, probably
before you joined the list (back when CMP was still called PKIX-3).  The
reasoning here is very simple:  completely irrespective of whether or not
specific attacks exist (denial-of-service, or more serious security
threats), certificates in a PKI only have meaning if the private key
corresponding to the public key in the certificate also belongs to the
entity named in the certificate.

After the signature on a cert. has been verified mathematically; after the
cert. has been checked for revocation; after the signature and revocation
status have been checked for all other certs involved in the path; after
validity periods, key usage bits, policy OIDs, etc., etc., etc., have been
confirmed to be acceptable, I *still* have to make the fundamental
assumption that the entity named in the certificate owns the corresponding
private key.  Otherwise, I have no reason whatsoever to use this certificate
instead of any other certificate or any bare public key.

If I want to encrypt for you, I use the public key in your encryption
certificate because I expect that you will be able to use the corresponding
private key to decrypt.  What causes me to have this expectation?  If we've
never met or exchanged encrypted data before, then the *only* reason to have
this expectation is because I trust your issuing CA to have confirmed that
this is true prior to signing your certificate.  This is why
proof-of-possession (whether in-band or out-of-band) is mandatory for the
certification of all key pairs in CMP.  Certificates are meaningless unless
this is done.

The entire promise of public-key cryptography was that two complete
strangers who had never met or exchanged data before could exchange data
securely.  Without proof-of-possession, this promise falls apart.

--------------------------------------------
Carlisle Adams
Entrust Technologies
[email-masked]
--------------------------------------------

Date: Fri, 12 Jun 1998 10:26:29 -0400
From: "Jessica Hymowitz" <[email-masked]>
To: [email-masked]
Subject: Certificate Revocation
Sender: [email-masked]

From:  Banking Industry Technology Secretariat (BITS)

Financial institutions need to offer new products based on
the latest technology while maintaining ease of use and the
highest level of security.  The Security and Risk Assessment
Working Group of BITS has been addressing this issue.  One
area of concern is the implementation of certificate
revocation in PKI based solutions.

The enclosed "Position Note on Certificate Revocation"
provides guidance on what the BITS financial institutions
would like to see in this arena, namely: core standards and
profiles to promote interoperability, incorporation of these
features within commercial products, and a combined approach
to certificate revocation that includes certificate
revocation lists and online certificate status checking.

If you have any questions or would like more information
please contact Jessica Hymowitz at the BITS office, (202)
289-4322 x240, [email-masked].

BITS position note on Certificate Revocation

One of the essential elements of deploying PKI based solutions 
in the financial services industry is a workable approach to 
certificate revocation.  Certificates may be revoked as a 
consequence of changes in status, changes in subject information, 
real or suspected compromise of keying material, improper actions, 
etc.  Financial institutions require a mechanism for revoking 
certificates that is compatible with the capabilities being built 
into commercial software packages (browsers, servers, email, 
remote access, etc.). 

In the current generation of products which make use of public key 
technology, and in CA products and services, support for revocation 
processing is inconsistent or non-existent.  This creates potential 
risk for web server IDs, secure e-mail, code signing, peer-to-peer 
transactions, and other applications with many relying parties.  In 
these applications, in the event of a compromise, there would be no 
reliable way to inform the community at large.  This problem exists 
no matter how certificate hierarchies and root structures evolve.  In 
order to address this potential security and risk issue, there needs 
to be agreement on core standards and profiles to promote interoperability 
and incorporation of these features within commercial products.

There are currently numerous technical alternatives which have been 
discussed for  handling revocation. Two of the leading options for 
revocation are certificate revocation lists (periodically issued 
"hot lists" of revoked certificates, fetched by relying parties) and 
online certificate status (real time inquiries made by the relying 
party to the CA or alternative agent).  Each of these mechanisms may 
be required by the financial services community depending on the 
circumstances and application.  In particular CRLs are essential for 
both offline operation and archival information while online status 
is essential for timely status, large communities, and lightweight 
client environments.  In combination, these two options provide a solid 
foundation for meeting the requirements of the financial industry.

The current status of products and infrastructure, however, tend to 
support neither (nor any other alternative) of these mechanism in any 
consistent, interoperable, deployed manner.  Consequently, BITS makes 
the following recommendations:
*  CAs (products and services) should support both CRL and online status 
   revocation methods
*  Application products using PK technology (i.e., relying parties) 
   should be capable of processing both CRL and online status revocation 
   methods, depending on configuration and certificate extensions.
*  There should be a single baseline profile (PKIX-1) for v2 CRLs to 
   promote interoperability.  This may be supplemented in individual 
   environments.
*  CRLs should be available via LDAP and application products should be 
   capable of making LDAP requests.
*  There should be a single baseline standard for online certificate 
   status checks (PKIX OCSP).
*  Such a standard should have, at a minimum, the following features:
   -  Signed responses including the time of the response and the 
      identity of the responder
   -  Global, unique identification of target certificates (i.e. no 
      assumed relation between the target certificate and the responder)
   -  Clear status information indicating the data which the responder 
      can authoritatively provide.  Values (not exclusive) should 
      distinguish between Yes, No, Can't answer (policy/technical)
      *  is it revoked (if so, include revocation date and 
         CRL/CRLEntry information)
      *  has it expired
      *  known to be issued
   -  Redirect/Retry messages suggesting an alternative responder or a 
      time to try back
   -  Choice of responder
      *  CA directed (by redirect, extension in the CA certificate, 
         and/or the subject certificate)
      *  User selected
      *  Agent/aggregation
   -  Optional authentication of responder as a valid provider for the 
      information
   -  Extensibility (e.g. for access control, expanded context, payment, 
      authentication)
*  Online status queries should be independent of transport method, but must 
   support operation at least using HTTP.

Date: Fri, 12 Jun 1998 14:01:10 +0200 (MET DST)
To: [email-masked]
From: Jerome Lubrez <[email-masked]>
Subject: subscription
Sender: [email-masked]

subscription
-- 
+-----------------------------------+--------------------------------------+
| CS-TELECOM     Groupe CS          [email-masked]|  
+-----------------------------------+--------------------------------------+
| PoBox 11, Rue de Cambrai          | Site  : La Villette                  |
|       75945 PARIS Cedex 19 FRANCE | Name  : Jerome Lubrez                |
|       Phone : +33 01 44 89 45 00  | Responsable supervision ARTEMIS      |

|       Fax   : +33 01 44 89 45 45  | Phone : +33 01 44 89 48 38           |
+-----------------------------------+--------------------------------------+
--

Date: Fri, 12 Jun 1998 11:12:44 +0200
To: [email-masked]
From: Nada Kapidzic Cicovic <[email-masked]>
Subject: proof-of-possesion for DH keys
Sender: [email-masked]

I am not quite clear about the rationale behind mandating POPO for
keyEncipherment and keyAgreement keys. I wonder if I may get your attention
on this issue.

For digitalSignature keys, proof of possession does make sense. You need to
prove that you have the corresponding private key, so that you cannot get a
certificate issued in your name containing someone else's public key. If
you would succeed in that, you could claim that it was you who has signed
some document that was in reality signed by the actual owner of the private
key (such as a request for patent). This indeed is a real threat and needs
to be guarded against. 

However, I somehow fail to see the reason for proving POPO for
keyEncipherment and keyAgreement keys. If you request the certification of
a keyEncipherment certificate with someone else's public key, I do not see
what would you gain by getting it issued in your name. People would encrypt
documents for you by using the public key from the certificate, but you
will not be able to recover the documents, since you are not in the
possession of the corresponding private key. Similar logic stands for
keyAgreement keys.

Am I missing some point here? Is there some denial of service attack that
can be made in the latter case? 

Regards,

Nada

______________________________________________________________

Nada Kapidzic Cicovic, Ph.D.
Technology Advisor / Systems Architect

Computer Security Technologies CST AB 
(subsidiary of Entegrity Solutions Corporation)
direct: + 46 (0)8 477 77 37
cell:   + 46 (0)70 495 09 03
fax:    + 46 (0)8 477 77 31
e-mail:   [email-masked] or [email-masked]
address:  Finlandsgatan 60, S-164 74 Kista, Sweden

To: IETF-Announce:;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-crmf-01.txt
Date: Wed, 03 Jun 1998 10:24:44 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group 
of the IETF.

	Title		: Internet X.509 Certificate Request Message Format
	Author(s)	: D. Solo, C. Adams, D. Kemp, M. Myers
	Filename	: draft-ietf-pkix-crmf-01.txt
	Pages		: 20
	Date		: 02-Jun-98
	
This document describes the Certificate Request Message Format (CRMF).
This syntax is used to convey a request for a certificate to a
Certification Authority (CA) (possibly via a Registration Authority
(RA)) for the purposes of X.509 certificate production.  The request
will typically include a public key and associated registration
information.

The key words ''MUST'', ''REQUIRED'', ''SHOULD'', ''RECOMMENDED'',
and ''MAY'' in this document (in uppercase, as shown)
are to be interpreted as described in RFC 2119.
 
Please send comments on this document to the [email-masked]
mail list.

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-crmf-01.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-crmf-01.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ftp.ietf.org
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-crmf-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-crmf-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-crmf-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Wed, 10 Jun 1998 19:51:38 -0700 (PDT)
From: 4n6n61 <[email-masked]>
To: <[email-masked]>
Reply-To: [email-masked]
Sender: [email-masked]

Authenticated sender is <[email-masked]>
Subject:  44
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

EMAIL MARKETING WORKS!!

Bull's Eye Gold is the PREMIER email address collection tool.
This program allows you to develop TARGETED lists of email
addresses.  Doctors, florists, MLM, biz opp,...you can collect
anything...you are only limited by your imagination!  You can
even collect email addresses for specific states, cities, and
even countries!  All you need is your web browser and this program.
Our software utilizes the latest in search technology called
"spidering". By simply feeding the spider program a starting
website it will collect for hours. The spider will go from website
to targeted website providing you with thousands upon thousands of
fresh TARGETED email addresses. When you are done collecting,  the
spider removes duplicates and saves the email list in a ready to
send format. No longer is it necessary to send millions of ads to
get a handful of responses...SEND LESS...EARN MORE!!!

A terrific aspect of the Bull's Eye software is that there is
no difficult set up involved and no special technical mumbo-jumbo
to learn. All you need to know is how to search for your targeted
market in one of the many search engines and let the spider do the
rest! Not familiar with the search engines? No problem, we provide
you with a list of all the top search engines. Just surf to the
location of a search engine on your browser then search for the
market you wish to reach...it's that easy!

For instance if you were looking for email addresses of Doctors
in New York all you would do is:

1) Do a search using your favorite search engine by typing in
the words doctor(s) and New York
2) Copy the URL (one or more)...that's the stuff after the
http://...  for instance it might look like
http://www.yahoo.com/?doctor(s)/?New+York
3) Press the START button

THAT's IT!!!  The Bull's Eye spider will go to all the websites
that are linked, automatically extracting the email addresses
you want.

The spider is passive too! That means you can let it run all
day or all night while you are working on important things or
just having fun on your computer. There is no need to keep a
constant watch on it, just feed it your target market and give
it praise when it delivers thousands of email addresses at
the end of the day!

Features of the Bull's Eye Software:

* Does TARGETED searches of websites collecting the email
  addresses you want!
* Collects Email addresses by City, State, even specific
  Countries
* Runs Automatically...simply enter the Starting information,
  press The Start Button, and it does the rest
* Filters out duplicates
* Keeps track of URLs already visited
* Can run 24 hours per day, 7 days per week
* Fast and Easy List Management
* Also has built in filtering options...you can put in words
  that it "Must" have while searching,...you can even put in
  criteria that it  "Must NOT Have"...giving you added flexibility
* Also imports email addresses from any kind of files (text
  files, binary files, database files)
* List editor handles Multiple files to work on many lists
  simultaneously
* Has a Black-Book feature... avoid sending emails to people
  who do not want to receive it
* Built-in Mail program...send email directly on the internet
  with just a click of your mouse
* Personalized Emails...if the email address has the user's
  name when it is collected,..you can send Personalized emails!!!
* Sort by Location, Server, User Name, Contact Name
* Advanced Operations:
· Email address lists export in many different formats
  (HTML, Comma delimited, text file)
· Advanced editing...Transfer, Copy,  Addition, Delete, Crop,
  Move to Top/Bottom
· Operations between lists...Union, Subtraction, Comparison
* Program is Passive,...meaning you can run other programs at
  the same time

CALL FOR MORE INFORMATION   213-969-4930
CALL FOR MORE INFORMATION   213-969-4930

ORDERING INFORMATION

Customer Name
Company Name
Address
City
State                       Zip
Phone                                       Fax
Email Address

______ BULL'S EYE SOFTWARE   $259.00
Includes Software, Instructions, Technical Support

______ Shipping & Handling  (2-3 Day Fedex)  $10.00
                           (Fedex Overnite) $20.00

______  TOTAL
                 (CA Residents add applicable sales tax)

*All orders are for Win 95 and Win NT

                *****CREDIT CARDS ACCEPTED*****
                   MASTERCARD   VISA   AMEX

   PLEASE CALL 213-969-4930 to process your order
                        9am-5pm Pacific Time
                Checks or Money Orders send to:
                      WorldTouch Network Inc.
5670 Wilshire Blvd.  Suite 2170 Los Angeles, CA 90036
Please note:  Allow 5 business days for all checks to
clear before order is shipped.

Date: Wed, 10 Jun 1998 18:03:09 -0700 (PDT)
From: 3rstyhd <[email-masked]>
To: <[email-masked]>
Reply-To: [email-masked]
Sender: [email-masked]

Authenticated sender is <[email-masked]>
Subject:  3  g
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

EMAIL MARKETING WORKS!!

Bull's Eye Gold is the PREMIER email address collection tool.
This program allows you to develop TARGETED lists of email
addresses.  Doctors, florists, MLM, biz opp,...you can collect
anything...you are only limited by your imagination!  You can
even collect email addresses for specific states, cities, and
even countries!  All you need is your web browser and this program.
Our software utilizes the latest in search technology called
"spidering". By simply feeding the spider program a starting
website it will collect for hours. The spider will go from website
to targeted website providing you with thousands upon thousands of
fresh TARGETED email addresses. When you are done collecting,  the
spider removes duplicates and saves the email list in a ready to
send format. No longer is it necessary to send millions of ads to
get a handful of responses...SEND LESS...EARN MORE!!!

A terrific aspect of the Bull's Eye software is that there is
no difficult set up involved and no special technical mumbo-jumbo
to learn. All you need to know is how to search for your targeted
market in one of the many search engines and let the spider do the
rest! Not familiar with the search engines? No problem, we provide
you with a list of all the top search engines. Just surf to the
location of a search engine on your browser then search for the
market you wish to reach...it's that easy!

For instance if you were looking for email addresses of Doctors
in New York all you would do is:

1) Do a search using your favorite search engine by typing in
the words doctor(s) and New York
2) Copy the URL (one or more)...that's the stuff after the
http://...  for instance it might look like
http://www.yahoo.com/?doctor(s)/?New+York
3) Press the START button

THAT's IT!!!  The Bull's Eye spider will go to all the websites
that are linked, automatically extracting the email addresses
you want.

The spider is passive too! That means you can let it run all
day or all night while you are working on important things or
just having fun on your computer. There is no need to keep a
constant watch on it, just feed it your target market and give
it praise when it delivers thousands of email addresses at
the end of the day!

Features of the Bull's Eye Software:

* Does TARGETED searches of websites collecting the email
  addresses you want!
* Collects Email addresses by City, State, even specific
  Countries
* Runs Automatically...simply enter the Starting information,
  press The Start Button, and it does the rest
* Filters out duplicates
* Keeps track of URLs already visited
* Can run 24 hours per day, 7 days per week
* Fast and Easy List Management
* Also has built in filtering options...you can put in words
  that it "Must" have while searching,...you can even put in
  criteria that it  "Must NOT Have"...giving you added flexibility
* Also imports email addresses from any kind of files (text
  files, binary files, database files)
* List editor handles Multiple files to work on many lists
  simultaneously
* Has a Black-Book feature... avoid sending emails to people
  who do not want to receive it
* Built-in Mail program...send email directly on the internet
  with just a click of your mouse
* Personalized Emails...if the email address has the user's
  name when it is collected,..you can send Personalized emails!!!
* Sort by Location, Server, User Name, Contact Name
* Advanced Operations:
· Email address lists export in many different formats
  (HTML, Comma delimited, text file)
· Advanced editing...Transfer, Copy,  Addition, Delete, Crop,
  Move to Top/Bottom
· Operations between lists...Union, Subtraction, Comparison
* Program is Passive,...meaning you can run other programs at
  the same time

CALL FOR MORE INFORMATION   213-969-4930
CALL FOR MORE INFORMATION   213-969-4930

ORDERING INFORMATION

Customer Name
Company Name
Address
City
State                       Zip
Phone                                       Fax
Email Address

______ BULL'S EYE SOFTWARE   $259.00
Includes Software, Instructions, Technical Support

______ Shipping & Handling  (2-3 Day Fedex)  $10.00
                           (Fedex Overnite) $20.00

______  TOTAL
                 (CA Residents add applicable sales tax)

*All orders are for Win 95 and Win NT

                *****CREDIT CARDS ACCEPTED*****
                   MASTERCARD   VISA   AMEX

   PLEASE CALL 213-969-4930 to process your order
                        9am-5pm Pacific Time
                Checks or Money Orders send to:
                      WorldTouch Network Inc.
5670 Wilshire Blvd.  Suite 2170 Los Angeles, CA 90036
Please note:  Allow 5 business days for all checks to
clear before order is shipped.

Date: Wed, 10 Jun 1998 17:19:12 -0400
From: [email-masked] (Yuan John Jiang)
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: DNS and X.501 DistinguishedName
Sender: [email-masked]

>So I can generate an X.509 certificate request from
>the system's domain name or one of it's IP addresses,
>(and I should make that user selectable.)
>
>However, the subjectAltName is specific to an X.509
>certificate request and so I believe I still need
>a way to enter an X.500 distinguished name into the
>system for LDAP services, unless there is a similar
>alternate name construct for LDAP?
>
>/Eric Bomarsi

There is an I-D or RFC by the LDAP working group specifying
using domain names as DNs.

John
>
>Greg Carter wrote:
>> 
>> Hi Eric,
>> 
>> For X.509 (PKCS10 requests or PKIX requests) you should look at the
>> subjectAltName extension.  It allows the certification authority to list a
>> number of alternative names which the entity is associated with.  This list
>> can include name types such as IP Address, DNS, and rfc822 names.  Therefore
>> the network device can have it's DNS and/or IP Address stored in the
>> certificate, while having an X.500 DN that fits the organizations directory
>> structure.
>> 
>> >From X.509
>> 12.3.2.1        Subject alternative name field
>> This field contains one or more alternative names, using any of a variety of
>> name forms, for the entity that is bound by the CA to the certified public
>> key. This field is defined as follows:
>> subjectAltName EXTENSION ::= {
>>         SYNTAX  GeneralNames
>>         IDENTIFIED BY id-ce-subjectAltName }
>> 
>> GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName
>> 
>> GeneralName ::= CHOICE {
>>         otherName                       [0]     INSTANCE OF OTHER-NAME,
>>         rfc822Name                      [1]     IA5String,
>>         dNSName                 [2]     IA5String,
>>         x400Address             [3]     ORAddress,
>>         directoryName           [4]     Name,
>>         ediPartyName            [5]     EDIPartyName,
>>         uniformResourceIdentifier       [6]     IA5String,
>>         iPAddress                       [7]     OCTET STRING,
>>         registeredID                    [8]     OBJECT IDENTIFIER }
>> 
>> OTHER-NAME ::= TYPE-IDENTIFIER
>> 
>> EDIPartyName ::= SEQUENCE {
>>         nameAssigner            [0]     DirectoryString {ub-name} OPTIONAL,
>>         partyName               [1]     DirectoryString {ub-name} }
>> The values in the alternatives of the GeneralName type are names of various
>> forms as follows:
>>         -       otherName is a name of any form defined as an instance of
>> the OTHER-NAME information object class;
>>         -       rfc822Name is an Internet electronic mail address defined in
>> accordance with Internet RFC 822;
>>         -       dNSName is an Internet domain name defined in accordance
>> with Internet RFC 1035;
>>         -       x400Address is an O/R address defined in accordance with
>> ITU-T Rec. X.411 | ISO/IEC 10021-4;
>>         -       directoryName is a directory name defined in accordance with
>> ITU-T Rec. X.501 | ISO/IEC 9594-2;
>>         -       ediPartyName is a name of a form agreed between
>> communicating Electronic Data Interchange partners; the nameAssigner
>> component identifies an authority that assigns unique values of names in the
>> partyName component;
>>         -       uniformResourceIdentifier is a Uniform Resource Identifier
>> for the World-Wide Web defined in accordance with Internet RFC 1630;
>>         -       iPAddress is an Internet Protocol address defined in
>> accordance with Internet RFC 791, represented as a binary string.
>>         -       registeredID is an identifier of any registered object
>> assigned in accordance with ITU-T Rec. X.660 | ISO/IEC 9834-1.
>> For every name form used in the GeneralName type, there shall be a name
>> registration system that ensures that any name used unambiguously identifies
>> one entity to both certificate issuer and certificate users.
>> This extension may, at the option of the certificate issuer, be either
>> critical or non-critical. An implementation which supports this extension is
>> not required to be able to process all name forms. If the extension is
>> flagged critical, at least one of the name forms that is present shall be
>> recognized and processed, otherwise the certificate shall be considered
>> invalid. Apart from the preceding restriction, a certificate-using system is
>> permitted to ignore any name with an unrecognized or unsupported name form.
>> It is recommended that, provided the subject field of the certificate
>> contains a directory name that unambiguously identifies the subject, this
>> field be flagged non-critical.
>> 
>> ----
>> Greg Carter, Entrust Technologies
>> [email-masked]
>> 
>> > ----------
>> > From:         Eric Bomarsi[SMTP:[email-masked]]
>> > Sent:         Tuesday, June 09, 1998 5:39 PM
>> > To:   [email-masked]; [email-masked]; [email-masked]
>> > Subject:      DNS and X.501 DistinguishedName
>> >
>> > A network entity such as a router may require
>> > an X.501 DistinguishedName to utilize LDAP
>> > directory serices or generate PKCS certificate
>> > requests.
>> >
>> > It's possible that the network entity can
>> > use it's domain name to create an X.500
>> > Distinguished Name as specified in RFC2247.
>> > However, I'm concerned that this might be too
>> > inflexible since many organizations may
>> > implement an internal X.500 naming convention
>> > unrelated to their Internet domain naming.
>> >
>> > Has any MIB work been done to support
>> > distinguished name configuration?
>> >
>> > Thanks in advance,
>> > Eric Bomarsi
>> >
>

From: Robert Zuccherato <[email-masked]>
To: "'Ferdinando Ricchiuti'" <[email-masked]>
Cc: [email-masked]
Subject: RE: Time Stamp and "Notary" Drafts
Date: Wed, 10 Jun 1998 16:55:54 -0400
Sender: [email-masked]

Ferdinando;

A nonce is a value used no more that once for the same purpose.  Usually it
is just a random number.  

In the Time Stamp Protocol the requester includes a nonce in the request and
the TSA will copy that value into the response.  The reason for this is so
that the requester can mach the response with the request when the requester
has no local time reference available.

	Robert.

> ----------
> From: 	Ferdinando Ricchiuti[SMTP:[email-masked]]
> Sent: 	Wednesday, June 10, 1998 11:38 AM
> To: 	Robert Zuccherato
> Cc: 	[email-masked]
> Subject: 	Re: Time Stamp and "Notary" Drafts
> 
> Robert Zuccherato wrote:
> > 
> > New versions of the Time Stamp and Notary drafts are now available.
> They
> > have again been submitted as independent drafts, since the PKIX charter
> > still does not include these topics.
> > [...]
> 
> Hello,
> 
> In the Time Stamp Protocols draft, has been introduced a new 
> field in the TimeStampRequest message: "nonce".
> 
> What it mean? 
> 
> Thanks!
> -- 
> +-------------------------------------------------------------------+
> | Ferdinando Ricchiuti                     Computer Science Student |
> +--------------------------------+----------------------------------+
> | Politecnico di Torino          | phone:  +39-(0)11-5647090        |
> | Dip. Automatica e Informatica  | fax:                             |
> | corso Duca degli Abruzzi, 24   | e-mail: [email-masked] | 
> | 10129 Torino                   |                                  |
> | ITALY                          | http://www.polito.it/~fricchi/   | 
> +--------------------------------+----------------------------------+
> 

From: Peter Whittaker <[email-masked]>
To: "'Eric Bomarsi'" <[email-masked]>, Greg Carter <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: RE: DNS and X.501 DistinguishedName
Date: Wed, 10 Jun 1998 14:43:52 -0400
Sender: [email-masked]

This is a Multipart MIME message
----=_NextPart_STJ_36039280.897504323
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="--=_NextPart_STJ_35994560.897504320"

This is a Multipart MIME message
----=_NextPart_STJ_35994560.897504320
Content-Type: multipart/alternative;
	boundary="--=_NextPart_STJ_36019408.897504320"

----=_NextPart_STJ_36019408.897504320
Content-Type: text/richtext;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

=7B=5Crtf1=5Cansi=5Cansicpg1252=5Cfromtext =5Cdeff0=7B=5Cfonttbl
=7B=5Cf0=5Cfswiss Arial;=7D
=7B=5Cf1=5Cfmodern Courier New;=7D
=7B=5Cf2=5Cfnil=5Cfcharset2 Symbol;=7D
=7B=5Cf3=5Cfmodern=5Cfcharset0 Courier New;=7D=7D
=7B=5Ccolortbl=5Cred0=5Cgreen0=5Cblue0;=5Cred0=5Cgreen0=5Cblue255;=7D
=5Cuc1=5Cpard=5Cplain=5Cdeftab360 =5Cf0=5Cfs20=5Ccf0 In your original note, you=
 questioned the use of RFC 2247 naming scheme, as organizations might choose to use some=
 other naming scheme in their directory.  Greg's suggestion allows you to accomodate a=
ny organization's naming scheme, with the data of interest to the devices/applicatio=
ns in question being located elsewhere than the DN (it may be there also, but devices/ap=
plications need not depend on being there). =5Cpar
=5Cpar
A device's certificate will contain its IP address or hostname in the subjectAltName e=
xtension, and may contain its DN in the subject field.  If these certificates are writt=
en to and retrieved from the directory, they will (likely) be in the entry whose DN is the=
 subject DN in the certificate.=5Cpar
=5Cpar
You're right that if you are using a directory and expecting to be able to store/retriev=
e certificates in/from it, you will need to generate DNs for your routers.  The subject=
AltName extension allows you do so within the bounds of your existing naming scheme/pr=
eferences, while retaining in the certificate information most likely to be useful fo=
r network devices.  In general, extensions such as subjectAltName are a very useful pl=
ace to put such data.=5Cpar
=5Cpar
Note too that the subject and issuer fields in X.509 certificates can be empty.  The PKI=
X group has profiled the use of empty issuer and subject names to allow for those cases wh=
ere directories are not involved.=5Cpar
=5Cpar
pww=5Cpar
=5Cpar
Peter Whittaker=5Cpar
Entrust Technologies=5Cpar
http://www.entrust.com=5Cpar
=5Cpar
=5Cpar
=5Cpar
> -----Original Message-----=5Cpar
> From: Eric Bomarsi =5Bmailto:ebomarsi=40xedia.com=5D=5Cpar
> Sent: Wednesday, June 10, 1998 2:16 PM=5Cpar
> To: Greg Carter=5Cpar
> Cc: ietf-lsd=40listserv.umu.se; ipsec=40tis.com; ietf-pkix=40imc.org=5Cpar
> Subject: Re: DNS and X.501 DistinguishedName=5Cpar
> =5Cpar
> =5Cpar
> Thanks Greg,=5Cpar
> =5Cpar
> I see. =5Cpar
> =5Cpar
> So I can generate an X.509 certificate request from=5Cpar
> the system's domain name or one of it's IP addresses,=5Cpar
> (and I should make that user selectable.)=5Cpar
> =5Cpar
> However, the subjectAltName is specific to an X.509=5Cpar
> certificate request and so I believe I still need=5Cpar
> a way to enter an X.500 distinguished name into the=5Cpar
> system for LDAP services, unless there is a similar=5Cpar
> alternate name construct for LDAP?=5Cpar
> =5Cpar
> /Eric Bomarsi=5Cpar
> =5Cpar
> Greg Carter wrote:=5Cpar
> > =5Cpar
> > Hi Eric,=5Cpar
> > =5Cpar
> > For X.509 (PKCS10 requests or PKIX requests) you should look at the=5Cpar
> > subjectAltName extension.  It allows the certification =5Cpar
> authority to list a=5Cpar
> > number of alternative names which the entity is associated =5Cpar
> with.  This list=5Cpar
> > can include name types such as IP Address, DNS, and rfc822 =5Cpar
> names.  Therefore=5Cpar
> > the network device can have it's DNS and/or IP Address stored in the=5Cpar
> > certificate, while having an X.500 DN that fits the =5Cpar
> organizations directory=5Cpar
> > structure.=5Cpar
> > =5Cpar
> > >From X.509=5Cpar
> > 12.3.2.1        Subject alternative name field=5Cpar
> > This field contains one or more alternative names, using =5Cpar
> any of a variety of=5Cpar
> > name forms, for the entity that is bound by the CA to the =5Cpar
> certified public=5Cpar
> > key. This field is defined as follows:=5Cpar
> > subjectAltName EXTENSION ::=3D =5C=7B=5Cpar
> >         SYNTAX  GeneralNames=5Cpar
> >         IDENTIFIED BY id-ce-subjectAltName =5C=7D=5Cpar
> > =5Cpar
> > GeneralNames ::=3D SEQUENCE SIZE (1..MAX) OF GeneralName=5Cpar
> > =5Cpar
> > GeneralName ::=3D CHOICE =5C=7B=5Cpar
> >         otherName                       =5B0=5D     INSTANCE OF =5Cpar
> OTHER-NAME,=5Cpar
> >         rfc822Name                      =5B1=5D     IA5String,=5Cpar
> >         dNSName                 =5B2=5D     IA5String,=5Cpar
> >         x400Address             =5B3=5D     ORAddress,=5Cpar
> >         directoryName           =5B4=5D     Name,=5Cpar
> >         ediPartyName            =5B5=5D     EDIPartyName,=5Cpar
> >         uniformResourceIdentifier       =5B6=5D     IA5String,=5Cpar
> >         iPAddress                       =5B7=5D     OCTET STRING,=5Cpar
> >         registeredID                    =5B8=5D     OBJECT IDENTIFIER =5C=7D=
=5Cpar
> > =5Cpar
> > OTHER-NAME ::=3D TYPE-IDENTIFIER=5Cpar
> > =5Cpar
> > EDIPartyName ::=3D SEQUENCE =5C=7B=5Cpar
> >         nameAssigner            =5B0=5D     DirectoryString =5Cpar
> =5C=7Bub-name=5C=7D OPTIONAL,=5Cpar
> >         partyName               =5B1=5D     DirectoryString =5C=7Bub-name=5C=
=7D =5C=7D=5Cpar
> > The values in the alternatives of the GeneralName type are =5Cpar
> names of various=5Cpar
> > forms as follows:=5Cpar
> >         -       otherName is a name of any form defined as =5Cpar
> an instance of=5Cpar
> > the OTHER-NAME information object class;=5Cpar
> >         -       rfc822Name is an Internet electronic mail =5Cpar
> address defined in=5Cpar
> > accordance with Internet RFC 822;=5Cpar
> >         -       dNSName is an Internet domain name defined =5Cpar
> in accordance=5Cpar
> > with Internet RFC 1035;=5Cpar
> >         -       x400Address is an O/R address defined in =5Cpar
> accordance with=5Cpar
> > ITU-T Rec. X.411 =7C ISO/IEC 10021-4;=5Cpar
> >         -       directoryName is a directory name defined =5Cpar
> in accordance with=5Cpar
> > ITU-T Rec. X.501 =7C ISO/IEC 9594-2;=5Cpar
> >         -       ediPartyName is a name of a form agreed between=5Cpar
> > communicating Electronic Data Interchange partners; the nameAssigner=5Cpar
> > component identifies an authority that assigns unique =5Cpar
> values of names in the=5Cpar
> > partyName component;=5Cpar
> >         -       uniformResourceIdentifier is a Uniform =5Cpar
> Resource Identifier=5Cpar
> > for the World-Wide Web defined in accordance with Internet RFC 1630;=5Cpar
> >         -       iPAddress is an Internet Protocol address defined in=5Cpar
> > accordance with Internet RFC 791, represented as a binary string.=5Cpar
> >         -       registeredID is an identifier of any =5Cpar
> registered object=5Cpar
> > assigned in accordance with ITU-T Rec. X.660 =7C ISO/IEC 9834-1.=5Cpar
> > For every name form used in the GeneralName type, there =5Cpar
> shall be a name=5Cpar
> > registration system that ensures that any name used =5Cpar
> unambiguously identifies=5Cpar
> > one entity to both certificate issuer and certificate users.=5Cpar
> > This extension may, at the option of the certificate =5Cpar
> issuer, be either=5Cpar
> > critical or non-critical. An implementation which supports =5Cpar
> this extension is=5Cpar
> > not required to be able to process all name forms. If the =5Cpar
> extension is=5Cpar
> > flagged critical, at least one of the name forms that is =5Cpar
> present shall be=5Cpar
> > recognized and processed, otherwise the certificate shall =5Cpar
> be considered=5Cpar
> > invalid. Apart from the preceding restriction, a =5Cpar
> certificate-using system is=5Cpar
> > permitted to ignore any name with an unrecognized or =5Cpar
> unsupported name form.=5Cpar
> > It is recommended that, provided the subject field of the =5Cpar
> certificate=5Cpar
> > contains a directory name that unambiguously identifies the =5Cpar
> subject, this=5Cpar
> > field be flagged non-critical.=5Cpar
> > =5Cpar
> > ----=5Cpar
> > Greg Carter, Entrust Technologies=5Cpar
> > greg.carter=40entrust.com=5Cpar
> > =5Cpar
> > > ----------=5Cpar
> > > From:         Eric Bomarsi=5BSMTP:ebomarsi=40xedia.com=5D=5Cpar
> > > Sent:         Tuesday, June 09, 1998 5:39 PM=5Cpar
> > > To:   ietf-lsd=40listserv.umu.se; ipsec=40tis.com; spki=40c2.net=5Cpar
> > > Subject:      DNS and X.501 DistinguishedName=5Cpar
> > >=5Cpar
> > > A network entity such as a router may require=5Cpar
> > > an X.501 DistinguishedName to utilize LDAP=5Cpar
> > > directory serices or generate PKCS certificate=5Cpar
> > > requests.=5Cpar
> > >=5Cpar
> > > It's possible that the network entity can=5Cpar
> > > use it's domain name to create an X.500=5Cpar
> > > Distinguished Name as specified in RFC2247.=5Cpar
> > > However, I'm concerned that this might be too=5Cpar
> > > inflexible since many organizations may=5Cpar
> > > implement an internal X.500 naming convention=5Cpar
> > > unrelated to their Internet domain naming.=5Cpar
> > >=5Cpar
> > > Has any MIB work been done to support=5Cpar
> > > distinguished name configuration?=5Cpar
> > >=5Cpar
> > > Thanks in advance,=5Cpar
> > > Eric Bomarsi=5Cpar
> > >=5Cpar
> =5Cpar
=7D
----=_NextPart_STJ_36019408.897504320
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

In your original note, you questioned the use of RFC 2247 naming scheme, as organizatio=
ns might choose to use some other naming scheme in their directory.  Greg's suggestion=
 allows you to accomodate any organization's naming scheme, with the data of interest t=
o the devices/applications in question being located elsewhere than the DN (it may be t=
here also, but devices/applications need not depend on being there).=20

A device's certificate will contain its IP address or hostname in the subjectAltName e=
xtension, and may contain its DN in the subject field.  If these certificates are writt=
en to and retrieved from the directory, they will (likely) be in the entry whose DN is the=
 subject DN in the certificate.

You're right that if you are using a directory and expecting to be able to store/retriev=
e certificates in/from it, you will need to generate DNs for your routers.  The subject=
AltName extension allows you do so within the bounds of your existing naming scheme/pr=
eferences, while retaining in the certificate information most likely to be useful fo=
r network devices.  In general, extensions such as subjectAltName are a very useful pl=
ace to put such data.

Note too that the subject and issuer fields in X.509 certificates can be empty.  The PKI=
X group has profiled the use of empty issuer and subject names to allow for those cases wh=
ere directories are not involved.

pww

Peter Whittaker
Entrust Technologies
http://www.entrust.com

> -----Original Message-----
> From: Eric Bomarsi =5Bmailto:ebomarsi=40xedia.com=5D
> Sent: Wednesday, June 10, 1998 2:16 PM
> To: Greg Carter
> Cc: ietf-lsd=40listserv.umu.se; ipsec=40tis.com; ietf-pkix=40imc.org
> Subject: Re: DNS and X.501 DistinguishedName
>=20
>=20
> Thanks Greg,
>=20
> I see.=20
>=20
> So I can generate an X.509 certificate request from
> the system's domain name or one of it's IP addresses,
> (and I should make that user selectable.)
>=20
> However, the subjectAltName is specific to an X.509
> certificate request and so I believe I still need
> a way to enter an X.500 distinguished name into the
> system for LDAP services, unless there is a similar
> alternate name construct for LDAP?
>=20
> /Eric Bomarsi
>=20
> Greg Carter wrote:
> >=20
> > Hi Eric,
> >=20
> > For X.509 (PKCS10 requests or PKIX requests) you should look at the
> > subjectAltName extension.  It allows the certification=20
> authority to list a
> > number of alternative names which the entity is associated=20
> with.  This list
> > can include name types such as IP Address, DNS, and rfc822=20
> names.  Therefore
> > the network device can have it's DNS and/or IP Address stored in the
> > certificate, while having an X.500 DN that fits the=20
> organizations directory
> > structure.
> >=20
> > >From X.509
> > 12.3.2.1        Subject alternative name field
> > This field contains one or more alternative names, using=20
> any of a variety of
> > name forms, for the entity that is bound by the CA to the=20
> certified public
> > key. This field is defined as follows:
> > subjectAltName EXTENSION ::=3D =7B
> >         SYNTAX  GeneralNames
> >         IDENTIFIED BY id-ce-subjectAltName =7D
> >=20
> > GeneralNames ::=3D SEQUENCE SIZE (1..MAX) OF GeneralName
> >=20
> > GeneralName ::=3D CHOICE =7B
> >         otherName                       =5B0=5D     INSTANCE OF=20
> OTHER-NAME,
> >         rfc822Name                      =5B1=5D     IA5String,
> >         dNSName                 =5B2=5D     IA5String,
> >         x400Address             =5B3=5D     ORAddress,
> >         directoryName           =5B4=5D     Name,
> >         ediPartyName            =5B5=5D     EDIPartyName,
> >         uniformResourceIdentifier       =5B6=5D     IA5String,
> >         iPAddress                       =5B7=5D     OCTET STRING,
> >         registeredID                    =5B8=5D     OBJECT IDENTIFIER =7D
> >=20
> > OTHER-NAME ::=3D TYPE-IDENTIFIER
> >=20
> > EDIPartyName ::=3D SEQUENCE =7B
> >         nameAssigner            =5B0=5D     DirectoryString=20
> =7Bub-name=7D OPTIONAL,
> >         partyName               =5B1=5D     DirectoryString =7Bub-name=7D =7D=

> > The values in the alternatives of the GeneralName type are=20
> names of various
> > forms as follows:
> >         -       otherName is a name of any form defined as=20
> an instance of
> > the OTHER-NAME information object class;
> >         -       rfc822Name is an Internet electronic mail=20
> address defined in
> > accordance with Internet RFC 822;
> >         -       dNSName is an Internet domain name defined=20
> in accordance
> > with Internet RFC 1035;
> >         -       x400Address is an O/R address defined in=20
> accordance with
> > ITU-T Rec. X.411 =7C ISO/IEC 10021-4;
> >         -       directoryName is a directory name defined=20
> in accordance with
> > ITU-T Rec. X.501 =7C ISO/IEC 9594-2;
> >         -       ediPartyName is a name of a form agreed between
> > communicating Electronic Data Interchange partners; the nameAssigner
> > component identifies an authority that assigns unique=20
> values of names in the
> > partyName component;
> >         -       uniformResourceIdentifier is a Uniform=20
> Resource Identifier
> > for the World-Wide Web defined in accordance with Internet RFC 1630;
> >         -       iPAddress is an Internet Protocol address defined in
> > accordance with Internet RFC 791, represented as a binary string.
> >         -       registeredID is an identifier of any=20
> registered object
> > assigned in accordance with ITU-T Rec. X.660 =7C ISO/IEC 9834-1.
> > For every name form used in the GeneralName type, there=20
> shall be a name
> > registration system that ensures that any name used=20
> unambiguously identifies
> > one entity to both certificate issuer and certificate users.
> > This extension may, at the option of the certificate=20
> issuer, be either
> > critical or non-critical. An implementation which supports=20
> this extension is
> > not required to be able to process all name forms. If the=20
> extension is
> > flagged critical, at least one of the name forms that is=20
> present shall be
> > recognized and processed, otherwise the certificate shall=20
> be considered
> > invalid. Apart from the preceding restriction, a=20
> certificate-using system is
> > permitted to ignore any name with an unrecognized or=20
> unsupported name form.
> > It is recommended that, provided the subject field of the=20
> certificate
> > contains a directory name that unambiguously identifies the=20
> subject, this
> > field be flagged non-critical.
> >=20
> > ----
> > Greg Carter, Entrust Technologies
> > greg.carter=40entrust.com
> >=20
> > > ----------
> > > From:         Eric Bomarsi=5BSMTP:ebomarsi=40xedia.com=5D
> > > Sent:         Tuesday, June 09, 1998 5:39 PM
> > > To:   ietf-lsd=40listserv.umu.se; ipsec=40tis.com; spki=40c2.net
> > > Subject:      DNS and X.501 DistinguishedName
> > >
> > > A network entity such as a router may require
> > > an X.501 DistinguishedName to utilize LDAP
> > > directory serices or generate PKCS certificate
> > > requests.
> > >
> > > It's possible that the network entity can
> > > use it's domain name to create an X.500
> > > Distinguished Name as specified in RFC2247.
> > > However, I'm concerned that this might be too
> > > inflexible since many organizations may
> > > implement an internal X.500 naming convention
> > > unrelated to their Internet domain naming.
> > >
> > > Has any MIB work been done to support
> > > distinguished name configuration?
> > >
> > > Thanks in advance,
> > > Eric Bomarsi
> > >
>=20

----=_NextPart_STJ_36019408.897504320--

----=_NextPart_STJ_35994560.897504320
Content-Type: application/octet-stream;
	name="%-1%Peter Whittaker (E-mail).vcf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="%-1%Peter Whittaker (E-mail).vcf"

----=_NextPart_STJ_35994560.897504320--

Protected with Entrust Express and S/MIME

----=_NextPart_STJ_36039280.897504323
Content-Type: application/x-pkcs7-signature;
	protocol="application/x-pkcs7-signature";
	micalg="sha1";
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

----=_NextPart_STJ_36039280.897504323--

Protected with Entrust Express and S/MIME

Date: Wed, 10 Jun 1998 14:15:45 -0400
From: Eric Bomarsi <[email-masked]>
Organization: xedia.com
To: Greg Carter <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: DNS and X.501 DistinguishedName
Sender: [email-masked]

Thanks Greg,

I see. 

So I can generate an X.509 certificate request from
the system's domain name or one of it's IP addresses,
(and I should make that user selectable.)

However, the subjectAltName is specific to an X.509
certificate request and so I believe I still need
a way to enter an X.500 distinguished name into the
system for LDAP services, unless there is a similar
alternate name construct for LDAP?

/Eric Bomarsi

Greg Carter wrote:
> 
> Hi Eric,
> 
> For X.509 (PKCS10 requests or PKIX requests) you should look at the
> subjectAltName extension.  It allows the certification authority to list a
> number of alternative names which the entity is associated with.  This list
> can include name types such as IP Address, DNS, and rfc822 names.  Therefore
> the network device can have it's DNS and/or IP Address stored in the
> certificate, while having an X.500 DN that fits the organizations directory
> structure.
> 
> >From X.509
> 12.3.2.1        Subject alternative name field
> This field contains one or more alternative names, using any of a variety of
> name forms, for the entity that is bound by the CA to the certified public
> key. This field is defined as follows:
> subjectAltName EXTENSION ::= {
>         SYNTAX  GeneralNames
>         IDENTIFIED BY id-ce-subjectAltName }
> 
> GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName
> 
> GeneralName ::= CHOICE {
>         otherName                       [0]     INSTANCE OF OTHER-NAME,
>         rfc822Name                      [1]     IA5String,
>         dNSName                 [2]     IA5String,
>         x400Address             [3]     ORAddress,
>         directoryName           [4]     Name,
>         ediPartyName            [5]     EDIPartyName,
>         uniformResourceIdentifier       [6]     IA5String,
>         iPAddress                       [7]     OCTET STRING,
>         registeredID                    [8]     OBJECT IDENTIFIER }
> 
> OTHER-NAME ::= TYPE-IDENTIFIER
> 
> EDIPartyName ::= SEQUENCE {
>         nameAssigner            [0]     DirectoryString {ub-name} OPTIONAL,
>         partyName               [1]     DirectoryString {ub-name} }
> The values in the alternatives of the GeneralName type are names of various
> forms as follows:
>         -       otherName is a name of any form defined as an instance of
> the OTHER-NAME information object class;
>         -       rfc822Name is an Internet electronic mail address defined in
> accordance with Internet RFC 822;
>         -       dNSName is an Internet domain name defined in accordance
> with Internet RFC 1035;
>         -       x400Address is an O/R address defined in accordance with
> ITU-T Rec. X.411 | ISO/IEC 10021-4;
>         -       directoryName is a directory name defined in accordance with
> ITU-T Rec. X.501 | ISO/IEC 9594-2;
>         -       ediPartyName is a name of a form agreed between
> communicating Electronic Data Interchange partners; the nameAssigner
> component identifies an authority that assigns unique values of names in the
> partyName component;
>         -       uniformResourceIdentifier is a Uniform Resource Identifier
> for the World-Wide Web defined in accordance with Internet RFC 1630;
>         -       iPAddress is an Internet Protocol address defined in
> accordance with Internet RFC 791, represented as a binary string.
>         -       registeredID is an identifier of any registered object
> assigned in accordance with ITU-T Rec. X.660 | ISO/IEC 9834-1.
> For every name form used in the GeneralName type, there shall be a name
> registration system that ensures that any name used unambiguously identifies
> one entity to both certificate issuer and certificate users.
> This extension may, at the option of the certificate issuer, be either
> critical or non-critical. An implementation which supports this extension is
> not required to be able to process all name forms. If the extension is
> flagged critical, at least one of the name forms that is present shall be
> recognized and processed, otherwise the certificate shall be considered
> invalid. Apart from the preceding restriction, a certificate-using system is
> permitted to ignore any name with an unrecognized or unsupported name form.
> It is recommended that, provided the subject field of the certificate
> contains a directory name that unambiguously identifies the subject, this
> field be flagged non-critical.
> 
> ----
> Greg Carter, Entrust Technologies
> [email-masked]
> 
> > ----------
> > From:         Eric Bomarsi[SMTP:[email-masked]]
> > Sent:         Tuesday, June 09, 1998 5:39 PM
> > To:   [email-masked]; [email-masked]; [email-masked]
> > Subject:      DNS and X.501 DistinguishedName
> >
> > A network entity such as a router may require
> > an X.501 DistinguishedName to utilize LDAP
> > directory serices or generate PKCS certificate
> > requests.
> >
> > It's possible that the network entity can
> > use it's domain name to create an X.500
> > Distinguished Name as specified in RFC2247.
> > However, I'm concerned that this might be too
> > inflexible since many organizations may
> > implement an internal X.500 naming convention
> > unrelated to their Internet domain naming.
> >
> > Has any MIB work been done to support
> > distinguished name configuration?
> >
> > Thanks in advance,
> > Eric Bomarsi
> >

Date: Wed, 10 Jun 1998 17:38:20 +0200
From: Ferdinando Ricchiuti <[email-masked]>
To: Robert Zuccherato <[email-masked]>
Cc: [email-masked]
Subject: Re: Time Stamp and "Notary" Drafts
Sender: [email-masked]

Robert Zuccherato wrote:
> 
> New versions of the Time Stamp and Notary drafts are now available.  They
> have again been submitted as independent drafts, since the PKIX charter
> still does not include these topics.
> [...]

Hello,

In the Time Stamp Protocols draft, has been introduced a new 
field in the TimeStampRequest message: "nonce".

What it mean? 

Thanks!
-- 
+-------------------------------------------------------------------+
| Ferdinando Ricchiuti                     Computer Science Student |
+--------------------------------+----------------------------------+
| Politecnico di Torino          | phone:  +39-(0)11-5647090        |
| Dip. Automatica e Informatica  | fax:                             |
| corso Duca degli Abruzzi, 24   | e-mail: [email-masked] | 
| 10129 Torino                   |                                  |
| ITALY                          | http://www.polito.it/~fricchi/   | 
+--------------------------------+----------------------------------+

Date: Wed, 10 Jun 1998 10:54:40 +0200
From: Antonio Lioy <[email-masked]>
Organization: Politecnico di Torino
To: [email-masked]
Subject: Re: Time Stamp and "Notary" Drafts
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms578F748BB1C75D0272ABBA1A
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Robert Zuccherato wrote:
> 
> New versions of the Time Stamp and Notary drafts are now available.  They
> have again been submitted as independent drafts, since the PKIX charter
> still does not include these topics.

We are setting up a time-stamp and notary server. We already
developed them according to the old PKIX drafts and will now modify
the code to accomodate the new drafts.

Is there anybody else that has (or is going to) set up similar
servers? we wish to perform interoperability checks.

Antonio Lioy
Politecnico di Torino
Computer & Network Security Group (http://security.polito.it)
--------------ms578F748BB1C75D0272ABBA1A
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms578F748BB1C75D0272ABBA1A--

From: "Fillingham,  David W." <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "'Bob Jueneman'" <[email-masked]>
Subject: RE: Extensibility in definitions
Date: Tue, 9 Jun 1998 13:24:29 -0400
Sender: [email-masked]

The "Security Policy Information File" (SPIF), is documented in SDN.801,
an older version of which can be found on:

http://www.armadillo.huntsville.al.us/Fortezza_docs/missi2.html#specs

The newest version of SDN.801 replaced the older "PRBAC Information
File" term with the newer "Security Policy Information File" name and
syntax.

The SPIF is a signed file that conveys the semantics of an access
control policy (e.g., the following classifications exist, they are
represented with these bits and integers, the following security
categories exist, they are represented with these other bits and
integers, these categories are "permissive," these other ones are
"restrictive," and you can't assert this category unless you also assert
those other ones, and so on.)

Dave Fillingham

>----------
>From: 	Bob Jueneman[SMTP:[email-masked]]
>Sent: 	Monday, June 08, 1998 1:14 PM
>To: 	[email-masked]; [email-masked]
>Subject: 	Re: Extensibility in definitions
>
>the Secuity Parameter Information File concept sounds interesting.  Is it
>going to be available soon?
>
>Bob
>
>>>> David P. Kemp <[email-masked]> 06/08 10:09 AM >>>
>From: "Balluffi, Frank" <[email-masked]>
>
>> Modifications to named BIT STRINGs and ENUMERATED types require
>> recompilation of the ASN.1.
>
>
>and From: "Bob Jueneman" <[email-masked]>
>> 
>> Clearly we don't want to recompile every piece of software
>> in the world just because someone makes a minor change to
>> clarify the semantic definition of some attribute, or defines a new
>> but compatible bit within a previously reserved field.
>> 
>> The extendedKeyUsage attribute gets around this problem by
>> defining an attribute that contains other attributes identified by
>> their own OID, but the result is cumbersome and space inefficient.
>> 
>> X.500 provides a means of distributing the syntax of new attributes
>> by registering them in the directory. Unfortunately, until we have lots
>> of software that support dynamic assignment of ASN.1 attributes, 
>> that isn't much help.  And what we _really_ need is some way of 
>> automatically updating the _semantics_ of these attributes, which
>> all too often are spell out in too-terse comments to the ASN.1, if 
>> at all.
>
>
>The obvious alternative to static (compile time) assignment is dynamic
>assignment using an interpreter or on-the-fly compiler.  If named BIT
>STRINGs and ENUMERATED types are required by X.680 to be implemented
>only in a static compilation environment (I don't believe any such
>restriction exists), then a reasonable alternative is to use normal BIT
>STRINGs and INTEGERs whose meaning is bound at runtime.  This avoids
>alternative of expanding each BIT out into it's own OID which, as Bob
>says, is cumbersome and space inefficient.  OIDs should be used for
>their intended purpose - object definition collision avoidance -
>not as a replacement for the data elements comprising an object.
>
>And as it turns out, Sandi and others are working on just such a
>scheme - the "Security Parameter Information File" (SPIF) which
>is interpreted at runtime (and signed by an Authority to prevent
>tampering).
>
>The same configuration management issues exist whether you use static
>or dynamic assignment - you don't want anything defined in the future
>to conflict with or modify the meaning of currently-defined bits.
>The SPIF uses a single OID to specify a security policy under which
>the bits are interpreted - compatible additions can be made under the
>same policy, but incompatible changes require a new policy OID.
>
>

From: Robert Zuccherato <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Time Stamp and "Notary" Drafts
Date: Tue, 9 Jun 1998 09:12:55 -0400 
Sender: [email-masked]

New versions of the Time Stamp and Notary drafts are now available.  They
have again been submitted as independent drafts, since the PKIX charter
still does not include these topics.

The Time Stamp Protocols draft is available at:
ftp://ftp.ietf.org/internet-drafts/draft-adams-time-stamp-02.txt
Some of the changes include:
-removal of requester name and TSA name from time stamp requests
-inclusion of tsaFreeData field in response to hold supplementary (e.g.
billing) information
-inclusion of section listing possibly relevant patents

The "Notary" draft and protocol has been renamed.  It became apparent at the
PKIX meetings that calling this protocol a "Notary" protocol caused some
confusion about the purpose of the "Notary" and the functions that it was
supposed to perform.  We have renamed it the Data Certification Server.  We
feel that this name is a little bit more descriptive of what this server
does.  It certifies data for later use in support of non-repudiation.
The Data Certification Server draft is available at:
ftp://ftp.ietf.org/internet-drafts/draft-adams-dcs-00.txt
Some of the changes include:
-extension capability included in both request and responses
-allows validation of multiple target certificates each with associated
trust chains
-improved support for certificate path validation
-inclusion of section listing possibly relevant patents

As always, comments are welcome.

	Robert Zuccherato.

Date: Mon, 08 Jun 1998 13:39:00 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: Certificate transport encoding question
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Peter:

PKCS#7 version 1.5 does not constrain the ordering of the certificates, so
the recipient must be prepared for the worst possible haphazard ordering.
CMS has a backward comparability goal, so we get this feature too.

Russ

At 05:10 AM 6/6/98 +0000, Peter Gutmann wrote:
>I've got two questions about certificate encoding in transport formats, I've 
>sent them to both lists since they're a bit nonspecific.
> 
>The first one concerns the order of certs in a cert chain.  Looking at the
CMS 
>spec, it says that the SET OF Certificate should contain chains from the
root 
>down to each required subject, but doesn't give any explicit ordering.  An 
>ASN.1 SET is inherently unordered, but is there any recommended, consistent 
>way to encode a cert chain, or do you just add them in whatever order you
feel 
>like?  So far I've seen them ordered from subject to root, from root to 
>subject, and pseudorandomly (using the DER SET encoding rules)... all of
these 
>are equally valid, it just seems messy to have any number of possible 
>orderings present.
> 
>The second one concerns something which isn't explicitly addressed by any 
>standard but which it might be worth covering somewhere.  When a certificate 
>or cert-related object (cert request, CRL) is base64-encoded, there are
again 
>a large number of different interpretations on what delimiters to use around 
>the base64 data.  I've seen BEGIN CERTIFICATE, BEGIN CERTIFICATE REQUEST, 
>BEGIN NEW CERTIFICATE REQUEST, BEGIN PGP MESS...no hang on, that's something 
>else :-).  Alongside these are various creative mutations (extra blank
lines, 
>name:value pairs a la PGP, and other oddities).  It's probably a good idea
to 
>specify a set format for these as well and attach them to some existing 
>standard.  If there's a need for them I'll put together a paragraph or two 
>defining the exact format.
> 
>Peter.
> 

Date: Mon, 08 Jun 1998 11:14:57 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Extensibility in definitions
Sender: [email-masked]

the Secuity Parameter Information File concept sounds interesting.  Is it going to be available soon?

Bob

>>> David P. Kemp <[email-masked]> 06/08 10:09 AM >>>
From: "Balluffi, Frank" <[email-masked]>

> Modifications to named BIT STRINGs and ENUMERATED types require
> recompilation of the ASN.1.

and From: "Bob Jueneman" <[email-masked]>
> 
> Clearly we don't want to recompile every piece of software
> in the world just because someone makes a minor change to
> clarify the semantic definition of some attribute, or defines a new
> but compatible bit within a previously reserved field.
> 
> The extendedKeyUsage attribute gets around this problem by
> defining an attribute that contains other attributes identified by
> their own OID, but the result is cumbersome and space inefficient.
> 
> X.500 provides a means of distributing the syntax of new attributes
> by registering them in the directory. Unfortunately, until we have lots
> of software that support dynamic assignment of ASN.1 attributes, 
> that isn't much help.  And what we _really_ need is some way of 
> automatically updating the _semantics_ of these attributes, which
> all too often are spell out in too-terse comments to the ASN.1, if 
> at all.

The obvious alternative to static (compile time) assignment is dynamic
assignment using an interpreter or on-the-fly compiler.  If named BIT
STRINGs and ENUMERATED types are required by X.680 to be implemented
only in a static compilation environment (I don't believe any such
restriction exists), then a reasonable alternative is to use normal BIT
STRINGs and INTEGERs whose meaning is bound at runtime.  This avoids
alternative of expanding each BIT out into it's own OID which, as Bob
says, is cumbersome and space inefficient.  OIDs should be used for
their intended purpose - object definition collision avoidance -
not as a replacement for the data elements comprising an object.

And as it turns out, Sandi and others are working on just such a
scheme - the "Security Parameter Information File" (SPIF) which
is interpreted at runtime (and signed by an Authority to prevent
tampering).

The same configuration management issues exist whether you use static
or dynamic assignment - you don't want anything defined in the future
to conflict with or modify the meaning of currently-defined bits.
The SPIF uses a single OID to specify a security policy under which
the bits are interpreted - compatible additions can be made under the
same policy, but incompatible changes require a new policy OID.

Date: Mon, 8 Jun 1998 12:09:21 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Extensibility in definitions
Sender: [email-masked]

From: "Balluffi, Frank" <[email-masked]>

> Modifications to named BIT STRINGs and ENUMERATED types require
> recompilation of the ASN.1.

and From: "Bob Jueneman" <[email-masked]>
> 
> Clearly we don't want to recompile every piece of software
> in the world just because someone makes a minor change to
> clarify the semantic definition of some attribute, or defines a new
> but compatible bit within a previously reserved field.
> 
> The extendedKeyUsage attribute gets around this problem by
> defining an attribute that contains other attributes identified by
> their own OID, but the result is cumbersome and space inefficient.
> 
> X.500 provides a means of distributing the syntax of new attributes
> by registering them in the directory. Unfortunately, until we have lots
> of software that support dynamic assignment of ASN.1 attributes, 
> that isn't much help.  And what we _really_ need is some way of 
> automatically updating the _semantics_ of these attributes, which
> all too often are spell out in too-terse comments to the ASN.1, if 
> at all.

The obvious alternative to static (compile time) assignment is dynamic
assignment using an interpreter or on-the-fly compiler.  If named BIT
STRINGs and ENUMERATED types are required by X.680 to be implemented
only in a static compilation environment (I don't believe any such
restriction exists), then a reasonable alternative is to use normal BIT
STRINGs and INTEGERs whose meaning is bound at runtime.  This avoids
alternative of expanding each BIT out into it's own OID which, as Bob
says, is cumbersome and space inefficient.  OIDs should be used for
their intended purpose - object definition collision avoidance -
not as a replacement for the data elements comprising an object.

And as it turns out, Sandi and others are working on just such a
scheme - the "Security Parameter Information File" (SPIF) which
is interpreted at runtime (and signed by an Authority to prevent
tampering).

The same configuration management issues exist whether you use static
or dynamic assignment - you don't want anything defined in the future
to conflict with or modify the meaning of currently-defined bits.
The SPIF uses a single OID to specify a security policy under which
the bits are interpreted - compatible additions can be made under the
same policy, but incompatible changes require a new policy OID.

Date: Mon, 08 Jun 1998 11:58:07 -0400
From: Eric Bomarsi <[email-masked]>
Organization: xedia.com
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: DNS and X.501 DistinguishedName
Sender: [email-masked]

A network entity such as a router may require
an X.501 DistinguishedName to utilize LDAP
directory serices or generate PKCS certificate 
requests. 

It's possible that the network entity can
use it's domain name to create an X.500
Distinguished Name as specified in RFC2247.
However, I'm concerned that this might be too 
inflexible since many organizations may
implement an internal X.500 naming convention
unrelated to their Internet domain naming.

Has any MIB work been done to support 
distinguished name configuration?

Thanks in advance,
Eric Bomarsi

Date: Mon, 08 Jun 1998 08:27:50 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Extensibility in definitions
Sender: [email-masked]

>I am under the belief that if I construct a bit map and allocate
>semantics to the bits, I cannot reallocate the meaning of the bits
>unless I create/register a new object.  However, if I create an
>enumerated list and at some future point (new countries, new anything)
>wish to extend that list, I can do so without registering a new object.
>
>Is this correct?
>
>Sandi
>
Sandi, that certainly sounds reasonable to me.

Likewise, if I define a bit string containing reserved or "spare" 
bits, I believe that I can later assign semantic meaning to 
those bits without changing the OID of the attribute.  However, 
I recognize that this is potentially a slippery slope -- I wouldn't 
want to suddenly have someone define a "Simon says" bit 
that either negates previous meanings, or assigns entirely 
new meanings to old bits, or otherwise potentially mislead 
or harms a relying party.

Seems to me that there is no really clear answer here -- we 
are between a rock and a hard place. We want to have
both interoperability and extensibility at the same time, and
that gives rise to this dynamic tension.

Clearly we don't want to recompile every piece of software
in the world just because someone makes a minor change to
clarify the semantic definition of some attribute, or defines a new
but compatible bit within a previously reserved field.

The extendedKeyUsage attribute gets around this problem by
defining an attribute that contains other attributes identified by
their own OID, but the result is cumbersome and space inefficient.

X.500 provides a means of distributing the syntax of new attributes
by registering them in the directory. Unfortunately, until we have lots
of software that support dynamic assignment of ASN.1 attributes, 
that isn't much help.  And what we _really_ need is some way of 
automatically updating the _semantics_ of these attributes, which
all too often are spell out in too-terse comments to the ASN.1, if 
at all.

Anyone else have any wisdom to contribute?  I'm open for 
suggestions.

Bob

Robert R. Jueneman
Security Architect
Novell, Inc.
Network Products Group
122 East 1700 South
Provo, UT 84604
801/861-7387
[email-masked]

"If you are trying to get to the moon, climbing a tree, 
although a step in the right direction, will not prove 
to be very helpful."

"The most dangerous strategy is to cross a chasm in two jumps."

From: "Balluffi, Frank" <[email-masked]>
To: "'Miklos, Sue A.'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "'Bob Jueneman'" <[email-masked]>
Subject: RE: Extensibility in definitions
Date: Mon, 8 Jun 1998 10:06:50 -0400 
Sender: [email-masked]

Sue Miklos asked:

I am under the belief that if I construct a bit map and allocate
semantics to the bits, I cannot reallocate the meaning of the bits
unless I create/register a new object.  However, if I create an
enumerated list and at some future point (new countries, new anything)
wish to extend that list, I can do so without registering a new object.

Modifications to named BIT STRINGs and ENUMERATED types require
recompilation of the ASN.1. Perhaps a better mechanism is the
TYPE-IDENTIFIER: a SEQUENCE containing an object identifier and an
encoded type. Using TYPE-IDENTIFIERs still requires registration of new
objects but does not require recompilation of the ASN.1. Depending on
how you construct your software, you may not even need to recompile your
application software.

Frank Balluffi
CertCo LLC

From: "Miklos, Sue A." <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "'Bob Jueneman'" <[email-masked]>
Subject: Extensibility in definitions
Date: Mon, 8 Jun 1998 08:44:07 -0400
Sender: [email-masked]

I am under the belief that if I construct a bit map and allocate
semantics to the bits, I cannot reallocate the meaning of the bits
unless I create/register a new object.  However, if I create an
enumerated list and at some future point (new countries, new anything)
wish to extend that list, I can do so without registering a new object.

Is this correct?

Sandi

>----------
>From: 	Bob Jueneman[SMTP:[email-masked]]
>Sent: 	Saturday, June 06, 1998 7:21 PM
>To: 	[email-masked]; [email-masked];
>[email-masked]; [email-masked]
>Subject: 	Re: Certificate reparenting, version numbers in extensions
>
>David, you said
>>If a new meaning 
>>is attached to the same semantics, then it should be given a new OID 
>
>I hope that you meant "if a new meaning is attached to the same SYNTAX it 
>should be given a new OID."
>
>I'm about to release a specification for what we call "Novell Registered
>Attributes(tm)", 
>a rather complex set of attributes that deal with computer security, crypto
>module 
>security, key storage quality, certificate class, an Enterprise ID, which is
>a form of 
>universal Mandatory Access Control label, and Reliance Limits.
>
>The syntax is complicated enough, but the semantics are even more extensive.
>
>In the case of Reliance Limits, for example, the document contains a listing
>of the
>currency codes used by every country in the world.
>
>Now, do the semantics of the attribute change just because some obscure
>country
>comes into existance, or changes its name, or decides to change the name of 
>of or revalue its currency?
>
>I don't think so, and hence wouldn't even consider changing the OID of the
>attribute in 
>that case -- it would cause needless confusion, and software that used to
>work would 
>suddenly stop.
>
>So within the mega-attribute, I have included both a major and a minor
>version number.
>I expect to update the minor version number any time I make a relatively
>minor editorial 
>change in the defining document, and to update the major version number to 
>correspond to major software releases.
>
>I haven't really thought quite that far ahead, but I guess I would change the
>OID if and
>only if the ASN.1 of the attribute changed in an incompatible way.  In other
>words, if
>a parameter within the ASN.1 were to change in such a way that the new ASN.1
>were 
>to become meaningless to anyone using the old definition, I would change the
>OID.
>
>But if I were to change a value that is self-describing, such as the maximum
>number of
>elements in a bit string, I certainly wouldn't change the OID, even if I did
>update the minor 
>version number to account for the design change.
>
>If I changed the semantic meaning of a particular coded value, I would change
>either the 
>major or the minor version number, so as to clue in the user to go get the
>latest set of 
>definitions. I also include a URL to the defining document within the
>attribute, and 
>would update it accordingly.
>
>Ideally, software which processes these attibutes would be keyed to the major
>and minor
>versions, and to the various languages, so that both the terse indications
>(which would 
>be likely to change only if a major version number update occurred) as well
>as the expanded 
>text and/or help screens would be updated automatically.  If th software saw
>a version
>number for which it didn't have the latest definitions, it ought to whine to
>the user,
>"There is apparently a new version of the definitions available. Please
>update me."
>But it is unlikely that everything would suddenly stop working, and so even
>if the 
>Critical flag is turned on, there is no reason to suddenly reject the
>attribute.
>
>Does this seem like a reasonable approach? 
>
>Bob
>
>>>  
>>> The second problem is that of putting version numbers into extensions.
>>>This 
>>> can interfere with the processing of critical extensions, because it's 
>>> uncertain whether a critical extension which you recognise with a version 
>>> number which you don't recognise counts as a "recognised" (in the sense of
>>> "don't reject the certificate") extension.  You certainly recognise the 
>>> extension (based on the OID), but you don't recognise it based on the
>>>version 
>>> number (this ties in with my earlier complaints about exactly what is
>>>meant 
>>> by "recognise an extension").  As I see it having version numbers in an 
>>> extension means the whole thing falls into a logical loophole, because you
>>>can 
>>> either accept the cert (you recognise the OID) or reject it (you don't 
>>> recognise the data in the extension).
>>>
>>
>>My take on this is that the OID of an extension specifies both the 
>>syntactic and semantic content of the extension. Therefore a given 
>>extension in several different certificate versions would still have 
>>the same meaning, and therefore if you recognise the extension, you 
>>recognise it, period, irrespective of the version. If a new meaning 
>>is attached to the same semantics, then it should be given a new OID 
>>(we already went around this one several years ago in X.500 schema 
>>definitions).
>>
>>The version number would most likely be there because additional 
>>extensions have been defined that you may or may not recognise (and 
>>which may or may not be present in any given certificate)
>>
>>David
>>
>>
>>***************************************************
>>David Chadwick
>>IT Institute, University of Salford, Salford M5 4WT
>>Tel +44 161 295 5351  Fax +44 161 745 8169
>>Mobile +44 370 957 287
>>Email [email-masked] 
>>Home Page  http://www.salford.ac.uk/its024/chadwick.htm 
>>Understanding X.500  http://www.salford.ac.uk/its024/X500.htm 
>>X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm 
>>***************************************************
>
>

Date: Sat, 06 Jun 1998 17:21:26 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Certificate reparenting, version numbers in extensions
Sender: [email-masked]

David, you said
>If a new meaning 
>is attached to the same semantics, then it should be given a new OID 

I hope that you meant "if a new meaning is attached to the same SYNTAX it 
should be given a new OID."

I'm about to release a specification for what we call "Novell Registered Attributes(tm)", 
a rather complex set of attributes that deal with computer security, crypto module 
security, key storage quality, certificate class, an Enterprise ID, which is a form of 
universal Mandatory Access Control label, and Reliance Limits.

The syntax is complicated enough, but the semantics are even more extensive.

In the case of Reliance Limits, for example, the document contains a listing of the
currency codes used by every country in the world.

Now, do the semantics of the attribute change just because some obscure country
comes into existance, or changes its name, or decides to change the name of 
of or revalue its currency?

I don't think so, and hence wouldn't even consider changing the OID of the attribute in 
that case -- it would cause needless confusion, and software that used to work would 
suddenly stop.

So within the mega-attribute, I have included both a major and a minor version number.
I expect to update the minor version number any time I make a relatively minor editorial 
change in the defining document, and to update the major version number to 
correspond to major software releases.

I haven't really thought quite that far ahead, but I guess I would change the OID if and
only if the ASN.1 of the attribute changed in an incompatible way.  In other words, if
a parameter within the ASN.1 were to change in such a way that the new ASN.1 were 
to become meaningless to anyone using the old definition, I would change the OID.

But if I were to change a value that is self-describing, such as the maximum number of
elements in a bit string, I certainly wouldn't change the OID, even if I did update the minor 
version number to account for the design change.

If I changed the semantic meaning of a particular coded value, I would change either the 
major or the minor version number, so as to clue in the user to go get the latest set of 
definitions. I also include a URL to the defining document within the attribute, and 
would update it accordingly.

Ideally, software which processes these attibutes would be keyed to the major and minor
versions, and to the various languages, so that both the terse indications (which would 
be likely to change only if a major version number update occurred) as well as the expanded 
text and/or help screens would be updated automatically.  If th software saw a version
number for which it didn't have the latest definitions, it ought to whine to the user,
"There is apparently a new version of the definitions available. Please update me."
But it is unlikely that everything would suddenly stop working, and so even if the 
Critical flag is turned on, there is no reason to suddenly reject the attribute.

Does this seem like a reasonable approach? 

Bob

>>  
>> The second problem is that of putting version numbers into extensions.  This 
>> can interfere with the processing of critical extensions, because it's 
>> uncertain whether a critical extension which you recognise with a version 
>> number which you don't recognise counts as a "recognised" (in the sense of 
>> "don't reject the certificate") extension.  You certainly recognise the 
>> extension (based on the OID), but you don't recognise it based on the version 
>> number (this ties in with my earlier complaints about exactly what is meant 
>> by "recognise an extension").  As I see it having version numbers in an 
>> extension means the whole thing falls into a logical loophole, because you can 
>> either accept the cert (you recognise the OID) or reject it (you don't 
>> recognise the data in the extension).
>>
>
>My take on this is that the OID of an extension specifies both the 
>syntactic and semantic content of the extension. Therefore a given 
>extension in several different certificate versions would still have 
>the same meaning, and therefore if you recognise the extension, you 
>recognise it, period, irrespective of the version. If a new meaning 
>is attached to the same semantics, then it should be given a new OID 
>(we already went around this one several years ago in X.500 schema 
>definitions).
>
>The version number would most likely be there because additional 
>extensions have been defined that you may or may not recognise (and 
>which may or may not be present in any given certificate)
>
>David
>
>
>***************************************************
>David Chadwick
>IT Institute, University of Salford, Salford M5 4WT
>Tel +44 161 295 5351  Fax +44 161 745 8169
>Mobile +44 370 957 287
>Email [email-masked] 
>Home Page  http://www.salford.ac.uk/its024/chadwick.htm 
>Understanding X.500  http://www.salford.ac.uk/its024/X500.htm 
>X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm 
>***************************************************

Comments: Authenticated sender is <[email-masked]>
From: "David Chadwick" <[email-masked]>
Organization: University of Salford
To: [email-masked], [email-masked]
Date: Sat, 6 Jun 1998 23:20:14 +0000
Subject: Re: Certificate reparenting, version numbers in extensions
Reply-to: [email-masked]
Sender: [email-masked]

>  
> The second problem is that of putting version numbers into extensions.  This 
> can interfere with the processing of critical extensions, because it's 
> uncertain whether a critical extension which you recognise with a version 
> number which you don't recognise counts as a "recognised" (in the sense of 
> "don't reject the certificate") extension.  You certainly recognise the 
> extension (based on the OID), but you don't recognise it based on the version 
> number (this ties in with my earlier complaints about exactly what is meant 
> by "recognise an extension").  As I see it having version numbers in an 
> extension means the whole thing falls into a logical loophole, because you can 
> either accept the cert (you recognise the OID) or reject it (you don't 
> recognise the data in the extension).
>

My take on this is that the OID of an extension specifies both the 
syntactic and semantic content of the extension. Therefore a given 
extension in several different certificate versions would still have 
the same meaning, and therefore if you recognise the extension, you 
recognise it, period, irrespective of the version. If a new meaning 
is attached to the same semantics, then it should be given a new OID 
(we already went around this one several years ago in X.500 schema 
definitions).

The version number would most likely be there because additional 
extensions have been defined that you may or may not recognise (and 
which may or may not be present in any given certificate)

David

***************************************************
David Chadwick
IT Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351  Fax +44 161 745 8169
Mobile +44 370 957 287
Email [email-masked]
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
***************************************************

From: "Blake Ramsdell" <[email-masked]>
To: "'Marc Branchaud'" <[email-masked]>, <[email-masked]>
Subject: RE: DER encoding of BITSTRING
Date: Fri, 5 Jun 1998 15:15:29 -0700
Sender: [email-masked]

> -----Original Message-----
> From: Marc Branchaud [mailto:[email-masked]]
> Sent: Friday, June 05, 1998 9:12 AM
> To: [email-masked]
> Subject: Re: DER encoding of BITSTRING
> 
> I was confusing the definition of keyUsage, which isn't just 
> a plain BIT
> STRING but is really what X.680 calls a "NamedBitList".  
> NamedBitLists, as
> you say, have trailing zeros removed in DER, whereas plain 
> BIT STRINGs don't.

Ah, good old ITU-T Rec. X.680 | ISO/IEC 8824-1, subclause 19.7.  I hate
it when that happens.

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Certificate transport encoding question
Reply-To: [email-masked]
Date: Sat, 6 Jun 1998 05:10:27 (NZST)
Sender: [email-masked]

I've got two questions about certificate encoding in transport formats, I've 
sent them to both lists since they're a bit nonspecific.
 
The first one concerns the order of certs in a cert chain.  Looking at the CMS 
spec, it says that the SET OF Certificate should contain chains from the root 
down to each required subject, but doesn't give any explicit ordering.  An 
ASN.1 SET is inherently unordered, but is there any recommended, consistent 
way to encode a cert chain, or do you just add them in whatever order you feel 
like?  So far I've seen them ordered from subject to root, from root to 
subject, and pseudorandomly (using the DER SET encoding rules)... all of these 
are equally valid, it just seems messy to have any number of possible 
orderings present.
 
The second one concerns something which isn't explicitly addressed by any 
standard but which it might be worth covering somewhere.  When a certificate 
or cert-related object (cert request, CRL) is base64-encoded, there are again 
a large number of different interpretations on what delimiters to use around 
the base64 data.  I've seen BEGIN CERTIFICATE, BEGIN CERTIFICATE REQUEST, 
BEGIN NEW CERTIFICATE REQUEST, BEGIN PGP MESS...no hang on, that's something 
else :-).  Alongside these are various creative mutations (extra blank lines, 
name:value pairs a la PGP, and other oddities).  It's probably a good idea to 
specify a set format for these as well and attach them to some existing 
standard.  If there's a need for them I'll put together a paragraph or two 
defining the exact format.
 
Peter.

To: [email-masked]
Subject: Re: DER encoding of BITSTRING 
Date: Fri, 05 Jun 1998 09:11:39 -0700
From: Marc Branchaud <[email-masked]>
Sender: [email-masked]

-----BEGIN PGP SIGNED MESSAGE-----

Content-Type: text/plain; charset=us-ascii

Olivier,

Thanks for the info!

I was confusing the definition of keyUsage, which isn't just a plain BIT
STRING but is really what X.680 calls a "NamedBitList".  NamedBitLists, as
you say, have trailing zeros removed in DER, whereas plain BIT STRINGs don't.

		Marc

+------------------------------------------------------------------------+
 Marc Branchaud                                  \/
 Chief PKI Architect                             /\CERT INTERNATIONAL INC.
 [email-masked]        PKI References page:              www.xcert.com
 604-640-6227          www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+
  PGP key fingerprint:  60 11 4B 9D 4E E5 2F 47  BD C5 C2 BF 26 DF 5A E1

 <[email-masked]> scrawled:
> 
> >-----BEGIN PGP SIGNED MESSAGE-----
> >
> >Content-Type: text/plain; charset=us-ascii
> >
> >
> >In Part 1, example D.3 on page 113 shows an encoding of keyUsage bits.  For 
> >the example, only the digitalSignature bit (bit 0) is set.
> >
> >The example has the following hex encoding: 03 02 07 80, meaning:
> >
> >	03 - This is a BITSTRING
> >	02 - There are 2 octets used to encode the string
> >	07 - Ignore the last 7 bits of the last octet
> >	80 - The bits
> >
> >The problem is that the 07 says that only the first bit of the last octet 
> >should be recognized.
> >
> >Isn't this wrong?  This is really an encoding for a 1-bit BITSTRING, no?  I
> >think the encoding should be 03 03 07 80 00, so that the first 9 bits of the
> >"8000" are fully specified and _all_ of keyUsage's bits are explicitly
> >assigned a value.
> >
> >		Marc
> >
> >+------------------------------------------------------------------------+
> > Marc Branchaud                                  \/
> > Chief PKI Architect                             /\CERT INTERNATIONAL INC.
> > [email-masked]        PKI References page:              www.xcert.com
> > 604-640-6227          www.xcert.com/~marcnarc/PKI/
> >+------------------------------------------------------------------------+
> >  PGP key fingerprint:  60 11 4B 9D 4E E5 2F 47  BD C5 C2 BF 26 DF 5A E1
> >
> >
> >
> >-----BEGIN PGP SIGNATURE-----
> >Version: 2.6.2
> >
> >iQB1AwUBNXcHx1rdFXNdDxPlAQEVKwL/X4LdXYob4rQnzYIE2sXpW1CYxNEynf+P
> >M6IC6cfYqIrHxLlgmRcNOIwiEH2Usj9d/pCYU6odJggH+HS4Kt8VsXXTQu5tcWCt
> >CtRRufTkDHsHuNDmI6yLDQkByR3nHRAN
> >=59Mu
> >-----END PGP SIGNATURE-----
> >
> >
> 
> Hi!
> 
> DER-coding is so simple !
> 
>  The DER-Encoding of a "NamedBitString" implies that the trailing bits which
> are 0
>  must NOT be coded:
> 
> 
> 
>         BER-coding:
>         According to X.680, Chapter 19.7,
>         "The trailing bits which are
>         0 can be removed from the coding (and are not relevant anymore)"
>  
>         DER-coding: 
>         In X.690,Chapter 11.2.2 (DER-encoding): 
>         "The bitstring shall have all trailing 0 bits
>         removed before it is encoded."
> 
>         It means, the bitstring '1' (DER-coded as 03 02 07 80) represents:
>                      digitalSignature  ON
>                      nonRepudiation    OFF
>                      keyEncipherment   OFF
>                      dataEncipherment  OFF
>                      keyAgreement      OFF
>                      keyCertSign       OFF
>                      cRLSign           OFF
>                      encipherOnly      OFF
>                      decipherOnly      OFF
> 
>        and it is the only correct DER-encoding for this.
> 
> 
> Bye
> 
> 
> Olivier.
> 
>  ___________________________________________________________________
>  Olivier Onimus                                            
>  Danet GmbH, Business Unit Telecommunications Technology   
>  Gutenbergstrasse 10, D-64331 Weiterstadt, Germany         
>  Tel: +49-6151-868-127  Fax:+49-6151-868-264  E-mail:[email-masked]
>  WEB: www.danet.de
>  __________________________________________________________________

Date: Fri, 05 Jun 1998 08:30:04 -0400
From: "Gorman, Jeanne" <[email-masked]>
Subject: RE: CRL issuing
To: [email-masked]
Sender: [email-masked]

SET applications support the case you have described.  The SET Brand CAs use
separate keys for Certificate Signing and CRL Signing - the usage is
indicated by the keyUsage extension.  SET uses V2 CRLs that contain the
AuthorityKeyIdentifier extension so that the signer can be found.  And the
Brand CA's Cert Signing and CRL Signing certs contain matching DNs so that
the cert issuer can be found.   

Jeanne Gorman
GTE
> ----------
> From: 	Peter Lipp[SMTP:[email-masked]]
> Sent: 	Wednesday, May 27, 1998 10:13 AM
> To: 	[email-masked]; Stefan Santesson
> Subject: 	Re: CRL issuing
> 
> >The CA is by this procedure linked to the CRL by certifying the
> >public key with which the CRL can be checked.
> 
> Which implementations currently can handle this and which don't?
> 
> More precisely, which implementations currently can handle CRL's at all
> and which of them can handle these special public key properly?
> 
> I guess not too many.....
> 
> Peter
> 

Date: Fri, 5 Jun 1998 10:58:54 +0200
To: Marc Branchaud <[email-masked]>
From: [email-masked] (Olivier Onimus)
Subject: Re: DER encoding of BITSTRING
Cc: [email-masked]
Sender: [email-masked]

>-----BEGIN PGP SIGNED MESSAGE-----
>
>Content-Type: text/plain; charset=us-ascii
>
>
>In Part 1, example D.3 on page 113 shows an encoding of keyUsage bits.  For 
>the example, only the digitalSignature bit (bit 0) is set.
>
>The example has the following hex encoding: 03 02 07 80, meaning:
>
>	03 - This is a BITSTRING
>	02 - There are 2 octets used to encode the string
>	07 - Ignore the last 7 bits of the last octet
>	80 - The bits
>
>The problem is that the 07 says that only the first bit of the last octet 
>should be recognized.
>
>Isn't this wrong?  This is really an encoding for a 1-bit BITSTRING, no?  I
>think the encoding should be 03 03 07 80 00, so that the first 9 bits of the
>"8000" are fully specified and _all_ of keyUsage's bits are explicitly
>assigned a value.
>
>		Marc
>
>+------------------------------------------------------------------------+
> Marc Branchaud                                  \/
> Chief PKI Architect                             /\CERT INTERNATIONAL INC.
> [email-masked]        PKI References page:              www.xcert.com
> 604-640-6227          www.xcert.com/~marcnarc/PKI/
>+------------------------------------------------------------------------+
>  PGP key fingerprint:  60 11 4B 9D 4E E5 2F 47  BD C5 C2 BF 26 DF 5A E1
>
>
>
>-----BEGIN PGP SIGNATURE-----
>Version: 2.6.2
>
>iQB1AwUBNXcHx1rdFXNdDxPlAQEVKwL/X4LdXYob4rQnzYIE2sXpW1CYxNEynf+P
>M6IC6cfYqIrHxLlgmRcNOIwiEH2Usj9d/pCYU6odJggH+HS4Kt8VsXXTQu5tcWCt
>CtRRufTkDHsHuNDmI6yLDQkByR3nHRAN
>=59Mu
>-----END PGP SIGNATURE-----
>
>

Hi!

DER-coding is so simple !

 The DER-Encoding of a "NamedBitString" implies that the trailing bits which
are 0
 must NOT be coded:

        BER-coding:
        According to X.680, Chapter 19.7,
        "The trailing bits which are
        0 can be removed from the coding (and are not relevant anymore)"
 
        DER-coding: 
        In X.690,Chapter 11.2.2 (DER-encoding): 
        "The bitstring shall have all trailing 0 bits
        removed before it is encoded."

        It means, the bitstring '1' (DER-coded as 03 02 07 80) represents:
                     digitalSignature  ON
                     nonRepudiation    OFF
                     keyEncipherment   OFF
                     dataEncipherment  OFF
                     keyAgreement      OFF
                     keyCertSign       OFF
                     cRLSign           OFF
                     encipherOnly      OFF
                     decipherOnly      OFF

       and it is the only correct DER-encoding for this.

Bye

Olivier.

 ___________________________________________________________________
 Olivier Onimus                                            
 Danet GmbH, Business Unit Telecommunications Technology   
 Gutenbergstrasse 10, D-64331 Weiterstadt, Germany         
 Tel: +49-6151-868-127  Fax:+49-6151-868-264  E-mail:[email-masked]
 WEB: www.danet.de
 __________________________________________________________________

Date: Fri, 05 Jun 1998 09:58:00 +0200
From: Ferdinando Ricchiuti <[email-masked]>
To: Marc Branchaud <[email-masked]>
Cc: [email-masked]
Subject: Re: DER encoding of BITSTRING
Sender: [email-masked]

Marc Branchaud wrote:

> In Part 1, example D.3 on page 113 shows an encoding of keyUsage bits.  For
> the example, only the digitalSignature bit (bit 0) is set.
> 
> The example has the following hex encoding: 03 02 07 80, meaning:
> 
>         03 - This is a BITSTRING
>         02 - There are 2 octets used to encode the string
>         07 - Ignore the last 7 bits of the last octet
>         80 - The bits
> 
> The problem is that the 07 says that only the first bit of the last octet
> should be recognized.
> 
> Isn't this wrong?  This is really an encoding for a 1-bit BITSTRING, no?  I
> think the encoding should be 03 03 07 80 00, so that the first 9 bits of the
> "8000" are fully specified and _all_ of keyUsage's bits are explicitly
> assigned a value.
> 
>                 Marc

Marc,

Probably the un-encoded bits are "don't-carry" but it is better to
encode all bits.
So I agree with you.

						Nando.

+-------------------------------------------------------------------+
| Ferdinando Ricchiuti                     Computer Science Student |
+--------------------------------+----------------------------------+
| Politecnico di Torino          | phone:  +39-(0)11-5647090        |
| Dip. Automatica e Informatica  | fax:                             |
| corso Duca degli Abruzzi, 24   | e-mail: [email-masked] | 
| 10129 Torino                   |                                  |
| ITALY                          | http://www.polito.it/~fricchi/   | 
+--------------------------------+----------------------------------+

To: [email-masked]
Subject: DER encoding of BITSTRING
Date: Thu, 04 Jun 1998 13:47:04 -0700
From: Marc Branchaud <[email-masked]>
Sender: [email-masked]

-----BEGIN PGP SIGNED MESSAGE-----

Content-Type: text/plain; charset=us-ascii

In Part 1, example D.3 on page 113 shows an encoding of keyUsage bits.  For 
the example, only the digitalSignature bit (bit 0) is set.

The example has the following hex encoding: 03 02 07 80, meaning:

	03 - This is a BITSTRING
	02 - There are 2 octets used to encode the string
	07 - Ignore the last 7 bits of the last octet
	80 - The bits

The problem is that the 07 says that only the first bit of the last octet 
should be recognized.

Isn't this wrong?  This is really an encoding for a 1-bit BITSTRING, no?  I
think the encoding should be 03 03 07 80 00, so that the first 9 bits of the
"8000" are fully specified and _all_ of keyUsage's bits are explicitly
assigned a value.

		Marc

+------------------------------------------------------------------------+
 Marc Branchaud                                  \/
 Chief PKI Architect                             /\CERT INTERNATIONAL INC.
 [email-masked]        PKI References page:              www.xcert.com
 604-640-6227          www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+
  PGP key fingerprint:  60 11 4B 9D 4E E5 2F 47  BD C5 C2 BF 26 DF 5A E1

Date: Wed, 03 Jun 1998 09:45:30 -0400
To: "Peter Lipp" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: question on Subject Key Identifier ipki-part1-07
Cc: [email-masked]
Sender: [email-masked]

PKCS#7 version 1.5 and the IETF CMS document are aligned in this area.
PKCS#7 version 1.6 acts differently, and only SET is using it.

Russ

At 10:17 AM 5/29/98 +0200, Peter Lipp wrote:
>This document sais:
>
>>The hash shall  be calculated over the value (excluding tag and length) of
>the BIT
>>STRING subjectPublicKey in the certificate.
>
>I assume that excluding tag and length comes from the fact that this was the
>same
>in PEM - and PKCS. Currently, PKCS#7 specs changed this behaviour and
>tag and length get included into the hash. Wouldn't it make sense to do the
>same here
>or is there any specific reason not to?
>
>Peter
>
>
> 

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-crmf-01.txt
Date: Wed, 03 Jun 1998 10:24:44 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group 
of the IETF.

	Title		: Internet X.509 Certificate Request Message Format
	Author(s)	: D. Solo, C. Adams, D. Kemp, M. Myers
	Filename	: draft-ietf-pkix-crmf-01.txt
	Pages		: 20
	Date		: 02-Jun-98
	
This document describes the Certificate Request Message Format (CRMF).
This syntax is used to convey a request for a certificate to a
Certification Authority (CA) (possibly via a Registration Authority
(RA)) for the purposes of X.509 certificate production.  The request
will typically include a public key and associated registration
information.

The key words ''MUST'', ''REQUIRED'', ''SHOULD'', ''RECOMMENDED'',
and ''MAY'' in this document (in uppercase, as shown)
are to be interpreted as described in RFC 2119.
 
Please send comments on this document to the [email-masked]
mail list.

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-crmf-01.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-crmf-01.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ftp.ietf.org
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-crmf-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-crmf-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-crmf-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Reply-To: <[email-masked]>
From: "Rich Ankney" <[email-masked]>
To: "Andreas Berger" <[email-masked]>, "Michael Myers" <[email-masked]>
Cc: "David P. Kemp" <[email-masked]>, <[email-masked]>
Subject: Re: CHOICE OF OCSP certID syntax
Date: Wed, 3 Jun 1998 08:12:24 -0400
Sender: [email-masked]

> From: Andreas Berger <[email-masked]>
<snip>
> Hi Mike (and all the others),
> 
> now that I am back again from my holidays...
> 
> Regarding the Hash of the Certificate in OCSP as a CertID. In
> conjunction with the German Signature Law, a method is needed that
> allows to retrieve Information about a certificate that does not require
> the transmission of personal data (issuer and serial can be regarded as
> that) is needed. A hash of a certificate makes sure that the requesting
> party is in posession of the certificate it tries to request information
> for.
> 
> Background: The Law mandates an on-line protocol to be used for checking
> signatures (CRLs are allowed but the potential "time gap" is the risk of
> the user choosing CRLs over the on-line method). So a client could send
> the certificate it requests information about to the on-line service.
> This is not recommended since it poses severe privacy threats if used
> unencrypted. The next best solution would be to hash the certificate and
> use this hash as an identifier.
> 
> But you are right, using a hash only to identify a certificate makes me
> feel a bit uneasy. Probably we should allow different hash algorithms?
> Or add a hash of the DER encoding of Issuer/Serial?
> 
> 
> Andreas

My concern over using just a hash is that it's hard to distribute the
repository using just the hash.  E.g. if I retrieve a certificate status
using the subject name, I can use the normal X.500 mechanisms to
distribute the repository database among multiple servers.  

If the certificate indicates (in the AuthorityInfoAccess extension, for
example) where the OCSP server is, then perhaps the hash would
be sufficient...

Regards,
Rich

From: "Fabio Omenigrandi" <[email-masked]>
To: [email-masked]
cc: "Andrea Sansone" <[email-masked]>
Date: Wed, 3 Jun 1998 13:03:54 +0200
Subject: Questions about using DeltaCRLIndicator extension
Sender: [email-masked]

Is it correct the value of attribute extensions of the
following CA behaviour when issues the CRL ?

Suppose that in a first time I issue the base CRL.

1 Time)    CRL (base):       cRLNumber = 1
                            BaseCRLNumber = Not used.

In a second time I issue a complete CRL and a first deltaCRL

2 Time)     CRL (complete) : cRLNumber = 2
                             BaseCRLNumber = Not used.

            CRL (Delta) : cRLNumber = 2
                     (the pointer to the complete new CRL)
                          BaseCRLNumber = 1
                     (the pointer to the first base CRL)

In a third time I issue a complete CRL and second deltaCRL

3 Time)    CRL (complete) : cRLNumber = 3

           CRL (Delta) : cRLNumber = 3
                        (the pointer to the complete new CRL)
                         BaseCRLNumber = 1
                        (the pointer to the base CRL)

Thank you.
Andrea Sansone. Fabio Omenigrandi
SSB S.p.A.

P.S.: there is a inconsistency between the definition of the
DeltaCRLIndicator given by PKIX-1 and given by X.509-8.
In particular in PKIX-1 (pag. 46) you can read "... received
delta-CRL is more *that* one greater that the ..." instead
in X.509-8 (pag. 44) you can read "... received delta-CRL
is more *than* one greater that the ...".

Date: Wed, 03 Jun 1998 10:09:34 +0200
From: Andreas Berger <[email-masked]>
To: Michael Myers <[email-masked]>
CC: "David P. Kemp" <[email-masked]>, [email-masked]
Subject: Re: CHOICE OF OCSP certID syntax
Sender: [email-masked]

Michael Myers wrote:
> 
> Dave,
> 
> At 10:15 AM 5/21/98 -0400, David P. Kemp wrote:
> >As discussed here previously, the cert hash by itself
> >may be insufficient to serve as a retrieval index.
> 
> I recall Steve discussing a hash of the CA's key:
> 
> >While the hash of a CA's key would likely be unique, it also is a terrible
> >search key in many instances. One has to be careful about the context in
> >which a pointer to a CA cert is being used. In a cert, having a CA "key ID"
> >that is based on the hash of the CA is fine, because we already have the CA
> >name, and maybe even a locator.  In other protocol context we should have a
> >similar level of naming for search purposes, and rely on something like a
> >key hash just for disambiguation among multiple possible keys associated
> >with the same CA.
> 
> but this doesn't speak to a hash of the subject certificate.
> 
> Do I take your response to be against the CHOICE generally?  There is
> benefit to the installed base of systems that are successfully using the
> {Issuer DN, subject serial number} model of certificate identification.
> 
> Mike
Hi Mike (and all the others),

now that I am back again from my holidays...

Regarding the Hash of the Certificate in OCSP as a CertID. In
conjunction with the German Signature Law, a method is needed that
allows to retrieve Information about a certificate that does not require
the transmission of personal data (issuer and serial can be regarded as
that) is needed. A hash of a certificate makes sure that the requesting
party is in posession of the certificate it tries to request information
for.

Background: The Law mandates an on-line protocol to be used for checking
signatures (CRLs are allowed but the potential "time gap" is the risk of
the user choosing CRLs over the on-line method). So a client could send
the certificate it requests information about to the on-line service.
This is not recommended since it poses severe privacy threats if used
unencrypted. The next best solution would be to hash the certificate and
use this hash as an identifier.

But you are right, using a hash only to identify a certificate makes me
feel a bit uneasy. Probably we should allow different hash algorithms?
Or add a hash of the DER encoding of Issuer/Serial?

Andreas
-- 
Erst kommt das Fressen, dann kommt die Moral
 -- Bertolt Brecht

Date: Tue, 02 Jun 1998 17:02:21 -0400
To: [email-masked]
From: Rodney Thayer <[email-masked]>
Subject: test
Sender: [email-masked]

please ignore.

-----------------
Rodney Thayer
EIS Corporation
[email-masked]

Date: Tue, 02 Jun 1998 08:26:10 +0200
From: Bertus Pretorius <[email-masked]>
Organization: SACA
To: E-CARM <[email-masked]>, certtalk <[email-masked]>, [email-masked]
Subject: Re: [E-CARM] Pseudonyms
Sender: [email-masked]

I though this argument was allready cleared.  Yes it is dangerous to use (reference
name, key).
Thus we should use (reference name, key, reference or validity domain or community)
where the technology bind the tuplet and the reference or community provide the
"trust" value and provide warrantees to the issuing of the subscriber for the user
to reference.

Stephen Kent wrote:

> Carl,
>
> >>I know that lot's of Peter Lipp's exist, so the individual corresponding to
> >>this
> >>name (which is the meaning of the name) is not clearly defined by Peter Lipp
> >>alone. What else is new? Does this make the concept of certificates invalid?
> >
> >This lack of name uniqueness makes (name,key) certificates dangerous and
> >puts the wisdom of using (name,key) certificates into doubt.  The danger is
> >that we are so accustomed to using names as valid identifiers of people in
> >our daily lives (thanks to our living, in the 3D world, in small communities
> >of friends, family, coworkers, ...), that we are tempted to believe that all
> >names are valid identifiers.  In a national, continental or global
> >namespace, those names are not valid identifiers and a careful security
> >design would not allow people to believe they are.  The current (name,key)
> >certificate design and more especially the verbiage surrounding (name,key)
> >certificates (including the texts of laws) not only allows people to believe
> >names are valid identifiers but also seems to suffer from that mistake itself.
> >The danger of this belief mismatch is that someone looking for the certified
> >key of an old friend (or co-worker or customer or merchant or ...) is led
> >to guess whether the name in the certificate belongs to the entity that
> >user things it might -- based on name match.  This process is a human guess
> >and there is no room in security procedures for human guesses...at least
> >not when we are trying to keep mistakes in the process down to a probability
> >of less than 2^{-90}.
>
> Names can be unique, if suitably qualified.  Each of us have a number of
> "names" that serve this purpose, and each tends to be used in a context
> where it is unique.  We all agree that no single name is both globally
> unique and universally meaningful.  However, that does not mean than we are
> unable to certify names in many contexts that will prove adequate for many
> applications.  Your claim that a name and key pair is dangerous is not well
> founded sounds way too much like a SPKI promotion.  Wrong list, Carl.
>
> Steve
>
> ===========================================================================
> Help with Majordomo commands plus list archives and information is
> available through the E-CARM web page at http://www.kc-inc.net/e-carm/.
> Sponsored by The Knowledge Connection.
> ===========================================================================

--
These are my biased opinions and do not represent SACA nor PQ Holdings
Bertus Pretorius, 083 303-1812, [email-masked]
The South African Certification Agency, www.saca.net
SACA is part of Persetel Q-Data Holdings, www.pqholdings.com
----------- A smile is the same in all languages -----------

Date: Sat, 30 May 1998 14:06:51 -0400
To: Carl Ellison <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: [E-CARM] Pseudonyms
Cc: "Peter Lipp" <[email-masked]>, "E-CARM" <[email-masked]>, "certtalk" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Carl,

>>I know that lot's of Peter Lipp's exist, so the individual corresponding to
>>this
>>name (which is the meaning of the name) is not clearly defined by Peter Lipp
>>alone. What else is new? Does this make the concept of certificates invalid?
>
>This lack of name uniqueness makes (name,key) certificates dangerous and
>puts the wisdom of using (name,key) certificates into doubt.  The danger is
>that we are so accustomed to using names as valid identifiers of people in
>our daily lives (thanks to our living, in the 3D world, in small communities
>of friends, family, coworkers, ...), that we are tempted to believe that all
>names are valid identifiers.  In a national, continental or global
>namespace, those names are not valid identifiers and a careful security
>design would not allow people to believe they are.  The current (name,key)
>certificate design and more especially the verbiage surrounding (name,key)
>certificates (including the texts of laws) not only allows people to believe
>names are valid identifiers but also seems to suffer from that mistake itself.
>The danger of this belief mismatch is that someone looking for the certified
>key of an old friend (or co-worker or customer or merchant or ...) is led
>to guess whether the name in the certificate belongs to the entity that
>user things it might -- based on name match.  This process is a human guess
>and there is no room in security procedures for human guesses...at least
>not when we are trying to keep mistakes in the process down to a probability
>of less than 2^{-90}.

Names can be unique, if suitably qualified.  Each of us have a number of
"names" that serve this purpose, and each tends to be used in a context
where it is unique.  We all agree that no single name is both globally
unique and universally meaningful.  However, that does not mean than we are
unable to certify names in many contexts that will prove adequate for many
applications.  Your claim that a name and key pair is dangerous is not well
founded sounds way too much like a SPKI promotion.  Wrong list, Carl.

Steve

Date: Sat, 30 May 1998 13:59:58 -0400
To: Ferdinando Ricchiuti <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Key Usage for for Authentication and digitalSignature
Cc: Nilsson Hans <[email-masked]>, [email-masked]
Sender: [email-masked]

Ferdinando,

>Actually in the SSL-v3.0 client-autentication phase, the client
>generates a MAC in this way:
>	1-the received data (master key) are padded and hashed
>	2-the resulting stream is then padded again and rehashed
>	3-this finaly stream is encrypted with client's private key
>This mean that the MAC sent to the server, is not a digital signature
>as defined in X.509 specification.
>Thus we think there are not security leack using both digitalSignature
>and nonRepudation bits.

Since SSL v3 supports more p[ublic key algorithms than just RSA, I am
puzzled by the third step as defined above.  How do I "encrypt" using my
private DSA or Diffie-Hellman key?

Steve

Date: Sat, 30 May 1998 13:56:44 -0400
To: "Peter Lipp" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: [E-CARM] Pseudonyms
Cc: "Ed Gerck" <[email-masked]>, "E-CARM" <[email-masked]>, "certtalk" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Peter,

I envision two ways of handling this, depdning on whether the certs are for
human or machine consumtion.  In the former case, some form of naming
conventions will likley be adopted, maybe in the CN, or maybe at a higher
RDN.  For automated consumption, why not use the security policy extension
and incorporate an approriate OID?

Steve

Date: Sat, 30 May 1998 13:33:11 -0400
To: Nilsson Hans <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Key Usage for for Authentication and digitalSignature
Cc: [email-masked]
Sender: [email-masked]

Nilsson,

>"For example, when an RSA key should be used only for signing, the
>digitalSignature and nonRepudation bits would be asserted"
>and also "The digitalSignature bit is asserted when the subject public key
>is used to privde authentication". The same writing can be found in the new
>ISO draft 1572 (Public Key certificates for banking.
>
>If understand this correctly, this introduces a possible security threat,
>with the following scenario: In a user's certificate, both bits are set.
>When the user is required to logon to a web server using SSL client
>authentication, the server actually sends a the hash value of a false
>message, instead of a random number as a challenge.  The user encrypts with
>the corresponding private key, and has thus unknowingly signed the false
>message.

I think the wording is in error.  Just because a key is used for signature
purposes does not mean that it is used for non-repudaiation, e.g., it may
be used for authentication.

>Because of this threat, we have in Sweden come to the conclusion that the
>nonRepudiation usage bit never may be combined with any other key usage. Is
>this correct (and PKIX-part1-07 wrong), or have we misunderstood something
>along the way?

I'd argue, as above, that one really should turn on both signature and
non-repduation flags when signing to support N-R.

steve

Date: Tue, 30 Jun 1998 19:36:04 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: PKIX-1 - use of UTF8
Sender: [email-masked]

All good points, Chris. But in our case, at least, the directory and all of the other 
Novell server and client code have been Unicode enabled for many years, and 
UTF-8 was relatively recent. So no one is rushing to BMPString -- we've been using
it for some time, at least as far as I know.

Whether in the past we emitted pure Unicode or perhaps BMPString before it was 
standardized, I don't know.

In our PKIS product, we store the certificates in NDS using the native NDS interface, i.e., 
in Unicode, as I understand it.

I'm told that our LDAP 3  implementation will handle UTF-8, but I don't yet know 
whether that is for storage or retrieval, or whether there are any options. You certainly
know LDAP3 better than I do -- is UTF-8 the only option allowed?i

The cost or availability of the conversion code is of course the least of the issues, 
at least to us. Whether Bill Gates lies awake wondering if he can afford it, I
don't know. :-)

Bob
>
>
>>>> Chris Newman <[email-masked]> 06/30 8:40 AM >>>
>There seems to be some confusion surrounding BMPString, UTF-8 and Unicode.
>
>BMPString is purportedly the 16-bit subset of Unicode (full Unicode is
>represented in UTF-16).  It's less expressive than UTF-8.  Technically, a
>Unicode to BMPString converter would lose data.  This could become a
>serious issue when less frequently used CJK characters are assigned in
>plane 1 of Unicode (outside the BMP). 
>
>The conversion between Unicode (UTF-16) and UTF-8 is simple, and free code
>is available at <ftp://ftp.unicode.org/Public/PROGRAMS/CVTUTF/>.  While
>UTF-8 is more expressive than Unicode, it's unlikely that codepoints will
>be assigned outside the overlap between the two (on the flip side, there
>are already numerous proposals to assign codepoints outside the BMP).
>
>I will also point out that UTF-8 support in LDAPString DNs is a mandatory
>part of the LDAPv3 spec.  Was there some other directory you were planning
>on storing certificates in? 
>
>So I question why people are rushing towards BMPString when it's different
>from the predominant future directory technology and less expressive than
>the IETF preferred charset. 
>
>		- Chris
>

Date: Tue, 30 Jun 1998 19:14:45 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: RE: PKIX-1 - use of UTF8
Sender: [email-masked]

Brian LaMacchia (of Microsoft, or at least of microsoft.com) said:

>To provide another datapoint concerning BMPString support, we introduced
>client-side support for BMPString-encoded DirectoryString components in IE
>4.01.  All client-side code released since then (including IE 4.01 SP1,
>Windows 98 and the IE 5.0 Developer Preview) uses BMPString encodings for
>strings that contain characters not in the PrintableString character set.
>(Internally, everything is kept in Unicode.)  MS Certificate Server follows
>the same encoding rules for certs it issues.   

Unfortunately, perhaps, in the Novell Public Key Infrastructure Services 
component about to be released, we followed the PKIX draft instead of 
what would have arguably have been the more reasonable position, i.e., 
Microsoft's.

That is, we test a given character string character by character. If it will fit in 
Printable String, that's what we use. If it will fit in teletext, that's what we use,
archane escape characters and all. Otherwise, we output BMPString.

It wouldn't break my heart to abandon teletext in the next release, and probably
(hopefully) no one would be impacted terribly.  If we (collectively) were to decide 
to do so in the next few weeks, we _might_ even be able to delete teletext prior to 
shipping the internationalized versions of the software, but that is not a committment.

However, as of today it appears that given the appropriate input we will output a 
string which the Microsoft browser, Windows 98(??), etc., could not accept, i.e., 
teletext.

Whether the Netscape browser will accept teletext (or BMPString, for that matter),
I'm not entirely sure. We are in the process of testing those kinds of compatiblity 
issues right now.

One thing does appear reasonably clear, however, and that is that no CA product that
I am aware of currently emits UTF-8. Moreover, it appears highly doubtful that with 
the possible exception of SET code (of which there isn't a vast quantity, certainly),
there are no browsers or other certificate consumers that would be capable of
displaying UTF-8.

On the other hand, it appears that there is a considerable amount of support
for BMPString, namely to support products which use Unicode internally,
for what other option would they have had until very recently?

My conclusions are that:

1.   We could probably abandon teletext and substitute BMPString without 
much pain, especially since it appears that there might not be much browser
support for it, whereas there is more support for BMPString. (This is perhaps 
a US-centric vendor view.  Some European vendors who aren't concerned 
with the Asian market might very well see the issue differently.)

2.  Browser vendors should be encouraged to support UTF-8 as soon as possible,
if that is the way we are going to go. (Personally, given the BMPString support, I 
am NOT entirely convinced that is the correct direction, but I'll go along with 
whatever the majority of vendors decide, more or less independently of what 
the IESG/IETF decides. In other words, interoperability is _far_ more important
than standards compliance, at this point.)

3.  There is no chance that the CA products are going to lead the pack in 
implementing UTF-8. If they don't have it already, they are going to have 
to implement BMPString to compete in the Asian market, since that is what the 
existing browsers support.  And once BMPString is widely supported, UTF-8
becomes a much more difficult sell, IMHO.  But clearly emitting UTF-8 strings
as a mandatory encoding for Asian characters and maybe even the accented 
European characters when there ar no consumers for such strings is
the Dr. Kevorkian option.  

Exactly where Russian and Greek fit into this equation I'm not quite sure.

bob
>
>					--bal
>
>-----Original Message-----
>From: Brian Korver [mailto:[email-masked]] 
>Sent: Monday, June 29, 1998 4:12 PM
>To: [email-masked] 
>Cc: [email-masked]; [email-masked]; [email-masked];
>[email-masked] 
>Subject: Re: PKIX-1 - use of UTF8
>
>Bob,
>
>I'm certainly not telling anyone "simply speak English", or suggesting
>that anyone else do that.  Maybe I haven't been clear.
>
>Let me restate my point:  I don't know that implementations that support
>BMPString are any more common than implementations that support UTF8String.
>(by "support", I mean that they do not merely treat DNs (et al.) as
>opaque data.)  
>
>BMPString is a recent addition to DirectoryString.  I'd like to know
>if there are any non-SET implementations that actually support
>BMPString (again, don't confuse "support BMPString" with "support for
>UNICODE").  I believe there aren't many (any?) non-SET implementations that
>actually support BMPString, but please correct me if I'm wrong.
>
>If support for BMPString is widespread, then backwards compatibility is
>an issue.  If support for BMPString is not widespread, then backwards
>compatibility may not be an issue.
>
>brian
>[email-masked]

Date: Tue, 30 Jun 1998 18:54:26 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: Proposed Resolution of Comments (LONG!)
Sender: [email-masked]

Russ,

I think that several of these issues have been clarified to my satisfaction.

(1) So long as we are not required to prefix the 4-bit identifier in the keyIdentifier
for certificates which include both subject and authority key ID, I'm satisfied.
Whether or not we should more or less automatically be aligning with other
(primarily US) standards groups is an issue we could talk about some other time.

(2) I don't care which way the DN= issue goes. At present, we encode
DNS names in the commonName, which is distasteful, and I would be happy to 
change to something else as soon as we decide what to do.

(3) I would strongly recommend we add the X.520 definition of streetAddress 
to the list of RDN types that constitute the minimal schema for certificate 
processing code, including directory/respositories.  Implementing it within 
a CA should be optional, but recommended.

(4) If the only aspects of KEA that are included are the OID and parameter list,
then I suppose I could withdraw my objection.  But on the other hand, 
shouldn't we then give elliptic curves the same status?  What about 
Redpike (UK), GOST(Russian), and other algorithms? What are the support 
considerations?  If KEA is included in the spec, will CA vendors be expected to 
generate KEA certs as well as DSS, yada, yada, yada?  where will it all end?
Will the various browsers, etc, now be expected to support it, just because 
it is in "the standard"? In other words, just because the US government is 
going to use it, why should it necessarily be imposed on all vendors via 
the PKIX spec?  BTW, did the US government release it free and clear of 
patent encumbrances, and will they agree to defend at USG expense any 
patent claims that might be brought by anyone claiming infringement?  I 
doubt that the various patent attorneys have had time to review this yet. 
I just hate to see us rush to judgment on this without a full airing of possible 
issues.

Bob

>
>>>> Russ Housley <[email-masked]> 06/30 8:49 AM >>>
>Bob:
>
>>(1) Could you explain the motivation for including the 4-bit identifier in 
>>the keyIdentifier?  Since it hasn't even been defined yet, we 
>>clearly aren't using it. And we had a hard enough time getting 
>>just the Netscape and IE browsers to accept the same
>>kind of certificates that I would be very reluctant to change 
>>anything at this point.
>>
>>But perhaps more to the point, does it matter a whit to anyone that is 
>>processing a certificate what particular algorithm was used to 
>>generate a key ID, or why?  Suppose I want to include 
>>some other information, such as the identity of the server on 
>>which the key was created, or a customer ID, etc., etc?  
>>Why does this matter to anyone's software other than the CA's?
>>
>>So long as the keyID is one-to-one with a public key (which is 
>>what I believe the underlying requirement to be, what difference 
>>does it make how it is encoded (at least within reason)?
>
>This has been answered before.  Here it is again.  The key identifier was
>selected to align with documents from US Government, ANSI X9, and Draft ISO
>TC68.  The four-bit prefix permits the definition of other schemes.  However,
>clients don't care since they simply do exact match comparisons.
>
>>(2) On the issue of the proposed schema for DN components, I agree with 
>>those that have said that decomposing and DNS name is mostly 
>>a waste of time, and I doubt the efficacy of using name subordination 
>>on those fields, but I don't feel terribly strongly on the subject.
>
>There are some people using DN= as a component of a distinguished name.  I
>have
>no problem adding this to the PKIX list.
>
>>(3) On the other hand I believe that not including support for the 
>>residentialPerson type of user is unacceptable.  Not all applications 
>>are going to involve e-mail, and a street address is a pretty 
>>fundamental construct for most business and social usage.
>>
>>Why would you even care what country someone lived in 
>>(other than mere curiosity), much less locality or state, if you 
>>couldn't refer to the individual's (or organization's)
>>physcial delivery address?  It is necessary for disambiguating 
>>the name, in general, in addition to its other uses.
>>
>>StreetAddress should be included.in the minimal set of attributes
>>which CA software would be expected to handed when issuing 
>>certificates, and relying party software should be able to display, IMHO.
>
>X.520 defines street address as follows:
>
> streetAddress ATTRIBUTE ::= {
> WITH SYNTAX DirectoryString {ub-street-address}
> EQUALITY MATCHING RULE caseIgnoreMatch
> SUBSTRINGS MATCHING RULE caseIgnoreSubstringsMatch
> ID id-at-streetAddress }
>
>I do not think that X.500 generally includes this as a potential distinguished
>name component.  However, if many people see a need, then we should look at
>it.
>
>>(4) And finally, I have to object on prinicple to including support for
>>KEA at this late date. It has only been declassified a very short time, 
>>I daresay very few of us have even read it in any detail, and there 
>>has not been the time for detailed scrutiny that ought to be provided a
>>new algorithm, regardless of its origins.  Remember, Clipper came from
>>the same group, but was later found to have significant protocol flaws.
>>with respect to what it was attempting to do.  That's why we have 
>>peer reviews.
>
>The KEA definition is not new.  It was in a separate document because we were
>told that the standards track document could only reference publicly available
>algorithms.  KEA is now publicly available.  I do not want to turn this thread
>into a discussion of KEA.
>
>PKIX Part 1 simply states the algorithm identifier and parameter syntax public
>keys that appear in certificates.  There is a large community of US
>Governement
>users that will have KEA public keys in their key management certificates.
>Now
>that KEA is publicly available, why not include the algorithm identifiers and
>parameter syntax in PKIX Part 1?  I think that making this information widely
>available is a good thing to do.
>
>Russ 

Date: Tue, 30 Jun 1998 10:49:01 -0400
To: "Bob Jueneman" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Proposed Resolution of Comments (LONG!)
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Bob:

>(1) Could you explain the motivation for including the 4-bit identifier in 
>the keyIdentifier?  Since it hasn't even been defined yet, we 
>clearly aren't using it. And we had a hard enough time getting 
>just the Netscape and IE browsers to accept the same
>kind of certificates that I would be very reluctant to change 
>anything at this point.
>
>But perhaps more to the point, does it matter a whit to anyone that is 
>processing a certificate what particular algorithm was used to 
>generate a key ID, or why?  Suppose I want to include 
>some other information, such as the identity of the server on 
>which the key was created, or a customer ID, etc., etc?  
>Why does this matter to anyone's software other than the CA's?
>
>So long as the keyID is one-to-one with a public key (which is 
>what I believe the underlying requirement to be, what difference 
>does it make how it is encoded (at least within reason)?

This has been answered before.  Here it is again.  The key identifier was
selected to align with documents from US Government, ANSI X9, and Draft ISO
TC68.  The four-bit prefix permits the definition of other schemes.  However,
clients don't care since they simply do exact match comparisons.

>(2) On the issue of the proposed schema for DN components, I agree with 
>those that have said that decomposing and DNS name is mostly 
>a waste of time, and I doubt the efficacy of using name subordination 
>on those fields, but I don't feel terribly strongly on the subject.

There are some people using DN= as a component of a distinguished name.  I
have
no problem adding this to the PKIX list.

>(3) On the other hand I believe that not including support for the 
>residentialPerson type of user is unacceptable.  Not all applications 
>are going to involve e-mail, and a street address is a pretty 
>fundamental construct for most business and social usage.
>
>Why would you even care what country someone lived in 
>(other than mere curiosity), much less locality or state, if you 
>couldn't refer to the individual's (or organization's)
>physcial delivery address?  It is necessary for disambiguating 
>the name, in general, in addition to its other uses.
>
>StreetAddress should be included.in the minimal set of attributes
>which CA software would be expected to handed when issuing 
>certificates, and relying party software should be able to display, IMHO.

X.520 defines street address as follows:

 streetAddress ATTRIBUTE ::= {
 WITH SYNTAX DirectoryString {ub-street-address}
 EQUALITY MATCHING RULE caseIgnoreMatch
 SUBSTRINGS MATCHING RULE caseIgnoreSubstringsMatch
 ID id-at-streetAddress }

I do not think that X.500 generally includes this as a potential distinguished
name component.  However, if many people see a need, then we should look at
it.

>(4) And finally, I have to object on prinicple to including support for
>KEA at this late date. It has only been declassified a very short time, 
>I daresay very few of us have even read it in any detail, and there 
>has not been the time for detailed scrutiny that ought to be provided a
>new algorithm, regardless of its origins.  Remember, Clipper came from
>the same group, but was later found to have significant protocol flaws.
>with respect to what it was attempting to do.  That's why we have 
>peer reviews.

The KEA definition is not new.  It was in a separate document because we were
told that the standards track document could only reference publicly available
algorithms.  KEA is now publicly available.  I do not want to turn this thread
into a discussion of KEA.

PKIX Part 1 simply states the algorithm identifier and parameter syntax public
keys that appear in certificates.  There is a large community of US
Governement
users that will have KEA public keys in their key management certificates.
Now
that KEA is publicly available, why not include the algorithm identifiers and
parameter syntax in PKIX Part 1?  I think that making this information widely
available is a good thing to do.

Russ 

Date: Tue, 30 Jun 1998 14:57:42 -0700
To: "Arsenault, Al W." <[email-masked]>, "[email-masked]" <[email-masked]>
From: Michael Myers <[email-masked]>
Subject: Re: Comments on OCSP draft
Cc: "Arsenault, Al W." <[email-masked]>
Sender: [email-masked]

Al,

Good to hear from you, and thanks much for the detailed read.

At 12:02 PM 6/30/98 -0400, Arsenault, Al W. wrote:
>
>(Apologies if any of these are outdated; I've been wrapped up with other
>things for a while and am just catching up to PKIX, etc.)
>
>A few semi-random comments on the June 1998 OCSP draft
>(draft-ietf-pkix-ocsp-04.txt):
>
>1.  To support words Dave Solo has often spoken, the purpose of this
>protocol can probably be made more clear by inserting between the first
>and second paragraphs of section 2:
>
>	"This protocol serves to provide as current an answer as possible to
>the question, 'if I looked at the current CRL right now, would this
>certificate be on it?'
>It should be noted, however, that there are other
>questions that the application will have to provide answers to in
>deciding whether or not to accept a certificate, such as 'Has this
>certificate expired?', 'Is this certificate correctly signed?', etc.
>Providing this information is beyond the scope of OCSP."

Section 2.2 already states that:

"A notRevoked state by an OCSP responder DOES NOT absolve the application
of the responsibility of checking that the certificate is in its validity
period and has been correctly signed."

>
>2.  Section 2.2, "A definitive response message is composed of:..." -
>the first bullet says "version of the response".  Shouldn't this really
>be "version of OCSP?"  As worded now, it looks like the responder could
>put out something like "answer, version 1: revoked"; "answer, version 2:
>unknown", "answer, version 3:  revoked", etc.
>

Request and response versioning is purposefully decoupled.  There are no
plans to change anything, but this will enable downline flexibility should
there be a need to do so.

Implementations SHOULD return the same semantic content regardless of
response syntax version.

>3.  Section 2.3:  Will one or more of the authors please enlighten me as
>to the usefulness of the error type "internalError"?  In what case does
>this provide more useful information to the client than the response
>"unknown"?  I'm generally not a big fan of having a server send error
>messages back to the client that the client can't do anything about,
>anyway.  Certainly, the responder's System Administrator should be
>notified of the internal error, and possibly also a CA or two, but it
>seems to me that if a responder is working well enough to determine that
>it can't make a decision, it should just reply with "unknown".

The general notion was that the following set likely is not exhaustive of
all possible exception conditions:

- malformedRequest
- tryLater
- certRequired
- sigRequired

The problem is that many errors are implementation-specific.  Depending on
design, one could experience connectivity problems between a frontend
server and a backend database, somebody misconfigured the OCSP server and
the "signer" process died although the "receiver", "lookup" and "send"
processes are running, somebody pulled the card out of the reader, etc.

We didn't want to sign these responses (in the last case we might not be
able to), as implied by use of the "unknown" value of OCSPResponse, since
the response may differ in the absence of such an error.  Yet we wanted to
provide some conclusion to the protocol so that blocking clients wouldn't
block indefinitely.

>4.  Section 3.2:  you probably should specify that it's a
>"malformedRequest" error message.  (I know, I'm being somewhat retentive
>here, but let's be clear where we can.)

Yes.

>
>5.  Section 4.1, TBSRequest definition:  again, to what is this
>"version" referring?  If it's to "OCSP, version1", then it's fine - you
>should just say that.  If it means version of something else, then
>please clarify.

See prior response re: versioning.

>
>6.  Section 4.2.1 and 4.4.3 both say "OCSP responders SHALL be capable
>of recognizing and responding to the id-pkix-ocsp-basic response type."
>This wording seems wrong - I think it should be "OCSP responders SHALL
>be capable of recognizing requests and responding with the
>id-pkix-ocsp-basic response type."

Agreed.

>
>7.  Section 4.2.2.2, Time:  The fourth sentence seems to be wrong.  It
>says "Responses whose thisUpdate time is earlier than the local system
>time SHOULD be considered unreliable."  Those responses are generally
>reliable, it's when the thisUpdate time is LATER than the local system
>time that something may be wrong.  

Agreed.  Good catch.

>
>8.  Section 4.2.2.3.1:  It seems to me that allowing a CA to prevent a
>client from checking the validity of an Authorized Responder's
>certificate is wrong and should be dropped from the spec.  First of all,
>there doesn't seem to me to be any purpose for the CA to select this
>option.  If the check is unnecessary, then the clients can be told that
>their local policy can be set to not check - thus, the current third
>choice adequately covers the situation.  Second, if the client WANTS to
>make this check, it doesn't seem to me correct to allow the CA to tell
>it not to check.

On a personal note, I agree.  The prefatory note to this section is mine.
So there's my position.

As the lead instigator/editor of this thing though (it looked so simple 1
1/2 years ago!), I'm looking for the group's consensus on this point.  I
would note that this is an optional mechanism.  PKI designers are free to
choose whether or not to include this value in the certificate of an
authorized responder.

>
>9.  Section 5, fourth paragraph, last sentence:  insert "with" between
>"costs associated" and "its successful execution."

OK.

>
>				Al Arsenault
>
>-  speaking only for myself.  My views do not necessarily represent
>those of my employer.

Mike

Date: Tue, 30 Jun 1998 10:56:40 -0700
From: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
To: "Arsenault, Al W." <[email-masked]>
CC: "[email-masked]" <[email-masked]>, "Arsenault, Al W." <[email-masked]>
Subject: Re: Comments on OCSP draft
Sender: [email-masked]

Hi Al,
    Great comments!!! Thanks for the great review.

Only have a response to your 8th point:

> 8.  Section 4.2.2.3.1:  It seems to me that allowing a CA to prevent a
> client from checking the validity of an Authorized Responder's
> certificate is wrong and should be dropped from the spec.  First of all,
> there doesn't seem to me to be any purpose for the CA to select this
> option.  If the check is unnecessary, then the clients can be told that
> their local policy can be set to not check - thus, the current third
> choice adequately covers the situation.  Second, if the client WANTS to
> make this check, it doesn't seem to me correct to allow the CA to tell
> it not to check.

The issue here is that a CA designates another entity to issue OCSP
responses for it - for example, if the CA wants to keep its private
key off line. In this case, it might not provide relying parties
with any way of checking the designated responder's certificate
for revocation and be willing to accept the consequences of the
responder's private key being compromised (just as it already accepts
the consequences of its own private key being compromised).

The ability to issue a certificate with a "doesn't need to be
checked for revocation" extension, is the way for the CA
to "tell the clients not to check" the responder's cert for revocation.
We are trying to address the situation where a CA doesn't have full
control over the software running on every client's machine and no easy
way of setting the security policy on every client machine,
but still wants to tell the client it is okay
not to check the responder's cert for revocation (note: it should
still be checked for expiration).

If a client still WANTS to make the check, sure, nobody can stop the
client from doing so.

Regards,
Ambarish

-- 
---------------------------------------------------------------------
Ambarish Malpani
Architect					       (650) 849-9880
ValiCert, Inc.				        [email-masked]
3160 W. Bayshore Road		              http://www.valicert.com
Palo Alto, CA 94303

From: Brian Korver <[email-masked]>
Subject: Re: PKIX-1 - use of UTF8
To: [email-masked] (Chris Newman)
Date: Tue, 30 Jun 1998 10:03:34 -0700 (PDT)
Cc: [email-masked]
Sender: [email-masked]

Chris,

Did the definition of UNICODE change (with v2.0)?  I seem to remember
UNICODE being defined as approx. 2^16 characters encoded in 2 bytes.
When I see "supports UNICODE" being used, I normally assume that it's
this definition.  The documents I've seen that define BMPString also
use this definition.

However, I understand that the UNICODE standard also allows for the
use of UTF-16 encoding, which allows for the encoding of over a million
characters.  See:

    http://www.unicode.org/unicode/standard/principles.html

brian
[email-masked]

Chris Newman writes:
> 
> There seems to be some confusion surrounding BMPString, UTF-8 and Unicode.
> 
> BMPString is purportedly the 16-bit subset of Unicode (full Unicode is
> represented in UTF-16).  It's less expressive than UTF-8.  Technically, a
> Unicode to BMPString converter would lose data.  This could become a
> serious issue when less frequently used CJK characters are assigned in
> plane 1 of Unicode (outside the BMP). 
> 
> The conversion between Unicode (UTF-16) and UTF-8 is simple, and free code
> is available at <ftp://ftp.unicode.org/Public/PROGRAMS/CVTUTF/>.  While
> UTF-8 is more expressive than Unicode, it's unlikely that codepoints will
> be assigned outside the overlap between the two (on the flip side, there
> are already numerous proposals to assign codepoints outside the BMP).
> 
> I will also point out that UTF-8 support in LDAPString DNs is a mandatory
> part of the LDAPv3 spec.  Was there some other directory you were planning
> on storing certificates in? 
> 
> So I question why people are rushing towards BMPString when it's different
> from the predominant future directory technology and less expressive than
> the IETF preferred charset. 
> 
> 		- Chris

Date: Tue, 30 Jun 1998 09:57:34 -0700
To: <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Comments on OCSP draft
Sender: [email-masked]

At 12:02 PM 6/30/98 -0400, Arsenault, Al W. wrote:
>	"This protocol serves to provide as current an answer as possible to
>the question, 'if I looked at the current CRL right now, would this
>certificate be on it?'

I would strongly object to this kind of language in the document. OCSP
tells you the latest status of a certificate, not the status of the
certificate in the latest CRL. There is a huge difference. If a CA issues a
CRL once a week and revokes a cert on the first day of that week, I expect
a "revoked" response from an OCSP request.

>2.  Section 2.2, "A definitive response message is composed of:..." -
>the first bullet says "version of the response".  Shouldn't this really
>be "version of OCSP?"  As worded now, it looks like the responder could
>put out something like "answer, version 1: revoked"; "answer, version 2:
>unknown", "answer, version 3:  revoked", etc.

You are right that the wording needs to be changed, but I would propose
"version of OCSPResponse" because there is no version number for all of
OCSP, and the version of the OCSPRequest might be different.

Please note that there is a new draft available, and some of your comments
had been addressed in it (but others had not). The structure changed a
great deal, so the section numbering was different.

--Paul Hoffman, Director
--Internet Mail Consortium

From: "Arsenault, Al W." <[email-masked]>
To: "[email-masked]" <[email-masked]>
Cc: "Arsenault, Al W." <[email-masked]>
Subject: Comments on OCSP draft
Date: Tue, 30 Jun 1998 12:02:58 -0400
Sender: [email-masked]

(Apologies if any of these are outdated; I've been wrapped up with other
things for a while and am just catching up to PKIX, etc.)

A few semi-random comments on the June 1998 OCSP draft
(draft-ietf-pkix-ocsp-04.txt):

1.  To support words Dave Solo has often spoken, the purpose of this
protocol can probably be made more clear by inserting between the first
and second paragraphs of section 2:

	"This protocol serves to provide as current an answer as possible to
the question, 'if I looked at the current CRL right now, would this
certificate be on it?' It should be noted, however, that there are other
questions that the application will have to provide answers to in
deciding whether or not to accept a certificate, such as 'Has this
certificate expired?', 'Is this certificate correctly signed?', etc.
Providing this information is beyond the scope of OCSP."

2.  Section 2.2, "A definitive response message is composed of:..." -
the first bullet says "version of the response".  Shouldn't this really
be "version of OCSP?"  As worded now, it looks like the responder could
put out something like "answer, version 1: revoked"; "answer, version 2:
unknown", "answer, version 3:  revoked", etc.

3.  Section 2.3:  Will one or more of the authors please enlighten me as
to the usefulness of the error type "internalError"?  In what case does
this provide more useful information to the client than the response
"unknown"?  I'm generally not a big fan of having a server send error
messages back to the client that the client can't do anything about,
anyway.  Certainly, the responder's System Administrator should be
notified of the internal error, and possibly also a CA or two, but it
seems to me that if a responder is working well enough to determine that
it can't make a decision, it should just reply with "unknown".

4.  Section 3.2:  you probably should specify that it's a
"malformedRequest" error message.  (I know, I'm being somewhat retentive
here, but let's be clear where we can.)

5.  Section 4.1, TBSRequest definition:  again, to what is this
"version" referring?  If it's to "OCSP, version1", then it's fine - you
should just say that.  If it means version of something else, then
please clarify.

6.  Section 4.2.1 and 4.4.3 both say "OCSP responders SHALL be capable
of recognizing and responding to the id-pkix-ocsp-basic response type."
This wording seems wrong - I think it should be "OCSP responders SHALL
be capable of recognizing requests and responding with the
id-pkix-ocsp-basic response type."

7.  Section 4.2.2.2, Time:  The fourth sentence seems to be wrong.  It
says "Responses whose thisUpdate time is earlier than the local system
time SHOULD be considered unreliable."  Those responses are generally
reliable, it's when the thisUpdate time is LATER than the local system
time that something may be wrong.  

8.  Section 4.2.2.3.1:  It seems to me that allowing a CA to prevent a
client from checking the validity of an Authorized Responder's
certificate is wrong and should be dropped from the spec.  First of all,
there doesn't seem to me to be any purpose for the CA to select this
option.  If the check is unnecessary, then the clients can be told that
their local policy can be set to not check - thus, the current third
choice adequately covers the situation.  Second, if the client WANTS to
make this check, it doesn't seem to me correct to allow the CA to tell
it not to check.

9.  Section 5, fourth paragraph, last sentence:  insert "with" between
"costs associated" and "its successful execution."

				Al Arsenault

-  speaking only for myself.  My views do not necessarily represent
those of my employer.

>

Date: Tue, 30 Jun 1998 08:46:41 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Re: KeyIdentifier Algorithm
Sender: [email-masked]

After talking to Mike off-line, I now understand the rationale better. 
I was only considering the case where the CA had created the certificate 
containing the key Id, and coudln't understand why the algorithm would 
matter.

The key IDs we are creating will be 160 bit SHA-1, but without any tag or 
prefix.  I would agree with Tolga Acar, that if knowledge of the algorithm is
important, that perhaps a full fledged OID would be the way to go.

But I hope, at least, that the our present scheme won't cause any 
interoperability problems, as we don't have time to re-do the testing with 
the various browsers. This scheme at least works with MSIE and Netscape.

Bob

>>> Michael Myers <[email-masked]> 06/29 3:13 PM >>>
Bob,

At 01:21 PM 6/29/98 -0600, Bob Jueneman wrote:
> . . .
>But perhaps more to the point, does it matter a whit to anyone that is 
>processing a certificate what particular algorithm was used to 
>generate a key ID, or why?

I believe it matters for interoperability planning.

Application developers wanting to use AKI-SKI mapping as a means around
naming issues and also planning a wide interoperability base might need to
consider the case where a CA certificate does not have a value for
subjectKeyIdentifier but for some reason the end-entity certificate has a
value for AuthorityKeyIdentifier.  In this case it's necessary to implement
the algorithm in the application to produce a value for
SubjectKeyIdentifier as input to one's find-ca-cert-by-ski() function
(which in turn references a table mapping SKI to the index of a CA cert in
a local cert store.)

There is also the case of cross-certification.  Assume a CA issuing an
end-entity certificate (CA1) uses a different keyID algorithm than that
used by the CA that cross-certifies that CA's public key (CA2).

A value for AKI in those end-entity certificates may not map to the
cross-certificate if its SKI value differs.  True, CA2 could just copy out
the value of SKI in CA1's cert if it's there, but the policies governing
CA2 may mandate a keyID value generation algorithm different from that of CA1.

Mike

Date: Tue, 30 Jun 1998 07:46:30 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: Re: PKIX-1 - use of UTF8
To: Bob Jueneman <[email-masked]>
Cc: [email-masked]
Originator-Info: login-id=chris; server=THOR.INNOSOFT.COM
Sender: [email-masked]

On Mon, 29 Jun 1998, Bob Jueneman wrote:
> We have to support at least 12 languages, certainly including Japanese and Chinese.
> I don't know about Korean and Arabic.  All of the Novell software is Unicode based,
> but precisely how that translates to BMPString I confess I don't exactly know.

You can perform a lossy conversion from Unicode to BMPString, or a
lossless conversion to UTF-8.  UTF-8 is just an encoding of Unicode.
BMPString is a subset of Unicode (which might exclude characters important
to CJK customers in the future).

> But the most rpessing problem from our perspective is that we will have to support
> UTF-8 in not only our certificate processing software, but in SSL, and an in our NDS 
> directory, and in the administrative tools, etc.  Right now, I don't believe that we have
> the UTF-8 to Unicode routines or vice versa, so it will be a while before we could 
> do that.

If you're doing LDAPv3, you already support UTF-8 in the directory.
Unicode has UTF-8 <-> Unicode (UTF-16) routines:
    <ftp://ftp.unicode.org/Public/PROGRAMS/CVTUTF/>

> But unfortunately, I don't think we are in a position to tell our customers, almost 
> 50% of which are outside the US, to simply speak English.  So we've got
> to do something, and that something starts in about three weeks. BMPString
> is our only option, as far as I know.

Read RFC 2251, the LDAPv3 standard.

		- Chris

Date: Tue, 30 Jun 1998 07:40:43 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: Re: PKIX-1 - use of UTF8
To: [email-masked]
Originator-Info: login-id=chris; server=THOR.INNOSOFT.COM
Sender: [email-masked]

There seems to be some confusion surrounding BMPString, UTF-8 and Unicode.

BMPString is purportedly the 16-bit subset of Unicode (full Unicode is
represented in UTF-16).  It's less expressive than UTF-8.  Technically, a
Unicode to BMPString converter would lose data.  This could become a
serious issue when less frequently used CJK characters are assigned in
plane 1 of Unicode (outside the BMP). 

The conversion between Unicode (UTF-16) and UTF-8 is simple, and free code
is available at <ftp://ftp.unicode.org/Public/PROGRAMS/CVTUTF/>.  While
UTF-8 is more expressive than Unicode, it's unlikely that codepoints will
be assigned outside the overlap between the two (on the flip side, there
are already numerous proposals to assign codepoints outside the BMP).

I will also point out that UTF-8 support in LDAPString DNs is a mandatory
part of the LDAPv3 spec.  Was there some other directory you were planning
on storing certificates in? 

So I question why people are rushing towards BMPString when it's different
from the predominant future directory technology and less expressive than
the IETF preferred charset. 

		- Chris

From: Brian LaMacchia <[email-masked]>
To: "'Brian Korver'" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: PKIX-1 - use of UTF8
Date: Tue, 30 Jun 1998 01:13:24 -0700
Sender: [email-masked]

To provide another datapoint concerning BMPString support, we introduced
client-side support for BMPString-encoded DirectoryString components in IE
4.01.  All client-side code released since then (including IE 4.01 SP1,
Windows 98 and the IE 5.0 Developer Preview) uses BMPString encodings for
strings that contain characters not in the PrintableString character set.
(Internally, everything is kept in Unicode.)  MS Certificate Server follows
the same encoding rules for certs it issues.   

					--bal

-----Original Message-----
From: Brian Korver [mailto:[email-masked]]
Sent: Monday, June 29, 1998 4:12 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: Re: PKIX-1 - use of UTF8

Bob,

I'm certainly not telling anyone "simply speak English", or suggesting
that anyone else do that.  Maybe I haven't been clear.

Let me restate my point:  I don't know that implementations that support
BMPString are any more common than implementations that support UTF8String.
(by "support", I mean that they do not merely treat DNs (et al.) as
opaque data.)  

BMPString is a recent addition to DirectoryString.  I'd like to know
if there are any non-SET implementations that actually support
BMPString (again, don't confuse "support BMPString" with "support for
UNICODE").  I believe there aren't many (any?) non-SET implementations that
actually support BMPString, but please correct me if I'm wrong.

If support for BMPString is widespread, then backwards compatibility is
an issue.  If support for BMPString is not widespread, then backwards
compatibility may not be an issue.

brian
[email-masked]

From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: subjectAltName example differences
Date: Mon, 29 Jun 1998 22:06:49 -0700
Sender: [email-masked]

Section D.3 has an example RSA certificate with a subjectAltName
extension:

04 36
   30 34
      rfc822name
      a1 1a
         IA5String "[email-masked]"
         16 18 65 73 63 65 72 74 2d 75 70 63 40 65 73
         63 65 72 74 2e 75 70 63 2e 65 73

Am I wrong, or is the IA5String EXPLICITly tagged in this example?  a1
is the constructed(?!?), context-specific tag 1, 1a bytes long, 16 is
the UNIVERSAL tag for IA5String, 18 is the length, and 65 ... 73 is the
IA5String content "[email-masked]"

Section D.2.1 has an example of a DSA certificate with a subjectAltName
extension:

0617 04 12         18: . . . . . OCTET STRING
                     : 30 10 81 0e 77 70 6f 6c 6b 40 6e 69 73 74 2e 67
                     : 6f 76

Which can be rewritten to look like section D.3 as follows:

04 12
   30 10
      rfc822Name
      81 0e
      77 70 6f 6c 6b 40 6e 69 73 74 2e 67 6f 76

Where 81 is the non-constructed, context-specific tag 1, 0e bytes long,
and the implicitly tagged IA5String content is 77 ... 76 which is
"[email-masked]"

Is my mind gone, or is the RSA example incorrect (it should be using
IMPLICIT tagging)?

My apologies if this has been covered.

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Proposed Resolution of Comments (LONG!)
Reply-To: [email-masked]
Date: Tue, 30 Jun 1998 15:43:36 (NZST)
Sender: [email-masked]

>(1) Could you explain the motivation for including the 4-bit identifier in the
>keyIdentifier?  Since it hasn't even been defined yet, we clearly aren't using
>it. And we had a hard enough time getting just the Netscape and IE browsers to
>accept the same kind of certificates that I would be very reluctant to change
>anything at this point.
>
>But perhaps more to the point, does it matter a whit to anyone that is
>processing a certificate what particular algorithm was used to generate a key
>ID, or why?  Suppose I want to include some other information, such as the
>identity of the server on which the key was created, or a customer ID, etc.,
>etc? Why does this matter to anyone's software other than the CA's?
 
If people really do require a keyID to be a 160-bit string, perhaps the profile
could recommend something like:
 
  if keyID != 160 bits
    keyID = SHA1-hash( keyID );
 
This way even if a cert contains a keyID as defined by whatever other standard
people are trying to comply with, you can still construct from it a meta-keyID
which complies with PKIX, which allows chaining from PKIX-compliant
issuer/subject and ISO-compliant subject/issuer.
 
[How tolerant are the other standards/profiles about keyID's?  Will the ISO
 police come after you if they see a 160-bit keyID?]
 
>(4) And finally, I have to object on prinicple to including support for KEA at
>this late date. It has only been declassified a very short time, I daresay
>very few of us have even read it in any detail, and there has not been the
>time for detailed scrutiny that ought to be provided a new algorithm,
>regardless of its origins.  Remember, Clipper came from the same group, but
>was later found to have significant protocol flaws. with respect to what it
>was attempting to do. That's why we have peer reviews.
 
Just a random data point, I'm not aware of anyone who's managed to implement
KEA in a manner which produces results consistent with the supplied test
vectors.  Although I don't have any objections to including KEA, it looks like
the currently published information on it may contain errors.
 
Peter.

From: [email-masked]
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Subject: RE: PKIX-1 - use of UTF8
Date: Tue, 30 Jun 1998 11:15:36 +1000
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------ =_NextPart_001_01BDA3C4.98E93450
Content-Type: text/plain

-----Original Message-----
From: Brian Korver [mailto:[email-masked]]
Sent: Tuesday, 30 June 1998 9:12
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: Re: PKIX-1 - use of UTF8

>snip

Bob,

I'm certainly not telling anyone "simply speak English", or suggesting
that anyone else do that.  Maybe I haven't been clear.

Let me restate my point:  I don't know that implementations that support
BMPString are any more common than implementations that support
UTF8String.
(by "support", I mean that they do not merely treat DNs (et al.) as
opaque data.)  

BMPString is a recent addition to DirectoryString.  I'd like to know
if there are any non-SET implementations that actually support
BMPString (again, don't confuse "support BMPString" with "support for
UNICODE").  I believe there aren't many (any?) non-SET implementations
that
actually support BMPString, but please correct me if I'm wrong.

If support for BMPString is widespread, then backwards compatibility is
an issue.  If support for BMPString is not widespread, then backwards
compatibility may not be an issue.

cm> Agreed, Perhaps the question should be, if UTF8 was implemented
today, is there any existing application that would break ?. If not then
UTF8, seems a better choice for implementors due to its evolutionary
approach.

brian
[email-masked]

------ =_NextPart_001_01BDA3C4.98E93450
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.1960.3">
<TITLE>RE: PKIX-1 - use of UTF8</TITLE>
</HEAD>
<BODY>
<BR>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Brian Korver [<A =
HREF=3D"mailto:[email-masked]" =
TARGET=3D"_blank">mailto:[email-masked]</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, 30 June 1998 9:12</FONT>
<BR><FONT SIZE=3D2>To: [email-masked]</FONT>
<BR><FONT SIZE=3D2>Cc: [email-masked]; [email-masked]; =
[email-masked];</FONT>
<BR><FONT SIZE=3D2>[email-masked]</FONT>
<BR><FONT SIZE=3D2>Subject: Re: PKIX-1 - use of UTF8</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt;snip</FONT>
</P>

<P><FONT SIZE=3D2>Bob,</FONT>
</P>

<P><FONT SIZE=3D2>I'm certainly not telling anyone &quot;simply speak =
English&quot;, or suggesting</FONT>
<BR><FONT SIZE=3D2>that anyone else do that.&nbsp; Maybe I haven't been =
clear.</FONT>
</P>

<P><FONT SIZE=3D2>Let me restate my point:&nbsp; I don't know that =
implementations that support</FONT>
<BR><FONT SIZE=3D2>BMPString are any more common than implementations =
that support UTF8String.</FONT>
<BR><FONT SIZE=3D2>(by &quot;support&quot;, I mean that they do not =
merely treat DNs (et al.) as</FONT>
<BR><FONT SIZE=3D2>opaque data.)&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2>BMPString is a recent addition to =
DirectoryString.&nbsp; I'd like to know</FONT>
<BR><FONT SIZE=3D2>if there are any non-SET implementations that =
actually support</FONT>
<BR><FONT SIZE=3D2>BMPString (again, don't confuse &quot;support =
BMPString&quot; with &quot;support for</FONT>
<BR><FONT SIZE=3D2>UNICODE&quot;).&nbsp; I believe there aren't many =
(any?) non-SET implementations that</FONT>
<BR><FONT SIZE=3D2>actually support BMPString, but please correct me if =
I'm wrong.</FONT>
</P>

<P><FONT SIZE=3D2>If support for BMPString is widespread, then =
backwards compatibility is</FONT>
<BR><FONT SIZE=3D2>an issue.&nbsp; If support for BMPString is not =
widespread, then backwards</FONT>
<BR><FONT SIZE=3D2>compatibility may not be an issue.</FONT>
</P>

<P><FONT SIZE=3D2>cm&gt; Agreed, Perhaps the question should be, if =
UTF8 was implemented today, is there any existing application that =
would break ?. If not then UTF8, seems a better choice for implementors =
due to its evolutionary approach.</FONT></P>
<BR>
<BR>

<P><FONT SIZE=3D2>brian</FONT>
<BR><FONT SIZE=3D2>[email-masked]</FONT>
</P>

</BODY>
</HTML>
------ =_NextPart_001_01BDA3C4.98E93450--

From: Brian Korver <[email-masked]>
Subject: Re: PKIX-1 - use of UTF8
To: [email-masked] (Bob Jueneman)
Date: Mon, 29 Jun 1998 16:11:51 -0700 (PDT)
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

Bob Jueneman writes:
[snip]
> We have to support at least 12 languages, certainly including Japanese and =
> Chinese.
> I don't know about Korean and Arabic.  All of the Novell software is =
> Unicode based,
> but precisely how that translates to BMPString I confess I don't exactly =
> know.
> 
> I'm rhight now trying to make sure that we have actually generated DNs in =
> Japanese
> (either katakana or kanji, I don't know which), and Chinese and other =
> languages to
> the extent possible.  Exactly what will happen when we run those certificat=
> es through
> the various browsers I don't know yet.
> 
> I assume that VeriSign Japan has faces some of these problme, although it =
> may be=20
> that they are only processing printableString.
> 
> But the most rpessing problem from our perspective is that we will have to =
> support
> UTF-8 in not only our certificate processing software, but in SSL, and an =
> in our NDS=20
> directory, and in the administrative tools, etc.  Right now, I don't =
> believe that we have
> the UTF-8 to Unicode routines or vice versa, so it will be a while before =
> we could=20
> do that.
> 
> But unfortunately, I don't think we are in a position to tell our =
> customers, almost=20
> 50% of which are outside the US, to simply speak English.  So we've got
> to do something, and that something starts in about three weeks. BMPString
> is our only option, as far as I know.
> 
> Bob

Bob,

I'm certainly not telling anyone "simply speak English", or suggesting
that anyone else do that.  Maybe I haven't been clear.

Let me restate my point:  I don't know that implementations that support
BMPString are any more common than implementations that support UTF8String.
(by "support", I mean that they do not merely treat DNs (et al.) as
opaque data.)  

BMPString is a recent addition to DirectoryString.  I'd like to know
if there are any non-SET implementations that actually support
BMPString (again, don't confuse "support BMPString" with "support for
UNICODE").  I believe there aren't many (any?) non-SET implementations that
actually support BMPString, but please correct me if I'm wrong.

If support for BMPString is widespread, then backwards compatibility is
an issue.  If support for BMPString is not widespread, then backwards
compatibility may not be an issue.

brian
[email-masked]

Date: Mon, 29 Jun 1998 17:03:53 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: PKIX-1 - use of UTF8
Sender: [email-masked]

>Bob,
>
>I agree with everything you say.  Perhaps you have more information
>than I do.
>
>It was my impression (please correct me if I'm wrong) that BMPString
>was not yet widely deployed for any of the types of implementations
>you list.  SET uses BMPString, but I thought it was an anomaly.
>Also, I don't interpret "supports UNICODE" and "is `BMPString aware'"
>as equivalent.
>
>Anyhow, the point I was trying to make was that _if_ BMPString isn't
>widely deployed, then "backward compatibility" with BMPString is a
>non-issue and thus the usage rules can be simplified.   Maybe that's
>too much wishful thinking.  ;)
>
>brian

We have to support at least 12 languages, certainly including Japanese and Chinese.
I don't know about Korean and Arabic.  All of the Novell software is Unicode based,
but precisely how that translates to BMPString I confess I don't exactly know.

I'm rhight now trying to make sure that we have actually generated DNs in Japanese
(either katakana or kanji, I don't know which), and Chinese and other languages to
the extent possible.  Exactly what will happen when we run those certificates through
the various browsers I don't know yet.

I assume that VeriSign Japan has faces some of these problme, although it may be 
that they are only processing printableString.

But the most rpessing problem from our perspective is that we will have to support
UTF-8 in not only our certificate processing software, but in SSL, and an in our NDS 
directory, and in the administrative tools, etc.  Right now, I don't believe that we have
the UTF-8 to Unicode routines or vice versa, so it will be a while before we could 
do that.

But unfortunately, I don't think we are in a position to tell our customers, almost 
50% of which are outside the US, to simply speak English.  So we've got
to do something, and that something starts in about three weeks. BMPString
is our only option, as far as I know.

Bob

Date: Mon, 29 Jun 1998 15:58:49 -0600
From: "Tolga Acar" <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: KeyIdentifier Algorithm
Sender: [email-masked]

--Tolga

>>> Michael Myers <[email-masked]> 6/29/98 15:13:35 >>> wrote:
[snip]

>Application developers wanting to use AKI-SKI mapping as a means around
>naming issues and also planning a wide interoperability base might need to
>consider the case where a CA certificate does not have a value for
>subjectKeyIdentifier but for some reason the end-entity certificate has a
>value for AuthorityKeyIdentifier.  In this case it's necessary to implement
>the algorithm in the application to produce a value for
>SubjectKeyIdentifier as input to one's find-ca-cert-by-ski() function
>(which in turn references a table mapping SKI to the index of a CA cert in
>a local cert store.)

Then, if the concern is ineroperability, there already is a interoperability problem with the existing V3 certificates.

If the idea is correctly chaining the certificates to their issuers, then such an implicit and to-be-changed definiton of key identifier doesn't seem to a good solution, since there are applications running, and applications being implemented as of today.

If such a definition of Key-ID computation is really necessary, then i'd suggest adding an OID to the key identifier as done with the SIGNED macro. However, this would either require e new extension id (ce-id) or an addition to the existing authorityKeyIdentifier and to the subjectKeyIdentifier SEQUENCEs (probably with another context-specific tag).
Then, the computation of the key-ID can be dynamically read from the certificate.

Date: Mon, 29 Jun 1998 14:13:35 -0700
To: "Bob Jueneman" <[email-masked]>, [email-masked], [email-masked]
From: Michael Myers <[email-masked]>
Subject: KeyIdentifier Algorithm
Sender: [email-masked]

Bob,

At 01:21 PM 6/29/98 -0600, Bob Jueneman wrote:
> . . .
>But perhaps more to the point, does it matter a whit to anyone that is 
>processing a certificate what particular algorithm was used to 
>generate a key ID, or why?

I believe it matters for interoperability planning.

Application developers wanting to use AKI-SKI mapping as a means around
naming issues and also planning a wide interoperability base might need to
consider the case where a CA certificate does not have a value for
subjectKeyIdentifier but for some reason the end-entity certificate has a
value for AuthorityKeyIdentifier.  In this case it's necessary to implement
the algorithm in the application to produce a value for
SubjectKeyIdentifier as input to one's find-ca-cert-by-ski() function
(which in turn references a table mapping SKI to the index of a CA cert in
a local cert store.)

There is also the case of cross-certification.  Assume a CA issuing an
end-entity certificate (CA1) uses a different keyID algorithm than that
used by the CA that cross-certifies that CA's public key (CA2).

A value for AKI in those end-entity certificates may not map to the
cross-certificate if its SKI value differs.  True, CA2 could just copy out
the value of SKI in CA1's cert if it's there, but the policies governing
CA2 may mandate a keyID value generation algorithm different from that of CA1.

Mike

From: Brian Korver <[email-masked]>
Subject: Re: PKIX-1 - use of UTF8
To: [email-masked] (Bob Jueneman)
Date: Mon, 29 Jun 1998 12:47:56 -0700 (PDT)
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

Bob Jueneman writes:
[snip]
> I think it is very important to differentiate as to the different types=20
> of "implementations" here.  there are at leaast three: =20
> (1) Certificate creation software,
> (2) Software which displays certificates, either to end-users or for=20
>      admninstrative purposes,
> (3) Software which has to follow certificate chains, but can do so =
> blindly,
>      one DN "blob" at a time,
> (3) Directory/repository software which has to store and retrieve the=20
>      certificates.
> 
> It has to be understood that all of these kinds of implementations will
> have to change, generally speaking, before UTF-8 can be successfully=20
> deployed.
> 
> For those applications that have to support internationalization right =
> out=20
> of the box, dropping BMPString simply isn't an option.  It is (to the best =
> of my=20
> knowledge) the only solution presently available for systems which are
> based on Unicode and are shipping today.
> 
> Clearly certificate creation software can't treat DNs as blobs, for the=20
> very essence of a certificate is to bind the public key to the user.
> If the CA can't even read the contents of the certificate, the binding=20
> isn't worth much.
> 
> Likewise, software that has to display the contents of the certificate =
> to=20
> a human consumer has to worry about the format of thge DN.  So does=20
> an application such as SSL V3 that is validating the client. Presumably=20
> it is doing so against the name that is contained in the certificate.
> 
> Also, storage and retrieval software has be be name-format aware.  =
> Directories
> and other repositories represent a large established code base that=20
> generally existed long before the emergence of X.509 certificates, and=20
> long before UTF-8.  Changes that potentially impact such database =
> structures
> involve more than just the vendors -- the users will have a substantial =
> say=20
> in how rapidly any conversion takes place.
[snip]

Bob,

I agree with everything you say.  Perhaps you have more information
than I do.

It was my impression (please correct me if I'm wrong) that BMPString
was not yet widely deployed for any of the types of implementations
you list.  SET uses BMPString, but I thought it was an anomaly.
Also, I don't interpret "supports UNICODE" and "is `BMPString aware'"
as equivalent.

Anyhow, the point I was trying to make was that _if_ BMPString isn't
widely deployed, then "backward compatibility" with BMPString is a
non-issue and thus the usage rules can be simplified.   Maybe that's
too much wishful thinking.  ;)

brian
[email-masked]

Date: Mon, 29 Jun 1998 13:42:16 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: PKIX-1 - use of UTF8
Sender: [email-masked]

Brian,
>
>>>> Brian Korver <[email-masked]> 06/28 12:25 PM >>>
>Russ Housley writes:
>> We must have a solution that permits different codesets for each attribute
>> in a name.
>
I agree with Russ, here.  We have to worry about bi- and multi-lingual 
countries, India being the outstanding example, with 14 official languages,
many of which use entirely different alphabets. but that brings up a whole 
host of additional issues that we have to address, such as whether alt 
names are "official" or "unofficial/advisory".
>> 
>> I am reluctant to support the incorrect tagging of things as T.61 that in
>> fact are not T.61.
>
The reluctance is understandable.  I even get upset at people using commonName
to means something entirely different, so I guess I agree.
>> 
>> Can folks live with the following:
>> 1.  Country must be represented in PrintableString.
>> 2.  Other name components are represented using either 2a or 2b.
>> 2a.  If can be represented at PrintableString, do so; otherwise use BMPString.
>> 2b.  Represent as UTF8String.
>> 
>> Russ

I don't see muchother choice, unfortunately.
>
>Russ,
>
>I'm only commenting on your #2, not the rest of your proposal. 
>
>BMPString is a relatively recent addition to DirectoryString and I
>don't believe it is being used much.  I would also guess that few
>implementations exist that even deal with BMPString as such (rather 
>than treating it merely as opaque data).  So if the point is to 
>transition to UTF8String gracefully, I would drop 2a.

I think it is very important to differentiate as to the different types 
of "implementations" here.  there are at leaast three:  
(1) Certificate creation software,
(2) Software which displays certificates, either to end-users or for 
     admninstrative purposes,
(3) Software which has to follow certificate chains, but can do so blindly,
     one DN "blob" at a time,
(3) Directory/repository software which has to store and retrieve the 
     certificates.

It has to be understood that all of these kinds of implementations will
have to change, generally speaking, before UTF-8 can be successfully 
deployed.

For those applications that have to support internationalization right out 
of the box, dropping BMPString simply isn't an option.  It is (to the best of my 
knowledge) the only solution presently available for systems which are
based on Unicode and are shipping today.

Clearly certificate creation software can't treat DNs as blobs, for the 
very essence of a certificate is to bind the public key to the user.
If the CA can't even read the contents of the certificate, the binding 
isn't worth much.

Likewise, software that has to display the contents of the certificate to 
a human consumer has to worry about the format of thge DN.  So does 
an application such as SSL V3 that is validating the client. Presumably 
it is doing so against the name that is contained in the certificate.

Also, storage and retrieval software has be be name-format aware.  Directories
and other repositories represent a large established code base that 
generally existed long before the emergence of X.509 certificates, and 
long before UTF-8.  Changes that potentially impact such database structures
involve more than just the vendors -- the users will have a substantial say 
in how rapidly any conversion takes place.

>
>(an extra $.02: I think DirectoryString already has too many choices)
>
>brian
>[email-masked]

I agree with you on that one. It's just too bad that we can't redefine the world 
retroactively.

Bob

Date: Mon, 29 Jun 1998 12:26:59 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Making UTF8 palatable and keeping backwards compatibility
Sender: [email-masked]

At 11:27 AM 6/29/98 -0600, Bob Jueneman wrote:
>Are you under the impression that no one is yet issuing V3 certs??
Certainly that
>is NOT the case.  We are generating a bundle of five V3 certs at the rate
of one 
>bundle every 10 seconds, with somewhere between 80,000 and 200,000 
>bundles to be generated by the end of July.

You're right here, and I made a dumb mistake in my suggestion. Please
ignore what I said on this thread, and let's just go with Tim's latest
proposal. <skulking sheepishly into the corner>

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Mon, 29 Jun 1998 13:21:57 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Proposed Resolution of Comments (LONG!)
Sender: [email-masked]

Tim, four points:

(1) Could you explain the motivation for including the 4-bit identifier in 
the keyIdentifier?  Since it hasn't even been defined yet, we 
clearly aren't using it. And we had a hard enough time getting 
just the Netscape and IE browsers to accept the same
kind of certificates that I would be very reluctant to change 
anything at this point.

But perhaps more to the point, does it matter a whit to anyone that is 
processing a certificate what particular algorithm was used to 
generate a key ID, or why?  Suppose I want to include 
some other information, such as the identity of the server on 
which the key was created, or a customer ID, etc., etc?  
Why does this matter to anyone's software other than the CA's?

So long as the keyID is one-to-one with a public key (which is 
what I believe the underlying requirement to be, what difference 
does it make how it is encoded (at least within reason)?

(2) On the issue of the proposed schema for DN components, I agree with 
those that have said that decomposing and DNS name is mostly 
a waste of time, and I doubt the efficacy of using name subordination 
on those fields, but I don't feel terribly strongly on the subject.

(3) On the other hand I believe that not including support for the 
residentialPerson type of user is unacceptable.  Not all applications 
are going to involve e-mail, and a street address is a pretty 
fundamental construct for most business and social usage.

Why would you even care what country someone lived in 
(other than mere curiosity), much less locality or state, if you 
couldn't refer to the individual's (or organization's)
physcial delivery address?  It is necessary for disambiguating 
the name, in general, in addition to its other uses.

StreetAddress should be included.in the minimal set of attributes
which CA software would be expected to handed when issuing 
certificates, and relying party software should be able to display, IMHO.

(4) And finally, I have to object on prinicple to including support for
KEA at this late date. It has only been declassified a very short time, 
I daresay very few of us have even read it in any detail, and there 
has not been the time for detailed scrutiny that ought to be provided a
new algorithm, regardless of its origins.  Remember, Clipper came from
the same group, but was later found to have significant protocol flaws.
with respect to what it was attempting to do.  That's why we have 
peer reviews.

Bob

Date: Mon, 29 Jun 1998 11:02:52 -0700
To: Irene Gassko <[email-masked]>, Mike Smith <[email-masked]>
From: Michael Myers <[email-masked]>
Subject: Re: New OCSP draft
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

Irene,

At 09:43 AM 6/29/98 -0400, Irene Gassko wrote:
. . .
>We discussed this issue with Ambarish and came to the conclusion that
>historical queries that had been mentioned on this list before can solve this
>problem. That is, the application that finds out that the CA's key is revoked
>should be able to find out if it was revoked at a certain point in the past,
>and then make its own decisions.

Most needs can be met using the revocationTime field in RevokedInfo:

CertStatus ::= CHOICE {
    notRevoked   [0] IMPLICIT NULL,
    revoked      [1] IMPLICIT RevokedInfo,
    unknown      [2] IMPLICIT UnknownInfo }

RevokedInfo ::= SEQUENCE {
    revocationTime         GeneralizedTime,
    revocationReason	[0]    EXPLICIT CRLReason OPTIONAL }

This will give applications a before/after threshold to compare against
prior status obtained on an end-entity certificate.

The suspend/reinstate and suspend/revoke scenarios require a time-based
request extension to enable indexing against a certificate's state history.

>A more complex situation can arise when the key is compromised. When
>we find out that our credit card is missing, it can mean that it was lost or
>stolen, say, during the preceding week. Usual procedure in such cases is
>to revoke it absolutely at the day it's absence was discovered and also to
>go through purchases of the preceding week one by one and cancel them
>selectively. If we want to be able to implement such mechanism for
>certificates,
>I see two possible approaches:
>
>1. To add one more attribute TimeOfPossibleCompromise

The current OCSP draft reads:

"4.4.4 Other Extensions

CRL Entry Extensions - specified in Section 5.3 of PKIX part I - are 
also supported as singleExtensions."

So I believe this case is covered by the invalidityDate CRL Entry
extension, which addresses the same need. It's an OID and a GeneralizedTime
and has the advantage in that it maps directly onto CRLs.

The only simplification possible is to put TimeOfPossibleCompromised in as
an OPTIONAL to the RevokedInfo and some tag clean up as a result:

RevokedInfo ::= SEQUENCE {
    revocationTime           [0] GeneralizedTime,
    timeOfPossibleCompromise [1] GeneralizedTime, OPTIONAL
    revocationReason         [2] EXPLICIT CRLReason OPTIONAL }

One advantage of the extension-based mechanism is that it allows us to
build a stable request/response base syntax while accomondating new and
evolving requirements.

>2. Have an index that will allow CA to find certificates it issued during
>    given time and either reissue them automatically with a new key,
>    or contact their owners before reissuing for confirmation. This
>    decision should be application dependent (e.g. for a music site
>    it probably makes sense to let unauthorized people listen to
>    their music for a while rather than make their customers unhappy, 
>    while for a military site it could the opposite situation).

This seems more like the next phase in CA compromise recovery: generate a
new key pair and resign some subset of currently valid certificates.  I
agree that there's no way to specify a single rule or principle regarding
which of the set of questionable certificates to resign.  This is very much
a practices issue.

Mike

Date: Mon, 29 Jun 1998 11:27:44 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Making UTF8 palatable and keeping backwards compatibility
Sender: [email-masked]

Paul,

I must be missing something. I reread Chris Newman's posting of 6/22, 
but I don't see anything in his note that would substantiate your position.

Why is it that you believe that there is no backward-compatibility issue
with respect to version 3 certificates?

Are you under the impression that no one is yet issuing V3 certs?? Certainly that
is NOT the case.  We are generating a bundle of five V3 certs at the rate of one 
bundle every 10 seconds, with somewhere between 80,000 and 200,000 
bundles to be generated by the end of July.

All of those foundation certs will use printableString.  I'm more than willing to 
move to UTF-8 for everything, as soon as see solid evidence that the Microsoft and 
Netscape browsers, any S/MIME packages, etc., will support it.  But they have to
go first, and so far I see no commitment from them.

The issue of whether some implementors keep ISSUING certificates that
do not contain UTF-8 is of no consequence at all -- the IETF police will
issue them a summons and haul them before the IESG Court, and presumably
their punishment will be severe indeed. Ignore the IESG's mandate?? 
How dare they! Off with their heads! :-)

The only real question is when will all of the CONSUMERS of certificates accept
UTF-8 uniformly.  I'd certainly hope that code will be widely available by 2003,
but I'm not very confident that the user community will have purchased and installed 
the necessary upgrades by then.

Bob

>
>>>> Paul Hoffman / IMC <[email-masked]> 06/28 11:40 AM >>>
>I agree with Tim's recent posting (labelled "Proposed Resolution of
>Comments (LONG!)"). However, I think that some implementors will be tempted
>to keep issuing non-UTF8 after the cutoff date due to inertia. Also, the
>more people are using UTF8 strings early on, the more experience we will
>have with subtle problems.
>
>Chris Newman earlier pointed out something that I think most of us missed:
>that we only need to worry about backwards compatibility with version 1 and
>version 2 certs. For version 3 certs, there's no backward-compatibility
>issue, so we can go to UTF8 immediately for those certs. Doing this will
>give more implementors experience with UTF8 and will flesh out any
>remaining internationalization issues early.
>
>Therefore, I propose the following changes to the central part of 4.1.2.4
>from Tim's posting:
>
>. . .
>The DirectoryString type is defined as a choice of PrintableString,
>TeletexString, BMPString UTF8String and UniversalString. The UTF8String
>encoding is the preferred encoding in the IETF. All certificates whose
>version is 3 (value is 2), and all certificates issued after Dec. 31, 2003
>must use the UTF8String encoding of DirectoryString (except as noted
>below). Until that date, conforming CAs shall choose from the following
>options when creating a distinguished name, including their own, for
>version 1 (value is omitted) and version 2 (value is 1) certificates:
>. . .
>
>--Paul Hoffman, Director
>--Internet Mail Consortium

Date: Mon, 29 Jun 1998 10:07:59 -0400 (EDT)
From: Anne Anderson - Sun Microsystems <[email-masked]>
Reply-To: Anne Anderson - Sun Microsystems <[email-masked]>
Subject: Re: Proposed Resolution of Comments (LONG!)
To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

The modifications made to support use of
the RFC2247 domainComponent (DC=) attribute satisfy
my objections.

Anne Anderson                 Email: [email-masked]
Sun Microsystems Laboratories   Tel: (978) 442-0928
2 Elizabeth Drive, UCHL03-205   Fax: (978) 250-5067
Chelmsford, MA 01824 USA

Date: Mon, 29 Jun 1998 09:43:06 -0400
To: Mike Smith <[email-masked]>
From: Irene Gassko <[email-masked]>
Subject: Re: New OCSP draft
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

At 04:03 PM 6/26/98 -0600, Mike Smith wrote:
>Ambarish:
>
>Your comments raised/revitalized some thoughts on two topics that I would
like to address:  Revocation/Chain validation and Risk/Trust.
>
>Actually, there should be a chain of revocation down from the cert being
revoked if a CA.  A CA cert being expired or revoked should cause a system
to revoke all certs issued under that CA cert, including all
cross-refenced/cross certified certs. 

I respectfully disagree with this. I believe that this decision (whether to
revoke
certificates that were issued under the revoked key of a CA while that key was
valid) should be implementation dependent. 

Consider this example: you buy a certificate that allows you to listen
to the music on the site of ABC Music Corporation for a month. Two
days later a salesman who sold you this certificate quits because his
contract has expired. You should be able to have access to your music
for the whole month, because it's none of your business what personnel
changes happen at this corporation and your certificate should be legitimate
under the circumstances. It could be different if the key was compromised
or in some other situation. Of course, if this guy used his keys to issue
certificates after he resigned, those should be invalid.

We discussed this issue with Ambarish and came to the conclusion that
historical queries that had been mentioned on this list before can solve this
problem. That is, the application that finds out that the CA's key is revoked
should be able to find out if it was revoked at a certain point in the past,
and then make its own decisions.

A more complex situation can arise when the key is compromised. When
we find out that our credit card is missing, it can mean that it was lost or
stolen, say, during the preceding week. Usual procedure in such cases is
to revoke it absolutely at the day it's absence was discovered and also to
go through purchases of the preceding week one by one and cancel them
selectively. If we want to be able to implement such mechanism for
certificates,
I see two possible approaches:

1. To add one more attribute TimeOfPossibleCompromise;

2. Have an index that will allow CA to find certificates it issued during
    given time and either reissue them automatically with a new key,
    or contact their owners before reissuing for confirmation. This
    decision should be application dependent (e.g. for a music site
    it probably makes sense to let unauthorized people listen to
    their music for a while rather than make their customers unhappy, 
    while for a military site it could the opposite situation).

Irene

 >Naturally, the revocation in lateral  chains of CAs in a
cross-certification schema becomes quite complex, and needs to rely on the
integrity of all CAs in that web of trust to operate seemlessly across each
other's ARL, CRL, CKL or whatever lists they use to indicate revocation,
suspension or compromise according to their rules.

>
>Then, of course, the problem always exists for the CA that may have been
cross-certified into other trust hierarchies (policy mapped, even) that
decides to simply abandon its CA business - how does one and when does one
check their cross-certified CAs' actual existence or status?
>
>Anyway, these are observations I've made in the past to some on this list,
and some of the reasons that cause us in the banking community to look at
building trusted PKI based on our business relationships, not on a new
trust model where we do not know with whom we are doing business without
someone we do have a business relationship backing up the third party's
claim of identity (and indemnifying us from their errors).  The PKI trust
models can reflect the trust models banks have used successfully for the
last couple centuries and these new models will probably have more success
and wider acceptance if they build on existing trust models, rather than
new, untrusted models of trust.  
>
>The mechanics of the PKI structures we are all working on in the IETF are
very important and can be adapted to fit within many trust models,
including those already in place in businesses, governments and financial
institutions, as well as in a new paradigm of technologically sophisticated
trust models.  Building standards to meet such diverse implementation goals
can lead to different groups trying to build in trust technologically to
try and outwit those that would use such systems in no-risk-assumed, no
trust needed environments.  I mean, would anyone expect a bank to honor a
self-authenticated (maybe even self issued) cert from a company or
individual unless there 
>
>I do believe that the market will be divided into the no-risk-assumed and
risk-assumed models, with the risk-assumed models being used in business
and government systems, and the no-risk-assumed models used more for social
context systems.
>
>Michael
>
>Michael
>
>>>> Dan Geer <[email-masked]> 06/26 3:05 PM >>>
>
>the physics of revocation include two perverse rules
>
>1. all revocations are retroactive
>
>2. the cost of revocation checking increases with the distance
>   the entity is from the root yet the value of the check decreases
>   with that same distance
>
>so at some scale of hierarchy, you will have to overcome the
>costs of hierarchy (such as by wildcarding and/or processing

>a validity check top down only so far as you care to bother)
>or you will have to treat this all as an exercise in buying
>and selling risk
>
>--dan
> 
Irene Gassko                                     Bell Laboratories
Lucent Technologies                          Secure Technologies Dept.
300 Brickstone Square                       voice:   (978) 691-3270
6-th Floor                                          e-mail: [email-masked]
Andover, MA 01845                            fax:      (978) 691-3186

Date: Mon, 29 Jun 1998 09:27:33 -0400
From: Paul Koning <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: SV: Last Call - Profile
Sender: [email-masked]

>>>>> "Nilsson" == Nilsson Hans <[email-masked]> writes:

 Nilsson> Peter, As you suspected, the Swedish SEIS specifications,
 Nilsson> also used in Finland, requires Givenname and Surname in the
 Nilsson> subject name. In addition, the CA may anything it wants
 Nilsson> according to the specification, and the CA product currently
 Nilsson> being used allows for input of Title and CommonName.

 Nilsson> I think we want to stick with that, and not treat the whole
 Nilsson> name as one blob. For example, you want to search for also
 Nilsson> persons with the Surname = "Nilsson" without knowing the
 Nilsson> Givenname. Also, different countries have different
 Nilsson> conventions for forming a Commonname from (Givenname,
 Nilsson> Surname).

Does this setup allow DNs that contain a given name but no surname?
That's necessary for some countries (Indonesia, for example).

Also, is a patronymic a "surname" (for Iceland)?

I think Peter is right.  The decomposition of names, starting with the 
notion that they can be decomposed at all to the granularity and
naming of the components, is very country/culture specific and is best 
left out.

If you want to search for all Nilssons, what's wrong with searching
for "CN contains Nilsson"?

	paul

Date: Mon, 29 Jun 1998 08:48:47 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: CRL Reason Code
Sender: [email-masked]

X.509 defines this extension as:

reasonCode EXTENSION ::= {
 SYNTAX CRLReason
 IDENTIFIED BY id-ce-reasonCode }

CRLReason ::= ENUMERATED {
 unspecified (0),
 keyCompromise (1), 
 cACompromise (2), 
 affiliationChanged (3), 
 superseded (4),
 cessationOfOperation (5),
 certificateHold (6),
 removeFromCRL (8) }

PKIX Part 1 refers to this extension as CRLReason,. but the extension name is
reasonCode.  Because the EXTENSION macro is not used in PKIX Part 1, it may be
confusing that these two are the same extension.

Anyone have a suggestion for making this clear?

Russ

From: Brian Korver <[email-masked]>
Subject: Re: PKIX-1 - use of UTF8
To: [email-masked] (Russ Housley)
Date: Sun, 28 Jun 1998 11:25:04 -0700 (PDT)
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Russ Housley writes:
> We must have a solution that permits different codesets for each attribute
> in a name.
> 
> I am reluctant to support the incorrect tagging of things as T.61 that in
> fact are not T.61.
> 
> Can folks live with the following:
> 1.  Country must be represented in PrintableString.
> 2.  Other name components are represented using either 2a or 2b.
> 2a.  If can be represented at PrintableString, do so; otherwise use BMPString.
> 2b.  Represent as UTF8String.
> 
> Russ

Russ,

I'm only commenting on your #2, not the rest of your proposal. 

BMPString is a relatively recent addition to DirectoryString and I
don't believe it is being used much.  I would also guess that few
implementations exist that even deal with BMPString as such (rather 
than treating it merely as opaque data).  So if the point is to 
transition to UTF8String gracefully, I would drop 2a.

(an extra $.02: I think DirectoryString already has too many choices)

brian
[email-masked]

Date: Sun, 28 Jun 1998 10:40:18 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Making UTF8 palatable and keeping backwards compatibility
Sender: [email-masked]

I agree with Tim's recent posting (labelled "Proposed Resolution of
Comments (LONG!)"). However, I think that some implementors will be tempted
to keep issuing non-UTF8 after the cutoff date due to inertia. Also, the
more people are using UTF8 strings early on, the more experience we will
have with subtle problems.

Chris Newman earlier pointed out something that I think most of us missed:
that we only need to worry about backwards compatibility with version 1 and
version 2 certs. For version 3 certs, there's no backward-compatibility
issue, so we can go to UTF8 immediately for those certs. Doing this will
give more implementors experience with UTF8 and will flesh out any
remaining internationalization issues early.

Therefore, I propose the following changes to the central part of 4.1.2.4
from Tim's posting:

. . .
The DirectoryString type is defined as a choice of PrintableString,
TeletexString, BMPString UTF8String and UniversalString. The UTF8String
encoding is the preferred encoding in the IETF. All certificates whose
version is 3 (value is 2), and all certificates issued after Dec. 31, 2003
must use the UTF8String encoding of DirectoryString (except as noted
below). Until that date, conforming CAs shall choose from the following
options when creating a distinguished name, including their own, for
version 1 (value is omitted) and version 2 (value is 1) certificates:
. . .

--Paul Hoffman, Director
--Internet Mail Consortium

Subject: Specifying Naming attribute types (was: Last Call - Profile)
To: [email-masked]
Reply-to: [email-masked]
From: [email-masked]
Date: Sun, 28 Jun 1998 02:39:13 -0700
Sender: [email-masked]

I am curious as to why pkix-ipki-part1-08 makes any assertions about what 
attribute types implementations should be prepared to accept in DNs. I suppose 
I wonder what the breadth of "implementations" is in this context.

In any case, a DN can be essentially considered the primary key of an entry in 
a directory someplace (where finding that directory is outside of the scope of 
pkix-ipki-part1-08). Besides needing specification of particular matching 
rules for DNs due to character encoding possibilities, I'm not sure I see any 
reason for a PKIX implementation (of some sort) needing to care about the 
attribute types used to construct any given DN. AFAICS, a PKIX impl is only 
going to be comparing DNs and/or using them to retrieve their respective 
directory entries (at which point there might be attributes within the entry 
that it would reasonably expect to be there).

Conventions on DN construction are in flux -- there's RFC2247 for instance. 
There's the msg below from Harald from a thread on DNs on the IDS list a while 
back. And there's also draft-hodges-ldap-dir-dn-reqs-00.txt and 
draft-ietf-lsd-nandi-00.txt. I expect that DN conventions will remain in flux 
and that the safest thing for relying implementations to do is to treat them 
as much as possible as opaque pointers to directory entries from whence one 
extracts the truly useful info -- like what the human-meaningful "name" of the 
subject of the directory entry is.

For example, here's a test directory server that sports DNs similar to the 
ones we'll be moving our directory to...

  server:	director.stanford.edu
  base:		dc=stanford,dc=edu

  example search:

    ldapsearch -h director.stanford.edu -b dc=stanford,dc=edu "cn=*entry*" dn

These DNs aren't anything like what section 4.1.2.4 and 4.1.2.6 and such 
discuss, but I'd expect them to work just as well in the wide world as DNs 
based on "o=Stanford University, c=US" (given that the machinery is in place 
to find the appropriate server to talk to in each case -- and that's an 
orthogonal topic).

Jeff

ps: I'll be out of town and out of touch this coming week, so if this sparks 
comments, it'll be after the 6th 'fore I can get to following up.
------------------------------------------------------------------------------
From: [email-masked]
To: [email-masked]
Subject: The 3 purposes of a Distinguished Name
Date: Wed, 09 Apr 1997 09:56:54 -0500

This came up during the IDS meeting, and I wanted to share my thoughts
with the mailing list:

At the moment, an X.500/LDAP Distinguished Name has 3 different
purposes:

- To give uniqueness to entries
- To give a way to specify a search space
- To add information (commonly Organization or Country) to an entry

My thought at the moment is that the current DN practice in Paradise
et al, and the suggested DNS-based DN scheme, perform all 3 purposes badly.

I think a naming plan should deprecate at least 1 and possibly 2 of the
purposes; things performing a single purpose usually are MUCH better than
things serving many incompatible purposes.

Details:

- Uniqueness of names is most easily done with more-or-less random
  name assignment, using appropriate delegation. An OID-based namespace
  might be the Right Thing for this.

- Search space setup is very dependent on how people think. And given
  our current technology, search algorithms HAVE to know the structure
  of the searchspace, because "whole subtree from root" is an unrealistic
  search space.

- Using the DN to give information like country or organization is an
  evil practice and should be abandoned. Put the attributes in each entry
  instead.

That's my opinions. Comments?

                   Harald A

Date: Sat, 27 Jun 1998 15:58:05 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Editorial changes for PKIX part 1 last call
Sender: [email-masked]

I found three small things that I'd like to see changed as part of last call.

In 4.2.1.7, first paragraph, fifth sentence, remove the parenthetical "(or
issuer alternative name)" because this section is only on the subject
alternative name.

In section 9's subsections, all patent numbers should say "US patent
number" since these are for the US only and we should be clear on that.
Let's be a tad US-centric, eh?

In appendic C, sixth paragraph, remove the reference to RFC 2044 and leave
the reference to RFC 2279. 2279 is complete and the reference to the older
(and incorrect) RFC could confuse implementors.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Sat, 27 Jun 1998 17:55:47 -0400
To: [email-masked]
From: Tim Polk <[email-masked]>
Subject: Proposed Resolution of Comments (LONG!)
Sender: [email-masked]

Folks,

In a case of very bad timing, I will be out of the office for the second
week of Last Call.  (My family frowned on canceling vacation.)  As a
result, I am posting my attempt at "resolution of comments" to the list
before I go...

Given the various and conflicting opinions, not one will be particularly
pleased with the changes (including me!)  This is standards, folks!  The
question should be "Can I live with this?", not "Is it exactly what I
want?"  It's Last Call, and we'll all have to compromise.  If you get a
funny feeling in the pit of your stomach, but don't actually become
nauseous, then I've hit the happy medium.

(Sorry.  I get cranky when I work on Saturdays.)

>> Abbreviated Highlights

There are five sections that I have modified.

4.1.2.4 Issuer

I added a Dec. 31, 2003 cutover to UTF8.  Exceptions: name rollover certs
and CA certificates issued to (non-compliant) CAs.

Until then:  CAs can always choose UTF8 encoding for names; otherwise use
the smallest of {PrintableString, BMPString} that includes the required
characters.

Implementations are encouraged to handle Latin1String characters in
TeletexString for backward compatability.

The domainComponent attribute, as defined in [RFC 2247], has been added
to the set of naming attributes that implementations should handle.

Implementation of the ISO name comparison rules is explicitly permitted
as an alternative to the specified algorithm.

4.1.2.6 Subject

The domainComponent attribute, as defined in [RFC 2247], has been added
to the set of naming attributes that implementations should handle.

4.2.1.2  Subject Key Identifier

In a move sure to please no one, I added a second key generation
technique (the whole SHA-1 hash) to the mix.  The idea with the 4-bit
type was to accomodate other key id generation algorithms over time.  Why
wait?  Let's define two up front.

The profile does not require any particular algorithm for generating
subject key identifiers! It describes one or two algorithms that would
have the desired properties - low collisions.  I personally think 60 bits
will do, but if a CA wants more confidence, use the whole hash. 

4.2.1.11 Name Constraints

A paragraph has been added stating that the name comparison rules from
4.1.2.4 apply here as well.

10 Security Considerations

Three paragraphs have been added at the end of the section to describe
all the bad things that happen when a CA assumes ISO-style DN comparison
but implementations use binary matching instead.

I also added one section:

7.3.4 KEA keys 

KEA was a classified algorithm, so we could not include it in a standards
track document. This text existed as a separate document intended for
Informational RFC status. Since the KEA algorithm has been declassified,
it makes sense to merge the two documents. (BTW, if you are interested
see the URL

	 http://csrc.nist.gov/encryption/skipjack-kea.htm

for the specifications for KEA and Skipjack, which was also
declassified.)

There is no new information in this section. I just cut the meat out of
the KEA draft and pasted into the profile.

Sorry to be so brief, but I'm out of time.  See you in a week.

Tim Polk

>>  Proposed "Resolution" Of Comments

<bigger>

4.1.2.4  Issuer

   The issuer field identifies the entity who has signed and issued the

   certificate.  The issuer field shall contain a non-null 
distinguished

   name (DN).  The issuer field is defined as the X.501 type Name.  
Name

   is defined by the following ASN.1 structures:

   Name ::= CHOICE {

     RDNSequence }

   RDNSequence ::= SEQUENCE OF RelativeDistinguishedName

   RelativeDistinguishedName ::=

     SET OF AttributeTypeAndValue

   AttributeTypeAndValue ::= SEQUENCE {

     type     AttributeType,

     value    AttributeValue }

   AttributeType ::= OBJECT IDENTIFIER

   AttributeValue ::= ANY DEFINED BY AttributeType

   DirectoryString ::= CHOICE {

         teletexString           TeletexString (SIZE (1..MAX)),

         printableString         PrintableString (SIZE (1..MAX)),

         universalString         UniversalString (SIZE (1..MAX)),

         utf8String              UTF8String (SIZE (1.. MAX)),

         bmpString               BMPString (SIZE (1..MAX)) }

   The Name describes a hierarchical name composed of attributes, such

   as country name, and corresponding values, such as US.  The type of

   the component AttributeValue is determined by the AttributeType; in

   general it will be a DirectoryString.

   The DirectoryString type is defined as a choice of PrintableString,

   TeletexString, BMPString UTF8String and UniversalString.  The

   UTF8String encoding is the preferred encoding in the IETF, and all

   certificates issued after Dec. 31, 2003 must use the UTF8String

   encoding of DirectoryString (except as noted below).  Until that

   date, conforming CAs shall choose from the following options when

   creating a distinguished name, including their own:

      (a) if the character set is sufficient, the string may be

      represented as a PrintableString;

      (b) failing (a), if the BMPString character set is sufficient the

      string may be represented as a BMPString; and

      (c) failing (a) and (b), the string shall be represented as a

      UTF8String.  If (a) or (b) is satisified, the CA may still choose

      to represent the string as a UTF8String.

   Exceptions to the Dec. 31, 2003 UTF8 encoding requirements are as

   follows:

      (a) CAs may issue "name rollover" certificates to support an ord-

      erly migration to UTF8 encoding.  Such certificates would include

      the CA's UTF8 encoded name as issuer and and the old name 
encoding

      as subject, or vice-versa.

      (b) As stated in section 4.1.2.6, the subject field must be popu-

      lated with a non-null distinguished name matching the contents of

      the issuer field in all certificates issued by the subject CA

      regardless of encoding.

   The TeletexString and UniversalString are included for backward com-

   patibility, and should not be used for certificates for new 
subjects.

   However, these types may be used in certificates where the name was

   previously established.  Certificate users should be prepared to

   receive certificates with these string types.

   In addition, many legacy implementations support strings encoded in

   the ISO 8859-1 character set (Latin1String) but tag them as Teletex-

   String.  The Latin1String includes many of the characters used in

   Western European countries which are omitted by TeletexString.

   Implementations that wish to display TeletexString should be 
prepared

   to handle the entire ISO 8859-1 character set.

   Standard sets of attributes have been defined in the X.500 series of

   specifications.  This specification recommends that issuer names 
con-

   tain only the following attribute types: country, organization,

   organizational-unit, distinguished name qualifier, title, locality,

   state or province name, common name (e.g., "Susan Housley"), 
surname,

   given name, initials, and generationqualifier (e.g., "Jr." or "IV").

   The syntax and associated object identifiers (OIDs) for these attri-

   bute types are provided in the ASN.1 modules in Appendices A and B.

   In addition, implementations of this specification should be 
prepared

   to receive the domainComponent attribute, as defined in [RFC 2247].

   The Domain (Nameserver) System (DNS) provides a hierarchical 
resource

   labeling system.  This attribute provides is a convenient mechanism

   for organizations that wish to use DNs that parallel their DNS 
names.

   (This is not a replacement for the dNSName component of the alterna-

   tive name field. Implementations are not required to convert such

   names into DNS names.) The syntax and associated object identifiers

   (OIDs) for this attribute type is provided in the ASN.1 modules in

   Appendices A and B.

   Certificate users must be prepared to process the issuer dis-

   tinguished name and subject distinguished name (see sec. 4.1.2.6)

   fields to perform name chaining for certification path validation

   (see section 6). Name chaining is performed by matching the issuer

   distinguished name in one certificate with the subject name in

   another.

   This specification requires only a subset of the name comparison

   functionality specified in X.501. The requirements for conforming

   implementations are as follows:

      (a) attribute values encoded in different string types (e.g.,

      PrintableString and BMPString) may be assumed to represent dif-

      ferent strings;

      (b) attribute values in string types other than PrintableString

      are case sensitive (this permits matching of attribute values as

      binary objects);

      (c) attribute values in PrintableString are not case sensitive

      (e.g., "Marianne Swanson" is the same as "MARIANNE SWANSON"); and

      (d) attribute values in PrintableString are compared after remov-

      ing leading and trailing white space and converting internal

      strings of one or more consecutive white space characters to a

      single space.

   These name comparison rules permit a certificate user to validate

   certificates issued using languages or encodings unfamiliar to the

   certificate user.

   Note that the ISO rules of DN comparison indicate that the character

   sets used to encode data in DNs are irrelevant.  The characters 
them-

   selves must be compared without regard to encoding.  Implementations

   of the profile are permitted to use the ISO DN comparison algorithm.

   Such an implementation will recognize a superset of name matches

   recognized by the algorithm specified above.

4.1.2.6  Subject

   The subject field identifies the entity associated with the public

   key stored in the subject public key field.  The subject name may be

   carried in the subject field and/or the subjectAltName extension.  
If

   the subject is a CA (e.g., the basic constraints extension, as dis-

   cussed in 4.2.1.10, is present and the value of cA is TRUE,) then 
the

   subject field must be populated with a non-null distinguished name

   matching the contents of the issuer field (see sec. 4.1.2.4) in all

   certificates issued by the subject CA.  If subject naming 
information

   is present only in the subjectAltName extension (e.g., a key bound

   only to an email address or URI), then the subject name must be an

   empty sequence and the subjectAltName extension must be critical.

   Where it is non-empty, the subject field shall contain an X.500 dis-

   tinguished name (DN). The DN must be unique for each subject entity

   certified by the one CA as defined by the issuer name field. (A CA

   may issue more than one certificate with the same DN to the same 
sub-

   ject entity.)

   The subject name field is defined as the X.501 type Name, and shall

   follow the encoding rules for the issuer name field (see sec.

   4.1.2.4). When encoding strings as the type PrintableString, 
conform-

   ing CAs should use mixed case but should not include leading or

   trailing white space and should limit internal white space to sub-

   strings of a single space.

   Implementations of this specification should be prepared to receive

   the following X.501 attribute types: country, organization,

   organizational-unit, distinguished name qualifier, title, locality,

   state or province name, common name (e.g., "Susan Housley"), 
surname,

   given name, initials, and generationqualifier (e.g., "Jr." or "IV").

   The syntax and associated object identifiers (OIDs) for these attri-

   bute types are provided in the ASN.1 modules in Appendices A and B.

   In addition, implementations of this specification should be 
prepared

   to receive the domainComponent attribute, as defined in [RFC 2247].

   The Domain (Nameserver) System (DNS) provides a hierarchical 
resource

   labeling system.  This attribute provides is a convenient mechanism

   for organizations that wish to use DNs that parallel their DNS 
names.

   (This is not a replacement for the dNSName component of the alterna-

   tive name field. Implementations are not required to convert such

   names into DNS names.) The syntax and associated object identifiers

   (OIDs) for this attribute type is provided in the ASN.1 modules in

   Appendices A and B.

   Legacy implementations exist where an RFC 822 name is embedded in 
the

   subject distinguished name as a PKCS #9 EmailAddress attribute [PKCS

   #9].  Conforming implementations generating new certificates with

   electronic mail addresses must use the rfc822Name in the subject

   alternative name field (see sec. 4.2.1.7) to describe such identi-

   ties.  Simultaneous inclusion of the EmailAddress attribute in the

   subject distinugished name to support legacy implementations is

   deprecated but permitted.

   The ASN.1 syntax for EmailAddress and the corresponding OID are sup-

   plied below.

   EmailAddress ::= IA5String

   pkcs-9 OBJECT IDENTIFIER ::=

          { iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) 9 }

   emailAddress OBJECT IDENTIFIER ::= { pkcs-9 1 }

4.2.1.2  Subject Key Identifier

   The subject key identifier extension provides a means of identifying

   the particular public key used in an application. This extension

   should be included in all certificates.

   To facilitate chain building, this extension MUST appear in all

   conforming CA certificates, that is, all certificates including the

   basic constraints extension (see sec. 4.2.1.10) where the value of 
cA

   is TRUE.  The value of the subject key identifier shall be the value

   placed in the key identifier field of the Authority Key Identifier

   extension (see sec. 4.2.1.1) of certificates issued by the subject 
of

   this certificate.

   Where a key identifier has not been previously established, this

   specification recommends the following method for generating 
keyIden-

   tifiers:  the keyIdentifier is composed of a four bit type field 
with

   the value 0100 followed by the least significant 60 bits of the 
SHA-1

   hash of the BIT STRING subjectPublicKey.

   Where a CA requires more than 60 bits in the keyIdentifier, the fol-

   lowing alternative is recommended:  the keyIdentifier is composed of

   a four bit type field with the value xxxx followed by the complete

   SHA-1 hash of the BIT STRING subjectPublicKey.

   This extension should be marked non-critical.

   id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::=  { id-ce 14 }

   SubjectKeyIdentifier ::= KeyIdentifier

4.2.1.11  Name Constraints

   The name constraints extension, which shall be used only in a CA 
cer-

   tificate, indicates a name space within which all subject names in

   subsequent certificates in a certification path must be located.

   Restrictions may apply to the subject distinguished name or subject

   alternative names.  Restrictions apply only when the specified name

   form is present. If no name of the type is in the certificate, the

   certificate is acceptable.

   Restrictions are defined in terms of permitted or excluded name sub-

   trees.  Any name matching a restriction in the excludedSubtrees 
field

   is invalid regardless of information appearing in the permittedSub-

   trees.  This extension must be critical.

   Within this profile, the minimum and maximum fields are not used 
with

   any name forms, thus minimum is always zero, and maximum is always

   absent.

   Restriction of DN name forms, the constraint shall be compared to

   DNs, the

   Restrictions for the rfc822 and uri name forms are all expressed in

   terms of strings with wild card matching.  An "*" is the wildcard

   character.

   For URIs, the constraint applies to the host part of the name.  
Exam-

   ples would be foo.bar.com; www*.bar.com; and *.xyz.com.  When a 
wild-

   card appears as the leftmost subdomain, it may be matched with one 
or

   more subdomains.  That is, the constraint "*.xyz.com" is satisfied 
by

   both abc.xyz.com and abc.def.xyz.com.  However, the constraint

   "*.xyz.com" is not satisfied by "xyz.com". Otherwise, the wildcard

   may only be expanded within a single subdomain. That is, 
www*.bar.com

   is satisfied by www1.bar.com but not www.foo.bar.com.

   To indicate all Internet mail addresses on a particular host, the 
"*"

   character is used. For example, "[email-masked]" indicates all mail

   addresses at the host "xyz.com". Note that although "*" is a valid

   character in Internet mail addresses, it is very rarely used on the

   Internet, and thus is appropriated by this specification for the

   email wildcard.

   Internet mail addresses may also be constrained by the host part of

   the name, as with URIs.  For example, "root@*.xyz.com" indicates all

   the Internet mail addresses root in the domain "xyz.com".  As above,

   "*" is a valid character in the host part of the name, but it is 
very

   rarely used on the Internet, and thus is appropriated by this 
specif-

   ication for the mail address wildcard.

   To indicate all Internet mail addresses in a particular domain, 
these

   mechanisms may be combined.  For example, "*@*.xyz.com" indicates 
all

   email addresses in the domain "xyz.com".

   DNS name restrictions are expressed as foo.bar.com. Any DNS name 
that

   can be constructed by simply adding to the left hand side of the 
name

   satisfies the name constraint. For example, www.foo.bar.com would

   satisfy the constraint but foo1.bar.com would not.

   Legacy implementations exist where an RFC 822 name is embedded in 
the

   subject distinguished name as a PKCS #9 e-mail attribute, which has

   the ASN.1 type EmailAddress [PKCS #9] (see sec. 4.1.2.6). When 
rfc822

   names are constrained, but the certificate does not include a 
subject

   alternative name, the rfc822 name constraint must be applied to PKCS

   #9 e-mail attributes in the subject distinguished name.  The ASN.1

   syntax for EmailAddress and the corresponding OID are supplied in

   4.1.2.6.

   Restrictions of the form directoryName shall be applied to the sub-

   ject field in the certificate and to the subjectAltName extensions 
of

   type directoryName. Restrictions of the form x400Address shall be

   applied to subjectAltName extensions of type x400Address.

   When applying restrictions of the form directoryName, an implementa-

   tion must compare DN attributes.  At a minimum, implementations 
shall

   perform the DN comparison rules specified in Section 4.1.2.4.  CAs

   issuing certificates with a restriction of the form directoryName

   should not rely on implementation of the full ISO DN name comparison

   algorithm.  This implies name restrictions must be stated 
identically

   to the encoding used in the subject field or subjectAltName exten-

   sion.

   The syntax of iPAddress shall be as described in section 4.2.1.7 
with

   the following additions specifically for Name Constraints.  For IPv4

   addresses, the ipAddress field of generalName shall contain eight 
(8)

   octets, encoded in the style of RFC 1519 (CIDR) to represent an

   address range.  For IPv6 addresses, the ipAddress field shall 
contain

   32 octets similarly encoded.  For example, a name constraint for

   "class C" subnet 10.9.8.0 shall be represented as the octets 0A 09 
08

   00 FF FF FF 00, representing the CIDR notation

   10.9.8.0/255.255.255.0.

   The syntax and semantics for name constraints for otherName,

   ediPartyName, and registeredID are not defined by this 
specification.

      id-ce-nameConstraints OBJECT IDENTIFIER ::=  { id-ce 30 }

      NameConstraints ::= SEQUENCE {

           permittedSubtrees       [0]     GeneralSubtrees OPTIONAL,

           excludedSubtrees        [1]     GeneralSubtrees OPTIONAL }

      GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree

      GeneralSubtree ::= SEQUENCE {

           base                    GeneralName,

           minimum         [0]     BaseDistance DEFAULT 0,

           maximum         [1]     BaseDistance OPTIONAL }

      BaseDistance ::= INTEGER (0..MAX)

7.3.4 KEA Keys

   The Key Exchange Algorithm (KEA) is an algorithm for exchanging

   keys[KEA].  A KEA "pairwise key" may be generated between two users

   if their KEA public keys were generated with the same KEA 
parameters.

   The KEA parameters are not included in a certificate; instead a

   "domain identifier" is supplied in the parameters field.

   When the subjectPublicKeyInfo field contains a KEA key, the 
algorithm

   identifier and parameters shall be as defined in [sdn.701r]:

      id-keyExchangeAlgorithm  OBJECT IDENTIFIER   ::=

             { 2 16 840 1 101 2 1 1 22 }

      KEA-Parms-Id     ::= OCTET STRING

   CAs shall populate the parameters field of the AlgorithmIdentifier

   within the subjectPublicKeyInfo field of each certificate containing

   a KEA public key with an 80-bit parameter identifier (OCTET STRING),

   also known as the domain identifier. The domain identifier will be

   computed in three steps: (1) the KEA parameters are DER encoded 
using

   the Dss-Parms structure (see Section 7.3.3); (2) a 160-bit SHA-1 
hash

   is generated from the parameters; and (3) the 160-bit hash is 
reduced

   to 80-bits by performing an "exclusive or" of the 80 high order bits

   with the 80 low order bits.  The resulting value is encoded such 
that

   the most significant byte of the 80-bit value is the first octet in

   the octet string.

   A KEA public key, y, is conveyed in the subjectPublicKey BIT STRING

   such that the most significant bit (MSB) of y becomes the MSB of the

   BIT STRING value field and the least significant bit (LSB) of y

   becomes the LSB of the BIT STRING value field.  This results in the

   following encoding: BIT STRING tag, BIT STRING length, 0 (indicating

   that there are zero unused bits in the final octet of y), BIT STRING

   value field including y.

   The key usage extension may optionally appear in a KEA certificate.

   If a KEA certificate includes the keyUsage extension, only the fol-

   lowing values may be asserted:  keyAgreement; encipherOnly; and 
deci-

   pherOnly.

   The encipherOnly and decipherOnly values may only be asserted if the

   keyAgreement value is also asserted.  At most one of encipherOnly 
and

   decipherOnly shall be asserted in keyUsage extension

10  Security Considerations

   The majority of this specification is devoted to the format and con-

   tent of certificates and CRLs.  Since certificates and CRLs are 
digi-

   tally signed, no additional integrity service is necessary. Neither

   certificates nor CRLs need be kept secret, and unrestricted and

   anonymous access to certificates and CRLs has no security implica-

   tions.

   However, security factors outside the scope of this specification

   will affect the assurance provided to certificate users.  This sec-

   tion highlights critical issues that should be considered by imple-

   mentors, administrators, and users.

   The procedures performed by CAs and RAs to validate the binding of

   the subject's identity of their public key greatly affect the

   assurance that should be placed in the certificate.  Relying parties

   may wish to review the CA's certificate practice statement.  This 
may

   be particularly important when issuing certificates to other CAs.

   The use of a single key pair for both signature and other purposes 
is

   strongly discouraged. Use of separate key pairs for signature and 
key

   management provides several benefits to the users. The ramifications

   associated with loss or disclosure of a signature key are different

   from loss or disclosure of a key management key. Using separate key

   pairs permits a balanced and flexible response.  Similarly, 
different

   validity periods or key lengths for each key pair may be appropriate

   in some application environments. Unfortunately, some legacy 
applica-

   tions (e.g., SSL) use a single key pair for signature and key 
manage-

   ment.

   The protection afforded private keys is a critical factor in main-

   taining security.  On a small scale, failure of users to protect

   their private keys will permit an attacker to masquerade as them, or

   decrypt their personal information. On a larger scale, compromise of

   a CA's private signing key may have a catastrophic effect.  If an

   attacker obtains the private key unnoticed, the attacker may issue

   bogus certificates and CRLs.  Existence of bogus certificates and

   CRLs will undermine confidence in the system. If the compromise is

   detected, all certificates issued to the CA must be revoked, 
prevent-

   ing services between its users and users of other CAs. Rebuilding

   after such a compromise will be problematic, so CAs are advised to

   implement a combination of strong technical measures (e.g., tamper-

   resistant cryptographic modules) and appropriate management pro-

   cedures (e.g., separation of duties) to avoid such an incident.

   Loss of a CA's private signing key may also be problematic.  The CA

   would not be able to produce CRLs or perform normal key rollover.

   CAs are advised to maintain secure backup for signing keys.  The

   security of the key backup procedures is a critical factor in avoid-

   ing key compromise.

   The availability and freshness of revocation information will affect

   the degree of assurance that should be placed in a certificate.

   While certificates expire naturally, events may occur during its

   natural lifetime which negate the binding between the subject and

   public key.  If revocation information is untimely or unavailable,

   the assurance associated with the binding is clearly reduced.  Simi-

   larly, implementations of the Path Validation mechanism described in

   section 6 that omit revocation checking provide less assurance than

   those that support it.

   The path validation algorithm depends on the certain knowledge of 
the

   public keys (and other information) about one or more trusted CAs.

   The decision to trust a CA is an important decision as it ultimately

   determines the trust afforded a certificate. The authenticated dis-

   tribution of trusted CA public keys (usually in the form of a "self-

   signed" certificate) is a security critical out of band process that

   is beyond the scope of this specification.

   In addition, where a key compromise or CA failure occurs for a

   trusted CA, the user will need to modify the information provided to

   the path validation routine.  Selection of too many trusted CAs will

   make the trusted CA information difficult to maintain.  On the other

   hand, selection of only one trusted CA may limit users to a closed

   community of users until a global PKI emerges.

   The quality of implementations that process certificates may also

   affect the degree of assurance provided.  The path validation algo-

   rithm described in section 6 relies upon the integrity of the 
trusted

   CA information, and especially the integrity of the public keys 
asso-

   ciated with the trusted CAs.  By substituting public keys for which

   an attacker has the private key, an attacker could trick the user

   into accepting false certificates.

   The binding between a key and certificate subject cannot be stronger

   than the cryptographic module implementation and algorithms used to

   generate the signature.  Short key lengths or weak hash algorithms

   will limit the utility of a certificate.  CAs are encouraged to note

   advances in cryptology so they can employ strong cryptographic tech-

   niques.  In addition, CAs should decline to issue certificates to 
CAs

   or end entities that generate weak signatures.

   Finally, inconsistent application of name comparison rules may 
result

   in acceptance of invalid X.509 certification paths, or rejection of

   valid ones.  The ISO rules for comparing distinguished names require

   comparison of strings without regard to case, character set, multi-

   character white space sequences, or leading and trailing white 
space.

   This specification relaxes these requirements, requiring support for

   binary comparison at a minimum.

   CAs must encode the subject DN of a CA certificate identically to 
the

   issuer DN in certificates issued by the latter CA.  If CAs use dif-

   ferent encodings, implementations of this specification may fail to

   recognize name chains for paths that include this certificate.  As a

   consequence, valid paths could be rejected.

   In addition, name constraints for DNs must be stated identically to

   the encoding used in the subject field or subjectAltName extension.

   If not, (1) name constraints stated as excludedSubTrees will not

   match and invalid paths will be accepted and (2) name constraints

   expressed as permittedSubtrees will not match and valid paths will 
be

   rejected.  To avoid acceptance of invalid paths, CAs should state

   name constraints for DNs as permittedSubtrees whereever possible.

</bigger>

Date: Fri, 26 Jun 1998 15:20:02 -0400
To: Nada Kapidzic Cicovic <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: SV: new profile submitted
Cc: Paul Hoffman / IMC <[email-masked]>, [email-masked]
Sender: [email-masked]

As stated on the list, the is for alignment with US Government, ANSI, and
Draft ISO TC68 documents.

Russ

At 12:08 PM 6/24/98 +0200, Nada Kapidzic Cicovic wrote:
>I do not understand the point of changing the key id calculation algorithm
>this late in pkix part 1 last call. 
>
>Is the size of the resulting key id the only problem with the old algorithm
>definition?
>
>Is this size really an issue for S/MIME messages?
>
>I would prefer changing the definition back to what it was, since we have
>already released the software implementing it in the old way, and we are
>probably not the only one.
>
>Regards,
>
>Nada
>
>
>At 20:55 6/23/98 -0400, Russ Housley wrote:
>>The PKIX Part 1 key identifier will be used in S/MIME to identify the
>>per-recipient information necessary for a recipient to perform decryption.
>>As stated in a previous message, collisions are not a problem here.
>>However, this key identifier will not be used to identify a particular
>>certificate used by an originator to sign a message content.  Collisions
>>could cause significant confusion in this circumstance.
>>
>>Russ
>>
>>
>>At 12:11 PM 6/23/98 -0700, Paul Hoffman / IMC wrote:
>>>I think the question here is whether or not it is useful to have the same
>>>key identifier for both PKIX part 1 and OCSP. If it is, then we need to
>>>choose one that works for both. Ambarish says that 60 bits, with the
>>>possibility of collision, is not strong enough for OCSP. If that's true, we
>>>need to decide if the two key identifiers have to be the same, or whether
>>>we can use a shorter one for PKIX part 1 and a longer one for OCSP.
>>>
>>>--Paul Hoffman, Director
>>>--Internet Mail Consortium
>>> 
>>
> 

Date: Fri, 26 Jun 1998 15:56:23 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: Last Call - Profile
Cc: [email-masked]
Sender: [email-masked]

Anne:

Thanks for your comments.  Let me repond to each.

>Objection 1: PKIX should not mandate use of X501 names for chaining.
>Not all PKI's store certificate information in an X500 directory.

I agree that X.500 Directory deployment will not be ubiqutious for many
years to come.  That is why I wrote the Internet-Draft dealing with the
distribuion of Certificates and CRLs using FTP and HTTP.

The use of X.501 names does not imply the existance of a Directory.  This
name format can be used without deploying a Directory.

S/MIME (and other protocols) as well as CRL entries identify certificates
by the combination of the issuer Distinguished Name and Serial Number.
This is the reaon that the population of the Issuer filed with a non-empty
name is important.

>Objection 2: If PKIX does mandate X501 names for chaining, then the
>RFC2247 "DC=" attribute should be added to the list of recommended
>name attributes to be used in section 4.1.2.4.

I have no objection to the inclusion of the "DC=" attribute as a name
component.

>Objection 3: If the intent is indeed to mandate use of X501 names for
>chaining, section 4.1.2.6 "Subject" is ambiguous with respect to this mandate
>and section 6.1 "Basic Path Validation" contradicts this mandate.  Locations
>and suggested changes follow.

Names can be used for path development.  However, the SubjectKeyIdentifier
and AuthorityKeyIdentifer extensions can also be used for path development.

Once the path is developed, the path validation includes the checking of
the parent subject name and the child issuer name at each link in the path.

Russ

Date: Fri, 26 Jun 1998 15:26:19 -0400
To: Harald Alvestrand <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: PKIX-1 - use of UTF8
Cc: [email-masked]
Sender: [email-masked]

All:

>>In the following, I'm going to call a system that implements the current
>>PKIX-1 rules an "Old" system, and one that emits certificates in UTF-8 a
>>"New" system (under the assumption that UTF-8 is where we'd like to get
>>to).  Similarly, "Old Certificates" contain names using the current PKIX-1
>>codeset selection rules, and "New Certificates" use UTF-8.
>
>You are making the assumption here that the same codeset is used for
>all attributes of all names within a certificate.
>Is this a requirement of the infrastructure?

We must have a solution that permits different codesets for each attribute
in a name.

I am reluctant to support the incorrect tagging of things as T.61 that in
fact are not T.61.

Can folks live with the following:
1.  Country must be represented in PrintableString.
2.  Other name components are represented using either 2a or 2b.
2a.  If can be represented at PrintableString, do so; otherwise use BMPString.
2b.  Represent as UTF8String.

Russ

From: Nilsson Hans <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: SV: Last Call - Profile
Date: Sat, 27 Jun 1998 08:32:26 +0100
Sender: [email-masked]

Peter,

As you suspected, the Swedish SEIS specifications, also used in Finland,
requires Givenname and Surname in the subject name. In addition, the CA may
anything it wants according to the specification, and the CA product
currently being used allows for input of Title and CommonName.

I think we want to stick with that, and not treat the whole name as one
blob. For example, you want to search for also persons with the Surname =
"Nilsson" without knowing the Givenname. Also, different countries have
different conventions for forming a Commonname from (Givenname, Surname).

Hans

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Last Call - Profile
Reply-To: [email-masked]
Date: Sat, 27 Jun 1998 15:51:04 (NZST)
Sender: [email-masked]

>>  Standard sets of attributes have been defined in the X.500 series of
>>  specifications.  This specification recommends that issuer names con-
>>  tain only the following attribute types: country, organization,
>>  organizational-unit, distinguished name qualifier, title, locality,
>>  state or province name, common name (e.g., "Susan Housley"), surname,
>>  given name, initials, and generationqualifier (e.g., "Jr." or "IV").
>>  The syntax and associated object identifiers (OIDs) for these attri-
>>  bute types are provided in the ASN.1 modules in Appendices A and B.
>>
>>[Insert: "domain component (i.e. RFC2247)" in the list of recommended
>>name attributes.]
 
The addition of name detritus looks like a late change in the most recent draft
(I can't find it in the previous drafts).  I think this is a bad move, because
all it does is add unnecessary confusion and complication without providing any
noticeable benefit (by "name detritus" I mean DN qualifier, title, surname,
given name, initials, generationqualifier, hair colour,
distinguishingmarksorfeatures, and God knows what else).
 
Currently almost all certs in existence use C, O, OU, L, SP, and CN.  I've
never seen any use of name detritus, so when making a change like this you need
to look at two issues:
 
  1. What benefits does this change bring?
  2. What drawbacks does this change have?
 
I can't see any benefits at all, since everything you can specify as name
detritus, as far as anyone not versed in X.500 theology is concerned (and that
covers 99.999% of the user base) is already possible in a DN.
 
As for the drawbacks, forcing people to break up names into their component
atoms and scattering them across half a dozen attributes will cause nothing but
confusion - give 20 different non-X.500-theologists the listed selection of
attributes and you'll get 20 different interpretations of how to use them, and
this doesn't even touch on the problems which are caused by the mostly US (or
at least north-american)-specific nature of the name detritus.  How this will
fly in localities where you may or may not be committing a mortal offence by
ommitting "Herr Doktor Professor" as a title, or where the concept of a
"surname" and "given name" (and other bits and pieces) are very mutable, or
where everyone is called Singh or (to a lesser extent) Kim, or where you have a
multitude of names and use different ones in different circumstances, or ...
(can anyone here outline the Swedish(?) use of situational names to give list
members an example of this problem?  I can remember partial details of how they
work, but it's been awhile since I read about them).
 
As far as I can see this change has no benefit at all (I can't see any
identifiable problem which it fixes), but has the potential to cause endless
complications once you move outside north american (and common european) naming
conventions.  CN's have worked fine so far, I can't see any reason to replace
them.
 
>Anne's note jogged my memory in this area.  One of the major problems with
>"locality" is that the semantics are exceptionally poorly defined in X.521.
>Is it a city or town, a real estate subdivision within a town, a county, the
>Washington Metropolitan Area, Europe, the Internet, the solar system, or what?
>What purpose is it intended to serve?
 
>In particular, does it serve as a reasonable name qualifier for the sake of
>uniqueness?  Does it serve as a geographical or geopolitical region that is
>sufficiently small that I might actually be able to find someone there? Is it
>a substitute for stateOrProvince, for those countries that don't have states,
>cantons, territories, parishes, etc., etc.?
 
[...]
 
>But while locality is so poorly defined as to be nearly useless, the list also
>omits the obviously necessary qualifier of streetAddress or postAddress, in
>addition to what I believe is Anne's concern, the need for cyberspace
>addresses, either in place of or in addition to physical addresses.
 
I think locality is another item which has been proven in the field to work
fine, and for which there's no need for change.  Sure, it's only vaguely
defined, but I've never seen anyone who has any problems with it.  A loose
definition of "locality" (as far as the rest of the world is concerned) is "the
bit of your address which appears just before your state or province, or before
your country if you don't have states or provinces".  Going to my cert
menagerie, I can't see any instances of people having problems with this - it
may not be what the ITU intended, but everyone who uses it seems to be able to
set "locality" to a sensible value.
 
[Looking through the menagerie, which represents certs harvested from all over
 the world, I can't find a single use of a DN attribute which isn't in the list
 {C, O, OU, L, SP, and CN}.  Like BMPStrings, there may be billions of
 potential possibilities there, but noone seems to feel any need for them]
 
Taking the menagerie as being representative of current usage, I would suggest
that PKIX recommend the traditional C, O, OU, L, SP, and CN, and mention that
others are possible but not recommended (a lot of commonly-used software won't
be able to do much with anything else - the last I saw, the likes of MSIE and
IIS only allowed the attributes listed above when you generated a cert request,
and I don't recall Netscape allowing much else either, although it's been
awhile since I looked at it).  If it ain't broken, I don't see any compelling
reason to try to "fix" it.
 
Peter.

Date: Fri, 26 Jun 1998 16:03:40 -0600
From: Mike Smith <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Cc: [email-masked]
Subject: Re: New OCSP draft
Sender: [email-masked]

Ambarish:

Your comments raised/revitalized some thoughts on two topics that I would like to address:  Revocation/Chain validation and Risk/Trust.

Actually, there should be a chain of revocation down from the cert being revoked if a CA.  A CA cert being expired or revoked should cause a system to revoke all certs issued under that CA cert, including all cross-refenced/cross certified certs.  Naturally, the revocation in lateral  chains of CAs in a cross-certification schema becomes quite complex, and needs to rely on the integrity of all CAs in that web of trust to operate seemlessly across each other's ARL, CRL, CKL or whatever lists they use to indicate revocation, suspension or compromise according to their rules.

Then, of course, the problem always exists for the CA that may have been cross-certified into other trust hierarchies (policy mapped, even) that decides to simply abandon its CA business - how does one and when does one check their cross-certified CAs' actual existence or status?

Anyway, these are observations I've made in the past to some on this list, and some of the reasons that cause us in the banking community to look at building trusted PKI based on our business relationships, not on a new trust model where we do not know with whom we are doing business without someone we do have a business relationship backing up the third party's claim of identity (and indemnifying us from their errors).  The PKI trust models can reflect the trust models banks have used successfully for the last couple centuries and these new models will probably have more success and wider acceptance if they build on existing trust models, rather than new, untrusted models of trust.  

The mechanics of the PKI structures we are all working on in the IETF are very important and can be adapted to fit within many trust models, including those already in place in businesses, governments and financial institutions, as well as in a new paradigm of technologically sophisticated trust models.  Building standards to meet such diverse implementation goals can lead to different groups trying to build in trust technologically to try and outwit those that would use such systems in no-risk-assumed, no trust needed environments.  I mean, would anyone expect a bank to honor a self-authenticated (maybe even self issued) cert from a company or individual unless there 

I do believe that the market will be divided into the no-risk-assumed and risk-assumed models, with the risk-assumed models being used in business and government systems, and the no-risk-assumed models used more for social context systems.

Michael

Michael

>>> Dan Geer <[email-masked]> 06/26 3:05 PM >>>

the physics of revocation include two perverse rules

1. all revocations are retroactive

2. the cost of revocation checking increases with the distance
   the entity is from the root yet the value of the check decreases
   with that same distance

so at some scale of hierarchy, you will have to overcome the
costs of hierarchy (such as by wildcarding and/or processing
a validity check top down only so far as you care to bother)
or you will have to treat this all as an exercise in buying
and selling risk

--dan

To: [email-masked], [email-masked]
Cc: IETF PKIX <[email-masked]>
Subject: Re: New OCSP draft 
Date: Fri, 26 Jun 1998 17:05:22 -0400
From: Dan Geer <[email-masked]>
Sender: [email-masked]

the physics of revocation include two perverse rules

1. all revocations are retroactive

2. the cost of revocation checking increases with the distance
   the entity is from the root yet the value of the check decreases
   with that same distance

so at some scale of hierarchy, you will have to overcome the
costs of hierarchy (such as by wildcarding and/or processing
a validity check top down only so far as you care to bother)
or you will have to treat this all as an exercise in buying
and selling risk

--dan

Date: Fri, 26 Jun 1998 11:24:18 -0700
From: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
To: Irene Gassko <[email-masked]>
CC: IETF PKIX <[email-masked]>
Subject: Re: New OCSP draft
Sender: [email-masked]

Hi Irene,
    I am not sure you actually want to distinugish between the cases
where a cert was issued before/after the CA's key was compromised.

You need to know whether you can trust the cert or not. If any
cert in the chain from that cert to a trusted root is revoked, you
can't trust that cert (unless you can create another path that can
be trusted), independent of when that cert was issued.

Did you have a situation where you are willing to trust a cert
even though the CA that issued the cert had its key compromised?

Regards,
Ambarish

Irene Gassko wrote:
> 
> At 10:33 AM 6/26/98 -0700, Ambarish Malpani wrote:
> >Hi Irene,
> >    OCSP returns the status of the certificate. If you are trying to
> >check a whole
> >chain, you should also query for the status of the CA of the
> >certificate, at
> >which point you will find out the the CA has been compromised.
> >
> >CA1 issues CA cert to CA2
> >CA2 issues regular cert to EU (end user)
> >
> >If CA2's key is compromised, then any application that only trusts
> >CA1 and is trying to verify the status of EU, should also, at the
> same
> >time, verify the status of CA2.
> >
> >Query { statusOf(EU), statusOf(CA2) }
> >Response { EU-notRevoked, CA2-revoked }
> 
> This is ambiguous, IMO. How do we distinguish two different cases:
> 
> 1. CA2 was revoked after the certificate was created (which for many
> applications will be fine).
> 2. CA2 was revoked before the certificate was created (which makes
> certificate useless, because it most probably was forged).
> 
> >
> >Would this solve the problem? I would prefer not trying to make
> >statements
> >about two different certs/levels of hierarchy at one time.
> 
> Agreed.
> 
> >
> >Regards,
> >Ambarish
> >
> >
> >Irene Gassko wrote:
> >>
> >> >> >3. CertStatus
> >> >> >I would really love to see the addition of notIssued to the
> list of
> >> >> >result codes. This would mean "I know about the CA and all the
> >> >> >certificates it has ever issued, but the certificate presented
> is *not*
> >> >> >on my list".
> >> >>
> >> >> This request has come up before.  The primary reason it's not in
> the
> >> >> list of result codes is that it seems unlikely an OCSP requester
> would
> >> >> be querying on a certificate it was not already handling and
> therefore
> >> >> had conclusive proof that the certificate was issued.
> >> >
> >> >
> >> If a CA key was revoked and a certificate a user is checking has
> been
> >> issued after  this revocation what status should be returned?
> Revoked
> >> does not look right - it is not in the CRL. Thus, notIssued seems
> one
> >> logical possibility.
> >>
> >> Irene

-- 
---------------------------------------------------------------------
Ambarish Malpani
Architect					       (650) 849-9880
ValiCert, Inc.				        [email-masked]
3160 W. Bayshore Road		              http://www.valicert.com
Palo Alto, CA 94303

Date: Fri, 26 Jun 1998 14:10:38 -0400
To: Michael Myers <[email-masked]>
From: Irene Gassko <[email-masked]>
Subject: Re: New OCSP draft
Cc: IETF PKIX <[email-masked]>
Sender: [email-masked]

At 09:34 AM 6/26/98 -0700, Michael Myers wrote:
>Irene,
>
>At 11:32 AM 6/26/98 -0400, Irene Gassko wrote:
>>
>>If a CA key was revoked and a certificate a user is checking has been 
>>issued after  this revocation what status should be returned? Revoked 
>>does not look right - it is not in the CRL. Thus, notIssued seems one 
>>logical possibility.
>
>
>Good catch.  It would be more appropriate however to add a cARevoked value
>to the RevokedInfo syntax of CertStatus.  This will ensure that the logic
>used to handle a "revoked" CertStatus is activated.  I would expect this
>logic to be more critical of accepting a certificate than that which might
>be written to handle notIssued.  This would be important in the event of
>compromised CA key.
>
>CertStatus ::= CHOICE {
>   notRevoked   [0]  IMPLICIT NULL,
>   revoked      [1]  IMPLICIT RevokedInfo,
>   unknown      [2]  IMPLICIT UnknownInfo }
>
>RevokedInfo ::= { . . . amend to provide a cARevoked reason code . . . }

I like this. I guess we need to provide enough info (e.g. which CA is
revoked) to enable the user to check when CA was revoked and why.
For example, if the key was compromised and the certificate was
created with this key after its revocation, we want to always reject
such a certificate. However, if the key was changed because an
employee left and someone purchased a certificate from him while
he still worked, this certificate may be perfectly legitimate.
>
>Mike
>
Irene
 
Irene Gassko                                     Bell Laboratories
Lucent Technologies                          Secure Technologies Dept.
300 Brickstone Square                       voice:   (978) 691-3270
6-th Floor                                          e-mail: [email-masked]
Andover, MA 01845                            fax:      (978) 691-3186

Cc: Andreas Berger <[email-masked]>, Michael Myers <[email-masked]>, IETF PKIX <[email-masked]>
Original-Cc: Andreas Berger <[email-masked]>, Michael Myers <[email-masked]>, IETF PKIX <[email-masked]>
Date: Fri, 26 Jun 1998 14:01:26 -0400
To: Ambarish Malpani <[email-masked]>
From: Irene Gassko <[email-masked]>
Subject: Re: New OCSP draft
Original-Cc: Andreas Berger <[email-masked]>, Michael Myers <[email-masked]>, IETF PKIX <[email-masked]>
Sender: [email-masked]

<html>
At 10:33 AM 6/26/98 -0700, Ambarish Malpani wrote:<br>
&gt;Hi Irene,<br>
&gt;=A0=A0=A0 OCSP returns the status of the certificate. If you are trying
to<br>
&gt;check a whole<br>
&gt;chain, you should also query for the status of the CA of the<br>
&gt;certificate, at<br>
&gt;which point you will find out the the CA has been compromised.<br>
&gt;<br>
&gt;CA1 issues CA cert to CA2<br>
&gt;CA2 issues regular cert to EU (end user)<br>
&gt;<br>
&gt;If CA2's key is compromised, then any application that only
trusts<br>
&gt;CA1 and is trying to verify the status of EU, should also, at the
same<br>
&gt;time, verify the status of CA2.<br>
&gt;<br>
&gt;Query { statusOf(EU), statusOf(CA2) }<br>
&gt;Response { EU-notRevoked, CA2-revoked }<br>
<br>
This is ambiguous, IMO. How do we distinguish two different cases:<br>
<br>
1. CA2 was revoked <b><i>after</i> </b>the certificate was created (which
for many<br>
applications will be fine).<br>
2. CA2 was revoked <b><i>before</b></i> the certificate was created
(which makes<br>
certificate useless, because it most probably was forged).<br>
<br>
&gt;<br>
&gt;Would this solve the problem? I would prefer not trying to make<br>
&gt;statements<br>
&gt;about two different certs/levels of hierarchy at one time.<br>
<br>
Agreed.<br>
<br>
&gt;<br>
&gt;Regards,<br>
&gt;Ambarish<br>
&gt;<br>
&gt;<br>
&gt;Irene Gassko wrote:<br>
&gt;&gt; <br>
&gt;&gt; &gt;&gt; &gt;3. CertStatus<br>
&gt;&gt; &gt;&gt; &gt;I would really love to see the addition of
notIssued to the list of<br>
&gt;&gt; &gt;&gt; &gt;result codes. This would mean &quot;I know about
the CA and all the<br>
&gt;&gt; &gt;&gt; &gt;certificates it has ever issued, but the
certificate presented is *not*<br>
&gt;&gt; &gt;&gt; &gt;on my list&quot;.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; This request has come up before.=A0 The primary reason
it's not in the<br>
&gt;&gt; &gt;&gt; list of result codes is that it seems unlikely an OCSP
requester would<br>
&gt;&gt; &gt;&gt; be querying on a certificate it was not already
handling and therefore<br>
&gt;&gt; &gt;&gt; had conclusive proof that the certificate was
issued.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; If a CA key was revoked and a certificate a user is checking has
been<br>
&gt;&gt; issued after=A0 this revocation what status should be returned?
Revoked<br>
&gt;&gt; does not look right - it is not in the CRL. Thus, notIssued
seems one<br>
&gt;&gt; logical possibility.<br>
&gt;&gt; <br>
&gt;&gt; Irene<br>
&gt;&gt; <br>
&gt;&gt; Irene Gassko=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Bell
Laboratories<br>
&gt;&gt; Lucent Technologies=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0 Secure Technologies
Dept.<br>
&gt;&gt; 300 Brickstone Square=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0 voice:=A0=A0 (978)
691-3270<br>
&gt;&gt; 6-th Floor=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 e-mail:
[email-masked]<br>
&gt;&gt; Andover, MA 01845=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 fax:=A0=A0=A0=A0=A0 (978)
691-3186<br>
&gt;<br>
&gt;-- <br>
&gt;---------------------------------------------------------------------<br=
>
&gt;Ambarish Malpani<br>
&gt;Architect     =A0=A0=A0=A0=A0=A0 (650) 849-9880<br>
&gt;ValiCert, Inc.    =A0=A0=A0=A0=A0=A0=A0 [email-masked]<br>
&gt;3160 W. Bayshore Road  =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
<a href=3D"http://www.valicert.com/"=
 eudora=3D"autourl">http://www.valicert.com</a><br>
&gt;Palo Alto, CA 94303<br>
&gt;=20
<BR>
<div>Irene
Gassko&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Bell Laboratories</div>
<div>Lucent
Technologies&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;
Secure Technologies Dept.</div>
<div>300 Brickstone
Square&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
voice:&nbsp;&nbsp; (978) 691-3270</div>
<div>6-th
Floor&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;
e-mail: [email-masked]</div>
Andover, MA
01845&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;
fax:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (978) 691-3186
</html>

Date: Fri, 26 Jun 1998 10:55:03 -0700
To: Paul Koning <[email-masked]>, [email-masked]
From: Tony Bartoletti <[email-masked]>
Subject: Re: Last Call - Profile (altName Chaining)
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

At 10:41 AM 6/26/98 -0400, Paul Koning wrote:
>
>So did we settle that alternate names CAN be used for chaining?  The
>outcome of that debate wasn't clear to me...

It was not clear to me either.  As I recall, arguments revolved
around (possibly) conflicted overloading of the poor and abused
critical extension bit.  Clarification is in order.

___tony___

Tony Bartoletti                                             LL
SPI-NET GURU                                             LL LL
Computer Security Technology Center                   LL LL LL
Lawrence Livermore National Lab                       LL LL LL
PO Box 808, L - 303                                   LL LL LLLLLLLL
Livermore, CA 94551-9900                              LL LLLLLLLL
email: [email-masked]   phone: 510-422-3881             LLLLLLLL

Date: Fri, 26 Jun 1998 10:46:41 -0700
From: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
To: Peter Sylvester <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: New OCSP draft
Sender: [email-masked]

Hi Peter, Andreas,

Peter Sylvester wrote:
> 
> > Problem is: I do not want to ask for the validity of a key, I have to
> > ask for the validity of a specific certificate, which is identified by
> > issuer and serial. Perhaps we could add:
> >
> >       serialNumber    CertificateSerialNumber OPTIONAL
> >       certificateHash CertificateHash         OPTIONAL
> >
> > Then we might need an additional response code: certificateHashRequried
> I can live with that.
> 
> Anyway, it seems to me that Certificatehash for identification is sufficient:
> - If ever there would be a duplicate, an issuer can easily avoid that
> - If ever there would be a duplicate, we probably have a problem with hashing?

Yes, the Certificatehash is sufficient for identifying a certificate,
however,
it assumes that an OCSP responder somehow has access to the hashes of
all
certificates issued by a CA. That is not necessarily true. It is quite
reasonable for an OCSP responder to be something that basically has
access to
the latest CRLs from certain CAs and that issues responses for those CAs
to
parties that trust that responder. Trying to identify certificates by
their
hashes would break that model.

Also, having a bunch of different ways of identifying a certificate will
either
make writing OCSP responders quite difficult, or result in a bunch of
non-interoperable implementations.

> 
> >
> > > I would like to propose another transport protocol:
> > > OCSP over UPD:
> > >
> > > The idea is to put an OCSP request into one UDP request.
> > > In order to identify results one need a sequence number. This
> > > can be done in the follonwg way: The UDP packet is filled using
> > > an sequence of an INTEGER containing the seuence number, the OCSPrequest.
> > > Similar for the response. (Where is my DNS and BIND handbook :-)
> >
> > Good idea, but we should mandate: SHOULD only be used in local
> > environments.
> 
> Why that?
>

I don't think I have a strong opinion on the UDP issue (I stopped using
it
when I found out about TCP :-)). If enough people in this group feel
that
UDP is important to support and if Peter is willing to write up
the UDP spec :-), we can put it in.

Regards,
Ambarish

-- 
---------------------------------------------------------------------
Ambarish Malpani
Architect					       (650) 849-9880
ValiCert, Inc.				        [email-masked]
3160 W. Bayshore Road		              http://www.valicert.com
Palo Alto, CA 94303

Date: Fri, 26 Jun 1998 10:33:39 -0700
From: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
To: Irene Gassko <[email-masked]>
CC: Andreas Berger <[email-masked]>, Michael Myers <[email-masked]>, IETF PKIX <[email-masked]>
Subject: Re: New OCSP draft
Sender: [email-masked]

Hi Irene,
    OCSP returns the status of the certificate. If you are trying to
check a whole
chain, you should also query for the status of the CA of the
certificate, at
which point you will find out the the CA has been compromised.

CA1 issues CA cert to CA2
CA2 issues regular cert to EU (end user)

If CA2's key is compromised, then any application that only trusts
CA1 and is trying to verify the status of EU, should also, at the same
time, verify the status of CA2.

Query { statusOf(EU), statusOf(CA2) }
Response { EU-notRevoked, CA2-revoked }

Would this solve the problem? I would prefer not trying to make
statements
about two different certs/levels of hierarchy at one time.

Regards,
Ambarish

Irene Gassko wrote:
> 
> >> >3. CertStatus
> >> >I would really love to see the addition of notIssued to the list of
> >> >result codes. This would mean "I know about the CA and all the
> >> >certificates it has ever issued, but the certificate presented is *not*
> >> >on my list".
> >>
> >> This request has come up before.  The primary reason it's not in the
> >> list of result codes is that it seems unlikely an OCSP requester would
> >> be querying on a certificate it was not already handling and therefore
> >> had conclusive proof that the certificate was issued.
> >
> >
> If a CA key was revoked and a certificate a user is checking has been
> issued after  this revocation what status should be returned? Revoked
> does not look right - it is not in the CRL. Thus, notIssued seems one
> logical possibility.
> 
> Irene
> 
> Irene Gassko                                     Bell Laboratories
> Lucent Technologies                          Secure Technologies Dept.
> 300 Brickstone Square                       voice:   (978) 691-3270
> 6-th Floor                                          e-mail: [email-masked]
> Andover, MA 01845                            fax:      (978) 691-3186

-- 
---------------------------------------------------------------------
Ambarish Malpani
Architect					       (650) 849-9880
ValiCert, Inc.				        [email-masked]
3160 W. Bayshore Road		              http://www.valicert.com
Palo Alto, CA 94303

Date: Fri, 26 Jun 1998 10:28:23 -0700
To: Paul Koning <[email-masked]>, [email-masked]
From: Tony Bartoletti <[email-masked]>
Subject: Re: Last Call - Profile
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

At 10:41 AM 6/26/98 -0400, Paul Koning wrote:
>>>>>> "Bob" == Bob Jueneman <[email-masked]> writes:
>
> Bob> Anne Anderson wrote:

[tony snips]

> >> Objection 2: If PKIX does mandate X501 names for chaining, then
> >> the RFC2247 "DC=" attribute should be added to the list of
> >> recommended name attributes to be used in section 4.1.2.4.
>
> Bob> I would have no objection to that, although personally I think
> Bob> that decomposing all of the domains into individual components
> Bob> is unnecessary. But if someone needs that ability, that's OK
> Bob> with me.
>
>So did we settle that alternate names CAN be used for chaining?  The
>outcome of that debate wasn't clear to me...  Because that's what you
>need for DNS names if you don't want to decompose them into DC pieces
>(right)?
>
>	paul

I don't believe that decomposition was a hard requirement.  An e-mail
or DNS name could be used as a "blob" DN component, but (twas argued)
this would make directory searches inefficient.  Listing DNS components
individually would lend itself to hierarchical structuring of directory 
searches.  (IMO, this is a marginal argument against "blob" DN entries.)

___tony___

Tony Bartoletti                                             LL
SPI-NET GURU                                             LL LL
Computer Security Technology Center                   LL LL LL
Lawrence Livermore National Lab                       LL LL LL
PO Box 808, L - 303                                   LL LL LLLLLLLL
Livermore, CA 94551-9900                              LL LLLLLLLL
email: [email-masked]   phone: 510-422-3881             LLLLLLLL

Date: Fri, 26 Jun 1998 09:34:08 -0700
To: Irene Gassko <[email-masked]>, Andreas Berger <[email-masked]>
From: Michael Myers <[email-masked]>
Subject: Re: New OCSP draft
Cc: Michael Myers <[email-masked]>, Ambarish Malpani <[email-masked]>, IETF PKIX <[email-masked]>
Sender: [email-masked]

Irene,

At 11:32 AM 6/26/98 -0400, Irene Gassko wrote:
>
>If a CA key was revoked and a certificate a user is checking has been 
>issued after  this revocation what status should be returned? Revoked 
>does not look right - it is not in the CRL. Thus, notIssued seems one 
>logical possibility.

Good catch.  It would be more appropriate however to add a cARevoked value
to the RevokedInfo syntax of CertStatus.  This will ensure that the logic
used to handle a "revoked" CertStatus is activated.  I would expect this
logic to be more critical of accepting a certificate than that which might
be written to handle notIssued.  This would be important in the event of
compromised CA key.

CertStatus ::= CHOICE {
   notRevoked   [0]  IMPLICIT NULL,
   revoked      [1]  IMPLICIT RevokedInfo,
   unknown      [2]  IMPLICIT UnknownInfo }

RevokedInfo ::= { . . . amend to provide a cARevoked reason code . . . }

Mike

Cc: Michael Myers <[email-masked]>, Ambarish Malpani <[email-masked]>, IETF PKIX <[email-masked]>
Original-Cc: Michael Myers <[email-masked]>, Ambarish Malpani <[email-masked]>, IETF PKIX <[email-masked]>
Date: Fri, 26 Jun 1998 11:32:25 -0400
To: Andreas Berger <[email-masked]>
From: Irene Gassko <[email-masked]>
Subject: Re: New OCSP draft
Original-Cc: Michael Myers <[email-masked]>, Ambarish Malpani <[email-masked]>, IETF PKIX <[email-masked]>
Sender: [email-masked]

>> >3. CertStatus
>> >I would really love to see the addition of notIssued to the list of
>> >result codes. This would mean "I know about the CA and all the
>> >certificates it has ever issued, but the certificate presented is *not*
>> >on my list".
>> 
>> This request has come up before.  The primary reason it's not in the
>> list of result codes is that it seems unlikely an OCSP requester would
>> be querying on a certificate it was not already handling and therefore
>> had conclusive proof that the certificate was issued.
>
>
If a CA key was revoked and a certificate a user is checking has been 
issued after  this revocation what status should be returned? Revoked 
does not look right - it is not in the CRL. Thus, notIssued seems one 
logical possibility.

Irene

Irene Gassko                                     Bell Laboratories
Lucent Technologies                          Secure Technologies Dept.
300 Brickstone Square                       voice:   (978) 691-3270
6-th Floor                                          e-mail: [email-masked]
Andover, MA 01845                            fax:      (978) 691-3186

From: "Paul Lambert" <[email-masked]>
To: "Bob Jueneman" <[email-masked]>
cc: [email-masked]
Date: Fri, 26 Jun 1998 11:10:26 -0400
Subject: Re: Last Call - Profile
Sender: [email-masked]

Bob,

I strongly disagree with your advocacy of the mandatory use of X501 names
in PKIX:

>we ought to at least support the means for creating unambiguous names.

This is not necessary.  Obviously DNS and e-mail addresses are much better
names.  We should not force the mandatory use ofX501 names just to support
the systems that use X500 and LDAP directories.  There are are other better
approaces that we should allow to evolve.

Paul

"Bob Jueneman" <[email-masked]> on 06/25/98 06:13:08 PM

To:   [email-masked], [email-masked]
cc:   [email-masked] (bcc: Paul Lambert/Certicom)
Subject:  Re: Last Call - Profile

Anne Anderson wrote:

>Objection 1: PKIX should not mandate use of X501 names for chaining.
>Not all PKI's store certificate information in an X500 directory.

I would respectfully disagree with Anne's objection number 1.  Although
not all PKI's will store certificate information in X.500 or X.500-like
(e.g., LDAP)
directories, I would expect that many will do so. If we do not settle on
some form of acceptable schema for storing certificates, we won't have
any kind of interoperability at all.  We've been using and assuming the
use of DNs in certificates for at least five years now, so it seems a bit
late
to change such a basic assumption.  But if you have something that for
some reason I don't understand cannot be formed into an attribute that
X.500 will accept, you are free to use an alternate subject name.
>
>--------------------------------------------------------------------
>Objection 2: If PKIX does mandate X501 names for chaining, then the
>RFC2247 "DC=" attribute should be added to the list of recommended
>name attributes to be used in section 4.1.2.4.

I would have no objection to that, although personally I think that
decomposing
all of the domains into individual components is unnecessary. But if
someone needs that ability, that's OK with me.
>
>4.1.2.4 Issuer
>..
>   Standard sets of attributes have been defined in the X.500 series of
>   specifications.  This specification recommends that issuer names con-
>   tain only the following attribute types: country, organization,
>   organizational-unit, distinguished name qualifier, title, locality,
>   state or province name, common name (e.g., "Susan Housley"), surname,
>   given name, initials, and generationqualifier (e.g., "Jr." or "IV").
>   The syntax and associated object identifiers (OIDs) for these attri-
>   bute types are provided in the ASN.1 modules in Appendices A and B.
>
>[Insert: "domain component (i.e. RFC2247)" in the list of recommended
>name attributes.]
>

Anne's note jogged my memory in this area.  One of the major problems
with "locality" is that the semantics are exceptionally poorly defined
in X.521.  Is it a city or town, a real estate subdivision within a town,
a county, the Washington Metropolitan Area, Europe, the Internet,
the solar system, or what?  What purpose is it intended to serve?

In particular, does it serve as a reasonable name qualifier for the sake of
uniqueness?  Does it serve as a geographical or geopolitical region that
is sufficiently small that I might actually be able to find someone there?
Is it a substitute for stateOrProvince, for those countries that don't have
states, cantons, territories, parishes, etc., etc.?

I think that locality is essentially useless and will remain so until the
semantics are clarified. Since ISO has not seen fit to do so, I would
suggest that the IETF find another qualirifier that is more useful,
if necessary making up its own and registering it under a new OID.
Or we might want to go back and dredge through the NADF archives
to find their definition, which was quite specific -- down to the level of
unincorporated areas and even trailer parks, so long as they were on the
NIST tape listing such areas, at least within the US.

But while locality is so poorly defined as to be nearly useless, the list
also
omits the obviously necessary qualifier of streetAddress or postAddress,
in addition to what I believe is Anne's concern, the need for cyberspace
addresses, either in place of or in addition to physical addresses.

But in any case, whether we insist on globally unambiguous names or not,
we ought to at least support the means for creating unambiguous names.
And as long as at least some people believe that there is some purpose for
having a physical address of record for digitally signed transactions, in
order
to send the sheriff there if necessary, omitting a street address is an
egregious
oversight.

Bob

Robert R. Jueneman
Security Architect
Novell, Inc.
Network Products Group
122 East 1700 South
Provo, UT 84604
801/861-7387
[email-masked]

"Architects, like prophets and saints, are
usually years ahead of their time. For this
reason they are often difficult to live with
at home, especially if they turn out to be
right."

Date: Fri, 26 Jun 1998 10:41:57 -0400
From: Paul Koning <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call - Profile
Sender: [email-masked]

>>>>> "Bob" == Bob Jueneman <[email-masked]> writes:

 Bob> Anne Anderson wrote:
 >> Objection 1: PKIX should not mandate use of X501 names for
 >> chaining.  Not all PKI's store certificate information in an X500
 >> directory.

 Bob> I would respectfully disagree with Anne's objection number 1.
 Bob> Although not all PKI's will store certificate information in
 Bob> X.500 or X.500-like (e.g., LDAP) directories, I would expect
 Bob> that many will do so. If we do not settle on some form of
 Bob> acceptable schema for storing certificates, we won't have any
 Bob> kind of interoperability at all.  We've been using and assuming
 Bob> the use of DNs in certificates for at least five years now, so
 Bob> it seems a bit late to change such a basic assumption.  But if
 Bob> you have something that for some reason I don't understand
 Bob> cannot be formed into an attribute that X.500 will accept, you
 Bob> are free to use an alternate subject name.
 >>
 >> --------------------------------------------------------------------
 >> Objection 2: If PKIX does mandate X501 names for chaining, then
 >> the RFC2247 "DC=" attribute should be added to the list of
 >> recommended name attributes to be used in section 4.1.2.4.

 Bob> I would have no objection to that, although personally I think
 Bob> that decomposing all of the domains into individual components
 Bob> is unnecessary. But if someone needs that ability, that's OK
 Bob> with me.

So did we settle that alternate names CAN be used for chaining?  The
outcome of that debate wasn't clear to me...  Because that's what you
need for DNS names if you don't want to decompose them into DC pieces
(right)?

	paul

-- 
!-----------------------------------------------------------------------
! Paul Koning, NI1D, D-20853
! Xedia Corporation, 119 Russell Street, Littleton, MA 01460, USA
! phone: +1 978 952 6000 ext 115, fax: +1 978 952 6090
! email: [email-masked]
! Pgp:   27 81 A9 73 A6 0B B3 BE 18 A3 BF DD 1A 59 51 75
!-----------------------------------------------------------------------
! "The only purpose for which power can be rightfully exercised over 
!  any member of a civilized community, against his will, is to prevent
!  harm to others.  His own good, either physical or moral, is not
!  a sufficient warrant."    -- John Stuart Mill, "On Liberty" 1859

From: Peter Sylvester <[email-masked]>
Date: Fri, 26 Jun 1998 12:46:58 +0200
To: [email-masked]
Subject: Re: New OCSP draft
Cc: [email-masked]
Sender: [email-masked]

> Problem is: I do not want to ask for the validity of a key, I have to
> ask for the validity of a specific certificate, which is identified by
> issuer and serial. Perhaps we could add:
> 
> 	serialNumber    CertificateSerialNumber OPTIONAL
> 	certificateHash CertificateHash         OPTIONAL
> 
> Then we might need an additional response code: certificateHashRequried
I can live with that.

Anyway, it seems to me that Certificatehash for identification is sufficient: 
- If ever there would be a duplicate, an issuer can easily avoid that
- If ever there would be a duplicate, we probably have a problem with hashing?

> 
> > I would like to propose another transport protocol:
> > OCSP over UPD:
> > 
> > The idea is to put an OCSP request into one UDP request.
> > In order to identify results one need a sequence number. This
> > can be done in the follonwg way: The UDP packet is filled using
> > an sequence of an INTEGER containing the seuence number, the OCSPrequest.
> > Similar for the response. (Where is my DNS and BIND handbook :-)
> 
> Good idea, but we should mandate: SHOULD only be used in local
> environments.

Why that? 
 
> 

Date: Fri, 26 Jun 1998 10:43:03 +0200
From: Andreas Berger <[email-masked]>
To: Peter Sylvester <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: New OCSP draft
Sender: [email-masked]

> > 3. CertStatus
> > I would really love to see the addition of notIssued to the list of
> > result codes. This would mean "I know about the CA and all the
> > certificates it has ever issued, but the certificate presented is *not*
> > on my list".
> This might give you a possibility to recover ALL certificates in a CA
> by using iteration through the serialnumbers, once you have guessed
> some pattern, thus doing something like a list operation in directory.
> 
> one can avoid the problem by allocating non-consecutive serial numbers
> for exemple, but why should one add restrictions to implementators of
> the CA about how to choose serial numbers in order to avoid this
> possible attack.
> 
> In fact I don't like the serialnumber in the CertID.
> Why not a hash of the key? If you HAVE a cert, THEN you can get
> make a request, but not if you DO NOT have it. Iterating to
> hashes of public keys is not that easy.
Problem is: I do not want to ask for the validity of a key, I have to
ask for the validity of a specific certificate, which is identified by
issuer and serial. Perhaps we could add:

	serialNumber    CertificateSerialNumber OPTIONAL
	certificateHash CertificateHash         OPTIONAL

Then we might need an additional response code: certificateHashRequried

> I would like to propose another transport protocol:
> OCSP over UPD:
> 
> The idea is to put an OCSP request into one UDP request.
> In order to identify results one need a sequence number. This
> can be done in the follonwg way: The UDP packet is filled using
> an sequence of an INTEGER containing the seuence number, the OCSPrequest.
> Similar for the response. (Where is my DNS and BIND handbook :-)

Good idea, but we should mandate: SHOULD only be used in local
environments.

Andreas
-- 
Microsoft -- definitly needs Viagra

Date: Fri, 26 Jun 1998 10:34:25 +0200
From: Andreas Berger <[email-masked]>
To: Michael Myers <[email-masked]>
CC: Ambarish Malpani <[email-masked]>, IETF PKIX <[email-masked]>
Subject: Re: New OCSP draft
Sender: [email-masked]

Mike,

> >1. OCSPResponseStatus:
> >certRequired: How are situations handled when status for multiple
> >certificates is requested and for just on the certificate is required.
> >This result code should probably be moved to "CertStatus" so that an
> >OCSP responder can produce this answer for each requested certificate
> >individually.
> 
> We did put in some syntax to provide per-cert granularity in the event of
> multi-cert requests.  The expectation regarding certRequired was that this
> would apply globally to all certs in a multi-cert request.
Considering the comment from Peter, this could perhaps be changed to:

successful, malformed request (optional), internal error, tryLater,
sigRequired

with certRequired moved to CertStatu (not nice). Perhaps:

SingleResponse ::= SEQUENCE {
	certID		certID,
	responseStatus	responseStatus,
	CertStatus	certStatus
... (unchanged)
}

ResponseStatus ::= CHOICE {
	tryLater
	certRequired
}

caReferral could be added here as well, altough this would add the whole
GeneralName syntax to OCSP.

> Would something along the following lines meet your need?
> 
> 4.4.5 CA Referral
> 
> To simply configuration management of OCSP requesters, OCSP responders
> may respond with a referral response extension in responseExtensions.
> The referral value will be identified by the object identifier
> id-pkix-ocsp-referral, while the extnValue provides a value the client
> should use in acquiring a response.
> 
> id-pkix-ocsp-referral     OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 }
> --value of syntax GeneralName
This is fine with me.

> >3. CertStatus
> >I would really love to see the addition of notIssued to the list of
> >result codes. This would mean "I know about the CA and all the
> >certificates it has ever issued, but the certificate presented is *not*
> >on my list".
> 
> This request has come up before.  The primary reason it's not in the
> list of result codes is that it seems unlikely an OCSP requester would
> be querying on a certificate it was not already handling and therefore
> had conclusive proof that the certificate was issued.

Just an explanation:

The idea behind "not issued" is that certificates can remain valid even
after a key compromise of the CA since the OCSP/Directory services
serves as a second source of trust (that does not mean I like this
concept, it is just mentioned and described in the Law). So what we will
probably specify is that we give a Status of unknown (or revoked, to be
semantically compatible with the rest of the world) and a private
extension specifying the "not issued" (or can we specify such an
extension here?).

> 
> >4. OCSPRequest
> >Addition of an extension that allows a requester to specify the point in
> >time it wants information for. Then it is possible to ask: "I have a
> >signature produced last week, was the certificate used in that process
> >valid then?".
> 
> This requirement has been considered in earlier drafts of the protocol.
> It was dropped out in favor of simplicity, prior to the establishment
> of the extension mechanism.  However, it does seem a general enough
> requirement to establish a standard OCSP extension for those with a need.
> 
> Would something along the lines of the following text meet your need?
> 
> 4.4.6 Archive Reference
> 
> OCSP clients may be required to establish the validity of a signature
> when it was produced.  OCSP responders that are intended to support
> such a capability SHOULD recognize the ArchiveReference extension.
> This request extension is recognized as id-pkix-ocsp-archiveReference
> and its value will be of type GeneralizedTime.
> 
> id-pkix-ocsp-archiveReference    OBJECT IDENTIFIER ::= { id-pkix-ocsp 6 }
> --value of syntax GeneralizedTime
> 
> The producedAt value of the resulting response will be the current time
> (i.e. the time when the response was produced). Values for thisUpdate
> and nextUpdate will be as specified in section 2.4.
This seems to solve that issue. Question is: Should we allow that
per-Cert or per-Request (or both?).

Andreas
-- 
Microsoft -- definitly needs Viagra

Date: Thu, 25 Jun 1998 16:13:08 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: Re: Last Call - Profile
Sender: [email-masked]

Anne Anderson wrote:

>Objection 1: PKIX should not mandate use of X501 names for chaining.
>Not all PKI's store certificate information in an X500 directory.

I would respectfully disagree with Anne's objection number 1.  Although 
not all PKI's will store certificate information in X.500 or X.500-like (e.g., LDAP)
directories, I would expect that many will do so. If we do not settle on
some form of acceptable schema for storing certificates, we won't have
any kind of interoperability at all.  We've been using and assuming the
use of DNs in certificates for at least five years now, so it seems a bit late
to change such a basic assumption.  But if you have something that for
some reason I don't understand cannot be formed into an attribute that 
X.500 will accept, you are free to use an alternate subject name.
>
>--------------------------------------------------------------------
>Objection 2: If PKIX does mandate X501 names for chaining, then the
>RFC2247 "DC=" attribute should be added to the list of recommended
>name attributes to be used in section 4.1.2.4.

I would have no objection to that, although personally I think that decomposing 
all of the domains into individual components is unnecessary. But if 
someone needs that ability, that's OK with me.
>
>4.1.2.4 Issuer
>..
>   Standard sets of attributes have been defined in the X.500 series of
>   specifications.  This specification recommends that issuer names con-
>   tain only the following attribute types: country, organization,
>   organizational-unit, distinguished name qualifier, title, locality,
>   state or province name, common name (e.g., "Susan Housley"), surname,
>   given name, initials, and generationqualifier (e.g., "Jr." or "IV").
>   The syntax and associated object identifiers (OIDs) for these attri-
>   bute types are provided in the ASN.1 modules in Appendices A and B.
>   
>[Insert: "domain component (i.e. RFC2247)" in the list of recommended
>name attributes.]
>

Anne's note jogged my memory in this area.  One of the major problems 
with "locality" is that the semantics are exceptionally poorly defined
in X.521.  Is it a city or town, a real estate subdivision within a town, 
a county, the Washington Metropolitan Area, Europe, the Internet, 
the solar system, or what?  What purpose is it intended to serve?

In particular, does it serve as a reasonable name qualifier for the sake of
uniqueness?  Does it serve as a geographical or geopolitical region that
is sufficiently small that I might actually be able to find someone there?
Is it a substitute for stateOrProvince, for those countries that don't have 
states, cantons, territories, parishes, etc., etc.?

I think that locality is essentially useless and will remain so until the 
semantics are clarified. Since ISO has not seen fit to do so, I would 
suggest that the IETF find another qualirifier that is more useful,
if necessary making up its own and registering it under a new OID.
Or we might want to go back and dredge through the NADF archives
to find their definition, which was quite specific -- down to the level of 
unincorporated areas and even trailer parks, so long as they were on the
NIST tape listing such areas, at least within the US.

But while locality is so poorly defined as to be nearly useless, the list also
omits the obviously necessary qualifier of streetAddress or postAddress,
in addition to what I believe is Anne's concern, the need for cyberspace 
addresses, either in place of or in addition to physical addresses.

But in any case, whether we insist on globally unambiguous names or not,
we ought to at least support the means for creating unambiguous names.
And as long as at least some people believe that there is some purpose for
having a physical address of record for digitally signed transactions, in order
to send the sheriff there if necessary, omitting a street address is an egregious 
oversight.

Bob

Robert R. Jueneman
Security Architect
Novell, Inc.
Network Products Group
122 East 1700 South
Provo, UT 84604
801/861-7387
[email-masked]

"Architects, like prophets and saints, are 
usually years ahead of their time. For this
reason they are often difficult to live with
at home, especially if they turn out to be 
right."

Date: Thu, 25 Jun 1998 12:49:52 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Cc: [email-masked]
Subject: Re: SV: new profile submitted
Sender: [email-masked]

I absolutely and vociferously agree with Nada.

Changing the size of the key ID this late in the game is ABSOLUTELY 
UNACCEPTABLE for anything less than an end-of-the-world kind of problem.

As part of the effort to ramp up for the release of Novell's NetWare 5.0 next month,
we are in the process of generating Foundation Key Sets containing 7 certificates 
each, with an initial run of over 200,000 Foundation Key Sets. Running flat out
on our Wang XTS B3 machine, it will take about a month to complete this
process. Since we sent out over 200,000 copies of the beta alone, I would 
expect that by the end of the year, there will probably be on the order of 
3.5 million certificates out there and presumably in use, with people starting to 
generate their own certificates using our CA product.

All of the keyIDs in those certificates use a 160 bit SHA-1 hash.

I can only imagine what will happen if this impacts Windows 98.
The IETF will suddenly have become irrelevant.

If this is last call, I will have to vote a strenuous NO unless this is changed.  
It's simply too late in the game.

Bob

Robert R. Jueneman
Security Architect
Novell, Inc.
Network Products Group
122 East 1700 South
Provo, UT 84604
801/861-7387
[email-masked]

"Architects, like prophets and saints, are 
usually years ahead of their time. For this
reason they are often difficult to live with
at home, especially if they turn out to be 
right."

>>> Nada Kapidzic Cicovic <[email-masked]> 06/24 4:08 AM >>>
I do not understand the point of changing the key id calculation algorithm
this late in pkix part 1 last call. 

Is the size of the resulting key id the only problem with the old algorithm
definition?

Is this size really an issue for S/MIME messages?

I would prefer changing the definition back to what it was, since we have
already released the software implementing it in the old way, and we are
probably not the only one.

Regards,

Nada

At 20:55 6/23/98 -0400, Russ Housley wrote:
>The PKIX Part 1 key identifier will be used in S/MIME to identify the
>per-recipient information necessary for a recipient to perform decryption.
>As stated in a previous message, collisions are not a problem here.
>However, this key identifier will not be used to identify a particular
>certificate used by an originator to sign a message content.  Collisions
>could cause significant confusion in this circumstance.
>
>Russ
>
>
>At 12:11 PM 6/23/98 -0700, Paul Hoffman / IMC wrote:
>>I think the question here is whether or not it is useful to have the same
>>key identifier for both PKIX part 1 and OCSP. If it is, then we need to
>>choose one that works for both. Ambarish says that 60 bits, with the
>>possibility of collision, is not strong enough for OCSP. If that's true, we
>>need to decide if the two key identifiers have to be the same, or whether
>>we can use a shorter one for PKIX part 1 and a longer one for OCSP.
>>
>>--Paul Hoffman, Director
>>--Internet Mail Consortium
>> 
>

From: [email-masked]
To: Tim Polk <[email-masked]>
cc: [email-masked]
Date: Thu, 25 Jun 1998 08:23:38 -0400
Subject: Re: PKIX-1 - use of UTF8
Sender: [email-masked]

Tim Polk <[email-masked]> wrote:

>Consider the same chain CA0, CA1, CA2, and EE.  Let {x,y} mean a
>certificate issued by x with subject y.
>
>Case 1:  CA0 "switches" to UTF8
>
>CA0 issues two certificates {CA0(T61),CA0(UTF8)} and {CA0(UTF8),
>CA0(T61)}.  New users trusting CA0(UTF8) can now trust old paths;
>old users trusting CA0(T61).
>
>Case 2: CA2 "switches" to UTF8
>
>CA2 issues two certificates {CA2(T61),CA2(UTF8)} and {CA2(UTF8),
>CA2(T61)}.  The path from CA0 to the EE cert is still valid.
>
>CA2 requests a new cert from CA1 for its UTF8 encoded name.
>CA1 issues the cert {CA1,CA2(UTF8)} with the UTF8 name constraints.
>
>At this point, the path from CA0 to the EE certificate does not use ANY
>of the new certificates.
>
>The EE cert expires.  CA2 issues {CA2(UTF8), EE(UTF8)}.
>
>There are two paths from CA0 to the EE certificate.  The first path is
>the "old" path with the name rollover certificate.  It is NOT VALID
>becasue of the name constraints.  The second path uses {CA1,CA2(UTF8)}
>and does not use the name rollover certificate.  This path satisfies
>the name constraints and is valid.

This is basically saying that whenever the first entity changes over to
UTF8, everything above it in a trust chain will have to change over
immediately in order for the new name can be recognized.  Since CA2 doesn't
know which trust chain a verifier is going to want to use when trying to
determine EE's key, it'll have to request new certs from every CA that has
issued one for it, not just from CA1. That's not a migration - that's a
stampede :-)

How do the CAs know that a name encoded in T61 is the same as a name
encoded
in UTF8 (so they will just simply OK the new certificate request)?  Is this
expected to require manual approval, or is it automatic?  If it's
automatic,
it means they can do codeset conversion, so why not build that same ability
now into end-systems and avoid the requirement for a sudden switch-over?

John

From: Nilsson Hans <[email-masked]>
To: Russ Housley <[email-masked]>, [email-masked]
Subject: Subject Key Id algorithm
Date: Thu, 25 Jun 1998 07:11:14 +0100
Sender: [email-masked]

Regarding the question of how to compute subject Key Identifier:

I have just seen that the "ISO draft 15782: Banking - certificate Management
- Part 1: Public Key Certificates" also recommends 60 bits hash as follows:

"When this extension is populated, CAs may use a 60 bit SHA-1 hash of the
subject's public key as the subjectKeyIdentifier" (and then a reference to
ISO 10118-3: Information Technology - Security techniques - Hashfunctions -
Part 3: Dedicated hash functions)

The only difference is then the leading 0100.

Hans

Date: Wed, 24 Jun 1998 15:15:07 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: RE: PKIX-1 - use of UTF8
Sender: [email-masked]

I agree with Tim here. The character set issue is unbounded and is very
likely to change over time. Case matching and composition is only easy for
Latin-based characters, and even then has wrinkles that typical
implementors are sure to get wrong (such as locale-based sorting and
capitalization rules). I think the best thing to do is to tell people not
to rely on exclusion rules that are based on ranges of non-ASCII characters
and be done with it, since trying to over-specify now will still lead to
changes in the future when the Unicode folks change the rules, which they
might.

--Paul Hoffman, Director
--Internet Mail Consortium

From: William Bellamy <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: draft-ietf-pkix-ipki-part1-08.txt
Date: Wed, 24 Jun 1998 13:12:32 -0700
Sender: [email-masked]

> Hi,
> 
> In section 4.1.2.6 Subject I read:
> Implementations of this specification should be prepared to receive the
> following X.501 attribute types: country, organization,
> organizational-unit, distinguished name qualifier, title, locality, state
> or province name, common name (e.g., "Susan Housley"), surname, given
> name, initials, and generationqualifier (e.g., "Jr." or "IV").
> I take this to mean that one of each of these attributes may be present.
> It is not clear if more than one organizational-units are permitted. My
> interpretation is that only one could be present. Can you confirm this
> reading?
> Thanks,
> William Bellamy
> Microsoft Critical Problem Resolution
> 

Date: Wed, 24 Jun 1998 15:03:07 -0400
To: Peter Whittaker <[email-masked]>, "[email-masked]'" <[email-masked]>
From: Tim Polk <[email-masked]>
Subject: RE: PKIX-1 - use of UTF8
Cc: [email-masked]
Sender: [email-masked]

Peter,

Technically, you are correct.  As you say, "the rules of DN comparison
indicate that the character sets used to encode data in DNs are irrelevant,
that it is the characters themselves that must be compared." These rules
are reasonable to implement for PrintableString and T61, but quickly become
very difficult when you add BMPString, UniversalString, or UTF8 to the mix.
 Constructed characters and undefined case make this really hard.

The IESG, and PKIX profile in turn, is commited to support for UTF8.  On
the other hand, implementers in the PKIX group have indicated the full
range of codeset comparison is unreasonable.  If they are going to support
UTF8, the problem must be bounded.

The current draft of the PKIX profile explicitly permits case-sensitive
comparison of names encoded in UTF8 or BMPString, without resolution of
constructed characters or compacting white space. It also permits an
implementation to assume that names encoded in different codesets are
different.

As a result, a PKIX compliant implementation meeting these minimal
requirements might not recognize all paths that a "full" implementation
(one that means all the X.5xx rules) would recognize. However, the PKIX
compliant implementation wouldn't accept invalid ones, either.

John Wray has identified a shortcoming in this approach.  In some cases,
the excluded subtrees mechanism might result in acceptance of a path by a
PKIX implementation that would be rejected by a "full" implementation.
This could happen if the excluded subtrees definition used different case,
uncompacted whitespace, or constructed characters that did not appear in
the certificate DNs.

(This also implies that "full" implementations must reject any
certification path with an unrecognized codeset in the excluded subtrees
field!  You can't be sure what it maps to, so you can't be sure that its
satisfied.)

As I understand it, a lot of care went into the certificate and CRL design
so that there was only one way to encode it. Even if you unroll it, store
it in a database, and reconstruct it later, the signature should validate.
Of course, that only works if you store the DN as a binary blob!  The X.5xx
name comparison rules are incompatible with that premise since white space,
code set choice, constructed characters, etc. all result in different
encodings of equivalent names.  Worse yet, I'm afraid that we haven't
discovered all the complications.

Stating that names encoded differently *are different* seems faithful to
the original intent.  Of course, I wasn't there so I may be wrong.  Could
just be wishful thinking.

Regardless of the X.509 authors' intent, I believe that it is useful to
bound the name comparison problem.  Let's set the bar at a reasonable
height so we know what we can count on.

Sorry for ranting on like this, but character sets have become the bane of
my existence!  Seriously, they are one of the thorniest issues remaining.
I am afraid that we'll build a global PKI and have zero interoperability
because of character set issues.  (I can see myself trying to explain to
the lab director why he can't validate certification paths from Singapore
or Japan.  And I don't like what I see!) 

Tim

At 11:13 AM 6/24/98 -0400, Peter Whittaker wrote:
>> Consider a trust-path CA0 -> CA1 -> CA2 -> EE, using current PKIX
>> certificates (i.e. names expressed using printable or 
>> T61/Latin-1 strings), being evaluated by an end-entity that follows
>> the current matching rules.
>> Each CA cert specifies permitted subtree name constraints.  
>> On January 1, 2003, the rollover starts.  Let's say the cert issued
>> by CA1 for CA 2 is the first to expire.  According to the above, CA1
>> is supposed to create a new certificate for CA2 using UTF8 strings.
>> OK, it goes ahead and does that.  Now, an end-entity tries to
>> evaluate the trust chain - it'll fail, because the permitted subtree
>> constraints imposed on CA1 by the CA0->CA1 cert don't allow for the
>> subtree containing CA2's UTF8 name, only its T.61 name.  I think
>> everything stays broken until all the certs are replaced.
>> Name rollover certs don't help this case.
>
>Shouldn't the rules of DN comparison apply in this case?  And don't the
>rules of DN comparison indicate that the character sets used to encode
>data in DNs are irrelevant, that it is the characters themselves that
>must be compared?
>
>If the certificate verifier must DER-encode the certificate prior to
>performing signature validation, they must take into account character
>sets while performing the encoding.  Once they have verified a
>certificate, that is, they have verified that the signature is valid,
>they extract whatever data is pertinent and use it appropriately.
>
>In the case of extracting and comparing DNs, one in the subject field
>of one certificate, the other in the subtree field of another, the rules
>of DN comparison would apply, and it would be legitimate for the
>user to convert a character representation from one set (say, T.61) to
>that of another set (say, BMPString), in order to verify that the
>characters represented are the same.  Or, the user could convert both
>encodings, that is, the representations of characters in the two DNs,
>to a third encoding (their local character table) in order to compare
>the strings.
>
>The important thing is that when comparing DNs, character data in the
>DNs are compared on a character-by-character basis, not on the basis
>of the encoding that results from representing those characters in any
>particular character set.
>
>An 'a' is an 'a' is 'a', be it manipulated in ASCII, T.61, EBCDIC, or
>sign language.
>
>pww
>
>
>Attachment Converted: "c:\program files\eudora\attach\Peter Whittaker
(E-mail).vcf"
>

From: Peter Sylvester <[email-masked]>
Date: Wed, 24 Jun 1998 19:48:24 +0200
To: [email-masked], [email-masked]
Subject: Re: New OCSP draft
Cc: [email-masked]
Sender: [email-masked]

> First of all, I like the new draft better then the previous version, a
> lot of the issues that I had problems with were resolved. I would like
> to make some comments on the protocol.
Fully agree, we also would like to make some comments:

The following paragraph may include something like: 
"Some legislation requires online checking of a certificate status. This
can be achieved by this protocol;" 

" In lieu of or as a supplement to checking against a periodic CRL, it
  may be necessary to obtain timely status regarding a certificate's
  revocation state (cf. PKIX Part 1, Section 3.3). Examples include
  high- value funds transfer or large stock trades.

> 
> As a preface, we try to specify a profile for OCSP for use in the
> on-line revocation check mandated in the German Signature Law. So some
> of the comments I make are with that application in mind.
> 
> 1. OCSPResponseStatus:
> certRequired: How are situations handled when status for multiple
> certificates is requested and for just on the certificate is required.
> This result code should probably be moved to "CertStatus" so that an
> OCSP responder can produce this answer for each requested certificate
> individually.
Or: when during the checking of the cert one cert information is 
temporarily not available. 

> 
> 2. SingleResponse/CertStatus
> Shouldn't possibility of "I do know the CA but I am unable to answer the
> request, pls. ask here" be added to a response? This would minimize the
> configuration on the client.
I second that. if the request is for a single cert this might be done
by an HTTP redirect, but it should be generalized inside OCSP.

Even with an AuthorityInfoAccess extension, the service provider 
may change. 

One might also consider some value added service provider that knows
where to look up.

> 
> 3. CertStatus
> I would really love to see the addition of notIssued to the list of
> result codes. This would mean "I know about the CA and all the
> certificates it has ever issued, but the certificate presented is *not*
> on my list".
This might give you a possibility to recover ALL certificates in a CA
by using iteration through the serialnumbers, once you have guessed
some pattern, thus doing something like a list operation in directory. 

one can avoid the problem by allocating non-consecutive serial numbers
for exemple, but why should one add restrictions to implementators of
the CA about how to choose serial numbers in order to avoid this
possible attack.

In fact I don't like the serialnumber in the CertID.
Why not a hash of the key? If you HAVE a cert, THEN you can get
make a request, but not if you DO NOT have it. Iterating to
hashes of public keys is not that easy.

In case of a request with a certificate, a response of notIssued may
make sense. 

   KeyHash ::= OCTET STRING --SHA-1 hash of responder's public key

Once we might discover that SHA-1 is not a good ? 

   The value for responseBytes consists of an OBJECT IDENTIFIER and a 
   response syntax identified by that OID encoded as an OCTET STRING:

   ResponseBytes ::=	SEQUENCE {
        responseType   OBJECT IDENTIFIER,
        response       OCTET STRING }

Do you really want encapsulation?  

=====    3.3 Signed Response Acceptance Requirements

One should be explicit: The validation may involve interaction with
the user. Attention: Recursion may occur. I want to validate a
signers cert, thus I may ask someone else and so on.

I would like to propose another transport protocol:
OCSP over UPD:

The idea is to put an OCSP request into one UDP request.
In order to identify results one need a sequence number. This
can be done in the follonwg way: The UDP packet is filled using
an sequence of an INTEGER containing the seuence number, the OCSPrequest.
Similar for the response. (Where is my DNS and BIND handbook :-)

The usage of the word   'SHALL' seems to be the ISO like one in
all cases. Wouldn't be MUST the better word? 

Peter Sylvester -- EdelWeb France 

Date: Wed, 24 Jun 1998 10:17:48 -0700
To: Andreas Berger <[email-masked]>, Ambarish Malpani <[email-masked]>
From: Michael Myers <[email-masked]>
Subject: Re: New OCSP draft
Cc: IETF PKIX <[email-masked]>
Sender: [email-masked]

Andreas,

Thanks for taking the time to read through the new draft.  It's taken us
longer than we would've like to get to this point.

Some responses on your comments below.

Mike

At 12:40 PM 6/24/98 +0200, Andreas Berger wrote:
>First of all, I like the new draft better then the previous version, a
>lot of the issues that I had problems with were resolved. I would like
>to make some comments on the protocol.
>
>As a preface, we try to specify a profile for OCSP for use in the
>on-line revocation check mandated in the German Signature Law. So some
>of the comments I make are with that application in mind.
>
>1. OCSPResponseStatus:
>certRequired: How are situations handled when status for multiple
>certificates is requested and for just on the certificate is required.
>This result code should probably be moved to "CertStatus" so that an
>OCSP responder can produce this answer for each requested certificate
>individually.

We did put in some syntax to provide per-cert granularity in the event of
multi-cert requests.  The expectation regarding certRequired was that this
would apply globally to all certs in a multi-cert request.

>
>2. SingleResponse/CertStatus
>Shouldn't possibility of "I do know the CA but I am unable to answer the
>request, pls. ask here" be added to a response? This would minimize the
>configuration on the client.

Would something along the following lines meet your need?

4.4.5 CA Referral

To simply configuration management of OCSP requesters, OCSP responders
may respond with a referral response extension in responseExtensions.
The referral value will be identified by the object identifier
id-pkix-ocsp-referral, while the extnValue provides a value the client
should use in acquiring a response.

id-pkix-ocsp-referral     OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 }
--value of syntax GeneralName

>3. CertStatus
>I would really love to see the addition of notIssued to the list of
>result codes. This would mean "I know about the CA and all the
>certificates it has ever issued, but the certificate presented is *not*
>on my list".

This request has come up before.  The primary reason it's not in the 
list of result codes is that it seems unlikely an OCSP requester would
be querying on a certificate it was not already handling and therefore
had conclusive proof that the certificate was issued.

>4. OCSPRequest
>Addition of an extension that allows a requester to specify the point in
>time it wants information for. Then it is possible to ask: "I have a
>signature produced last week, was the certificate used in that process
>valid then?".

This requirement has been considered in earlier drafts of the protocol.
It was dropped out in favor of simplicity, prior to the establishment
of the extension mechanism.  However, it does seem a general enough
requirement to establish a standard OCSP extension for those with a need.

Would something along the lines of the following text meet your need?

4.4.6 Archive Reference

OCSP clients may be required to establish the validity of a signature
when it was produced.  OCSP responders that are intended to support
such a capability SHOULD recognize the ArchiveReference extension.
This request extension is recognized as id-pkix-ocsp-archiveReference
and its value will be of type GeneralizedTime.

id-pkix-ocsp-archiveReference    OBJECT IDENTIFIER ::= { id-pkix-ocsp 6 }
--value of syntax GeneralizedTime

The producedAt value of the resulting response will be the current time
(i.e. the time when the response was produced). Values for thisUpdate
and nextUpdate will be as specified in section 2.4.

>
>THNX
>Andreas
>-- 
>Microsoft -- definitly needs Viagra
>
>

Date: Wed, 24 Jun 1998 11:13:31 -0400
To: [email-masked]
From: Hal Lockhart <[email-masked]>
Subject: Re: PKIX-1 - use of UTF8
Sender: [email-masked]

At 03:04 PM 6/23/98 -0400, [email-masked] wrote:

>I don't think that's true.  Under the assumption that the stated name
>comparison rules would be applied when evaluating name constraints as well
>as when chaining issuer and subject names, a system that implemented the
>PKIX matching rules might fail to enforce an excluded subtree constraint
>that a codeset-converting implementation would catch.  This would result in
>a system that implemented the PKIX-1 rules verifying a chain against the
>expressed intentions of one of the CAs in that chain, whereas a system that
>performed codeset conversion would correctly refuse to accept the chain.

Sigh.  I keep running into this general problem in different guises. I am
becoming increasingly convinced that any security mechanism of the sort
"allow everything except for ..." will eventually break.  At the very
least, it is on my list of things to avoid in software engineering, along
with implied acknowledgements and global variables. Yes, I know this is
X.509 and cannot be (quickly) changed.

Hal

====================================================================
Harold W. Lockhart Jr.               PLATINUM technology
Chief Technical Architect            8 New England Executive Park
Email: [email-masked]  Burlington, MA 01803 USA
Voice: (781)273-6406                 Fax: (781)229-2969
====================================================================

From: Peter Whittaker <[email-masked]>
To: "[email-masked]'" <[email-masked]>, Tim Polk <[email-masked]>
Cc: [email-masked]
Subject: RE: PKIX-1 - use of UTF8
Date: Wed, 24 Jun 1998 11:13:39 -0400
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------ =_NextPart_000_01BD9F82.AAA9D0A4
Content-Type: text/plain

> Consider a trust-path CA0 -> CA1 -> CA2 -> EE, using current PKIX
> certificates (i.e. names expressed using printable or 
> T61/Latin-1 strings), being evaluated by an end-entity that follows
> the current matching rules.
> Each CA cert specifies permitted subtree name constraints.  
> On January 1, 2003, the rollover starts.  Let's say the cert issued
> by CA1 for CA 2 is the first to expire.  According to the above, CA1
> is supposed to create a new certificate for CA2 using UTF8 strings.
> OK, it goes ahead and does that.  Now, an end-entity tries to
> evaluate the trust chain - it'll fail, because the permitted subtree
> constraints imposed on CA1 by the CA0->CA1 cert don't allow for the
> subtree containing CA2's UTF8 name, only its T.61 name.  I think
> everything stays broken until all the certs are replaced.
> Name rollover certs don't help this case.

Shouldn't the rules of DN comparison apply in this case?  And don't the
rules of DN comparison indicate that the character sets used to encode
data in DNs are irrelevant, that it is the characters themselves that
must be compared?

If the certificate verifier must DER-encode the certificate prior to
performing signature validation, they must take into account character
sets while performing the encoding.  Once they have verified a
certificate, that is, they have verified that the signature is valid,
they extract whatever data is pertinent and use it appropriately.

In the case of extracting and comparing DNs, one in the subject field
of one certificate, the other in the subtree field of another, the rules
of DN comparison would apply, and it would be legitimate for the
user to convert a character representation from one set (say, T.61) to
that of another set (say, BMPString), in order to verify that the
characters represented are the same.  Or, the user could convert both
encodings, that is, the representations of characters in the two DNs,
to a third encoding (their local character table) in order to compare
the strings.

The important thing is that when comparing DNs, character data in the
DNs are compared on a character-by-character basis, not on the basis
of the encoding that results from representing those characters in any
particular character set.

An 'a' is an 'a' is 'a', be it manipulated in ASCII, T.61, EBCDIC, or
sign language.

pww

------ =_NextPart_000_01BD9F82.AAA9D0A4
Content-Type: application/octet-stream;
	name="Peter Whittaker (E-mail).vcf"
Content-Disposition: attachment;
	filename="Peter Whittaker (E-mail).vcf"

BEGIN:VCARD
VERSION:2.1
N:Whittaker;Peter;;;
FN:Peter Whittaker (E-mail)
ORG:Entrust Technologies;
TITLE:
TEL;WORK;VOICE:+1 613 247 3485
TEL;HOME;VOICE:
TEL;WORK;FAX:+1 613 247 3401
ADR;WORK:;;750 Heron Road;Ottawa;Ontario;K1V 1A7;Canada
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:750 Heron Road=0D=0AOttawa, Ontario K1V 1A7=0D=0ACanada
ADR;HOME:;;;;;;Canada
LABEL;HOME;ENCODING=QUOTED-PRINTABLE:=0D=0A,  =0D=0ACanada
EMAIL;PREF;INTERNET:[email-masked]
REV:19980601T154022Z
END:VCARD

------ =_NextPart_000_01BD9F82.AAA9D0A4--

From: [email-masked]
To: Tim Polk <[email-masked]>
cc: [email-masked]
Date: Wed, 24 Jun 1998 10:51:28 -0400
Subject: Re: PKIX-1 - use of UTF8
Sender: [email-masked]

Tim Polk <[email-masked]> wrote:

>>Basically, the current rules appear to force us to retain today's
>>multiplicity of codesets indefinitely.  Mandating codeset-conversions
prior
>>to comparison lets us prepare for a future migration to a single codeset.
>>
>
>I don't think this is true.  I proposed the following solution to support
a hard
>cutover to UTF8 encodings in 2003 on a different thread:
>
>I think a hard cutover in 2003 could be managed, though. Certificates
*issued*
>after January 1, 2003 could be required to use the UTF8String encodings.
>The one exception would be "name rollover" certificates for CAs changing
>their own names to the UTF8String encodings.  (This sounds ugly, but we'll
>be doing it for key rollover anyway.  CAs can just do them both at the
same time.)
>
>Key rollover certificates are self-signed certificates (issuer = subject)
where the
>new signing key is certified by the old signing key, or vice-versa.   A
name rollover
>certificate would have the issuer name in the old (e.g., T61) encoding and
subject
>name in UTF8, or vice-versa.  I expect CAs to perform key rollover
regularly. A
>small amount of planning will allow the CA to combine the two functions -
that is
>name and key rollover can be performed together.
>
>I think this resolves the problem of codeset migration.  Am I missing
something?

Consider a trust-path CA0 -> CA1 -> CA2 -> EE, using current PKIX
certificates (i.e. names expressed using printable or T61/Latin-1 strings),
being evaluated by an end-entity that follows the current matching rules.
Each CA cert specifies permitted subtree name constraints.  On January 1,
2003, the rollover starts.  Let's say the cert issued by CA1 for CA 2 is
the first to expire.  According to the above, CA1 is supposed to create a
new certificate for CA2 using UTF8 strings.  OK, it goes ahead and does
that.  Now, an end-entity tries to evaluate the trust chain - it'll fail,
because the permitted subtree constraints imposed on CA1 by the CA0->CA1
cert don't allow for the subtree containing CA2's UTF8 name, only its T.61
name.  I think everything stays broken until all the certs are replaced.
Name rollover certs don't help this case.

John

Date: Wed, 24 Jun 1998 10:34:22 -0400 (EDT)
From: Anne Anderson - Sun Microsystems <[email-masked]>
Reply-To: Anne Anderson - Sun Microsystems <[email-masked]>
Subject: Re: Last Call - Profile
To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

Objection 1: PKIX should not mandate use of X501 names for chaining.
Not all PKI's store certificate information in an X500 directory.

--------------------------------------------------------------------
Objection 2: If PKIX does mandate X501 names for chaining, then the
RFC2247 "DC=" attribute should be added to the list of recommended
name attributes to be used in section 4.1.2.4.

4.1.2.4 Issuer
...
   Standard sets of attributes have been defined in the X.500 series of
   specifications.  This specification recommends that issuer names con-
   tain only the following attribute types: country, organization,
   organizational-unit, distinguished name qualifier, title, locality,
   state or province name, common name (e.g., "Susan Housley"), surname,
   given name, initials, and generationqualifier (e.g., "Jr." or "IV").
   The syntax and associated object identifiers (OIDs) for these attri-
   bute types are provided in the ASN.1 modules in Appendices A and B.
   
[Insert: "domain component (i.e. RFC2247)" in the list of recommended
name attributes.]

--------------------------------------------------------------------
Objection 3: If the intent is indeed to mandate use of X501 names for
chaining, section 4.1.2.6 "Subject" is ambiguous with respect to this mandate
and section 6.1 "Basic Path Validation" contradicts this mandate.  Locations
and suggested changes follow.

4.1.2.4  Issuer

   Certificate users must be prepared to process the issuer dis-
   tinguished name and subject distinguished name (see sec. 4.1.2.6)
   fields to perform name chaining for certification path validation
   (see section 6). Name chaining is performed by matching the issuer
   distinguished name in one certificate with the subject name in
   another.
   
[Is this the only way name chaining may be performed?

If so,

  change

    "Name chaining is performed..."
  
  to
  
    "Name chaining must be performed...".

If not,

  change
  
  "Name chaining is performed by matching the issuer distinguished name
  in one certificate with the subject name in another."
  
  to
  
  "Name chaining is performed by matching the non-null issuer distinguished name
  or (if issuer is null) the critical instance of issuerAltName in one certificate
  with the non-null subject distinguished name or (if subject is null) the
  critical instance of subjectAltName in another."
]

4.1.2.6  Subject
...
   If
   the subject is a CA (e.g., the basic constraints extension, as dis-
   cussed in 4.2.1.10, is present and the value of cA is TRUE,) then the
   subject field must be populated with a non-null distinguished name
   matching the contents of the issuer field (see sec. 4.1.2.4) in all
   certificates issued by the subject CA.  If subject naming information
   is present only in the subjectAltName extension (e.g., a key bound
   only to an email address or URI), then the subject name must be an
   empty sequence and the subjectAltName extension must be critical.

[If chaining may be done using issuerAltName and subjectAltName, then

  remove first sentence
  
if not, then

  change second sentence to
  
  "If subject is not a CA and subject naming information is present only
  in the subjectAltName extension..."
]

6.1 Basic Path Validation

...
         (4) the subject and issuer names chain correctly (that is, the
         issuer of this certificate was the subject of the previous cer-
         tificate.)  If the certificate has an empty sequence in the
         name field, name chaining will use the critical subjectAltNames
         and issuerAltNames fields.

[If chaining may be done using issuerAltName and subjectAltName, then leave
as is.

If not, then remove second sentence.
]   

Anne Anderson                 Email: [email-masked]
Sun Microsystems Laboratories   Tel: (978) 442-0928
2 Elizabeth Drive, UCHL03-205   Fax: (978) 250-5067
Chelmsford, MA 01824 USA

From: [email-masked]
To: Harald Alvestrand <[email-masked]>
cc: [email-masked]
Date: Wed, 24 Jun 1998 09:57:09 -0400
Subject: Re: PKIX-1 - use of UTF8
Sender: [email-masked]

harald Alvestrand <[email-masked]> writes:

>>In the following, I'm going to call a system that implements the
>>current PKIX-1 rules an "Old" system, and one that emits certificates
>>in UTF-8 a "New" system (under the assumption that UTF-8 is where
>>we'd like to get to).  Similarly, "Old Certificates" contain names
>>using the current PKIX-1 codeset selection rules, and "New
>>Certificates" use UTF-8.
>
>You are making the assumption here that the same codeset is used for
>all attributes of all names within a certificate.
>Is this a requirement of the infrastructure?

I don't think anything I said assumes that every attribute is encoded the
same way.  PKIX-1 currently specifies codeset selection rules for each
attribute value individually.  I'm assuming that in the future we would
like to migrate to UTF-8, or at least a smaller and simpler set of syntaxes
than the five we have today.

>>I think the big implementation problem with name comparisons isn't
>>codeset conversion, but instead concerns how to compare strings in an
>>"extended" codeset.  For example, the ability to encode characters with
>>accents as either "accent"+"character" or as "accented character".  Also
>>the problems of case-insensitive comparison.  I'm quite happy to punt on
>>those issues and simply mandate a byte-for-byte equivalence, as it's a
>>hard problem, and we don't have a answer that we'd like to migrate to.
>>The case of codeset conversion is different though, since it's fairly
>>trivial to do (particularly if we decide that teletexString is really
>>just a mis-labelled IA5String).
>
>Correction: You mean mis-labelled ISO-8859-1 string, not IA5String.
>An IA5String is limited to the ASCII character range.

You're right - I meant 8859-1.

>This seems attractive for the [UTF-8, PrintableString, BMPString] camp;
>less so for the T61String quagmire. You always have the risk of someone
>*really* using the capabilities of T61String.....

PKIX has to decide how it wants to interpret a string that claims to be a
T61string.  Whichever way we go on that issue, I believe that we have to
require codeset widening before comparing attributes, at least if the
attributes are encoded using different syntaxes.

John

Date: Wed, 24 Jun 1998 09:53:11 -0400
To: [email-masked]
From: Tim Polk <[email-masked]>
Subject: Re: PKIX-1 - use of UTF8
Cc: [email-masked]
Sender: [email-masked]

John,

You wrote:

>I don't think that's true.  Under the assumption that the stated name

>comparison rules would be applied when evaluating name constraints as
well

>as when chaining issuer and subject names, a system that implemented
the

>PKIX matching rules might fail to enforce an excluded subtree
constraint

>that a codeset-converting implementation would catch.  This would result
in

>a system that implemented the PKIX-1 rules verifying a chain against
the

>expressed intentions of one of the CAs in that chain, whereas a system
that

>performed codeset conversion would correctly refuse to accept the
chain.

>

You are correct.  I hadn't given much thought to the implications of name
matching in the name constraints area.  After brief though, it looks like
included subtrees are "safe", but excluded subtrees could be trouble.  At
the least the name constraints section needs some cautionary words to
convey that.

This may also serve as a lever to encourage vendors to implement codeset
sonversion.

You also wrote:

>

>There are two parts to this issue:

>

>i) The rules for choosing codesets for emitted certificates

>

>ii) The rules for matching names within certificates.

>

>The problem is that choosing rules for (ii) that permits conforming

>implementations to consider the codeset as part of the name pretty 
much

>means that we can't change the rules for (i) without breaking things

>horribly.  This prevents a graceful migration to a different preferred

>codeset.

>

>In the following, I'm going to call a system that implements the
current

>PKIX-1 rules an "Old" system, and one that emits certificates in UTF-8
a

>"New" system (under the assumption that UTF-8 is where we'd like to 
get

>to).  Similarly, "Old Certificates" contain names using the current
PKIX-1

>codeset selection rules, and "New Certificates" use UTF-8.

>

>Old end-systems will be able to chain two certificates only if the names
in

>those certificates are expressed in the same codeset.  This means that,
in

>order to migrate to UTF-8, entire certificate chains will have to be

>replaced in one step, since old systems will not be able to chain old
and

>new certificates together.

>

>Old CAs will only emit old certificates.  Therefore any certificate
chain

>that includes an old CA cannot migrate to new certificates, but must

>continue to use old certificates.

>

>

>Basically, the current rules appear to force us to retain today's

>multiplicity of codesets indefinitely.  Mandating codeset-conversions
prior

>to comparison lets us prepare for a future migration to a single
codeset.

>

I don't think this is true.  I proposed the following solution to support
a hard cutover to UTF8 encodings in 2003 on a different thread:

<paraindent><param>left</param>I think a hard cutover in 2003 could be
managed, though. Certificates *issued* after January 1, 2003 could be
required to use the UTF8String encodings.  The one exception would be
"name rollover" certificates for CAs changing their own names to the
UTF8String encodings.  (This sounds ugly, but we'll be doing it for key
rollover anyway.  CAs can just do them both at the same time.)

</paraindent>

Key rollover certificates are self-signed certificates (issuer = subject)
where the new signing key is certified by the old signing key, or
vice-versa.   A name rollover certificate would have the issuer name in
the old (e.g., T61) encoding and subject name in UTF8, or vice-versa.  I
expect CAs to perform key rollover regularly. A small amount of planning
will allow the CA to combine the two functions - that is name and key
rollover can be performed together.

I think this resolves the problem of codeset migration.  Am I missing
something?

>

>

>>Implementors requested the "minimum" requirements be added because

>>they consider the name conversion an unbounded burden.  It would

>>require constant code maintenance as the character sets are enhanced

>>or modified. I tend to agree.  I think specifying the minimum

>>requirements, and encoding rules to match, will greatly enhance

>>interoperability.

>

>

>I think the big implementation problem with name comparisons isn't
codeset

>conversion, but instead concerns how to compare strings in an
"extended"

>codeset.  For example, the ability to encode characters with accents 
as

>either "accent"+"character" or as "accented character".  Also the
problems

>of case-insensitive comparison.  I'm quite happy to punt on those
issues

>and simply mandate a byte-for-byte equivalence, as it's a hard problem,
and

>we don't have a answer that we'd like to migrate to.  The case of
codeset

>conversion is different though, since it's fairly trivial to do

>(particularly if we decide that teletexString is really just a
mis-labelled

>IA5String).

>

I would certainly agree that constructed characters and case-sensitivity
are difficult problems.  Constructed characters seems an intractable
problem, and upper and lower case is not well defined for some codesets. 
(On the latter point, I'm repeating hearsay.  Hope it was correct!)

I think byte-for-byte comparison is acceptable for the near-term.  It is
something implementors can reasonably implement, and codeset conversion
can always be supported as an added value feature.  I would advocate
keeping the name matching rules, and revisiting the issue when we
progress to Draft RFC.

>

>John

>

>

>

Tim

Date: Wed, 24 Jun 1998 07:57:41 -0400
To: [email-masked], Tim Polk <[email-masked]>
From: Harald Alvestrand <[email-masked]>
Subject: Re: PKIX-1 - use of UTF8
Cc: [email-masked]
Sender: [email-masked]

At 15:04 23.06.98 -0400, [email-masked] wrote:
>
>There are two parts to this issue:
>
>i) The rules for choosing codesets for emitted certificates
>
>ii) The rules for matching names within certificates.
>
>The problem is that choosing rules for (ii) that permits conforming
>implementations to consider the codeset as part of the name pretty much
>means that we can't change the rules for (i) without breaking things
>horribly.  This prevents a graceful migration to a different preferred
>codeset.
>
>In the following, I'm going to call a system that implements the current
>PKIX-1 rules an "Old" system, and one that emits certificates in UTF-8 a
>"New" system (under the assumption that UTF-8 is where we'd like to get
>to).  Similarly, "Old Certificates" contain names using the current PKIX-1
>codeset selection rules, and "New Certificates" use UTF-8.

You are making the assumption here that the same codeset is used for
all attributes of all names within a certificate.
Is this a requirement of the infrastructure?

>Basically, the current rules appear to force us to retain today's
>multiplicity of codesets indefinitely.  Mandating codeset-conversions prior
>to comparison lets us prepare for a future migration to a single codeset.

>I think the big implementation problem with name comparisons isn't codeset
>conversion, but instead concerns how to compare strings in an "extended"
>codeset.  For example, the ability to encode characters with accents as
>either "accent"+"character" or as "accented character".  Also the problems
>of case-insensitive comparison.  I'm quite happy to punt on those issues
>and simply mandate a byte-for-byte equivalence, as it's a hard problem, and
>we don't have a answer that we'd like to migrate to.  The case of codeset
>conversion is different though, since it's fairly trivial to do
>(particularly if we decide that teletexString is really just a mis-labelled
>IA5String).

Correction: You mean mis-labelled ISO-8859-1 string, not IA5String.
An IA5String is limited to the ASCII character range.

This seems attractive for the [UTF-8, PrintableString, BMPString] camp;
less so for the T61String quagmire. You always have the risk of someone
*really* using the capabilities of T61String.....

                      Harald A

-- 
Harald Tveit Alvestrand, Maxware, Norway
[email-masked]
On holiday June 28 to July 17. Expect delays in responses!

Date: Wed, 24 Jun 1998 12:40:26 +0200
From: Andreas Berger <[email-masked]>
To: Ambarish Malpani <[email-masked]>
CC: IETF PKIX <[email-masked]>
Subject: Re: New OCSP draft
Sender: [email-masked]

Ambarish Malpani wrote:
> 
> Hi All,
>     We have put out a new version of the OCSP draft. While we
> wait for it to be put up on the IETF site, it is available at:
> 
> ftp://ftp.valicert.com/pub/draft-ietf-pkix-ocsp-04.txt
> 
> The main changes are:
> 1. Changed the optional signed requests quite a bit.
> 2. Changed the way a certificate is identified to use the hash of the
> issuer's DN, to enable HTTP caching to work better
> 3. Added support for both GET/POST in making OCSP requests over HTTP
> (again, to better support caching)
> 4. Changed the format for the result status
> 5. Added information about how to check/not check an authorized
> OCSP responder for revocation.
> 6. Allow responder to be identified by name/key
> 
> Please let me know about your feedback ASAP.
First of all, I like the new draft better then the previous version, a
lot of the issues that I had problems with were resolved. I would like
to make some comments on the protocol.

As a preface, we try to specify a profile for OCSP for use in the
on-line revocation check mandated in the German Signature Law. So some
of the comments I make are with that application in mind.

1. OCSPResponseStatus:
certRequired: How are situations handled when status for multiple
certificates is requested and for just on the certificate is required.
This result code should probably be moved to "CertStatus" so that an
OCSP responder can produce this answer for each requested certificate
individually.

2. SingleResponse/CertStatus
Shouldn't possibility of "I do know the CA but I am unable to answer the
request, pls. ask here" be added to a response? This would minimize the
configuration on the client.

3. CertStatus
I would really love to see the addition of notIssued to the list of
result codes. This would mean "I know about the CA and all the
certificates it has ever issued, but the certificate presented is *not*
on my list".

4. OCSPRequest
Addition of an extension that allows a requester to specify the point in
time it wants information for. Then it is possible to ask: "I have a
signature produced last week, was the certificate used in that process
valid then?".

THNX
Andreas
-- 
Microsoft -- definitly needs Viagra

Date: Wed, 24 Jun 1998 12:08:40 +0200
To: Russ Housley <[email-masked]>, Paul Hoffman / IMC <[email-masked]>
From: Nada Kapidzic Cicovic <[email-masked]>
Subject: Re: SV: new profile submitted
Cc: [email-masked]
Sender: [email-masked]

I do not understand the point of changing the key id calculation algorithm
this late in pkix part 1 last call. 

Is the size of the resulting key id the only problem with the old algorithm
definition?

Is this size really an issue for S/MIME messages?

I would prefer changing the definition back to what it was, since we have
already released the software implementing it in the old way, and we are
probably not the only one.

Regards,

Nada

At 20:55 6/23/98 -0400, Russ Housley wrote:
>The PKIX Part 1 key identifier will be used in S/MIME to identify the
>per-recipient information necessary for a recipient to perform decryption.
>As stated in a previous message, collisions are not a problem here.
>However, this key identifier will not be used to identify a particular
>certificate used by an originator to sign a message content.  Collisions
>could cause significant confusion in this circumstance.
>
>Russ
>
>
>At 12:11 PM 6/23/98 -0700, Paul Hoffman / IMC wrote:
>>I think the question here is whether or not it is useful to have the same
>>key identifier for both PKIX part 1 and OCSP. If it is, then we need to
>>choose one that works for both. Ambarish says that 60 bits, with the
>>possibility of collision, is not strong enough for OCSP. If that's true, we
>>need to decide if the two key identifiers have to be the same, or whether
>>we can use a shorter one for PKIX part 1 and a longer one for OCSP.
>>
>>--Paul Hoffman, Director
>>--Internet Mail Consortium
>> 
>

Date: Tue, 23 Jun 1998 20:55:42 -0400
To: Paul Hoffman / IMC <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: SV: new profile submitted
Cc: [email-masked]
Sender: [email-masked]

The PKIX Part 1 key identifier will be used in S/MIME to identify the
per-recipient information necessary for a recipient to perform decryption.
As stated in a previous message, collisions are not a problem here.
However, this key identifier will not be used to identify a particular
certificate used by an originator to sign a message content.  Collisions
could cause significant confusion in this circumstance.

Russ

At 12:11 PM 6/23/98 -0700, Paul Hoffman / IMC wrote:
>I think the question here is whether or not it is useful to have the same
>key identifier for both PKIX part 1 and OCSP. If it is, then we need to
>choose one that works for both. Ambarish says that 60 bits, with the
>possibility of collision, is not strong enough for OCSP. If that's true, we
>need to decide if the two key identifiers have to be the same, or whether
>we can use a shorter one for PKIX part 1 and a longer one for OCSP.
>
>--Paul Hoffman, Director
>--Internet Mail Consortium
> 

Date: Tue, 23 Jun 1998 15:40:58 -0400
From: [email-masked]
To: [email-masked]
Reply-To: [email-masked]
Subject: Is Your Web Site Posted?
Sender: [email-masked]

To: [email-masked] 

     Is Your Web Site Posted?
     SitePoster will post your site to 50 search engines for $89. 
     We guarantee your satisfaction, or you pay nothing!

Millions of people every day use search engines to find web sites.
SitePoster makes your site easier to find by posting it to the top 50 search engines.

Here's how it works:

1.  Fill out the form below, and return it to us.

2.  We'll post your site to the top 50 search engines within two business days and send 
you a full promotion report.

3.  Pay nothing now.  We'll send you a bill for $89 with the promotion report.  If you're 
not completely happy, simply write "cancel" on the bill, and you'll owe nothing.

THE SEARCH ENGINES

Here's the list of top search engines to which we'll post your site:

Alta Vista, Excite, Galaxy, HotBot, Infoseek, Lycos, Magellan, Open Text Web Index,
Web Crawler, BizWeb, New Riders WWW Yellow Pages, LinkMonster, True North, 
Northern Light, YelloWWWeb, The Weekly Bookmark, The Galactic Galaxy, TurnPike,
Unlock:The Information Exchange, Your WebScout, Manufacturers Information
Network, Net Happenings, Net Mall, Web World  Internet Directory, WebVenture
Hotlist, What's New, WhatUSeek, JumpLink, Linkcentre Directory, InfoSpace, Jayde
Online Directory, BC Internet, BizCardz Business Directory, Net-Announce, New Page
ListOne World Plaza, PageHost A-Z, PeekABoo, Project Cool, Scrub The Web, Seven
Wonders, Sserv, Starting Point, Web 100, Web Walker, Where2Go, World Wide Business
Yellow Pages, Wow! Web Wonders!, WWW Worm, JumpCity.

ORDER FORM

Hit the REPLY button on your e-mail program and fill out the following information.
 (This information will be posted to the search engines/indexes):

URL:  http://
Site Title: 
Description (250 characters): 

Key words (250 characters, in descending order of importance):

Your name: 
Company Name:
Address:
City:              State/Prov:     Zip/Postal Code: 
Telephone: 
Fax: 
Email address: 

Contact e-mail address (in case we have questions about this order): 

If  billing a different address, please complete the following:

Addressee: 
Company Name:
Address:
City:              State/Prov:     Zip/Postal Code: 
Telephone: 
Fax: 
Email address: 

TERMS

Terms are net 15 days from date of invoice.

______________________________________________________________________
SitePoster, Inc.
1440 Whalley Avenue - Suite 239
New Haven, CT 06515
Phone: (203) 928-9207
Fax:     (203) 389-8074
E-mail: [email-masked]

Date: Tue, 23 Jun 1998 16:50:04 -0700
From: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
To: IETF PKIX <[email-masked]>
Subject: New OCSP draft
Sender: [email-masked]

Hi All,
    We have put out a new version of the OCSP draft. While we
wait for it to be put up on the IETF site, it is available at:

ftp://ftp.valicert.com/pub/draft-ietf-pkix-ocsp-04.txt

The main changes are:
1. Changed the optional signed requests quite a bit.
2. Changed the way a certificate is identified to use the hash of the
issuer's DN, to enable HTTP caching to work better
3. Added support for both GET/POST in making OCSP requests over HTTP
(again, to better support caching)
4. Changed the format for the result status
5. Added information about how to check/not check an authorized
OCSP responder for revocation.
6. Allow responder to be identified by name/key

Please let me know about your feedback ASAP.

Thanks,
Ambarish

-- 
---------------------------------------------------------------------
Ambarish Malpani
Architect					       (650) 849-9880
ValiCert, Inc.				        [email-masked]
3160 W. Bayshore Road		              http://www.valicert.com
Palo Alto, CA 94303

Date: Tue, 23 Jun 1998 13:37:32 -0600
From: Mike Smith <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: SV: new profile submitted
Sender: [email-masked]

Russ, Paul, Ambarish:

SHA-1 is not supposed to be very good at hashing small (in size) objects; SHA-1 ends up being 160 bits; we need to reconcile the two standards: why not use something the size of which does not weaken SHA-1.

Not being a cryptographer, I hesitate to recommend an alternative for key identifier.

Michael
>>> Paul Hoffman / IMC <[email-masked]> 06/23 1:11 PM >>>
I think the question here is whether or not it is useful to have the same
key identifier for both PKIX part 1 and OCSP. If it is, then we need to
choose one that works for both. Ambarish says that 60 bits, with the
possibility of collision, is not strong enough for OCSP. If that's true, we
need to decide if the two key identifiers have to be the same, or whether
we can use a shorter one for PKIX part 1 and a longer one for OCSP.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Tue, 23 Jun 1998 12:11:18 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: SV: new profile submitted
Sender: [email-masked]

I think the question here is whether or not it is useful to have the same
key identifier for both PKIX part 1 and OCSP. If it is, then we need to
choose one that works for both. Ambarish says that 60 bits, with the
possibility of collision, is not strong enough for OCSP. If that's true, we
need to decide if the two key identifiers have to be the same, or whether
we can use a shorter one for PKIX part 1 and a longer one for OCSP.

--Paul Hoffman, Director
--Internet Mail Consortium

From: [email-masked]
To: Tim Polk <[email-masked]>
cc: [email-masked]
Date: Tue, 23 Jun 1998 15:04:34 -0400
Subject: Re: PKIX-1 - use of UTF8
Sender: [email-masked]

Tim Polk <[email-masked]> writes:

>I have a slightly different interpretation of the name comparison
>rules in POKIX-1 than you presented below.  The text was *intended*
>to state the minimum rules for name comparison.  Consider two
>implementations - (a) implements only the PKIX-1 requirements, and
>(b) implements the rules you propose.  Any certificate path whose
>names chain for (a) will chain for (b) as well.

I don't think that's true.  Under the assumption that the stated name
comparison rules would be applied when evaluating name constraints as well
as when chaining issuer and subject names, a system that implemented the
PKIX matching rules might fail to enforce an excluded subtree constraint
that a codeset-converting implementation would catch.  This would result in
a system that implemented the PKIX-1 rules verifying a chain against the
expressed intentions of one of the CAs in that chain, whereas a system that
performed codeset conversion would correctly refuse to accept the chain.

>The converse is *not* true; the implementations translating to the
>great character set in the sky would accept additional paths.  CAs
>that cared about interoperability would issue certs conforming to
>the encoding rules so that both implementations worked.
>
>Anyway, an implementation that converted to a standard syntax prior
>to comparison should be conformant to the specification.  It is an
>upwardly compatible enhancement, and no one intended to rule this out.
>Perhaps an additional paragraph clarifying this would be appropriate.
>

There are two parts to this issue:

i) The rules for choosing codesets for emitted certificates

ii) The rules for matching names within certificates.

The problem is that choosing rules for (ii) that permits conforming
implementations to consider the codeset as part of the name pretty much
means that we can't change the rules for (i) without breaking things
horribly.  This prevents a graceful migration to a different preferred
codeset.

In the following, I'm going to call a system that implements the current
PKIX-1 rules an "Old" system, and one that emits certificates in UTF-8 a
"New" system (under the assumption that UTF-8 is where we'd like to get
to).  Similarly, "Old Certificates" contain names using the current PKIX-1
codeset selection rules, and "New Certificates" use UTF-8.

Old end-systems will be able to chain two certificates only if the names in
those certificates are expressed in the same codeset.  This means that, in
order to migrate to UTF-8, entire certificate chains will have to be
replaced in one step, since old systems will not be able to chain old and
new certificates together.

Old CAs will only emit old certificates.  Therefore any certificate chain
that includes an old CA cannot migrate to new certificates, but must
continue to use old certificates.

Basically, the current rules appear to force us to retain today's
multiplicity of codesets indefinitely.  Mandating codeset-conversions prior
to comparison lets us prepare for a future migration to a single codeset.

>Implementors requested the "minimum" requirements be added because
>they consider the name conversion an unbounded burden.  It would
>require constant code maintenance as the character sets are enhanced
>or modified. I tend to agree.  I think specifying the minimum
>requirements, and encoding rules to match, will greatly enhance
>interoperability.

I think the big implementation problem with name comparisons isn't codeset
conversion, but instead concerns how to compare strings in an "extended"
codeset.  For example, the ability to encode characters with accents as
either "accent"+"character" or as "accented character".  Also the problems
of case-insensitive comparison.  I'm quite happy to punt on those issues
and simply mandate a byte-for-byte equivalence, as it's a hard problem, and
we don't have a answer that we'd like to migrate to.  The case of codeset
conversion is different though, since it's fairly trivial to do
(particularly if we decide that teletexString is really just a mis-labelled
IA5String).

John

Date: Tue, 23 Jun 1998 15:03:41 -0400
To: Ambarish Malpani <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: SV: new profile submitted
Cc: Nilsson Hans <[email-masked]>, "'Tim Polk'" <[email-masked]>, [email-masked]
Sender: [email-masked]

Ambarish:

In my mind, the point of key identifier is to have a short identifier for
the key.  It does not have to be collision free.

S/MIME (and other security protocols) use the key identifier to identify
the their own per-recipient information.  In the unlikely event that two
recipients have the same 60 bit value, then each of the values with the
same 60-bit value can be tried.

The structure that you propose is quite a but longet the 64 bits.  My
personal desire is a realtively short identifier.  Using the first four
bits an a type, allow us to pick some other hash if SHA-1 does not meet the
community's needs in the long run.

Russ

At 04:23 PM 6/22/98 -0700, Ambarish Malpani wrote:
>Hi Tim, Russ,
>    I, too, am concerned about this new definition of KeyIdentifier.
>As you know, we are trying to use the hash of the issuer's public
>key to distinguish between two issuers with the same DN. I was
>hoping that applications that are sensitive to the cost of even
>a hashing operation, be able to use the keyIdentifier in the
>cert if it had the AuthorityKeyIdentifier extension.
>
>2 points:
>
>1. With this new definition, applications can't rely on using
>keyIdentifier at all, since it is only 64 bits and there could
>be a lot more collisions - either deliberate, or accidental.
>
>2. Even with the old definition, it was unclear if the keyIdentifier
>was actually the SHA1 hash or some random number that the CA decided
>to use, since the keyIdentifier was not required to be the SHA1
>hash.
>
>I would prefer something like:
>
>KeyIdentifier ::= SEQUENCE {
>    algorithmIdentifier		AlgorithmIdentifier,
>    data			OCTET STRING }
>
>Regards,
>Ambarish
>
>Russ Housley wrote:
>> 
>> Hans:
>> 
>> >Can you please explain the background for the new writing regarding
>> >subjectKeyIdentifier, using 0100 + 60 bits from the SHA-1 hash of the BIT
>> >STRING subjectPublicKey? Is this in conformance with something else, or a
>> >new invention?
>> 
>> This aligns PKIX with a specification used by the US Government.  Neither
>> Tim not I saw any harm in adopting the format.  Further, the use of a
>> prefix allows PKIX to specify a different means of computing the key
>> identifier if the SHA-1 method should ever be discovered to be deficient.
>> 
>> Russ
>
>-- 
>---------------------------------------------------------------------
>Ambarish Malpani
>Architect					       (650) 849-9880
>ValiCert, Inc.				        [email-masked]
>3160 W. Bayshore Road		              http://www.valicert.com
>Palo Alto, CA 94303
> 

Date: Tue, 23 Jun 1998 14:03:29 -0700
To: [email-masked]
From: Warwick Ford <[email-masked]>
Subject: Last Call - Profile
Sender: [email-masked]

The PKIX Profile is issued for a 2-week WG last call.  Given no major
objections, it will then be forwarded to the IESG with a recommendation for
progression to Proposed Standard.  Thanks to Tim and Russ for their
extensive efforts with the editing.

Warwick

--------
There was a delay at the IETF in getting new drafts into the official draft
directory. The new PKIX part 1 is now there, and is also mirrored at
<http://www.imc.org/draft-ietf-pkix-ipki-part1>.

--Paul Hoffman, Director
--Internet Mail Consortium

>Date: Tue, 16 Jun 1998 17:28:41 -0400
>To: [email-masked]
>From: Tim Polk <[email-masked]>
>Subject: new profile submitted
>Cc: [email-masked], [email-masked], [email-masked]
>
>
>I have submitted the new draft of the profile.  In the interim, you can get
>it via the following URL:
>
>http://csrc.nist.gov/pki/draft-ietf-pkix-ipki-part1-08.txt
>
>It corporates all changes discussed in LA, but CRL distribution points was
>not excised from the draft.  After extensive negotiations, new licensing
>terms were completed THIS MORNING.
>
>(I will not speak to the agreement - I'm leaving that for Jeff Schiller.) 
>
>Brief Notes:
>
>#1 I am asking for Last Call.
>
>#2 If you want something changed, please submit your suggestions to the
>list WITH TEXT.  We want to forward this to the IESG as soon as possible.
>That will not be possible if we discuss abstract changes on the list.
>Concrete text is a MUST.
>
>#3 The document isn't really longer - the ASN.1 in the appendices is simply
>more complete.
>
>Thanks,
>
>Tim Polk
>
>

---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., Tel (781)2456996 x225; Fax (781)2456006
[email-masked];  301 Edgewater Pl, Suite 210, Wakefield, MA 01880
---------------------------------------------------------------------

Date: Tue, 23 Jun 1998 11:46:34 -0400
To: [email-masked]
From: Tim Polk <[email-masked]>
Subject: Re: Limiting non-UTF-8 kludges
Sender: [email-masked]

At 04:17 PM 6/22/98 -0700, Chris Newman wrote:

>Perhaps it would be possible to require UTF8String for all
certificates,

>with a short-term exception permitted for RSA certificates intended 
for

>use on the https port with SSL.  Is there any other significant
installed

>base? 

>

>Since the TLS and S/MIME standards will make DSS certs mandatory to

>implement, why not cut over to UTF8String at the same time?

>

UTF8String will be added to the ISO DirectoryString definition in the
next version, I believe.  There is no installed base, and there will be a
significant lag time to widespread implementation.  "Cutting over" to
UTF8String as the only choice for DirectoryString would, in my opinion,
be a mistake.  In my opinion, the installed base warrants backwards
compatability.

I think a hard cutover in 2003 could be managed, though. Certificates
*issued* after January 1, 2003 could be required to use the UTF8String
encodings.  The one exception would be "name rollover" certificates for
CAs changing their own names to the UTF8String encodings.  (This sounds
ugly, but we'll be doing it for key rollover anyway.  CAs can just do
them both at the same time.)

>Using T61String as a false label for Latin1String makes me nervous. 
I'd

>prefer to forbid generation of T61String in PKIX, even if acceptance 
is

>permitted for backwards compatibility reasons.

>

It makes me nervous as well, but it sounds like we must accomodate it.
Peter and As I see it, we have two options:

<paraindent><param>left</param>(1) The specification remains the same for
name encoding (PrintableString, BMPString, or UTF8String in that order)
but "strongly recommend that implementations be prepared to accept" the
Latin1String character set in the T61String type.  

</paraindent><paraindent><param>left</param>(2) Replace BMPString with T61String as
the second choice for name encoding and specify the the Latin1String
characters be recognized by conforming implementations.

</paraindent>

Since BMPString is not widely implemented, the T61String/Latin1String
kludge is widely implemented, and we would be transitioning to UTF8String
in 2003, choice (2) seems the better choice.

>Using BMPString also makes me nervous.  What byte-order is that?  What

>does it mean if there are characters from the surrogate range -- is it

>really just UTF-16 mislabelled?  Is the BOM required or not?  Is there
a

>version of the charset registered with IANA that's suitable? (I know

>version 1.0 is registered, but that's incompatible with version 2.0)

>

I was not aware of any ambiguities with BMPString.  Maybe this is another
good reason to deprecate its use.

>I'm including the relevant IETF policy from RFC 2277.  If PKIX doesn't

>follow this, then the spec will be booted back to the WG by the IESG. 
In

>particular, a cert using UTF8 MUST be compliant with PKIX regardless 
of

>what other forms are permitted.

I believe the current text satisfies the IESG requirements.  (One
exception: I don't know if BMPString or T61String have been registered in
the IANA character set registry.)  Any changes we contemplate MUST
continue to satisfy those requirements.

>

>   Protocols MUST be able to use the UTF-8 charset, which consists of

>   the ISO 10646 coded character set combined with the UTF-8 character

>   encoding scheme, as defined in [10646] Annex R (published in

>   Amendment 2), for all text.

>

>   Protocols MAY specify, in addition, how to use other charsets or

>   other character encoding schemes for ISO 10646, such as UTF-16, but

>   lack of an ability to use UTF-8 is a violation of this policy; such
a

>   violation would need a variance procedure ([BCP9] section 9) with

>   clear and solid justification in the protocol specification 
document

>   before being entered into or advanced upon the standards track.

>

>   For existing protocols or protocols that move data from existing

>   datastores, support of other charsets, or even using a default 
other

>   than UTF-8, may be a requirement. This is acceptable, but UTF-8

>   support MUST be possible.

>

>   When using other charsets than UTF-8, these MUST be registered in
the

>   IANA charset registry, if necessary by registering them when the

>   protocol is published.

>

>		- Chris

>

>

>

Date: Tue, 23 Jun 1998 11:41:59 -0400
To: [email-masked], [email-masked]
From: Tim Polk <[email-masked]>
Subject: Re: PKIX-1 - use of UTF8
Cc: [email-masked]
Sender: [email-masked]

John,

I have a slightly different interpretation of the name comparison rules in
POKIX-1 than you presented below.  The text was *intended* to state the
minimum rules for name comparison.  Consider two implementations - (a)
implements only the PKIX-1 requirements, and (b) implements the rules you
propose.  Any certificate path whose names chain for (a) will chain for (b)
as well.

The converse is *not* true; the implementations translating to the great
character set in the sky would accept additional paths.  CAs that cared
about interoperability would issue certs conforming to the encoding rules
so that both implementations worked.

Anyway, an implementation that converted to a standard syntax prior to
comparison should be conformant to the specification.  It is an upwardly
compatible enhancement, and no one intended to rule this out.  Perhaps an
additional paragraph clarifying this would be appropriate.

Implementors requested the "minimum" requirements be added because they
consider the name conversion an unbounded burden.  It would require
constant code maintenance as the character sets are enhanced or modified.
I tend to agree.  I think specifying the minimum requirements, and encoding
rules to match, will greatly enhance interoperability.

Another side point - if a CA chooses to use the basic local character set
anyway for end entities, this has only minor consequences.  Some
implementations that might be able to display the subject name in the more
restrictive character set, but not in the user's local character set.  For
example, an implementation might be able to display "Fred", but would not
recognize it in T61String.

A CA cannot choose to "switch" character sets for CA names, though.
Consider a CA certificate issued by a US CA to a Japanese CA.  Switching to
local character sets involves translation, not encoding.  (I realize this
is more radical than what you are thinking of, but it is the logical
extension.) The solution is to use the subject's chosen encoding in the
subject field and the issuer's local encoding/translation in the subject
alternative name field.

Tim Polk

>Interoperability with current code.  Firstly, UTF8 and BMPString are recent
>additions to the permitted syntaxes for directoryString, and certificates
>using either of these syntaxes are unlikely to be understood by deployed
>code.  Also, there's a slightly less serious problem in that PKIX has
>currently adopted a very strict set of rules for comparison of strings (for
>example, during certificate chain processing).  PKIX-1 mandates that two
>strings are considered different if they are encoded using different
>syntaxes, regardless of their contents.  This means that if PKIX issues
>certificates encoded using UTF8 or BMPString, those certificates can never
>be part of the same trust chain as a certificate issued by a system that
>chooses a different syntax.
>
>>Finally, what does it mean to say that a character set is "sufficient"?
>>Does this mean that a given character string has to be examined
>>one character at a time to see whether an accented character just
>>happens to be included in that person's name, for example?
>
>Yes, that's pretty much it.
>
>>Or, as I would prefer, can the decision be made on the basis of the
>>basic code set in use, so  that a user who normally uses German
>>would always their input encoded the same way, regardless of the
>>actual characters used?
>
>Not with the current PKIX string matching rules.  "Fred" encoded as a
>printableString is defined as different to "Fred" encoded as a BMPString,
>or UniversalString, or UTF8String - all of these "Fred"s have to be
>considered as distinct and different names, even though it's trivial to
>convert between those encodings.  Because of this, PKIX has to mandate the
>encoding syntax used, so that certificates have a chance of chaining
>properly.
>
>In another message, I suggested a relaxation of the matching rules to allow
>conversion to a standard syntax prior to comparison.  This would make it
>possible for us to change or relax the rules for picking a syntax to use
>when emitting certificates, if we so desired.  This would allow us to use
>the current arcane rules for a transition period so that PKIX can
>interoperate with current systems, but in the future, when more systems
>understand UTF8, PKIX could switch to specifying that as the prefered
>syntax, without breaking anything.
>
>John
>
>
>

Date: Tue, 23 Jun 1998 08:31:26 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: new profile submitted
Sender: [email-masked]

There was a delay at the IETF in getting new drafts into the official draft
directory. The new PKIX part 1 is now there, and is also mirrored at
<http://www.imc.org/draft-ietf-pkix-ipki-part1>.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Mon, 22 Jun 1998 07:24:07 -0400
To: [email-masked], [email-masked], [email-masked]
From: Harald Tveit Alvestrand <[email-masked]>
Subject: Re: PKIX-1 - use of UTF8
Sender: [email-masked]

At 12:49 19.06.98, Peter Gutmann wrote:
>Actually it's none of the above.  What I meant was:
> 
>    (b) failing (a), if the latin-1 (ISO 8859-1) character set is sufficient
>the string shall be represented as a latin-1 string with a T61String tag.

A sad state of affairs indeed.

>(that may not be the best way to say it, what I mean here is to use straight
>latin-1 but tag it as a T61String).
> 
>Before people start dusting off their flamethrowers, the reason for this is
>twofold:
> 
>1. It codifies existing practice.  I've never found a single certificate in
>   which a T61String really is a T61String - in every case it's latin-1 (if
>   anyone has an example of a cert with a real T.61 string, please send me a
>   copy for my collection).  For all implementations I know of, T61String
>   currently *is* Latin1String.

I can't speak for certificates, but in other usages of a DN, there are
definitely both services running "real" T.61 and "Latin1" T.61.
It's a pain in the posterior, indeed.

>2. T.61 has apparently been withdrawn by the ITU, so it's not even
possible to
>   get a copy of this in order to comply with it.  For people who have seen
>   this or related standards like T.51/52, withdrawing it is probably a good
>   move (IMNSHO any standard which requires diagrams extending into three
>   dimensions in order to explain how to encode an a-umlaut has problems).
>   T61String in itself (without complex escape codes and shifting) is next to
>   useless because there's almost nothing which is common to latin-1 and
>   straight T.61, and once you add the escape codes it's unworkable.
> 

T61String isn't defined in T.61, but in X.680 and X.208 - the ASN.1
standards. It's defined as a profile on unrestricted ISO 2022 character
set switching - you ARE allowed to encode Latin1 into a T61String, but
you have to insert the right escape-sequence gook first.
Naturally, this standard is *somewhat* removed from reality.

>>X.509 doesn't contain an option for an 8-bit Western European codeset. If we
>>want to stay within the standard, we have to go multibyte to get accented
>>characters.
> 
>X.509 doesn't handle latin-1, but (AFAIK) every existing implementation -
tens
>of millions - do by treating T61String as Latin1String.  All you need to
do to
>work with this is add a single sentence to PKIX which codifies this practice.
>There's simply too large an installed base out there to change it now, and
>mandating an immediate unconditional switch to UTF8 for vendors is suicidal
>because any certificates their software issues will be regarded as invalid by
>virtually every application which makes use of certificates.

Actually a requirement that you compare two attributes byte by byte
will effectively nullify the problem - if you compare bytes and not
characters, it doesn't matter what the characters represent.

It's just a "#¤%&/( pain in the user interface.

My thought: This is indeed a good argument for refusing to emit T61
strings at all.

               Harald

-- 
Harald Tveit Alvestrand, Maxware, Norway
[email-masked]

Date: Mon, 22 Jun 1998 16:23:29 -0700
From: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
To: Russ Housley <[email-masked]>
CC: Nilsson Hans <[email-masked]>, "'Tim Polk'" <[email-masked]>, [email-masked]
Subject: Re: SV: new profile submitted
Sender: [email-masked]

Hi Tim, Russ,
    I, too, am concerned about this new definition of KeyIdentifier.
As you know, we are trying to use the hash of the issuer's public
key to distinguish between two issuers with the same DN. I was
hoping that applications that are sensitive to the cost of even
a hashing operation, be able to use the keyIdentifier in the
cert if it had the AuthorityKeyIdentifier extension.

2 points:

1. With this new definition, applications can't rely on using
keyIdentifier at all, since it is only 64 bits and there could
be a lot more collisions - either deliberate, or accidental.

2. Even with the old definition, it was unclear if the keyIdentifier
was actually the SHA1 hash or some random number that the CA decided
to use, since the keyIdentifier was not required to be the SHA1
hash.

I would prefer something like:

KeyIdentifier ::= SEQUENCE {
    algorithmIdentifier		AlgorithmIdentifier,
    data			OCTET STRING }

Regards,
Ambarish

Russ Housley wrote:
> 
> Hans:
> 
> >Can you please explain the background for the new writing regarding
> >subjectKeyIdentifier, using 0100 + 60 bits from the SHA-1 hash of the BIT
> >STRING subjectPublicKey? Is this in conformance with something else, or a
> >new invention?
> 
> This aligns PKIX with a specification used by the US Government.  Neither
> Tim not I saw any harm in adopting the format.  Further, the use of a
> prefix allows PKIX to specify a different means of computing the key
> identifier if the SHA-1 method should ever be discovered to be deficient.
> 
> Russ

-- 
---------------------------------------------------------------------
Ambarish Malpani
Architect					       (650) 849-9880
ValiCert, Inc.				        [email-masked]
3160 W. Bayshore Road		              http://www.valicert.com
Palo Alto, CA 94303

Date: Mon, 22 Jun 1998 16:17:26 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: Limiting non-UTF-8 kludges
To: [email-masked]
Originator-Info: login-id=chris; server=THOR.INNOSOFT.COM
Sender: [email-masked]

Perhaps it would be possible to require UTF8String for all certificates,
with a short-term exception permitted for RSA certificates intended for
use on the https port with SSL.  Is there any other significant installed
base? 

Since the TLS and S/MIME standards will make DSS certs mandatory to
implement, why not cut over to UTF8String at the same time?

Using T61String as a false label for Latin1String makes me nervous.  I'd
prefer to forbid generation of T61String in PKIX, even if acceptance is
permitted for backwards compatibility reasons.

Using BMPString also makes me nervous.  What byte-order is that?  What
does it mean if there are characters from the surrogate range -- is it
really just UTF-16 mislabelled?  Is the BOM required or not?  Is there a
version of the charset registered with IANA that's suitable? (I know
version 1.0 is registered, but that's incompatible with version 2.0)

I'm including the relevant IETF policy from RFC 2277.  If PKIX doesn't
follow this, then the spec will be booted back to the WG by the IESG.  In
particular, a cert using UTF8 MUST be compliant with PKIX regardless of
what other forms are permitted.

   Protocols MUST be able to use the UTF-8 charset, which consists of
   the ISO 10646 coded character set combined with the UTF-8 character
   encoding scheme, as defined in [10646] Annex R (published in
   Amendment 2), for all text.

   Protocols MAY specify, in addition, how to use other charsets or
   other character encoding schemes for ISO 10646, such as UTF-16, but
   lack of an ability to use UTF-8 is a violation of this policy; such a
   violation would need a variance procedure ([BCP9] section 9) with
   clear and solid justification in the protocol specification document
   before being entered into or advanced upon the standards track.

   For existing protocols or protocols that move data from existing
   datastores, support of other charsets, or even using a default other
   than UTF-8, may be a requirement. This is acceptable, but UTF-8
   support MUST be possible.

   When using other charsets than UTF-8, these MUST be registered in the
   IANA charset registry, if necessary by registering them when the
   protocol is published.

		- Chris

From: Amit Kapoor <[email-masked]>
Subject: CertID clarification
To: [email-masked]
Date: Mon, 22 Jun 1998 15:55:10 -0700 (PDT)
Sender: [email-masked]

Hi,

	Needed a clarification on CertID.  In the current
	drafts I see two different ASN.1 structures in
	CRMF and OCSP.  The functionality seems similar
	enough to try and make both of them the same.
	Comments?

	Second, along the above lines maybe it makes
	sense to identify the common ASN.1 structures
	from the drafts and move them to a single
	document to prevent duplicate functionality
	with different structures abd creating implementation
	and interoperability headaches.  Is it too late
	for something like this?  Thoughts?

	Thanks.

Amit

From: "Phillip M Hallam-Baker" <[email-masked]>
To: "Bob Jueneman" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: RE: RE: Certificate Revocation
Date: Mon, 22 Jun 1998 10:34:48 -0400
Importance: Normal
Sender: [email-masked]

Bob,

> But I really like the suggestion that my statement of the requirements
> triggered.  W've often talked about a personal directory, i.e., a subset
> of the corporate and/or Whole Earth, directory, but I'd never
> thought about
> a personalized CRL list.
>
> Neat idea, and compatible with existing technology. I like that a lot.
> I'd like to see you expand on your "scope" question some more.

This could be handled by adding a scope tag 'enumerated set' which
would simply contain a set of certficate serial numbers.

> With respect to the CD-ROM issue, however, I'm not sure that I would blow
> that off quite so quickly....

I think it is a valid solution, but not necessarily for the application
you suggest. I believe that security has to be zero impact is the users
are to be trusted to follow the proceedures.

On the other hand I would guess our legal friends would like a repository
of that type. I still think it is a good idea to partition the CRL since
CDROM has a number of access speed restrictions which will haunt us
for some time - it is only possible to rotate a perspex disk at a certain
speed before the giroscope effect is noticable :-) But the partitions on
a CDROM could be significantly larger, optimised for the medium. 8Kb chunks
are more likely to be optimal.

	Phill

Date: Mon, 22 Jun 1998 10:03:53 -0400
From: Paul Koning <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: PKIX-1 - use of UTF8
Sender: [email-masked]

>>>>> "John" == John Wray <[email-masked]> writes:

 John> Peter Gutmann ([email-masked]) writes:
 >> Bob Jueneman has suggested deprecating the current practice after
 >> a certain date (2005), which is a good approach: Accept both types
 >> of encoding until then to give vendors time to switch over, but
 >> only emit UTF8 after the cutover date.  The ideal solution would
 >> be to take an approach like the cert validity Y2K fix: Provide a
 >> workaround for the current practice, and require a unified format
 >> (UTF8 only) after the cutover date.  Once everything is ready for
 >> the new format, we can finally lay the character set mess to rest.

 John> I'm happy with that solution.  Codifying this in PKIX-1 would
 John> mean three changes to the document:

 John> 1. The ASN.1 needs to be amended to convey the fact that the
 John> teletexString choice within directoryString isn't really a
 John> teletexString, but instead is an IA5String with a teletexString
 John> tag.  I guess that makes it really an IA5String,
 John> implictly-tagged as a UNIVERSAL 20 (It's not legal ASN.1 to use
 John> a Universal-class tag, so it'll need a statement to explain
 John> that this is simply codifying existing practice).

Sounds good.  

>...
 John> 3. The rules for matching names need to require codeset
 John> conversion to UTF8 (or universal string) prior to performing a
 John> comparison.  This will enable a change to UTF8 in the future.
 John> If teletexString is really IA5, the reasons for not doing
 John> caseIgnore matching on this syntax go away, and it should be
 John> treated the same way as printableString for that purpose.

Um, I wonder about caseIgnore applied to Latin-1 strings.  The case
ignore rules are locale dependent.  (For example, in some countries
letters lose their accents when upcased, in others they don't.  So
"e with acute" matches "E" in France but not in Canada. 

	paul

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: PKIX-1 - use of UTF8
Reply-To: [email-masked]
Date: Mon, 22 Jun 1998 12:43:09 (NZST)
Sender: [email-masked]

Paul Hoffman / IMC <[email-masked]> writes:
>At 01:14 AM 6/22/98 +0000, Peter Gutmann wrote:
>>Finding anything which requires BMPString is very difficult.  I've never seen
>>a cert with a BMPString apart from some Microsoft "everything is a BMPString"
>>ones (that is, I've never seen one which really needs a BMPString).  This
>>isn't through lack of trying, I've asked all sorts of people in locations
>>which could use BMPStrings (China, Korea, Malaysia, Hong Kong, Egypt) to try
>>and create a cert like this for me, without success.  There may be billions
>>of names which require BMPStrings, but noone seems to be using any of them at
>>the moment, and I can't even find someone who can be persuaded to use one for
>>testing purposes.
 
>This mystifies me. What kind of personal name or corporate (not email name)
>certs are being generated for people in Japan, China, and Korea? Names spelled
>in Roman characters in a PrintableString?
 
Exclusively.  I've spent ages doing depth-first searches of Asian CA's web
pages full of characters I can't display or understand only to find that, when
I finally locate the certs, they're all PrintableStrings.  For example here's
the DN from a typical cert:
 
  PrintableString 'CN'
  PrintableString 'Guangdong'
  PrintableString 'Shenzhen'
  PrintableString 'China Merchants Bank'
  PrintableString 'Department of Computers'
 
There are many more like that from all over Asia.  I don't know why this is
happening, possibly because users in Asian countries are used to dealing with
non-i18nised software, so they automatically compensate by romanising their
strings.
 
Peter.

Date: Sun, 21 Jun 1998 10:38:47 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: PKIX-1 - use of UTF8
Sender: [email-masked]

Thank you Nilsson and Peter for the quick (but somewhat depressing)
replies. However, I think I did not state my real question succinctly
enough. I don't care what current cert creators are creating: I care what
cert validators do when handed a cert with a BMPString. Could you repeat
your analyses for cert validators? I'm afraid they might be the same, but
want to be sure.

The reason I ask is simple. If cert validators can handle BMPString and
KludgeStrings, then we should mandate BMPString and remind implementors
that they should definitely handle KludgeStrings. However, if many cert
validators break when handed a cert that has a name in BMPString, then I
agree that we need to specify KludgeStrings followed by UTF8Strings.

Said a different way, just because many CA's issue KludgeString certs
doesn't mean we have to mandate it if there is something better.

At 01:14 AM 6/22/98 +0000, Peter Gutmann wrote:
>Finding anything which requires BMPString is very difficult.  I've never
seen a
>cert with a BMPString apart from some Microsoft "everything is a BMPString"
>ones (that is, I've never seen one which really needs a BMPString).  This
isn't
>through lack of trying, I've asked all sorts of people in locations which
could
>use BMPStrings (China, Korea, Malaysia, Hong Kong, Egypt) to try and create a
>cert like this for me, without success.  There may be billions of names which
>require BMPStrings, but noone seems to be using any of them at the moment,
and
>I can't even find someone who can be persuaded to use one for testing
purposes.

This mystifies me. What kind of personal name or corporate (not email name)
certs are being generated for people in Japan, China, and Korea? Names
spelled in Roman characters in a PrintableString?

--Paul Hoffman, Director
--Internet Mail Consortium

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: PKIX-1 - use of UTF8
Reply-To: [email-masked]
Date: Mon, 22 Jun 1998 01:14:15 (NZST)
Sender: [email-masked]

Paul Hoffman / IMC <[email-masked]> writes:
 
>Peter, you seem to have the best information on a variety of cert writers and
>readers here. Are you saying that there many implementations that do
>{T61String that contains ISO 8859-1} but do *not* do {BMPString} ? That means
>that they have no way to create or read certs for billions of names that don't
>fit in ISO 8859-1.
 
Finding anything which requires BMPString is very difficult.  I've never seen a
cert with a BMPString apart from some Microsoft "everything is a BMPString"
ones (that is, I've never seen one which really needs a BMPString).  This isn't
through lack of trying, I've asked all sorts of people in locations which could
use BMPStrings (China, Korea, Malaysia, Hong Kong, Egypt) to try and create a
cert like this for me, without success.  There may be billions of names which
require BMPStrings, but noone seems to be using any of them at the moment, and
I can't even find someone who can be persuaded to use one for testing purposes.
 
Of the certs I've seen with non-7-bit characters, the T61String always seemed
to be latin-1 (that is, when treated as latin-1 the characters came out right).
These mostly appeared in personal names and possibly once or twice in a company
name.
 
[If there's anyone running a CA in Europe who could provide more data here I'd
 be interested in hearing it.  CA certs from Europe seem to deliberately
 restrict themselves to using PrintableStrings because of the problems with
 other string types, and certs from end-users (who aren't aware of the
 pitfalls) are somewhat hard to find in public locations]
 
Of the three most common cert-handling implementations (Netscape, MSIE, and
SSLeay (which is used in large numbers of servers and SSL proxies, especially
outside the US, and by a number of CA's)), support is as follows:
 
MS products: Tends to favour BMPString for everything, skipping T61String.
Netscape: Used to use T61String for everything which wasn't a PrintableString,
          and would apparently crash if it encountered a BMPString (I think
          this was fixed recently - consider what happens when, say, IIS meets
          Navigator to see why this was a problem).
SSLeay: Uses T61String for everything which isn't a PrintableString (that is,
        if it has a high bit set it gets treated as a T61String.  This is where
        some of the T61String = 8859-1 certs came from).
 
Secude (of which I only have the last publicly-available copy, which predates
BMPString) does in fact appear to jump through the T61String hoops, converting
to and from 8859-1, which would make it the only implementation I'm aware of
which uses real T61Strings.  I've got some Secude-generated certs here, but
none contain T61Strings, so I'm not sure if there really are any genuine
T61String certs in existence.
 
[Another problem I've heard about from CA's, many of which have a web-based
 interface, is that you can't get very far with a BMPString in HTML, whereas
 8859-1 comes built in.  Since a lot of cert-handling software doesn't convert
 the strings for you, you run into problems if you find non-8859-1 strings in a
 cert]
 
>If these implementations actually handle both, then we should not perpetuate
>the T61String hack and should go straight to BMPString. I would really prefer
>to go to UTF8, but agree that we can't just not interoperate with current
>implementations. We should have a cutoff date for mandating new certs use
>UTF8String, and I feel comfortable with making that cutoff five years from
>now, not eight.
 
I'd really like to be able to pretend the whole mess doesn't exist and go
straight to UTF8, but I don't think that'll work because of the size of the
existing installed base :-(.  Summarising the details of certs and
implementations I've been able to get at so far:
 
- Almost all certs use PrintableString (but see the note above that this may be
  due to CA's deliberately using a restricted character set for their own
  certs because they know other types will break).
- A small number of certs use Latin1String (fake T61String).
- I've never seen a cert with a real T61String.
- I've never seen a cert with a BMPString which actually required it.
 
For BMPStrings, Microsoft support it (because Unicode is native to their OS),
Netscape presumably support it in the latest releases, and other
implementations don't appear to support it much.
 
>If there are lots of implementations that do the lie and really don't do
>BMPString, and this WG decides to go with the {T61String that contains ISO
>8859-1} lie, we have to describe it in more than one sentence. We have to say
>exactly how to encode the T61String, and we must say that those strings MUST
>NOT contain actual T.61 text. We should then also have the transition direct
>to UTF8String, again in five years.
 
I like John Wray's suggestion of something like:
 
[UNIVERSAL 20] IMPLICIT OCTET STRING    -- Contains an 8859-1 string
 
although I'd rather call it KludgeString than PkixString (well, at least
Latin1String, which is more indicative of what it really is).
 
This use of universal tags has already been applied to add UTF8 into ASN.1
compilers which don't know about it, so it's not totally unprecedented
(although redefining a basic string type is a bit dodgy).
 
There are two things worth considering, because of the extreme scarcity of
non-PrintableStrings in certs:
 
- The apparent prevalence of 8859-1 strings in T61Strings may be entirely due
  to the if( !PrintableString ) -> T61String strategy used in many
  implementations.  Since the only non-PrintableString's being used to any
  degree are 8859-1, you naturally end up seeing 8859-1 strings.
 
- An early changeover to UTF8 may not be as painful as the installed base would
  appear to indicate because they're almost never used - it's only when people
  actually start using the things that you run into problems.
 
Bob Jueneman's calculations for 2005 make a lot of sense, but it may in fact be
possible to move the cutover date forward a bit without causing too many
problems - you need to find some reasonable balance between the followig two
cases:
 
- If you do it too soon, existing implementations will break (this is why I
  argued against an immediate cutover - even if it's mandated, vendors will
  probably be quite reluctant to risk alienating their existing users).
 
- If you leave it too late, many more implementations will perpetuate the
  kludge, making it harder to change later.
 
There are probably three main implementations which are likely to be used in
locations with i18n concerns, Netscape, assorted MS products, and SSLeay (I
realise that there are many others out there, but once these three are
converted you've got almost everything covered - the rest either have only a
small market share and/or are locked inside the ASCII-only US by export
controls).
 
How quickly can these three be switched over to UTF8, and how quickly will that
propagate through the user base?
 
Peter.

From: Nilsson Hans <[email-masked]>
To: [email-masked]
Subject: SV: PKIX-1 - use of UTF8
Date: Sun, 21 Jun 1998 09:01:02 +0100
Sender: [email-masked]

Paul,
Let me add some information on how existing public CAs work today:

* iD2 (CA system market leader in Scandinavia and Finland, where åäö are
very popular) uses exactly the white lie Peter is describing (8859-1 tagged
as T61String)
* BelSign (fast-growing public CA service in Belgium, issuing certificates
all over the world) also uses the same white lie
* Verisign: refuses to issue certificates containing strange characters as
åäö (at least a month ago when I tried it)

Maybe someone can supply information regarding Entrust and GTE/Cybertrust?

Also for your information, we have now decided to include the white lie in
the joint Swedish/Finnish certificate standard.

The only warning flag I would like to raise is the following: ALMOST all
umlaut characters fit well within 8859-1 without conflict with the T61
characters. However, the 8859-1 code for Norwegian OE (i.e. O with a
slash-thru) is the same as a T61 escape character (8859-1 column 12?), and
when you try to put a certificate containing this character into a directory
and make this attribute searchable, the directory refuses to accept it,
since it contains an illegal T61 string.

Regards
Hans

Date: Sat, 20 Jun 1998 17:12:25 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: PKIX-1 - use of UTF8
Sender: [email-masked]

Peter, you seem to have the best information on a variety of cert writers
and readers here. Are you saying that there many implementations that do
{T61String that contains ISO 8859-1} but do *not* do {BMPString} ? That
means that they have no way to create or read certs for billions of names
that don't fit in ISO 8859-1.

If these implementations actually handle both, then we should not
perpetuate the T61String hack and should go straight to BMPString. I would
really prefer to go to UTF8, but agree that we can't just not interoperate
with current implementations. We should have a cutoff date for mandating
new certs use UTF8String, and I feel comfortable with making that cutoff
five years from now, not eight.

If there are lots of implementations that do the lie and really don't do
BMPString, and this WG decides to go with the {T61String that contains ISO
8859-1} lie, we have to describe it in more than one sentence. We have to
say exactly how to encode the T61String, and we must say that those strings
MUST NOT contain actual T.61 text. We should then also have the transition
direct to UTF8String, again in five years.

--Paul Hoffman, Director
--Internet Mail Consortium

From: [email-masked]
Date: Sat, 20 Jun 1998 16:08:08 -0700
To: [email-masked], "Bob Jueneman" <[email-masked]>
Subject: Re[2]: PKIX-1 - use of UTF8
Sender: [email-masked]

--IMA.Boundary.9593838980
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Description: cc:Mail note part

     I agree with Bob, Peter, and John.
     
     First we should go with the little white lie.  Since that is what we 
     are basically doing now it's nice to see it in a standard :}
     
     Second 2005 sounds about right for the cutoff date.  It seems like a 
     long time right now but it will come quickly.  It seems just like the 
     Y2K problem that we all saw 10 years ago but said "oh well I won't be 
     coding by then so it won't matter to me".
     
     David Grawrock

______________________________ Reply Separator _________________________________
Subject: Re: PKIX-1 - use of UTF8
Author:  "Bob Jueneman" <[email-masked]> at Internet
Date:    6/20/98 11:33 AM

Peter and John,
     
My e-mail has been non compos mentis for the last several days, 
so it was a real pleasure to come back and see the responses to 
my two suggestions a couple of days ago.
     
I'll leave the technical details of the ASN.1 and string types to 
you guys, but Peter's suggestion to use straight
latin-1 but tag it as a T61String is very much in the spirit of the 
"white lie" I was suggesting, and I think it has merit. Of course the 
standards purists will have a heart attack, but we all ought to practice 
our CPR every now and then, and who better to practice on than
the people who cooked up T61 in the first place? :-)
     
It appears, that there is a reasonable amount of acceptance for 
the notion of a standardized cut-over date, but at least one person 
expressed a hope that something could be done earlier than 2005.
     
I proposed 2005 off the top of my head, but what would be realistic? 
Let's think this through.
     
Two major factors to consider are the Y2K problem and the 
Euro conversion problem.  I hadn't thought too much about 
the Y2K problem because my work doesn't involve databases,
but when someone mentions all of the various user's spreadsheet 
lying around that might stop working,  I suddenly understood the 
scope better.
     
Likewise, after installing a new version of Adobe Acrobat,  and 
browsing Adobe's web page, I came across a couple of fonts that 
contain only the Euro character in several versions.  So never mind 
the people and programs that have to deal with the currency issues 
directly, even such a relatively mundane thing as a font is probably 
going to have to be updated. Since I personally have almost 600 
different Adobe fonts of different families, and surely that many more 
TrueType and Type 1 fonts from other vendors, plus all of the 
archaic bit-mapped fonts, the scope of this second problem 
suddenly becomes staggering as well, at least for the Europeans 
and those who have routine dealings with them.  (Speaking of fonts, 
do the various character sets we are considering include the 
Euro character, and is that going to be another hit?)
     
Business people I respect have suggested that after about February 
1999, businesses aren't going to be buying ANY new software, 
except as required to fix these two problems. So if it isn't on the shelf 
by the end of this year, forget it, at least until about June of 2000.
     
I submit that it isn't likely that we'll have a reasonably solid agreement 
on this notion for at least another couple of months, the process being 
what it is.
     
In that case, there is virtually no chance that _anyone_ is going to 
implement the new solution, whatever it is, by the end of the year, 
and so at _best_ we are probably talking about mid-2000 for the 
new software to released.  That allows a good 18 to 24 month 
development cycle, which is certainly do-able assuming that there 
aren't any other higher priorities.
     
Unfortunately, some companies undoubtedly _will_ have other, 
higher priorities, and they might not get around to fixing the problem 
until after the first wave of programs convinces their marketeers 
and program management that they are going to have to address the 
problem if they want to stay in that business.  So add another 18 to 
24 months for that process. That's mid-2002 before say 80% of 
the various programs are ready.
     
Realistically, however, the users aren't going to going to rush out 
and replace all of the software that they just bought overnight. Novell is 
in the process of releasing NetWare 5.0, and we still have a significant 
fraction of our users running on NetWare 3. Likewise, although 
Windows 98 is about to come out, and Windows 95 has been 
out for three years, it is estimated that on the order of 
20% of the corporate users are still running Windows 3.1.
     
This isn't just a case of new software costing too much -- it's a question 
of stability, user training, support, other applications which
have to be converted at the same time, and all of the other hidden 
costs. These costs would still be there even if the software upgrades 
were free.
     
So I believe it would be on the order of three years, at a _minimum_, 
before the natural replacement and upgrade cycle would take effect, 
and backwards compatibility would no longer be an issue.
     
Oops, guess what.  That brings us to 2005, just like my first, off-the-cuff, 
no analysis guess predicted. And no, I didn't take that date and work 
backward -- as anyone you knows me could tell, my brain is really in my 
fingers, and I very seldom know how a message is going to come out 
before I've actually written it.
     
What think the rest of ye?
     
Bob

     
Robert R. Jueneman
Security Architect
Novell, Inc.
Network Products Group
122 East 1700 South
Provo, UT 84604
801/861-7387
[email-masked]
     
"Architects, like prophets and saints, are 
usually years ahead of their time. For this 
reason they are often difficult to live with 
at home, especially if they turn out to be 
right."
     
--IMA.Boundary.9593838980
Content-Type: text/plain; charset=US-ASCII; name="RFC822 message headers"
Content-Transfer-Encoding: 7bit
Content-Description: cc:Mail note part
Content-Disposition: inline; filename="RFC822 message headers"

Date: Sat, 20 Jun 1998 11:33:02 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Re: PKIX-1 - use of UTF8
LAA06481
Sender: [email-masked]
Precedence: bulk
--IMA.Boundary.9593838980--

Date: Fri, 19 Jun 1998 15:57:19 -0400
To: Nilsson Hans <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: SV: new profile submitted
Cc: "'Tim Polk'" <[email-masked]>, [email-masked]
Sender: [email-masked]

Hans:

>Can you please explain the background for the new writing regarding
>subjectKeyIdentifier, using 0100 + 60 bits from the SHA-1 hash of the BIT
>STRING subjectPublicKey? Is this in conformance with something else, or a
>new invention?

This aligns PKIX with a specification used by the US Government.  Neither
Tim not I saw any harm in adopting the format.  Further, the use of a
prefix allows PKIX to specify a different means of computing the key
identifier if the SHA-1 method should ever be discovered to be deficient.

Russ

Date: Sat, 20 Jun 1998 11:48:07 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: Re: RE: RE: Certificate Revocation
Sender: [email-masked]

Phill, my e-mail has been down for several days, so I am slow to 
respond. Actually, I had typed a response, but lost it when the 
system crashed, seconds before I was about to hit the send button.

But I really like the suggestion that my statement of the requirements
triggered.  W've often talked about a personal directory, i.e., a subset 
of the corporate and/or Whole Earth, directory, but I'd never thought about
a personalized CRL list.

Neat idea, and compatible with existing technology. I like that a lot.
I'd like to see you expand on your "scope" question some more.

With respect to the CD-ROM issue, however, I'm not sure that I would blow 
that off quite so quickly. I routinely download our entire corporate directory
to my laptop, because among other things it contains telephone 
numbers, e-mail address, and other things I might need, even 
(especially) when I am on the road. But the people I might need 
to call in that case are often NOT the same peole that my most recently 
used cache of e-mail contacts would include.

Novell has about 4000 employees, so the space reuqired isn't all that 
huge. And in all likelyhood, I won't need to know the data for some sales
person in Bangladesh, so I could prune the list a bit. But a CD-ROM 
plus a delta directory would still be convenient, and if I worked for 
say the US government it might be a necessity.  I routinely carry 3 CDs
of phone records for the entire US along with other CDs (including music 
CDs) when I travel, so putting the entire Internet directory on a CD isn't unreasonable.

Because I'd rather go ahead and encrypt any sensitive messages 
as the time I create them, I'm more likely to need the certificates than
I am the CRLs. But if the same mechanism could deliver both, that's
even better.

Regards,

Bob

>>> "Phillip M Hallam-Baker" <[email-masked]> 06/18 1:45 PM >>>
Carlisle,

> Just a quick request for clarification.  Are you really saying 
> "one compact
> CRL of 1Kb for *each* of the 1000 odd certificates", or are you instead
> suggesting a single CRL that might hold up to 1000 entries?

Hmm, if the CRL was created on the fly by a status responder and
contained a series of distinct OCDP scopes I suppose it COULD be 
a single CRL with 1000 scope entries. Interesting thought.

Perhaps there are more efficient methods of encoding such a response.
The query could be hashed and incorporated in the CRL as 
a scope specification... Interesting.

> The former case requires CAs to partition at one cert per 
> distribution point

Or use OCDP scopes and mark the scope extensions critical. This
allows the scopes to be produced in bulk. They are in effect an
validation token of the type proposed by Rivest but conforming 
to existing syntax and are aggregate tokens validating more 
than one certificate.

Returning to Bob's original proposal. It is quite practical to
download 1000 CRLs of 1kb when Bob connects his powerbook to
the ethernet. On the other hand when he is in roaming mode
tethered by a 28.8Kb modem some intelligent means of obtaining
the <20 CRLs he is interested in that _day_ seems appropriate.

Waiting 10 sec to download the CRLs for use that day seems
reasonable. Certainly this seems simpler to me than mucking about
with CDROMs, floppies and so on. Leave the CDROM for what it's
meant for, inflight movies and TombRaider II. Bob's personal
problem is independent of the size of the network he is on. If
we have to resort to 650Mb of information we is probably doing
something wrong.

Essentially all I am suggesting to do with OCDP at this stage is:
let us start putting the scope code into the clients. If it turns
out to be the case that revocation lists are small enough to
cope with without it we have added a few hundred unnecessary bytes 
to the executable. On the other hand if we turn out to need it I
believe we will REALLY need it. It is a high leverage idea that 
could save us all having to panic a couple of years down the road.

		Phill

Date: Sat, 20 Jun 1998 11:33:02 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Re: PKIX-1 - use of UTF8
Sender: [email-masked]

Peter and John,

My e-mail has been non compos mentis for the last several days, 
so it was a real pleasure to come back and see the responses to
my two suggestions a couple of days ago.

I'll leave the technical details of the ASN.1 and string types to 
you guys, but Peter's suggestion to use straight
latin-1 but tag it as a T61String is very much in the spirit of the 
"white lie" I was suggesting, and I think it has merit. Of course the
standards purists will have a heart attack, but we all ought to practice
our CPR every now and then, and who better to practice on than
the people who cooked up T61 in the first place? :-)

It appears, that there is a reasonable amount of acceptance for 
the notion of a standardized cut-over date, but at least one person 
expressed a hope that something could be done earlier than 2005.

I proposed 2005 off the top of my head, but what would be realistic?
Let's think this through.

Two major factors to consider are the Y2K problem and the 
Euro conversion problem.  I hadn't thought too much about
the Y2K problem because my work doesn't involve databases,
but when someone mentions all of the various user's spreadsheet 
lying around that might stop working,  I suddenly understood the 
scope better.

Likewise, after installing a new version of Adobe Acrobat,  and 
browsing Adobe's web page, I came across a couple of fonts that 
contain only the Euro character in several versions.  So never mind
the people and programs that have to deal with the currency issues
directly, even such a relatively mundane thing as a font is probably 
going to have to be updated. Since I personally have almost 600 
different Adobe fonts of different families, and surely that many more
TrueType and Type 1 fonts from other vendors, plus all of the 
archaic bit-mapped fonts, the scope of this second problem 
suddenly becomes staggering as well, at least for the Europeans 
and those who have routine dealings with them.  (Speaking of fonts, 
do the various character sets we are considering include the 
Euro character, and is that going to be another hit?)

Business people I respect have suggested that after about February
1999, businesses aren't going to be buying ANY new software, 
except as required to fix these two problems. So if it isn't on the shelf
by the end of this year, forget it, at least until about June of 2000.

I submit that it isn't likely that we'll have a reasonably solid agreement
on this notion for at least another couple of months, the process being 
what it is.

In that case, there is virtually no chance that _anyone_ is going to 
implement the new solution, whatever it is, by the end of the year,
and so at _best_ we are probably talking about mid-2000 for the 
new software to released.  That allows a good 18 to 24 month 
development cycle, which is certainly do-able assuming that there 
aren't any other higher priorities.

Unfortunately, some companies undoubtedly _will_ have other, 
higher priorities, and they might not get around to fixing the problem 
until after the first wave of programs convinces their marketeers 
and program management that they are going to have to address the
problem if they want to stay in that business.  So add another 18 to 
24 months for that process. That's mid-2002 before say 80% of 
the various programs are ready.

Realistically, however, the users aren't going to going to rush out 
and replace all of the software that they just bought overnight. Novell is
in the process of releasing NetWare 5.0, and we still have a significant 
fraction of our users running on NetWare 3. Likewise, although 
Windows 98 is about to come out, and Windows 95 has been 
out for three years, it is estimated that on the order of
20% of the corporate users are still running Windows 3.1.

This isn't just a case of new software costing too much -- it's a question
of stability, user training, support, other applications which
have to be converted at the same time, and all of the other hidden
costs. These costs would still be there even if the software upgrades
were free.

So I believe it would be on the order of three years, at a _minimum_, 
before the natural replacement and upgrade cycle would take effect,
and backwards compatibility would no longer be an issue.

Oops, guess what.  That brings us to 2005, just like my first, off-the-cuff,
no analysis guess predicted. And no, I didn't take that date and work
backward -- as anyone you knows me could tell, my brain is really in my 
fingers, and I very seldom know how a message is going to come out 
before I've actually written it.

What think the rest of ye?

Bob

Robert R. Jueneman
Security Architect
Novell, Inc.
Network Products Group
122 East 1700 South
Provo, UT 84604
801/861-7387
[email-masked]

"Architects, like prophets and saints, are 
usually years ahead of their time. For this
reason they are often difficult to live with
at home, especially if they turn out to be 
right."

From: [email-masked]
To: [email-masked], [email-masked]
Date: Fri, 19 Jun 1998 10:04:31 -0400
Subject: Re: PKIX-1 - use of UTF8
Sender: [email-masked]

Peter Gutmann ([email-masked]) writes:

>Bob Jueneman has suggested deprecating the current practice
>after a certain date (2005), which is a good approach: Accept
>both types of encoding until then to give vendors time to
>switch over, but only emit UTF8 after the cutover date.
>The ideal solution would be to take an approach like the
>cert validity Y2K fix: Provide a workaround for the current
>practice, and require a unified format (UTF8 only) after the
>cutover date.  Once everything is ready for the new
>format, we can finally lay the character set mess to rest.

I'm happy with that solution.  Codifying this in PKIX-1 would
mean three changes to the document:

1. The ASN.1 needs to be amended to convey the fact that the
teletexString choice within directoryString isn't really a
teletexString, but instead is an IA5String with a teletexString
tag.  I guess that makes it really an IA5String,
implictly-tagged as a UNIVERSAL 20 (It's not legal ASN.1
to use a Universal-class tag, so it'll need a statement to
explain that this is simply codifying existing practice).

2. The rules for choosing a code-set when emitting certificates
can stay as in the current document, but need additional text
saying that these rules are for backwards compatibility, and
are in effect only for a transition period, and that PKIX
systems should be prepared to change to the use of UTF8 in
generated certificate at some time in the future (you mention
2005 as a candidate - I'd hope we could plan for a bit sooner
than that).

3. The rules for matching names need to require codeset
conversion to UTF8 (or universal string) prior to performing
a comparison.  This will enable a change to UTF8 in the future.
If teletexString is really IA5, the reasons for not doing
caseIgnore matching on this syntax go away, and it should be
treated the same way as printableString for that purpose.

Here is some suggested text for the three changes:

1)  Page 19, DirectoryString definition:

|
|DirectoryString ::= CHOICE {
|    pkixString      PkixString(SIZE (1..MAX)),
|    printableString PrintableString(SIZE(1..MAX)),
|    universalString UniversalString(SIZE(1..MAX)),
|    utf8String      UTF8String(SIZE(1..MAX)),
|    bmpString       BMPString(SIZE(1..MAX)) }
|
|
|PkixString ::= [UNIVERSAL 20] IMPLICIT IA5String
|
|-- The use of the [UNIVERSAL 20] tag in the PkixString
|-- type is not legal ASN.1, but serves to codify
|-- existing practice.  It is to be interpreted as a
|-- character string encoded using the IA5 codeset, but
|-- tagged as though it were a TeletexString.

[Similar text needs to go in the ASN.1 appendix]

2)  Top of page 20, after the three rules for choosing
codesets in emitted certificates, add new para:

|These rules document existing certificate practices, and are
|provided for backwards compatibility between certificates
|generated by PKIX systems and consumed by existing applications.
|These rules shall be in effect only until <date>, after which
|time PKIX systems should use the UTF8String syntax for encoding
|all directoryString attribute values.

3)  Bottom of page 20, replace the "requirements for conforming
implementations" clauses a through d with:

|(a) Attribute values encoded using the printableString or pkixString
|    syntaxes shall have any leading or trailing white space removed,
|    any internal consecutive white space characters replaced with a
|    a single space, any uppercase characters converted to lowercase,
|    and their encoding converted to universalString prior to comparison.
|
|(b) Attribute values encoded using utf8String or bmpString syntaxes
|    shall be converted to universalString prior to comparison.
|
|(c) After application of transforms (a) and (b) as appropriate,
|    comparison of two attribute values shall be performed using
|    binary matching of the encoded string data.
|
|    Implementations may use an alternate comparison algorithm,
|    provided the results of the comparison are identical to those
|    given by the algorithm specified here.

John

From: Trevor Freeman <[email-masked]>
To: "Pkix List (E-mail)" <[email-masked]>
Subject: Re: PKIX-1 - use of UTF8
Date: Thu, 18 Jun 1998 18:22:11 -0700
Sender: [email-masked]

Why is it that I am not getting a warm feeling that this issue has been
thought through. 
There is a large installed base out there of systems which understand
encoding such as printable sting and Unicode, but not UTF8. Therefore UTF8
should be the last resort when all else fails. Other consideration like what
I can and cannot do with it in C pale into insignificance compared to the
prospect of not being able to decode the name. And I am sure all of the app
providers code will handle the error gracefully when they encounter the
problem of a UTF8 encoded directory string. The installed base of systems
today are using ACSII and Unicode, so lets try and live with that reality.

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: PKIX-1 - use of UTF8
Reply-To: [email-masked]
Date: Fri, 19 Jun 1998 12:49:47 (NZST)
Sender: [email-masked]

John Wray <[email-masked]> writes:
 
>I think your (b) needs a bit more expansion.
>
>You could mean either:
>
>1)   "... if the string contains characters that may be represented in both
>T.61 and ISO 8859-1, then the string shall be encoded as a T61String", or
>
>2)   "...if the string contains characters that may be represented in both ISO
>8859-1 and ISO 8859-1, and whose encoding under ISO 8859-1 is the same as
>their encoding as T61String characters, the the string shall be encoded as a
>T61 string".
 
Actually it's none of the above.  What I meant was:
 
    (b) failing (a), if the latin-1 (ISO 8859-1) character set is sufficient
the string shall be represented as a latin-1 string with a T61String tag.
 
(that may not be the best way to say it, what I mean here is to use straight
latin-1 but tag it as a T61String).
 
Before people start dusting off their flamethrowers, the reason for this is
twofold:
 
1. It codifies existing practice.  I've never found a single certificate in
   which a T61String really is a T61String - in every case it's latin-1 (if
   anyone has an example of a cert with a real T.61 string, please send me a
   copy for my collection).  For all implementations I know of, T61String
   currently *is* Latin1String.
 
2. T.61 has apparently been withdrawn by the ITU, so it's not even possible to
   get a copy of this in order to comply with it.  For people who have seen
   this or related standards like T.51/52, withdrawing it is probably a good
   move (IMNSHO any standard which requires diagrams extending into three
   dimensions in order to explain how to encode an a-umlaut has problems).
   T61String in itself (without complex escape codes and shifting) is next to
   useless because there's almost nothing which is common to latin-1 and
   straight T.61, and once you add the escape codes it's unworkable.
 
>X.509 doesn't contain an option for an 8-bit Western European codeset. If we
>want to stay within the standard, we have to go multibyte to get accented
>characters.
 
X.509 doesn't handle latin-1, but (AFAIK) every existing implementation - tens
of millions - do by treating T61String as Latin1String.  All you need to do to
work with this is add a single sentence to PKIX which codifies this practice.
There's simply too large an installed base out there to change it now, and
mandating an immediate unconditional switch to UTF8 for vendors is suicidal
because any certificates their software issues will be regarded as invalid by
virtually every application which makes use of certificates.
 
Bob Jueneman has suggested deprecating the current practice after a certain
date (2005), which is a good approach: Accept both types of encoding until then
to give vendors time to switch over, but only emit UTF8 after the cutover date.
The ideal solution would be to take an approach like the cert validity Y2K fix:
Provide a workaround for the current practice, and require a unified format
(UTF8 only) after the cutover date.  Once everything is ready for the new
format, we can finally lay the character set mess to rest.
 
Peter.

From: "Phillip M Hallam-Baker" <[email-masked]>
To: "Carlisle Adams" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: RE: Certificate Revocation
Date: Thu, 18 Jun 1998 15:45:21 -0400
Importance: Normal
Sender: [email-masked]

Carlisle,

> Just a quick request for clarification.  Are you really saying 
> "one compact
> CRL of 1Kb for *each* of the 1000 odd certificates", or are you instead
> suggesting a single CRL that might hold up to 1000 entries?

Hmm, if the CRL was created on the fly by a status responder and
contained a series of distinct OCDP scopes I suppose it COULD be 
a single CRL with 1000 scope entries. Interesting thought.

Perhaps there are more efficient methods of encoding such a response.
The query could be hashed and incorporated in the CRL as 
a scope specification... Interesting.

> The former case requires CAs to partition at one cert per 
> distribution point

Or use OCDP scopes and mark the scope extensions critical. This
allows the scopes to be produced in bulk. They are in effect an
validation token of the type proposed by Rivest but conforming 
to existing syntax and are aggregate tokens validating more 
than one certificate.

Returning to Bob's original proposal. It is quite practical to
download 1000 CRLs of 1kb when Bob connects his powerbook to
the ethernet. On the other hand when he is in roaming mode
tethered by a 28.8Kb modem some intelligent means of obtaining
the <20 CRLs he is interested in that _day_ seems appropriate.

Waiting 10 sec to download the CRLs for use that day seems
reasonable. Certainly this seems simpler to me than mucking about
with CDROMs, floppies and so on. Leave the CDROM for what it's
meant for, inflight movies and TombRaider II. Bob's personal
problem is independent of the size of the network he is on. If
we have to resort to 650Mb of information we is probably doing
something wrong.

Essentially all I am suggesting to do with OCDP at this stage is:
let us start putting the scope code into the clients. If it turns
out to be the case that revocation lists are small enough to
cope with without it we have added a few hundred unnecessary bytes 
to the executable. On the other hand if we turn out to need it I
believe we will REALLY need it. It is a high leverage idea that 
could save us all having to panic a couple of years down the road.

		Phill

From: Carlisle Adams <[email-masked]>
To: "'Phillip Hallam-Baker'" <[email-masked]>
Cc: [email-masked]
Subject: RE: RE: Certificate Revocation
Date: Thu, 18 Jun 1998 14:59:58 -0400
Sender: [email-masked]

Hi Phill,

> ----------
> From: 	Phillip Hallam-Baker[SMTP:[email-masked]]
> Sent: 	Thursday, June 18, 1998 2:02 PM
> To: 	Bob Jueneman; [email-masked]; [email-masked]
> Subject: 	RE: RE: Certificate Revocation
> 
> It seems to me that using OCDP to create one compact CRL of 1Kb
> for each of the 1000 odd certificates Bob is likely to deal with
> on his portable is a good plan.
> 
Just a quick request for clarification.  Are you really saying "one compact
CRL of 1Kb for *each* of the 1000 odd certificates", or are you instead
suggesting a single CRL that might hold up to 1000 entries?

The former case requires CAs to partition at one cert per distribution point
(certainly possible within the standard, but I think it's unlikely that many
CAs will do this).  The latter case, combined with the remainder of your
sentence, requires the CA to partition according to the set of people Bob is
likely to deal with...

> Protecting the sending of encrypted mail suggests that he needs
> a batch SMTP send client that downloads the most up to date CRL 
> and performs a CRL validity check before transmission.
> 
There are existing products that have been doing this for some time, so I
agree with you that it appears that Bob's requirements can be met.

Carlisle.

From: "Phillip Hallam-Baker" <[email-masked]>
To: "Bob Jueneman" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: RE: Certificate Revocation
Date: Thu, 18 Jun 1998 14:02:58 -0400
Importance: Normal
Sender: [email-masked]

> But what about the case where you are about to send off 
> an encrypted message? There I care a little more whether
> the certificate is valid, because although I probably have
> a pretty good reasonableness-filter to detect an imposter 
> independent of the signature, if my correspondent's keys have
> been compromised, or if he is no longer with the same 
> company, I definitely don't want to send the message.

I think this is an important point.

Editing Bob's requirement's down a tad:

1) He has a quasi-offline connection
	In this case he has a notebook which connects to the 
	Internet at irregular intervals.
2) He is going to send email
	Aha! he has to connect to a network before the
	damage is done.

I would also venture that

3) He has limited storage on his machine

4) Regardless of the number of people who obtain a certificate
	Bob is only interested in communicating with a limited 
	number.

These latter two constraints suggest to me that we have a scaling 
constraint, but also a constraint on the fundamental complexity
of the problem.

It seems to me that using OCDP to create one compact CRL of 1Kb
for each of the 1000 odd certificates Bob is likely to deal with
on his portable is a good plan.

The machine can download these into his system each time he
makes a connection.

Protecting the sending of encrypted mail suggests that he needs
a batch SMTP send client that downloads the most up to date CRL 
and performs a CRL validity check before transmission. Alternatively
a module of this type could be built into a mail hub (incidentially
why is it that mail clients insist on sending THROUGH a mail hub
these days rather than directly?).

Another program could perform a periodic spring clean of his
certificate database, checking to see if all his certificates 
were current.

Otherwise Bob's requirements appear pretty easy to meet provided 
he does not insist on being able to base decisions on material
more recent than his last contact with the world at large.

		Phill

Date: Thu, 18 Jun 1998 11:23:59 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: RE: Certificate Revocation
Sender: [email-masked]

Fair enough, Hal. You probably aren't going to make any 
crucial decisions that depend on the CRL at all, never 
mind whether it is completely current.

Just how you go back and revalidate mail you have 
already opened is an interesting question. Maybe, as you 
suggest, you don't bother unless you have some reason
to suspect the message.  After all, it was signed, wasn't it?
That must mean that it is secure, right? Surely no one 
expects me to go get the keys necessary to validate all
the signed PGP mail I get, do they? It looks impressive,
so it must be secure. :-)

But what about the case where you are about to send off 
an encrypted message? There I care a little more whether
the certificate is valid, because although I probably have
a pretty good reasonableness-filter to detect an imposter 
independent of the signature, if my correspondent's keys have
been compromised, or if he is no longer with the same 
company, I definitely don't want to send the message.

So what do you do?  Do you defer the actual encryption 
until transmission time, i.e., when you land and plug in your
laptop and dial up your server? Is the amount of additional 
time that would take of concern?

What happens to the message prior to the time that it is 
encrypted?  Does it sit there in the clear, naked and 
vulnerable to someone who steal my laptop prior to my getting
a successful connection? Or should I encrypt it in my own
private key and hold it that way until I can re-encrypt the 
message key in the public key of the authenticated user?

If I can't access the latest CRL database instantly, should 
I not send the message?

I'm not just asking rhetorical questions -- these are very real 
issues that are presently confronting us.

What to other S/MIME users/vendors do to solve this
disconnected mode of operation question?

Bob

>Warwick Ford <[email-masked]> wrote on 06/17 9:49 PM:
>
>>An example of a state maintenance problem here would be getting your laptop
>>out on the plane and realizing that, while you had been astute enough to
>>pick up the latest diskette, you had brought the wrong CD for that diskette.
>
>At 08:39 PM 6/17/98 -0600, Bob Jueneman wrote:
>>Yup.  Things like that happen, but only to other people, right?
>>
>>But at least you can listen to the Eagles, or play a game, or do 
>>whatever else WAS on the diskette that you brought!
>>
>>Option two, per Dilbert, is to use the CD drawer in your computer as a 
>>handy-dandy coffee cup holder. That will solve several other 
>>problems as well.
>
>Engineers frequently get accused of using technology for its own sake.
>Let's try to get back to reality.  In practice, you are most likely to read
>the message and decide, based on its contents, whether to even bother to
>verify its signature, later on.
>
>Hal
>
>==============================================================
>======
>Harold W. Lockhart Jr.               PLATINUM technology
>Chief Technical Architect            8 New England Executive Park
>Email: [email-masked]  Burlington, MA 01803 USA
>Voice: (781)273-6406                 Fax: (781)229-2969
>==============================================================
>======

Date: Thu, 18 Jun 1998 11:03:04 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: PKIX-1 - use of UTF8
Sender: [email-masked]

John, thanks for your informative reply. Since I suspect 
most of us are not specialists in this rather arcane area,
the education is useful.
>
>>>> <[email-masked]> 06/18 10:37 AM >>>
>Bob Jueneman ([email-masked]) writes:
>
>>John, not having looked at the API implications of UTF-8, I can't say
>>whether it is more implementor friendly than BMPString or not. Frankly,
>>I would be perfectly happy to stick with Unicode universally, as memory0
>>and communications costs continue to decrease, while programmers
>>time, effort, and salaries continue to increase.  And I understand that
>>BMPString, which always uses two bytes, is much easier to parse,
>>since it doesn't necessarily have to be converted into say Unicode for
>>processing. (I may have an incorrect understanding of this, but if it is
>>true,I would have a hard time arguing that UTF-8 is more
>>implementor-friendly.)
>
>The reasons I'm claiming UTF-8 is implementor friendly are:
>
>i)  It is designed such that code that scans a string looking for specific
>7-bit ASCII characters will find them, without having to know that the
>string is actually a UTF-8 string - that is, octet values between 0 and
>0x7f always mean the corresponding ASCII character, and are never a part of
>some other character.  One result of this is that you can use a standard C
>char * object to hold a UTF-8 string, and most standard C string-handling
>routines (e.g. strcmp, strcpy etc) will work just fine.
>
>ii) It is the standard way that Java strings are passed to C code via the
>Java Native Interface, so it's a natural codeset for applications that are
>written part in Java and part in C/C++.
>
>iii) It's an byte-stream oriented encoding, so there are no endian-ness
>issues lurking to trip up unwary programmers.

OK, I guess I'll buy that set of arguments -- they're pretty convincing.
>
>>However, decreasing the options to be considered from three to two is
>>a step in the right direction, but two options still requires a lot of
>>additional and rather useless decision making, testing, etc.
>>
>>If as I understand it, UTF-8 produces one byte encodings for the
>equivalent
>>(at least roughly) for the western European unaccented characters, and
>>other encoding schemes for those characters generally require two bytes
>>in any case, why not use UTF-8 universally?  (This assumes that the
>>universal use of BMPString would not acceptable, presumably for the
>>arguable efficiency considerations.)
>
>That's right.  For 7-bit ASCII characters, UTF-8 encoding is the same as
>ASCII.
>
>>(Obviously for backwards compatibility incoming PrintableString and
>>BMPString,and maybe even Teletex will have to continue to be supported
>>for some period of time, but hopefully they could be strongly deprecated
>>after say 2005.)
>>
>>If the decision is made to support both PrintableString and UTF-8,
>>would an implementation be conforming if it chose to output everything
>>in UTF-8, whether it could have been encoded in a more restrictive
>>character set or not?  (That would be my preference.)
>
>Interoperability with current code.  Firstly, UTF8 and BMPString are recent
>additions to the permitted syntaxes for directoryString, and certificates
>using either of these syntaxes are unlikely to be understood by deployed
>code.  Also, there's a slightly less serious problem in that PKIX has
>currently adopted a very strict set of rules for comparison of strings (for
>example, during certificate chain processing).  PKIX-1 mandates that two
>strings are considered different if they are encoded using different
>syntaxes, regardless of their contents.  This means that if PKIX issues
>certificates encoded using UTF8 or BMPString, those certificates can never
>be part of the same trust chain as a certificate issued by a system that
>chooses a different syntax.

I would defer to Peter Gutmann on this subject, but my impression 
is that the world is pretty well broken in this area.  We've had a hard 
enough time trying to get Netscape and Microsoft browsers to accept
the same certificate string, but as an international company with nearly 40
million users outside the US, we obviously are very concerned about
double-byte encoding.

I like your suggestion of upconverting to a common character set 
for equivalence matching. I'm very concerned that with bowser 
manufacturers all over the world, plus CA toolkit vednors equally 
distributed internationally, plus multinational corporations, nothing is
going to be interoperable.

It certainly seems undesirable to force the subject and issuer name 
to be in two different character sets in order to verify the certificate 
hierarchy, for exmaple.
>
>>Finally, what does it mean to say that a character set is "sufficient"?
>>Does this mean that a given character string has to be examined
>>one character at a time to see whether an accented character just
>>happens to be included in that person's name, for example?
>
>Yes, that's pretty much it.

That seems like a really unfortunate and inefficient requirement.
>
>>Or, as I would prefer, can the decision be made on the basis of the
>>basic code set in use, so  that a user who normally uses German
>>would always their input encoded the same way, regardless of the
>>actual characters used?
>
>Not with the current PKIX string matching rules.  "Fred" encoded as a
>printableString is defined as different to "Fred" encoded as a BMPString,
>or UniversalString, or UTF8String - all of these "Fred"s have to be
>considered as distinct and different names, even though it's trivial to
>convert between those encodings.  Because of this, PKIX has to mandate the
>encoding syntax used, so that certificates have a chance of chaining
>properly.

Obviously the other approach is to mandate the use of a single, universal
encoding syntax.
>
>In another message, I suggested a relaxation of the matching rules to allow
>conversion to a standard syntax prior to comparison.  This would make it
>possible for us to change or relax the rules for picking a syntax to use
>when emitting certificates, if we so desired.  This would allow us to use
>the current arcane rules for a transition period so that PKIX can
>interoperate with current systems, but in the future, when more systems
>understand UTF8, PKIX could switch to specifying that as the prefered
>syntax, without breaking anything.

Is it the case that the characters in 7-bit ASCII are encoded the same way 
in both PrintableString and UTF-8?  I.e.., is PrintableString a strict encoding
subset of UTF-8?

If so, is there some way that we could "lie" and accept 7-bit ASCII 
as though it were UTF-8, and vice versa, so long as no other 
characters were included? That might be an acceptable (temporary) 
operational restriction.

If true, this might be an acceptable answer as to how to get over the interoperability hurdle.  If I'm supposed to output UTF-8 but no one's 
browser can read it, no one will buy my product.  So the market winner 
is the last person who complies with the standard? Doesn't sound like
a recipe for success.

These are hard problems. I'm glad someone is thinking about them.
The "let them eat cake," i.e., "use English" approach isn't going to 
work much longer.

Bob
>
>John
>
>

From: [email-masked]
To: [email-masked]
cc: [email-masked]
Date: Thu, 18 Jun 1998 12:37:48 -0400
Subject: Re: PKIX-1 - use of UTF8
Sender: [email-masked]

Bob Jueneman ([email-masked]) writes:

>John, not having looked at the API implications of UTF-8, I can't say
>whether it is more implementor friendly than BMPString or not. Frankly,
>I would be perfectly happy to stick with Unicode universally, as memory0
>and communications costs continue to decrease, while programmers
>time, effort, and salaries continue to increase.  And I understand that
>BMPString, which always uses two bytes, is much easier to parse,
>since it doesn't necessarily have to be converted into say Unicode for
>processing. (I may have an incorrect understanding of this, but if it is
>true,I would have a hard time arguing that UTF-8 is more
>implementor-friendly.)

The reasons I'm claiming UTF-8 is implementor friendly are:

i)  It is designed such that code that scans a string looking for specific
7-bit ASCII characters will find them, without having to know that the
string is actually a UTF-8 string - that is, octet values between 0 and
0x7f always mean the corresponding ASCII character, and are never a part of
some other character.  One result of this is that you can use a standard C
char * object to hold a UTF-8 string, and most standard C string-handling
routines (e.g. strcmp, strcpy etc) will work just fine.

ii) It is the standard way that Java strings are passed to C code via the
Java Native Interface, so it's a natural codeset for applications that are
written part in Java and part in C/C++.

iii) It's an byte-stream oriented encoding, so there are no endian-ness
issues lurking to trip up unwary programmers.

>However, decreasing the options to be considered from three to two is
>a step in the right direction, but two options still requires a lot of
>additional and rather useless decision making, testing, etc.
>
>If as I understand it, UTF-8 produces one byte encodings for the
equivalent
>(at least roughly) for the western European unaccented characters, and
>other encoding schemes for those characters generally require two bytes
>in any case, why not use UTF-8 universally?  (This assumes that the
>universal use of BMPString would not acceptable, presumably for the
>arguable efficiency considerations.)

That's right.  For 7-bit ASCII characters, UTF-8 encoding is the same as
ASCII.

>(Obviously for backwards compatibility incoming PrintableString and
>BMPString,and maybe even Teletex will have to continue to be supported
>for some period of time, but hopefully they could be strongly deprecated
>after say 2005.)
>
>If the decision is made to support both PrintableString and UTF-8,
>would an implementation be conforming if it chose to output everything
>in UTF-8, whether it could have been encoded in a more restrictive
>character set or not?  (That would be my preference.)

Interoperability with current code.  Firstly, UTF8 and BMPString are recent
additions to the permitted syntaxes for directoryString, and certificates
using either of these syntaxes are unlikely to be understood by deployed
code.  Also, there's a slightly less serious problem in that PKIX has
currently adopted a very strict set of rules for comparison of strings (for
example, during certificate chain processing).  PKIX-1 mandates that two
strings are considered different if they are encoded using different
syntaxes, regardless of their contents.  This means that if PKIX issues
certificates encoded using UTF8 or BMPString, those certificates can never
be part of the same trust chain as a certificate issued by a system that
chooses a different syntax.

>Finally, what does it mean to say that a character set is "sufficient"?
>Does this mean that a given character string has to be examined
>one character at a time to see whether an accented character just
>happens to be included in that person's name, for example?

Yes, that's pretty much it.

>Or, as I would prefer, can the decision be made on the basis of the
>basic code set in use, so  that a user who normally uses German
>would always their input encoded the same way, regardless of the
>actual characters used?

Not with the current PKIX string matching rules.  "Fred" encoded as a
printableString is defined as different to "Fred" encoded as a BMPString,
or UniversalString, or UTF8String - all of these "Fred"s have to be
considered as distinct and different names, even though it's trivial to
convert between those encodings.  Because of this, PKIX has to mandate the
encoding syntax used, so that certificates have a chance of chaining
properly.

In another message, I suggested a relaxation of the matching rules to allow
conversion to a standard syntax prior to comparison.  This would make it
possible for us to change or relax the rules for picking a syntax to use
when emitting certificates, if we so desired.  This would allow us to use
the current arcane rules for a transition period so that PKIX can
interoperate with current systems, but in the future, when more systems
understand UTF8, PKIX could switch to specifying that as the prefered
syntax, without breaking anything.

John

Date: Thu, 18 Jun 1998 09:15:29 -0700
To: [email-masked]
From: Michael Myers <[email-masked]>
Subject: POP in CRMF
Sender: [email-masked]

All,

The POP discussions have immediate relevance to the CRMF work product out
for review.  Consistent with Stefan's observation, there are several
variations of POP for different deployment scenarios:

1. Signature key:
   a) Produce a signature using the private key.
   b) Produce a MAC value which is a function of
      the public signature key and a shared secret. 

2. For encryption keys:
   a) Include an encrypted version of the private in
      the certification request.
   b) Produce a MAC which is a function in part of
      the subscriber's private key and the CA's
      public key (key agreement only).
   c) Engage in a challenge-response protocol.

3. Delegate POP to an RA.

Mike

At 09:45 AM 6/18/98 +0200, Stefan Santesson wrote:
>Thanks Mike for putting this debate into the right perspective.
>
>At 11.01 1998-06-16 -0600, Mike Smith wrote:
>>These operational procedure capabilities must be supported by the technical 
>>requirements at a minimum, but not the requirement to conduct such
>operational 
>>testing itself.  POP and all other operational requirements or best
>practices 
>>should be in the policies and concept of operations efforts and so should 
>>the debate.
>
>Is this debate really about protocols or policies ?
>
>When defining a protocol for certificate request it would be wise to include 
>mechanisms for POP.
>
>But the decision to mandate POP for a specific set of certificates can only
>be made by
>the CA and should then reflect the identified certificate policy where this
>requirement
>should be specified.
>
>Personally, I find that many technical issues discussed in this list really
>are policy 
>issues and policy issues are virtually impossible to discuss without first
>defining the
>type of community and set of applications (with common security
>requirements)in which the
>policy is to be used. 
>
>/Stefan Santesson
>
>
>----------------------------------------------------------------
>Stefan Santesson                <[email-masked]>
>Accurata Systemsäkerhet AB     
>Lotsgatan 27 D                  Tel. +46-40 152211              
>216 42  Malmö                   Fax. +46-40 150790              
>Sweden                        Mobile +46-70 5247799
>----------------------------------------------------------------
>
>

From: Ian Roberts <[email-masked]>
Date: Thu, 18 Jun 1998 17:07:16 +0000
To: [email-masked]
Subject: CRL This/Next Update
Sender: [email-masked]

Can a CRL be issued with a later this update date, but an earlier next   
update date?

For example

Time            t1        t2           t3        t4
CRL1            |--------------------------------|
CRL2                      |------------|

What should happen between time t3 and t4?

I had initially thought that we should specify that no CA should issue   
CRLs with a Next Update Date earlier that any previous CRL, but this   
would make it difficult if a CA wished to start issuing CRLs more   
frequently than it had previously.

I believe that unless CRL3 is issued before t3, that verification should   
fail since CRL2 (the latest) has expired.

Also,

PKIX Part 1 states that the This Update date is the date of issue - I   
presume from this that no CA should post a CRL with a This Update date in   
the future.

If a (valid) CRL is received with a This Update date in the future, what   
action should a validator take?

If one takes the CRL with the latest This Update date, then one must also   
use the CRL date as the expiry date for Certificates (lest a previously   
revoked certificate which expires between now and the This Update date is   
incorrectly accepted since it will not be in the new CRL).

Failing this one should ignore the new CRL until the This Update date is   
reached, but ignoring a newer CRL makes me uncomfortable.

Thoughts?

I think these two issues should be tightened up in the draft.  
--
Zergo Limited, The Square, Basing View, Basingstoke, Hants. RG21 4EG, UK
Tel: + 44 (0) 1442 342 600    Fax: +44 (0) 1256 812 901
Website:  http://www.zergo.com

Date: Thu, 18 Jun 1998 09:08:45 -0400
To: "Bob Jueneman" <[email-masked]>, [email-masked], [email-masked], [email-masked]
From: Hal Lockhart <[email-masked]>
Subject: Re: RE: Certificate Revocation
Sender: [email-masked]

Warwick Ford <[email-masked]> wrote on 06/17 9:49 PM:

>An example of a state maintenance problem here would be getting your laptop
>out on the plane and realizing that, while you had been astute enough to
>pick up the latest diskette, you had brought the wrong CD for that diskette.

At 08:39 PM 6/17/98 -0600, Bob Jueneman wrote:
>Yup.  Things like that happen, but only to other people, right?
>
>But at least you can listen to the Eagles, or play a game, or do 
>whatever else WAS on the diskette that you brought!
>
>Option two, per Dilbert, is to use the CD drawer in your computer as a 
>handy-dandy coffee cup holder. That will solve several other 
>problems as well.

Engineers frequently get accused of using technology for its own sake.
Let's try to get back to reality.  In practice, you are most likely to read
the message and decide, based on its contents, whether to even bother to
verify its signature, later on.

Hal

====================================================================
Harold W. Lockhart Jr.               PLATINUM technology
Chief Technical Architect            8 New England Executive Park
Email: [email-masked]  Burlington, MA 01803 USA
Voice: (781)273-6406                 Fax: (781)229-2969
====================================================================

Date: Thu, 18 Jun 1998 08:59:55 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Re: PKIX-1 - use of UTF8
Sender: [email-masked]

John, not having looked at the API implications of UTF-8, I can't say 
whether it is more implementor friendly than BMPString or not. Frankly,
I would be perfectly happy to stick with Unicode universally, as memory 
and communications costs continue to decrease, while programmers
time, effort, and salaries continue to increase.  And I understand that
BMPString, which always uses two bytes, is much easier to parse,
since it doesn't necessarily have to be converted into say Unicode for
processing. (I may have an incorrect understanding of this, but if it is true,
I would have a hard time arguing that UTF-8 is more implementor-friendly.)

However, decreasing the options to be considered from three to two is 
a step in the right direction, but two options still requires a lot of additional 
and rather useless decision making, testing, etc.

If as I understand it, UTF-8 produces one byte encodings for the equivalent
(at least roughly) for the western European unaccented characters, and 
other encoding schemes for those characters generally require two bytes 
in any case, why not use UTF-8 universally?  (This assumes that the 
universal use of BMPString would not acceptable, presumably for the 
arguable efficiency considerations.)

(Obviously for backwards compatibility incoming PrintableString and BMPString,
and maybe even Teletex will have to continue to be supported for 
some period of time, but hopefully they could be strongly deprecated 
after say 2005.)

If the decision is made to support both PrintableString and UTF-8,
would an implementation be conforming if it chose to output everything
in UTF-8, whether it could have been encoded in a more restrictive
character set or not?  (That would be my preference.)

Finally, what does it mean to say that a character set is "sufficient"?
Does this mean that a given character string has to be examined 
one character at a time to see whether an accented character just 
happens to be included in that person's name, for example?

Or, as I would prefer, can the decision be made on the basis of the 
basic code set in use, so  that a user who normally uses German 
would always their input encoded the same way, regardless of the 
actual characters used?

Bob

Robert R. Jueneman
Security Architect
Novell, Inc.
Network Products Group
122 East 1700 South
Provo, UT 84604
801/861-7387
[email-masked]

"Architects, like prophets and saints, are 
usually years ahead of their time. For this
reason they are often difficult to live with
at home, especially if they turn out to be 
right."
turn out to be right."

>>> <[email-masked]> 06/17 7:49 AM >>>
As requested, here is a change request with suggested text, against the
latest PKIX-1 draft.

Top of page 20.  Current text:

    (a) if the character set is sufficient, the string will be represented
as a PrintableString;

    (b) failing (a), if the BMPString character set is sufficient the
string shall be represented as a BMPString; and

    (c) failing (a) and (b), the string shall be represented as a
UTF8String.

Replacement text:

    (a) if the character set is sufficient, the string will be represented
as a PrintableString;

    (b) failing (a), the string shall be represented as a UTF8String.

Rationale:

As discussed on the list, the current text means that BMPString will be
used for all names that don't fit into the restricted printableString
character-set; UTF8 will never be used.  UTF8 is a much more
implementor-friendly code-set than BMPString, and is the IETF's recommended
international codeset, and we should use it in preference to BMPString.

John

From: [email-masked]
To: [email-masked], [email-masked]
Date: Thu, 18 Jun 1998 10:32:43 -0400
Subject: Re: PKIX-1 - use of UTF8
Sender: [email-masked]

Peter ([email-masked]) writes:

>I disagree with the requirement to jump straight to UTF8String.  This is
going
>to break compatibility with virtually every implementation in existence at
the
>moment, and make any PKIX-compliant cert impossible to verify with any
existing
>software... imagine the nightmare this will pose to anyone who obtains or
>issues a new cert which is going to be rejected as invalid by the existing
>installed base of tens of millions of browsers and whatnot.  I think a
much
>better approach, which retains compatilibity with existing
implementations, is:
>
>    (a) if the character set is sufficient, the string will be represented
as
>a PrintableString;
>
>    (b) failing (a), if the latin-1 (ISO 8859-1) character set is
sufficient
>the string shall be represented as a T61String containing only latin-1
>characters; and
>
>[then either a jump to UTF8 or an optional layover in BMPString, depending
on
> how people feel about this]
>
>Rationale:
>
>Pretty much every implementation and OS in existence supports latin-1
natively.
>This is compatible with (I would hope) all existing implementations - the
only,
>very minor change this makes is that it constrains T61String to contain
only
>latin-1 characters rather than the full menagerie of T.61 characters
(which I
>doubt anyone ever used anyway).

I think your (b) needs a bit more expansion.

You could mean either:

1)   "... if the string contains characters that may be represented in both
T.61 and ISO 8859-1, then the string shall be encoded as a T61String", or

2)   "...if the string contains characters that may be represented in both
ISO 8859-1 and ISO 8859-1, and whose encoding under ISO 8859-1 is the same
as their encoding as T61String characters, the the string shall be encoded
as a T61 string".

(2) would be basically saying if the string doesn't fit in printableString,
but contains only 7-bit ASCII characters, or the handful of currency and
punctuation symbols that are common between T.61 and ISO 8859-1, then
encode it as a T61String.  This wouldn't buy a lot, since the major
omissions from printableString (other than underscore, semicolon and the
"@"-sign) are accented characters, which are also absent from 7-bit ASCII.

Assuming (1) is what you mean, that's a compromise I could live with
(assuming that UTF-8, and not BMPString is what is used if you have to
stray outside ISO 8859-1).  It allows the small number of "important"
accented characters permitted in ISO 8859-1 to be encoded as T.61
accent+character 2-byte sequences.  However, is there a way we can flag
this usage of T.61 as "transitional" or "for backwards compatibility"? T.61
is a horrible codeset, and we really should be looking towards UTF-8 as the
way to represent internationalized strings in the future.  We should at
least write the specs such that a PKIX-compliant system would interoperate
with a system that used UTF-8.  For example, we could adopt your
modification above for transmission of data, but require that PKIX systems
will accept such data encoded in either UTF-8 or T.61, and perform string
comparisons on such data as though they were converted to UTF-8 before
comparison.

The resulting change to PKIX-1 would be:

|    (a) if the character set is sufficient, the string will be represented
|    as a PrintableString;
|
|    (b) failing (a), if the latin-1 (ISO 8859-1) character set would
|    be sufficient, the string shall be represented as a T61String.
|
|    (c) failing (b), the string shall be represented as a UTF8String.

Also, the text at the bottom of page 20 would change to:

|    (a) Attribute values encoded using the printableString syntax
|    shall have any leading or trailing white space removed, any
|    internal consecutive white space characters replaced with a
|    a single space, and any uppercase characters converted to
|    lowercase prior to comparison.
|
|    (b) Attribute values encoded using T61String syntax shall be converted
|    to the UTF8String prior to comparison.
|
|    (c) After application of transforms (a) and (b), comparison of two
|    attribute values encoded using the same syntax shall be performed
|    using binary matching of the encoded string data; attribute values
|    encoded using different syntaxes may be assumed to represent different
|    strings.
|
|    Implementations may use an alternate comparison algorithm, provided
the
|    results of the comparison are identical to those given by the
algorithm
|    specified here.

If we really want to foster interoperation with what's out there today,
we should make rule (a) also convert to UTF-8, and extend rule (b) to
require conversion of BMPString and UniversalString to UTF-8 prior to
comparison too.

John

Date: Thu, 18 Jun 1998 08:25:31 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: proof-of-possession for DH keys
Sender: [email-masked]

Adam,

Whenever I am involved in this kind of analysis, I tend to reach 
for the "bigger hammer," i.e., a tool that I know will get the job 
done, rather then trying to finesse the issue with the least 
possible constraint.
>
>Carlisle writes:
>> > You assume that I am holding the corresponding private decryption key.
>> > If I don't, I am unable to decrypt. That case might happen if, when
>> > performing my certification request, I provided garbage data instead of
>> > a real public key or if I *willingly* gave the value of the public key
>> > from someone else. 
>> > 
>> 
>> This is the whole purpose of doing POP: precisely to prevent such
>> pointless actions on the part of the requester.
>
>Preventing against the "pointless action" attack is kind of hard --
>normally parties are expected to be acting in their own interests.

Well, yes, honest parties presumably do. But here are a lot of 
subtle issues that lurk on the fringes, and that are quite easy to miss.

For example, it is reasonably well understood why it is important
to insist on POP in the case of a digital signature key, since someone 
might include someone else's public key in their certificate, and later 
falsely claim attribution of that person's work, if it turned out to be valuable.

Given that problem, and Carlisle's quite reasonable, IMHO, argument 
against creating useless, if not provably dangerous, certificates, I would 
certainly opt for the more conservative position.

I don't know, and don't have time to think about, all of the possible 
ramifications of not requiring POP. I do think it would be necessary to 
analyze almost all protocols that might ever use certificates, including those such as SSL that use a single certificate and key for both encryption and 
authentication.

Certainly we ought to consider every possible combination and use of the keyUsage bits in that analysis (and that alone is enough to make my head hurt),
together with all of the popular algorithms and variants, to make sure that 
no harm is even potentially lurking there.

After all, even the public key substitution attack surprised a number of us
(followed by a head-slapping, "of course").  And there have been far, FAR,
too many cryptographic protocols and schemes that looked sound when 
first proposed but later turned out to be flawed. I've broken a few myself,
and unfortunately had some of mine broken by people that were more 
perspicacious than myself. It's a humbling experience that teaches you a 
lesson.

I am sympathetic to the argument that as protocol designers we should not 
unduly constrain the developers. But not, I believe, at the possible expense of
introducing unanalyzed flaws. And although I hate to disagree with my 
friend Mike Smith , although there may be some CAs who will have the 
considerable technical expertise to deal with these issues within their 
Certification Practice Statement, the VAST majority of CAs will NOT have 
anywhere near the assembled talent represented by this body, and may 
make serious mistakes if not adequately guided.

So my position is that if someone can construct a fully worked out 
logical PROOF (not just arm-waving or proof by example) that not 
requiring POP, although harmful in case A, is completely harmless 
in all other cases, I will read it with interest.  But until then, and certainly 
at Last Call, I believe we should stick to the more conservative, safer 
position.

Bob

From: [email-masked]
To: [email-masked]
cc: [email-masked]
Date: Thu, 18 Jun 1998 10:20:16 -0400
Subject: Re: PKIX-1 - use of UTF8
Sender: [email-masked]

Paul Koning ([email-masked]) writes:

>I agree with Peter and Stefan.
>
>The rule has to support Western European names in an encoding with 8
>bits per character, as 8859-1 does.  Forcing multibyte representations
>on such strings is not good.

That's not what Peter is saying.  He is (unless I've misunderstood him)
advocating the use of T61String to encode strings that fall within the
ISO 8859-1 character set.  T.61 encodes accented characters as
double-byte sequences (one byte for the base character, and one byte
for the accent).

X.509 doesn't contain an option for an 8-bit Western European codeset.
If we want to stay within the standard, we have to go multibyte to
get accented characters.

John

Date: Thu, 18 Jun 1998 09:44:04 -0400
From: Paul Koning <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: PKIX-1 - use of UTF8
Sender: [email-masked]

I agree with Peter and Stefan.

The rule has to support Western European names in an encoding with 8
bits per character, as 8859-1 does.  Forcing multibyte representations 
on such strings is not good.

On the BMP vs. UTF8 question, could this be a place for the "strict
when sending, lenient when receiving" theory?  I.e., require UTF8 in
new certs but accept BMP for backward compatibility?

	paul

Date: Thu, 18 Jun 1998 11:39:59 +0200
To: [email-masked], [email-masked], [email-masked]
From: Stefan Santesson <[email-masked]>
Subject: Re: PKIX-1 - use of UTF8
Sender: [email-masked]

Could someone explain to me why we can't use ISO 8859-1

Being from Sweden, one of the many European countries who
use characters outside of the 7-bit PrintableString format but
still being able to use the ISO 8859-1 8 bit format, I still 
wonder why there is no place for defining a working 8 bit code.

There was T-61 string but using this, many programs (like MS IE
and Netscape) still interpret it as ISO 8859-1.

I think we share this problem with countries like Norway, Denmark
Finland, Germany, France, etc.

We have many times been faced with the fact

a) Printable string is not enough
b) 8-bit coding like T-61 string is not treated
   correct by applications on the market.
c) complex coding (like BMPsting) is rejected by
   many applications. 

Will UTF8String solve this problem ?

I guess there must be a reason for not having a valid option
of defining ISO 8859-1 (such as lack of definitions in X.509) 
but I'm still puzzled about this. Could someone help me out.

/Stefan Santesson

At 09.49 1998-06-17 -0400, [email-masked] wrote:
>As requested, here is a change request with suggested text, against the
>latest PKIX-1 draft.
>
>Top of page 20.  Current text:
>
>    (a) if the character set is sufficient, the string will be represented
>as a PrintableString;
>
>    (b) failing (a), if the BMPString character set is sufficient the
>string shall be represented as a BMPString; and
>
>    (c) failing (a) and (b), the string shall be represented as a
>UTF8String.
>
>Replacement text:
>
>    (a) if the character set is sufficient, the string will be represented
>as a PrintableString;
>
>    (b) failing (a), the string shall be represented as a UTF8String.
>
>Rationale:
>
>As discussed on the list, the current text means that BMPString will be
>used for all names that don't fit into the restricted printableString
>character-set; UTF8 will never be used.  UTF8 is a much more
>implementor-friendly code-set than BMPString, and is the IETF's recommended
>international codeset, and we should use it in preference to BMPString.
>
>John
>
>
>
>
>
----------------------------------------------------------------
Stefan Santesson                <[email-masked]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. +46-40 152211              
216 42  Malmö                   Fax. +46-40 150790              
Sweden                        Mobile +46-70 5247799
----------------------------------------------------------------

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: PKIX-1 - use of UTF8
Reply-To: [email-masked]
Date: Thu, 18 Jun 1998 20:19:57 (NZST)
Sender: [email-masked]

>Top of page 20.  Current text:
>
>    (a) if the character set is sufficient, the string will be represented as
>a PrintableString;
>
>    (b) failing (a), if the BMPString character set is sufficient the string
>shall be represented as a BMPString; and
>
>    (c) failing (a) and (b), the string shall be represented as a UTF8String.
>
>Replacement text:
>
>    (a) if the character set is sufficient, the string will be represented as
>a PrintableString;
>
>    (b) failing (a), the string shall be represented as a UTF8String.
 
I disagree with the requirement to jump straight to UTF8String.  This is going
to break compatibility with virtually every implementation in existence at the
moment, and make any PKIX-compliant cert impossible to verify with any existing
software... imagine the nightmare this will pose to anyone who obtains or
issues a new cert which is going to be rejected as invalid by the existing
installed base of tens of millions of browsers and whatnot.  I think a much
better approach, which retains compatilibity with existing implementations, is:
 
    (a) if the character set is sufficient, the string will be represented as
a PrintableString;
 
    (b) failing (a), if the latin-1 (ISO 8859-1) character set is sufficient
the string shall be represented as a T61String containing only latin-1
characters; and
 
[then either a jump to UTF8 or an optional layover in BMPString, depending on
 how people feel about this]
 
Rationale:
 
Pretty much every implementation and OS in existence supports latin-1 natively. 
This is compatible with (I would hope) all existing implementations - the only,
very minor change this makes is that it constrains T61String to contain only
latin-1 characters rather than the full menagerie of T.61 characters (which I
doubt anyone ever used anyway).
 
Since few implementations currently use, or possibly even support,
BMPString, it may be possible to avoid this in favour of UTF8, although it'd be
better to leave it in for compatibility.  But I think going straight to UTF8 is
a definite mistake.
 
Peter.

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: new profile submitted
Reply-To: [email-masked]
Date: Thu, 18 Jun 1998 20:18:39 (NZST)
Sender: [email-masked]

(I can't really submit concrete text for this, unless you'd like me to send in
 a dump of a certificate which really is a CA cert).
 
>#2 If you want something changed, please submit your suggestions to the list
>WITH TEXT.  We want to forward this to the IESG as soon as possible. That will
>not be possible if we discuss abstract changes on the list. Concrete text is a
>MUST.
 
The NIST certificate in the examples is *still* broken: It doesn't mark
basicConstraints as critical, and is marked as a non-CA certificate while the
text claims it's a CA certificate.
 
Peter.

Date: Thu, 18 Jun 1998 09:45:56 +0200
To: Mike Smith <[email-masked]>, [email-masked], [email-masked]
From: Stefan Santesson <[email-masked]>
Subject: Re: RE: proof-of-possession for DH keys
Cc: [email-masked]
Sender: [email-masked]

Thanks Mike for putting this debate into the right perspective.

At 11.01 1998-06-16 -0600, Mike Smith wrote:
>These operational procedure capabilities must be supported by the technical 
>requirements at a minimum, but not the requirement to conduct such
operational 
>testing itself.  POP and all other operational requirements or best
practices 
>should be in the policies and concept of operations efforts and so should 
>the debate.

Is this debate really about protocols or policies ?

When defining a protocol for certificate request it would be wise to include 
mechanisms for POP.

But the decision to mandate POP for a specific set of certificates can only
be made by
the CA and should then reflect the identified certificate policy where this
requirement
should be specified.

Personally, I find that many technical issues discussed in this list really
are policy 
issues and policy issues are virtually impossible to discuss without first
defining the
type of community and set of applications (with common security
requirements)in which the
policy is to be used. 

/Stefan Santesson

----------------------------------------------------------------
Stefan Santesson                <[email-masked]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. +46-40 152211              
216 42  Malmö                   Fax. +46-40 150790              
Sweden                        Mobile +46-70 5247799
----------------------------------------------------------------

To: [email-masked]
Subject: On line document for X509v3 extention ?
Date: Thu, 18 Jun 1998 14:16:59 +0900
From: Ryu Inada <[email-masked]>
Lines: 11
Sender: [email-masked]

Dear PKIX wizards.

I'm new in the list sorry for out of date and faq
questions.
I'm seeking for X.509v3 extentiond ocument for create CA's code.

Please point me out, where I can get.

Thanks in advance.

Ryu Inada <[email-masked]>

Date: Wed, 17 Jun 1998 20:39:42 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Re: RE: Certificate Revocation
Sender: [email-masked]

Yup.  Things like that happen, but only to other people, right?

But at least you can listen to the Eagles, or play a game, or do 
whatever else WAS on the diskette that you brought!

Option two, per Dilbert, is to use the CD drawer in your computer as a 
handy-dandy coffee cup holder. That will solve several other 
problems as well.

Bob

>>> Warwick Ford <[email-masked]> 06/17 9:49 PM >>>
Bob:

How about Uncle Bob, who helped shape the youngster in its early toddler
days?  (I'll bet you guys are real pleased that people are now considering
offering it its first job.)

An example of a state maintenance problem here would be getting your laptop
out on the plane and realizing that, while you had been astute enough to
pick up the latest diskette, you had brought the wrong CD for that diskette.

Warwick

At 05:19 PM 6/17/98 -0600, Bob Jueneman wrote:
>Warwick,
>
>Re fathers, mothers, aunts and uncles, etc., for certificate revocation,
>you may recall that I suggested essentially the delta CRL concept
>in terms of a CRL-CD-of-the-month club, where a CD containing
>the base information would be supplemented with a floppy disk
>of containing the day's or week's latest updates.
>
>What I was talking about then is still a problem -- how do you authenticate
>either the addressee of an encrypted e-mail, or the originator of a 
>digital signature, when you are sitting in an airplane at 30,000 feet
>and don't have connectivity to a network?
>
>OFCSP and lots of other protocols, including insurance and/or notarization
>protocols may be absolutely needed, or at least highly useful in an 
>environment where everyone is on-line, but that isn't always the case.
>
>I don't want to have to download the entire CRL database in order to get the
>5% that might have changed most recently -- hence, delta CRLs.
>
>Bob
>
>
>>>> Warwick Ford <[email-masked]> 06/16 9:07 PM >>>
>Hi, Carlisle:
>
>At 11:25 AM 6/15/98 -0400, Carlisle Adams wrote:
>>Hi Warwick,
>>
>>> ----------
>>> From: 	Warwick Ford[SMTP:[email-masked]] 
>>> Sent: 	Saturday, June 13, 1998 5:27 PM
>>> To: 	Robert Zuccherato; [email-masked]; 'Jessica Hymowitz'
>>> Subject: 	RE: Certificate Revocation
>>> 
>>> I read with interest Robert and Carlisle's "White Paper".  It provides
>>> some
>>> helpful discussion of the indirection mechanism ("CRL List" mechanism)
>>> developed in OCDP, and contains some interesting refinement ideas.  
>>> 
>>> The thought of using delta CRLs in conjubction with the CRL List mechanism
>>> is interesting, although I suspect client implementors will not embrace
>>> that, given the implementation complexities.  Back in the X.509 v3 design
>>> days, Hoyt and I spent hours discussing the pros and cons of delta CRLs
>>> and
>>> we concluded that they may well be an attractive option for large servers
>>> (for performance reasons) but not appropriate for clients (because of
>>> state
>>> maintenance problems).  I tend to think that same analysis will apply to
>>> using delta CRLs with CRL Lists.
>>> 
>>Perhaps you could give some more detail regarding the "hours of discussion"
>>you and Hoyt had on delta CRLs (feel free to copy him on the response, if
>>you like, so he can join in if he wishes), because I don't understand your
>>summary above at all.  Why would deltas have any more "state maintenance"
>>than CRLs themselves?  Few people have built or will build a client that
>>pulls down an entire CRL every time it wants to check revocation; rather, it
>>typically pulls down a CRL once per period and caches it until its
>>nextUpdate date.  Deltas don't in any way add to this state maintenance.
>>All they do is allow a relying party to get fresher information (if they
>>want it) between CRL updates.
>
>Yes, I would welcome Hoyt's views (I consider Hoyt to be the father of
>delta CRLs).  The volume of discussion was largely because the two concepts
>of delta CRLs and CRL partitions were themselves being designed at the time
>and we were trying to be sure we understood the rationale for having both
>mechanisms.  I won't try to go through all the paths here, but rather shall
>try to spell out the bottom line.  The complicating factor with deltas is
>that someone checking revocation is no longer able to process a single data
>item to be certain that the cert is not revoked.  Rather he/she/it needs to
>obtain, validate, and scan at least two separate data items (the delta and
>the base CRL), and maybe more depending on your delta regime.  Deltas are
>inherently state-oriented, in that it only makes sense to deploy them in an
>environment in which you have a general expectation that, when you fetch
>the delta CRL, you already hold, from some prior activity, the base CRL or
>contents thereof.  This is likely true in a busy server but more
>questionable in a small client system which does only very sporadic
>revocation checks with any given CA.  The reason for using deltas is to
>keep down the size of items retrieved.  An alternative means of keeping
>down size is partitioning, and if partitioning if done sufficiently
>intelligently (note that, with Scopes, we now have some interesting new
>options for intelligent partitioning), the use of deltas may not be
>warranted, especially in small clients.  That said, let me make clear that
>I am not opposed to deltas -- I have always supported having them as an
>option, and I think your proposal for using them in CRL lists is a good
>idea -- as an option.  
>
>>> One deficiency in Robert and Carlisle's analysis is their lack of
>>> recognition of one of the most important underlying concepts of OCDP.  If
>>> unsigned pointers indeed have denial of service implications, the solution
>>> offered by Robert and Carlisle, that is to have the CA sign the pointer,
>>> is
>>> just not the general answer.  The point is that, in many spheres of
>>> application of certificates, the issue of revocation or status checking is
>>> considered a relying-party-domain-control issue -- not a
>>> certificate-issuer-domain-control issue.  In other words, the relying
>>> party's enterprise will decide where, and under what policy conditions,
>>> its
>>> relying parties will go to check certificate status.  This could very well
>>> be a local server or directory -- not back at the CA.
>>> 
>>> Financial industry applications, for example, generally reflect this model
>>> (for good business reasons).  For example, with credit cards, the merchant
>>> goes to its acquirer for a card authorization -- not directly to the
>>> issuer.  The credit card equivalent of a CDP would be for the issuer to
>>> include its contact details (for card authorization purposes) on the card
>>> -- this is not the practice. 
>>> 
>>> For this reason (among others) we saw it important to move away from the
>>> model in which the revocation mechanism is rigidly tied to an embedded
>>> revocation pointer in the certificate itself.  I feel that any work to
>>> further develop the OCDP ideas should definitely preserve this aspect of
>>> the OCDP model.
>>> 
>>You claim above that we have not recognized one of the most important
>>underlying concepts of OCDP.  On the contrary, I suggest that you seem not
>>to have recognized *the* most important underlying concept of CDP:  it is
>>OPTIONAL (and when it is used, it is NON-CRITICAL).  Thus, there is no
>>standard anywhere in which "the revocation mechanism is rigidly tied to an
>>embedded revocation pointer in the certificate itself".  CAs can put
>>distribution points in certificates, or not.  If they happen to do so,
>>relying parties can go to the location pointed to for revocation
>>information, or can go somewhere else of their own choosing (note that since
>>the extension is non-critical, a relying party may not have software that
>>understands the extension while still being perfectly conformant with X.509
>>and PKIX).
>
>You need to clarify something in your paper.  In your early material you
>appeared to dismiss OCDP with the comment "The use of unsigned pointers,
>however, leaves the proposal open to denial-of-service attacks."  While I
>don't understand or subscribe to that comment, I read into it that you were
>similarly dismissing all mechanisms that did not use CDPs.  I welcome the
>new assurance that that is not the case, and suggest you clarify that you
>recognize the need for non-CDP mechanisms (such as OCDP) as well as the CDP
>mechanism, dependent on needs.
>
>Warwick 
>
>
>
>---------------------------------------------------------------------
>Warwick Ford, VeriSign, Inc., Tel (781)2456996 x225; Fax (781)2456006
>[email-masked];  301 Edgewater Pl, Suite 210, Wakefield, MA 01880
>---------------------------------------------------------------------
> 
>
>

---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., Tel (781)2456996 x225; Fax (781)2456006
[email-masked];  301 Edgewater Pl, Suite 210, Wakefield, MA 01880
---------------------------------------------------------------------

Date: Wed, 17 Jun 1998 20:49:07 -0700
To: "Bob Jueneman" <[email-masked]>, [email-masked], [email-masked]
From: Warwick Ford <[email-masked]>
Subject: Re: RE: Certificate Revocation
Sender: [email-masked]

Bob:

How about Uncle Bob, who helped shape the youngster in its early toddler
days?  (I'll bet you guys are real pleased that people are now considering
offering it its first job.)

An example of a state maintenance problem here would be getting your laptop
out on the plane and realizing that, while you had been astute enough to
pick up the latest diskette, you had brought the wrong CD for that diskette.

Warwick

At 05:19 PM 6/17/98 -0600, Bob Jueneman wrote:
>Warwick,
>
>Re fathers, mothers, aunts and uncles, etc., for certificate revocation,
>you may recall that I suggested essentially the delta CRL concept
>in terms of a CRL-CD-of-the-month club, where a CD containing
>the base information would be supplemented with a floppy disk
>of containing the day's or week's latest updates.
>
>What I was talking about then is still a problem -- how do you authenticate
>either the addressee of an encrypted e-mail, or the originator of a 
>digital signature, when you are sitting in an airplane at 30,000 feet
>and don't have connectivity to a network?
>
>OFCSP and lots of other protocols, including insurance and/or notarization
>protocols may be absolutely needed, or at least highly useful in an 
>environment where everyone is on-line, but that isn't always the case.
>
>I don't want to have to download the entire CRL database in order to get the
>5% that might have changed most recently -- hence, delta CRLs.
>
>Bob
>
>
>>>> Warwick Ford <[email-masked]> 06/16 9:07 PM >>>
>Hi, Carlisle:
>
>At 11:25 AM 6/15/98 -0400, Carlisle Adams wrote:
>>Hi Warwick,
>>
>>> ----------
>>> From: 	Warwick Ford[SMTP:[email-masked]] 
>>> Sent: 	Saturday, June 13, 1998 5:27 PM
>>> To: 	Robert Zuccherato; [email-masked]; 'Jessica Hymowitz'
>>> Subject: 	RE: Certificate Revocation
>>> 
>>> I read with interest Robert and Carlisle's "White Paper".  It provides
>>> some
>>> helpful discussion of the indirection mechanism ("CRL List" mechanism)
>>> developed in OCDP, and contains some interesting refinement ideas.  
>>> 
>>> The thought of using delta CRLs in conjubction with the CRL List mechanism
>>> is interesting, although I suspect client implementors will not embrace
>>> that, given the implementation complexities.  Back in the X.509 v3 design
>>> days, Hoyt and I spent hours discussing the pros and cons of delta CRLs
>>> and
>>> we concluded that they may well be an attractive option for large servers
>>> (for performance reasons) but not appropriate for clients (because of
>>> state
>>> maintenance problems).  I tend to think that same analysis will apply to
>>> using delta CRLs with CRL Lists.
>>> 
>>Perhaps you could give some more detail regarding the "hours of discussion"
>>you and Hoyt had on delta CRLs (feel free to copy him on the response, if
>>you like, so he can join in if he wishes), because I don't understand your
>>summary above at all.  Why would deltas have any more "state maintenance"
>>than CRLs themselves?  Few people have built or will build a client that
>>pulls down an entire CRL every time it wants to check revocation; rather, it
>>typically pulls down a CRL once per period and caches it until its
>>nextUpdate date.  Deltas don't in any way add to this state maintenance.
>>All they do is allow a relying party to get fresher information (if they
>>want it) between CRL updates.
>
>Yes, I would welcome Hoyt's views (I consider Hoyt to be the father of
>delta CRLs).  The volume of discussion was largely because the two concepts
>of delta CRLs and CRL partitions were themselves being designed at the time
>and we were trying to be sure we understood the rationale for having both
>mechanisms.  I won't try to go through all the paths here, but rather shall
>try to spell out the bottom line.  The complicating factor with deltas is
>that someone checking revocation is no longer able to process a single data
>item to be certain that the cert is not revoked.  Rather he/she/it needs to
>obtain, validate, and scan at least two separate data items (the delta and
>the base CRL), and maybe more depending on your delta regime.  Deltas are
>inherently state-oriented, in that it only makes sense to deploy them in an
>environment in which you have a general expectation that, when you fetch
>the delta CRL, you already hold, from some prior activity, the base CRL or
>contents thereof.  This is likely true in a busy server but more
>questionable in a small client system which does only very sporadic
>revocation checks with any given CA.  The reason for using deltas is to
>keep down the size of items retrieved.  An alternative means of keeping
>down size is partitioning, and if partitioning if done sufficiently
>intelligently (note that, with Scopes, we now have some interesting new
>options for intelligent partitioning), the use of deltas may not be
>warranted, especially in small clients.  That said, let me make clear that
>I am not opposed to deltas -- I have always supported having them as an
>option, and I think your proposal for using them in CRL lists is a good
>idea -- as an option.  
>
>>> One deficiency in Robert and Carlisle's analysis is their lack of
>>> recognition of one of the most important underlying concepts of OCDP.  If
>>> unsigned pointers indeed have denial of service implications, the solution
>>> offered by Robert and Carlisle, that is to have the CA sign the pointer,
>>> is
>>> just not the general answer.  The point is that, in many spheres of
>>> application of certificates, the issue of revocation or status checking is
>>> considered a relying-party-domain-control issue -- not a
>>> certificate-issuer-domain-control issue.  In other words, the relying
>>> party's enterprise will decide where, and under what policy conditions,
>>> its
>>> relying parties will go to check certificate status.  This could very well
>>> be a local server or directory -- not back at the CA.
>>> 
>>> Financial industry applications, for example, generally reflect this model
>>> (for good business reasons).  For example, with credit cards, the merchant
>>> goes to its acquirer for a card authorization -- not directly to the
>>> issuer.  The credit card equivalent of a CDP would be for the issuer to
>>> include its contact details (for card authorization purposes) on the card
>>> -- this is not the practice. 
>>> 
>>> For this reason (among others) we saw it important to move away from the
>>> model in which the revocation mechanism is rigidly tied to an embedded
>>> revocation pointer in the certificate itself.  I feel that any work to
>>> further develop the OCDP ideas should definitely preserve this aspect of
>>> the OCDP model.
>>> 
>>You claim above that we have not recognized one of the most important
>>underlying concepts of OCDP.  On the contrary, I suggest that you seem not
>>to have recognized *the* most important underlying concept of CDP:  it is
>>OPTIONAL (and when it is used, it is NON-CRITICAL).  Thus, there is no
>>standard anywhere in which "the revocation mechanism is rigidly tied to an
>>embedded revocation pointer in the certificate itself".  CAs can put
>>distribution points in certificates, or not.  If they happen to do so,
>>relying parties can go to the location pointed to for revocation
>>information, or can go somewhere else of their own choosing (note that since
>>the extension is non-critical, a relying party may not have software that
>>understands the extension while still being perfectly conformant with X.509
>>and PKIX).
>
>You need to clarify something in your paper.  In your early material you
>appeared to dismiss OCDP with the comment "The use of unsigned pointers,
>however, leaves the proposal open to denial-of-service attacks."  While I
>don't understand or subscribe to that comment, I read into it that you were
>similarly dismissing all mechanisms that did not use CDPs.  I welcome the
>new assurance that that is not the case, and suggest you clarify that you
>recognize the need for non-CDP mechanisms (such as OCDP) as well as the CDP
>mechanism, dependent on needs.
>
>Warwick 
>
>
>
>---------------------------------------------------------------------
>Warwick Ford, VeriSign, Inc., Tel (781)2456996 x225; Fax (781)2456006
>[email-masked];  301 Edgewater Pl, Suite 210, Wakefield, MA 01880
>---------------------------------------------------------------------
> 
>
>

---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., Tel (781)2456996 x225; Fax (781)2456006
[email-masked];  301 Edgewater Pl, Suite 210, Wakefield, MA 01880
---------------------------------------------------------------------

Date: Wed, 17 Jun 1998 17:19:58 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: RE: Certificate Revocation
Sender: [email-masked]

Warwick,

Re fathers, mothers, aunts and uncles, etc., for certificate revocation,
you may recall that I suggested essentially the delta CRL concept
in terms of a CRL-CD-of-the-month club, where a CD containing
the base information would be supplemented with a floppy disk
of containing the day's or week's latest updates.

What I was talking about then is still a problem -- how do you authenticate
either the addressee of an encrypted e-mail, or the originator of a 
digital signature, when you are sitting in an airplane at 30,000 feet
and don't have connectivity to a network?

OFCSP and lots of other protocols, including insurance and/or notarization
protocols may be absolutely needed, or at least highly useful in an 
environment where everyone is on-line, but that isn't always the case.

I don't want to have to download the entire CRL database in order to get the
5% that might have changed most recently -- hence, delta CRLs.

Bob

>>> Warwick Ford <[email-masked]> 06/16 9:07 PM >>>
Hi, Carlisle:

At 11:25 AM 6/15/98 -0400, Carlisle Adams wrote:
>Hi Warwick,
>
>> ----------
>> From: 	Warwick Ford[SMTP:[email-masked]] 
>> Sent: 	Saturday, June 13, 1998 5:27 PM
>> To: 	Robert Zuccherato; [email-masked]; 'Jessica Hymowitz'
>> Subject: 	RE: Certificate Revocation
>> 
>> I read with interest Robert and Carlisle's "White Paper".  It provides
>> some
>> helpful discussion of the indirection mechanism ("CRL List" mechanism)
>> developed in OCDP, and contains some interesting refinement ideas.  
>> 
>> The thought of using delta CRLs in conjubction with the CRL List mechanism
>> is interesting, although I suspect client implementors will not embrace
>> that, given the implementation complexities.  Back in the X.509 v3 design
>> days, Hoyt and I spent hours discussing the pros and cons of delta CRLs
>> and
>> we concluded that they may well be an attractive option for large servers
>> (for performance reasons) but not appropriate for clients (because of
>> state
>> maintenance problems).  I tend to think that same analysis will apply to
>> using delta CRLs with CRL Lists.
>> 
>Perhaps you could give some more detail regarding the "hours of discussion"
>you and Hoyt had on delta CRLs (feel free to copy him on the response, if
>you like, so he can join in if he wishes), because I don't understand your
>summary above at all.  Why would deltas have any more "state maintenance"
>than CRLs themselves?  Few people have built or will build a client that
>pulls down an entire CRL every time it wants to check revocation; rather, it
>typically pulls down a CRL once per period and caches it until its
>nextUpdate date.  Deltas don't in any way add to this state maintenance.
>All they do is allow a relying party to get fresher information (if they
>want it) between CRL updates.

Yes, I would welcome Hoyt's views (I consider Hoyt to be the father of
delta CRLs).  The volume of discussion was largely because the two concepts
of delta CRLs and CRL partitions were themselves being designed at the time
and we were trying to be sure we understood the rationale for having both
mechanisms.  I won't try to go through all the paths here, but rather shall
try to spell out the bottom line.  The complicating factor with deltas is
that someone checking revocation is no longer able to process a single data
item to be certain that the cert is not revoked.  Rather he/she/it needs to
obtain, validate, and scan at least two separate data items (the delta and
the base CRL), and maybe more depending on your delta regime.  Deltas are
inherently state-oriented, in that it only makes sense to deploy them in an
environment in which you have a general expectation that, when you fetch
the delta CRL, you already hold, from some prior activity, the base CRL or
contents thereof.  This is likely true in a busy server but more
questionable in a small client system which does only very sporadic
revocation checks with any given CA.  The reason for using deltas is to
keep down the size of items retrieved.  An alternative means of keeping
down size is partitioning, and if partitioning if done sufficiently
intelligently (note that, with Scopes, we now have some interesting new
options for intelligent partitioning), the use of deltas may not be
warranted, especially in small clients.  That said, let me make clear that
I am not opposed to deltas -- I have always supported having them as an
option, and I think your proposal for using them in CRL lists is a good
idea -- as an option.  

>> One deficiency in Robert and Carlisle's analysis is their lack of
>> recognition of one of the most important underlying concepts of OCDP.  If
>> unsigned pointers indeed have denial of service implications, the solution
>> offered by Robert and Carlisle, that is to have the CA sign the pointer,
>> is
>> just not the general answer.  The point is that, in many spheres of
>> application of certificates, the issue of revocation or status checking is
>> considered a relying-party-domain-control issue -- not a
>> certificate-issuer-domain-control issue.  In other words, the relying
>> party's enterprise will decide where, and under what policy conditions,
>> its
>> relying parties will go to check certificate status.  This could very well
>> be a local server or directory -- not back at the CA.
>> 
>> Financial industry applications, for example, generally reflect this model
>> (for good business reasons).  For example, with credit cards, the merchant
>> goes to its acquirer for a card authorization -- not directly to the
>> issuer.  The credit card equivalent of a CDP would be for the issuer to
>> include its contact details (for card authorization purposes) on the card
>> -- this is not the practice. 
>> 
>> For this reason (among others) we saw it important to move away from the
>> model in which the revocation mechanism is rigidly tied to an embedded
>> revocation pointer in the certificate itself.  I feel that any work to
>> further develop the OCDP ideas should definitely preserve this aspect of
>> the OCDP model.
>> 
>You claim above that we have not recognized one of the most important
>underlying concepts of OCDP.  On the contrary, I suggest that you seem not
>to have recognized *the* most important underlying concept of CDP:  it is
>OPTIONAL (and when it is used, it is NON-CRITICAL).  Thus, there is no
>standard anywhere in which "the revocation mechanism is rigidly tied to an
>embedded revocation pointer in the certificate itself".  CAs can put
>distribution points in certificates, or not.  If they happen to do so,
>relying parties can go to the location pointed to for revocation
>information, or can go somewhere else of their own choosing (note that since
>the extension is non-critical, a relying party may not have software that
>understands the extension while still being perfectly conformant with X.509
>and PKIX).

You need to clarify something in your paper.  In your early material you
appeared to dismiss OCDP with the comment "The use of unsigned pointers,
however, leaves the proposal open to denial-of-service attacks."  While I
don't understand or subscribe to that comment, I read into it that you were
similarly dismissing all mechanisms that did not use CDPs.  I welcome the
new assurance that that is not the case, and suggest you clarify that you
recognize the need for non-CDP mechanisms (such as OCDP) as well as the CDP
mechanism, dependent on needs.

Warwick 

---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., Tel (781)2456996 x225; Fax (781)2456006
[email-masked];  301 Edgewater Pl, Suite 210, Wakefield, MA 01880
---------------------------------------------------------------------

From: Robert Zuccherato <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "'Frank Acker'" <[email-masked]>
Subject: RE: Time Stamp and "Notary" Drafts
Date: Wed, 17 Jun 1998 16:41:02 -0400
Sender: [email-masked]

Frank;

Thank you for your interest in our work.  I don't think that the changes you
suggested are needed however, and may introduce a flaw in the protocol.  Let
me explain.  You write:

> ----------
> From: 	Frank Acker[SMTP:[email-masked]]
> Sent: 	Wednesday, June 17, 1998 2:32 PM
> To: 	Robert Zuccherato; [email-masked]'
> Subject: 	Re: Time Stamp and "Notary" Drafts
> 
> In section 5 of "Data Certification Server Protocols", the data to be
> certified is defined as follows:
> 
> "The Data type is defined to be either the message itself, a hash of 
> the message (this allows a signature indicating possession of private 
> data to be certified) or the certificate to be verified.  
> 
> Data ::= CHOICE  {
>      message                [0]  Message,
>      messageimprint         [1]  MessageImprint,
>      certs                  [2]  SEQUENCE SIZE (1..MAX) OF "
> 
> Ignoring the 'certs' type for the sake of this discussion, the type of
> data
> can be *either* a message *or* a messageImprint (a hash of the message).
> One or the other.  But not both.
> 
> I suggest that the choice should be a (required) messageImprint *and*
> (optionally) the message (from which the hash was computed). 
> 
> Furthermore, I suggest that the message (if present) be unsigned.  Since
> the messageImprint is signed, it is not necessary to include (and
> redundantly hash) the message in the signature.
> 
So, if I understand you correctly, the hash of the message would be included
in the signed part, and the message would be sent unsigned.  Is this
correct?

> The reason I make these suggestions is two-fold: DCS server performance
> improvement and bandwidth reduction.
> 
> If a DCS client includes the message in the request, the message must be
> hashed by the client with either approach, so there is no gain on the
> client side. 
> 
Agreed.

> However, by including the hash of the message in the request
> (and not signing the message component), the DCS server has less work to
> do
> to verify the signature on the request (i.e. it does not have to hash the
> message).  
> 
Here is where I have a problem.  If the server does not hash the unsigned
message, and just verifies the signature on the message imprint, an attacker
could replace the unsigned message with anything.  Assume we are in the
situation where the message has data type id-signedData and the server is
verifying the signature in that message.  That message could be replaced
with anything and the server would never know because it never hashed the
message to compare it with the message imprint in the signed part of the
request.  Thus, the server must always hash everything and therefore has no
less work to do.

> The only extra overhead here is small amount of memory for the
> hash of the message.
> 
> Now, since both the message and the messageImprint have been sent to the
> DCS server, both the client and the server have a copy of that message.
> 
Under your proposal, they might not if the message wasn't hashed and
compared with that in the signature.

> Since the server is not signing the message component, I suggest that the
> message be removed from the DCSReqInfo that is encapsulated in the
> DCSInfo.
> This would reduce the bandwidth requirements because the token returned to
> the client would not contain the (optional) message...only the (required)
> hash of it.
> 
Actually, if you look at page 5 of the draft, DCSReqInfo does not contain
the message.  The message is bound to the token in DCSInfo by including its
message imprint.  Thus, the draft already does what you ask for here.

	Robert.

Date: Wed, 17 Jun 1998 11:32:54 -0700
To: Robert Zuccherato <[email-masked]>, "[email-masked]'" <[email-masked]>
From: Frank Acker <[email-masked]>
Subject: Re: Time Stamp and "Notary" Drafts
Sender: [email-masked]

Robert:

Thank you for your work in defining the Data Certification Server
Protocols.  I have a couple of suggestions that might improve the
robustness of the protocol.

In section 5 of "Data Certification Server Protocols", the data to be
certified is defined as follows:

"The Data type is defined to be either the message itself, a hash of 
the message (this allows a signature indicating possession of private 
data to be certified) or the certificate to be verified.  

Data ::= CHOICE  {
     message                [0]  Message,
     messageimprint         [1]  MessageImprint,
     certs                  [2]  SEQUENCE SIZE (1..MAX) OF "

Ignoring the 'certs' type for the sake of this discussion, the type of data
can be *either* a message *or* a messageImprint (a hash of the message).
One or the other.  But not both.

I suggest that the choice should be a (required) messageImprint *and*
(optionally) the message (from which the hash was computed). 

Furthermore, I suggest that the message (if present) be unsigned.  Since
the messageImprint is signed, it is not necessary to include (and
redundantly hash) the message in the signature.

The reason I make these suggestions is two-fold: DCS server performance
improvement and bandwidth reduction.

If a DCS client includes the message in the request, the message must be
hashed by the client with either approach, so there is no gain on the
client side. However, by including the hash of the message in the request
(and not signing the message component), the DCS server has less work to do
to verify the signature on the request (i.e. it does not have to hash the
message).  The only extra overhead here is small amount of memory for the
hash of the message.

Now, since both the message and the messageImprint have been sent to the
DCS server, both the client and the server have a copy of that message.
Since the server is not signing the message component, I suggest that the
message be removed from the DCSReqInfo that is encapsulated in the DCSInfo.
This would reduce the bandwidth requirements because the token returned to
the client would not contain the (optional) message...only the (required)
hash of it.

The benefits are increased DCS server performance and reduced network
traffic, particularly for large messages.

Regards,

Frank

------------------------------------------------------
Frank Acker	                 [email-masked]
Senior Member Technical Staff
Coastek, Inc.                  www.coastek.com
5550 Scotts Valley Drive       408-440-0180 X408
Scotts Valley, CA  95066

Date: Wed, 17 Jun 1998 13:50:06 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: proof-of-possession for DH keys
Sender: [email-masked]

> From: Denis Pinkas <[email-masked]>
> 
> [Tony writes]
> 
> Is the "key" issue here (sorry about that) that by requiring POP for
> encypherment/agreement key certification, one gets authentication "for
> free" when message encryption is employed?  Otherwise, a protocol would
> require that the encrypted data be, in addition, signed?
> 
> [Denis writes]
> 
> Yes, Tony, this is the key point.  :-) 
> 
> More precisely, the key usage bits shall/should indicate what kind of
> SERVICE can be handled with the key, instead of the kind of MECHANISM
> that may be supported with the key. We already tackled the issue when
> taken about non repudiation (which is a service and not a mechanism). We
> have another case here.
> 
> Now let me try to answer the question from Nada, and let us restrict the
> discusssion for the next two lines to keys only able to encrypt/decrypt.
> 
> If the key is used to support a confidentiality service, then POP is NOT
> required.
> If the key is used to support an authentication service, then POP is
> required.

Which leads to:

  If the key is not used to support an authentication service, then
  neither POP nor a certificate is required.

The first case above is incorrect, since KEA keys are used to support
both confidentiality and authentication.  D-H keys may be used in both
authenticating and ephemeral protocols.

I agree with Carlisle that if the PKI is being invoked to certify a
keypair, then POP is required.  And I agree with Adam that a PKI cannot
prevent "auto-DoS" :-).  The way forward is for the PKI specification
to remain as it is, with POP required for every certified keypair.
If POP does not make sense for a particular application, then the
way to not use it is to not invoke the PKI (request or rely upon
a certificate) in the first place.

Date: Wed, 17 Jun 1998 10:50:24 -0700
To: <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject: RE: PKIX-1 - use of UTF8
Sender: [email-masked]

I'll add a "me too" to Phill and John. We have a stable UTF-8 definition in
the IETF (RFC 2279), and it is the recommended charset in the BCP document
on i18n (RFC 2277). There's no need to emit BMPString in PKIX.

--Paul Hoffman, Director
--Internet Mail Consortium

From: "Phillip M Hallam-Baker" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: PKIX-1 - use of UTF8
Date: Wed, 17 Jun 1998 12:33:54 -0400
Importance: Normal
Sender: [email-masked]

> Rationale:
> 
> As discussed on the list, the current text means that BMPString will be
> used for all names that don't fit into the restricted printableString
> character-set; UTF8 will never be used.  UTF8 is a much more
> implementor-friendly code-set than BMPString, and is the IETF's 
> recommended
> international codeset, and we should use it in preference to BMPString.

I think John's point is entirely right. UTF8 is the standard folk
are building their O/S arround. We should use it.

		Phill

From: Carlisle Adams <[email-masked]>
To: "'Adam Back'" <[email-masked]>
Cc: [email-masked]
Subject: RE: proof-of-possession for DH keys
Date: Wed, 17 Jun 1998 12:27:42 -0400
Sender: [email-masked]

Hi Adam,

> ----------
> From: 	Adam Back[SMTP:[email-masked]]
> Sent: 	Tuesday, June 16, 1998 8:31 PM
> To: 	[email-masked]
> Cc: 	[email-masked]; [email-masked]
> Subject: 	Re: proof-of-possession for DH keys
> 
> 
> Carlisle writes:
> > > You assume that I am holding the corresponding private decryption key.
> > > If I don't, I am unable to decrypt. That case might happen if, when
> > > performing my certification request, I provided garbage data instead
> of
> > > a real public key or if I *willingly* gave the value of the public key
> > > from someone else. 
> > > 
> > 
> > This is the whole purpose of doing POP: precisely to prevent such
> > pointless actions on the part of the requester.
> 
> Preventing against the "pointless action" attack is kind of hard --
> normally parties are expected to be acting in their own interests.
> 
> You are proposing that we instead consider that parties are trying to
> act in as obtuse a manner as they are able, by creating random public
> keys (which will result in their receiving messages which they will
> not be able to decrypt).  
> 
> You would then be proposing that our task is to detect and prevent
> this behaviour within the protocol.  It seems that the particular
> pointless action attack you are interested to prevent is self
> inflicted DoS.
> 
We are in agreement that you can't really stop people from doing dumb (or at
least pointless) things if they really want to.  However, if you can avoid
having a CA authoritatively put its stamp of approval on this "pointless
thing", thereby causing people to trust it, it seems to me that this is
worth doing.  I honestly can't understand why you would argue otherwise.

> Earlier I gave an example of how Mary (the Masochist, our self
> destructive party) can still perform a self inflicted DoS attack even
> in the presence of POPs which claim to defend against this: (1) delete
> her private key immediately after creating the POP.
> 
> Another attack Mary might perform (2) is to post her private key to
> USENET, destroying your expectation of privacy in using her public
> key.
> 
> Or Mary might (3) post the plaintext all of your encrypted emails sent
> to her to USENET more immediately destroying your expectation of
> privacy.
> 
Presumably Mary might do all sorts of other things as well, but that's
hardly the point.  The point is that when the CA creates the certificate, it
authoritatively asserts a binding between the entity and a key pair (having
done its due diligence to ensure that the binding is valid).  Any future
action, subsequent to the creation of the certificate, may break the
validity of that binding (e.g., any of Mary's actions above, or legitimate
key compromise, etc.)  --  that's what revocation is for.  But if we allow
the situation in which even the initial binding asserted by the CA cannot be
trusted, then certificates are meaningless and there is, in effect, no
useful PKI.  Is this really what we want PKIX to define?

> You can actually do things to reduce the risk of and/or increase the
> costs to Mary of performing all of these attacks, the question really
> though is does the utility gained justify the added complexity.
> 
In PKIX-CMP, the "added complexity" is one encryption of a small quantity on
the CA side and one decryption of that quantity on the client side; there
need not even be any extra messages in the exchange.  [CMP also allows the
case in which POP is done by some out-of-band means (i.e., outside the
protocol).]  This seems pretty insignificant considering that it can help
make the difference between useful and useless certificates.

--------------------------------------------
Carlisle Adams
Entrust Technologies
[email-masked]
--------------------------------------------

From: [email-masked]
To: [email-masked], [email-masked]
Date: Wed, 17 Jun 1998 09:49:30 -0400
Subject: PKIX-1 - use of UTF8
Sender: [email-masked]

As requested, here is a change request with suggested text, against the
latest PKIX-1 draft.

Top of page 20.  Current text:

    (a) if the character set is sufficient, the string will be represented
as a PrintableString;

    (b) failing (a), if the BMPString character set is sufficient the
string shall be represented as a BMPString; and

    (c) failing (a) and (b), the string shall be represented as a
UTF8String.

Replacement text:

    (a) if the character set is sufficient, the string will be represented
as a PrintableString;

    (b) failing (a), the string shall be represented as a UTF8String.

Rationale:

As discussed on the list, the current text means that BMPString will be
used for all names that don't fit into the restricted printableString
character-set; UTF8 will never be used.  UTF8 is a much more
implementor-friendly code-set than BMPString, and is the IETF's recommended
international codeset, and we should use it in preference to BMPString.

John

From: Nilsson Hans <[email-masked]>
To: "'Tim Polk'" <[email-masked]>, [email-masked]
Subject: SV: new profile submitted
Date: Wed, 17 Jun 1998 13:47:46 +0100
Sender: [email-masked]

Tim,
Can you please explain the background for the new writing regarding
subjectKeyIdentifier, using 0100 + 60 bits from the SHA-1 hash of the BIT
STRING subjectPublicKey? Is this in conformance with something else, or a
new invention?

Thanks

Hans Nilsson

Date: Wed, 17 Jun 1998 17:57:01 +1000
From: Michael Warner <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: proof-of-possession for DH keys
Cc: [email-masked]
Sender: [email-masked]

Carlisle Adams wrote:
> 
> Thank you, Denis.  I couldn't possibly have put the argument more succinctly
> than that!  You clearly agree that without POP I have no reason to use the
> public key in the certificate to encrypt for you.  Therefore, your
> encryption certificate is of no value whatsoever to me.

This is just not true... the certification authority has verified my
identity and I have given it the public key with which I want messages
for me to be encrypted.   So if anyone wants to encrypt message for
me they should use that key.   How I process the messages when they 
get to me is my business.

> 
> Why in the world would PKIX define protocols that allow such worthless
> certificates to be created?  PKIX is trying to create a usable PKI.  The PKI
> is not "usable" if I can't know which certificates I can use and which ones
> I can't.

Every protocol in the world allows useless activity to occur using it.   If 
you try to design protocols to prevent it, you invariably make them more 
complex than they need to be, and also prevent some useful activity 
that you haven't considered.   

The whole argument for mandating POP seems to be to allow broken 
security protocols to work in some specific imagined application.
I still haven't seen a realistic threat which is prevented by POP.

> 
> Carlisle.
> 
> 

Cheers,

Michael Warner
Telstra Research Laboratories

Date: Tue, 16 Jun 1998 17:35:47 -0700
To: Tim Polk <[email-masked]>, [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: new profile submitted
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

At 05:28 PM 6/16/98 -0400, Tim Polk wrote:
>It corporates all changes discussed in LA, but CRL distribution points was
>not excised from the draft.  After extensive negotiations, new licensing
>terms were completed THIS MORNING.
>
>(I will not speak to the agreement - I'm leaving that for Jeff Schiller.) 

<waiting for the other shoe to drop...> 

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Wed, 17 Jun 1998 01:31:32 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: proof-of-possession for DH keys
Sender: [email-masked]

Carlisle writes:
> > You assume that I am holding the corresponding private decryption key.
> > If I don't, I am unable to decrypt. That case might happen if, when
> > performing my certification request, I provided garbage data instead of
> > a real public key or if I *willingly* gave the value of the public key
> > from someone else. 
> > 
> 
> This is the whole purpose of doing POP: precisely to prevent such
> pointless actions on the part of the requester.

Preventing against the "pointless action" attack is kind of hard --
normally parties are expected to be acting in their own interests.

You are proposing that we instead consider that parties are trying to
act in as obtuse a manner as they are able, by creating random public
keys (which will result in their receiving messages which they will
not be able to decrypt).  

You would then be proposing that our task is to detect and prevent
this behaviour within the protocol.  It seems that the particular
pointless action attack you are interested to prevent is self
inflicted DoS.

Earlier I gave an example of how Mary (the Masochist, our self
destructive party) can still perform a self inflicted DoS attack even
in the presence of POPs which claim to defend against this: (1) delete
her private key immediately after creating the POP.

Another attack Mary might perform (2) is to post her private key to
USENET, destroying your expectation of privacy in using her public
key.

Or Mary might (3) post the plaintext all of your encrypted emails sent
to her to USENET more immediately destroying your expectation of
privacy.

You can actually do things to reduce the risk of and/or increase the
costs to Mary of performing all of these attacks, the question really
though is does the utility gained justify the added complexity.

The (marginal) utility that I see POP provides is early detection of
implementation flaws where the implementation erroneously submits
random data, garbled data, or malformed ASN.1 in place of a public key
(for example if it was written by Microsoft).

Adam

For the curious, mechanisms to reduce risks/increase costs are
respectively:

For attack (1) do as Denis Pinkas argued against on grounds of
practicality: demand a POP prior to sending encrypted message, or have
the CA demand fresh POPs periodically.  Or financially penalise Mary
if she fails to answer periodic POP challenges from the CA with funds
held in escrow.

For attack (2) use a ZKP to ensure that if Mary reveals her private
key she will be financially penalised, for example by including in the
certificate electronic cash encrypted with the private key.

For attack (3) use public key watermarking on your document prior to
encrypting and sending it to Mary.  (Public key watermarking prevents
against the obvious false accusation problem).  Present proof of
Mary's posting to the CA to have CA financially penalise Mary.

Date: Tue, 16 Jun 1998 20:07:58 -0700
To: Carlisle Adams <[email-masked]>, Robert Zuccherato <[email-masked]>, [email-masked], "'Jessica Hymowitz'" <[email-masked]>
From: Warwick Ford <[email-masked]>
Subject: RE: Certificate Revocation
Sender: [email-masked]

Hi, Carlisle:

At 11:25 AM 6/15/98 -0400, Carlisle Adams wrote:
>Hi Warwick,
>
>> ----------
>> From: 	Warwick Ford[SMTP:[email-masked]]
>> Sent: 	Saturday, June 13, 1998 5:27 PM
>> To: 	Robert Zuccherato; [email-masked]; 'Jessica Hymowitz'
>> Subject: 	RE: Certificate Revocation
>> 
>> I read with interest Robert and Carlisle's "White Paper".  It provides
>> some
>> helpful discussion of the indirection mechanism ("CRL List" mechanism)
>> developed in OCDP, and contains some interesting refinement ideas.  
>> 
>> The thought of using delta CRLs in conjubction with the CRL List mechanism
>> is interesting, although I suspect client implementors will not embrace
>> that, given the implementation complexities.  Back in the X.509 v3 design
>> days, Hoyt and I spent hours discussing the pros and cons of delta CRLs
>> and
>> we concluded that they may well be an attractive option for large servers
>> (for performance reasons) but not appropriate for clients (because of
>> state
>> maintenance problems).  I tend to think that same analysis will apply to
>> using delta CRLs with CRL Lists.
>> 
>Perhaps you could give some more detail regarding the "hours of discussion"
>you and Hoyt had on delta CRLs (feel free to copy him on the response, if
>you like, so he can join in if he wishes), because I don't understand your
>summary above at all.  Why would deltas have any more "state maintenance"
>than CRLs themselves?  Few people have built or will build a client that
>pulls down an entire CRL every time it wants to check revocation; rather, it
>typically pulls down a CRL once per period and caches it until its
>nextUpdate date.  Deltas don't in any way add to this state maintenance.
>All they do is allow a relying party to get fresher information (if they
>want it) between CRL updates.

Yes, I would welcome Hoyt's views (I consider Hoyt to be the father of
delta CRLs).  The volume of discussion was largely because the two concepts
of delta CRLs and CRL partitions were themselves being designed at the time
and we were trying to be sure we understood the rationale for having both
mechanisms.  I won't try to go through all the paths here, but rather shall
try to spell out the bottom line.  The complicating factor with deltas is
that someone checking revocation is no longer able to process a single data
item to be certain that the cert is not revoked.  Rather he/she/it needs to
obtain, validate, and scan at least two separate data items (the delta and
the base CRL), and maybe more depending on your delta regime.  Deltas are
inherently state-oriented, in that it only makes sense to deploy them in an
environment in which you have a general expectation that, when you fetch
the delta CRL, you already hold, from some prior activity, the base CRL or
contents thereof.  This is likely true in a busy server but more
questionable in a small client system which does only very sporadic
revocation checks with any given CA.  The reason for using deltas is to
keep down the size of items retrieved.  An alternative means of keeping
down size is partitioning, and if partitioning if done sufficiently
intelligently (note that, with Scopes, we now have some interesting new
options for intelligent partitioning), the use of deltas may not be
warranted, especially in small clients.  That said, let me make clear that
I am not opposed to deltas -- I have always supported having them as an
option, and I think your proposal for using them in CRL lists is a good
idea -- as an option.  

>> One deficiency in Robert and Carlisle's analysis is their lack of
>> recognition of one of the most important underlying concepts of OCDP.  If
>> unsigned pointers indeed have denial of service implications, the solution
>> offered by Robert and Carlisle, that is to have the CA sign the pointer,
>> is
>> just not the general answer.  The point is that, in many spheres of
>> application of certificates, the issue of revocation or status checking is
>> considered a relying-party-domain-control issue -- not a
>> certificate-issuer-domain-control issue.  In other words, the relying
>> party's enterprise will decide where, and under what policy conditions,
>> its
>> relying parties will go to check certificate status.  This could very well
>> be a local server or directory -- not back at the CA.
>> 
>> Financial industry applications, for example, generally reflect this model
>> (for good business reasons).  For example, with credit cards, the merchant
>> goes to its acquirer for a card authorization -- not directly to the
>> issuer.  The credit card equivalent of a CDP would be for the issuer to
>> include its contact details (for card authorization purposes) on the card
>> -- this is not the practice. 
>> 
>> For this reason (among others) we saw it important to move away from the
>> model in which the revocation mechanism is rigidly tied to an embedded
>> revocation pointer in the certificate itself.  I feel that any work to
>> further develop the OCDP ideas should definitely preserve this aspect of
>> the OCDP model.
>> 
>You claim above that we have not recognized one of the most important
>underlying concepts of OCDP.  On the contrary, I suggest that you seem not
>to have recognized *the* most important underlying concept of CDP:  it is
>OPTIONAL (and when it is used, it is NON-CRITICAL).  Thus, there is no
>standard anywhere in which "the revocation mechanism is rigidly tied to an
>embedded revocation pointer in the certificate itself".  CAs can put
>distribution points in certificates, or not.  If they happen to do so,
>relying parties can go to the location pointed to for revocation
>information, or can go somewhere else of their own choosing (note that since
>the extension is non-critical, a relying party may not have software that
>understands the extension while still being perfectly conformant with X.509
>and PKIX).

You need to clarify something in your paper.  In your early material you
appeared to dismiss OCDP with the comment "The use of unsigned pointers,
however, leaves the proposal open to denial-of-service attacks."  While I
don't understand or subscribe to that comment, I read into it that you were
similarly dismissing all mechanisms that did not use CDPs.  I welcome the
new assurance that that is not the case, and suggest you clarify that you
recognize the need for non-CDP mechanisms (such as OCDP) as well as the CDP
mechanism, dependent on needs.

Warwick 

---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., Tel (781)2456996 x225; Fax (781)2456006
[email-masked];  301 Edgewater Pl, Suite 210, Wakefield, MA 01880
---------------------------------------------------------------------

Date: Tue, 16 Jun 1998 17:28:41 -0400
To: [email-masked]
From: Tim Polk <[email-masked]>
Subject: new profile submitted
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

I have submitted the new draft of the profile.  In the interim, you can get
it via the following URL:

http://csrc.nist.gov/pki/draft-ietf-pkix-ipki-part1-08.txt

It corporates all changes discussed in LA, but CRL distribution points was
not excised from the draft.  After extensive negotiations, new licensing
terms were completed THIS MORNING.

(I will not speak to the agreement - I'm leaving that for Jeff Schiller.) 

Brief Notes:

#1 I am asking for Last Call.

#2 If you want something changed, please submit your suggestions to the
list WITH TEXT.  We want to forward this to the IESG as soon as possible.
That will not be possible if we discuss abstract changes on the list.
Concrete text is a MUST.

#3 The document isn't really longer - the ASN.1 in the appendices is simply
more complete.

Thanks,

Tim Polk

Date: Tue, 16 Jun 1998 11:01:11 -0600
From: Mike Smith <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: Re: RE: proof-of-possession for DH keys
Sender: [email-masked]

There is another important reason for a PKI deployer to require POP, aside from the "I have the private key" assertion of the certificate requestor.  With POP, the deployer/issuer will know that the requestor has in her or his possession a tool that can create a digital signature AND that their own tools (within the PKI that they are issuing the cert) can validate the signature using the signed request and included public key.

This is an operational reeason that would be a best business practice, and separate from a tech spec, but important none the less.  So, POP is a good business practice and a good thing in generla.  The question then becomes< "where should POP be specified".  If the intent is to define a minimum operational specification, then POP, time and date stamping, transaction logging and many more things should be included in such a document.  These operational procedure capabilities must be supported by the technical requirements at a minimum, but not the requirement to conduct such operational testing itself.  POP and all other operational requirements or best practices should be in the policies and concept of operations efforts and so should the debate.

Michael

>>> Carlisle Adams <[email-masked]> 06/16 9:54 AM >>>
Hi Adam,

> ----------
> From:  Adam Back[SMTP:[email-masked]] 
> Sent:  Tuesday, June 16, 1998 7:30 AM
> To:  [email-masked] 
> Cc:  [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked] 
> Subject:  Re: proof-of-possession for DH keys
> 
> 
> Carlisle Adams writes:
> > A certificate [...] is a binding between an entity and a key pair.
> > I think we all recognize that the CA should verify the identity of
> > the requester [...]  However, until we've got [...] operational
> > protocols that verify that the entity named in the certificate has
> > possession of *both* halves of the key pair, the only prudent action
> > is to mandate that the CA must verify this as well.  If this is not
> > done, certificates in the PKI have no meaning and are, for all
> > intents and purposes, worthless.
> 
> Others have used this argument.  I think this line of reasoning is
> suspect.
> 
> A CA's purpose is to certify public key <-> name bindings based on
> some procedure for verifying the identity of the certification request
> originator.
> 
> If a user chooses to supply a public key which he does not have the
> private key for, all he is doing is performing a DoS attack against
> himself.  This is not an interesting class of attack (self inflicted
> DoS), therefore defending against it is also uninteresting.  It is
> impossible to defend against self inflicted DoS -- I could as easily
> destroy the private key immediately creating the proof of possession.
> 
POP is *NOT* done to defend against denial-of-service attacks.  [I'm
beginning to wonder how many times I've said this in the past couple of
years...]  It's primary goal has nothing whatsoever to do with any kind of
attack (although it can coincidentally help to avoid a particular attack in
the case of signing key pairs).

POP is done so that a certificate has meaning, is trustworthy in some sense,
to a relying party.  When I use your certificate (to encrypt for you, to
verify your signature, whatever), it is because I assume that you hold the
private key corresponding to the public key in the certificate.  If I can't
make that assumption, then I have no reason *whatsoever* to use your
certificate (*regardless* of any possible security attack; I simply have no
reason to use your cert.).  This is not a useful PKI by any definition.

> It is an unnecessary restriction to require proof of possession of
> private keys for algorithms which provide only encryption, and do not
> directly provide a signature method.
> 
I can't see why trying to ensure that meaningful certificates are created is
an "unnecessary restriction" in PKIX.

> Separation of concerns suggests that signature keys and signature
> algorithms should be used to delegate trust to encryption keys,
> whether by individuals using signature keys ceritified by CAs, or by
> CAs certifying encryption keys directly.
> 
I don't understand your comment here.  This is precisely what PKIX does,
because certificates are signed by signature keys.  All we're saying is
that, as much as this can be determined,  trust should be delegated to
something trustworthy.

--------------------------------------------
Carlisle Adams
Entrust Technologies
[email-masked] 
--------------------------------------------

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            

From: Carlisle Adams <[email-masked]>
To: "'Adam Back'" <[email-masked]>
Cc: [email-masked]
Subject: RE: proof-of-possession for DH keys
Date: Tue, 16 Jun 1998 11:54:01 -0400
Sender: [email-masked]

Hi Adam,

> ----------
> From: 	Adam Back[SMTP:[email-masked]]
> Sent: 	Tuesday, June 16, 1998 7:30 AM
> To: 	[email-masked]
> Cc: 	[email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: 	Re: proof-of-possession for DH keys
> 
> 
> Carlisle Adams writes:
> > A certificate [...] is a binding between an entity and a key pair.
> > I think we all recognize that the CA should verify the identity of
> > the requester [...]  However, until we've got [...] operational
> > protocols that verify that the entity named in the certificate has
> > possession of *both* halves of the key pair, the only prudent action
> > is to mandate that the CA must verify this as well.  If this is not
> > done, certificates in the PKI have no meaning and are, for all
> > intents and purposes, worthless.
> 
> Others have used this argument.  I think this line of reasoning is
> suspect.
> 
> A CA's purpose is to certify public key <-> name bindings based on
> some procedure for verifying the identity of the certification request
> originator.
> 
> If a user chooses to supply a public key which he does not have the
> private key for, all he is doing is performing a DoS attack against
> himself.  This is not an interesting class of attack (self inflicted
> DoS), therefore defending against it is also uninteresting.  It is
> impossible to defend against self inflicted DoS -- I could as easily
> destroy the private key immediately creating the proof of possession.
> 
POP is *NOT* done to defend against denial-of-service attacks.  [I'm
beginning to wonder how many times I've said this in the past couple of
years...]  It's primary goal has nothing whatsoever to do with any kind of
attack (although it can coincidentally help to avoid a particular attack in
the case of signing key pairs).

POP is done so that a certificate has meaning, is trustworthy in some sense,
to a relying party.  When I use your certificate (to encrypt for you, to
verify your signature, whatever), it is because I assume that you hold the
private key corresponding to the public key in the certificate.  If I can't
make that assumption, then I have no reason *whatsoever* to use your
certificate (*regardless* of any possible security attack; I simply have no
reason to use your cert.).  This is not a useful PKI by any definition.

> It is an unnecessary restriction to require proof of possession of
> private keys for algorithms which provide only encryption, and do not
> directly provide a signature method.
> 
I can't see why trying to ensure that meaningful certificates are created is
an "unnecessary restriction" in PKIX.

> Separation of concerns suggests that signature keys and signature
> algorithms should be used to delegate trust to encryption keys,
> whether by individuals using signature keys ceritified by CAs, or by
> CAs certifying encryption keys directly.
> 
I don't understand your comment here.  This is precisely what PKIX does,
because certificates are signed by signature keys.  All we're saying is
that, as much as this can be determined,  trust should be delegated to
something trustworthy.

--------------------------------------------
Carlisle Adams
Entrust Technologies
[email-masked]
--------------------------------------------

From: Carlisle Adams <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: [email-masked]
Subject: RE: proof-of-possession for DH keys
Date: Tue, 16 Jun 1998 11:29:36 -0400
Sender: [email-masked]

Hi Denis,

> ----------
> From: 	Denis Pinkas[SMTP:[email-masked]]
> Sent: 	Tuesday, June 16, 1998 6:06 PM
> To: 	Carlisle Adams
> Cc: 	[email-masked]
> Subject: 	Re: proof-of-possession for DH keys
> 
> > However, until we've got (in a completely ubiquitous way,
> > without any exceptions whatsoever) operational protocols that verify
> that
> > the entity named in the certificate has possession of *both* halves of
> the
> > key pair, 
> 
> This is the issue. We are now saying that, in the current draft, we
> mandate POP for encryption keys but without a justification for it. If
> there is no justification, then we should not mandate it.
> 
> > the only prudent action is to mandate that the CA must verify this
> > as well.  If this is not done, certificates in the PKI have no meaning
> and
> > are, for all intents and purposes, worthless.
> 
> This is not a justification.
> 
Given that the entire goal of PKIX is to create a usable PKI for the
Internet, it seems clear that avoiding meaningless, worthless certificates
*is* a justification.

> > If I'm going to encrypt for you using your public encryption key, I must
> be
> > confident that you hold the corresponding private decryption key or else
> why
> > would I bother encrypting?  
> 
> You assume that I am holding the corresponding private decryption key.
> If I don't, I am unable to decrypt. That case might happen if, when
> performing my certification request, I provided garbage data instead of
> a real public key or if I *willingly* gave the value of the public key
> from someone else. 
> 
This is the whole purpose of doing POP:  precisely to prevent such pointless
actions on the part of the requester.

> > Perhaps I can go through some sort of on-line
> > protocol with you to see if you have the private key, but clearly this
> is
> > not always practical (not to mention that such (standardized) protocols
> do
> > not currently exist for most environments...).  
> > Consequently, the only course of action is to assume that 
> > the certificate binds the entity to the *pair* of keys.
> > Otherwise, I have no reason to use the public key in the
> > certificate to encrypt for you.
> 
> Fine.
> 
Thank you, Denis.  I couldn't possibly have put the argument more succinctly
than that!  You clearly agree that without POP I have no reason to use the
public key in the certificate to encrypt for you.  Therefore, your
encryption certificate is of no value whatsoever to me.

Why in the world would PKIX define protocols that allow such worthless
certificates to be created?  PKIX is trying to create a usable PKI.  The PKI
is not "usable" if I can't know which certificates I can use and which ones
I can't.

Carlisle.

Date: Tue, 16 Jun 1998 15:06:38 -0700
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: Carlisle Adams <[email-masked]>
CC: [email-masked]
Subject: Re: proof-of-possession for DH keys
Sender: [email-masked]

Carlisle,

It seems that we have different views on this issue.

> A certificate (at least for the purposes of PKIX) is a binding between an
> entity and a key pair.  I think we all recognize that the CA should verify
> the identity of the requester (i.e., that identity = "id of the entity", so
> to speak  :-).  

... but also verify that the request is coming from that entity. As Adam
Back said in a response to you:

" A CA's purpose is to certify public key <-> name bindings based on
some procedure for verifying the identity of the certification request
originator."

> However, until we've got (in a completely ubiquitous way,
> without any exceptions whatsoever) operational protocols that verify that
> the entity named in the certificate has possession of *both* halves of the
> key pair, 

This is the issue. We are now saying that, in the current draft, we
mandate POP for encryption keys but without a justification for it. If
there is no justification, then we should not mandate it.

> the only prudent action is to mandate that the CA must verify this
> as well.  If this is not done, certificates in the PKI have no meaning and
> are, for all intents and purposes, worthless.

This is not a justification. Again, Adam Back gave the right answer:

" If a user chooses to supply a public key which he does not have the
private key for, all he is doing is performing a DoS [Denial of Service]
attack against himself."
 
> If I'm going to encrypt for you using your public encryption key, I must be
> confident that you hold the corresponding private decryption key or else why
> would I bother encrypting?  

You assume that I am holding the corresponding private decryption key.
If I don't, I am unable to decrypt. That case might happen if, when
performing my certification request, I provided garbage data instead of
a real public key or if I *willingly* gave the value of the public key
from someone else. 

> Perhaps I can go through some sort of on-line
> protocol with you to see if you have the private key, but clearly this is
> not always practical (not to mention that such (standardized) protocols do
> not currently exist for most environments...).  

I agree with you that we should not.  :-)

> Consequently, the only course of action is to assume that 
> the certificate binds the entity to the *pair* of keys.

Your assumption is correct, but it is only an assumption, ... not a
proof.
  
> Otherwise, I have no reason to use the public key in the
> certificate to encrypt for you.

Fine.
 
> > [Denis writes]

> > More precisely, the key usage bits shall/should indicate what kind of
> > SERVICE can be handled with the key, instead of the kind of MECHANISM
> > that may be supported with the key. We already tackled the issue when
> > taken about non repudiation (which is a service and not a mechanism). We
> > have another case here.

> > Now let me try to answer the question from Nada, and let us restrict the
> > discusssion for the next two lines to keys only able to encrypt/decrypt.

> > If the key is used to support a confidentiality service, then POP is NOT
> > required.
> > If the key is used to support an authentication service, then POP is
> > required.

> > My conclusion is that the key usage bits shall always indicate the usage
> > of the key for, at least, one security SERVICE. If we still use some
> > bits to indicate a mechanism (like digital signature) then at least one
> > key usage bit for a service should be present. Now, I wonder if we still
> > need bits for mechanisms. If we do, making a clear cut between service
> > bits and mechanism bits, will certainly help to clarify the overall
> > topic.

> > Note : For the difference between a service and a mechanism see ISO
> > 7498-2 (where digital signature is defined as a mechanism, and not as
> > service). See table 1. BTW, ISO 7498-2 is already 10 years old.

> This has nothing whatsoever to do with specific attacks and nothing
> whatsoever to do with services vs. mechanisms (as useful as that distinction
> might be).  

I respectfully disagree with you on this. The distinction is fairly
important. There exists some protocols (that I do not like too much) but
which nevertheless allow to perform per entity authentication while
using encrypting keys (instead of signature keys). In that case it is
mandatory to perform POP.

> It has to do with whether or not it makes sense for me to use
> the public key in your certificate to encrypt for you.  If POP has been
> done, then it makes sense for me to use your certificate.  

... in order to support one of the following services: per entity
authentication, data origin authentication with integrity or data
confidentiality.

> If POP has not been done, 

... then it makes sense to use your certificate, in order to support
only the following service: data confidentiality.

> then I might as well use any arbitrary public key 

No. You won't do this. Will you ?  :-)

> (or, in fact, I might as well not encrypt because I have absolutely 
> no reason to think that you will be able to decrypt the data).

Denis

-- 
      Denis Pinkas     Bull S.A.          mailto:[email-masked]
      Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

Date: Tue, 16 Jun 1998 12:30:55 +0100
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: proof-of-possession for DH keys
Sender: [email-masked]

Carlisle Adams writes:
> A certificate [...] is a binding between an entity and a key pair.
> I think we all recognize that the CA should verify the identity of
> the requester [...]  However, until we've got [...] operational
> protocols that verify that the entity named in the certificate has
> possession of *both* halves of the key pair, the only prudent action
> is to mandate that the CA must verify this as well.  If this is not
> done, certificates in the PKI have no meaning and are, for all
> intents and purposes, worthless.

Others have used this argument.  I think this line of reasoning is
suspect.

A CA's purpose is to certify public key <-> name bindings based on
some procedure for verifying the identity of the certification request
originator.

If a user chooses to supply a public key which he does not have the
private key for, all he is doing is performing a DoS attack against
himself.  This is not an interesting class of attack (self inflicted
DoS), therefore defending against it is also uninteresting.  It is
impossible to defend against self inflicted DoS -- I could as easily
destroy the private key immediately creating the proof of possession.

If an imposter manages to fool the CA into thinking that he is Bob,
then it seems likley that the imposter would be able to provide proof
of possession of the corresponding private key -- the attacker would
after all have generated the certificate request.

The authentication of the certificate request _has_ to take place
using other mechanisms anyway, because an attacker can easily replace
a certificate and a POP with an equally valid appearing cert and POP.

It is an unnecessary restriction to require proof of possession of
private keys for algorithms which provide only encryption, and do not
directly provide a signature method.

Separation of concerns suggests that signature keys and signature
algorithms should be used to delegate trust to encryption keys,
whether by individuals using signature keys ceritified by CAs, or by
CAs certifying encryption keys directly.

Adam

Date: Tue, 16 Jun 1998 10:24:24 +0200
To: Carlisle Adams <[email-masked]>, "'Nada Kapidzic Cicovic'" <[email-masked]>
From: Harald Tveit Alvestrand <[email-masked]>
Subject: RE: proof-of-possession for DH keys
Cc: [email-masked]
Sender: [email-masked]

At 10:24 12.06.98 -0400, Carlisle Adams wrote:
>
>The entire promise of public-key cryptography was that two complete
>strangers who had never met or exchanged data before could exchange data
>securely.  Without proof-of-possession, this promise falls apart.
>
I don't quite see this.
I think there are 2 parts to security with public-key cryptography:

- Possession. A self-signed certificate proves that *someone* has that
  key, and is enough for anonymous secure communication (unless there's a man
  in the middle. CA chains prove either that there's no man in the
  middle or that he's caught your other channels too.)
  Successful decryption of an encrypted message is also proof of possession.
- Sole possession. Secrecy depends on me being the *only* holder of my
  private key (or that the other holders are trustworthy too).
  A CA can only sign that I have promised that at one point in time;
  it is not a fact that can be verified.

So what you want the CA to verify with encryption keys is not really POPO,
but POPTTC - Proof of Promise To Take Care.

                            Harald A

-- 
Harald Tveit Alvestrand, Maxware, Norway
[email-masked]

Date: Mon, 15 Jun 1998 10:47:29 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Cc: [email-masked]
Subject: Re: RE: proof-of-possession for DH keys
Sender: [email-masked]

Sorry, Nada, you are quite right.  I guess I was thinking 
more about proving someone's bona fides than simply 
POP of the private key. Must have been
working too hard last week.

Not enforcing POP for encryption certificates potentially leads to a 
denial of service attack against the party named in the certificate, 
but not much else that I can see. But there might be some subtlety
that is escaping me.

Bob

>>> Nada Kapidzic Cicovic <[email-masked]> 06/15 2:42 AM >>>
At 12:36 6/12/98 -0600, Bob Jueneman wrote:
>Tony,
>
>No, the flow is going the other way. Carlisle's well stated 
>point is that whenever you validate a certificate, for 
>whatever purpose at all, you have to ensure that the 
>person whose public key is being bound into the certificate
>actually owns the private key.
>
>I think it is clear in the case of digital signatures -- someone else 
>could claim to have signed your invention disclosure, etc.
>
>But it is even worse if I take MY public key and send it to your CA
>along with a certificate request in your name.  Now someone 
>tries to send you encrypted mail, and you can't read it but I can.

Bob,

This is a problem no matter what type of certificate you want to get
certified, and enforcing POPO on the CA is not helping you get out of it.
You can create the valid POPO with YOUR private key corresponding to the
public key from the certificate and present it to the CA in my name. 

The problem you are describing has to do with having the CA authenticate
the request and prove for the binding between the request and your claimed
identity. POP is not the mechanism for doing that.

Regards,

Nada

>
>Bob
>
>>At 10:24 AM 6/12/98 -0400, Carlisle Adams wrote:
>>>Hi Nada,
>>
>>[Nada writes]
>>
>>>> For digitalSignature keys, proof of possession does make sense. You need
>>>> to
>>>> prove that you have the corresponding private key, so that you cannot get
>>>> a
>>>> certificate issued in your name containing someone else's public key.
>>
>>[Nada continues]
>>
>>>> However, I somehow fail to see the reason for proving POPO for
>>>> keyEncipherment and keyAgreement keys. If you request the
certification of
>>>> a keyEncipherment certificate with someone else's public key, I do not
see
>>>> what would you gain by getting it issued in your name.
>>
>>
>>[Carlisle replies]
>>
>>>After the signature on a cert. has been verified mathematically; after the
>>>cert. has been checked for revocation; after the signature and revocation
>>>status have been checked for all other certs involved in the path; after
>>>validity periods, key usage bits, policy OIDs, etc., etc., etc., have been
>>>confirmed to be acceptable, I *still* have to make the fundamental
>>>assumption that the entity named in the certificate owns the corresponding
>>>private key.  Otherwise, I have no reason whatsoever to use this
certificate
>>>instead of any other certificate or any bare public key.
>>
>>Friends,
>>
>>Is the "key" issue here (sorry about that) that by requiring POP for
>>encypherment/agreement key certification, one gets authentication "for
>>free" when message encryption is employed?  Otherwise, a protocol would
>>require that the encrypted data be, in addition, signed?
>>
>>___tony___
>>
>>Tony Bartoletti                                             LL
>>SPI-NET GURU                                             LL LL
>>Computer Security Technology Center                   LL LL LL
>>Lawrence Livermore National Lab                       LL LL LL
>>PO Box 808, L - 303                                   LL LL LLLLLLLL
>>Livermore, CA 94551-9900                              LL LLLLLLLL
>>email: [email-masked]   phone: 510-422-3881             LLLLLLLL
>
>
>

From: Carlisle Adams <[email-masked]>
To: Bob Jueneman <[email-masked]>, "[email-masked]'" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: RE: proof-of-possession for DH keys
Date: Mon, 15 Jun 1998 12:03:50 -0400
Sender: [email-masked]

Hi Denis,

> ----------
> From: 	Denis Pinkas[SMTP:[email-masked]]
> Sent: 	Monday, June 15, 1998 12:44 PM
> To: 	Bob Jueneman
> Cc: 	[email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: 	Re: proof-of-possession for DH keys
> 
> [Bob continues]
>  
> I think it is clear in the case of digital signatures -- someone else
> could claim to have signed your invention disclosure, etc.
>  
> But it is even worse if I take MY public key and send it to your CA
> along with a certificate request in your name.  Now someone
> tries to send you encrypted mail, and you can't read it but I can.
> 
> [Denis writes]
> 
> Bob, your scenario won't work: the CA should refuse to issue the
> certificate because you cannot authenticate your request to the RA/CA
> under someone else name. The CA shall verify that the name for which you
> request the certificate can be authenticated with your whole request
> (that includes a public key).
> 
Might I suggest that we all look back at the PKIX archives (personal or
public) on this thread?  This was all discussed quite thoroughly some time
ago...

A certificate (at least for the purposes of PKIX) is a binding between an
entity and a key pair.  I think we all recognize that the CA should verify
the identity of the requester (i.e., that identity = "id of the entity", so
to speak  :-).  However, until we've got (in a completely ubiquitous way,
without any exceptions whatsoever) operational protocols that verify that
the entity named in the certificate has possession of *both* halves of the
key pair, the only prudent action is to mandate that the CA must verify this
as well.  If this is not done, certificates in the PKI have no meaning and
are, for all intents and purposes, worthless.

If I'm going to encrypt for you using your public encryption key, I must be
confident that you hold the corresponding private decryption key or else why
would I bother encrypting?  Perhaps I can go through some sort of on-line
protocol with you to see if you have the private key, but clearly this is
not always practical (not to mention that such (standardized) protocols do
not currently exist for most environments...).  Consequently, the only
course of action is to assume that the certificate binds the entity to the
*pair* of keys.  Otherwise, I have no reason to use the public key in the
certificate to encrypt for you.

> [Denis writes]
> 
> More precisely, the key usage bits shall/should indicate what kind of
> SERVICE can be handled with the key, instead of the kind of MECHANISM
> that may be supported with the key. We already tackled the issue when
> taken about non repudiation (which is a service and not a mechanism). We
> have another case here.
> 
> Now let me try to answer the question from Nada, and let us restrict the
> discusssion for the next two lines to keys only able to encrypt/decrypt.
> 
> If the key is used to support a confidentiality service, then POP is NOT
> required.
> If the key is used to support an authentication service, then POP is
> required.
> 
> My conclusion is that the key usage bits shall always indicate the usage
> of the key for, at least, one security SERVICE. If we still use some
> bits to indicate a mechanism (like digital signature) then at least one
> key usage bit for a service should be present. Now, I wonder if we still
> need bits for mechanisms. If we do, making a clear cut between service
> bits and mechanism bits, will certainly help to clarify the overall
> topic.
> 
> Note : For the difference between a service and a mechanism see ISO
> 7498-2 (where digital signature is defined as a mechanism, and not as
> service). See table 1. BTW, ISO 7498-2 is already 10 years old.
> 
This has nothing whatsoever to do with specific attacks and nothing
whatsoever to do with services vs. mechanisms (as useful as that distinction
might be).  It has to do with whether or not it makes sense for me to use
the public key in your certificate to encrypt for you.  If POP has been
done, then it makes sense for me to use your certificate.  If POP has not
been done, then I might as well use any arbitrary public key (or, in fact, I
might as well not encrypt because I have absolutely no reason to think that
you will be able to decrypt the data).

--------------------------------------------
Carlisle Adams
Entrust Technologies
[email-masked]
--------------------------------------------

From: Carlisle Adams <[email-masked]>
To: Robert Zuccherato <[email-masked]>, [email-masked], "'Jessica Hymowitz'" <[email-masked]>, "'Warwick Ford'" <[email-masked]>
Subject: RE: Certificate Revocation
Date: Mon, 15 Jun 1998 11:25:09 -0400
Sender: [email-masked]

Hi Warwick,

> ----------
> From: 	Warwick Ford[SMTP:[email-masked]]
> Sent: 	Saturday, June 13, 1998 5:27 PM
> To: 	Robert Zuccherato; [email-masked]; 'Jessica Hymowitz'
> Subject: 	RE: Certificate Revocation
> 
> I read with interest Robert and Carlisle's "White Paper".  It provides
> some
> helpful discussion of the indirection mechanism ("CRL List" mechanism)
> developed in OCDP, and contains some interesting refinement ideas.  
> 
> The thought of using delta CRLs in conjubction with the CRL List mechanism
> is interesting, although I suspect client implementors will not embrace
> that, given the implementation complexities.  Back in the X.509 v3 design
> days, Hoyt and I spent hours discussing the pros and cons of delta CRLs
> and
> we concluded that they may well be an attractive option for large servers
> (for performance reasons) but not appropriate for clients (because of
> state
> maintenance problems).  I tend to think that same analysis will apply to
> using delta CRLs with CRL Lists.
> 
Perhaps you could give some more detail regarding the "hours of discussion"
you and Hoyt had on delta CRLs (feel free to copy him on the response, if
you like, so he can join in if he wishes), because I don't understand your
summary above at all.  Why would deltas have any more "state maintenance"
than CRLs themselves?  Few people have built or will build a client that
pulls down an entire CRL every time it wants to check revocation; rather, it
typically pulls down a CRL once per period and caches it until its
nextUpdate date.  Deltas don't in any way add to this state maintenance.
All they do is allow a relying party to get fresher information (if they
want it) between CRL updates.

> One deficiency in Robert and Carlisle's analysis is their lack of
> recognition of one of the most important underlying concepts of OCDP.  If
> unsigned pointers indeed have denial of service implications, the solution
> offered by Robert and Carlisle, that is to have the CA sign the pointer,
> is
> just not the general answer.  The point is that, in many spheres of
> application of certificates, the issue of revocation or status checking is
> considered a relying-party-domain-control issue -- not a
> certificate-issuer-domain-control issue.  In other words, the relying
> party's enterprise will decide where, and under what policy conditions,
> its
> relying parties will go to check certificate status.  This could very well
> be a local server or directory -- not back at the CA.
> 
> Financial industry applications, for example, generally reflect this model
> (for good business reasons).  For example, with credit cards, the merchant
> goes to its acquirer for a card authorization -- not directly to the
> issuer.  The credit card equivalent of a CDP would be for the issuer to
> include its contact details (for card authorization purposes) on the card
> -- this is not the practice. 
> 
> For this reason (among others) we saw it important to move away from the
> model in which the revocation mechanism is rigidly tied to an embedded
> revocation pointer in the certificate itself.  I feel that any work to
> further develop the OCDP ideas should definitely preserve this aspect of
> the OCDP model.
> 
You claim above that we have not recognized one of the most important
underlying concepts of OCDP.  On the contrary, I suggest that you seem not
to have recognized *the* most important underlying concept of CDP:  it is
OPTIONAL (and when it is used, it is NON-CRITICAL).  Thus, there is no
standard anywhere in which "the revocation mechanism is rigidly tied to an
embedded revocation pointer in the certificate itself".  CAs can put
distribution points in certificates, or not.  If they happen to do so,
relying parties can go to the location pointed to for revocation
information, or can go somewhere else of their own choosing (note that since
the extension is non-critical, a relying party may not have software that
understands the extension while still being perfectly conformant with X.509
and PKIX).

I would therefore argue that our proposal is the most general, readily
incorporating the credit card model you suggest above, as well as other
models more suited to other environments.

--------------------------------------------
Carlisle Adams
Entrust Technologies
[email-masked]
--------------------------------------------

Date: Mon, 15 Jun 1998 11:13:44 +0200
To: [email-masked], Bob Jueneman <[email-masked]>
From: Nada Kapidzic Cicovic <[email-masked]>
Subject: Re: proof-of-possession for DH keys
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

...

8<--------------------------------

>
>[Tony writes]
>
>Is the "key" issue here (sorry about that) that by requiring POP for
>encypherment/agreement key certification, one gets authentication "for
>free" when message encryption is employed?  Otherwise, a protocol would
>require that the encrypted data be, in addition, signed?
>
>[Denis writes]
>
>Yes, Tony, this is the key point.  :-) 
>
>More precisely, the key usage bits shall/should indicate what kind of
>SERVICE can be handled with the key, instead of the kind of MECHANISM
>that may be supported with the key. We already tackled the issue when
>taken about non repudiation (which is a service and not a mechanism). We
>have another case here.
>
>Now let me try to answer the question from Nada, and let us restrict the
>discusssion for the next two lines to keys only able to encrypt/decrypt.
>
>If the key is used to support a confidentiality service, then POP is NOT
>required.
>If the key is used to support an authentication service, then POP is
>required.
>
>My conclusion is that the key usage bits shall always indicate the usage
>of the key for, at least, one security SERVICE. If we still use some
>bits to indicate a mechanism (like digital signature) then at least one
>key usage bit for a service should be present. Now, I wonder if we still
>need bits for mechanisms. If we do, making a clear cut between service
>bits and mechanism bits, will certainly help to clarify the overall
>topic.
>

Denis,

Thank you for the explanation. I now understand the rationale for having
POP for authentication keys, and I also support your idea of
extending/replacing key usage bits with the actual security services
instead of mechanisms. I feel that the intended usage of keys would be much
more clear, if the key usage bits were specified in this way. 

I wonder if something could be done in that direction. Is it too late to
suggest one such change in part 1 and CMP, and I guess X.509 as well? It
seems to be worth a pain of changing all of them. Key usage should really
carry only definition of the service, since it seems to me that the
mechanism definition is implicit to the key algorithm (with RSA keys you
can both sign and encrypt, but with DSA you can only sign, etc.).
Additionally, the application developers would then be clear on what type
of service can they expect to have implicit in certification protocols, and
what they need to implement themselves.

An alternative to making a distinction between services and mechanisms in
key usage bits is to have keyUsage contain only description of key
mechanisms, and leave the services to application protocols. However, then
I do not see a reason for enforcing POP for encryption and agreement keys.

Regards,

Nada

Date: Mon, 15 Jun 1998 10:42:53 +0200
To: "Bob Jueneman" <[email-masked]>, [email-masked], [email-masked]
From: Nada Kapidzic Cicovic <[email-masked]>
Subject: Re: RE: proof-of-possession for DH keys
Cc: [email-masked]
Sender: [email-masked]

At 12:36 6/12/98 -0600, Bob Jueneman wrote:
>Tony,
>
>No, the flow is going the other way. Carlisle's well stated 
>point is that whenever you validate a certificate, for 
>whatever purpose at all, you have to ensure that the 
>person whose public key is being bound into the certificate
>actually owns the private key.
>
>I think it is clear in the case of digital signatures -- someone else 
>could claim to have signed your invention disclosure, etc.
>
>But it is even worse if I take MY public key and send it to your CA
>along with a certificate request in your name.  Now someone 
>tries to send you encrypted mail, and you can't read it but I can.

Bob,

This is a problem no matter what type of certificate you want to get
certified, and enforcing POPO on the CA is not helping you get out of it.
You can create the valid POPO with YOUR private key corresponding to the
public key from the certificate and present it to the CA in my name. 

The problem you are describing has to do with having the CA authenticate
the request and prove for the binding between the request and your claimed
identity. POP is not the mechanism for doing that.

Regards,

Nada

>
>Bob
>
>>At 10:24 AM 6/12/98 -0400, Carlisle Adams wrote:
>>>Hi Nada,
>>
>>[Nada writes]
>>
>>>> For digitalSignature keys, proof of possession does make sense. You need
>>>> to
>>>> prove that you have the corresponding private key, so that you cannot get
>>>> a
>>>> certificate issued in your name containing someone else's public key.
>>
>>[Nada continues]
>>
>>>> However, I somehow fail to see the reason for proving POPO for
>>>> keyEncipherment and keyAgreement keys. If you request the
certification of
>>>> a keyEncipherment certificate with someone else's public key, I do not
see
>>>> what would you gain by getting it issued in your name.
>>
>>
>>[Carlisle replies]
>>
>>>After the signature on a cert. has been verified mathematically; after the
>>>cert. has been checked for revocation; after the signature and revocation
>>>status have been checked for all other certs involved in the path; after
>>>validity periods, key usage bits, policy OIDs, etc., etc., etc., have been
>>>confirmed to be acceptable, I *still* have to make the fundamental
>>>assumption that the entity named in the certificate owns the corresponding
>>>private key.  Otherwise, I have no reason whatsoever to use this
certificate
>>>instead of any other certificate or any bare public key.
>>
>>Friends,
>>
>>Is the "key" issue here (sorry about that) that by requiring POP for
>>encypherment/agreement key certification, one gets authentication "for
>>free" when message encryption is employed?  Otherwise, a protocol would
>>require that the encrypted data be, in addition, signed?
>>
>>___tony___
>>
>>Tony Bartoletti                                             LL
>>SPI-NET GURU                                             LL LL
>>Computer Security Technology Center                   LL LL LL
>>Lawrence Livermore National Lab                       LL LL LL
>>PO Box 808, L - 303                                   LL LL LLLLLLLL
>>Livermore, CA 94551-9900                              LL LLLLLLLL
>>email: [email-masked]   phone: 510-422-3881             LLLLLLLL
>
>
>

Date: Mon, 15 Jun 1998 09:44:00 -0700
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: Bob Jueneman <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: proof-of-possession for DH keys
Sender: [email-masked]

[Bob Jueneman writes]

Tony,
 
No, the flow is going the other way. Carlisle's well stated
point is that whenever you validate a certificate, for
whatever purpose at all, you have to ensure that the
person whose public key is being bound into the certificate
actually owns the private key.

[Denis writes]

This is precisely what Nada is wondering about, so Carlisle's statement
cannot be taken as an axiome. The question from Nada has to be answered.

[Bob continues]
 
I think it is clear in the case of digital signatures -- someone else
could claim to have signed your invention disclosure, etc.
 
But it is even worse if I take MY public key and send it to your CA
along with a certificate request in your name.  Now someone
tries to send you encrypted mail, and you can't read it but I can.

[Denis writes]

Bob, your scenario won't work: the CA should refuse to issue the
certificate because you cannot authenticate your request to the RA/CA
under someone else name. The CA shall verify that the name for which you
request the certificate can be authenticated with your whole request
(that includes a public key).
 
[Nada writes]

For digitalSignature keys, proof of possession does make sense. 
You need to prove that you have the corresponding private key, 
so that you cannot get a certificate issued in your name containing
someone else's public key.
 
[Nada continues]
 
However, I somehow fail to see the reason for proving POPO for
keyEncipherment and keyAgreement keys. If you request the certification
of
a keyEncipherment certificate with someone else's public key, I do not
see
what would you gain by getting it issued in your name.

[Denis writes]

Yes. This is still the original question to be answered. :-)

[Carlisle replies]

After the signature on a cert. has been verified mathematically; after
the
cert. has been checked for revocation; after the signature and
revocation
status have been checked for all other certs involved in the path; after
validity periods, key usage bits, policy OIDs, etc., etc., etc., have
been
confirmed to be acceptable, I *still* have to make the fundamental
assumption that the entity named in the certificate owns the
corresponding
private key.  Otherwise, I have no reason whatsoever to use this
certificate
instead of any other certificate or any bare public key.

[Denis writes]

However, this does not answer Nada's question. :-(

[Tony writes]

Is the "key" issue here (sorry about that) that by requiring POP for
encypherment/agreement key certification, one gets authentication "for
free" when message encryption is employed?  Otherwise, a protocol would
require that the encrypted data be, in addition, signed?

[Denis writes]

Yes, Tony, this is the key point.  :-) 

More precisely, the key usage bits shall/should indicate what kind of
SERVICE can be handled with the key, instead of the kind of MECHANISM
that may be supported with the key. We already tackled the issue when
taken about non repudiation (which is a service and not a mechanism). We
have another case here.

Now let me try to answer the question from Nada, and let us restrict the
discusssion for the next two lines to keys only able to encrypt/decrypt.

If the key is used to support a confidentiality service, then POP is NOT
required.
If the key is used to support an authentication service, then POP is
required.

My conclusion is that the key usage bits shall always indicate the usage
of the key for, at least, one security SERVICE. If we still use some
bits to indicate a mechanism (like digital signature) then at least one
key usage bit for a service should be present. Now, I wonder if we still
need bits for mechanisms. If we do, making a clear cut between service
bits and mechanism bits, will certainly help to clarify the overall
topic.

Note : For the difference between a service and a mechanism see ISO
7498-2 (where digital signature is defined as a mechanism, and not as
service). See table 1. BTW, ISO 7498-2 is already 10 years old.

Thanks to Nada for daring raising the initial question. :-)

Denis

-- 
      Denis Pinkas     Bull S.A.          mailto:[email-masked]
      Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

Date: Sat, 13 Jun 1998 14:27:55 -0700
To: Robert Zuccherato <[email-masked]>, [email-masked], "'Jessica Hymowitz'" <[email-masked]>
From: Warwick Ford <[email-masked]>
Subject: RE: Certificate Revocation
Sender: [email-masked]

I read with interest Robert and Carlisle's "White Paper".  It provides some
helpful discussion of the indirection mechanism ("CRL List" mechanism)
developed in OCDP, and contains some interesting refinement ideas.  

The thought of using delta CRLs in conjubction with the CRL List mechanism
is interesting, although I suspect client implementors will not embrace
that, given the implementation complexities.  Back in the X.509 v3 design
days, Hoyt and I spent hours discussing the pros and cons of delta CRLs and
we concluded that they may well be an attractive option for large servers
(for performance reasons) but not appropriate for clients (because of state
maintenance problems).  I tend to think that same analysis will apply to
using delta CRLs with CRL Lists.

Also the proposal to use regular CRL syntax to encode a CRL List is
interesting -- we considered that when we drafted OCDP but thought this
might confuse rather than help readers in initially understanding the
special properties of a CRL List.  However, if this syntax would facilitate
implementation, that would be a good change to make.

One deficiency in Robert and Carlisle's analysis is their lack of
recognition of one of the most important underlying concepts of OCDP.  If
unsigned pointers indeed have denial of service implications, the solution
offered by Robert and Carlisle, that is to have the CA sign the pointer, is
just not the general answer.  The point is that, in many spheres of
application of certificates, the issue of revocation or status checking is
considered a relying-party-domain-control issue -- not a
certificate-issuer-domain-control issue.  In other words, the relying
party's enterprise will decide where, and under what policy conditions, its
relying parties will go to check certificate status.  This could very well
be a local server or directory -- not back at the CA.

Financial industry applications, for example, generally reflect this model
(for good business reasons).  For example, with credit cards, the merchant
goes to its acquirer for a card authorization -- not directly to the
issuer.  The credit card equivalent of a CDP would be for the issuer to
include its contact details (for card authorization purposes) on the card
-- this is not the practice. 

For this reason (among others) we saw it important to move away from the
model in which the revocation mechanism is rigidly tied to an embedded
revocation pointer in the certificate itself.  I feel that any work to
further develop the OCDP ideas should definitely preserve this aspect of
the OCDP model.

Certainly more work is needed to fully develop a complete revocation
solution based on OCDP, and Robert and Carlisle's contribution is welcomed.
 I think if we put all our heads together here, we can come up with
something that is a lot better than what was, in 1997, considered the state
of the art.

Warwick

At 02:07 PM 6/12/98 -0400, Robert Zuccherato wrote:
>For a more detailed description of our proposal, please see our white paper.

---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., Tel (781)2456996 x225; Fax (781)2456006
[email-masked];  301 Edgewater Pl, Suite 210, Wakefield, MA 01880
---------------------------------------------------------------------

Date: Fri, 12 Jun 1998 16:11:33 -0700
To: "Bob Jueneman" <[email-masked]>, [email-masked], [email-masked]
From: Tony Bartoletti <[email-masked]>
Subject: Re: RE: proof-of-possession for DH keys
Cc: [email-masked]
Sender: [email-masked]

At 12:36 PM 6/12/98 -0600, Bob Jueneman wrote:
>Tony,
>
>No, the flow is going the other way. Carlisle's well stated 
>point is that whenever you validate a certificate, for 
>whatever purpose at all, you have to ensure that the 
>person whose public key is being bound into the certificate
>actually owns the private key.
>
>I think it is clear in the case of digital signatures -- someone else 
>could claim to have signed your invention disclosure, etc.
>
>But it is even worse if I take MY public key and send it to your CA
>along with a certificate request in your name.  Now someone 
>tries to send you encrypted mail, and you can't read it but I can.

Thanks Bob.  I hadn't considered that scenario.

Question:  (Was I half-right?)  That is, given POP of encypherment/
agreement keys, my successful decryption of a message sent to me
should serve to authenticate the sender.  At least, in the case
I am used to (DSS Keys) each party uses their own secret key and
the other party's public key to generate a common shared secret
(modulo alg-parameters P,Q,G) which is used to convey a disposable
traffic key.

__tony__

Tony Bartoletti                                             LL
SPI-NET GURU                                             LL LL
Computer Security Technology Center                   LL LL LL
Lawrence Livermore National Lab                       LL LL LL
PO Box 808, L - 303                                   LL LL LLLLLLLL
Livermore, CA 94551-9900                              LL LLLLLLLL
email: [email-masked]   phone: 510-422-3881             LLLLLLLL

Date: Fri, 12 Jun 1998 12:36:43 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Cc: [email-masked]
Subject: Re: RE: proof-of-possession for DH keys
Sender: [email-masked]

Tony,

No, the flow is going the other way. Carlisle's well stated 
point is that whenever you validate a certificate, for 
whatever purpose at all, you have to ensure that the 
person whose public key is being bound into the certificate
actually owns the private key.

I think it is clear in the case of digital signatures -- someone else 
could claim to have signed your invention disclosure, etc.

But it is even worse if I take MY public key and send it to your CA
along with a certificate request in your name.  Now someone 
tries to send you encrypted mail, and you can't read it but I can.

Bob

>At 10:24 AM 6/12/98 -0400, Carlisle Adams wrote:
>>Hi Nada,
>
>[Nada writes]
>
>>> For digitalSignature keys, proof of possession does make sense. You need
>>> to
>>> prove that you have the corresponding private key, so that you cannot get
>>> a
>>> certificate issued in your name containing someone else's public key.
>
>[Nada continues]
>
>>> However, I somehow fail to see the reason for proving POPO for
>>> keyEncipherment and keyAgreement keys. If you request the certification of
>>> a keyEncipherment certificate with someone else's public key, I do not see
>>> what would you gain by getting it issued in your name.
>
>
>[Carlisle replies]
>
>>After the signature on a cert. has been verified mathematically; after the
>>cert. has been checked for revocation; after the signature and revocation
>>status have been checked for all other certs involved in the path; after
>>validity periods, key usage bits, policy OIDs, etc., etc., etc., have been
>>confirmed to be acceptable, I *still* have to make the fundamental
>>assumption that the entity named in the certificate owns the corresponding
>>private key.  Otherwise, I have no reason whatsoever to use this certificate
>>instead of any other certificate or any bare public key.
>
>Friends,
>
>Is the "key" issue here (sorry about that) that by requiring POP for
>encypherment/agreement key certification, one gets authentication "for
>free" when message encryption is employed?  Otherwise, a protocol would
>require that the encrypted data be, in addition, signed?
>
>___tony___
>
>Tony Bartoletti                                             LL
>SPI-NET GURU                                             LL LL
>Computer Security Technology Center                   LL LL LL
>Lawrence Livermore National Lab                       LL LL LL
>PO Box 808, L - 303                                   LL LL LLLLLLLL
>Livermore, CA 94551-9900                              LL LLLLLLLL
>email: [email-masked]   phone: 510-422-3881             LLLLLLLL

From: Robert Zuccherato <[email-masked]>
To: [email-masked], "'Jessica Hymowitz'" <[email-masked]>
Subject: RE: Certificate Revocation
Date: Fri, 12 Jun 1998 14:07:57 -0400
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------ =_NextPart_000_01BD962D.0820EE34
Content-Type: text/plain;
	charset="iso-8859-1"

 <<certrev>> 
Jessica;

Revocation is a topic of current interest among many different groups.  It
is for this reason that Carlisle Adams and I have recently prepared a white
paper on the topic.  The paper has been attached to this email and will be
available on our website within a few days  In this paper we discuss an
approach to revocation that provides all the advantages of using different
revocation technologies (OCSP, Open CDP, different flavours of CRLs) in one
simple proposal.  This proposal requires minimal changes to existing
standards.

We propose that one new certificate extension be defined.  This extension,
called the "Freshest Revocation Information Pointer" would be similar to the
CRL Distribution Point (CDP) extension.  It would be used, in addition to a
CDP, to point to a CRL that provides fresher information than the CDP.
Typically this would be a Delta CRL having as its base the CRL fragment
pointed to by the CDP extension.  Thus, applications that require fresher
information can obtain it, at an additional cost.

We also propose a new CRL extension, called a "Redirect Pointer".  This
pointer would allow repartitioning of Distribution Points by redirecting
certificates with particular scopes to other CRLs.  This is similar to the
Open CDP proposal, except that it is less open to denial of service attacks,
and it is based on existing standards.

For a more detailed description of our proposal, please see our white paper.

I would also like to respond to some of the comments made in the BITS
position note:

> ----------
> From: 	Jessica Hymowitz[SMTP:[email-masked]]
> Sent: 	Friday, June 12, 1998 10:26 AM
> To: 	[email-masked]
> Subject: 	Certificate Revocation
> 
> In the current generation of products which make use of public key 
> technology, and in CA products and services, support for revocation 
> processing is inconsistent or non-existent.  This creates potential 
> risk for web server IDs, secure e-mail, code signing, peer-to-peer 
> transactions, and other applications with many relying parties.  In 
> these applications, in the event of a compromise, there would be no 
> reliable way to inform the community at large.  This problem exists 
> no matter how certificate hierarchies and root structures evolve.  In 
> order to address this potential security and risk issue, there needs 
> to be agreement on core standards and profiles to promote interoperability
> 
> and incorporation of these features within commercial products.
> 
The core standards already exist and, as our white paper shows, are
sufficient for meeting the needs of most (all?) application environments.

> There are currently numerous technical alternatives which have been 
> discussed for  handling revocation. Two of the leading options for 
> revocation are certificate revocation lists (periodically issued 
> "hot lists" of revoked certificates, fetched by relying parties) and 
> online certificate status (real time inquiries made by the relying 
> party to the CA or alternative agent).  Each of these mechanisms may 
> be required by the financial services community depending on the 
> circumstances and application.  In particular CRLs are essential for 
> both offline operation and archival information while online status 
> is essential for timely status, large communities, and lightweight 
> client environments.  In combination, these two options provide a solid 
> foundation for meeting the requirements of the financial industry.
> 
I disagree that OCSP is essential for timely status, large communities and
lightweight clients.  It remains to be seen if OCSP can scale to provide
timely status to large communities.  However, our white paper describes how
to meet both requirements using existing CRL structures and the extensions I
mentioned above.  I am also unsure as to whether OCSP can support
lightweight clients.  Remember, certificate revocation status is only one
element in path validation.  Additionally, these lightweight clients won't
exist if they are going to have to process CRLs anyway (as you seem to
imply).

> The current status of products and infrastructure, however, tend to 
> support neither (nor any other alternative) of these mechanism in any 
> consistent, interoperable, deployed manner.  
> 
Again I disagree.  CRLs have been implemented and in use for some time now.

> Consequently, BITS makes 
> the following recommendations:
> 
...Stuff deleted...

I encourage you to read our white paper.  I believe that it might satisfy
your requirements.

Thank you,

	Robert Zuccherato
	Entrust Technologies

------ =_NextPart_000_01BD962D.0820EE34
Content-Type: application/octet-stream;
	name="certrev.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="certrev.pdf"
Content-Description: certrev

------ =_NextPart_000_01BD962D.0820EE34--

Date: Fri, 12 Jun 1998 11:03:33 -0700
To: Carlisle Adams <[email-masked]>, "'Nada Kapidzic Cicovic'" <[email-masked]>
From: Tony Bartoletti <[email-masked]>
Subject: RE: proof-of-possession for DH keys
Cc: [email-masked]
Sender: [email-masked]

At 10:24 AM 6/12/98 -0400, Carlisle Adams wrote:
>Hi Nada,

[Nada writes]

>> For digitalSignature keys, proof of possession does make sense. You need
>> to
>> prove that you have the corresponding private key, so that you cannot get
>> a
>> certificate issued in your name containing someone else's public key.

[Nada continues]

>> However, I somehow fail to see the reason for proving POPO for
>> keyEncipherment and keyAgreement keys. If you request the certification of
>> a keyEncipherment certificate with someone else's public key, I do not see
>> what would you gain by getting it issued in your name.

[Carlisle replies]

>After the signature on a cert. has been verified mathematically; after the
>cert. has been checked for revocation; after the signature and revocation
>status have been checked for all other certs involved in the path; after
>validity periods, key usage bits, policy OIDs, etc., etc., etc., have been
>confirmed to be acceptable, I *still* have to make the fundamental
>assumption that the entity named in the certificate owns the corresponding
>private key.  Otherwise, I have no reason whatsoever to use this certificate
>instead of any other certificate or any bare public key.

Friends,

Is the "key" issue here (sorry about that) that by requiring POP for
encypherment/agreement key certification, one gets authentication "for
free" when message encryption is employed?  Otherwise, a protocol would
require that the encrypted data be, in addition, signed?

___tony___

Tony Bartoletti                                             LL
SPI-NET GURU                                             LL LL
Computer Security Technology Center                   LL LL LL
Lawrence Livermore National Lab                       LL LL LL
PO Box 808, L - 303                                   LL LL LLLLLLLL
Livermore, CA 94551-9900                              LL LLLLLLLL
email: [email-masked]   phone: 510-422-3881             LLLLLLLL

Date: Fri, 12 Jun 1998 09:32:58 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Use of UTF8 in directory strings
Sender: [email-masked]

Passed on from Harald Alvestrand with permission:

>From: [email-masked] 
>X-Internal-ID: 357E1B5E00000666 
>X-Lotus-FromDomain: BULL 
>To: [email-masked] 
>cc: [email-masked], [email-masked] 
>Date: Thu, 11 Jun 1998 01:50:11 -0700 
>Subject: utf8 
> 
>hello all 
> 
>in the phoenix meeting we agreed to support the request from ietf to add 
>utf8 into the choice for directory string. 
> 
>the addition of this has minimal impact on the document, i.e. the one line 
>addition to the choice and supporting text in the conformance clause. 
> 
>i had mentioned that i thought that iso and jtc1 ahd implemented some 
>expedited process minor enhancements. 
> 
>it appears that all we can do is the following 
> 
>1. request a subproject (this can be approved at the sc33 meeting); this a 
>proper subproject of the project that added support for 10646 
> 
>2. request that the text be registed as a final pdam. 
> 
>3. go through one pdam vote and one dam vote (under the new procedures, 
>this is supposed to be a yes/no vote) 
> 
>of course we could consider it in the defect process (although not really a 
>defect, it is a simple alignment to use an additional encoding for the 
>10646 character set. 
> 
>comments? 
> 
> hoyt 
> 
> 
-- 
Harald Tveit Alvestrand, Maxware, Norway 
[email-masked]

From: Carlisle Adams <[email-masked]>
To: "'Nada Kapidzic Cicovic'" <[email-masked]>
Cc: [email-masked]
Subject: RE: proof-of-possession for DH keys
Date: Fri, 12 Jun 1998 10:24:12 -0400
Sender: [email-masked]

Hi Nada,

> ----------
> From: 	Nada Kapidzic Cicovic[SMTP:[email-masked]]
> Sent: 	Friday, June 12, 1998 5:12 AM
> To: 	[email-masked]
> Subject: 	proof-of-possesion for DH keys
> 
> I am not quite clear about the rationale behind mandating POPO for
> keyEncipherment and keyAgreement keys. I wonder if I may get your
> attention
> on this issue.
> 
> For digitalSignature keys, proof of possession does make sense. You need
> to
> prove that you have the corresponding private key, so that you cannot get
> a
> certificate issued in your name containing someone else's public key. If
> you would succeed in that, you could claim that it was you who has signed
> some document that was in reality signed by the actual owner of the
> private
> key (such as a request for patent). This indeed is a real threat and needs
> to be guarded against. 
> 
> However, I somehow fail to see the reason for proving POPO for
> keyEncipherment and keyAgreement keys. If you request the certification of
> a keyEncipherment certificate with someone else's public key, I do not see
> what would you gain by getting it issued in your name. People would
> encrypt
> documents for you by using the public key from the certificate, but you
> will not be able to recover the documents, since you are not in the
> possession of the corresponding private key. Similar logic stands for
> keyAgreement keys.
> 
> Am I missing some point here? Is there some denial of service attack that
> can be made in the latter case? 
> 
There was quite a long thread on this exact topic some time ago, probably
before you joined the list (back when CMP was still called PKIX-3).  The
reasoning here is very simple:  completely irrespective of whether or not
specific attacks exist (denial-of-service, or more serious security
threats), certificates in a PKI only have meaning if the private key
corresponding to the public key in the certificate also belongs to the
entity named in the certificate.

After the signature on a cert. has been verified mathematically; after the
cert. has been checked for revocation; after the signature and revocation
status have been checked for all other certs involved in the path; after
validity periods, key usage bits, policy OIDs, etc., etc., etc., have been
confirmed to be acceptable, I *still* have to make the fundamental
assumption that the entity named in the certificate owns the corresponding
private key.  Otherwise, I have no reason whatsoever to use this certificate
instead of any other certificate or any bare public key.

If I want to encrypt for you, I use the public key in your encryption
certificate because I expect that you will be able to use the corresponding
private key to decrypt.  What causes me to have this expectation?  If we've
never met or exchanged encrypted data before, then the *only* reason to have
this expectation is because I trust your issuing CA to have confirmed that
this is true prior to signing your certificate.  This is why
proof-of-possession (whether in-band or out-of-band) is mandatory for the
certification of all key pairs in CMP.  Certificates are meaningless unless
this is done.

The entire promise of public-key cryptography was that two complete
strangers who had never met or exchanged data before could exchange data
securely.  Without proof-of-possession, this promise falls apart.

--------------------------------------------
Carlisle Adams
Entrust Technologies
[email-masked]
--------------------------------------------

Date: Fri, 12 Jun 1998 10:26:29 -0400
From: "Jessica Hymowitz" <[email-masked]>
To: [email-masked]
Subject: Certificate Revocation
Sender: [email-masked]

From:  Banking Industry Technology Secretariat (BITS)

Financial institutions need to offer new products based on
the latest technology while maintaining ease of use and the
highest level of security.  The Security and Risk Assessment
Working Group of BITS has been addressing this issue.  One
area of concern is the implementation of certificate
revocation in PKI based solutions.

The enclosed "Position Note on Certificate Revocation"
provides guidance on what the BITS financial institutions
would like to see in this arena, namely: core standards and
profiles to promote interoperability, incorporation of these
features within commercial products, and a combined approach
to certificate revocation that includes certificate
revocation lists and online certificate status checking.

If you have any questions or would like more information
please contact Jessica Hymowitz at the BITS office, (202)
289-4322 x240, [email-masked].

BITS position note on Certificate Revocation

One of the essential elements of deploying PKI based solutions 
in the financial services industry is a workable approach to 
certificate revocation.  Certificates may be revoked as a 
consequence of changes in status, changes in subject information, 
real or suspected compromise of keying material, improper actions, 
etc.  Financial institutions require a mechanism for revoking 
certificates that is compatible with the capabilities being built 
into commercial software packages (browsers, servers, email, 
remote access, etc.). 

In the current generation of products which make use of public key 
technology, and in CA products and services, support for revocation 
processing is inconsistent or non-existent.  This creates potential 
risk for web server IDs, secure e-mail, code signing, peer-to-peer 
transactions, and other applications with many relying parties.  In 
these applications, in the event of a compromise, there would be no 
reliable way to inform the community at large.  This problem exists 
no matter how certificate hierarchies and root structures evolve.  In 
order to address this potential security and risk issue, there needs 
to be agreement on core standards and profiles to promote interoperability 
and incorporation of these features within commercial products.

There are currently numerous technical alternatives which have been 
discussed for  handling revocation. Two of the leading options for 
revocation are certificate revocation lists (periodically issued 
"hot lists" of revoked certificates, fetched by relying parties) and 
online certificate status (real time inquiries made by the relying 
party to the CA or alternative agent).  Each of these mechanisms may 
be required by the financial services community depending on the 
circumstances and application.  In particular CRLs are essential for 
both offline operation and archival information while online status 
is essential for timely status, large communities, and lightweight 
client environments.  In combination, these two options provide a solid 
foundation for meeting the requirements of the financial industry.

The current status of products and infrastructure, however, tend to 
support neither (nor any other alternative) of these mechanism in any 
consistent, interoperable, deployed manner.  Consequently, BITS makes 
the following recommendations:
*  CAs (products and services) should support both CRL and online status 
   revocation methods
*  Application products using PK technology (i.e., relying parties) 
   should be capable of processing both CRL and online status revocation 
   methods, depending on configuration and certificate extensions.
*  There should be a single baseline profile (PKIX-1) for v2 CRLs to 
   promote interoperability.  This may be supplemented in individual 
   environments.
*  CRLs should be available via LDAP and application products should be 
   capable of making LDAP requests.
*  There should be a single baseline standard for online certificate 
   status checks (PKIX OCSP).
*  Such a standard should have, at a minimum, the following features:
   -  Signed responses including the time of the response and the 
      identity of the responder
   -  Global, unique identification of target certificates (i.e. no 
      assumed relation between the target certificate and the responder)
   -  Clear status information indicating the data which the responder 
      can authoritatively provide.  Values (not exclusive) should 
      distinguish between Yes, No, Can't answer (policy/technical)
      *  is it revoked (if so, include revocation date and 
         CRL/CRLEntry information)
      *  has it expired
      *  known to be issued
   -  Redirect/Retry messages suggesting an alternative responder or a 
      time to try back
   -  Choice of responder
      *  CA directed (by redirect, extension in the CA certificate, 
         and/or the subject certificate)
      *  User selected
      *  Agent/aggregation
   -  Optional authentication of responder as a valid provider for the 
      information
   -  Extensibility (e.g. for access control, expanded context, payment, 
      authentication)
*  Online status queries should be independent of transport method, but must 
   support operation at least using HTTP.

Date: Fri, 12 Jun 1998 14:01:10 +0200 (MET DST)
To: [email-masked]
From: Jerome Lubrez <[email-masked]>
Subject: subscription
Sender: [email-masked]

subscription
-- 
+-----------------------------------+--------------------------------------+
| CS-TELECOM     Groupe CS          [email-masked]|  
+-----------------------------------+--------------------------------------+
| PoBox 11, Rue de Cambrai          | Site  : La Villette                  |
|       75945 PARIS Cedex 19 FRANCE | Name  : Jerome Lubrez                |
|       Phone : +33 01 44 89 45 00  | Responsable supervision ARTEMIS      |

|       Fax   : +33 01 44 89 45 45  | Phone : +33 01 44 89 48 38           |
+-----------------------------------+--------------------------------------+
--

Date: Fri, 12 Jun 1998 11:12:44 +0200
To: [email-masked]
From: Nada Kapidzic Cicovic <[email-masked]>
Subject: proof-of-possesion for DH keys
Sender: [email-masked]

I am not quite clear about the rationale behind mandating POPO for
keyEncipherment and keyAgreement keys. I wonder if I may get your attention
on this issue.

For digitalSignature keys, proof of possession does make sense. You need to
prove that you have the corresponding private key, so that you cannot get a
certificate issued in your name containing someone else's public key. If
you would succeed in that, you could claim that it was you who has signed
some document that was in reality signed by the actual owner of the private
key (such as a request for patent). This indeed is a real threat and needs
to be guarded against. 

However, I somehow fail to see the reason for proving POPO for
keyEncipherment and keyAgreement keys. If you request the certification of
a keyEncipherment certificate with someone else's public key, I do not see
what would you gain by getting it issued in your name. People would encrypt
documents for you by using the public key from the certificate, but you
will not be able to recover the documents, since you are not in the
possession of the corresponding private key. Similar logic stands for
keyAgreement keys.

Am I missing some point here? Is there some denial of service attack that
can be made in the latter case? 

Regards,

Nada

______________________________________________________________

Nada Kapidzic Cicovic, Ph.D.
Technology Advisor / Systems Architect

Computer Security Technologies CST AB 
(subsidiary of Entegrity Solutions Corporation)
direct: + 46 (0)8 477 77 37
cell:   + 46 (0)70 495 09 03
fax:    + 46 (0)8 477 77 31
e-mail:   [email-masked] or [email-masked]
address:  Finlandsgatan 60, S-164 74 Kista, Sweden

To: IETF-Announce:;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-crmf-01.txt
Date: Wed, 03 Jun 1998 10:24:44 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group 
of the IETF.

	Title		: Internet X.509 Certificate Request Message Format
	Author(s)	: D. Solo, C. Adams, D. Kemp, M. Myers
	Filename	: draft-ietf-pkix-crmf-01.txt
	Pages		: 20
	Date		: 02-Jun-98
	
This document describes the Certificate Request Message Format (CRMF).
This syntax is used to convey a request for a certificate to a
Certification Authority (CA) (possibly via a Registration Authority
(RA)) for the purposes of X.509 certificate production.  The request
will typically include a public key and associated registration
information.

The key words ''MUST'', ''REQUIRED'', ''SHOULD'', ''RECOMMENDED'',
and ''MAY'' in this document (in uppercase, as shown)
are to be interpreted as described in RFC 2119.
 
Please send comments on this document to the [email-masked]
mail list.

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-crmf-01.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-crmf-01.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ftp.ietf.org
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-crmf-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-crmf-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-crmf-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Wed, 10 Jun 1998 19:51:38 -0700 (PDT)
From: 4n6n61 <[email-masked]>
To: <[email-masked]>
Reply-To: [email-masked]
Sender: [email-masked]

Authenticated sender is <[email-masked]>
Subject:  44
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

EMAIL MARKETING WORKS!!

Bull's Eye Gold is the PREMIER email address collection tool.
This program allows you to develop TARGETED lists of email
addresses.  Doctors, florists, MLM, biz opp,...you can collect
anything...you are only limited by your imagination!  You can
even collect email addresses for specific states, cities, and
even countries!  All you need is your web browser and this program.
Our software utilizes the latest in search technology called
"spidering". By simply feeding the spider program a starting
website it will collect for hours. The spider will go from website
to targeted website providing you with thousands upon thousands of
fresh TARGETED email addresses. When you are done collecting,  the
spider removes duplicates and saves the email list in a ready to
send format. No longer is it necessary to send millions of ads to
get a handful of responses...SEND LESS...EARN MORE!!!

A terrific aspect of the Bull's Eye software is that there is
no difficult set up involved and no special technical mumbo-jumbo
to learn. All you need to know is how to search for your targeted
market in one of the many search engines and let the spider do the
rest! Not familiar with the search engines? No problem, we provide
you with a list of all the top search engines. Just surf to the
location of a search engine on your browser then search for the
market you wish to reach...it's that easy!

For instance if you were looking for email addresses of Doctors
in New York all you would do is:

1) Do a search using your favorite search engine by typing in
the words doctor(s) and New York
2) Copy the URL (one or more)...that's the stuff after the
http://...  for instance it might look like
http://www.yahoo.com/?doctor(s)/?New+York
3) Press the START button

THAT's IT!!!  The Bull's Eye spider will go to all the websites
that are linked, automatically extracting the email addresses
you want.

The spider is passive too! That means you can let it run all
day or all night while you are working on important things or
just having fun on your computer. There is no need to keep a
constant watch on it, just feed it your target market and give
it praise when it delivers thousands of email addresses at
the end of the day!

Features of the Bull's Eye Software:

* Does TARGETED searches of websites collecting the email
  addresses you want!
* Collects Email addresses by City, State, even specific
  Countries
* Runs Automatically...simply enter the Starting information,
  press The Start Button, and it does the rest
* Filters out duplicates
* Keeps track of URLs already visited
* Can run 24 hours per day, 7 days per week
* Fast and Easy List Management
* Also has built in filtering options...you can put in words
  that it "Must" have while searching,...you can even put in
  criteria that it  "Must NOT Have"...giving you added flexibility
* Also imports email addresses from any kind of files (text
  files, binary files, database files)
* List editor handles Multiple files to work on many lists
  simultaneously
* Has a Black-Book feature... avoid sending emails to people
  who do not want to receive it
* Built-in Mail program...send email directly on the internet
  with just a click of your mouse
* Personalized Emails...if the email address has the user's
  name when it is collected,..you can send Personalized emails!!!
* Sort by Location, Server, User Name, Contact Name
* Advanced Operations:
· Email address lists export in many different formats
  (HTML, Comma delimited, text file)
· Advanced editing...Transfer, Copy,  Addition, Delete, Crop,
  Move to Top/Bottom
· Operations between lists...Union, Subtraction, Comparison
* Program is Passive,...meaning you can run other programs at
  the same time

CALL FOR MORE INFORMATION   213-969-4930
CALL FOR MORE INFORMATION   213-969-4930

ORDERING INFORMATION

Customer Name
Company Name
Address
City
State                       Zip
Phone                                       Fax
Email Address

______ BULL'S EYE SOFTWARE   $259.00
Includes Software, Instructions, Technical Support

______ Shipping & Handling  (2-3 Day Fedex)  $10.00
                           (Fedex Overnite) $20.00

______  TOTAL
                 (CA Residents add applicable sales tax)

*All orders are for Win 95 and Win NT

                *****CREDIT CARDS ACCEPTED*****
                   MASTERCARD   VISA   AMEX

   PLEASE CALL 213-969-4930 to process your order
                        9am-5pm Pacific Time
                Checks or Money Orders send to:
                      WorldTouch Network Inc.
5670 Wilshire Blvd.  Suite 2170 Los Angeles, CA 90036
Please note:  Allow 5 business days for all checks to
clear before order is shipped.

Date: Wed, 10 Jun 1998 18:03:09 -0700 (PDT)
From: 3rstyhd <[email-masked]>
To: <[email-masked]>
Reply-To: [email-masked]
Sender: [email-masked]

Authenticated sender is <[email-masked]>
Subject:  3  g
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

EMAIL MARKETING WORKS!!

Bull's Eye Gold is the PREMIER email address collection tool.
This program allows you to develop TARGETED lists of email
addresses.  Doctors, florists, MLM, biz opp,...you can collect
anything...you are only limited by your imagination!  You can
even collect email addresses for specific states, cities, and
even countries!  All you need is your web browser and this program.
Our software utilizes the latest in search technology called
"spidering". By simply feeding the spider program a starting
website it will collect for hours. The spider will go from website
to targeted website providing you with thousands upon thousands of
fresh TARGETED email addresses. When you are done collecting,  the
spider removes duplicates and saves the email list in a ready to
send format. No longer is it necessary to send millions of ads to
get a handful of responses...SEND LESS...EARN MORE!!!

A terrific aspect of the Bull's Eye software is that there is
no difficult set up involved and no special technical mumbo-jumbo
to learn. All you need to know is how to search for your targeted
market in one of the many search engines and let the spider do the
rest! Not familiar with the search engines? No problem, we provide
you with a list of all the top search engines. Just surf to the
location of a search engine on your browser then search for the
market you wish to reach...it's that easy!

For instance if you were looking for email addresses of Doctors
in New York all you would do is:

1) Do a search using your favorite search engine by typing in
the words doctor(s) and New York
2) Copy the URL (one or more)...that's the stuff after the
http://...  for instance it might look like
http://www.yahoo.com/?doctor(s)/?New+York
3) Press the START button

THAT's IT!!!  The Bull's Eye spider will go to all the websites
that are linked, automatically extracting the email addresses
you want.

The spider is passive too! That means you can let it run all
day or all night while you are working on important things or
just having fun on your computer. There is no need to keep a
constant watch on it, just feed it your target market and give
it praise when it delivers thousands of email addresses at
the end of the day!

Features of the Bull's Eye Software:

* Does TARGETED searches of websites collecting the email
  addresses you want!
* Collects Email addresses by City, State, even specific
  Countries
* Runs Automatically...simply enter the Starting information,
  press The Start Button, and it does the rest
* Filters out duplicates
* Keeps track of URLs already visited
* Can run 24 hours per day, 7 days per week
* Fast and Easy List Management
* Also has built in filtering options...you can put in words
  that it "Must" have while searching,...you can even put in
  criteria that it  "Must NOT Have"...giving you added flexibility
* Also imports email addresses from any kind of files (text
  files, binary files, database files)
* List editor handles Multiple files to work on many lists
  simultaneously
* Has a Black-Book feature... avoid sending emails to people
  who do not want to receive it
* Built-in Mail program...send email directly on the internet
  with just a click of your mouse
* Personalized Emails...if the email address has the user's
  name when it is collected,..you can send Personalized emails!!!
* Sort by Location, Server, User Name, Contact Name
* Advanced Operations:
· Email address lists export in many different formats
  (HTML, Comma delimited, text file)
· Advanced editing...Transfer, Copy,  Addition, Delete, Crop,
  Move to Top/Bottom
· Operations between lists...Union, Subtraction, Comparison
* Program is Passive,...meaning you can run other programs at
  the same time

CALL FOR MORE INFORMATION   213-969-4930
CALL FOR MORE INFORMATION   213-969-4930

ORDERING INFORMATION

Customer Name
Company Name
Address
City
State                       Zip
Phone                                       Fax
Email Address

______ BULL'S EYE SOFTWARE   $259.00
Includes Software, Instructions, Technical Support

______ Shipping & Handling  (2-3 Day Fedex)  $10.00
                           (Fedex Overnite) $20.00

______  TOTAL
                 (CA Residents add applicable sales tax)

*All orders are for Win 95 and Win NT

                *****CREDIT CARDS ACCEPTED*****
                   MASTERCARD   VISA   AMEX

   PLEASE CALL 213-969-4930 to process your order
                        9am-5pm Pacific Time
                Checks or Money Orders send to:
                      WorldTouch Network Inc.
5670 Wilshire Blvd.  Suite 2170 Los Angeles, CA 90036
Please note:  Allow 5 business days for all checks to
clear before order is shipped.

Date: Wed, 10 Jun 1998 17:19:12 -0400
From: [email-masked] (Yuan John Jiang)
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: DNS and X.501 DistinguishedName
Sender: [email-masked]

>So I can generate an X.509 certificate request from
>the system's domain name or one of it's IP addresses,
>(and I should make that user selectable.)
>
>However, the subjectAltName is specific to an X.509
>certificate request and so I believe I still need
>a way to enter an X.500 distinguished name into the
>system for LDAP services, unless there is a similar
>alternate name construct for LDAP?
>
>/Eric Bomarsi

There is an I-D or RFC by the LDAP working group specifying
using domain names as DNs.

John
>
>Greg Carter wrote:
>> 
>> Hi Eric,
>> 
>> For X.509 (PKCS10 requests or PKIX requests) you should look at the
>> subjectAltName extension.  It allows the certification authority to list a
>> number of alternative names which the entity is associated with.  This list
>> can include name types such as IP Address, DNS, and rfc822 names.  Therefore
>> the network device can have it's DNS and/or IP Address stored in the
>> certificate, while having an X.500 DN that fits the organizations directory
>> structure.
>> 
>> >From X.509
>> 12.3.2.1        Subject alternative name field
>> This field contains one or more alternative names, using any of a variety of
>> name forms, for the entity that is bound by the CA to the certified public
>> key. This field is defined as follows:
>> subjectAltName EXTENSION ::= {
>>         SYNTAX  GeneralNames
>>         IDENTIFIED BY id-ce-subjectAltName }
>> 
>> GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName
>> 
>> GeneralName ::= CHOICE {
>>         otherName                       [0]     INSTANCE OF OTHER-NAME,
>>         rfc822Name                      [1]     IA5String,
>>         dNSName                 [2]     IA5String,
>>         x400Address             [3]     ORAddress,
>>         directoryName           [4]     Name,
>>         ediPartyName            [5]     EDIPartyName,
>>         uniformResourceIdentifier       [6]     IA5String,
>>         iPAddress                       [7]     OCTET STRING,
>>         registeredID                    [8]     OBJECT IDENTIFIER }
>> 
>> OTHER-NAME ::= TYPE-IDENTIFIER
>> 
>> EDIPartyName ::= SEQUENCE {
>>         nameAssigner            [0]     DirectoryString {ub-name} OPTIONAL,
>>         partyName               [1]     DirectoryString {ub-name} }
>> The values in the alternatives of the GeneralName type are names of various
>> forms as follows:
>>         -       otherName is a name of any form defined as an instance of
>> the OTHER-NAME information object class;
>>         -       rfc822Name is an Internet electronic mail address defined in
>> accordance with Internet RFC 822;
>>         -       dNSName is an Internet domain name defined in accordance
>> with Internet RFC 1035;
>>         -       x400Address is an O/R address defined in accordance with
>> ITU-T Rec. X.411 | ISO/IEC 10021-4;
>>         -       directoryName is a directory name defined in accordance with
>> ITU-T Rec. X.501 | ISO/IEC 9594-2;
>>         -       ediPartyName is a name of a form agreed between
>> communicating Electronic Data Interchange partners; the nameAssigner
>> component identifies an authority that assigns unique values of names in the
>> partyName component;
>>         -       uniformResourceIdentifier is a Uniform Resource Identifier
>> for the World-Wide Web defined in accordance with Internet RFC 1630;
>>         -       iPAddress is an Internet Protocol address defined in
>> accordance with Internet RFC 791, represented as a binary string.
>>         -       registeredID is an identifier of any registered object
>> assigned in accordance with ITU-T Rec. X.660 | ISO/IEC 9834-1.
>> For every name form used in the GeneralName type, there shall be a name
>> registration system that ensures that any name used unambiguously identifies
>> one entity to both certificate issuer and certificate users.
>> This extension may, at the option of the certificate issuer, be either
>> critical or non-critical. An implementation which supports this extension is
>> not required to be able to process all name forms. If the extension is
>> flagged critical, at least one of the name forms that is present shall be
>> recognized and processed, otherwise the certificate shall be considered
>> invalid. Apart from the preceding restriction, a certificate-using system is
>> permitted to ignore any name with an unrecognized or unsupported name form.
>> It is recommended that, provided the subject field of the certificate
>> contains a directory name that unambiguously identifies the subject, this
>> field be flagged non-critical.
>> 
>> ----
>> Greg Carter, Entrust Technologies
>> [email-masked]
>> 
>> > ----------
>> > From:         Eric Bomarsi[SMTP:[email-masked]]
>> > Sent:         Tuesday, June 09, 1998 5:39 PM
>> > To:   [email-masked]; [email-masked]; [email-masked]
>> > Subject:      DNS and X.501 DistinguishedName
>> >
>> > A network entity such as a router may require
>> > an X.501 DistinguishedName to utilize LDAP
>> > directory serices or generate PKCS certificate
>> > requests.
>> >
>> > It's possible that the network entity can
>> > use it's domain name to create an X.500
>> > Distinguished Name as specified in RFC2247.
>> > However, I'm concerned that this might be too
>> > inflexible since many organizations may
>> > implement an internal X.500 naming convention
>> > unrelated to their Internet domain naming.
>> >
>> > Has any MIB work been done to support
>> > distinguished name configuration?
>> >
>> > Thanks in advance,
>> > Eric Bomarsi
>> >
>

From: Robert Zuccherato <[email-masked]>
To: "'Ferdinando Ricchiuti'" <[email-masked]>
Cc: [email-masked]
Subject: RE: Time Stamp and "Notary" Drafts
Date: Wed, 10 Jun 1998 16:55:54 -0400
Sender: [email-masked]

Ferdinando;

A nonce is a value used no more that once for the same purpose.  Usually it
is just a random number.  

In the Time Stamp Protocol the requester includes a nonce in the request and
the TSA will copy that value into the response.  The reason for this is so
that the requester can mach the response with the request when the requester
has no local time reference available.

	Robert.

> ----------
> From: 	Ferdinando Ricchiuti[SMTP:[email-masked]]
> Sent: 	Wednesday, June 10, 1998 11:38 AM
> To: 	Robert Zuccherato
> Cc: 	[email-masked]
> Subject: 	Re: Time Stamp and "Notary" Drafts
> 
> Robert Zuccherato wrote:
> > 
> > New versions of the Time Stamp and Notary drafts are now available.
> They
> > have again been submitted as independent drafts, since the PKIX charter
> > still does not include these topics.
> > [...]
> 
> Hello,
> 
> In the Time Stamp Protocols draft, has been introduced a new 
> field in the TimeStampRequest message: "nonce".
> 
> What it mean? 
> 
> Thanks!
> -- 
> +-------------------------------------------------------------------+
> | Ferdinando Ricchiuti                     Computer Science Student |
> +--------------------------------+----------------------------------+
> | Politecnico di Torino          | phone:  +39-(0)11-5647090        |
> | Dip. Automatica e Informatica  | fax:                             |
> | corso Duca degli Abruzzi, 24   | e-mail: [email-masked] | 
> | 10129 Torino                   |                                  |
> | ITALY                          | http://www.polito.it/~fricchi/   | 
> +--------------------------------+----------------------------------+
> 

From: Peter Whittaker <[email-masked]>
To: "'Eric Bomarsi'" <[email-masked]>, Greg Carter <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: RE: DNS and X.501 DistinguishedName
Date: Wed, 10 Jun 1998 14:43:52 -0400
Sender: [email-masked]

This is a Multipart MIME message
----=_NextPart_STJ_36039280.897504323
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="--=_NextPart_STJ_35994560.897504320"

This is a Multipart MIME message
----=_NextPart_STJ_35994560.897504320
Content-Type: multipart/alternative;
	boundary="--=_NextPart_STJ_36019408.897504320"

----=_NextPart_STJ_36019408.897504320
Content-Type: text/richtext;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

=7B=5Crtf1=5Cansi=5Cansicpg1252=5Cfromtext =5Cdeff0=7B=5Cfonttbl
=7B=5Cf0=5Cfswiss Arial;=7D
=7B=5Cf1=5Cfmodern Courier New;=7D
=7B=5Cf2=5Cfnil=5Cfcharset2 Symbol;=7D
=7B=5Cf3=5Cfmodern=5Cfcharset0 Courier New;=7D=7D
=7B=5Ccolortbl=5Cred0=5Cgreen0=5Cblue0;=5Cred0=5Cgreen0=5Cblue255;=7D
=5Cuc1=5Cpard=5Cplain=5Cdeftab360 =5Cf0=5Cfs20=5Ccf0 In your original note, you=
 questioned the use of RFC 2247 naming scheme, as organizations might choose to use some=
 other naming scheme in their directory.  Greg's suggestion allows you to accomodate a=
ny organization's naming scheme, with the data of interest to the devices/applicatio=
ns in question being located elsewhere than the DN (it may be there also, but devices/ap=
plications need not depend on being there). =5Cpar
=5Cpar
A device's certificate will contain its IP address or hostname in the subjectAltName e=
xtension, and may contain its DN in the subject field.  If these certificates are writt=
en to and retrieved from the directory, they will (likely) be in the entry whose DN is the=
 subject DN in the certificate.=5Cpar
=5Cpar
You're right that if you are using a directory and expecting to be able to store/retriev=
e certificates in/from it, you will need to generate DNs for your routers.  The subject=
AltName extension allows you do so within the bounds of your existing naming scheme/pr=
eferences, while retaining in the certificate information most likely to be useful fo=
r network devices.  In general, extensions such as subjectAltName are a very useful pl=
ace to put such data.=5Cpar
=5Cpar
Note too that the subject and issuer fields in X.509 certificates can be empty.  The PKI=
X group has profiled the use of empty issuer and subject names to allow for those cases wh=
ere directories are not involved.=5Cpar
=5Cpar
pww=5Cpar
=5Cpar
Peter Whittaker=5Cpar
Entrust Technologies=5Cpar
http://www.entrust.com=5Cpar
=5Cpar
=5Cpar
=5Cpar
> -----Original Message-----=5Cpar
> From: Eric Bomarsi =5Bmailto:ebomarsi=40xedia.com=5D=5Cpar
> Sent: Wednesday, June 10, 1998 2:16 PM=5Cpar
> To: Greg Carter=5Cpar
> Cc: ietf-lsd=40listserv.umu.se; ipsec=40tis.com; ietf-pkix=40imc.org=5Cpar
> Subject: Re: DNS and X.501 DistinguishedName=5Cpar
> =5Cpar
> =5Cpar
> Thanks Greg,=5Cpar
> =5Cpar
> I see. =5Cpar
> =5Cpar
> So I can generate an X.509 certificate request from=5Cpar
> the system's domain name or one of it's IP addresses,=5Cpar
> (and I should make that user selectable.)=5Cpar
> =5Cpar
> However, the subjectAltName is specific to an X.509=5Cpar
> certificate request and so I believe I still need=5Cpar
> a way to enter an X.500 distinguished name into the=5Cpar
> system for LDAP services, unless there is a similar=5Cpar
> alternate name construct for LDAP?=5Cpar
> =5Cpar
> /Eric Bomarsi=5Cpar
> =5Cpar
> Greg Carter wrote:=5Cpar
> > =5Cpar
> > Hi Eric,=5Cpar
> > =5Cpar
> > For X.509 (PKCS10 requests or PKIX requests) you should look at the=5Cpar
> > subjectAltName extension.  It allows the certification =5Cpar
> authority to list a=5Cpar
> > number of alternative names which the entity is associated =5Cpar
> with.  This list=5Cpar
> > can include name types such as IP Address, DNS, and rfc822 =5Cpar
> names.  Therefore=5Cpar
> > the network device can have it's DNS and/or IP Address stored in the=5Cpar
> > certificate, while having an X.500 DN that fits the =5Cpar
> organizations directory=5Cpar
> > structure.=5Cpar
> > =5Cpar
> > >From X.509=5Cpar
> > 12.3.2.1        Subject alternative name field=5Cpar
> > This field contains one or more alternative names, using =5Cpar
> any of a variety of=5Cpar
> > name forms, for the entity that is bound by the CA to the =5Cpar
> certified public=5Cpar
> > key. This field is defined as follows:=5Cpar
> > subjectAltName EXTENSION ::=3D =5C=7B=5Cpar
> >         SYNTAX  GeneralNames=5Cpar
> >         IDENTIFIED BY id-ce-subjectAltName =5C=7D=5Cpar
> > =5Cpar
> > GeneralNames ::=3D SEQUENCE SIZE (1..MAX) OF GeneralName=5Cpar
> > =5Cpar
> > GeneralName ::=3D CHOICE =5C=7B=5Cpar
> >         otherName                       =5B0=5D     INSTANCE OF =5Cpar
> OTHER-NAME,=5Cpar
> >         rfc822Name                      =5B1=5D     IA5String,=5Cpar
> >         dNSName                 =5B2=5D     IA5String,=5Cpar
> >         x400Address             =5B3=5D     ORAddress,=5Cpar
> >         directoryName           =5B4=5D     Name,=5Cpar
> >         ediPartyName            =5B5=5D     EDIPartyName,=5Cpar
> >         uniformResourceIdentifier       =5B6=5D     IA5String,=5Cpar
> >         iPAddress                       =5B7=5D     OCTET STRING,=5Cpar
> >         registeredID                    =5B8=5D     OBJECT IDENTIFIER =5C=7D=
=5Cpar
> > =5Cpar
> > OTHER-NAME ::=3D TYPE-IDENTIFIER=5Cpar
> > =5Cpar
> > EDIPartyName ::=3D SEQUENCE =5C=7B=5Cpar
> >         nameAssigner            =5B0=5D     DirectoryString =5Cpar
> =5C=7Bub-name=5C=7D OPTIONAL,=5Cpar
> >         partyName               =5B1=5D     DirectoryString =5C=7Bub-name=5C=
=7D =5C=7D=5Cpar
> > The values in the alternatives of the GeneralName type are =5Cpar
> names of various=5Cpar
> > forms as follows:=5Cpar
> >         -       otherName is a name of any form defined as =5Cpar
> an instance of=5Cpar
> > the OTHER-NAME information object class;=5Cpar
> >         -       rfc822Name is an Internet electronic mail =5Cpar
> address defined in=5Cpar
> > accordance with Internet RFC 822;=5Cpar
> >         -       dNSName is an Internet domain name defined =5Cpar
> in accordance=5Cpar
> > with Internet RFC 1035;=5Cpar
> >         -       x400Address is an O/R address defined in =5Cpar
> accordance with=5Cpar
> > ITU-T Rec. X.411 =7C ISO/IEC 10021-4;=5Cpar
> >         -       directoryName is a directory name defined =5Cpar
> in accordance with=5Cpar
> > ITU-T Rec. X.501 =7C ISO/IEC 9594-2;=5Cpar
> >         -       ediPartyName is a name of a form agreed between=5Cpar
> > communicating Electronic Data Interchange partners; the nameAssigner=5Cpar
> > component identifies an authority that assigns unique =5Cpar
> values of names in the=5Cpar
> > partyName component;=5Cpar
> >         -       uniformResourceIdentifier is a Uniform =5Cpar
> Resource Identifier=5Cpar
> > for the World-Wide Web defined in accordance with Internet RFC 1630;=5Cpar
> >         -       iPAddress is an Internet Protocol address defined in=5Cpar
> > accordance with Internet RFC 791, represented as a binary string.=5Cpar
> >         -       registeredID is an identifier of any =5Cpar
> registered object=5Cpar
> > assigned in accordance with ITU-T Rec. X.660 =7C ISO/IEC 9834-1.=5Cpar
> > For every name form used in the GeneralName type, there =5Cpar
> shall be a name=5Cpar
> > registration system that ensures that any name used =5Cpar
> unambiguously identifies=5Cpar
> > one entity to both certificate issuer and certificate users.=5Cpar
> > This extension may, at the option of the certificate =5Cpar
> issuer, be either=5Cpar
> > critical or non-critical. An implementation which supports =5Cpar
> this extension is=5Cpar
> > not required to be able to process all name forms. If the =5Cpar
> extension is=5Cpar
> > flagged critical, at least one of the name forms that is =5Cpar
> present shall be=5Cpar
> > recognized and processed, otherwise the certificate shall =5Cpar
> be considered=5Cpar
> > invalid. Apart from the preceding restriction, a =5Cpar
> certificate-using system is=5Cpar
> > permitted to ignore any name with an unrecognized or =5Cpar
> unsupported name form.=5Cpar
> > It is recommended that, provided the subject field of the =5Cpar
> certificate=5Cpar
> > contains a directory name that unambiguously identifies the =5Cpar
> subject, this=5Cpar
> > field be flagged non-critical.=5Cpar
> > =5Cpar
> > ----=5Cpar
> > Greg Carter, Entrust Technologies=5Cpar
> > greg.carter=40entrust.com=5Cpar
> > =5Cpar
> > > ----------=5Cpar
> > > From:         Eric Bomarsi=5BSMTP:ebomarsi=40xedia.com=5D=5Cpar
> > > Sent:         Tuesday, June 09, 1998 5:39 PM=5Cpar
> > > To:   ietf-lsd=40listserv.umu.se; ipsec=40tis.com; spki=40c2.net=5Cpar
> > > Subject:      DNS and X.501 DistinguishedName=5Cpar
> > >=5Cpar
> > > A network entity such as a router may require=5Cpar
> > > an X.501 DistinguishedName to utilize LDAP=5Cpar
> > > directory serices or generate PKCS certificate=5Cpar
> > > requests.=5Cpar
> > >=5Cpar
> > > It's possible that the network entity can=5Cpar
> > > use it's domain name to create an X.500=5Cpar
> > > Distinguished Name as specified in RFC2247.=5Cpar
> > > However, I'm concerned that this might be too=5Cpar
> > > inflexible since many organizations may=5Cpar
> > > implement an internal X.500 naming convention=5Cpar
> > > unrelated to their Internet domain naming.=5Cpar
> > >=5Cpar
> > > Has any MIB work been done to support=5Cpar
> > > distinguished name configuration?=5Cpar
> > >=5Cpar
> > > Thanks in advance,=5Cpar
> > > Eric Bomarsi=5Cpar
> > >=5Cpar
> =5Cpar
=7D
----=_NextPart_STJ_36019408.897504320
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

In your original note, you questioned the use of RFC 2247 naming scheme, as organizatio=
ns might choose to use some other naming scheme in their directory.  Greg's suggestion=
 allows you to accomodate any organization's naming scheme, with the data of interest t=
o the devices/applications in question being located elsewhere than the DN (it may be t=
here also, but devices/applications need not depend on being there).=20

A device's certificate will contain its IP address or hostname in the subjectAltName e=
xtension, and may contain its DN in the subject field.  If these certificates are writt=
en to and retrieved from the directory, they will (likely) be in the entry whose DN is the=
 subject DN in the certificate.

You're right that if you are using a directory and expecting to be able to store/retriev=
e certificates in/from it, you will need to generate DNs for your routers.  The subject=
AltName extension allows you do so within the bounds of your existing naming scheme/pr=
eferences, while retaining in the certificate information most likely to be useful fo=
r network devices.  In general, extensions such as subjectAltName are a very useful pl=
ace to put such data.

Note too that the subject and issuer fields in X.509 certificates can be empty.  The PKI=
X group has profiled the use of empty issuer and subject names to allow for those cases wh=
ere directories are not involved.

pww

Peter Whittaker
Entrust Technologies
http://www.entrust.com

> -----Original Message-----
> From: Eric Bomarsi =5Bmailto:ebomarsi=40xedia.com=5D
> Sent: Wednesday, June 10, 1998 2:16 PM
> To: Greg Carter
> Cc: ietf-lsd=40listserv.umu.se; ipsec=40tis.com; ietf-pkix=40imc.org
> Subject: Re: DNS and X.501 DistinguishedName
>=20
>=20
> Thanks Greg,
>=20
> I see.=20
>=20
> So I can generate an X.509 certificate request from
> the system's domain name or one of it's IP addresses,
> (and I should make that user selectable.)
>=20
> However, the subjectAltName is specific to an X.509
> certificate request and so I believe I still need
> a way to enter an X.500 distinguished name into the
> system for LDAP services, unless there is a similar
> alternate name construct for LDAP?
>=20
> /Eric Bomarsi
>=20
> Greg Carter wrote:
> >=20
> > Hi Eric,
> >=20
> > For X.509 (PKCS10 requests or PKIX requests) you should look at the
> > subjectAltName extension.  It allows the certification=20
> authority to list a
> > number of alternative names which the entity is associated=20
> with.  This list
> > can include name types such as IP Address, DNS, and rfc822=20
> names.  Therefore
> > the network device can have it's DNS and/or IP Address stored in the
> > certificate, while having an X.500 DN that fits the=20
> organizations directory
> > structure.
> >=20
> > >From X.509
> > 12.3.2.1        Subject alternative name field
> > This field contains one or more alternative names, using=20
> any of a variety of
> > name forms, for the entity that is bound by the CA to the=20
> certified public
> > key. This field is defined as follows:
> > subjectAltName EXTENSION ::=3D =7B
> >         SYNTAX  GeneralNames
> >         IDENTIFIED BY id-ce-subjectAltName =7D
> >=20
> > GeneralNames ::=3D SEQUENCE SIZE (1..MAX) OF GeneralName
> >=20
> > GeneralName ::=3D CHOICE =7B
> >         otherName                       =5B0=5D     INSTANCE OF=20
> OTHER-NAME,
> >         rfc822Name                      =5B1=5D     IA5String,
> >         dNSName                 =5B2=5D     IA5String,
> >         x400Address             =5B3=5D     ORAddress,
> >         directoryName           =5B4=5D     Name,
> >         ediPartyName            =5B5=5D     EDIPartyName,
> >         uniformResourceIdentifier       =5B6=5D     IA5String,
> >         iPAddress                       =5B7=5D     OCTET STRING,
> >         registeredID                    =5B8=5D     OBJECT IDENTIFIER =7D
> >=20
> > OTHER-NAME ::=3D TYPE-IDENTIFIER
> >=20
> > EDIPartyName ::=3D SEQUENCE =7B
> >         nameAssigner            =5B0=5D     DirectoryString=20
> =7Bub-name=7D OPTIONAL,
> >         partyName               =5B1=5D     DirectoryString =7Bub-name=7D =7D=

> > The values in the alternatives of the GeneralName type are=20
> names of various
> > forms as follows:
> >         -       otherName is a name of any form defined as=20
> an instance of
> > the OTHER-NAME information object class;
> >         -       rfc822Name is an Internet electronic mail=20
> address defined in
> > accordance with Internet RFC 822;
> >         -       dNSName is an Internet domain name defined=20
> in accordance
> > with Internet RFC 1035;
> >         -       x400Address is an O/R address defined in=20
> accordance with
> > ITU-T Rec. X.411 =7C ISO/IEC 10021-4;
> >         -       directoryName is a directory name defined=20
> in accordance with
> > ITU-T Rec. X.501 =7C ISO/IEC 9594-2;
> >         -       ediPartyName is a name of a form agreed between
> > communicating Electronic Data Interchange partners; the nameAssigner
> > component identifies an authority that assigns unique=20
> values of names in the
> > partyName component;
> >         -       uniformResourceIdentifier is a Uniform=20
> Resource Identifier
> > for the World-Wide Web defined in accordance with Internet RFC 1630;
> >         -       iPAddress is an Internet Protocol address defined in
> > accordance with Internet RFC 791, represented as a binary string.
> >         -       registeredID is an identifier of any=20
> registered object
> > assigned in accordance with ITU-T Rec. X.660 =7C ISO/IEC 9834-1.
> > For every name form used in the GeneralName type, there=20
> shall be a name
> > registration system that ensures that any name used=20
> unambiguously identifies
> > one entity to both certificate issuer and certificate users.
> > This extension may, at the option of the certificate=20
> issuer, be either
> > critical or non-critical. An implementation which supports=20
> this extension is
> > not required to be able to process all name forms. If the=20
> extension is
> > flagged critical, at least one of the name forms that is=20
> present shall be
> > recognized and processed, otherwise the certificate shall=20
> be considered
> > invalid. Apart from the preceding restriction, a=20
> certificate-using system is
> > permitted to ignore any name with an unrecognized or=20
> unsupported name form.
> > It is recommended that, provided the subject field of the=20
> certificate
> > contains a directory name that unambiguously identifies the=20
> subject, this
> > field be flagged non-critical.
> >=20
> > ----
> > Greg Carter, Entrust Technologies
> > greg.carter=40entrust.com
> >=20
> > > ----------
> > > From:         Eric Bomarsi=5BSMTP:ebomarsi=40xedia.com=5D
> > > Sent:         Tuesday, June 09, 1998 5:39 PM
> > > To:   ietf-lsd=40listserv.umu.se; ipsec=40tis.com; spki=40c2.net
> > > Subject:      DNS and X.501 DistinguishedName
> > >
> > > A network entity such as a router may require
> > > an X.501 DistinguishedName to utilize LDAP
> > > directory serices or generate PKCS certificate
> > > requests.
> > >
> > > It's possible that the network entity can
> > > use it's domain name to create an X.500
> > > Distinguished Name as specified in RFC2247.
> > > However, I'm concerned that this might be too
> > > inflexible since many organizations may
> > > implement an internal X.500 naming convention
> > > unrelated to their Internet domain naming.
> > >
> > > Has any MIB work been done to support
> > > distinguished name configuration?
> > >
> > > Thanks in advance,
> > > Eric Bomarsi
> > >
>=20

----=_NextPart_STJ_36019408.897504320--

----=_NextPart_STJ_35994560.897504320
Content-Type: application/octet-stream;
	name="%-1%Peter Whittaker (E-mail).vcf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="%-1%Peter Whittaker (E-mail).vcf"

----=_NextPart_STJ_35994560.897504320--

Protected with Entrust Express and S/MIME

----=_NextPart_STJ_36039280.897504323
Content-Type: application/x-pkcs7-signature;
	protocol="application/x-pkcs7-signature";
	micalg="sha1";
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

----=_NextPart_STJ_36039280.897504323--

Protected with Entrust Express and S/MIME

Date: Wed, 10 Jun 1998 14:15:45 -0400
From: Eric Bomarsi <[email-masked]>
Organization: xedia.com
To: Greg Carter <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: DNS and X.501 DistinguishedName
Sender: [email-masked]

Thanks Greg,

I see. 

So I can generate an X.509 certificate request from
the system's domain name or one of it's IP addresses,
(and I should make that user selectable.)

However, the subjectAltName is specific to an X.509
certificate request and so I believe I still need
a way to enter an X.500 distinguished name into the
system for LDAP services, unless there is a similar
alternate name construct for LDAP?

/Eric Bomarsi

Greg Carter wrote:
> 
> Hi Eric,
> 
> For X.509 (PKCS10 requests or PKIX requests) you should look at the
> subjectAltName extension.  It allows the certification authority to list a
> number of alternative names which the entity is associated with.  This list
> can include name types such as IP Address, DNS, and rfc822 names.  Therefore
> the network device can have it's DNS and/or IP Address stored in the
> certificate, while having an X.500 DN that fits the organizations directory
> structure.
> 
> >From X.509
> 12.3.2.1        Subject alternative name field
> This field contains one or more alternative names, using any of a variety of
> name forms, for the entity that is bound by the CA to the certified public
> key. This field is defined as follows:
> subjectAltName EXTENSION ::= {
>         SYNTAX  GeneralNames
>         IDENTIFIED BY id-ce-subjectAltName }
> 
> GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName
> 
> GeneralName ::= CHOICE {
>         otherName                       [0]     INSTANCE OF OTHER-NAME,
>         rfc822Name                      [1]     IA5String,
>         dNSName                 [2]     IA5String,
>         x400Address             [3]     ORAddress,
>         directoryName           [4]     Name,
>         ediPartyName            [5]     EDIPartyName,
>         uniformResourceIdentifier       [6]     IA5String,
>         iPAddress                       [7]     OCTET STRING,
>         registeredID                    [8]     OBJECT IDENTIFIER }
> 
> OTHER-NAME ::= TYPE-IDENTIFIER
> 
> EDIPartyName ::= SEQUENCE {
>         nameAssigner            [0]     DirectoryString {ub-name} OPTIONAL,
>         partyName               [1]     DirectoryString {ub-name} }
> The values in the alternatives of the GeneralName type are names of various
> forms as follows:
>         -       otherName is a name of any form defined as an instance of
> the OTHER-NAME information object class;
>         -       rfc822Name is an Internet electronic mail address defined in
> accordance with Internet RFC 822;
>         -       dNSName is an Internet domain name defined in accordance
> with Internet RFC 1035;
>         -       x400Address is an O/R address defined in accordance with
> ITU-T Rec. X.411 | ISO/IEC 10021-4;
>         -       directoryName is a directory name defined in accordance with
> ITU-T Rec. X.501 | ISO/IEC 9594-2;
>         -       ediPartyName is a name of a form agreed between
> communicating Electronic Data Interchange partners; the nameAssigner
> component identifies an authority that assigns unique values of names in the
> partyName component;
>         -       uniformResourceIdentifier is a Uniform Resource Identifier
> for the World-Wide Web defined in accordance with Internet RFC 1630;
>         -       iPAddress is an Internet Protocol address defined in
> accordance with Internet RFC 791, represented as a binary string.
>         -       registeredID is an identifier of any registered object
> assigned in accordance with ITU-T Rec. X.660 | ISO/IEC 9834-1.
> For every name form used in the GeneralName type, there shall be a name
> registration system that ensures that any name used unambiguously identifies
> one entity to both certificate issuer and certificate users.
> This extension may, at the option of the certificate issuer, be either
> critical or non-critical. An implementation which supports this extension is
> not required to be able to process all name forms. If the extension is
> flagged critical, at least one of the name forms that is present shall be
> recognized and processed, otherwise the certificate shall be considered
> invalid. Apart from the preceding restriction, a certificate-using system is
> permitted to ignore any name with an unrecognized or unsupported name form.
> It is recommended that, provided the subject field of the certificate
> contains a directory name that unambiguously identifies the subject, this
> field be flagged non-critical.
> 
> ----
> Greg Carter, Entrust Technologies
> [email-masked]
> 
> > ----------
> > From:         Eric Bomarsi[SMTP:[email-masked]]
> > Sent:         Tuesday, June 09, 1998 5:39 PM
> > To:   [email-masked]; [email-masked]; [email-masked]
> > Subject:      DNS and X.501 DistinguishedName
> >
> > A network entity such as a router may require
> > an X.501 DistinguishedName to utilize LDAP
> > directory serices or generate PKCS certificate
> > requests.
> >
> > It's possible that the network entity can
> > use it's domain name to create an X.500
> > Distinguished Name as specified in RFC2247.
> > However, I'm concerned that this might be too
> > inflexible since many organizations may
> > implement an internal X.500 naming convention
> > unrelated to their Internet domain naming.
> >
> > Has any MIB work been done to support
> > distinguished name configuration?
> >
> > Thanks in advance,
> > Eric Bomarsi
> >

Date: Wed, 10 Jun 1998 17:38:20 +0200
From: Ferdinando Ricchiuti <[email-masked]>
To: Robert Zuccherato <[email-masked]>
Cc: [email-masked]
Subject: Re: Time Stamp and "Notary" Drafts
Sender: [email-masked]

Robert Zuccherato wrote:
> 
> New versions of the Time Stamp and Notary drafts are now available.  They
> have again been submitted as independent drafts, since the PKIX charter
> still does not include these topics.
> [...]

Hello,

In the Time Stamp Protocols draft, has been introduced a new 
field in the TimeStampRequest message: "nonce".

What it mean? 

Thanks!
-- 
+-------------------------------------------------------------------+
| Ferdinando Ricchiuti                     Computer Science Student |
+--------------------------------+----------------------------------+
| Politecnico di Torino          | phone:  +39-(0)11-5647090        |
| Dip. Automatica e Informatica  | fax:                             |
| corso Duca degli Abruzzi, 24   | e-mail: [email-masked] | 
| 10129 Torino                   |                                  |
| ITALY                          | http://www.polito.it/~fricchi/   | 
+--------------------------------+----------------------------------+

Date: Wed, 10 Jun 1998 10:54:40 +0200
From: Antonio Lioy <[email-masked]>
Organization: Politecnico di Torino
To: [email-masked]
Subject: Re: Time Stamp and "Notary" Drafts
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms578F748BB1C75D0272ABBA1A
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Robert Zuccherato wrote:
> 
> New versions of the Time Stamp and Notary drafts are now available.  They
> have again been submitted as independent drafts, since the PKIX charter
> still does not include these topics.

We are setting up a time-stamp and notary server. We already
developed them according to the old PKIX drafts and will now modify
the code to accomodate the new drafts.

Is there anybody else that has (or is going to) set up similar
servers? we wish to perform interoperability checks.

Antonio Lioy
Politecnico di Torino
Computer & Network Security Group (http://security.polito.it)
--------------ms578F748BB1C75D0272ABBA1A
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms578F748BB1C75D0272ABBA1A--

From: "Fillingham,  David W." <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "'Bob Jueneman'" <[email-masked]>
Subject: RE: Extensibility in definitions
Date: Tue, 9 Jun 1998 13:24:29 -0400
Sender: [email-masked]

The "Security Policy Information File" (SPIF), is documented in SDN.801,
an older version of which can be found on:

http://www.armadillo.huntsville.al.us/Fortezza_docs/missi2.html#specs

The newest version of SDN.801 replaced the older "PRBAC Information
File" term with the newer "Security Policy Information File" name and
syntax.

The SPIF is a signed file that conveys the semantics of an access
control policy (e.g., the following classifications exist, they are
represented with these bits and integers, the following security
categories exist, they are represented with these other bits and
integers, these categories are "permissive," these other ones are
"restrictive," and you can't assert this category unless you also assert
those other ones, and so on.)

Dave Fillingham

>----------
>From: 	Bob Jueneman[SMTP:[email-masked]]
>Sent: 	Monday, June 08, 1998 1:14 PM
>To: 	[email-masked]; [email-masked]
>Subject: 	Re: Extensibility in definitions
>
>the Secuity Parameter Information File concept sounds interesting.  Is it
>going to be available soon?
>
>Bob
>
>>>> David P. Kemp <[email-masked]> 06/08 10:09 AM >>>
>From: "Balluffi, Frank" <[email-masked]>
>
>> Modifications to named BIT STRINGs and ENUMERATED types require
>> recompilation of the ASN.1.
>
>
>and From: "Bob Jueneman" <[email-masked]>
>> 
>> Clearly we don't want to recompile every piece of software
>> in the world just because someone makes a minor change to
>> clarify the semantic definition of some attribute, or defines a new
>> but compatible bit within a previously reserved field.
>> 
>> The extendedKeyUsage attribute gets around this problem by
>> defining an attribute that contains other attributes identified by
>> their own OID, but the result is cumbersome and space inefficient.
>> 
>> X.500 provides a means of distributing the syntax of new attributes
>> by registering them in the directory. Unfortunately, until we have lots
>> of software that support dynamic assignment of ASN.1 attributes, 
>> that isn't much help.  And what we _really_ need is some way of 
>> automatically updating the _semantics_ of these attributes, which
>> all too often are spell out in too-terse comments to the ASN.1, if 
>> at all.
>
>
>The obvious alternative to static (compile time) assignment is dynamic
>assignment using an interpreter or on-the-fly compiler.  If named BIT
>STRINGs and ENUMERATED types are required by X.680 to be implemented
>only in a static compilation environment (I don't believe any such
>restriction exists), then a reasonable alternative is to use normal BIT
>STRINGs and INTEGERs whose meaning is bound at runtime.  This avoids
>alternative of expanding each BIT out into it's own OID which, as Bob
>says, is cumbersome and space inefficient.  OIDs should be used for
>their intended purpose - object definition collision avoidance -
>not as a replacement for the data elements comprising an object.
>
>And as it turns out, Sandi and others are working on just such a
>scheme - the "Security Parameter Information File" (SPIF) which
>is interpreted at runtime (and signed by an Authority to prevent
>tampering).
>
>The same configuration management issues exist whether you use static
>or dynamic assignment - you don't want anything defined in the future
>to conflict with or modify the meaning of currently-defined bits.
>The SPIF uses a single OID to specify a security policy under which
>the bits are interpreted - compatible additions can be made under the
>same policy, but incompatible changes require a new policy OID.
>
>

From: Robert Zuccherato <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Time Stamp and "Notary" Drafts
Date: Tue, 9 Jun 1998 09:12:55 -0400 
Sender: [email-masked]

New versions of the Time Stamp and Notary drafts are now available.  They
have again been submitted as independent drafts, since the PKIX charter
still does not include these topics.

The Time Stamp Protocols draft is available at:
ftp://ftp.ietf.org/internet-drafts/draft-adams-time-stamp-02.txt
Some of the changes include:
-removal of requester name and TSA name from time stamp requests
-inclusion of tsaFreeData field in response to hold supplementary (e.g.
billing) information
-inclusion of section listing possibly relevant patents

The "Notary" draft and protocol has been renamed.  It became apparent at the
PKIX meetings that calling this protocol a "Notary" protocol caused some
confusion about the purpose of the "Notary" and the functions that it was
supposed to perform.  We have renamed it the Data Certification Server.  We
feel that this name is a little bit more descriptive of what this server
does.  It certifies data for later use in support of non-repudiation.
The Data Certification Server draft is available at:
ftp://ftp.ietf.org/internet-drafts/draft-adams-dcs-00.txt
Some of the changes include:
-extension capability included in both request and responses
-allows validation of multiple target certificates each with associated
trust chains
-improved support for certificate path validation
-inclusion of section listing possibly relevant patents

As always, comments are welcome.

	Robert Zuccherato.

Date: Mon, 08 Jun 1998 13:39:00 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: Certificate transport encoding question
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Peter:

PKCS#7 version 1.5 does not constrain the ordering of the certificates, so
the recipient must be prepared for the worst possible haphazard ordering.
CMS has a backward comparability goal, so we get this feature too.

Russ

At 05:10 AM 6/6/98 +0000, Peter Gutmann wrote:
>I've got two questions about certificate encoding in transport formats, I've 
>sent them to both lists since they're a bit nonspecific.
> 
>The first one concerns the order of certs in a cert chain.  Looking at the
CMS 
>spec, it says that the SET OF Certificate should contain chains from the
root 
>down to each required subject, but doesn't give any explicit ordering.  An 
>ASN.1 SET is inherently unordered, but is there any recommended, consistent 
>way to encode a cert chain, or do you just add them in whatever order you
feel 
>like?  So far I've seen them ordered from subject to root, from root to 
>subject, and pseudorandomly (using the DER SET encoding rules)... all of
these 
>are equally valid, it just seems messy to have any number of possible 
>orderings present.
> 
>The second one concerns something which isn't explicitly addressed by any 
>standard but which it might be worth covering somewhere.  When a certificate 
>or cert-related object (cert request, CRL) is base64-encoded, there are
again 
>a large number of different interpretations on what delimiters to use around 
>the base64 data.  I've seen BEGIN CERTIFICATE, BEGIN CERTIFICATE REQUEST, 
>BEGIN NEW CERTIFICATE REQUEST, BEGIN PGP MESS...no hang on, that's something 
>else :-).  Alongside these are various creative mutations (extra blank
lines, 
>name:value pairs a la PGP, and other oddities).  It's probably a good idea
to 
>specify a set format for these as well and attach them to some existing 
>standard.  If there's a need for them I'll put together a paragraph or two 
>defining the exact format.
> 
>Peter.
> 

Date: Mon, 08 Jun 1998 11:14:57 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Extensibility in definitions
Sender: [email-masked]

the Secuity Parameter Information File concept sounds interesting.  Is it going to be available soon?

Bob

>>> David P. Kemp <[email-masked]> 06/08 10:09 AM >>>
From: "Balluffi, Frank" <[email-masked]>

> Modifications to named BIT STRINGs and ENUMERATED types require
> recompilation of the ASN.1.

and From: "Bob Jueneman" <[email-masked]>
> 
> Clearly we don't want to recompile every piece of software
> in the world just because someone makes a minor change to
> clarify the semantic definition of some attribute, or defines a new
> but compatible bit within a previously reserved field.
> 
> The extendedKeyUsage attribute gets around this problem by
> defining an attribute that contains other attributes identified by
> their own OID, but the result is cumbersome and space inefficient.
> 
> X.500 provides a means of distributing the syntax of new attributes
> by registering them in the directory. Unfortunately, until we have lots
> of software that support dynamic assignment of ASN.1 attributes, 
> that isn't much help.  And what we _really_ need is some way of 
> automatically updating the _semantics_ of these attributes, which
> all too often are spell out in too-terse comments to the ASN.1, if 
> at all.

The obvious alternative to static (compile time) assignment is dynamic
assignment using an interpreter or on-the-fly compiler.  If named BIT
STRINGs and ENUMERATED types are required by X.680 to be implemented
only in a static compilation environment (I don't believe any such
restriction exists), then a reasonable alternative is to use normal BIT
STRINGs and INTEGERs whose meaning is bound at runtime.  This avoids
alternative of expanding each BIT out into it's own OID which, as Bob
says, is cumbersome and space inefficient.  OIDs should be used for
their intended purpose - object definition collision avoidance -
not as a replacement for the data elements comprising an object.

And as it turns out, Sandi and others are working on just such a
scheme - the "Security Parameter Information File" (SPIF) which
is interpreted at runtime (and signed by an Authority to prevent
tampering).

The same configuration management issues exist whether you use static
or dynamic assignment - you don't want anything defined in the future
to conflict with or modify the meaning of currently-defined bits.
The SPIF uses a single OID to specify a security policy under which
the bits are interpreted - compatible additions can be made under the
same policy, but incompatible changes require a new policy OID.

Date: Mon, 8 Jun 1998 12:09:21 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Extensibility in definitions
Sender: [email-masked]

From: "Balluffi, Frank" <[email-masked]>

> Modifications to named BIT STRINGs and ENUMERATED types require
> recompilation of the ASN.1.

and From: "Bob Jueneman" <[email-masked]>
> 
> Clearly we don't want to recompile every piece of software
> in the world just because someone makes a minor change to
> clarify the semantic definition of some attribute, or defines a new
> but compatible bit within a previously reserved field.
> 
> The extendedKeyUsage attribute gets around this problem by
> defining an attribute that contains other attributes identified by
> their own OID, but the result is cumbersome and space inefficient.
> 
> X.500 provides a means of distributing the syntax of new attributes
> by registering them in the directory. Unfortunately, until we have lots
> of software that support dynamic assignment of ASN.1 attributes, 
> that isn't much help.  And what we _really_ need is some way of 
> automatically updating the _semantics_ of these attributes, which
> all too often are spell out in too-terse comments to the ASN.1, if 
> at all.

The obvious alternative to static (compile time) assignment is dynamic
assignment using an interpreter or on-the-fly compiler.  If named BIT
STRINGs and ENUMERATED types are required by X.680 to be implemented
only in a static compilation environment (I don't believe any such
restriction exists), then a reasonable alternative is to use normal BIT
STRINGs and INTEGERs whose meaning is bound at runtime.  This avoids
alternative of expanding each BIT out into it's own OID which, as Bob
says, is cumbersome and space inefficient.  OIDs should be used for
their intended purpose - object definition collision avoidance -
not as a replacement for the data elements comprising an object.

And as it turns out, Sandi and others are working on just such a
scheme - the "Security Parameter Information File" (SPIF) which
is interpreted at runtime (and signed by an Authority to prevent
tampering).

The same configuration management issues exist whether you use static
or dynamic assignment - you don't want anything defined in the future
to conflict with or modify the meaning of currently-defined bits.
The SPIF uses a single OID to specify a security policy under which
the bits are interpreted - compatible additions can be made under the
same policy, but incompatible changes require a new policy OID.

Date: Mon, 08 Jun 1998 11:58:07 -0400
From: Eric Bomarsi <[email-masked]>
Organization: xedia.com
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: DNS and X.501 DistinguishedName
Sender: [email-masked]

A network entity such as a router may require
an X.501 DistinguishedName to utilize LDAP
directory serices or generate PKCS certificate 
requests. 

It's possible that the network entity can
use it's domain name to create an X.500
Distinguished Name as specified in RFC2247.
However, I'm concerned that this might be too 
inflexible since many organizations may
implement an internal X.500 naming convention
unrelated to their Internet domain naming.

Has any MIB work been done to support 
distinguished name configuration?

Thanks in advance,
Eric Bomarsi

Date: Mon, 08 Jun 1998 08:27:50 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Extensibility in definitions
Sender: [email-masked]

>I am under the belief that if I construct a bit map and allocate
>semantics to the bits, I cannot reallocate the meaning of the bits
>unless I create/register a new object.  However, if I create an
>enumerated list and at some future point (new countries, new anything)
>wish to extend that list, I can do so without registering a new object.
>
>Is this correct?
>
>Sandi
>
Sandi, that certainly sounds reasonable to me.

Likewise, if I define a bit string containing reserved or "spare" 
bits, I believe that I can later assign semantic meaning to 
those bits without changing the OID of the attribute.  However, 
I recognize that this is potentially a slippery slope -- I wouldn't 
want to suddenly have someone define a "Simon says" bit 
that either negates previous meanings, or assigns entirely 
new meanings to old bits, or otherwise potentially mislead 
or harms a relying party.

Seems to me that there is no really clear answer here -- we 
are between a rock and a hard place. We want to have
both interoperability and extensibility at the same time, and
that gives rise to this dynamic tension.

Clearly we don't want to recompile every piece of software
in the world just because someone makes a minor change to
clarify the semantic definition of some attribute, or defines a new
but compatible bit within a previously reserved field.

The extendedKeyUsage attribute gets around this problem by
defining an attribute that contains other attributes identified by
their own OID, but the result is cumbersome and space inefficient.

X.500 provides a means of distributing the syntax of new attributes
by registering them in the directory. Unfortunately, until we have lots
of software that support dynamic assignment of ASN.1 attributes, 
that isn't much help.  And what we _really_ need is some way of 
automatically updating the _semantics_ of these attributes, which
all too often are spell out in too-terse comments to the ASN.1, if 
at all.

Anyone else have any wisdom to contribute?  I'm open for 
suggestions.

Bob

Robert R. Jueneman
Security Architect
Novell, Inc.
Network Products Group
122 East 1700 South
Provo, UT 84604
801/861-7387
[email-masked]

"If you are trying to get to the moon, climbing a tree, 
although a step in the right direction, will not prove 
to be very helpful."

"The most dangerous strategy is to cross a chasm in two jumps."

From: "Balluffi, Frank" <[email-masked]>
To: "'Miklos, Sue A.'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "'Bob Jueneman'" <[email-masked]>
Subject: RE: Extensibility in definitions
Date: Mon, 8 Jun 1998 10:06:50 -0400 
Sender: [email-masked]

Sue Miklos asked:

I am under the belief that if I construct a bit map and allocate
semantics to the bits, I cannot reallocate the meaning of the bits
unless I create/register a new object.  However, if I create an
enumerated list and at some future point (new countries, new anything)
wish to extend that list, I can do so without registering a new object.

Modifications to named BIT STRINGs and ENUMERATED types require
recompilation of the ASN.1. Perhaps a better mechanism is the
TYPE-IDENTIFIER: a SEQUENCE containing an object identifier and an
encoded type. Using TYPE-IDENTIFIERs still requires registration of new
objects but does not require recompilation of the ASN.1. Depending on
how you construct your software, you may not even need to recompile your
application software.

Frank Balluffi
CertCo LLC

From: "Miklos, Sue A." <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "'Bob Jueneman'" <[email-masked]>
Subject: Extensibility in definitions
Date: Mon, 8 Jun 1998 08:44:07 -0400
Sender: [email-masked]

I am under the belief that if I construct a bit map and allocate
semantics to the bits, I cannot reallocate the meaning of the bits
unless I create/register a new object.  However, if I create an
enumerated list and at some future point (new countries, new anything)
wish to extend that list, I can do so without registering a new object.

Is this correct?

Sandi

>----------
>From: 	Bob Jueneman[SMTP:[email-masked]]
>Sent: 	Saturday, June 06, 1998 7:21 PM
>To: 	[email-masked]; [email-masked];
>[email-masked]; [email-masked]
>Subject: 	Re: Certificate reparenting, version numbers in extensions
>
>David, you said
>>If a new meaning 
>>is attached to the same semantics, then it should be given a new OID 
>
>I hope that you meant "if a new meaning is attached to the same SYNTAX it 
>should be given a new OID."
>
>I'm about to release a specification for what we call "Novell Registered
>Attributes(tm)", 
>a rather complex set of attributes that deal with computer security, crypto
>module 
>security, key storage quality, certificate class, an Enterprise ID, which is
>a form of 
>universal Mandatory Access Control label, and Reliance Limits.
>
>The syntax is complicated enough, but the semantics are even more extensive.
>
>In the case of Reliance Limits, for example, the document contains a listing
>of the
>currency codes used by every country in the world.
>
>Now, do the semantics of the attribute change just because some obscure
>country
>comes into existance, or changes its name, or decides to change the name of 
>of or revalue its currency?
>
>I don't think so, and hence wouldn't even consider changing the OID of the
>attribute in 
>that case -- it would cause needless confusion, and software that used to
>work would 
>suddenly stop.
>
>So within the mega-attribute, I have included both a major and a minor
>version number.
>I expect to update the minor version number any time I make a relatively
>minor editorial 
>change in the defining document, and to update the major version number to 
>correspond to major software releases.
>
>I haven't really thought quite that far ahead, but I guess I would change the
>OID if and
>only if the ASN.1 of the attribute changed in an incompatible way.  In other
>words, if
>a parameter within the ASN.1 were to change in such a way that the new ASN.1
>were 
>to become meaningless to anyone using the old definition, I would change the
>OID.
>
>But if I were to change a value that is self-describing, such as the maximum
>number of
>elements in a bit string, I certainly wouldn't change the OID, even if I did
>update the minor 
>version number to account for the design change.
>
>If I changed the semantic meaning of a particular coded value, I would change
>either the 
>major or the minor version number, so as to clue in the user to go get the
>latest set of 
>definitions. I also include a URL to the defining document within the
>attribute, and 
>would update it accordingly.
>
>Ideally, software which processes these attibutes would be keyed to the major
>and minor
>versions, and to the various languages, so that both the terse indications
>(which would 
>be likely to change only if a major version number update occurred) as well
>as the expanded 
>text and/or help screens would be updated automatically.  If th software saw
>a version
>number for which it didn't have the latest definitions, it ought to whine to
>the user,
>"There is apparently a new version of the definitions available. Please
>update me."
>But it is unlikely that everything would suddenly stop working, and so even
>if the 
>Critical flag is turned on, there is no reason to suddenly reject the
>attribute.
>
>Does this seem like a reasonable approach? 
>
>Bob
>
>>>  
>>> The second problem is that of putting version numbers into extensions.
>>>This 
>>> can interfere with the processing of critical extensions, because it's 
>>> uncertain whether a critical extension which you recognise with a version 
>>> number which you don't recognise counts as a "recognised" (in the sense of
>>> "don't reject the certificate") extension.  You certainly recognise the 
>>> extension (based on the OID), but you don't recognise it based on the
>>>version 
>>> number (this ties in with my earlier complaints about exactly what is
>>>meant 
>>> by "recognise an extension").  As I see it having version numbers in an 
>>> extension means the whole thing falls into a logical loophole, because you
>>>can 
>>> either accept the cert (you recognise the OID) or reject it (you don't 
>>> recognise the data in the extension).
>>>
>>
>>My take on this is that the OID of an extension specifies both the 
>>syntactic and semantic content of the extension. Therefore a given 
>>extension in several different certificate versions would still have 
>>the same meaning, and therefore if you recognise the extension, you 
>>recognise it, period, irrespective of the version. If a new meaning 
>>is attached to the same semantics, then it should be given a new OID 
>>(we already went around this one several years ago in X.500 schema 
>>definitions).
>>
>>The version number would most likely be there because additional 
>>extensions have been defined that you may or may not recognise (and 
>>which may or may not be present in any given certificate)
>>
>>David
>>
>>
>>***************************************************
>>David Chadwick
>>IT Institute, University of Salford, Salford M5 4WT
>>Tel +44 161 295 5351  Fax +44 161 745 8169
>>Mobile +44 370 957 287
>>Email [email-masked] 
>>Home Page  http://www.salford.ac.uk/its024/chadwick.htm 
>>Understanding X.500  http://www.salford.ac.uk/its024/X500.htm 
>>X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm 
>>***************************************************
>
>

Date: Sat, 06 Jun 1998 17:21:26 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Certificate reparenting, version numbers in extensions
Sender: [email-masked]

David, you said
>If a new meaning 
>is attached to the same semantics, then it should be given a new OID 

I hope that you meant "if a new meaning is attached to the same SYNTAX it 
should be given a new OID."

I'm about to release a specification for what we call "Novell Registered Attributes(tm)", 
a rather complex set of attributes that deal with computer security, crypto module 
security, key storage quality, certificate class, an Enterprise ID, which is a form of 
universal Mandatory Access Control label, and Reliance Limits.

The syntax is complicated enough, but the semantics are even more extensive.

In the case of Reliance Limits, for example, the document contains a listing of the
currency codes used by every country in the world.

Now, do the semantics of the attribute change just because some obscure country
comes into existance, or changes its name, or decides to change the name of 
of or revalue its currency?

I don't think so, and hence wouldn't even consider changing the OID of the attribute in 
that case -- it would cause needless confusion, and software that used to work would 
suddenly stop.

So within the mega-attribute, I have included both a major and a minor version number.
I expect to update the minor version number any time I make a relatively minor editorial 
change in the defining document, and to update the major version number to 
correspond to major software releases.

I haven't really thought quite that far ahead, but I guess I would change the OID if and
only if the ASN.1 of the attribute changed in an incompatible way.  In other words, if
a parameter within the ASN.1 were to change in such a way that the new ASN.1 were 
to become meaningless to anyone using the old definition, I would change the OID.

But if I were to change a value that is self-describing, such as the maximum number of
elements in a bit string, I certainly wouldn't change the OID, even if I did update the minor 
version number to account for the design change.

If I changed the semantic meaning of a particular coded value, I would change either the 
major or the minor version number, so as to clue in the user to go get the latest set of 
definitions. I also include a URL to the defining document within the attribute, and 
would update it accordingly.

Ideally, software which processes these attibutes would be keyed to the major and minor
versions, and to the various languages, so that both the terse indications (which would 
be likely to change only if a major version number update occurred) as well as the expanded 
text and/or help screens would be updated automatically.  If th software saw a version
number for which it didn't have the latest definitions, it ought to whine to the user,
"There is apparently a new version of the definitions available. Please update me."
But it is unlikely that everything would suddenly stop working, and so even if the 
Critical flag is turned on, there is no reason to suddenly reject the attribute.

Does this seem like a reasonable approach? 

Bob

>>  
>> The second problem is that of putting version numbers into extensions.  This 
>> can interfere with the processing of critical extensions, because it's 
>> uncertain whether a critical extension which you recognise with a version 
>> number which you don't recognise counts as a "recognised" (in the sense of 
>> "don't reject the certificate") extension.  You certainly recognise the 
>> extension (based on the OID), but you don't recognise it based on the version 
>> number (this ties in with my earlier complaints about exactly what is meant 
>> by "recognise an extension").  As I see it having version numbers in an 
>> extension means the whole thing falls into a logical loophole, because you can 
>> either accept the cert (you recognise the OID) or reject it (you don't 
>> recognise the data in the extension).
>>
>
>My take on this is that the OID of an extension specifies both the 
>syntactic and semantic content of the extension. Therefore a given 
>extension in several different certificate versions would still have 
>the same meaning, and therefore if you recognise the extension, you 
>recognise it, period, irrespective of the version. If a new meaning 
>is attached to the same semantics, then it should be given a new OID 
>(we already went around this one several years ago in X.500 schema 
>definitions).
>
>The version number would most likely be there because additional 
>extensions have been defined that you may or may not recognise (and 
>which may or may not be present in any given certificate)
>
>David
>
>
>***************************************************
>David Chadwick
>IT Institute, University of Salford, Salford M5 4WT
>Tel +44 161 295 5351  Fax +44 161 745 8169
>Mobile +44 370 957 287
>Email [email-masked] 
>Home Page  http://www.salford.ac.uk/its024/chadwick.htm 
>Understanding X.500  http://www.salford.ac.uk/its024/X500.htm 
>X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm 
>***************************************************

Comments: Authenticated sender is <[email-masked]>
From: "David Chadwick" <[email-masked]>
Organization: University of Salford
To: [email-masked], [email-masked]
Date: Sat, 6 Jun 1998 23:20:14 +0000
Subject: Re: Certificate reparenting, version numbers in extensions
Reply-to: [email-masked]
Sender: [email-masked]

>  
> The second problem is that of putting version numbers into extensions.  This 
> can interfere with the processing of critical extensions, because it's 
> uncertain whether a critical extension which you recognise with a version 
> number which you don't recognise counts as a "recognised" (in the sense of 
> "don't reject the certificate") extension.  You certainly recognise the 
> extension (based on the OID), but you don't recognise it based on the version 
> number (this ties in with my earlier complaints about exactly what is meant 
> by "recognise an extension").  As I see it having version numbers in an 
> extension means the whole thing falls into a logical loophole, because you can 
> either accept the cert (you recognise the OID) or reject it (you don't 
> recognise the data in the extension).
>

My take on this is that the OID of an extension specifies both the 
syntactic and semantic content of the extension. Therefore a given 
extension in several different certificate versions would still have 
the same meaning, and therefore if you recognise the extension, you 
recognise it, period, irrespective of the version. If a new meaning 
is attached to the same semantics, then it should be given a new OID 
(we already went around this one several years ago in X.500 schema 
definitions).

The version number would most likely be there because additional 
extensions have been defined that you may or may not recognise (and 
which may or may not be present in any given certificate)

David

***************************************************
David Chadwick
IT Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351  Fax +44 161 745 8169
Mobile +44 370 957 287
Email [email-masked]
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
***************************************************

From: "Blake Ramsdell" <[email-masked]>
To: "'Marc Branchaud'" <[email-masked]>, <[email-masked]>
Subject: RE: DER encoding of BITSTRING
Date: Fri, 5 Jun 1998 15:15:29 -0700
Sender: [email-masked]

> -----Original Message-----
> From: Marc Branchaud [mailto:[email-masked]]
> Sent: Friday, June 05, 1998 9:12 AM
> To: [email-masked]
> Subject: Re: DER encoding of BITSTRING
> 
> I was confusing the definition of keyUsage, which isn't just 
> a plain BIT
> STRING but is really what X.680 calls a "NamedBitList".  
> NamedBitLists, as
> you say, have trailing zeros removed in DER, whereas plain 
> BIT STRINGs don't.

Ah, good old ITU-T Rec. X.680 | ISO/IEC 8824-1, subclause 19.7.  I hate
it when that happens.

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Certificate transport encoding question
Reply-To: [email-masked]
Date: Sat, 6 Jun 1998 05:10:27 (NZST)
Sender: [email-masked]

I've got two questions about certificate encoding in transport formats, I've 
sent them to both lists since they're a bit nonspecific.
 
The first one concerns the order of certs in a cert chain.  Looking at the CMS 
spec, it says that the SET OF Certificate should contain chains from the root 
down to each required subject, but doesn't give any explicit ordering.  An 
ASN.1 SET is inherently unordered, but is there any recommended, consistent 
way to encode a cert chain, or do you just add them in whatever order you feel 
like?  So far I've seen them ordered from subject to root, from root to 
subject, and pseudorandomly (using the DER SET encoding rules)... all of these 
are equally valid, it just seems messy to have any number of possible 
orderings present.
 
The second one concerns something which isn't explicitly addressed by any 
standard but which it might be worth covering somewhere.  When a certificate 
or cert-related object (cert request, CRL) is base64-encoded, there are again 
a large number of different interpretations on what delimiters to use around 
the base64 data.  I've seen BEGIN CERTIFICATE, BEGIN CERTIFICATE REQUEST, 
BEGIN NEW CERTIFICATE REQUEST, BEGIN PGP MESS...no hang on, that's something 
else :-).  Alongside these are various creative mutations (extra blank lines, 
name:value pairs a la PGP, and other oddities).  It's probably a good idea to 
specify a set format for these as well and attach them to some existing 
standard.  If there's a need for them I'll put together a paragraph or two 
defining the exact format.
 
Peter.

To: [email-masked]
Subject: Re: DER encoding of BITSTRING 
Date: Fri, 05 Jun 1998 09:11:39 -0700
From: Marc Branchaud <[email-masked]>
Sender: [email-masked]

-----BEGIN PGP SIGNED MESSAGE-----

Content-Type: text/plain; charset=us-ascii

Olivier,

Thanks for the info!

I was confusing the definition of keyUsage, which isn't just a plain BIT
STRING but is really what X.680 calls a "NamedBitList".  NamedBitLists, as
you say, have trailing zeros removed in DER, whereas plain BIT STRINGs don't.

		Marc

+------------------------------------------------------------------------+
 Marc Branchaud                                  \/
 Chief PKI Architect                             /\CERT INTERNATIONAL INC.
 [email-masked]        PKI References page:              www.xcert.com
 604-640-6227          www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+
  PGP key fingerprint:  60 11 4B 9D 4E E5 2F 47  BD C5 C2 BF 26 DF 5A E1

 <[email-masked]> scrawled:
> 
> >-----BEGIN PGP SIGNED MESSAGE-----
> >
> >Content-Type: text/plain; charset=us-ascii
> >
> >
> >In Part 1, example D.3 on page 113 shows an encoding of keyUsage bits.  For 
> >the example, only the digitalSignature bit (bit 0) is set.
> >
> >The example has the following hex encoding: 03 02 07 80, meaning:
> >
> >	03 - This is a BITSTRING
> >	02 - There are 2 octets used to encode the string
> >	07 - Ignore the last 7 bits of the last octet
> >	80 - The bits
> >
> >The problem is that the 07 says that only the first bit of the last octet 
> >should be recognized.
> >
> >Isn't this wrong?  This is really an encoding for a 1-bit BITSTRING, no?  I
> >think the encoding should be 03 03 07 80 00, so that the first 9 bits of the
> >"8000" are fully specified and _all_ of keyUsage's bits are explicitly
> >assigned a value.
> >
> >		Marc
> >
> >+------------------------------------------------------------------------+
> > Marc Branchaud                                  \/
> > Chief PKI Architect                             /\CERT INTERNATIONAL INC.
> > [email-masked]        PKI References page:              www.xcert.com
> > 604-640-6227          www.xcert.com/~marcnarc/PKI/
> >+------------------------------------------------------------------------+
> >  PGP key fingerprint:  60 11 4B 9D 4E E5 2F 47  BD C5 C2 BF 26 DF 5A E1
> >
> >
> >
> >-----BEGIN PGP SIGNATURE-----
> >Version: 2.6.2
> >
> >iQB1AwUBNXcHx1rdFXNdDxPlAQEVKwL/X4LdXYob4rQnzYIE2sXpW1CYxNEynf+P
> >M6IC6cfYqIrHxLlgmRcNOIwiEH2Usj9d/pCYU6odJggH+HS4Kt8VsXXTQu5tcWCt
> >CtRRufTkDHsHuNDmI6yLDQkByR3nHRAN
> >=59Mu
> >-----END PGP SIGNATURE-----
> >
> >
> 
> Hi!
> 
> DER-coding is so simple !
> 
>  The DER-Encoding of a "NamedBitString" implies that the trailing bits which
> are 0
>  must NOT be coded:
> 
> 
> 
>         BER-coding:
>         According to X.680, Chapter 19.7,
>         "The trailing bits which are
>         0 can be removed from the coding (and are not relevant anymore)"
>  
>         DER-coding: 
>         In X.690,Chapter 11.2.2 (DER-encoding): 
>         "The bitstring shall have all trailing 0 bits
>         removed before it is encoded."
> 
>         It means, the bitstring '1' (DER-coded as 03 02 07 80) represents:
>                      digitalSignature  ON
>                      nonRepudiation    OFF
>                      keyEncipherment   OFF
>                      dataEncipherment  OFF
>                      keyAgreement      OFF
>                      keyCertSign       OFF
>                      cRLSign           OFF
>                      encipherOnly      OFF
>                      decipherOnly      OFF
> 
>        and it is the only correct DER-encoding for this.
> 
> 
> Bye
> 
> 
> Olivier.
> 
>  ___________________________________________________________________
>  Olivier Onimus                                            
>  Danet GmbH, Business Unit Telecommunications Technology   
>  Gutenbergstrasse 10, D-64331 Weiterstadt, Germany         
>  Tel: +49-6151-868-127  Fax:+49-6151-868-264  E-mail:[email-masked]
>  WEB: www.danet.de
>  __________________________________________________________________

Date: Fri, 05 Jun 1998 08:30:04 -0400
From: "Gorman, Jeanne" <[email-masked]>
Subject: RE: CRL issuing
To: [email-masked]
Sender: [email-masked]

SET applications support the case you have described.  The SET Brand CAs use
separate keys for Certificate Signing and CRL Signing - the usage is
indicated by the keyUsage extension.  SET uses V2 CRLs that contain the
AuthorityKeyIdentifier extension so that the signer can be found.  And the
Brand CA's Cert Signing and CRL Signing certs contain matching DNs so that
the cert issuer can be found.   

Jeanne Gorman
GTE
> ----------
> From: 	Peter Lipp[SMTP:[email-masked]]
> Sent: 	Wednesday, May 27, 1998 10:13 AM
> To: 	[email-masked]; Stefan Santesson
> Subject: 	Re: CRL issuing
> 
> >The CA is by this procedure linked to the CRL by certifying the
> >public key with which the CRL can be checked.
> 
> Which implementations currently can handle this and which don't?
> 
> More precisely, which implementations currently can handle CRL's at all
> and which of them can handle these special public key properly?
> 
> I guess not too many.....
> 
> Peter
> 

Date: Fri, 5 Jun 1998 10:58:54 +0200
To: Marc Branchaud <[email-masked]>
From: [email-masked] (Olivier Onimus)
Subject: Re: DER encoding of BITSTRING
Cc: [email-masked]
Sender: [email-masked]

>-----BEGIN PGP SIGNED MESSAGE-----
>
>Content-Type: text/plain; charset=us-ascii
>
>
>In Part 1, example D.3 on page 113 shows an encoding of keyUsage bits.  For 
>the example, only the digitalSignature bit (bit 0) is set.
>
>The example has the following hex encoding: 03 02 07 80, meaning:
>
>	03 - This is a BITSTRING
>	02 - There are 2 octets used to encode the string
>	07 - Ignore the last 7 bits of the last octet
>	80 - The bits
>
>The problem is that the 07 says that only the first bit of the last octet 
>should be recognized.
>
>Isn't this wrong?  This is really an encoding for a 1-bit BITSTRING, no?  I
>think the encoding should be 03 03 07 80 00, so that the first 9 bits of the
>"8000" are fully specified and _all_ of keyUsage's bits are explicitly
>assigned a value.
>
>		Marc
>
>+------------------------------------------------------------------------+
> Marc Branchaud                                  \/
> Chief PKI Architect                             /\CERT INTERNATIONAL INC.
> [email-masked]        PKI References page:              www.xcert.com
> 604-640-6227          www.xcert.com/~marcnarc/PKI/
>+------------------------------------------------------------------------+
>  PGP key fingerprint:  60 11 4B 9D 4E E5 2F 47  BD C5 C2 BF 26 DF 5A E1
>
>
>
>-----BEGIN PGP SIGNATURE-----
>Version: 2.6.2
>
>iQB1AwUBNXcHx1rdFXNdDxPlAQEVKwL/X4LdXYob4rQnzYIE2sXpW1CYxNEynf+P
>M6IC6cfYqIrHxLlgmRcNOIwiEH2Usj9d/pCYU6odJggH+HS4Kt8VsXXTQu5tcWCt
>CtRRufTkDHsHuNDmI6yLDQkByR3nHRAN
>=59Mu
>-----END PGP SIGNATURE-----
>
>

Hi!

DER-coding is so simple !

 The DER-Encoding of a "NamedBitString" implies that the trailing bits which
are 0
 must NOT be coded:

        BER-coding:
        According to X.680, Chapter 19.7,
        "The trailing bits which are
        0 can be removed from the coding (and are not relevant anymore)"
 
        DER-coding: 
        In X.690,Chapter 11.2.2 (DER-encoding): 
        "The bitstring shall have all trailing 0 bits
        removed before it is encoded."

        It means, the bitstring '1' (DER-coded as 03 02 07 80) represents:
                     digitalSignature  ON
                     nonRepudiation    OFF
                     keyEncipherment   OFF
                     dataEncipherment  OFF
                     keyAgreement      OFF
                     keyCertSign       OFF
                     cRLSign           OFF
                     encipherOnly      OFF
                     decipherOnly      OFF

       and it is the only correct DER-encoding for this.

Bye

Olivier.

 ___________________________________________________________________
 Olivier Onimus                                            
 Danet GmbH, Business Unit Telecommunications Technology   
 Gutenbergstrasse 10, D-64331 Weiterstadt, Germany         
 Tel: +49-6151-868-127  Fax:+49-6151-868-264  E-mail:[email-masked]
 WEB: www.danet.de
 __________________________________________________________________

Date: Fri, 05 Jun 1998 09:58:00 +0200
From: Ferdinando Ricchiuti <[email-masked]>
To: Marc Branchaud <[email-masked]>
Cc: [email-masked]
Subject: Re: DER encoding of BITSTRING
Sender: [email-masked]

Marc Branchaud wrote:

> In Part 1, example D.3 on page 113 shows an encoding of keyUsage bits.  For
> the example, only the digitalSignature bit (bit 0) is set.
> 
> The example has the following hex encoding: 03 02 07 80, meaning:
> 
>         03 - This is a BITSTRING
>         02 - There are 2 octets used to encode the string
>         07 - Ignore the last 7 bits of the last octet
>         80 - The bits
> 
> The problem is that the 07 says that only the first bit of the last octet
> should be recognized.
> 
> Isn't this wrong?  This is really an encoding for a 1-bit BITSTRING, no?  I
> think the encoding should be 03 03 07 80 00, so that the first 9 bits of the
> "8000" are fully specified and _all_ of keyUsage's bits are explicitly
> assigned a value.
> 
>                 Marc

Marc,

Probably the un-encoded bits are "don't-carry" but it is better to
encode all bits.
So I agree with you.

						Nando.

+-------------------------------------------------------------------+
| Ferdinando Ricchiuti                     Computer Science Student |
+--------------------------------+----------------------------------+
| Politecnico di Torino          | phone:  +39-(0)11-5647090        |
| Dip. Automatica e Informatica  | fax:                             |
| corso Duca degli Abruzzi, 24   | e-mail: [email-masked] | 
| 10129 Torino                   |                                  |
| ITALY                          | http://www.polito.it/~fricchi/   | 
+--------------------------------+----------------------------------+

To: [email-masked]
Subject: DER encoding of BITSTRING
Date: Thu, 04 Jun 1998 13:47:04 -0700
From: Marc Branchaud <[email-masked]>
Sender: [email-masked]

-----BEGIN PGP SIGNED MESSAGE-----

Content-Type: text/plain; charset=us-ascii

In Part 1, example D.3 on page 113 shows an encoding of keyUsage bits.  For 
the example, only the digitalSignature bit (bit 0) is set.

The example has the following hex encoding: 03 02 07 80, meaning:

	03 - This is a BITSTRING
	02 - There are 2 octets used to encode the string
	07 - Ignore the last 7 bits of the last octet
	80 - The bits

The problem is that the 07 says that only the first bit of the last octet 
should be recognized.

Isn't this wrong?  This is really an encoding for a 1-bit BITSTRING, no?  I
think the encoding should be 03 03 07 80 00, so that the first 9 bits of the
"8000" are fully specified and _all_ of keyUsage's bits are explicitly
assigned a value.

		Marc

+------------------------------------------------------------------------+
 Marc Branchaud                                  \/
 Chief PKI Architect                             /\CERT INTERNATIONAL INC.
 [email-masked]        PKI References page:              www.xcert.com
 604-640-6227          www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+
  PGP key fingerprint:  60 11 4B 9D 4E E5 2F 47  BD C5 C2 BF 26 DF 5A E1

Date: Wed, 03 Jun 1998 09:45:30 -0400
To: "Peter Lipp" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: question on Subject Key Identifier ipki-part1-07
Cc: [email-masked]
Sender: [email-masked]

PKCS#7 version 1.5 and the IETF CMS document are aligned in this area.
PKCS#7 version 1.6 acts differently, and only SET is using it.

Russ

At 10:17 AM 5/29/98 +0200, Peter Lipp wrote:
>This document sais:
>
>>The hash shall  be calculated over the value (excluding tag and length) of
>the BIT
>>STRING subjectPublicKey in the certificate.
>
>I assume that excluding tag and length comes from the fact that this was the
>same
>in PEM - and PKCS. Currently, PKCS#7 specs changed this behaviour and
>tag and length get included into the hash. Wouldn't it make sense to do the
>same here
>or is there any specific reason not to?
>
>Peter
>
>
> 

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-crmf-01.txt
Date: Wed, 03 Jun 1998 10:24:44 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group 
of the IETF.

	Title		: Internet X.509 Certificate Request Message Format
	Author(s)	: D. Solo, C. Adams, D. Kemp, M. Myers
	Filename	: draft-ietf-pkix-crmf-01.txt
	Pages		: 20
	Date		: 02-Jun-98
	
This document describes the Certificate Request Message Format (CRMF).
This syntax is used to convey a request for a certificate to a
Certification Authority (CA) (possibly via a Registration Authority
(RA)) for the purposes of X.509 certificate production.  The request
will typically include a public key and associated registration
information.

The key words ''MUST'', ''REQUIRED'', ''SHOULD'', ''RECOMMENDED'',
and ''MAY'' in this document (in uppercase, as shown)
are to be interpreted as described in RFC 2119.
 
Please send comments on this document to the [email-masked]
mail list.

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-crmf-01.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-crmf-01.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ftp.ietf.org
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-crmf-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-crmf-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-crmf-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Reply-To: <[email-masked]>
From: "Rich Ankney" <[email-masked]>
To: "Andreas Berger" <[email-masked]>, "Michael Myers" <[email-masked]>
Cc: "David P. Kemp" <[email-masked]>, <[email-masked]>
Subject: Re: CHOICE OF OCSP certID syntax
Date: Wed, 3 Jun 1998 08:12:24 -0400
Sender: [email-masked]

> From: Andreas Berger <[email-masked]>
<snip>
> Hi Mike (and all the others),
> 
> now that I am back again from my holidays...
> 
> Regarding the Hash of the Certificate in OCSP as a CertID. In
> conjunction with the German Signature Law, a method is needed that
> allows to retrieve Information about a certificate that does not require
> the transmission of personal data (issuer and serial can be regarded as
> that) is needed. A hash of a certificate makes sure that the requesting
> party is in posession of the certificate it tries to request information
> for.
> 
> Background: The Law mandates an on-line protocol to be used for checking
> signatures (CRLs are allowed but the potential "time gap" is the risk of
> the user choosing CRLs over the on-line method). So a client could send
> the certificate it requests information about to the on-line service.
> This is not recommended since it poses severe privacy threats if used
> unencrypted. The next best solution would be to hash the certificate and
> use this hash as an identifier.
> 
> But you are right, using a hash only to identify a certificate makes me
> feel a bit uneasy. Probably we should allow different hash algorithms?
> Or add a hash of the DER encoding of Issuer/Serial?
> 
> 
> Andreas

My concern over using just a hash is that it's hard to distribute the
repository using just the hash.  E.g. if I retrieve a certificate status
using the subject name, I can use the normal X.500 mechanisms to
distribute the repository database among multiple servers.  

If the certificate indicates (in the AuthorityInfoAccess extension, for
example) where the OCSP server is, then perhaps the hash would
be sufficient...

Regards,
Rich

From: "Fabio Omenigrandi" <[email-masked]>
To: [email-masked]
cc: "Andrea Sansone" <[email-masked]>
Date: Wed, 3 Jun 1998 13:03:54 +0200
Subject: Questions about using DeltaCRLIndicator extension
Sender: [email-masked]

Is it correct the value of attribute extensions of the
following CA behaviour when issues the CRL ?

Suppose that in a first time I issue the base CRL.

1 Time)    CRL (base):       cRLNumber = 1
                            BaseCRLNumber = Not used.

In a second time I issue a complete CRL and a first deltaCRL

2 Time)     CRL (complete) : cRLNumber = 2
                             BaseCRLNumber = Not used.

            CRL (Delta) : cRLNumber = 2
                     (the pointer to the complete new CRL)
                          BaseCRLNumber = 1
                     (the pointer to the first base CRL)

In a third time I issue a complete CRL and second deltaCRL

3 Time)    CRL (complete) : cRLNumber = 3

           CRL (Delta) : cRLNumber = 3
                        (the pointer to the complete new CRL)
                         BaseCRLNumber = 1
                        (the pointer to the base CRL)

Thank you.
Andrea Sansone. Fabio Omenigrandi
SSB S.p.A.

P.S.: there is a inconsistency between the definition of the
DeltaCRLIndicator given by PKIX-1 and given by X.509-8.
In particular in PKIX-1 (pag. 46) you can read "... received
delta-CRL is more *that* one greater that the ..." instead
in X.509-8 (pag. 44) you can read "... received delta-CRL
is more *than* one greater that the ...".

Date: Wed, 03 Jun 1998 10:09:34 +0200
From: Andreas Berger <[email-masked]>
To: Michael Myers <[email-masked]>
CC: "David P. Kemp" <[email-masked]>, [email-masked]
Subject: Re: CHOICE OF OCSP certID syntax
Sender: [email-masked]

Michael Myers wrote:
> 
> Dave,
> 
> At 10:15 AM 5/21/98 -0400, David P. Kemp wrote:
> >As discussed here previously, the cert hash by itself
> >may be insufficient to serve as a retrieval index.
> 
> I recall Steve discussing a hash of the CA's key:
> 
> >While the hash of a CA's key would likely be unique, it also is a terrible
> >search key in many instances. One has to be careful about the context in
> >which a pointer to a CA cert is being used. In a cert, having a CA "key ID"
> >that is based on the hash of the CA is fine, because we already have the CA
> >name, and maybe even a locator.  In other protocol context we should have a
> >similar level of naming for search purposes, and rely on something like a
> >key hash just for disambiguation among multiple possible keys associated
> >with the same CA.
> 
> but this doesn't speak to a hash of the subject certificate.
> 
> Do I take your response to be against the CHOICE generally?  There is
> benefit to the installed base of systems that are successfully using the
> {Issuer DN, subject serial number} model of certificate identification.
> 
> Mike
Hi Mike (and all the others),

now that I am back again from my holidays...

Regarding the Hash of the Certificate in OCSP as a CertID. In
conjunction with the German Signature Law, a method is needed that
allows to retrieve Information about a certificate that does not require
the transmission of personal data (issuer and serial can be regarded as
that) is needed. A hash of a certificate makes sure that the requesting
party is in posession of the certificate it tries to request information
for.

Background: The Law mandates an on-line protocol to be used for checking
signatures (CRLs are allowed but the potential "time gap" is the risk of
the user choosing CRLs over the on-line method). So a client could send
the certificate it requests information about to the on-line service.
This is not recommended since it poses severe privacy threats if used
unencrypted. The next best solution would be to hash the certificate and
use this hash as an identifier.

But you are right, using a hash only to identify a certificate makes me
feel a bit uneasy. Probably we should allow different hash algorithms?
Or add a hash of the DER encoding of Issuer/Serial?

Andreas
-- 
Erst kommt das Fressen, dann kommt die Moral
 -- Bertolt Brecht

Date: Tue, 02 Jun 1998 17:02:21 -0400
To: [email-masked]
From: Rodney Thayer <[email-masked]>
Subject: test
Sender: [email-masked]

please ignore.

-----------------
Rodney Thayer
EIS Corporation
[email-masked]

Date: Tue, 02 Jun 1998 08:26:10 +0200
From: Bertus Pretorius <[email-masked]>
Organization: SACA
To: E-CARM <[email-masked]>, certtalk <[email-masked]>, [email-masked]
Subject: Re: [E-CARM] Pseudonyms
Sender: [email-masked]

I though this argument was allready cleared.  Yes it is dangerous to use (reference
name, key).
Thus we should use (reference name, key, reference or validity domain or community)
where the technology bind the tuplet and the reference or community provide the
"trust" value and provide warrantees to the issuing of the subscriber for the user
to reference.

Stephen Kent wrote:

> Carl,
>
> >>I know that lot's of Peter Lipp's exist, so the individual corresponding to
> >>this
> >>name (which is the meaning of the name) is not clearly defined by Peter Lipp
> >>alone. What else is new? Does this make the concept of certificates invalid?
> >
> >This lack of name uniqueness makes (name,key) certificates dangerous and
> >puts the wisdom of using (name,key) certificates into doubt.  The danger is
> >that we are so accustomed to using names as valid identifiers of people in
> >our daily lives (thanks to our living, in the 3D world, in small communities
> >of friends, family, coworkers, ...), that we are tempted to believe that all
> >names are valid identifiers.  In a national, continental or global
> >namespace, those names are not valid identifiers and a careful security
> >design would not allow people to believe they are.  The current (name,key)
> >certificate design and more especially the verbiage surrounding (name,key)
> >certificates (including the texts of laws) not only allows people to believe
> >names are valid identifiers but also seems to suffer from that mistake itself.
> >The danger of this belief mismatch is that someone looking for the certified
> >key of an old friend (or co-worker or customer or merchant or ...) is led
> >to guess whether the name in the certificate belongs to the entity that
> >user things it might -- based on name match.  This process is a human guess
> >and there is no room in security procedures for human guesses...at least
> >not when we are trying to keep mistakes in the process down to a probability
> >of less than 2^{-90}.
>
> Names can be unique, if suitably qualified.  Each of us have a number of
> "names" that serve this purpose, and each tends to be used in a context
> where it is unique.  We all agree that no single name is both globally
> unique and universally meaningful.  However, that does not mean than we are
> unable to certify names in many contexts that will prove adequate for many
> applications.  Your claim that a name and key pair is dangerous is not well
> founded sounds way too much like a SPKI promotion.  Wrong list, Carl.
>
> Steve
>
> ===========================================================================
> Help with Majordomo commands plus list archives and information is
> available through the E-CARM web page at http://www.kc-inc.net/e-carm/.
> Sponsored by The Knowledge Connection.
> ===========================================================================

--
These are my biased opinions and do not represent SACA nor PQ Holdings
Bertus Pretorius, 083 303-1812, [email-masked]
The South African Certification Agency, www.saca.net
SACA is part of Persetel Q-Data Holdings, www.pqholdings.com
----------- A smile is the same in all languages -----------

Date: Sat, 30 May 1998 14:06:51 -0400
To: Carl Ellison <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: [E-CARM] Pseudonyms
Cc: "Peter Lipp" <[email-masked]>, "E-CARM" <[email-masked]>, "certtalk" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Carl,

>>I know that lot's of Peter Lipp's exist, so the individual corresponding to
>>this
>>name (which is the meaning of the name) is not clearly defined by Peter Lipp
>>alone. What else is new? Does this make the concept of certificates invalid?
>
>This lack of name uniqueness makes (name,key) certificates dangerous and
>puts the wisdom of using (name,key) certificates into doubt.  The danger is
>that we are so accustomed to using names as valid identifiers of people in
>our daily lives (thanks to our living, in the 3D world, in small communities
>of friends, family, coworkers, ...), that we are tempted to believe that all
>names are valid identifiers.  In a national, continental or global
>namespace, those names are not valid identifiers and a careful security
>design would not allow people to believe they are.  The current (name,key)
>certificate design and more especially the verbiage surrounding (name,key)
>certificates (including the texts of laws) not only allows people to believe
>names are valid identifiers but also seems to suffer from that mistake itself.
>The danger of this belief mismatch is that someone looking for the certified
>key of an old friend (or co-worker or customer or merchant or ...) is led
>to guess whether the name in the certificate belongs to the entity that
>user things it might -- based on name match.  This process is a human guess
>and there is no room in security procedures for human guesses...at least
>not when we are trying to keep mistakes in the process down to a probability
>of less than 2^{-90}.

Names can be unique, if suitably qualified.  Each of us have a number of
"names" that serve this purpose, and each tends to be used in a context
where it is unique.  We all agree that no single name is both globally
unique and universally meaningful.  However, that does not mean than we are
unable to certify names in many contexts that will prove adequate for many
applications.  Your claim that a name and key pair is dangerous is not well
founded sounds way too much like a SPKI promotion.  Wrong list, Carl.

Steve

Date: Sat, 30 May 1998 13:59:58 -0400
To: Ferdinando Ricchiuti <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Key Usage for for Authentication and digitalSignature
Cc: Nilsson Hans <[email-masked]>, [email-masked]
Sender: [email-masked]

Ferdinando,

>Actually in the SSL-v3.0 client-autentication phase, the client
>generates a MAC in this way:
>	1-the received data (master key) are padded and hashed
>	2-the resulting stream is then padded again and rehashed
>	3-this finaly stream is encrypted with client's private key
>This mean that the MAC sent to the server, is not a digital signature
>as defined in X.509 specification.
>Thus we think there are not security leack using both digitalSignature
>and nonRepudation bits.

Since SSL v3 supports more p[ublic key algorithms than just RSA, I am
puzzled by the third step as defined above.  How do I "encrypt" using my
private DSA or Diffie-Hellman key?

Steve

Date: Sat, 30 May 1998 13:56:44 -0400
To: "Peter Lipp" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: [E-CARM] Pseudonyms
Cc: "Ed Gerck" <[email-masked]>, "E-CARM" <[email-masked]>, "certtalk" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Peter,

I envision two ways of handling this, depdning on whether the certs are for
human or machine consumtion.  In the former case, some form of naming
conventions will likley be adopted, maybe in the CN, or maybe at a higher
RDN.  For automated consumption, why not use the security policy extension
and incorporate an approriate OID?

Steve

Date: Sat, 30 May 1998 13:33:11 -0400
To: Nilsson Hans <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Key Usage for for Authentication and digitalSignature
Cc: [email-masked]
Sender: [email-masked]

Nilsson,

>"For example, when an RSA key should be used only for signing, the
>digitalSignature and nonRepudation bits would be asserted"
>and also "The digitalSignature bit is asserted when the subject public key
>is used to privde authentication". The same writing can be found in the new
>ISO draft 1572 (Public Key certificates for banking.
>
>If understand this correctly, this introduces a possible security threat,
>with the following scenario: In a user's certificate, both bits are set.
>When the user is required to logon to a web server using SSL client
>authentication, the server actually sends a the hash value of a false
>message, instead of a random number as a challenge.  The user encrypts with
>the corresponding private key, and has thus unknowingly signed the false
>message.

I think the wording is in error.  Just because a key is used for signature
purposes does not mean that it is used for non-repudaiation, e.g., it may
be used for authentication.

>Because of this threat, we have in Sweden come to the conclusion that the
>nonRepudiation usage bit never may be combined with any other key usage. Is
>this correct (and PKIX-part1-07 wrong), or have we misunderstood something
>along the way?

I'd argue, as above, that one really should turn on both signature and
non-repduation flags when signing to support N-R.

steve