Subject: Multiply CRLs for one CA and the CRLDisributionPoint extension
From: [email-masked]
To: [email-masked]
Date: Sun, 29 Jun 1997 16:37:41 +0200

Hi

The CRLDisributionPoint enable the division of the CRL into several 
shorter CRLs. It has standard attributes to divide the CRL according
to the revocation reason and weather the revoked entitiy is a CA or
not. 
My question is if I can use this extension to divide the CRL along
other lines?

The situation that I have in mind is comunication between users and
machines. Where the users comunicate directly only with the machines.

I would like to enable the users to download a CRL containing only the
revocations of machines which is expected to be a small fraction of the
total CRL.

I was thinking about creating to CRL, one for the users and one for the
machine, and to put in each certificate's CRLDisributionPoint atribute
the distribution point of the appropriate CRL.

I didn't see in standards anything against that solution for arbitrary
division of a CRL, but it seems to implicitaly assume that the divison
is done by revocation reason  or CA/not CA.

So does it complies with the standards?

Regards
Moshe

it is expected to have a lot of users and very few
machines. It is also expected that user's certificate will be revoked
more often.

I don't want to have force the user to download the whole CRL 

The problem is that it seems that 

From: Brian Korver <[email-masked]>
Subject: Re: Certificate Policies field - looking for CertPolicyID values
To: [email-masked] (Michael Leahy)
Date: Fri, 27 Jun 1997 12:18:18 -0700 (PDT)
Cc: [email-masked]

Michael Leahy writes:
> 
> Hi
> 
> I was wondering if anyone knows of any Certificate Policies Identifiers i=
> n use in systems today ?  and if you have a list of known OIDs I would ce=
> rtainly appreciate this information
> 
> Regards
> Michael Leahy=20
> ISOCOR

The SET protocol, insofar as it's in use in systems today, uses the
CertificatePolicies extension.  SET v1.0 defines one policy
identifier, id-set-policy-root, as 
    { joint-iso-itu-t(2) internationalRA(23) set(42) 5 0 }

brian
[email-masked]

Date: Fri, 27 Jun 1997 17:04:07 UT
From: Michael Leahy <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Certificate Policies field - looking for CertPolicyID values

Hi

I was wondering if anyone knows of any Certificate Policies Identifiers i=
n use in systems today ?  and if you have a list of known OIDs I would ce=
rtainly appreciate this information

Regards
Michael Leahy=20
ISOCOR

Date: Thu, 26 Jun 1997 13:49:49 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: PKIX Part 1 private internet extensions

Section 4.2.2 of PKIX part 1 defines two private internet extensions,
SubjectInfoAccess and AuthorityInfoAccess.  Each of these contains
URIs represented by IA5Strings, but the ASN.1 definition uses GeneralName
instead of IA5String for the various information fields.  Given the
processing descriptions in Section 4.2.2, it doesn't make sense to use
any of the other GeneralName forms (IPAddress, EDIPartyName, etc) as
info access fields.

The following paragraph appears at the end of 4.2.2.2:
  "The expected values for CertStatus and authorityInfo are those defined
   in 4.2.2.1 for subjectInfo field. Processing rules for other values
   for certStatus and authorityInfo are not defined."

Presumably the "other values" refers to other types of GeneralName.
Before PKIX can progress along the standards track, it must be well
specified, with undefined options eliminated.  If no suitable processing
rules are specified for all the types of GeneralName, the non-URI types
must be explicitly prohibited.

Because of the extra unnecessary complexity of GeneralName, I propose
eliminating its use here, with the following replacement extension
definitions:

    AccessDescription ::= SEQUENCE OF IA5String

    SubjectInfoAccess ::= SEQUENCE SIZE (1..MAX) OF AccessDescription

    AuthorityInfoAccess ::= SEQUENCE SIZE (1..MAX) OF {
	authorityInfo    [0] AccessDescription OPTIONAL,
	certStatus       [1] AccessDescription OPTIONAL }

Comments?

Dave Kemp

Date: Thu, 26 Jun 97 10:25:53 CST
From: "Eric Leighninger" <[email-masked]>
To: [email-masked]
Subject: Subscription to PKIX Working Group

     subscribe [email-masked] ietf-pkix

From: [email-masked] (Amit Kapoor)
Subject: More stuff on ipki3cmp-02.txt
To: [email-masked] (pkix)
Date: Wed, 25 Jun 1997 15:30:54 -0700 (PDT)
Content-Length: 589

Couple more things:

1.	Section 3.1.1 Page 17

	Regards the sender field it says, if nothing about the
	sender is known to the sending entity, then the "sender"
	field must contain a "NULL" value.

	Why not make the sender field optional too?  A encoded
	SEQUENCE OF relative distinguished name with length 0
	does not buy you anything.

2.	Use of UTCTime

	The draft is making liberal use of it :).  If we cannot
	change it to GeneralizedTime, then we should change it
	to CertificateValidityDate (CHOICE UTCTime, GeneralizedTime)
	(maybe call it ValidityDate instead).

	cheers-

Amit

From: [email-masked] (Amit Kapoor)
Subject: CMP Spec
To: [email-masked] (pkix)
Date: Wed, 25 Jun 1997 13:00:46 -0700 (PDT)
Content-Length: 1417

Hi,

Is is too late to request changes to the basic
pdu structure in the CMP (draft 02.txt)?

Anyways I think it might help if the structure
of the PKIMessage is simplified a little more.
Here is my proposal and reasons:

	PKIMessage ::= SEQUENCE {
		info		PKIMessageInfo,
		protection [0]	Protection OPTIONAL,
		extraCerts [1]  SEQUENCE OF Certificate OPTIONAL
	}

	PKIMessageInfo ::= SEQUENCE {
		header		PKIHeader,
		body		PKIBody
	}

	Protection ::= SEQUENCE {
		algId		AlgorithmIdentifier,
		signature	BIT STRING
	}

	PKIHeader remains the same except for removal
	of protectionAlg which has been moved to Protection as
	algId.

	My reasons are as follows:

1.	To calculate the signature on the current construct,
	an implementor will have to create a new structure
	SEQUENCE { PKIHeader, PKIBody } and then discard it.
	Instead in the above case the structure is created
	only once and used in the message itself.

2.	The check for signature is done only via one structure
	instead of thru two (PKIHeader.protectionAlg & protection),
	making it much easier.

	I have not understood the use of extraCerts yet and that
	is why I have left them the way they are, otherwise it
	also can be moved inside PKIMessageInfo.  I am looking at
	this from an implementation point of view and this does
	not change the semantics.

	A question:

1.	Does the module have IMPLICIT tags as defined for
	part1?

	Thanks.

Amit

Comments: Authenticated sender is <[email-masked]>
From: Nick Pope <[email-masked]>
To: Tim Dierks <[email-masked]>
Date: Wed, 25 Jun 1997 16:04:47 +0000
Subject: Re: basic constraints?
CC: [email-masked]
Priority: normal

In reply to your message of 25 Jun 97, 3:40:

> Several questions and comment regading basic constraints:
> 
> Q: How do you count the depth of a certification path? Is a simple
> single-CA model (self-signed root CA signs leaf cert- now that's a
> small tree) a path depth of 0, 1, or 2? (or 7, for all I know). Also,
> how does this work for sub-CAs? If I have the following chain:
>
This is fuller explained in the X.509 '97 base standard than in the 
PKIX document.   It states "Value 0 indicates that the subject of this 
certificate may issue certificates only to end-entities and not to 
further CAs."

>     Root - CA1 - CA2 - Leaf

Thus in your example:

Certificate Subject   PathLenConstraint (min value)
  Leaf                     Not present
  CA2                     0
  CA1                     1
  Root                     2
> 
> What are the minimum valid values for the CA's pathLenConstraint?
> Also, if the optional pathLenConstraint is missing, what does this
> imply? No limit?

Yes if not present then no limit.
> 
> C: Basic constraints should probably be mentioned in section 6,
> Certificate Path Validation.
> 
Quickly looking through the PKIX part 1 section 6 there seems to be 
some major discrepancies between this and the equivalent clause 12.4 in 
X.509 (e.g. it refers to the "key usage restiction extension" which 
no longer exists).

I would suggest that you refer to the '97 version of the X.509 text for 
the definitive use of X.509 fields including the use of basic 
constraints.

Nick Pope

-------------------------------------

Security & Standards
Suite A
191 Moulsham St.
Chelmsford
Essex
CM2 0LG
U.K.

Tel: +44 1245 495018
Fax: +44 1245 494517

Comments: Authenticated sender is <[email-masked]>
From: Nick Pope <[email-masked]>
To: Sharon Boeyen <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Date: Wed, 25 Jun 1997 16:04:46 +0000
Subject: RE: Authority Revocation List
CC: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Priority: normal

Sharon,

In reply to your message of 25 Jun 97, 8:42:

> There seems to still be a few glitches in my email connectivity since
> our move. I did receive your message (I think via the PKIX list) but
> was having trouble with the bull domain yesterday and couldn't send
> mail to or receive mail from it, so I'm not too sure if my original
> response got to the list. I think things are working better today -
> we'll see with this message I guess.
> 
I got your original response OK, and this one as your see - thanks.

> >Possibly my confusion lies with this sentence which I say is "out of 
> >place"
> 
> I do agree that the text could be clearer. My memory is sure not as
> good as it used to be, but think back to the April 96 meeting in
> Geneva. My earlier response (and your questions I believe) are
> assuming that the revocation lists are published in a Directory and
> therefore published in attributes and entries as defined in X.509 and
> X.521. We had a lot of discussion at that meeting about handling
> situations where the directory is not the publication mechanism. 
> 
> Isn't it the case that if revocation lists are published through some
> other mechanism (files on an http or ftp server for example) that
> there also needs to be a way to differentiate what is contained in the
> revocation list (between end user revocations and CA revocations)?
> Without the X.509 attribute types, wouldn't a revocation list
> published elsewhere be just the CertificateList syntax? In that case,
> the only way to differentiate between the two types of lists is to
> include the issuingDistributionPoint extension and the name field is
> unnecessary. Wasn't this a PKIX requirement at the time? Warwick?
> others?

I can't remember that far back but I had understood that 
cRLDistributionPoint and issuingDistributionPoint applied whenever 
there was a need to partition CRLs (either by subject community or 
by reason) and could well include a DirectoryName for the case where 
the part CRL is held in the directory.

However, I can see that it is not necessary where it is partitioned by 
CA/End user community and these are held in attributes of the CA entry 
as per CRL v1.

> 
> If you read the current text with a non directory publication method
> for crls in mind, I think it does make sense.
> 
> I'd like to hear from you and others who participated in those Geneva
> discussions though, because as they say - the memory is one of the
> first things to go :-)
> 
> >> >
> >> >This is followed by a statement "If this field is absent the CRL shall 
> >> >contain entries for all revoked unexpired certificates issued by the 
> >> >CRL issuer."  (By the way this sentence seems out of place where it is 
> >> >after the description of distributionPoint in the X.509 text).
> >> ...
... 
> >
> >My understanding from what you are saying and reading the standard is 
> >as follows:
> >
> >a) To issue two separate CRLs for users and CAs without using 
> >distribution points I must place these in CA entry attributes 
> >CertificateRevocationList and AttributeRevocationList with the 
> >issuingDistributionPoint containing just the elements 
> >onlyContainsUserCerts or onlyContainsCACerts.
> 
> If you are publishing your revocation lists in a directory using the
> attribute types defined in X.509, then the issuing distribution point
> extension is superfluous here and not required. 
> 

This is where I am not sure how the above sentence applies.  I read it 
to say that if the issuingDistributionPoint ("this field") is absent 
then the CRL must be complete.  However, I now see that it could also 
be read to mean if the distributionPoint component of the 
issuingDistributionPoint is absent (but the whole field present) then 
the CRL must be complete.

> >b) To do the same using distributionPoints then I also add the 
> >distributionPoint name in the issuingDistributionPoint as well as use 
> >the certificate extension field cRLDistributionPoint.  The 
> >CRL and ARL attributes should be used as above but held in the 
> >distributionPoint entry.
> 
> Yes (again assuming a directory is used).
> >
> >c) With a '97 CRL if the Issuing Distribution Point CRL extension is 
> >not present then both User and CA certificate revocations need to be 
> >present in the CRL and this is held in the CRL attribute.
> 
> No, if you are publishing in the directory you would use the two
> distinct attribute types and only need the distribution point
> extension if you are publishing in distribution point entries.

I now understand this interpretation but this still depends on the 
directory being trusted.  If I copy the value held in the 
AuthorityRevocationList into the CertificateRevocationList without 
using this extension then I can fool a user into believing that my 
(end user) certificate was not revoked.

Thus, I still prefer my original interpretation that it is the value of 
the "onlyContainsCACerts" which decides whether the CRL only contains 
CA certificates.  Not the fact whether it is placed in the 
AuthorityRevocationList or CertificateRevocationList attributes.  
However, I see it is reasonable to use these attributes to facilitate 
access to the required data.

> >
> >d) With a '93 CRL it is undefined whether CA revocations will be 
> >listed in the same CRL as user certificate revocations and hence in the 
> >general case both CRL and ARL attributes should be read.
> 
> I agree that the text doesn't strictly mandate what you put in each
> attribute, but believe that you would logically put the CA revocations
> in the ARL and user revocations in CRL.
> 
I think that it would be worth clarifying the situation for the '93. 
Unless it is clearly stated that for a complete list of user and CA 
revocations two CRLs need to be retrieved then an '93 implementation 
may be fooled into picking up just one CRL and believing that it has 
the complete list.

..... 

Nick

-------------------------------------

Security & Standards
Suite A
191 Moulsham St.
Chelmsford
Essex
CM2 0LG
U.K.

Tel: +44 1245 495018
Fax: +44 1245 494517

Reply-To: "Atila Xavier" <[email-masked]>
From: "Atila Xavier" <[email-masked]>
To: "Tim Dierks" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: basic constraints?
Date: Wed, 25 Jun 1997 11:09:34 -0300

>Several questions and comment regading basic constraints:
>
>Q: How do you count the depth of a certification path? Is a simple
>single-CA model (self-signed root CA signs leaf cert- now that's a =
small
>tree) a path depth of 0, 1, or 2? (or 7, for all I know). Also, how =
does
>this work for sub-CAs? If I have the following chain:
>
>    Root - CA1 - CA2 - Leaf
As the recommendation X.509 (in Amendment 1 to ITU-T Rec. X.509 -1993 E) =
says, this field gives the maximum number of CA-certificates that may =
follow a certificate in a certification path.=20
In your example, the minimum values would be:
Root: 2
CA1: 1
CA2: 0

Leaf: not present

It's important to remember that this component shall be present only if =
the "cA"  component is set to true.

>What are the minimum valid values for the CA's pathLenConstraint?=20
The minimum value is 0, meaning that the subject of the certificate may =
issue certificates only to end-entities and not to further CAs.

>Also, if
>the optional pathLenConstraint is missing, what does this imply? No =
limit?
If this field doesn't appear in any certificate of a certification path, =
there is no limit to the allowed length of the certification path. If =
it's set in any certificate, that value will impose the limit of the =
certification path.=20
So, talking about your example, the values would be:
Root: 2
CA1: not present
CA2: not present
Leaf: not present
The value for the root certificate defines the maximum length for the =
certification path.

Atila.
System Engineer
CertiSign - Certificadora Digital Ltda.

Date: Wed, 25 Jun 1997 09:52:30 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: basic constraints?

The X.509 documentation is clear on this, but it hasn't been copied or
paraphrased into PKIX yet.

  "The pathLenConstraint component shall be present only if cA is set to
  true. It gives the maximum number of CA-certificates that may follow
  this certificate in a certification path. Value 0 indicates that the
  subject of this certificate may issue certificates only to end-entities
  and not to further CAs. If no pathLenConstraint field appears in any
  certificate of a certification path, there is no limit to the allowed
  length of the certification path."

That said, the BasicConstraints extension is (IMO) an example of needless
complexity.  It is defined as:

  BasicConstraints ::= SEQUENCE {
      cA                 BOOLEAN DEFAULT FALSE,
      pathLenConstraint  INTEGER (0..MAX) OPTIONAL }

where it could have been defined much more simply as:

  BasicConstraints ::= INTEGER (0..MAX)

with the integer representing the total number of certs (including the
leaf) that may follow this certificate in the certification path.  I.e.
0 indicates not-a-CA, 1 indicates only end-entity certs may be issued,
2 indicates only one CA may follow, etc.

This is one example (the AuthorityKeyIdentifier extension is a more
egregious one) where I agree with the SPKI criticism that the use of
ASN.1 seduces designers into unnecessarily obtuse constructs.

From: Sharon Boeyen <[email-masked]>
To: "'Nick Pope'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Authority Revocation List
Date: Wed, 25 Jun 1997 08:42:23 -0400

Nick,

There seems to still be a few glitches in my email connectivity since
our move. I did receive your message (I think via the PKIX list) but was
having trouble with the bull domain yesterday and couldn't send mail to
or receive mail from it, so I'm not too sure if my original response
got to the list. I think things are working better today - we'll see
with this message I guess.

Comments interspersed below.

------------------
NOTE: WE'VE MOVED 

Sharon Boeyen                  
Entrust Technologies
750 Heron Road, Suite E08
Ottawa, Ontario Canada K1V 1A7

mailto:[email-masked]       Tel: (613) 247-3181 
http://www.entrust.com          Fax: (613) 247-3690 
         Orchestrating Enterprise Security

>----------
>From: 	Nick Pope[SMTP:[email-masked]]
>Sent: 	June 24, 1997 12:20 PM
>To: 	Sharon Boeyen
>Cc: 	[email-masked]'; [email-masked]'
>Subject: 	RE: Authority Revocation List
>
>Sharon
>
>In reply to your message of 24 Jun 97, 10:09:
>
>Thanks for your input.
>
>Possibly my confusion lies with this sentence which I say is "out of 
>place"

I do agree that the text could be clearer. My memory is sure not as good
as it used to be, but think back to the April 96 meeting in Geneva. My
earlier response (and your questions I believe) are assuming that the
revocation lists are published in a Directory and therefore published in
attributes and entries as defined in X.509 and X.521. We had a lot of
discussion at that meeting about handling situations where the directory
is not the publication mechanism. 

Isn't it the case that if revocation lists are published through some
other mechanism (files on an http or ftp server for example) that there
also needs to be a way to differentiate what is contained in the
revocation list (between end user revocations and CA revocations)?
Without the X.509 attribute types, wouldn't a revocation list published
elsewhere be just the CertificateList syntax? In that case, the only way
to differentiate between the two types of lists is to include the
issuingDistributionPoint extension and the name field is unnecessary.
Wasn't this a PKIX requirement at the time? Warwick? others?

If you read the current text with a non directory publication method for
crls in mind, I think it does make sense.

I'd like to hear from you and others who participated in those Geneva
discussions though, because as they say - the memory is one of the first
things to go :-)

>> >
>> >This is followed by a statement "If this field is absent the CRL shall 
>> >contain entries for all revoked unexpired certificates issued by the 
>> >CRL issuer."  (By the way this sentence seems out of place where it is 
>> >after the description of distributionPoint in the X.509 text).
>> 
>> In the version I have this phrase follows the distributionPoint
>> element of the syntax only and has nothing to do with whether crl or
>> arl are included.
>
>This is the same with my copy.  However, because the sentence refers to 
>"this field" I presumed it applied to the whole 
>"issuingDistributionPoint" field.  Not to the distributionPoint 
>component of that field.  Hence I thought it was more appropriate above 
>the ASN.1 description.  If it applies just to the distributionPoint 
>then it imples that onlyContainsCACerts can't be used without 
>using distributionPoints.
>
>My understanding from what you are saying and reading the standard is 
>as follows:
>
>a) To issue two separate CRLs for users and CAs without using 
>distribution points I must place these in CA entry attributes 
>CertificateRevocationList and AttributeRevocationList with the 
>issuingDistributionPoint containing just the elements 
>onlyContainsUserCerts or onlyContainsCACerts.

If you are publishing your revocation lists in a directory using the
attribute types defined in X.509, then the issuing distribution point
extension is superfluous here and not required. 
>
>b) To do the same using distributionPoints then I also add the 
>distributionPoint name in the issuingDistributionPoint as well as use 
>the certificate extension field cRLDistributionPoint.  The 
>CRL and ARL attributes should be used as above but held in the 
>distributionPoint entry.

Yes (again assuming a directory is used).
>
>c) With a '97 CRL if the Issuing Distribution Point CRL extension is 
>not present then both User and CA certificate revocations need to be 
>present in the CRL and this is held in the CRL attribute.

No, if you are publishing in the directory you would use the two
distinct attribute types and only need the distribution point extension
if you are publishing in distribution point entries. 
>
>d) With a '93 CRL it is undefined whether CA revocations will be 
>listed in the same CRL as user certificate revocations and hence in the 
>general case both CRL and ARL attributes should be read.

I agree that the text doesn't strictly mandate what you put in each
attribute, but believe that you would logically put the CA revocations
in the ARL and user revocations in CRL.

>
>Am I correct ?
>
>
>
>Nick
>
>
>> Hoyt, I tried to access the bull server to make sure
>> I have the right text and I can't - keep getting errors saying check
>> the address - I used:  ftp://ftp.bull.com?
>> 
>> Re the "out of place" I'm not sure I agree - this is the description
>> of the extension field to be contained in a revocation list - that is
>> not the same as the description of the crlDistributionPoint object
>> class which describes directory entries holding such lists.  
>> >
>> >How is it normally expected to handle CA revocations?
>> >
>> >Is it expected that CRLs normally hold both end user and CA 
>> >revocations?
>> 
>> We use crl for end-user cert revocation and arl for CA cert revocation
>> - both can be placed in distribution points.
>> >
>> >If it is required to handle CA revocations separately should the CRL be 
>> >placed in the Authority Revocation List attribute or should a 
>> >distribution point be used?
>> >
>> >Is the Authority Revocation List attribute still relevant ?
>> 
>> Yes
>> >
>> >Any views would be welcomed.
>> 
>> I'm not sure where the confusion is, but to see the whole picture with
>> respect to distribution points and their use by certificate using
>> systems or relying parties, you need to look at the certificate
>> extension (crlDistributionPoints) and the revocation list extension
>> (issuingDistributionPoint) - both defined in 509. If you are using a
>> directory as a repository for certificates and crls you also need to
>> look at the attribute and object class definitions. For revocation
>> lists this includes both the arl and cxrl defined in X.509 and the
>> certificationAuthority, certificationAuthority-V2, and
>> cRLDistributionPoint object classes defined in X.521.
>> 
>> 
>> >
>> >Nick Pope
>> >
>> >-------------------------------------
>> >
>> >
>> >Security & Standards
>> >Suite A
>> >191 Moulsham St.
>> >Chelmsford
>> >Essex
>> >CM2 0LG
>> >U.K.
>> >
>> >Tel: +44 1245 495018
>> >Fax: +44 1245 494517
>> >
>
>-------------------------------------
>
>
>Security & Standards
>Suite A
>191 Moulsham St.
>Chelmsford
>Essex
>CM2 0LG
>U.K.
>
>Tel: +44 1245 495018
>Fax: +44 1245 494517
>

Date: Wed, 25 Jun 1997 03:40:31 -0700
To: [email-masked]
From: Tim Dierks <[email-masked]>
Subject: basic constraints?

Several questions and comment regading basic constraints:

Q: How do you count the depth of a certification path? Is a simple
single-CA model (self-signed root CA signs leaf cert- now that's a small
tree) a path depth of 0, 1, or 2? (or 7, for all I know). Also, how does
this work for sub-CAs? If I have the following chain:

    Root - CA1 - CA2 - Leaf

What are the minimum valid values for the CA's pathLenConstraint? Also, if
the optional pathLenConstraint is missing, what does this imply? No limit?

C: Basic constraints should probably be mentioned in section 6, Certificate
Path Validation.

Thanks!
 - Tim

Tim Dierks - [email-masked] - www.consensus.com
     Software Haruspex - Consensus Development
  Developer of SSL Plus: SSL 3.0 Integration Suite

Date: Tue, 24 Jun 1997 19:20:04 -0700
To: [email-masked] (David P. Kemp)
From: Warwick Ford <[email-masked]>
Subject: Re: PKIX Part 1 Certificate Policies extension
Cc: [email-masked]

Actually, I believe we should just make the type OBJECT IDENTIFIER, rather
than try to hardwire in a fixed set.  The PKIX syntax should not prohibit
the use of private or other policy qualifiers if applications and policy
writers wish to use them.

Warwick 

At 11:13 AM 6/24/97 -0400, David P. Kemp wrote:
>
>Prodded by the release of the new Part 3, I've been working on examples
>for Part 1, and have a question about the syntax of the Certificate
>Policies extension.
>
>The text of section 4.2.1.5 shows:
>
>  PolicyQualifierId ::= ENUMERATED { id-pkix-cps, id-pkix-unotice }
>
>where id-pkix-cps and id-pkix-unotice are OIDs.  I'm not sure this is
>legal syntax - isn't ENUMERATED required to have integer values, not OIDs?
>But the use of the pkix OIDs agrees with the text in X.509, which says:
>
>   CERT-POLICY-QUALIFIER ::= CLASS {
>        &id           OBJECT IDENTIFIER UNIQUE,
>        &Qualifier    OPTIONAL }
>
>
>However, PKIX part 1 section 9 (the ASN.1 appendix) says:
>
>  PolicyQualifierID ::= ENUMERATED {
>        qualId1 (1), qualId2 (2), ... qualId5 (5) }
>
>
>I believe section 9 is incorrect, and that section 4 is only half
>correct - the ENUMERATED should be replaced by a CHOICE.
>
>Comments?
>
>Dave Kemp
>
>
---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
   [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716
---------------------------------------------------------------------

Date: Tue, 24 Jun 1997 11:17:45 -0500
To: Nick Pope <[email-masked]>
From: "Robert W. Shirey" <[email-masked]>
Subject: Re: Authority Revocation List
Cc: [email-masked], [email-masked]

Nick,

I'll let Warwick reply to your questions, since he is the rapporteur for
the standard.  I just wanted to say hello, and that I have not seen you for
a long time.

(Maybe Warwick will suggest that you get his new book, which is "reviewed"
below by Hoyt Kesterson.)

Regards, -Rob-

[email-masked],  Tel 703-284-4641, Recept 284-4600,  Fax 284-2766
Robert W. Shirey,  BBN Corporation,  Mail Stop 30/12B2, Suite 1200
1300 North Seventeenth Street, Arlington, Virginia  22209-3801 USA

From: [email-masked]
To: [email-masked]
Subject: fyi - warwick's new book
Date: Friday, June 20, 1997 7:20PM

warwick ford's new book (co-authored with michael baum) has just been
published.
i have my copy. it does a good job covering those things we added to x.509
over
the last three years. it also covers the legal understandings that must be
reached for electronic commerce.

i'm not getting a commission but when someone asks about the standards, i
would
rather refer them to david's or warwick's books rather than the standards
themselves.

on my recommendation one person in my company has already purchased the
book. he
said that it was not yet on the shelves but had to be special ordered.

here's the info for ordering (i apologize for not having european ordering
information)

Title: "Secure Electronic Commerce: Building the Infrastructure for Digital
Signatures and Encrypytion"
Authors: Warwick Ford and Michael S. Baum
Publisher: Prentice-Hall
ISBN:  0-13-476342-4
Price: $48.00
Telephone orders: (US) 1-800-947-7700; (Can) 1-800-567-3800

   hoyt

Comments: Authenticated sender is <[email-masked]>
From: Nick Pope <[email-masked]>
To: Sharon Boeyen <[email-masked]>
Date: Tue, 24 Jun 1997 16:20:04 +0000
Subject: RE: Authority Revocation List
CC: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Priority: normal

Sharon

In reply to your message of 24 Jun 97, 10:09:

Thanks for your input.

Possibly my confusion lies with this sentence which I say is "out of 
place" 

> >
> >This is followed by a statement "If this field is absent the CRL shall 
> >contain entries for all revoked unexpired certificates issued by the 
> >CRL issuer."  (By the way this sentence seems out of place where it is 
> >after the description of distributionPoint in the X.509 text).
> 
> In the version I have this phrase follows the distributionPoint
> element of the syntax only and has nothing to do with whether crl or
> arl are included.

This is the same with my copy.  However, because the sentence refers to 
"this field" I presumed it applied to the whole 
"issuingDistributionPoint" field.  Not to the distributionPoint 
component of that field.  Hence I thought it was more appropriate above 
the ASN.1 description.  If it applies just to the distributionPoint 
then it imples that onlyContainsCACerts can't be used without 
using distributionPoints.

My understanding from what you are saying and reading the standard is 
as follows:

a) To issue two separate CRLs for users and CAs without using 
distribution points I must place these in CA entry attributes 
CertificateRevocationList and AttributeRevocationList with the 
issuingDistributionPoint containing just the elements 
onlyContainsUserCerts or onlyContainsCACerts.

b) To do the same using distributionPoints then I also add the 
distributionPoint name in the issuingDistributionPoint as well as use 
the certificate extension field cRLDistributionPoint.  The 
CRL and ARL attributes should be used as above but held in the 
distributionPoint entry.

c) With a '97 CRL if the Issuing Distribution Point CRL extension is 
not present then both User and CA certificate revocations need to be 
present in the CRL and this is held in the CRL attribute.

d) With a '93 CRL it is undefined whether CA revocations will be 
listed in the same CRL as user certificate revocations and hence in the 
general case both CRL and ARL attributes should be read.

Am I correct ?

Nick

> Hoyt, I tried to access the bull server to make sure
> I have the right text and I can't - keep getting errors saying check
> the address - I used:  ftp://ftp.bull.com?
> 
> Re the "out of place" I'm not sure I agree - this is the description
> of the extension field to be contained in a revocation list - that is
> not the same as the description of the crlDistributionPoint object
> class which describes directory entries holding such lists.  
> >
> >How is it normally expected to handle CA revocations?
> >
> >Is it expected that CRLs normally hold both end user and CA 
> >revocations?
> 
> We use crl for end-user cert revocation and arl for CA cert revocation
> - both can be placed in distribution points.
> >
> >If it is required to handle CA revocations separately should the CRL be 
> >placed in the Authority Revocation List attribute or should a 
> >distribution point be used?
> >
> >Is the Authority Revocation List attribute still relevant ?
> 
> Yes
> >
> >Any views would be welcomed.
> 
> I'm not sure where the confusion is, but to see the whole picture with
> respect to distribution points and their use by certificate using
> systems or relying parties, you need to look at the certificate
> extension (crlDistributionPoints) and the revocation list extension
> (issuingDistributionPoint) - both defined in 509. If you are using a
> directory as a repository for certificates and crls you also need to
> look at the attribute and object class definitions. For revocation
> lists this includes both the arl and cxrl defined in X.509 and the
> certificationAuthority, certificationAuthority-V2, and
> cRLDistributionPoint object classes defined in X.521.
> 
> 
> >
> >Nick Pope
> >
> >-------------------------------------
> >
> >
> >Security & Standards
> >Suite A
> >191 Moulsham St.
> >Chelmsford
> >Essex
> >CM2 0LG
> >U.K.
> >
> >Tel: +44 1245 495018
> >Fax: +44 1245 494517
> >

-------------------------------------

Security & Standards
Suite A
191 Moulsham St.
Chelmsford
Essex
CM2 0LG
U.K.

Tel: +44 1245 495018
Fax: +44 1245 494517

Date: Tue, 24 Jun 1997 11:13:52 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: PKIX Part 1 Certificate Policies extension

Prodded by the release of the new Part 3, I've been working on examples
for Part 1, and have a question about the syntax of the Certificate
Policies extension.

The text of section 4.2.1.5 shows:

  PolicyQualifierId ::= ENUMERATED { id-pkix-cps, id-pkix-unotice }

where id-pkix-cps and id-pkix-unotice are OIDs.  I'm not sure this is
legal syntax - isn't ENUMERATED required to have integer values, not OIDs?
But the use of the pkix OIDs agrees with the text in X.509, which says:

   CERT-POLICY-QUALIFIER ::= CLASS {
        &id           OBJECT IDENTIFIER UNIQUE,
        &Qualifier    OPTIONAL }

However, PKIX part 1 section 9 (the ASN.1 appendix) says:

  PolicyQualifierID ::= ENUMERATED {
        qualId1 (1), qualId2 (2), ... qualId5 (5) }

I believe section 9 is incorrect, and that section 4 is only half
correct - the ENUMERATED should be replaced by a CHOICE.

Comments?

Dave Kemp

Old-To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]
From: [email-masked]
Reply-To: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-ipki3cmp-02.txt
Date: Tue, 24 Jun 1997 10:24:06 -0400
To: [email-masked]

--NextPart

 A Revised 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 Public Key Infrastructure  Part III: 
                   Certificate Management Protocols                        
       Author(s) : C. Adams, S. Farrell
       Filename  : draft-ietf-pkix-ipki3cmp-02.txt
       Pages     : 68
       Date      : 06/23/1997

This is a draft of the Internet Public Key Infrastructure (X.509) 
Certificate Management Protocols. Protocol messages are defined for all 
relevant aspects of certificate creation and management.                   

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-ipki3cmp-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-pkix-ipki3cmp-02.txt
 
Internet-Drafts directories are located at:	
	                                                
     o  Africa:  ftp.is.co.za                    
	                                                
     o  Europe:  ftp.nordu.net            	
                 ftp.nis.garr.it                 
	                                                
     o  Pacific Rim: munnari.oz.au               
	                                                
     o  US East Coast: ds.internic.net           
	                                                
     o  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-ipki3cmp-02.txt".
							
NOTE: The mail server at ds.internic.net 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-ipki3cmp-02.txt

--OtherAccess
Content-Type:   Message/External-body;
        name="draft-ietf-pkix-ipki3cmp-02.txt";
        site="ds.internic.net";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--OtherAccess--

--NextPart--

To: [email-masked]
cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-ipki3cmp-02.txt
Date: Tue, 24 Jun 1997 10:24:06 -0400
Sender: [email-masked]

--NextPart

 A Revised 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 Public Key Infrastructure  Part III: 
                   Certificate Management Protocols                        
       Author(s) : C. Adams, S. Farrell
       Filename  : draft-ietf-pkix-ipki3cmp-02.txt
       Pages     : 68
       Date      : 06/23/1997

This is a draft of the Internet Public Key Infrastructure (X.509) 
Certificate Management Protocols. Protocol messages are defined for all 
relevant aspects of certificate creation and management.                   

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-ipki3cmp-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-pkix-ipki3cmp-02.txt
 
Internet-Drafts directories are located at:	
	                                                
     o  Africa:  ftp.is.co.za                    
	                                                
     o  Europe:  ftp.nordu.net            	
                 ftp.nis.garr.it                 
	                                                
     o  Pacific Rim: munnari.oz.au               
	                                                
     o  US East Coast: ds.internic.net           
	                                                
     o  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-ipki3cmp-02.txt".
							
NOTE: The mail server at ds.internic.net 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-ipki3cmp-02.txt

--OtherAccess
Content-Type:   Message/External-body;
        name="draft-ietf-pkix-ipki3cmp-02.txt";
        site="ds.internic.net";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--OtherAccess--

--NextPart--

Date: Tue, 24 Jun 1997 10:46:55 -0400
To: Nick Pope <[email-masked]>
From: Santosh Chokhani <[email-masked]>
Subject: Re: Authority Revocation List
Cc: [email-masked], [email-masked]

It is there for performance reasons.  In a chain of certificates, typically,
all but the last certificate are CA certificates.  The number of CAs and
their revocation rates are expected to be orders and orders of magnitude
lower than those for end entities.  Thus, getting the relevant authority
CRLs (which will be empty or very sparse) will reduce communication overhead
and processing load.

At 01:41 PM 6/24/97 +0000, Nick Pope wrote:
>Looking through the X.509 v3 text the situation on handling revocation 
>information on CAs seems to be unclear.
>
>X.509 had two attributes to hold revocation lists:
>a) Certificate Revocation List
>b) Authority Revocation List
>
>the v3 extension Issuing Distribution Point has two flags:
>  onlyContainsUserCerts and onlyContainsCACerts
>
>This is followed by a statement "If this field is absent the CRL shall 
>contain entries for all revoked unexpired certificates issued by the 
>CRL issuer."  (By the way this sentence seems out of place where it is 
>after the description of distributionPoint in the X.509 text).
>
>How is it normally expected to handle CA revocations?
>
>Is it expected that CRLs normally hold both end user and CA 
>revocations?
>
>If it is required to handle CA revocations separately should the CRL be 
>placed in the Authority Revocation List attribute or should a 
>distribution point be used?
>
>Is the Authority Revocation List attribute still relevant ?
>
>Any views would be welcomed.
>
>Nick Pope
>
>-------------------------------------
>
>
>Security & Standards
>Suite A
>191 Moulsham St.
>Chelmsford
>Essex
>CM2 0LG
>U.K.
>
>Tel: +44 1245 495018
>Fax: +44 1245 494517
>
>

-------------------------------------------------
Santosh Chokhani
CygnaCom Solutions, Inc.
Suite 100 West
7927 Jones Branch Drive
McLean, Virginia 22102-3305
(703) 848 - 0883
[email-masked]

From: "Miklos, Sue A." <[email-masked]>
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Nick Pope <[email-masked]>
Cc: "'bgreenle'" <[email-masked]>
Subject: RE: Authority Revocation List
Date: Tue, 24 Jun 97 09:17:00 EDT
Encoding: 61 TEXT

Hi Nick...

We've briefly looked at this, since arl is a mandatory element in the object 
class.  I think it would be very useful to use it for revoked CA 
certificates instead of requiring validation software to parse through a 
list composed of both end-user and CA certificates.  It's my understanding 
that TC68 is working up standards for Certificate management, but I haven't 
seen output/recommendations about this particular issue.

Sandi
 ----------
From: Nick Pope
To: [email-masked]; [email-masked]
Subject: Authority Revocation List
Date: Tuesday, June 24, 1997 9:41AM

Looking through the X.509 v3 text the situation on handling revocation
information on CAs seems to be unclear.

X.509 had two attributes to hold revocation lists:
a) Certificate Revocation List
b) Authority Revocation List

the v3 extension Issuing Distribution Point has two flags:
  onlyContainsUserCerts and onlyContainsCACerts

This is followed by a statement "If this field is absent the CRL shall
contain entries for all revoked unexpired certificates issued by the
CRL issuer."  (By the way this sentence seems out of place where it is
after the description of distributionPoint in the X.509 text).

How is it normally expected to handle CA revocations?

Is it expected that CRLs normally hold both end user and CA
revocations?

If it is required to handle CA revocations separately should the CRL be
placed in the Authority Revocation List attribute or should a
distribution point be used?

Is the Authority Revocation List attribute still relevant ?

Any views would be welcomed.

Nick Pope

 -------------------------------------

Security & Standards
Suite A
191 Moulsham St.
Chelmsford
Essex
CM2 0LG
U.K.

Tel: +44 1245 495018
Fax: +44 1245 494517

From: Sharon Boeyen <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "'Nick Pope'" <[email-masked]>
Subject: RE: Authority Revocation List
Date: Tue, 24 Jun 1997 10:09:33 -0400

The two attributes certificateRevocationList and authorityRevocationList
apply now the same way they did back in the 1988 standard. The thing
that has changed in 1997 is the entries which might hold these
attributes - nothing else. ARLs are most useful when validation
certification paths.  

These attributes may be held in the CA entry or in entries of object
class crlDistributionPoint - that doesn't affect what the attributes are
for. We use both ARLs and CRLs and use distribution points, so no it's
not obsolete.  Additional notes below.

If I'm missing your point, let me know.
 
------------------
NOTE: WE'VE MOVED 

Sharon Boeyen                  
Entrust Technologies
750 Heron Road, Suite E08
Ottawa, Ontario Canada K1V 1A7

mailto:[email-masked]       Tel: (613) 247-3181 
http://www.entrust.com          Fax: (613) 247-3690 
         Orchestrating Enterprise Security

>----------
>From: 	Nick Pope[SMTP:[email-masked]]
>Sent: 	June 24, 1997 9:41 AM
>To: 	[email-masked]; [email-masked]
>Subject: 	Authority Revocation List
>
>Looking through the X.509 v3 text the situation on handling revocation 
>information on CAs seems to be unclear.
>
>X.509 had two attributes to hold revocation lists:
>a) Certificate Revocation List
>b) Authority Revocation List
>
>the v3 extension Issuing Distribution Point has two flags:
>  onlyContainsUserCerts and onlyContainsCACerts
>
>This is followed by a statement "If this field is absent the CRL shall 
>contain entries for all revoked unexpired certificates issued by the 
>CRL issuer."  (By the way this sentence seems out of place where it is 
>after the description of distributionPoint in the X.509 text).

In the version I have this phrase follows the distributionPoint element
of the syntax only and has nothing to do with whether crl or arl are
included. Hoyt, I tried to access the bull server to make sure I have
the right text and I can't - keep getting errors saying check the
address - I used:  ftp://ftp.bull.com?

Re the "out of place" I'm not sure I agree - this is the description of
the extension field to be contained in a revocation list - that is not
the same as the description of the crlDistributionPoint object class
which describes directory entries holding such lists.  
>
>How is it normally expected to handle CA revocations?
>
>Is it expected that CRLs normally hold both end user and CA 
>revocations?

We use crl for end-user cert revocation and arl for CA cert revocation -
both can be placed in distribution points.
>
>If it is required to handle CA revocations separately should the CRL be 
>placed in the Authority Revocation List attribute or should a 
>distribution point be used?
>
>Is the Authority Revocation List attribute still relevant ?

Yes
>
>Any views would be welcomed.

I'm not sure where the confusion is, but to see the whole picture with
respect to distribution points and their use by certificate using
systems or relying parties, you need to look at the certificate
extension (crlDistributionPoints) and the revocation list extension
(issuingDistributionPoint) - both defined in 509. If you are using a
directory as a repository for certificates and crls you also need to
look at the attribute and object class definitions. For revocation lists
this includes both the arl and cxrl defined in X.509 and the
certificationAuthority, certificationAuthority-V2, and
cRLDistributionPoint object classes defined in X.521.

>
>Nick Pope
>
>-------------------------------------
>
>
>Security & Standards
>Suite A
>191 Moulsham St.
>Chelmsford
>Essex
>CM2 0LG
>U.K.
>
>Tel: +44 1245 495018
>Fax: +44 1245 494517
>

Comments: Authenticated sender is <[email-masked]>
From: Nick Pope <[email-masked]>
To: [email-masked], [email-masked]
Date: Tue, 24 Jun 1997 13:41:42 +0000
Subject: Authority Revocation List
Priority: normal

Looking through the X.509 v3 text the situation on handling revocation 
information on CAs seems to be unclear.

X.509 had two attributes to hold revocation lists:
a) Certificate Revocation List
b) Authority Revocation List

the v3 extension Issuing Distribution Point has two flags:
  onlyContainsUserCerts and onlyContainsCACerts

This is followed by a statement "If this field is absent the CRL shall 
contain entries for all revoked unexpired certificates issued by the 
CRL issuer."  (By the way this sentence seems out of place where it is 
after the description of distributionPoint in the X.509 text).

How is it normally expected to handle CA revocations?

Is it expected that CRLs normally hold both end user and CA 
revocations?

If it is required to handle CA revocations separately should the CRL be 
placed in the Authority Revocation List attribute or should a 
distribution point be used?

Is the Authority Revocation List attribute still relevant ?

Any views would be welcomed.

Nick Pope

-------------------------------------

Security & Standards
Suite A
191 Moulsham St.
Chelmsford
Essex
CM2 0LG
U.K.

Tel: +44 1245 495018
Fax: +44 1245 494517

From: Carlisle Adams <[email-masked]>
To: "'Stephen Kent'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: PKIX-3...
Date: Mon, 23 Jun 1997 13:57:33 -0400

Hi Stephen, Warwick,

I have (finally!) gotten a chance to update the PKIX Part 3 document
with respect to the comments received at the Memphis meeting.  The sense
I got was that people were basically happy with the previous set of
changes and only wanted some minor clarifications put in.  This has now
been done, along with extensive editing of the tables in the Appendix
(to ensure that they meet the Internet Draft / .txt guidelines) and the
addition of e-mail and http transport protocols in Section 5.

The draft was submitted this morning and so should soon show up in the
usual repositories.

My understanding at Memphis was that (like Part 1) once the minor
revisions had been made the document would go to Working Group last
call.  Is this still the plan?

--------------------------------------------
Carlisle Adams
Entrust Technologies
[email-masked]
--------------------------------------------

To: [email-masked]
Date: Fri, 20 Jun 1997 18:23:14 JST
From: Hideki Kushima <[email-masked]>

subscribe [email-masked] ietf-pkix

Date: 19 Jun 97 16:29:00 -0700
From: [email-masked]
To: [email-masked]
Subject: How to UNSUBSCRIBE yourself from this list..

Please use the [email-masked] address !

If you ever want to remove yourself from this mailing list,
send the following command in email to "[email-masked]"
(NOT [email-masked]):

    unsubscribe <your e-mail-id> ietf-pkix

Date: Thu, 19 Jun 97 15:33:25 PDT
From: [email-masked] (Matt Bishop)
To: [email-masked]
Subject: CFP: Symposium on Network and Distributed System Security (Mar. 1998)

CALL FOR PAPERS

The Internet Society Symposium on Network and Distributed System Security

Where: San Diego, California
When: March 1998

GOAL: The symposium will foster information exchange between hardware and
software developers of network and distributed system security services.
The intended audience is those who are interested in the practical aspects
of network and distributed system security, focusing on actual system
design and implementation, rather than theory.  Encouraging and enabling
the Internet community to apply, deploy, and advance the state of available
security technology is the major focus of symposium.  Symposium proceedings
will be published by the Internet Society.  Topics for the symposium
include, but are not limited to, the following:

* Architectures for large-scale, heterogeneous distributed systems
* Security in malleable systems: mobile code, mobile agents, dynamic policy
  updates, etc.
* Special problems: e.g. interplay between security goals and other goals --
  efficiency, reliability, interoperability, resource sharing, and cost.
* Integrating security services with system and application security
  facilities and with application protocols, including message handling,
  file transport, remote file access,  directories, time synchronization,
  data base management, routing, voice and video multicast, network
  management, boot services, and mobile computing.
* Fundamental services:  authentication, integrity, confidentiality,
  authorization, non-repudiation, and availability.
* Supporting mechanisms and APIs: key management and certification
  infrastructures, audit, and intrusion detection.
* Telecommunications security, especially for emerging technologies -- very
  large systems like the Internet, high-speed systems like the gigabit 
  testbeds, wireless systems, and personal communication systems.
* Controls: firewalls, packet filters, application gateways
* Object security and security objects
* Network information resources and tools such as World Wide Web (WWW),
  Gopher, Archie, and WAIS.
* Electronic commerce:  payment services, fee-for-access, EDI, notary;
  endorsement, licensing, bonding, and other forms of assurance; intellectual 
  property protections

GENERAL CHAIR:
	David Balenson, Trusted Information Systems
PROGRAM CHAIRS:
	Matt Bishop, University of California at Davis
	Steve Kent, BBN
PROGRAM COMMITTEE:
	Steve Bellovin, AT&T Labs -- Research
	Doug Engert, Argonne National Laboratories
	Warwick Ford, VeriSign
	Li Gong, JavaSoft
	Rich Graveman, Bellcore
	Ari Juels, RSA Laboratories
	Tom Longstaff, CERT/CC
	Doug Maughan, National Security Agency
	Dan Nessett, 3Com Corporation
	Rich Parker, NATO
	Michael Roe, Cambridge University
	Rob Rosenthal, DARPA
	Wolfgang Schneider, GMD Darmstadt
	Christoph Schuba, Purdue University
	Win Treese, Open Market, Inc.
	Jonathan Trostle, Novell
	Gene Tsudik, USC/Information Sciences Institute
	Steve Welke, Institute for Defense Analyses
LOCAL ARRANGEMENTS CHAIR:
	Thomas Hutton, San Diego Supercomputer Center
PUBLICATIONS CHAIR:
	Steve Welke, Institute for Defense Analyses
LOGISTICS CHAIR:
	Torryn Brazell, Internet Society

SUBMISSIONS: The committee invites technical papers and panel
proposals, for topics of technical and general interest.  Technical
papers should be 10-20 pages in length.  Panel proposals should be two
pages and should describe the topic, identify the panel chair, explain
the format of the panel, and list three to four potential panelists.
Technical papers will appear in the proceedings.  A description of each
panel will appear in the proceedings, and may at the discretion of the
panel chair, include written position statements from each panelist.

Each submission must contain a separate title page with the type of
submission (paper or panel), the title or topic, the names of the
author(s), organizational affiliation(s), telephone and FAX numbers,
postal addresses, Internet electronic mail addresses, and must list a
single point of contact if more than one author.  The names of authors,
affiliations, and other identifying information should appear only on
the separate title page.

Submissions must be received by 1 August 1997, and should be made via
electronic mail in either PostScript or ASCII format.  If the committee
is unable to print a PostScript submission, it will be returned and
hardcopy requested.  Therefore, PostScript submissions should arrive
well before 1 August.  If electronic submission is difficult,
submissions should be sent via postal mail.

All submissions and program related correspondence (only) should be
directed to the program chair:  Matt Bishop, Department of Computer
Science, University of California at Davis, Davis CA  95616-8562,
Email: [email-masked]. Phone: +1 (916) 752-8060,
FAX: +1 (916) 752-4767,

Dates, final call for papers, advance program, and registration
information will be available at the URL:
http://www.isoc.org/conferences/ndss98.

Each submission will be acknowledged by e-mail.  If acknowledgment is
not received within seven days, please contact the program chair as in-
dicated above.  Authors and panelists will be notified of acceptance by
1 October 1997.  Instructions for preparing camera-ready copy for the
proceedings will be sent at that time.  The camera-ready copy must be
received by 1 November 1997.

To: [email-masked]
Subject: Unsubscribe
Date: Fri, 20 Jun 1997 03:13:22 JST
From: KOJIMA Hisashi <[email-masked]>

Unsubscribe us to the list.

To: [email-masked]
Subject: Unsubscribe
Date: Thu, 19 Jun 1997 23:08:29 JST
From: KOJIMA Hisashi <[email-masked]>

Unsubscribe me to the list.

E-Mail: [email-masked]

Hisashi Kojima, Maruyama lab., Tokyo Institute of Technology

To: [email-masked]
Subject: Unsubscribe
Date: Thu, 19 Jun 1997 23:08:29 JST
From: KOJIMA Hisashi <[email-masked]>

Unsubscribe me to the list.

E-Mail: [email-masked]

Hisashi Kojima, Maruyama lab., Tokyo Institute of Technology

Date: Wed, 18 Jun 1997 12:15:56 +0000
From: VPNet Technologies <[email-masked]>
Reply-To: [email-masked]
Organization: VPNet
To: [email-masked]
Subject: Unsubscribe

Unsubscribe us to the list.

Date: Tue, 17 Jun 1997 16:59:46 -0400
To: [email-masked]
From: Rodney Thayer <[email-masked]>
Subject: Re: Elliptic Curves

It's also a massive pain in the neck if an internet draft is written such
that it's hard to add a new algorithm.  Witness the pain we're going
through in the IPsec world to talk about signed HMAC digests.  

>X-Sender: [email-masked]
>Date: Tue, 17 Jun 1997 09:51:54 -0400
>To: Ken Rowe <[email-masked]>, Bob Jueneman <[email-masked]>
>From: Tim Polk <[email-masked]>
>Subject: Re: Elliptic Curves
>Cc: [email-masked]
>
>At 08:26 PM 6/16/97 -0500, Ken Rowe wrote:
>>At 11:22 AM 6/16/97 -0600, Bob Jueneman wrote:
>>[stuff deleted]
>>>I believe that before we take any position regarding the inclusion or
>>>exclusion of a particular algorithm, we should think through what such an
>>>inclusion implies, and the process by which we should reach such a
decision.
>>>
>>>I have no problem with listing an algorithm identifier for a particular
>>>algorithm, so long as we specifically say that we are neither endorsing
nor
>>>recommending against its use, but rather feel that it is a decision that
>>>must be left to the user at this time.
>>[stuff deleted]
>>
>>I feel that way about any algorithm included in the standard.  I don't think
>>the pkix is about endorsement of suitability of algorithms, only providing
>>a public interface for using "standard" (i.e., well-defined) algorithms.
>>In that sense, I think EC crypto is far enough along to include it in 
>>the pkix standard as just one of many algorithms.
>>
>>Ken.
>>
>>
>
>Inclusion of an algorithm in PKIX-1 is not an endorsement.  It is simply
>recognition that an algorithm will be "widely" used in the Internet PKI.
>Conforming implementations need not support any of the algorithms identified.
>However, implementations that support an algorithm included in PKIX-1 must
>process the algorithm as specified to claim conformance.
>
>By including the algorithm, we specify the algorithm identifier(s) and the
>rules for encoding key materials.  If CAs conform when they issue certs,
>and clients process the certs as specified, two clients that use the same
>algorithm will (in general) be interoperable.  If PKIX-1 does not include
>the algorithm, two conforming clients may support different OIDs or
>encoding rules, and wouldn't interoperate even tho' they use the same
>algorithm.
>
>I believe there will be sufficient ECDSA certs issued in the Internet PKI
>to justify including the algorithm in PKIX-1.
>
>Tim
>
>

From: John Marchioni <[email-masked]>
To: "'Housley, Russ'" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "'Lily Chen'" <[email-masked]>
Subject: RE: Elliptic Curves
Date: Tue, 17 Jun 1997 11:35:53 +0100

Here are Cylink's comments per Lily Chen.  Other than its narrow view on 
curve selection methods we find X9.62 acceptable.

- John 

ANSI X9.62 seems not to have been written in the same spirit of
flexibility as other ANSI X9 standards. For example, X9.42 and 
X9.52 both allow for several variants of Diffie-Hellman and Triple 
DES respectively.

Thinking about what should be considered for inclusion of ANSI X9.62
(in the EC DSA area) in the PKIX RFC, the first is to add other curve 
selecting methods. 

Currently, ANSI X9.62 specifies the way to select curves "randomly".
This can be done by using a random SEED as an input of hash function 
H such that one of the parameters b = H(SEED). If an "a" can be 
found such that the curve defined by (a, b) has a "nearly prime" order, 
then it will be used in EC DSA. The curve can be verified to be 
generated randomly, given SEED and hash function H. 

However, there is no reasonable execuse for excluding two other
methods which have been used by people:

1. Weil Theorem: It starts by choosing a curve over GF(2^k) where k is
small, i.e. both "a" and "b" are in GF(2^k). Then by considering this curve
is a curve over a larger field GF(2^{k*n}), the order of the curve can be 
calculated by Weil Theorem. If the order is "nearly prime", take it. 
Otherwise, start to get another.

2. Complex Multiplication (CM) method: it starts by choosing the order 
of the curve. Then construct a curve with the order. 

Both of the above methods are effective and efficient.  A paper 
authored by Jerry Solinas will be presented at Crypto'97, Santa 
Barbara, August. In this paper, the curves are selected with CM 
structure. 

There are many efficient implementations of EC cryptographic 
algorithm  with curves selected by either Weil Theorem  and 
CM method. 

Furthermore, IEEE standard draft P1363 mentioned three 
approaches in selecting curves: (1) random;(2) Weil Theorem; 
and (3) CM.

If Weil Theorem is included, the field operations over GF(2^m)
by coefficients over GF(2^k) where m = n * k should be added
However, the current ANSI X9.62 doesn't exclude this situation 
since the operation of GF(2^m) is not specified. This should be 
a field representation problem-so we conclude it is up to 
implementor, however, such an example in X9.62 and PKIX 
would be useful.. 

The representation should be generalized as GF(q^n), where q = p,
a prime, or q =2^k. 

This is what I can see about this problem.

Lily

-----Original Message-----
From:	Housley, Russ [SMTP:[email-masked]]
Sent:	Monday, June 16, 1997 6:20 AM
To:	[email-masked]
Subject:	Elliptic Curves

Since we began work on PKIX part 1, Elliptic Curve thecnology has become 
more and more mature.  In fact, ANSI X9.62 looks pretty close to final.  
How do people feel about ading the ECDSA algorithm to the list of signature 
algorithms in part 1?

Russ

Date: Tue, 17 Jun 1997 09:51:54 -0400
To: Ken Rowe <[email-masked]>, Bob Jueneman <[email-masked]>
From: Tim Polk <[email-masked]>
Subject: Re: Elliptic Curves
Cc: [email-masked]

At 08:26 PM 6/16/97 -0500, Ken Rowe wrote:
>At 11:22 AM 6/16/97 -0600, Bob Jueneman wrote:
>[stuff deleted]
>>I believe that before we take any position regarding the inclusion or
>>exclusion of a particular algorithm, we should think through what such an
>>inclusion implies, and the process by which we should reach such a decision.
>>
>>I have no problem with listing an algorithm identifier for a particular
>>algorithm, so long as we specifically say that we are neither endorsing  nor
>>recommending against its use, but rather feel that it is a decision that
>>must be left to the user at this time.
>[stuff deleted]
>
>I feel that way about any algorithm included in the standard.  I don't think
>the pkix is about endorsement of suitability of algorithms, only providing
>a public interface for using "standard" (i.e., well-defined) algorithms.
>In that sense, I think EC crypto is far enough along to include it in 
>the pkix standard as just one of many algorithms.
>
>Ken.
>
>

Inclusion of an algorithm in PKIX-1 is not an endorsement.  It is simply
recognition that an algorithm will be "widely" used in the Internet PKI.
Conforming implementations need not support any of the algorithms identified.
However, implementations that support an algorithm included in PKIX-1 must
process the algorithm as specified to claim conformance.

By including the algorithm, we specify the algorithm identifier(s) and the
rules for encoding key materials.  If CAs conform when they issue certs,
and clients process the certs as specified, two clients that use the same
algorithm will (in general) be interoperable.  If PKIX-1 does not include
the algorithm, two conforming clients may support different OIDs or
encoding rules, and wouldn't interoperate even tho' they use the same
algorithm.

I believe there will be sufficient ECDSA certs issued in the Internet PKI
to justify including the algorithm in PKIX-1.

Tim

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: Elliptic Curves
Cc: [email-masked]
Sender: [email-masked]
Reply-To: [email-masked]
Date: Tue, 17 Jun 1997 15:17:26 (NZST)

Rodney Thayer <[email-masked]> writes:

>It would be nice if some reference implementations were floating about.  I
>haven't looked in a while, I suspect there are some now.  If some
>kind-hearted soul wanted to post a URL or two that would be nice.

George Barwood has done a rather nice ECC library which is available from
http://ds.dial.pipex.com/george.barwood/crypto.htm.  In addition there'll be 
ECC code added to my own cryptlib, 
http://www.cs.auckland.ac.nz/~pgut001/cryptlib.html, Real Soon Now (well OK,
probably not *that* soon).
 
Peter.

Date: Mon, 16 Jun 1997 22:33:54 -0400
From: Juan Rodriguez Torrent <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
CC: "Housley, Russ" <[email-masked]>, Bob Jueneman <[email-masked]>, Charles Breed <[email-masked]>
Subject: Elliptic Curves

There are several commercial ventures (indirectly referenced by Charles
Breed -below-) with large amounts of money at stake if ECDSA is not
quickly and broadly accepted. This results in a intense pressure on the
technical community to speed-up the acceptance of the ECDSA algorithm
regardless of its maturity. I think Jueneman's position (below) is well
thought and I like very much his suggestion of inclusion without
endorsement.

Juan

Housley, Russ wrote:
> 
> Since we began work on PKIX part 1, Elliptic Curve thecnology has become
> more and more mature.  In fact, ANSI X9.62 looks pretty close to final.
> How do people feel about ading the ECDSA algorithm to the list of signature
> algorithms in part 1?
> 
> Russ

Bob Jueneman wrote:
> 
> My only concern is that various states, the legal community, and users tend
> to be strongly influenced by the actions of standards groups in areas such
> as this.
> 
> I'm not taking any position one way or the other regarding the maturity of
> elliptic curves from a cryptanalytic standpoint, although as a matter of
> prudence I would not feel comfortable using them for high-value transactions
> until they have been subected to several more years of examination by the
> cryptographic community.
> 
> I believe that before we take any position regarding the inclusion or
> exclusion of a particular algorithm, we should think through what such an
> inclusion implies, and the process by which we should reach such a decision.
> 
> I have no problem with listing an algorithm identifier for a particular
> algorithm, so long as we specifically say that we are neither endorsing  nor
> recommending against its use, but rather feel that it is a decision that
> must be left to the user at this time.
> 
> Bob
> 
> >>> Charles Breed <[email-masked]> 06/16/97 09:38AM >>>
> Having the flexibility to add new algorithms is always a smart thing.
> Elliptic curve (discrete log-based asymmetric) algorithms make a lot of
> sense, wrt smart cards and their need for small keys, low memory and low
> burden on CPUs. As long as the relevant PKCS 'standards' can accommodate the
> new algorithm, I vote YES.
> 
> Charles
> 

-- 
            '''             
           (0 0)            
+----oOO----(_)------------+  
| Juan Rodriguez i Torrent |   
|     [email-masked]      |   
+-----------------oOO------+    
          |__|__|          
           || ||
          ooO Ooo

Date: Mon, 16 Jun 1997 20:26:09 -0500
To: Bob Jueneman <[email-masked]>
From: Ken Rowe <[email-masked]>
Subject: Re: Elliptic Curves
Cc: [email-masked]

At 11:22 AM 6/16/97 -0600, Bob Jueneman wrote:
[stuff deleted]
>I believe that before we take any position regarding the inclusion or
>exclusion of a particular algorithm, we should think through what such an
>inclusion implies, and the process by which we should reach such a decision.
>
>I have no problem with listing an algorithm identifier for a particular
>algorithm, so long as we specifically say that we are neither endorsing  nor
>recommending against its use, but rather feel that it is a decision that
>must be left to the user at this time.
[stuff deleted]

I feel that way about any algorithm included in the standard.  I don't think
the pkix is about endorsement of suitability of algorithms, only providing
a public interface for using "standard" (i.e., well-defined) algorithms.
In that sense, I think EC crypto is far enough along to include it in 
the pkix standard as just one of many algorithms.

Ken.

Date: Mon, 16 Jun 1997 15:19:12 -0400
To: "Housley, Russ" <[email-masked]>, [email-masked]
From: Tim Polk <[email-masked]>
Subject: Re: Elliptic Curves

At 05:20 AM 6/16/97, Housley, Russ wrote:
>
>Since we began work on PKIX part 1, Elliptic Curve thecnology has become 
>more and more mature.  In fact, ANSI X9.62 looks pretty close to final.  
>How do people feel about ading the ECDSA algorithm to the list of signature 
>algorithms in part 1?
>
>Russ
>
>

At NIST, we are also comfortable with the current draft of X9.62.  We have
already put ECDSA in our "Minimum Interoperability Specification for PKI
Components", and would support adding ECDSA to the PKIX-1 document.

Tim Polk

From: Trevor Freeman <[email-masked]>
To: "Pkix List (E-mail)" <[email-masked]>
Subject: Proposal to Modify the pkix part3 ROOT CA Key Change Protocol
Date: Mon, 16 Jun 1997 11:05:52 -0700

As part of my work on CA's with multiple algorithms, I believe I have
developed a simplified scheme to enable ROOT CA's to bind certificates
together. ROOT CA's are required to bind certificates together to
establish they are published by the same entity when they:
	wish to replace their own Certificate near the end of its
validity period,
	wish to publish multiple ROOT Certificates with the same
algorithm
	wish to publish ROOT Certificates with different algorithms.

The Method.
The same sequence of certificates is generated as currently proposed in
pkix part3, but a date independent method of determining there purpose
is possible and I believe simpler.
	Cert-A is a  ROOT certificate for subject ROOT-CA, containing
Pub-a, KeyID-a and is signed by Pri-a.
	Cert-B is a  ROOT certificate for subject ROOT-CA, containing
Pub-b, KeyID-b and is signed by Pri-b.
	Where
	Pub-a is Public Key a
	Pri-a is the private key which corresponds to Pub-a
	Pub-b is Public Key b
	Pri-b is the private key which corresponds to Pub-b
	KeyID-a is the Key identifier for the A key pair
	KeyID-b is the Key identifier for the B key pair.

To bind Cert-A and Cert-B together, to establish they are from the same
authority, a pair of Binding certificates is generated. (Sign A with B
and Sign B with A - equivalent to the old with new and new with old as
per pkix)
	Cert-C is a ROOT binding certificate for subject ROOT-CA,
containing Pub-a, KeyID-b and is signed by Pri-b
	Cert-D is a ROOT binding certificate for subject ROOT-CA,
containing Pub-b, KeyID-a and is signed by Pri-a
Options for identifying which certificate is which.

1 Deduction my dear Watson.
This requires some trial and error with certificate validation.
Certificate A and B are from homogeneous key pairs, that is the public
key they publish and the private key used to sign the certificate is the
same key pair. ROOT binding certificate keys are from heterogeneous
pairs, therefore the Public key they contain will not verify the
certificate. This homogeneous/heterogeneous feature can be therefore be
used to distinguish ROOT certificates from Root binding certificates.
Identifying ROOT certificates also identifies the KeyID for the ROOT
Public key pairs. Having identified the KeyID's, the public key in
Cert-B, can be used to verify Cert-C, thus establishing the link between
Cert-B and C. Likewise the KMID in Cert-D shows that the Pub-a key in
Cert-A will verify Cert-D and establishing the link between Cert-A and
D.
2. Extra Key Identifier Extension.
This requires an extra extension in the ROOT binding certificates.
If an extension with the KeyID of the key pair belonging to the public
key in the certificate in addition to the normal Key Identifier of the
signing key, identifies exactly which ROOT binding certificate is which.
You have one KeyID indicating the identity of the Public Key pair
belonging to the public key and another KeyID indicating the identifying
of the key pair used to sign the certificate. Knowing the key pairs in
question, then the correct key should be used to verify each certificate
first time.

As these methods do not rely on dates to identify the purpose of a
certificate. If a CA wishes to publish two or more ROOT certificates,
with the same validity dates with the same or different algorithms, this
is possible under this scheme. The scheme also supports the renewal of
an expiring ROOT certificate.

Dr Trevor Freeman
Senior Consultant
Microsoft Consulting Services
Microsoft Ltd ECU
> Tel:  UK(+44) 1734 270412 
Fax: UK(+44) 1734 270435

Date: Mon, 16 Jun 1997 11:22:30 -0600
From: Bob Jueneman <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Re: Elliptic Curves

My only concern is that various states, the legal community, and users tend
to be strongly influenced by the actions of standards groups in areas such
as this.

I'm not taking any position one way or the other regarding the maturity of
elliptic curves from a cryptanalytic standpoint, although as a matter of
prudence I would not feel comfortable using them for high-value transactions
until they have been subected to several more years of examination by the
cryptographic community.

I believe that before we take any position regarding the inclusion or
exclusion of a particular algorithm, we should think through what such an
inclusion implies, and the process by which we should reach such a decision.

I have no problem with listing an algorithm identifier for a particular
algorithm, so long as we specifically say that we are neither endorsing  nor
recommending against its use, but rather feel that it is a decision that
must be left to the user at this time.

Bob

>>> Charles Breed <[email-masked]> 06/16/97 09:38AM >>>
Having the flexibility to add new algorithms is always a smart thing.
Elliptic curve (discrete log-based asymmetric) algorithms make a lot of
sense, wrt smart cards and their need for small keys, low memory and low
burden on CPUs. As long as the relevant PKCS 'standards' can accommodate the
new algorithm, I vote YES.

Charles

At 05:20 AM 6/16/97, Housley, Russ wrote:
>
>Since we began work on PKIX part 1, Elliptic Curve thecnology has become 
>more and more mature.  In fact, ANSI X9.62 looks pretty close to final.  
>How do people feel about ading the ECDSA algorithm to the list of signature

>algorithms in part 1?
>
>Russ
>
>

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

Date: Mon, 16 Jun 1997 12:44:58 -0400
To: [email-masked]
From: Rodney Thayer <[email-masked]>
Subject: Re: Elliptic Curves

It would be nice if some reference implementations were floating about.  I
haven't looked in a while, I suspect there are some now.  If some
kind-hearted soul wanted to post a URL or two that would be nice.

At 05:20 AM 6/16/97, you wrote:
>
>Since we began work on PKIX part 1, Elliptic Curve thecnology has become 
>more and more mature.  In fact, ANSI X9.62 looks pretty close to final.  
>How do people feel about ading the ECDSA algorithm to the list of signature 
>algorithms in part 1?
>
>Russ
>
>

Date: Mon, 16 Jun 1997 08:38:50 -0700
To: "Housley, Russ" <[email-masked]>, [email-masked]
From: Charles Breed <[email-masked]>
Subject: Re: Elliptic Curves

Having the flexibility to add new algorithms is always a smart thing. Elliptic curve (discrete log-based asymmetric) algorithms make a lot of sense, wrt smart cards and their need for small keys, low memory and low burden on CPUs. As long as the relevant PKCS 'standards' can accommodate the new algorithm, I vote YES.

Charles

At 05:20 AM 6/16/97, Housley, Russ wrote:
>
>Since we began work on PKIX part 1, Elliptic Curve thecnology has become 
>more and more mature.  In fact, ANSI X9.62 looks pretty close to final.  
>How do people feel about ading the ECDSA algorithm to the list of signature 
>algorithms in part 1?
>
>Russ
>
>

Date: Mon, 16 Jun 97 05:20:28 
From: "Housley, Russ" <[email-masked]>
Encoding: 259 Text
To: [email-masked]
Subject: Elliptic Curves

Since we began work on PKIX part 1, Elliptic Curve thecnology has become 
more and more mature.  In fact, ANSI X9.62 looks pretty close to final.  
How do people feel about ading the ECDSA algorithm to the list of signature 
algorithms in part 1?

Russ

Date: 14 Jun 97 19:01:00 +1700
From: [email-masked]
To: [email-masked]
Subject: How to UNSUBSCRIBE yourself from this list..

If you ever want to remove yourself from this mailing list,
send the following command in email to "[email-masked]"
(NOT [email-masked]):

    unsubscribe <your e-mail-id> ietf-pkix

From: "Shyh-Wei Luan" <[email-masked]>
Date: Thu, 12 Jun 1997 10:55:28 -0700
To: Hal Lockhart <[email-masked]>, Shyh-Wei Luan <[email-masked]>, [email-masked], "Steiner Viktor, GD-IT453" <[email-masked]>
Subject: Re: Subject naming
Cc: "[email-masked]'" <[email-masked]>

On Jun 12,  9:10am, Hal Lockhart wrote:

> >Nobody here is suggesting that names are obsolete!  We have names on our
driver
> >license and other ID's and we also see names of UNIX file owner/group, but
yet
> >there are underliying numerical ID's.
>
> I believe this discussion has begun to go over the same ground. As someone
> else poined out a week or two ago, the problem with this type of approach is
> that you need a trusted facility to perform the mapping.

The mapping is provided in the certificates by CA's.  The updates in the
mapping
(i.e., name changes) will be propagated to applications upon accesses based on
the names cited in new certificates when used.

There are at least two other potential means for application to update name or
other (non-Subject-UID) attribute information in the ACLs.

(1) Applications may refresh the attribute information through a protocol with
CA's or directories for pulling up-to-date certificates to update annotations
to
Subject UID's.

(2) Applications may provide an interface for on-line, user initiated updates
of attributes (except the Subject UID).  Note that these updates can be
automatically verified with the use of the new certificates.  No additional
name-update protocol between CA's and applications is needed.

> This works ok if
> the scope of the identifier is local (e.g. an OS), but gets harder as the
> scope increases.  If the mapping is incorrect, either because of out of date
> information or fraudulent manipulation, the authorization decision will be
> incorrect *and it is unlikely to be noticed by people*.
>
> Although a serial number encoded in the subject name:
>
> CN=John Smith + SN=12345
>
> is just as obscure, the human readable portion of the name does provide the
> possibility that a human being can detect what is going on.

I don't understand what you mean here.  Do you mean that a SUID field is less
human-readable than the SN attribute?

For applications that are really concerned with name changes, they can always
include Subject Names in ACL's to deny certificates with new names, until ACL's
get updated.  But there are a many businesses which do not care what your
name is, where you live/work, etc. They only care that you are the same person
whom they have been dealing with.  Applications can also choose to grant
accesses to certificates with name changes but at the same time send out
confirmation notices to the certifying CA's and the certified subject.  This is
similar to address-change requests in today's business practices.

Using Subject UID's alone as the basis of access control offers these
flexibilities upon name changes.

There is also another perspective that would argue for the use of Subject UID
field - the decoupling of certification from naming.  I'll elaborate if
interested ...

Shyh-Wei

Date: Thu, 12 Jun 1997 09:00:21 -0500
From: jamesd <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Subject: Unsubscribe

Unsubscribe

Date: Thu, 12 Jun 1997 09:10:18 -0400
To: Shyh-Wei Luan <[email-masked]>, [email-masked], "Steiner Viktor, GD-IT453" <[email-masked]>
From: Hal Lockhart <[email-masked]>
Subject: Re: Subject naming
Cc: "[email-masked]'" <[email-masked]>

At 11:45 AM 6/11/97 -0700, Shyh-Wei Luan wrote:

>Nobody here is suggesting that names are obsolete!  We have names on our driver
>license and other ID's and we also see names of UNIX file owner/group, but yet
>there are underliying numerical ID's.

I believe this discussion has begun to go over the same ground. As someone
else poined out a week or two ago, the problem with this type of approach is
that you need a trusted facility to perform the mapping.  This works ok if
the scope of the identifier is local (e.g. an OS), but gets harder as the
scope increases.  If the mapping is incorrect, either because of out of date
information or fraudulent manipulation, the authorization decision will be
incorrect *and it is unlikely to be noticed by people*.

Although a serial number encoded in the subject name:

CN=John Smith + SN=12345

is just as obscure, the human readable portion of the name does provide the
possibility that a human being can detect what is going on.

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

Date: Wed, 11 Jun 97 16:29:12 EST
From: "Tom Zmudzinski" <[email-masked]>
Cc: [email-masked]
Subject: Re[2]: Subject naming

As "3490835689758974233" <[email-masked]> posted to ietf-pkix
on 6/11/97 at 12:29 PM --

> I think the solution was already presented to us in the film "The
> President's Analyst" -- we simply have to replace names with serial
> numbers. Names are obsolete anyway.
>
>  Sincerely
>  3490835689758974233

  Given the fact that Mother Bell wants to give [sell] us all permanent
  phone numbers plus the existence of satellite cell phones plus just a 
  little bit of miniaturization, I'd say that "The President's Analyst" 
  qualifies as prophetic, frightfully prophetic!  Maybe it's time to 
  resurrect "contingency plan: Rasputen" [the trick that saved James 
  Colburn and friends at the end of the movie]?
  
  Tongue only slightly in cheek,
  "ZERO-ZERO-ZERO-DESTRUCT-ALPHA" 

From: "Shyh-Wei Luan" <[email-masked]>
Date: Wed, 11 Jun 1997 11:45:26 -0700
To: [email-masked], "Steiner Viktor, GD-IT453" <[email-masked]>
Subject: Re: Subject naming
Cc: "[email-masked]'" <[email-masked]>

On Jun 11, 11:15am, Perry E. Metzger wrote:
> I think the solution was already presented to us in the film "The
> President's Analyst" -- we simply have to replace names with serial
> numbers. Names are obsolete anyway.
>
>       Sincerely
>       3490835689758974233

Nobody here is suggesting that names are obsolete!  We have names on our driver
license and other ID's and we also see names of UNIX file owner/group, but yet
there are underliying numerical ID's.  You don't necessarily remember or cite
them.  But they are there and they have important functions!

Shyh-Wei (who does not remember his California license number)

Date: Wed, 11 Jun 1997 12:44:03 -0400
To: Shyh-Wei Luan <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: X.509 certificate and its subject name field
Cc: [email-masked]

Folks,

	This has been a fascinating, extended discussion re the form of ACL
entries for use with certs, but it is somewhat removed from the current
PKIX charter.  I suggest that we move forward with the current work items
and revisit these complex issues later.

Steve

Date: Wed, 11 Jun 1997 09:36:32 -0700
To: [email-masked]
From: Greg Anderson <[email-masked]>
Subject: Please remove me, someone

Can someone please remove [email-masked] or [email-masked], or whatever
greg I am known as from this mailing list?  Someone subscribed me by
mistake, so I don't even know how to unsubscribe.

If the owner of this list reads this, please send me a message and let me
know if you can remove me.

Thanks a lot,
Greg
___________________________________________________________________
Greg Anderson                                      [email-masked] 
Anderson-Coates, Inc.  (www.acoates.com)             (408) 267-3306   
San Jose Living: http://www.sjliving.com/

To: "Steiner Viktor, GD-IT453" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>
Subject: Re: Subject naming 
Reply-To: [email-masked]
Date: Wed, 11 Jun 1997 11:15:58 -0400
From: "Perry E. Metzger" <[email-masked]>

I think the solution was already presented to us in the film "The
President's Analyst" -- we simply have to replace names with serial
numbers. Names are obsolete anyway.

	Sincerely
	3490835689758974233

"Steiner Viktor, GD-IT453" writes:
> Doesn't it come down to "Computer vs. Person"?  Shyh-Wei - like all of
> us - grew up with computers which required us to use unambiguous keys.
> And most of us accept this subservience.  
> 
> Later - and I think that is the idea behind the DNs (doesn't that mean
> 'Distinguished Name' - think about it!) of X.500 - some people felt
> computers should be servants and not masters; we are after all persons,
> living in a personal society, and we have the right to identify each
> other (and the organisations we deal with) by names, rather than IDs.
> 
> "I saw Dave yesterday."
> "Dave?"
> "Yes, Dave Smith, you know."
> "In Marketing?"
> "No, he sits on the third floor above the canteen."
> "Oh, the one with the beard?"
> "Yes, that's right."
> 
> We're not interested that his ID is 6271534.  Let the computer worry
> about unambiguous fields, but let me name entities with NAMES, where
> necessary qualified by additional attributes to resolve ambiguities.
> Mit freundlichen Grüssen / Meilleures salutations / Kind regards
> Viktor Steiner, IT453

Date: Wed, 11 Jun 1997 10:05:33 -0400
From: "Mark D. Rasch" <[email-masked]>
To: Bob Jueneman <[email-masked]>
CC: [email-masked], [email-masked]
Subject: unsubscribe

unsubscribe

From: "Alain Zahm" <[email-masked]>
To: "Steiner Viktor, GD-IT453" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: Subject naming
Date: Wed, 11 Jun 1997 10:57:49 +0200

Few cents in this thread.

Identify human beings is not as simple as to call them. We have various =
identities depending the context.
	1/ I am the individual Alain Zahm when I purchase goods on the WEB
	2/ I am a project manager of my company when I order software on the =
WEB
	3/ I am a code number when I reach my anonymous bank account.

In the first case my name and address with optionnaly my ID card number =
may be my identity
In the second case my name plus my title and company name is a valid =
identity
at last the third case my need a single secret code number.

X.500 made used of an extensible structure that has no restriction at =
all. This structure being tied to a directory schema implementation it =
needs the service to be available. I don't beleive this will happen soon =
worldwide.

IMO restricted schema with well defined and fixed structure should be =
specified in order to avoid any ambiguiousity:
for example individual identity is =
INDIVIDUAL-ID:<Name:Zahm;GivenName:Alain;Country:FR;Street:....>
COMPANY-ID:<Role:"Project Manager";Name:Zahm....>
BANK-ID:<Code:17352X53RD3574G83593YGT>
These ID shouldn't rely on a given underlying architecture (like X.500). =
They just represent the syntactic expression of the ID.
A CA is then able to set and sign this ID. The complete ID must be =
unique of course. But the main aim of these structures is that they must =
be verifiable and understandable by human beings and applications.

Alain

----------
De : Steiner Viktor, GD-IT453 <[email-masked]>
A : [email-masked]'
Objet : Subject naming
Date=A0: mercredi 11 juin 1997 11:01

Doesn't it come down to "Computer vs. Person"?  Shyh-Wei - like all of
us - grew up with computers which required us to use unambiguous keys.
And most of us accept this subservience. =20

Later - and I think that is the idea behind the DNs (doesn't that mean
'Distinguished Name' - think about it!) of X.500 - some people felt
computers should be servants and not masters; we are after all persons,
living in a personal society, and we have the right to identify each
other (and the organisations we deal with) by names, rather than IDs.

"I saw Dave yesterday."
"Dave?"
"Yes, Dave Smith, you know."
"In Marketing?"
"No, he sits on the third floor above the canteen."
"Oh, the one with the beard?"
"Yes, that's right."

We're not interested that his ID is 6271534.  Let the computer worry
about unambiguous fields, but let me name entities with NAMES, where
necessary qualified by additional attributes to resolve ambiguities.
Mit freundlichen Gr=FCssen / Meilleures salutations / Kind regards
Viktor Steiner, IT453

>If you are registered with Department of Commerce as SUID 19970001 =
today,
>then
>some other successful Dave Kemp can register as 20070001 10 years =
later,
>because the ACL's won't inadvetantly grant your accesses to SUID =
20070001.
>
>> What precisely is the advantage of SUIDs over unique terminal RDN's?
>
>advantages:
>
>(1) explicitness in what field is going to be persistent and temporally
>unique
>(2) DN's do not need to be persistent and temporally unique and can be
>simpler
>(3) the SUID scheme is not tied to the X500-type of names
>
>Shyh-Wei
>
>----------

From: "Steiner Viktor, GD-IT453" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Subject naming
Date: Wed, 11 Jun 1997 11:01:32 +0200

Doesn't it come down to "Computer vs. Person"?  Shyh-Wei - like all of
us - grew up with computers which required us to use unambiguous keys.
And most of us accept this subservience. =20

Later - and I think that is the idea behind the DNs (doesn't that mean
'Distinguished Name' - think about it!) of X.500 - some people felt
computers should be servants and not masters; we are after all persons,
living in a personal society, and we have the right to identify each
other (and the organisations we deal with) by names, rather than IDs.

"I saw Dave yesterday."
"Dave?"
"Yes, Dave Smith, you know."
"In Marketing?"
"No, he sits on the third floor above the canteen."
"Oh, the one with the beard?"
"Yes, that's right."

We're not interested that his ID is 6271534.  Let the computer worry
about unambiguous fields, but let me name entities with NAMES, where
necessary qualified by additional attributes to resolve ambiguities.
Mit freundlichen Gr=FCssen / Meilleures salutations / Kind regards
Viktor Steiner, IT453

>If you are registered with Department of Commerce as SUID 19970001 =
today,
>then
>some other successful Dave Kemp can register as 20070001 10 years =
later,
>because the ACL's won't inadvetantly grant your accesses to SUID =
20070001.
>
>> What precisely is the advantage of SUIDs over unique terminal RDN's?
>
>advantages:
>
>(1) explicitness in what field is going to be persistent and temporally
>unique
>(2) DN's do not need to be persistent and temporally unique and can be
>simpler
>(3) the SUID scheme is not tied to the X500-type of names
>
>Shyh-Wei
>
>

From: "Shyh-Wei Luan" <[email-masked]>
Date: Tue, 10 Jun 1997 15:14:17 -0700
To: [email-masked] (David P. Kemp), [email-masked]
Subject: Re: X.509 certificate and its subject name field

On Jun 10,  9:49am, David P. Kemp wrote:

> Perhaps this is of general interest, so we return to the list ...

This is certainly a good idea.

> Forget about "annotated by names" - that's just a red herring.  Your
> access control decisions will be based on some information.  That
> information either includes something other than the SUID or it does
> not.

So, let's also forget about "user and group names" in Unix, that's just a
red herring.  Your access control deceisions will be based on some information.
That information either includes something other than the uid/gid or it does
not.  :-)

> So, if you are going to base decisions on SUIDs, those SUIDs need to be
> allocated in some manner.  You have proposed that they not be managed
> across CA's, i.e. not be required to be unique.  Therefore the Access
> Control List must maintain the entire path of SUIDs from the trusted
> ("root") CA down through the subject's SUID.  Therefore the SUID path
> is required to be topologically equivalent to the certification path,

The SUID path *is* the certification path.

> i.e.  you cannot separate naming authorities from certification
> authorities.

> That is the SDSI model - a subject is named by an entire path: "Fred's
> Bob's Alice's Denis' Shyh-Wei", which may or may not be the same person
> as "Fred's Mike's John's Dave's Shyh-Wei".

I would more likely see something like "Department of Commerce's IBM" or
"California DMV's Shyh-Wei".   PC's in the future might have built-in
public keys of Department of Commerce, DMV's, and other well-known CA's.

> If you are happy with purely local, SDSI-type, names for your subjects,
> then put those names in the DN, not in a separate SUID field, and base
> your ACL identity on a path of DNs.  But you can't have your cake and eat it
> too - if you aren't going to manage the namespace across CAs, you'll
> have to use the full SDSI name-path in your ACLs, whether the relevant
> name is contained in the DN field or the SUID field.

Do I have to use my name in UNIX file owner uid/gid filed?  Can't
I use the uid/gid for access checking and use the name (the cake) for
displaying owner and group names?

> Above all, you can't claim the simplicity of local SUIDs and then turn
> around and wave your hands and claim the advantages of managed DNs
> on the grounds that "DNs are available as annotation".

Why not???

> How does using the SUID field address any hypothetical shortage of
> CA names?

You may be able to register your business today with Department of Commerce
as "Dave Kemp Enterprises".  Then you start doing businesses with a lot of
places and "Dave Kemp Enterprises" gets on the ACL's or identity databases
all around the world.   Assume that the company goes out of business
in December.  Then, Department of Commerce cannot register anyone else as
the "Dave Kemp Enterprises", because the new party might be gaining accesses
that belonged to you.   Dave, please be fair with future "Dave Kemp's",
will you? :-)

If you are registered with Department of Commerce as SUID 19970001 today, then
some other successful Dave Kemp can register as 20070001 10 years later,
because the ACL's won't inadvetantly grant your accesses to SUID 20070001.

> If you assume that IBM goes out of business this year, and next year
> Dave Kemp Enterprises wants to issue certs under the name "ibm.com",
> those two IBMs have to be kept separate in some manner.

I believe there are tons of "going-nowhere" companies/enterprises out there.
I would not assume IBM is one of them. ;-)

> Assuming for
> a moment that the lawyers and the PTO agree to allow reuse of the
> IBM name,
>
>   "..., CN=ibm.com" and SUID=1
>
> seems no more effective at designating the real IBM in a name reuse
> scenario than does
>
>   "..., CN=ibm.com + SN=1"
>
>
> What precisely is the advantage of SUIDs over unique terminal RDN's?

advantages:

(1) explicitness in what field is going to be persistent and temporally unique
(2) DN's do not need to be persistent and temporally unique and can be simpler
(3) the SUID scheme is not tied to the X500-type of names

Shyh-Wei

Date: Tue, 10 Jun 1997 11:17:03 -0700
From: Peter Williams <[email-masked]>
To: "David P. Kemp" <[email-masked]>
CC: [email-masked]
Subject: Re: X.509 certificate and its subject name field

David P. Kemp wrote:

If you assume that IBM goes out of business this year, and next year

> Dave Kemp Enterprises wants to issue certs under the name "ibm.com",
> those two IBMs have to be kept separate in some manner.  Assuming for
> a moment that the lawyers and the PTO agree to allow reuse of the
> IBM name,
>
>   "..., CN=ibm.com" and SUID=1
>
> seems no more effective at designating the real IBM in a name reuse
> scenario than does
>
>   "..., CN=ibm.com + SN=1"
>
> What precisely is the advantage of SUIDs over unique terminal RDN's?

  Reuse of names is controlled by a CA, during its responsible and
reliable
performance of the authentication management process.

Whereas NAs, lawysers and PTO will manage who gets
"o= IBM Co; l=Internet; cn=www.ibm.com", and a CA will do due
diligence and reliable authentication for the party claiming to
be thusly named,...

its a value-added CA service to enable some other party
to, at a subsequent moment, reuse that name, and its
the CA represnetation that name-reuse and change
of authentication has occured. The name, upon validation of reuse,
need not change, as in the SN=2 RDN case.

As is often said, use of this cert, or reliance on the identification
information for access control (including SUID where present)
orotherwise,
transcends the DN name-form, bringing the benefits to other name-forms
of
GeneralName in the critical altSubjectName extension.

To take an example, If I start an new name-form registry provided
for my GeneralNames, for  car vanity number plates "IAMVANE" , when
the plate is re-sold, the plate name should not change. Thats
the whole point!

This does beg a question of which name-form the SUID controls refer if
there are multiple names in the GeneralNames-based extension. There is
no reason why the SUID PDV cannot be a sequence of such controls, that
one might note in the CA technical disclosures constraining use or
reliance.

Date: Tue, 10 Jun 1997 09:49:36 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: X.509 certificate and its subject name field

Perhaps this is of general interest, so we return to the list ...

> From: "Shyh-Wei Luan" <[email-masked]>
> Date: Mon, 9 Jun 1997 14:52:21 -0700
> To: [email-masked], "David P. Kemp" <[email-masked]>
> 
> On Jun 9, 12:03pm, Denis Pinkas wrote:
> >
> > > But if you allow CA
> > > certs to have SUID fields, you get into "UID subordination rules",
> > > blah blah blah, the entire naming discussion all over again.
> 
> To David: I don't understand what you mean by "UID subordination rules" and
> the blah blah blah.  Why does one need to be subordinated to any other?
> It will be a chain of identities uniquely identified by SUIDs and annotated
> by names.
> 
> I bet that you are aware of Rivest and Lampson's SDSI.  What do you think of
> that???

Forget about "annotated by names" - that's just a red herring.  Your
access control decisions will be based on some information.  That
information either includes something other than the SUID or it does
not.  Businesses can keep whatever databases on customers they want,
maintained by whatever practices they feel are appropriate, without
requiring that information to be included in certificates.  If a DN
happens to be included in the customer database, fine, but if it is not
used in the access control decision, it is not germaine to the
discussion.

So, if you are going to base decisions on SUIDs, those SUIDs need to be
allocated in some manner.  You have proposed that they not be managed
across CA's, i.e. not be required to be unique.  Therefore the Access
Control List must maintain the entire path of SUIDs from the trusted
("root") CA down through the subject's SUID.  Therefore the SUID path
is required to be topologically equivalent to the certification path,
i.e.  you cannot separate naming authorities from certification
authorities.

That is the SDSI model - a subject is named by an entire path: "Fred's
Bob's Alice's Denis' Shyh-Wei", which may or may not be the same person
as "Fred's Mike's John's Dave's Shyh-Wei".

Alternatively, you could manage SUIDs across CAs in the same manner
that DNs are managed - by allowing CA's to certify only a subset of the
namespace.  One way of carving up the namespace is strictly by
heirarchy, again requiring names to be linked to the CA structure
(although not requiring strict topological equivalence), using
subordination rules. Another way of carving up the namespace is by
naming authority, using Name Constraints, which allows the naming and
certification functions to be separated.

If you are happy with purely local, SDSI-type, names for your subjects,
then put those names in the DN, not in a separate SUID field, and base
your ACL identity on a path of DNs.  But you can't have your cake and eat it
too - if you aren't going to manage the namespace across CAs, you'll
have to use the full SDSI name-path in your ACLs, whether the relevant
name is contained in the DN field or the SUID field.

Above all, you can't claim the simplicity of local SUIDs and then turn
around and wave your hands and claim the advantages of managed DNs
on the grounds that "DNs are available as annotation".

> > This is the reason why I limited the proposal to leaf certificates ...
> > until someone can find a story which is acceptable. I anticipate that no
> > one will be able to propose such a story .  :-)
> 
> To Denis:  I don't know what kind of "story" you would qualify as an
> acceptable "story". The shortage of desirable business/CA names will
> be a problem. Don't we agree?
> 
> Shyh-Wei

How does using the SUID field address any hypothetical shortage of
CA names?

If you assume that IBM goes out of business this year, and next year
Dave Kemp Enterprises wants to issue certs under the name "ibm.com",
those two IBMs have to be kept separate in some manner.  Assuming for
a moment that the lawyers and the PTO agree to allow reuse of the
IBM name,

  "..., CN=ibm.com" and SUID=1

seems no more effective at designating the real IBM in a name reuse
scenario than does

  "..., CN=ibm.com + SN=1"

What precisely is the advantage of SUIDs over unique terminal RDN's?

From: "Shyh-Wei Luan" <[email-masked]>
Date: Mon, 9 Jun 1997 17:13:45 -0700
To: Bob Jueneman <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Globally unique subjectUID?

On Jun 6,  2:27pm, Bob Jueneman wrote:

> Hal Lockhart recently asked what exactly defined a "subject", and I gave him
> sort of a wise guy, "it depends" answer.  So if you want to specify what I
> think you are specifying, I would suggest a more semantic-oriented
> definition of "subject." In other words, I believe that you are suggesting
> that the flesh-and-blood human entity be the underlying construct, and that
> changes of DNs and/or alternateSubjectNames would not matter.

What I suggest is that "a Subject Unique Identifier should be a unique
identifier of a subject, within the context of the issuing CA".  Isn't that
simple and straightforward? :-)  It should not change as long as the *subject*
remain existing in the context of the CA.  I don't think a subject must be
a human.

> However, without using either my concept of forming a message digest from
> someone's birth certificate in a predefined way, or else using some form of
> biometric indicator, I'm not sure that I understand how a CA would enforce
> even the CA-unique requirement.

It could be as simple as a timestamp or a serial number.

> Consider one of the most common cases -- a
> woman gets married, changes her name and address, and gets a new driver's
> license, perhaps in a different state. Now she reapplies to her CA for a new
> certificate, but forgets to mention the old name.  What does the CA do to
> enforce the uniqueness requirement?

The CA might use a different SUID if the woman left the context (the state)
and come back without requesting the revalidation of her old SUID.  For
marriage, name and address changes, the SUID will remain valid.

> Is this a user-driven, optional
> function? If so, what does it accomplish?

I think it should be CA-policy driven.  CA's that provides/enforces temporal
uniqueness of SUID's may annouce so and may be classified as a CA that's more
suitable for longlived applications.  The use of temporal unique SUID's on
ACL's would prevent another Shyh-Wei Luan with a California DMV certificate
100 years later from accessing my cyberspace accesses/assets.  Using SUID
alone on ACL's will also make it unnecessary for me to contact San Jose
Mercury News and Time to change my name in their identity database or ACLs,
when I get an English name and start using it with California DMV.

> If it is to be user-driven and optional (at least as far as the uniqueness
> is concerned), then portability between CAs might be a consideration.  If
> one of the schemes that was suggested for deriving completely unique or
> probabilistically unique IDs was used, then a user should be able to carry
> that ID to another CA and use the same UID.

This is NOT what I proposed.  It is each CA itself who will choose the SUID
algorithm that fits its own specific context.

> All this is metaphysical enough, but I really begin to get a headache when I
> start to think how to apply these concepts to non-human entities. How would
> it work for a server name?

Yes, it is perfectly possible that a server can get a SUID in the context of
of a ISP's CA, for example.

> Would it apply in the case of a corporation name,
> for example after a merger?

If the merger affects the context of CA's, then some changes are necessary.
For example, if IBM wants to disband Lotus Corp's CA, then all Lotus employee
will be included in IBM CA's context.  Of couse, IBM can choose to maintain
the use of the Lotus CA.

> How about a law partnership that adds one more
> partner?  Is that still the "same" entity?  The semantic issues would be the
> driving factors, here, I think.

I don't think a fixed semantics can be provided for everyone here.  Each CA
will decide what to do in accordance to future rules/laws, I believe.

> I'm not suggesting that a globally unique UID is necessary, only that it
> might be nice for applications such as access control.  In particular, the
> Orange Book requirements for a B3 system require that it be possible to
> EXCLUDE individuals or groups of individuals from access, and I don't know
> how to implement that, particularly in the network context, if people can
> freely change their names.

A globally unique Subject UID will not prevent frauds by itself either.  I
don't think getting a new Subject UID would be easier than getting a new
globally unique identifier.  What's needed here is some law enforcement against
fooling CA's in order to get new SUID's.  One can change his/her name but not
his/her identity!

Shyh-Wei

Date: Mon, 09 Jun 1997 17:24:35 -0700
To: [email-masked]
From: Warwick Ford <[email-masked]>
Subject: Call for Papers: Jurimetrics
Cc: [email-masked]

FYI...
-----
*** Announcement ***

JURIMETRICS

Winter 1998

Special Issue on Public Key Infrastructure

(Security in Electronic Commerce: Technology, Infrastructure and=20
Practices for Certification Authorities and Digital Signatures)

I. Contents of this Solicitation

=B7 General Information
=B7 Call for Papers
=B7 Criteria for Papers
=B7 Submission Information
=B7 Important Dates
=B7 Virtual Conference
=B7 Organization
=B7 Inquiries
=20
=20
II. General Information
=20
We are pleased to announce the planned publication of a special issue of
the Jurimetrics Journal of Law, Science and Technology that will
exclusively address public key infrastructure (PKI) -- the law and
technology of certificate-based digital signatures and secure electronic
commerce. This announcement solicits articles for consideration for this
special Winter 1998 issue, which is intended as a forum for attorneys,
technologists, developers, and users interested in the legal aspects and
implications of PKI.
=20
Jurimetrics Journal of Law, Science and Technology, published quarterly, is
the journal of the American Bar Association Section of Science and
Technology and the Center for the Study of Law, Science and Technology of
the Arizona State University College of Law.
=20
The Information Security Committee, Electronic Commerce Division, Section
of Science and Technology of the American Bar Association (ISC) explores
and develops legal policy and foundation to support PKI and secure
electronic commerce. The ICS=92s current endeavors include research and work
product concerning: accreditation of certification authorities, commercial
key escrow guidelines, PKI evidentiary issues, digital signature
legislative initiatives, CA and user liability, and other legal issues
relating to secure electronic commerce. The discussions are moderated by
the relevant Work Groups of the ISC, and the ISC is open to professionals
of all disciplines with similar interests. In August l996, the ISC
published the Digital Signature Guidelines.  See Tutorial, Table of
Contents, and List of Contributors of the Digital Signature Guidelines at
http://www.abanet.org/scitech/ec/isc/dsg-tutorial.html.=20
=20
=20
III. Call for Papers
=20
 Papers are invited on all subjects related to applications of PKI and
their corresponding legal issues. The special edition is structured as
follows:
=20
=B7 Preface
=B7 Introduction
=B7 Tutorial, Architecture and Technology
=B7 International Issues
=B7 Liability, Contractual, Intellectual Property, and other Substantive
Legal Issues
=B7 Government =96 Legislative, Regulatory, Policy, Enforcement
=B7 Accreditation of Certification Authorities (including licensure and=
 other
quality issues)=20
=B7 Miscellaneous
=20
Papers submitted should be concise and focused on the kernel rather than
exhaustive detail of new ideas intended to be communicated.  Papers should
not restate basic PKI technology but instead refer to the common tutorial
located in the introductory materials.=20
 =20
We thank you in advance for your submissions to this special issue of
Jurimetrics on PKI.
=20
=20
IV. Criteria for Papers
=20
Preference will be given to papers that comply with the following criteria:
=20
=B7 are no longer than 8,000 words (under 10 pages, 12 point type, single
spaced)
=B7 provide appropriate annotation
=B7 include URLs in annotations, where available
=B7 consider both legal and technical issues/implications
=B7 involve joint authorship between a lawyer and technologist
=B7 are original works not previously published elsewhere
=B7 conformance to the instructions for prospective Jurimetrics authors
posted at    http://www.asu.edu/law/jurimetrics/author.htm=20
=20
=20
 V. Submission Information
=20
Send brief but informative abstract of one or two pages as an email
attachment to [email-masked]. If possible, please use Word 6.0
(Office 95) to facilitate handling. A one paragraph bio is also requested
but not required.
=20
=20
 VI. Important Dates
=20
=B7 Abstracts must be submitted by: 25 June 1997
=B7 Deadline for submission of drafts: 15 October 1997
=B7 Final version ready, after all cite checks and editorial changes: 31
December 1997
=B7 Publication of Jurimetrics special issue on PKI: February 1998

=20
VII. Virtual Conference

All papers accepted to Jurimetrics Winter 1998 special issue on PKI will
appear in full or abstract form in a Virtual Conference Center hosted by
the ISC.  The PKI community will have the opportunity to participate in
discussions with the authors using e-mail and the World Wide Web. The
Virtual Conference Center will feature a variety of electronic discussions
moderated by leading PKI experts for the facilitation of communication
within the virtual PKI/law & technology community.

VIII. Organization for the Jurimetrics Special Issue on PKI

  Guest Editor-in-Chief:

     Michael S. Baum, Esq., VP, Practices and External Affairs, VeriSign,=
 Inc.

  Associate Guest Editors:

     Joseph H. Alhadeff, Esq., Director, Electronic Commerce, U.S. Council
         for Int=92l Business (USCIB)
     Warwick Ford, Ph.D., Director, Advanced Technology, Verisign, Inc.
     Theodore Ling, Esq., Baker & McKenzie, Toronto, Ontario.=20
     Charles R. Merrill, Esq., McCarter & English, Newark, NJ.
     Arthur F. Purcell, J.D., International Project Specialist, US Patent &
         Trademark Office=20
     Ruven Schwartz, Esq., Info. Security, West Group Business Manager

XI. Inquiries

If you need help or have questions which are not answered in the above
information, please e-mail: [email-masked]

---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
   [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716
---------------------------------------------------------------------
=20

Date: Tue, 10 Jun 1997 00:00:11 +0700
To: Cryptography List <[email-masked]>, [email-masked], Censor List <[email-masked]>, IETF PGP/MIME List <[email-masked]>, Linux-IPSEC List <[email-masked]>, [email-masked], [email-masked], [email-masked]
From: "Dinesh Mahtani (Dino)" <[email-masked]>
Subject: subscribe

subscribe [email-masked]
 _______________________________________________________________
|								|
|      TEMPORARY EMAIL ADDRESS: [email-masked]	|
|_______________________________________________________________|
 _______________________________________________________________
|								|
| Please note that our company will be changing our Internet	|
| Service Provider in the very near future.  I may be unable 	|
| to view messages sent to [email-masked].  To 	|
| avoid any possible problems please update your address 	|
| books and/or send carbon copies of all correspondance to my 	|
| old school address during this transition. 			|
|_______________________________________________________________|
 _______________________________________________________________
|								|
|      TEMPORARY EMAIL ADDRESS: [email-masked]	|
|_______________________________________________________________|

From: Trevor Freeman <[email-masked]>
To: "Pkix List (E-mail)" <[email-masked]>
Subject: CA's and PKI's with multiple signature algorithms
Date: Sat, 7 Jun 1997 04:10:56 -0700

There seems to be a significant overhead for CA's and PKI's in general
which support multiple signature algorithms. PKI's cannot make
assumptions about the capabilities of a certificate user, therefore
users with only one signature algorithm must be catered for.
CA's and PKI's must ensure that a certification path exists for each
signature algorithm they use. It seems unreasonable for a path to force
a switch of algorithms. This introduces the concept that a CA is
operating in an algorithm qualified name space.
There seems to be at least two solutions to this problem

1. CA's maintain multiple certificate hierarchies independently and in
parallel. This would also include CRL's distribution point for each
algorithm. This is in effect maintaining multiple PKI's with all the
management overhead that would entail. As the CA hierarchy for each
algorithm qualified name space is independent, they can have different
structures. This may be a benefit??. However users with multiple
signature algorithms are being artificially constrained by this option
since they can cross algorithms name spaces. 

2 Certificates could optionally carry multiple signatures thus
permitting their use by either algorithm user community. This is then a
singe PKI for all algorithms. I cannot however see how to do this
without a change in the certificate structure.

Any enlightened solutions?

Dr Trevor Freeman
Senior Consultant
Microsoft Consulting Services
Microsoft Ltd ECU
> Tel:  UK(+44) 1734 270412 
Fax: UK(+44) 1734 270435

Date: Fri, 6 Jun 1997 14:13:47 -0700
To: Cryptography List <[email-masked]>, [email-masked], Censor List <[email-masked]>, IETF PGP/MIME List <[email-masked]>, Linux-IPSEC List <[email-masked]>, [email-masked], Mac Crypto List <[email-masked]>, PGP Dev List <[email-masked]>, PGP Users <[email-masked]>, [email-masked], [email-masked], [email-masked]
From: Dave Del Torto <[email-masked]>
Subject: [ANNOUNCE] Phil Zimmermann on recent FUD and PGP 5.0 plans
Cc: Mike Nelson <[email-masked]>

A message from our Fearless Leader...

   dave

................................. cut here .................................

-----BEGIN PGP SIGNED MESSAGE-----

Last month, Pretty Good Privacy Inc went through a  reorganization in
its top management.  We were spending too much money, too fast.  Tom
Steding was replaced by Phil Dunkelberger as the president of PGP, and
I handed over the chairman title to Jonathan Seybold, who had been, with
me, the original cofounder of the company.  Jonathan is devoting his time
to the business side of things, while I am focussing my attention on my
role as chief technology officer.

I have seen some speculation in some usenet newsgroups that these changes
were in some way connected with the fact that PGP was recently sued by RSA
Data Security over some dispute regarding royalties for use of the RSA
patent, which PGP holds a license to.  Let me set the record straight
on this.  There are sound business reasons why this shuffling of top
management occurred at PGP, and these reasons are known to all of our
employees.  The RSA lawsuit against PGP is absolutely not one of the
reasons, not even remotely.  I don't think shuffling top management is
a likely reaction for any company to take in response to a lawsuit, even
if the lawsuit had merit, which this one does not.  We fully expect the
RSA matter to be resolved in arbitration proceedings, in our favor.

I know that it is common practice for some companies to issue statements
to "spin" the story about certain events, sometimes at the expense of
truth.  This makes a lot of people understandably skeptical about such
explanations.  I do have responsibilities toward my company, but no
one could get me to deny a truth about the reasons for the restructuring.
The truth is, the restructuring had absolutely nothing at all to do with
the RSA lawsuit.

I would now like to announce that we will be releasing PGP 5.0 in mid-June.
It's in beta release right now on our web page (www.pgp.com).  In keeping
with my own dedication to personal freedom and privacy, we will be releasing
a freeware version for noncommercial use through MIT's web site
(web.mit.edu/pgp), just like in the old days before the company was formed.
And we do plan to publish the full PGP source code for Mac, Windows 95,
and Linux.

There are a lot of new exciting features, including automatic key lookups
from remote key servers on the Internet, which will likely result in the
rapid growth of a ready-made nationwide PGP public-key infrastructure,
on an unprecedented scale.  We are also encouraging the migration to new
public key algorithms in addition to RSA, namely the NIST Digital
Signature Standard (DSS), as well as Diffie-Hellman (Elgamal) keys.
We expect most of the new users to be using these new algorithms instead
of RSA, in part because they offer new features, better performance, and
better security for the same key sizes.  I hope that you will all join me
in this opportunity to move to these new algorithms, allowing everyone to
finally enjoy the use of public key cryptography without the encumberances
of patents.

Philip Zimmermann
Chief Technology Officer, PGP Inc.

Date: Fri, 06 Jun 1997 14:27:02 -0600
From: Bob Jueneman <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re:  Globally unique subjectUID?

>>> Shyh-Wei Luan <[email-masked]> 06/06/97 01:34AM >>>

>Bob,
>
>> If the subjectUID were a constant, unique and unambiguous reference to
the
>> PERSON, there might be a lot of advantages. But this would require that
it
>> the subjectUID not be unique per issuer, but globally unique.
>
>Although a "globally unique ID" seems desirable, it was not what
>I proposed.  I proposed that the spec encourages each CA's to maintain
>its own ID issuance with temporal uniqueness (i.e., the same ID never gets
>assigned to more than one subject, and the same subject can retain the same
>ID even if its name gets changed) for the lifetime of the CA.

Hal Lockhart recently asked what exactly defined a "subject", and I gave him
sort of a wise guy, "it depends" answer.  So if you want to specify what I
think you are specifying, I would suggest a more semantic-oriented
definition of "subject." In other words, I believe that you are suggesting
that the flesh-and-blood human entity be the underlying construct, and that
changes of DNs and/or alternateSubjectNames would not matter.

However, without using either my concept of forming a message digest from
someone's birth certificate in a predefined way, or else using some form of
biometric indicator, I'm not sure that I understand how a CA would enforce
even the CA-unique requirement. Consider one of the most common cases -- a
woman gets married, changes her name and address, and gets a new driver's
license, perhaps in a different state. Now she reapplies to her CA for a new
certificate, but forgets to mention the old name.  What does the CA do to
enforce the uniqueness requirement?  Is this a user-driven, optional
function? If so, what does it accomplish?

If it is to be user-driven and optional (at least as far as the uniqueness
is concerned), then portability between CAs might be a consideration.  If
one of the schemes that was suggested for deriving completely unique or
probabilistically unique IDs was used, then a user should be able to carry
that ID to another CA and use the same UID.  Perhaps they would have to show
prior possession of use, in the form of a certificate issued by the other
CA, in order to prevent someone from claiming someone else's UID.  The
liability implications for the CA in this case are not clear, however.

All this is metaphysical enough, but I really begin to get a headache when I
start to think how to apply these concepts to non-human entities. How would
it work for a server name? Would it apply in the case of a corporation name,
for example after a merger?  How about a law partnership that adds one more
partner?  Is that still the "same" entity?  The semantic issues would be the
driving factors, here, I think.
>
>IMO, a globally unique ID is not required, *IF* it is possible at all.  I
use my
>social security number, driver license number at my banks, insurance
agents,
>and I use my IBM employee ID for accessing my company's systems.  I used
>my student ID at my university.  Sometimes the IDs match my SSN, but many
>times they don't.

I'm not suggesting that a globally unique UID is necessary, only that it
might be nice for applications such as access control.  In particular, the
Orange Book requirements for a B3 system require that it be possible to
EXCLUDE individuals or groups of individuals from access, and I don't know
how to implement that, particularly in the network context, if people can
freely change their names.
[snip]

Bob

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

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

From: "Shyh-Wei Luan" <[email-masked]>
Date: Fri, 6 Jun 1997 11:26:59 -0700
To: [email-masked]
Subject: Re: X.509 certificate and its subject name field

On Jun 6,  8:57am, Shyh-Wei Luan wrote:
> Subject: Re: X.509 certificate and its subject name field
> > What is the basis for this name re-use speculation ?
>
> > Clearly there will be no shortage of CA name space.  What may
> > be a problem is a shortage of _desirable_ CA names.  Witness
> > the shortage of desirable names in the DNS.
>
> This is exactly what I mean.  Yeah, "desirable CA names" is a better
> way to put it - just like desirable DN's.
                            ^^^^^^^^^^^^^^
I guess I meant to say *desirable DNS names* and desirable *DN's* (for those
which do not have some UID attribute) at the same time.  Sigh, I guess I am
little bit tired.  :-)

Shyh-Wei

From: "Duncan C. Kinder" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: List Information
Date: Fri, 6 Jun 1997 12:22:09 -0400

I'm sorry for posting this message, but I am unable to locate the list 
information necessary to unsubscribe.

Would someone please inform me how to do so.

Duncan Kinder
[email-masked]

Date: Fri, 6 Jun 1997 09:20:59 -0700
From: <[email-masked]> (Shyh-Wei Luan)
To: [email-masked]
Subject: Re: X.509 certificate and its subject name field
Cc: [email-masked], [email-masked], [email-masked]

From: Denis Pinkas <[email-masked]>

> (Shyh-Wei Luan) wrote:

> > CA names will become a scarce resource in years and need to reused.

> I would agree with that statement which would be a nice requirement ...

> > Thus I think CA's should also be assigned SUID's by their certifying CA's.

>       .... but saying that the issuer Unique ID is the solution
>            is not the right answer  ... until there is a whole story
>            about how to use/manage it.

I am not saying that "issuer UID" should be used.  As a matter of fact,
I oppose to the use of the issuer UID field.  What I am saying is that
a CA certifying other CA's can use *Subject UID* to address name reuses
(or name changes).  The following is the text that I object to.

>    CAs conforming to this profile should not reuse issuer names.
>    Therefore they should not generate cross-certificates that
>    incorporate a subject unique identifier.

For example, the US Department of Commerce can certify Company X's CA with
Subject UID 123 today and Company X's can go out of
business, say, end of this year. The Department can choose to certify a
different entity, say, 15 years later as Company X with Subject UID 456.

Shyh-Wei

Date: Fri, 6 Jun 1997 08:57:30 -0700
From: <[email-masked]> (Shyh-Wei Luan)
To: [email-masked], [email-masked], [email-masked]
Subject: Re: X.509 certificate and its subject name field
Cc: [email-masked]

From: John Lowry <[email-masked]>

> What is the basis for this name re-use speculation ?

> Clearly there will be no shortage of CA name space.  What may
> be a problem is a shortage of _desirable_ CA names.  Witness
> the shortage of desirable names in the DNS.

This is exactly what I mean.  Yeah, "desirable CA names" is a better
way to put it - just like desirable DN's.

> I'm sure that BULL and IBM would object mightily if I set up
> a public CA that had a name which differed from one of their CA's
> names by only a UID.  Or wouldn't they ?    :-)

Yes, I think these companies will not like it as long as they stay in
business. :-)

Shyh-Wei

Date: Fri, 6 Jun 1997 10:20:06 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: X.509 certificate and its subject name field

> From: Hal Lockhart <[email-masked]>
> 
> Look, I apologize if I am the only one on this list who doesn't "get it",
> but I am trying to ask serious questions about what the specification
> specifies and what it does not specify.

They are valuable questions, and I in turn apologize if my comments sound
abrupt.  But getting a universal understanding of the facts and the areas
of general agreement will free up the discussion to focus on other topics.

> Suppose I am going to make an authorization decision.  To do so, one of the
> things I have to determine is the "subject."  It seems to me that my notion
> of what a subject is has to match that of the certificate issuer. 
> 
> Does the spec tell me what fields I need to check to (unambigiously)
> determine the identity of the subject?  Or is that up to me?
> 
> Is the CA free to put anything it likes in the subject name field as long as
> the syntax is right and it follows its own published policies?

Precisely.

The IETF conundrum "mechanism, not policy" applies here.  I believe PKIX's
role is to define unambiguous mechanisms for allowing the various parties
in the PKI (subjects, issuers, and verifiers) to interwork.  The mechanisms
must be precisely defined, because policy designers must know how to encode
their intended semantics into certificates, but they must be flexible
enough to allow a wide range of semantics to be expressed.

The question "what is a subject" is unanswerable in the PKIX context
(except perhaps for the PKIX part 4 document, which specifies the universe
of questions PKI participants should consider, but does not specify answers
to any of them).

Anyone who claims that X.509 DNs are globally unique is probably speaking
in the context of the X.500 DIT.

But it is certainly a requirement that X.509 certificates be usable without
relying on globally-unique DNs, given the fact that the world has not signed
up to the concept of either a single root Certification Authority or a
single root Naming Authority (the Directory).  The best we can hope for
is Federated Naming, ugly though it might be.

Bottom-up designs and locally managed environments are a fact of life.
We must just ensure that the mechanisms used in local environments are
also capable of scaling up to global scope.  Designing for the global
environment but allowing the flexibility to simplify is the PKIX approach,
in contrast to some other public key based mechanisms.

Date: Fri, 6 Jun 1997 09:59:37 -0400
From: John Lowry <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: X.509 certificate and its subject name field
Cc: [email-masked]

What is the basis for this name re-use speculation ?

Clearly there will be no shortage of CA name space.  What may
be a problem is a shortage of _desirable_ CA names.  Witness
the shortage of desirable names in the DNS.

I'm sure that BULL and IBM would object mightily if I set up
a public CA that had a name which differed from one of their CA's 
names by only a UID.  Or wouldn't they ?    :-)

> From: Denis Pinkas <[email-masked]>
> 
> (Shyh-Wei Luan) wrote:
> 
> > CA names will become a scarce resource in years and need to reused.
> 
> I would agree with that statement which would be a nice requirement ...
> 
> > Thus I think CA's should also be assigned SUID's by their certifying CA's.
> 
>       .... but saying that the issuer Unique ID is the solution 
>            is not the right answer  ... until there is a whole story 
>            about how to use/manage it.
> 
> No one has proposed such a story, yet. Until it is proposed, I am
> proposing to solve the most urgent one, i.e. re-use of "end-entity"
> names. This is why I proposed the text change.
> 
>  
> > BTW, thanks for putting up the proposal!  I am glad that the long discussion
> > is getting us somewhere.
> > 
> > Shyh-Wei
> 
> -- 
> 
>       Denis Pinkas     Bull S.A.         E-mail : [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: Fri, 06 Jun 1997 13:48:49 -0700
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: " (Shyh-Wei Luan)" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: X.509 certificate and its subject name field

(Shyh-Wei Luan) wrote:

> CA names will become a scarce resource in years and need to reused.

I would agree with that statement which would be a nice requirement ...

> Thus I think CA's should also be assigned SUID's by their certifying CA's.

      .... but saying that the issuer Unique ID is the solution 
           is not the right answer  ... until there is a whole story 
           about how to use/manage it.

No one has proposed such a story, yet. Until it is proposed, I am
proposing to solve the most urgent one, i.e. re-use of "end-entity"
names. This is why I proposed the text change.

> BTW, thanks for putting up the proposal!  I am glad that the long discussion
> is getting us somewhere.
> 
> Shyh-Wei

-- 

      Denis Pinkas     Bull S.A.         E-mail : [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: Fri, 6 Jun 1997 01:29:39 -0700
From: <[email-masked]> (Shyh-Wei Luan)
To: [email-masked]
Subject: Re: X.509 certificate and its subject name field
Cc: [email-masked], [email-masked], [email-masked]

Denis,

Here are some more comments on the proposed changes ...

From: Denis Pinkas <[email-masked]>
> 4.1.2.8  Unique Identifiers

>    The subject and issuer unique identifier are intended to handle
>    the possibility of reuse of subject and/or issuer names over time.

>    The subject unique identifier is an integer issued by a
>    certification authority that is unique during the life time of
>    a given certification authority and that is assigned by that
>    certification authority to the entity associated with the public
>    key stored in the subject public key field. It must be identical
>    for each updated certificate issued by a given CA (i.e., the issuer
>    name and the subject unique identifier identify a unique entity).

>    When the subject unique identifier is used, end-entity names may be
>    re-used over time.

>    CAs conforming to this profile should not reuse issuer names.
>    Therefore they should not generate cross-certificates that
>    incorporate a subject unique identifier.

I think it is possible that many companies/organizations will have their own
CA's - not necessarily for certifying its customers but for certifying its
employees/members or its business units for conducting businesses with other
companies or with governments (e.g., regulations, IRS).  CA names will
become a scarce resource in years and need to reused.

Thus I think CA's should also be assigned SUID's by their certifying CA's.

BTW, thanks for putting up the proposal!  I am glad that the long discussion
is getting us somewhere.

Shyh-Wei

Date: Fri, 6 Jun 1997 00:34:15 -0700
From: <[email-masked]> (Shyh-Wei Luan)
To: [email-masked], [email-masked], [email-masked]
Subject: Re:  Globally unique subjectUID?

Bob,

From: Bob Jueneman <[email-masked]>

> If the subjectUID were a constant, unique and unambiguous reference to the
> PERSON, there might be a lot of advantages. But this would require that it
> the subjectUID not be unique per issuer, but globally unique.

Although a "globally unique ID" seems desirable, it was not what
I proposed.  I proposed that the spec encourages each CA's to maintain
its own ID issuance with temporal uniqueness (i.e., the same ID never gets
assigned to more than one subject, and the same subject can retain the same
ID even if its name gets changed) for the lifetime of the CA.

IMO, a globally unique ID is not required, *IF* it is possible at all.  I use my
social security number, driver license number at my banks, issurance agents,
and I use my IBM employee ID for accessing my company's systems.  I used
my student ID at my university.  Sometimes the IDs match my SSN, but many
times they don't.

I think we can hope that a powerful ID formula can generate ID's that
can be used in *many* CA's - maybe for human subjects.  But I do not think
there will be any formula that fits *all* (humans, companies, schools,
goverments, countries, machines, programs, ...) and *forever*.  Maybe it will be
possible if an Earth Empire rises someday. :-)   But that will also fail when
ET's come in real contact. :-)

I will be happy if I only need to be certifies by a few CA's directly.  Same
ID's will be better but different ID's will be fine too.  (I know many
people will not like to have the same ID's for privacy reason.)

Shyh-Wei

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: X.509 certificate and its subject name field
Cc: [email-masked]
Sender: [email-masked]
Reply-To: [email-masked]
Date: Fri, 6 Jun 1997 14:00:07 (NZST)

>>Well, in Peter Gutmann's excellent X.509 Style Guide, he specifically says
>>multi-value RDNs should *not* be used, citing LDAP support and encoding
>>issues as reasons. However, at the end of the section he does say
>>"Everything will probably break when you move to LDAP anyway."
>
>Could you tell me where this style guide is located?
 
It's at http://www.cs.auckland.ac.nz/~pgut001/x509guide.html.
 
>To clear up possible confusion,
>
>[LDAPv3 features]
 
When I wrote the style guide I read through all the LDAP-related RFC's and the 
documentation for LDAP software I could get my hands on (as well as sundry
standards, drafts, guidelines, interoperability specs, etc etc), and tried to 
take into account the various "Use of this feature will result in the 
immediate demise of all small furry animals in an eight-block radius"-type 
warnings contained therein to find a lowest common denominator set of rules
which should result in the least pain for all concerned if they're adhered 
to.  The result is in the guide.  The idea behind the guide is to present a 
"If you do this, you should be OK" set of guidelines, rather than a "You're 
theoretically allowed to do this if you can find an implementation which 
supports it" feature list.  I keep updating the guide as new things come to 
light (at the moment I've got to add bits on character set encoding issues and 
the ongoing debate over errors in PKCS #10), if there's a significant reason 
to change the text about DN-related issues (that is, if the majority of 
software being fielded now supports more than what's described in the guide, 
and if someone using these extra features still stands a good chance of being 
able to talk to other real, deployed implementations) then I'll be happy to 
make the changes.
 
Peter.

Date: Thu, 05 Jun 1997 21:08:56 -0400
From: pdlampru <[email-masked]>
Subject: Business Model and Architecture for an Open PKCI
To: [email-masked]
Cc: Jim Luisi <[email-masked]>

IETF-PKIX:

Please review the attached paper if it seems interesting to you.  It
represents a very different paradigm for creating a Public Key CA
infrastructure.  There are many questions the paper does not answer. =
  So,=20
I welcome any opportunity to present and explain these ideas at any
conference or other appropriate forum.  The ideas in this paper will =
be
presented at the next Financial Services Technology Consortium (FSTC)
meeting in Toronto on July 24, 1997. Information about the FSTC meeti=
ng may
be obtained from http://www.fstc.org/

I monitored this group's conversations for awhile and it seems that m=
any of
the recent threads touch on issues that are addressed in this paper t=
o some
limited extent.=20

Respectfully submitted...pdl

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Strategic Tasks for Government in the Information Age

Financial Cryptology Conference 1997
Anguilla, BWI
February 24-28, 1997

Presented by
Paul Lampru
Strategic Marketing for Electronic Commerce and Security
Financial, Healthcare and Government Markets
U.S. Division, VeriFone, Inc.

(The ideas expressed in this paper are those of the author and=20
do not necessarily represent those of VeriFone, Inc.)

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
Snip of my paper to focus on ideas for an "Open" Public Key Certifica=
tion
Infrastructure
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D

Key Element: =20
National Public Key Certification Infrastructure (NPKCI)

Since Public Key encryption is extremely secure when key lengths are =
over
1024 bits, we should recognize that it is not the weakest message sec=
urity
link and focus our efforts on a much weaker link----the NPKCI.   Toda=
y it
is not clear how our Certification Authority (CA) infrastructure will
inevitably organize itself.  Competition and short-term revenue objec=
tives
are unduly influencing the evolution of the CA infrastructure.  For
instance, should the MasterCard and Visa CA architecture for issuing
certificates linked to credit card numbers be a universal model for o=
ther
certification applications?  It is certainly appropriate for securing
credit card transactions over the Internet.  But does this suggest th=
at
every special application should construct a special purpose way to i=
ssue
certificates?  Is there not a common set of functions that certificat=
es
provide for all applications?  We need a consensus on a common set of
services which a National PKCI must provide to the Internet community=
 in
the broadest sense.  Considering these common elements, a collective
long-term vision for a national Public Key Certification architecture
should emerge.

A simple vision for a NPKCI is that it should be based on a viable bu=
siness
model capable of providing low cost PKC to every person while minimiz=
ing
the opportunity to fraudulently obtain a PKC.  It should enable CA to
establish reasonable and explicit liability limits.  It should assure
citizens and businesses that digitally signed documents will be uphel=
d in a
court of law.  It should increase personal control and access to priv=
ate
information stored in third party databases.  To achieve this set of =
goals
the key component to manage is the design of an NPKCI.  Since it must=
 be
based in law, it is important that government authorities monitor,
influence and reinforce its ultimate architecture. =20

National Public Key Certification Infrastructure (NPKCI)
PKCI Architectures

There are at least two extreme architectures upon which a Public Key
Certificate Infrastructure (PKCI) could be based=97a "fully-distribut=
ed"
architecture and a "hierarchical" architecture.  A fully distributed
architecture is one in which any organization may issue a Public Key
Certificate (PKC) without cross certification.  Under this model the =
PKC is
useful "locally".  A hierarchical CA architecture is one in which a s=
ingle
organization is the root for all Certificate Authorities.  This model=
 is
inflexible and may not be achievable.  While neither of these two ext=
remes
are practical, they are useful for framing alternate architectures.  =
This
paper proposes ideas for a hybrid National PKCI based on the elementa=
ry
functions that a PKC provides.

National Public Key Certification Infrastructure (NPKCI)
PKC Elementary Functions

A PKC provides at least two elementary functions.  First, a PKC provi=
des
personal identification so all parties may identify each other before=
 a
transaction is finalized.  Second, a PKC can be used to authorize an
individual to have certain "privileges", such as access to a bank acc=
ount,
authorization to purchase something, or permission to act on behalf o=
f
another.  A PKCI organized around these two functions (that is,
identification and authorization) would recognize two types of PKC=
=97an
Identification Certificate (ID-PKC) and an Authorization Certificate
(AU-PKC). =20

For example consider an architecture where an individual's ID-PKC, no=
t the
CA is the "root" or the center of focus.  Granted, an individual's
certificate and a CA are not similar; but the idea is to create a hyb=
rid
hierarchy based on the ID-PKC=97not the CA.  This paper briefly descr=
ibes how
such an architecture might be organized and operate. =20

National Public Key Certification Infrastructure (NPKCI)
Maximum Identification Liability (MIL)

An ID-CA issues an ID-PKC (X.509) in accordance with its Certificatio=
n
Practice Statement (CPS).  However, the ID-PKC includes a new data el=
ement
called the "Maximum Identification Liability" value.  The MIL establi=
shes
the ID-CA's maximum liability for guaranteeing that the information
contained in a certificate correctly identifies an individual and the
associated Public Key.  An ID-CA may establish different liability li=
mits
for each individual.=20

In the event the ID-CA issues a certificate erroneously, the ID-CA is
contractually bound to compensate a business for any loss it incurs a=
s a
result of the error up to the Maximum Identification Liability limit,=
 as
long as that business had "registered and linked" with the ID-CA befo=
re
relying on that certificate.  (See "ID-PKC Registering and Linking" b=
elow
for an explanation of these terms.)

National Public Key Certification Infrastructure (NPKCI)
Credit Risk

Merchants and other parties dealing with consumers are always faced w=
ith
credit risk, the possibility their customers will not repay a loan or=
 a
line of credit.  Businesses reduce credit risk by obtaining a consume=
r's
payment history.  Three national credit bureaus in the United States
provide consumer credit reports upon receipt of an electronic request
containing information which uniquely identifies that consumer.  Usua=
lly a
business obtains ID information directly from the consumer when he su=
bmits
an application. =20

A credit bureau uses the ID information transmitted by the business t=
o
retrieve that consumer's credit report from a database that may conta=
in as
many as 150 million credit report records.  Often more than one credi=
t
report may match the criteria supplied by a business.  In this case,
multiple credit reports may be returned to the requester who must dec=
ide
which report is related to his customer.  The business=97not the cred=
it
bureau--is responsible for properly identifying the consumer. =20

National Public Key Certification Infrastructure (NPKCI)
Identity Risk

Identity Risk is the risk that an ID-CA might issue an ID-PKC to an
impostor or simply issue an ID-PKC in error even though it followed i=
ts CPS
procedures carefully.  Consequently, any business that relies on an I=
D-PKC
may be entitled to recover losses attributable to an erroneously issu=
ed
certificate=97up to the Maximum Liability Limit (MIL) offered by the =
ID-CA.=20
The MIL is a form of insurance that reflects the ID-CA degree of conf=
idence
that the information in the certificate correctly identifies the
individual. =20

National Public Key Certification Infrastructure (NPKCI)
Residual Identity Risk

Before an Internet merchant establishes a relationship with a new cus=
tomer,
the merchant would use the value in the MIL field to calculate his
"Residual Identity Risk".  The Residual Identity Risk is simply the
difference between the goods or services offered by a business and th=
e
Maximum Identification Liability offered by the ID-CA.  If the Residu=
al
Identity Risk is too large, the merchant must decide either to accept=
 that
extra risk or require additional identification information.  Here bu=
siness
rules could manage the merchant's Residual Identity Risk.  In this wa=
y a
merchant selling books might enter into a transaction with a potentia=
l
customer based solely on the individual's ID-PKC.  On the other hand,=
 a
merchant selling computers might require more identifying information=
 than
just the individual's ID-PKC.=20

National Public Key Certification Infrastructure (NPKCI)
ID-PKC Registering and Linking

The Maximum Identification Liability value offered by the ID-CA is a =
form
of insurance.  Consequently, a merchant must apply for this insurance=
 and
be accepted before the ID-CA can be held liable for subsequent losses=
.=20
Requesting ID-PKC insurance is strictly at the option of the merchant=
.  A
process called "registering and linking" describes procedures to appl=
y for
ID-PKC/MIL insurance.  The following are the five steps to "registeri=
ng and
linking".

1.=09The business checks the ID-CA's Certificate Revocation List (CRL=
) to
verify that its customer's ID-PKC is still valid.

2.=09The business registers itself with the ID-CA by establishing a
"tradeline" linked to the customer's ID-PKC.  The "tradeline" is a cr=
edit
industry term for the list of businesses on the credit report with wh=
om a
consumer has established relationships. =20

3.=09The ID-CA accepts a business's request for Identification insura=
nce.=20
For example, the ID-CA might establish risk management procedures to
control the total value of its exposure for each new ID-PKC it issued=
 or
registered.  If the ID-CA's cumulative risk limits are exceeded, the =
ID-CA
might decline a request. =20

4.=09The ID-CA automatically establishes a "push" notification system=
 to
alert businesses with an established tradeline when the ID-CA determi=
nes an
ID-PKC must be revoked.  If a new ID-PKC replaces a revoked ID-PKC, t=
his
information is also pushed to all businesses with a tradeline.  This
procedure minimizes the need for a merchant to check the Certificate
Revocation List (CRL) before completing each transaction with a custo=
mer.=20
The CRL is checked on the first transaction only.

5.=09The business who registers and links to an ID-PKC pays a fee sim=
ilar to
an insurance premium to the ID-CA.   There may be other types of fees=
, too.

National Public Key Certification Infrastructure (NPKCI)
Hypothetical Issuance of an ID-PKC

An ID-CA receives an application for an ID-PKC from a consumer.  The =
ID-CA
uses its Certification Practice Statement (CPS) and operating procedu=
res to
verify the identity of the individual.  Considering the degree of
confidence that the information in the application correctly identifi=
es the
applicant, the ID-CA establishes its Maximum Identification Liability=
 (MIL)
value and includes this value in the ID-PKC issued to the applicant. =
=20

Depending on the information an individual is willing to provide and =
the
ability of the ID-CA to verify that information=97either electronical=
ly or by
physical presence, the ID-CA Maximum Liability Limit may differ by
individual.  It is important to note that the liability limit is rela=
ted to
only the identity of the applicant and has nothing to do with the
applicant's credit risk, social status or national citizenship.  This
structure assumes every person has a universal right to obtain=97or n=
ot to
obtain=97an ID-PKC from any ID-CA, irrespective of the individual's n=
ational
citizenship or the business's national registry.  Thus a citizen of a=
ny
country could obtain an ID-PKC from any ID-CA.  By accepting an ID-CA
certificate the individual accepts the ID-CA governing rules disclose=
d
during the application phase.  Such rules might state the legal
jurisdiction where disputes will be resolved.

National Public Key Certification Infrastructure (NPKCI)
Government Digital Signature Accreditation

If an authorized government agency reviewed an ID-CA's CPS and operat=
ing
procedures and found they met "best practices" standards, the ID-CA c=
ould
be granted a government "Digital Signature Accreditation".  Such an
Accreditation would insure that an individual's digital signature=
=97created
with a certificate from an accredited ID-CA=97would be upheld in a co=
urt of
law as a handwritten signature.  In this situation the government aut=
hority
would enforce a person's digital signature and, by implication, would=
 be
providing another "guarantee" that the ID-PKC was properly issued.=
=20

By granting a Digital Signature Accreditation the government would au=
gment
the ID-CA Maximum Identification Liability with the threat of crimina=
l
penalty for a person who obtained an ID-PKC by impersonation or by th=
eft.=20
It would be treated as another form of forgery.  If appropriate, a co=
urt
might find the impostor was personally liable for all damages that ex=
ceeded
the ID-CA Maximum Identification Liability amount (that is, the Resid=
ual
Identity Risk).  In any event, granting an Accreditation to an ID-CA =
 would
mandate a penalty fee the ID-CA would pay if it issued a fraudulent
certificate even though it followed its CPS procedures.

National Public Key Certification Infrastructure (NPKCI)
Authorization Public Key Certificates (AU-PKC)

A Public Key Certificate (PKC) could be issued with or without an
identification "guarantee" or MIL.  An example is the MasterCard and =
Visa
PKC that may be used to sign an Internet credit card purchase only. =
=20

An AU-PKC is a special type of PKC which is "registered and linked" t=
o an
ID-PKC as described previously.  The AU-CA issues an AU-PKC to its cu=
stomer
to grant local privileges. =20

One of the primary uses for the ID-PKC is to enable a customer to dig=
itally
sign electronic applications for "membership" where the applicant's
identity must be established before services will be extended.  For
example, a consumer wants to apply for an electronic bank account.  T=
he
bank requests that the customer complete and digitally sign an Intern=
et
home banking application.  The consumer uses his ID-PKC to apply for =
an
AU-PKC.  Much of the information in the application is copied to the =
home
banking account application enabling the customer to add only a minim=
um
amount of information.  The bank no longer needs to verify the indivi=
dual's
identity.  The bank would simply "register and link" the bank's AU-PK=
C
certificate to the ID-PKC thereby transferring Identity Risk to the I=
D-CA
up to the MIL value. =20

If the ID-CA is accredited by the state to issue legally enforceable
digital certificates, the AU-CA would have a government assurance tha=
t the
potential customer is correctly identified.  This assurance is based =
on the
threat of criminal prosecution if the customer obtained an ID-PKC usi=
ng
false information. =20

Finally, if the AU-CA found these two levels of assurances insufficie=
nt,
the AU-CA could begin any identification procedures it believed were
necessary.

National Public Key Certification Infrastructure (NPKCI)
AU-PKC Revocation

Since the AU-CA grants privileges, it may withdraw those privileges b=
y
revoking its AU-PKC and posting that information to its Certificate
Revocation List (CRL).  Before revocation the AU-CA would send a "Clo=
sed
Account Confirmation Notice" (CACN) to the customer with a reason his
AU-PKC was revoked. =20

In addition to notifying the customer, the AU-CA would notify the ID-=
CA
that its relationship with this customer was closed.  At its option t=
he
AU-CA may include a reason the AU-PKC was revoked.  When the AU-CA pr=
ovides
a reason for revocation, the ID-CA records and links this information=
 to
the individual's ID-PKC. =20

Occasionally an AU-CA may be forced to close a customer's account
unilaterally for administrative or for punitive reasons.  If the acco=
unt
was closed for punitive reasons the customer may elect to refute or t=
o
explain his side of the story.  In this case the customer would send =
an
electronic copy of the CACN to the ID-CA with his digitally signed
rebuttal.  The ID-CA would link the rebuttal to the original CACN and=
 the
individual's ID-PKC.

National Public Key Certification Infrastructure (NPKCI)
Privacy Control for ID-PKC Linked Information

Anyone with a ID-PKC has a right to obtain a copy of all ancillary
information (that is, "tradelines", CACNs, etc.) that might be linked=
 to
his ID-PKC.  He could do this by digitally signing a request form and
sending it to the ID-CA.  For instance, an individual may want to rev=
iew
information about himself periodically to make sure it is accurate an=
d
complete.  Any changes an individual believes are necessary are digit=
ally
signed and sent directly to the ID-CA for review and action.  The ID-=
CA
decides if the requested changes should be made.  In any event, the I=
D-CA
replies explain all actions taken to the consumer.  Finally, if an ID=
-CA
has any information related to an individual's ID-PKC, that individua=
l
should have the right to require the ID-CA to "lock" his data record =
to
prevent any information from being disclosed without his digitally si=
gned
authorization. =20

Assume for a moment that an NPKCI is based on the architecture discus=
sed
above in which a citizen is issued an ID-PKC.  Furthermore, assume th=
at the
healthcare industry, as an example, constructs patient health record
databases accessible over the Internet.  Consider in this scenario th=
at
citizens have the same degree of privacy with their health records th=
at
they have today with their credit reports.  Privacy rights groups and
consumers will rightly perceive an erosion of "privacy" if cyberspace
databases use the ID-PKC as the common link between all the electroni=
c
activities of an individual. =20

National Public Key Certification Infrastructure (NPKCI)
Privacy Controls for ID-PKC Linked Information
Government's Role

It seems appropriate that government should proactively influence the
design of an NPKCI so that it encourages businesses to protect consum=
ers'
privacy.  To accomplish this it is important that the public and priv=
ate
sectors work together to design NPKCI that increases a citizen's priv=
acy
and access to personal information.  A government-industry goal shoul=
d be
balancing a consumer's right to privacy with a consumer's need to pro=
vide
voluntarily and selectively personal information to businesses and
government agencies before being authorized to receive benefits and
services.  If we can define an NPKCI infrastructure that is balanced =
in the
eyes of the public and businesses, then a source of bitter contention=
 could
be mitigated to some degree.  One possible way to achieve this balanc=
e is
proposed below.

National Public Key Certification Infrastructure (NPKCI)
Privacy Controls for ID-PKC Linked Information
Direct Control of Private Information

Assume for purposes of discussion that a person's ID-PKC is linked to=
 an
AU-PKC.  Assume the AU-PKC is linked to his personal healthcare datab=
ase
record stored in an Internet-accessible database.  In this scenario t=
he
Trusted Third Party (TTP) database operator could offer a patient an
Internet database location where he could store his personal healthca=
re
records.  The TTP database operator would warrant that no information
contained in his patient record could be released without the patient=
's
digitally-signed authorization message.  As compensation the database
operator charges the patient (or HMO, etc.) a storage fee for holding=
 this
information.  Perhaps the database operator also charges a fee to a
business or government agency the patient authorized to retrieve
information. =20

In this scenario a patient would fill out an electronic form to give =
a
doctor access to specific information in his electronic patient recor=
d.=20
When the doctor needs to retrieve this information, the doctor digita=
lly
"endorses" the patient's authorization form and submits the request t=
o the
TTP database to obtain the information.  A patient has absolute contr=
ol
over who has access to his medical records as well as the right to vi=
ew his
personal records over the Internet.  This NPKCI business model provid=
es any
degree of privacy a consumer desires while enabling global access to =
his
health records.  In the general case the individual is able to direct=
ly
authorize a business to retrieve only the information required to pro=
vide
the services and benefits requested. =20

Key Element: =20
Chip Card Related Technologies

To generate a "digital signature", a secure, easily carried electroni=
c
token, such as a chip card or similar device, will be needed to hold =
an
individual's Private Key and Public Key Certificate.  Assuming the to=
ken is
a chip card, there will be a need for chip card readers/writers where=
ver
individuals need to digitally sign Internet transactions and document=
s=97for
example:  a consumer's home, a doctor's office, a business or governm=
ent
office, a public phone, an Internet-connected kiosk, etc. =20

The consumer's home PC is expected to be the first place digital sign=
atures
will be generated in large numbers.  Mastercard and Visa intend to us=
e
Public Key digital signatures to authorize credit card payments over =
the
Internet.  In any event a joint industry-government strategy is neede=
d to
encourage the long-term proliferation of chip card related technologi=
es
into consumers' homes, into businesses, and eventually into public si=
tes
for those without computers. =20

Summary

There are a number of most important ideas presented in this paper.=
=20
Foremost is that the Information Age is Internet-centric.  Other
technologies need to find their niche within the Internet.  Proprieta=
ry
networks may have special purpose uses, but their value in an open, p=
ublic
networked world will be somewhat reduced from the critical role they =
play
today.  The application of government resources should carefully but
methodically accelerate the movement away from systems that use propr=
ietary
networks.

Another important idea is that the creation of a National Public Key
Certification infrastructure is critical to realizing the full potent=
ial of
the Internet.  Today we seem to be constructing Certification Authori=
ties
that issue single-purpose certificates.  We need a National Public Ke=
y
Certificate infrastructure built around the ID-PKC and the AU-PKC. =
=20

It is certainly possible that the  ID-PKC could evolve into a "nation=
al
identification number" with all the Big Brother implications.  Theref=
ore,
it is critical that we design features and privacy laws that prevent
undesirable uses of the ID-PKC while allowing us to benefit from the
enormous transaction efficiencies such a system might provide.

------------------------
Paul Lampru
Strategic Marketing, US Division
VeriFone, Inc.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Work: [email-masked]      770-754-3688
Home: [email-masked] 770-992-9849

Date: Thu, 05 Jun 1997 18:24:03 -0600
From: Bob Jueneman <[email-masked]>
To: [email-masked]
Subject: Re: X.509 certificate and its subject name field

Hal Lockhart wrote:

>Does the spec tell me what fields I need to check to (unambigiously)
>determine the identity of the subject?  Or is that up to me?

Clearly and unequivocally, it depends.

What do you consider to make up "identity"?

If all you are concerned about in the subject's DN, that is enough. But what
if someone has the same DN, but two different e-mail addresses, and two
different certificates containing different alternateSubjectNames?

Or maybe someone doesn't use a serialNumber approach to disambiguating the
subject DN, but encodes hair, eye and skin color, weight, height, and a
fingerprint GIF or JPEG image as additional attributes in the certificate?
>
>Is the CA free to put anything it likes in the subject name field as long
as
>the syntax is right and it follows its own published policies?

Yes. The Internet Society has disbanded its army, and has decided not to
declare war on anyone who violates its standards, if any.

In this case, however, there aren't any standards in any case, because the
Internet Architecture Board back in the PEM days never got around to
adopting a specific schema for what would be considered an acceptable RDN
component for a certificate.

So as a CA, you are technically, legally, and morally free to include
anything you want in a certificate, even in a DN. The components don't even
have to be listed in any of the oxymoronic "useful attribute" types defined
in X.520. So feel free to put a JPEG image of your dog in your DN, if you so
desire.

Of course, if you ever try to put this certificate into any kind of a
reasonable,. real life directory and expect to use the DN in the certificate
as the DN for the entry, you may get some flack from the directory
administrator, who thinks it is his job to specify the allowable schemas.
But what the hay, the CA and the directory providers are in separate
organizations, and neither is subservient to the other, so let them agree to
disagree.

Likewise, if you put an obscure, much less proprietary, attribute in your DN
(or anywhere else in the certificate), you may find that lots of software
won't be able to parse or display, much less browse, those attributes, even
if LDAP grows up to the point of handling something more than ASCII. But
that's OK -- we'll put out new ASN.1 definitions every Friday, and everyone
in the world can recompile their browsers and certificate verifiers once a
week to handle the new definitions.

Or you can just wait for Microsoft (or Netscape, or VeriSign, or IBM,  or
Entrust, ...) to take over the world, and just do what they do.  Of course
you won't get much market share that way, but...

Or maybe we can make it a Java problem, and assign someone else to solve it?

Always glad to be of help! :-)

Bob

 

Date: Thu, 05 Jun 1997 17:00:03 -0600
From: Bob Jueneman <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Re: Globally unique subjectUID?

>
>At 10:15 AM 6/5/97 -0600, Bob Jueneman wrote:
>
>>If the subjectUID were a constant, unique and unambiguous reference to the
>>PERSON, there might be a lot of advantages. But this would require that it
>>the subjectUID not be unique per issuer, but globally unique.
>
>Without commenting on the desirablity of this, there is already a perfectly
>good mechanism defined for creating unique identifiers defined in:
>
>ftp://ds.internic.net/internet-drafts/draft-leach-uuids-guids-00.txt 

That approach, and others that might be dreamed up, can generate IDs that
are either guaranteed to be unique, or are extremely unlikely to be
nonunique.

What I was hoping to find was a way of creating a unique ID that was
verifiably one-to-one with the subject entity, and hence (presumably)
unique.  For such a purpose, the uniqueness would not have to be absolutely
infallible to still be quite useful.  In other words, the absolute
uniqueness was somewhat less important than a repeatable and confirmable
correlation with the subject.

Bob

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

Date: Thu, 05 Jun 1997 16:52:49 -0400
To: [email-masked] (David P. Kemp), [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: X.509 certificate and its subject name field

All,

The PKIX #1 RelativeDistinguishedName syntax IS different than the RDN
syntax in the latest draft 1997 X.501 spec that is stored on bull.ftp.com.
The latest RDN definition is:

RelativeDistinguishedName ::= SET SIZE (1..MAX) OF
AttributeTypeAndDistinguishedValue
AttributeTypeAndDistinguishedValue ::= SEQUENCE {
	type			ATTRIBUTE.&id ({SupportedAttributes}),
	value			ATTRIBUTE.&Type({SupportedAttributes}{@type}),
	primaryDistinguished	BOOLEAN DEFAULT TRUE,
	valuesWithContext	SET SIZE (1 .. MAX) OF SEQUENCE {
		distingAttrValue ATTRIBUTE.&Type ({SupportedAttributes}{@type}) OPTIONAL,
		contextList			SET SIZE (1 .. MAX) OF Context } OPTIONAL }

Please note that the AttributeTypeAndDistinguishedValue syntax is backwards
compatible with the 1988 AttributeValueAssertion syntax if the
primaryDistinguished is set to TRUE (i.e. DER states that default value is
not encoded) and valuesWithContext is set to absent.  I am sure that this
was done intentionally so that current software could process the new syntax
(assuming the primaryDistinguished and valuesWithContext fields are not
present).

Please note that the draft 97 X.501 document really is "drafty" since the
RDN ASN.1 definition in the text doesn't match that in the ASN.1 module at
the end of the X.501 spec.  
==============================================================
John Pawling                               (301) 953-3600
J.G. Van Dyke & Associates, Inc.           (410) 880-6095
141 National Business Pkwy, Suite 210      FAX: (301) 953-2901
Annapolis Junction, MD  20701              [email-masked]

Date: Thu, 05 Jun 1997 15:28:29 -0400
To: [email-masked] (David P. Kemp), [email-masked]
From: Hal Lockhart <[email-masked]>
Subject: Re: X.509 certificate and its subject name field

At 01:04 PM 6/5/97 -0400, David P. Kemp wrote:

>I'm not sure what version skew issues you are referring to.

Perhaps I was misinformed.

>> Sure.  How about "CN=John Smith"
>
>And why is that not a perfectly legal Distinguished Name?  It certainly
>complies with the ASN.1 definition of DN.

Well I guess I am out of my depth here, but it was my understanding that
while DNs and RND sequences have the same syntax, they have different semantics.

In the course of the recent thread on whether SubjectUID is needed or not, a
number of people all said things like "of course the name is a DN and
therefore will be unique (unambigous)" and nobody contradicted them.  

>What is your definition of a "subject"?  The tautological definition of
>"the entity referred to by the subjectName field of a certificate" isn't
>useful - it's always unique "per subject".

Oh no, you can't get me with that one.  I am well aware that the "what is a
subject?" discussion is non-terminating.

>If you believe that a single issuer should not create more than one
>subjectName to refer to a particular flesh-and-blood human, I disagree
>with that requirement also.  I as a human may want two different DNs
>to refer to two different roles that I perform.

Obviously it is the converse case I am interested in.

Look, I apologize if I am the only one on this list who doesn't "get it",
but I am trying to ask serious questions about what the specification
specifies and what it does not specify.

Suppose I am going to make an authorization decision.  To do so, one of the
things I have to determine is the "subject."  It seems to me that my notion
of what a subject is has to match that of the certificate issuer. 

Does the spec tell me what fields I need to check to (unambigiously)
determine the identity of the subject?  Or is that up to me?

Is the CA free to put anything it likes in the subject name field as long as
the syntax is right and it follows its own published policies?

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

Date: Thu, 05 Jun 1997 15:28:25 -0400
To: Bob Jueneman <[email-masked]>, [email-masked], [email-masked]
From: Hal Lockhart <[email-masked]>
Subject: Re: Globally unique subjectUID?

At 10:15 AM 6/5/97 -0600, Bob Jueneman wrote:

>If the subjectUID were a constant, unique and unambiguous reference to the
>PERSON, there might be a lot of advantages. But this would require that it
>the subjectUID not be unique per issuer, but globally unique.

Without commenting on the desirablity of this, there is already a perfectly
good mechanism defined for creating unique identifiers defined in:

ftp://ds.internic.net/internet-drafts/draft-leach-uuids-guids-00.txt

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

Date: Thu, 05 Jun 1997 14:39:20 -0400
To: Mark Wahl <[email-masked]>
From: Hal Lockhart <[email-masked]>
Subject: Re: X.509 certificate and its subject name field
Cc: Sharon Boeyen <[email-masked]>, "[email-masked]'"  <[email-masked]>, "[email-masked]'" <[email-masked]>

At 01:31 PM 6/5/97 -0500, Mark Wahl wrote:
>
>> Well, in Peter Gutmann's excellent X.509 Style Guide, he specifically says
>> multi-value RDNs should *not* be used, citing LDAP support and encoding
>> issues as reasons. However, at the end of the section he does say
>> "Everything will probably break when you move to LDAP anyway."
> 
>Could you tell me where this style guide is located?

The URL is:

http://www.cs.auckland.ac.nz/~pgut001/x509guide.txt

I believe this was recently posted to the ietf-pkix list.

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

From: Mark Wahl <[email-masked]>
To: Hal Lockhart <[email-masked]>
cc: Sharon Boeyen <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: X.509 certificate and its subject name field
Date: Thu, 05 Jun 1997 13:31:18 -0500
Sender: [email-masked]

> Well, in Peter Gutmann's excellent X.509 Style Guide, he specifically says
> multi-value RDNs should *not* be used, citing LDAP support and encoding
> issues as reasons. However, at the end of the section he does say
> "Everything will probably break when you move to LDAP anyway."
 
Could you tell me where this style guide is located?

To clear up possible confusion,

 - LDAP supports multi-valued RDNs,

 - LDAP does not enforce any additional restrictions on name structures: X.500
   Distinguished Names are be used,

 - LDAPv3 supports the X.509v3 certificate and CRL data formats, and it is
   also possible to use the LDAPv3 mechanism to transfer X.509v3 certificates
   between several existing LDAPv2 implementations,
   
 - LDAPv3 supports the X.509(97) attribute types, 

 - LDAPv3 allows the transfer of RDN values in their DER format, if this is 
   needed to ensure tags of DirectoryString values are maintained, and

 - There are already implementations which use LDAP for the storage and 
   retrieval by PKI components of X.509v3 certificates and revocation lists
   in an X.500-based directory service.

Thanks,

Mark Wahl, Enterprise Directory Integration
Critical Angle Inc.

From: Sharon Boeyen <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "'Hal Lockhart'" <[email-masked]>
Subject: RE: X.509 certificate and its subject name field
Date: Thu, 5 Jun 1997 13:56:10 -0400
Encoding: 28 TEXT

------------------
Sharon Boeyen                 
Entrust Technologies
mailto:[email-masked]       Tel: (613) 765-4931
http://www.entrust.com          Fax: (613) 765-3520

         Orchestrating Enterprise Security

>
Hal Lockhart wrote:
>
>Well, in Peter Gutmann's excellent X.509 Style Guide, he specifically says
>multi-value RDNs should *not* be used, citing LDAP support and encoding
>issues as reasons. However, at the end of the section he does say
>"Everything will probably break when you move to LDAP anyway."
>
>
We use LDAP today with multivalued RDNs are have no problems. I'm not
sure what LDAP support or encoding are problems but this works fine and
there are several directory products which we have seen work fine. In
the earlier days there were some directory vendors who had
misinterpreted the standard and not supported the multi-valued RDN
concept but I'm not aware of any remaining products that don't support
>it today.
>

Date: Thu, 05 Jun 1997 10:15:57 -0600
From: Bob Jueneman <[email-masked]>
To: [email-masked], [email-masked]
Subject: Globally unique subjectUID?

>> From: Bob Jueneman <[email-masked]>
>> 
>> Unaccustomed as I am to lurking and reading a thread before jumping in
with
>> a response, I finally seem to be back on the PKIX mailing list, and would
>> like to contribute my 2 cents. 
>
>Welcome back, Bob!
>
>> However, just identifying the individual uniquely is not sufficient, and
>> unless I have suddenly had a metal lapse we will need a subjectUniqueID
in
>> order to differentiate between the different certificates that a single,
>> unambiguously identified user may validly possess.
>
>
>An unambiguously identified user may indeed have multiple certificates, but
>what purpose does a subjectUID have in distinguishing between them?  The
>serialNumber field is already unique per issuer.  Assuming that the
>"multiple humans with the same DN" issue is solved by the
>multiple-attribute terminal RDN, what other problem is addressed by
>a subjectUID that could not be addressed by using the serialNumber?
>

The "metal" lapse was obviously a "mental" one. You're quite right, the
serialNumber field is unique per issuer, and is sufficient to differentiate
between different certificates.

But before we deprecate it, lets think just a little longer.  There are some
strong arguments that could be made against a permanent national or
international ID number, especially from a privacy standpoint. But there are
also some strong arguments that can be made in favor of one, as is evidence
by the almost universal use of the Social Security Number, at least within
the US.

Sharon's recent point regarding uniqueness of names was right on target -- I
have tended to use the term globally unambiguous instead of uniqueness
regarding names.

But it occurs to me that if we were to define it correctly, subjectUID might
be a very useful attribute if it referred to the underlying, corporeal
ENTITY which is being named.

Names change, and in particular organizationalPerson names are likely to
change often. residentialPerson names are likely to change, especially if
geopolitical structures such as city and street names are used to provide an
unambiguous reference.  The multi-valued RDN can be used to eliminate the
ambiguity in one's common name, but the serial number has to be assigned by
the namregistration authroity, whether that is your company, your CA, or
maybe your ISP. But why should my name change just because I change jobs,
move, or change Internet provider?

And of course people sometimes change their common name as well. 

In addition to marriage and adoption, demands of orthography and current
convention can cause people to change their name. For example, my
great-grandfather's name was Ju(umlaut)nemann, but the u-umlaut became the
conventional ue when he moved to the US. And my father was born Frederick R.
Juenemann, but in grade school during WWI the use of the Germanic double-n
was rather unpopular, and he just dropped it. (His father, mother, and
sister did not, however.) Later, in the Army in WWII, the full Frederick
became a bother, and he shortened it to just Fred. As a result, his will
lists three aliases, Frederick R. Juenemann, Frederick R. Jueneman, and Fred
R. Jueneman, just to make sure there is no mistake.

(I'm sure that Shyh-Wei Luan can relate to this problem, as can many other
people of Asian heritage. Even the names of cities change, viz. Peking to
Beijing, Stalingrad to Leningrad, not to mention whole countries.)

If the subjectUID were a constant, unique and unambiguous reference to the
PERSON, there might be a lot of advantages. But this would require that it
the subjectUID not be unique per issuer, but globally unique.

It occurs to me that in addition to the hash of the birth certificate I
talked about, it might also be possible to some biometric indicia, such as
the map of fingerprint minutia. Or better yet, something that does not have
the negative forensic connotations of a fingerprint, such as a
representation of one's retinal pattern. At least no one ever got convicted
because of a latent retinal print!

Let's not discard this idea just yet -- it might have a lot of applicability
for access control and other similar mechanisms that would span name
changes.

Bob

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                    

Date: Thu, 05 Jun 1997 13:03:38 -0400
To: Sharon Boeyen <[email-masked]>, "[email-masked]'"  <[email-masked]>, "[email-masked]'" <[email-masked]>
From: Hal Lockhart <[email-masked]>
Subject: RE: X.509 certificate and its subject name field

At 10:13 AM 6/5/97 -0400, Sharon Boeyen wrote:

>Next issue I'd like to clarify is the requirement for uniqueness of
>names, regardless of certificates or access control. X.501 states that a
>name is a construct that identifies a particular from among the set of
>all objects. A name shall be unambiguous, that is, denotes just one
>object. However, a name need not be unique, that is, be the only name
>that unambiguously denotes an object.  As an example of what is meant
>here, my work name might be c=CA; o=Entrust Technologies; cn=Sharon
>Boeyen while my name as part of a different group (e.g. if I was a
>student taking evening courses) would be very different, however both
>identify me.  These names are supposed to be unambiguous among the set
>of ALL objects and therefore meet any requirements I've seen discussed
>on this list for what is being called "uniqueness".  It is up to the
>naming authority (not necessarily the same entity as the CA) to ensure
>this unambiguous property. 

This is the notion I was trying to get at. I think the spec should say this
explicitly.

>When you tie the requirement for unambiguous names to that which a PKI
>has  for the non-reuse of a name, adding a numeric identifier as part of
>the terminal RDN can satisfy both requirements as well as addressing any
>concerns over rogue CAs or naming authorities duplicating names.

I don't see how any scheme can prevent a rogue CA from creating a
certificate containing arbitrary contents and signing it.  I think this
problem can only be dealt with by market and legal mechanisms (don't honor
their certificates, sue them) and should be dropped from this discussion.
Inadvertent duplication is another matter.

>I still see this as a simpler way to address the problem that by
>combining any two fields together. I see a trend in companies toward DNs
>which have fewer rather than more RDNs in them. This reduces the
>frequency of DN changes due to organizational changes and also appears
>to make directory and database searching more efficient. Multi-valued
>RDNs support this 'short DN' approach and, with a serial number type
>component, can ensure that DNs (the full DN) are never re-used. All this
>can be accomplished in a single structure (the DN) and surely this is
>easier to match against than using multiple fields of a certificate. 

Well, in Peter Gutmann's excellent X.509 Style Guide, he specifically says
multi-value RDNs should *not* be used, citing LDAP support and encoding
issues as reasons. However, at the end of the section he does say
"Everything will probably break when you move to LDAP anyway."

Comments from Peter? others?

>I've seen nothing to convince me that use of the subjectUID or issuerUID
>fields provide any added value and to the contrary I think their use
>overcomplicates matters when matching on a single piece of data (the DN)
>can achieve the same thing.

It depends on whether you just want to unambigiously identify the subject,
or you would like extra semantics, such as stability over time.

If you want the latter, then you must either use an additional field or
precisely define what element(s) in the name carries this semantic.  As I
understand the pro-subjectUID view, the additional field is prefered because
a) it is not related to the DIT and b) specifying naming schemes is the
"third rail" of standardization efforts. (Touch it and you die. ;-)

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

Date: Thu, 5 Jun 1997 13:04:59 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: X.509 certificate and its subject name field

> From: Hal Lockhart <[email-masked]>
> 
> At 02:08 PM 6/4/97 -0400, David P. Kemp wrote:
> 
> >This definition of Name in <draft-ietf-pkix-ipki-part1-04.txt> is identical
> >to (i.e. taken directly from) the definition of Name in X.501.  X.509
> >imports this definition from X.501.  Not only is the *intent* for PKIX to
> >be the same as X.509, the ASN.1 is identical.
> 
> Peter gave me to understand that because of an ASN.1 version skew issue, the
> definitions in the draft are *not* the same as the ones in the latest X.509
> documents.

As far as I know, the latest drafts of the X.500 series documents are
maintained by Hoyt Kesterson, are named "97x5??Rev0.doc", and have file
revision dates of March 27 of this year.  The documents themselves are
based on the 1993 versions, and do not have internal release numbers or
revision dates, although they do have the new content denoted by strikeouts
and underlines.

The 97 draft of X.509 still uses Name as the subject field of a certificate,
and the 97 draft of X.501 still defines Name with the same ASN.1 as the 93
version (and the PKIX draft).

I'm not sure what version skew issues you are referring to.

> 
> >I don't understand your comment.  As I read the ASN.1 definition,
> >DistinguishedName and RDNSequence are synonymous.  Can you provide an
> >example of a sequence of RDNs which is not a Distinguished Name?
> 
> Sure.  How about "CN=John Smith"

And why is that not a perfectly legal Distinguished Name?  It certainly
complies with the ASN.1 definition of DN.

It isn't a searchable X.500 directory name, to be sure.  But X.509
certificates are to be used for more than just authentication to X.500
directories.

For intranet applications, for example, why shouldn't it be
legal for a company CA to issue certificates with DNs of the form:

  "CN=John Smith + SN=12345"

> >I believe it should be allowable for a single issuer to create multiple
> >certificates containing the same subject name, but differing in some
> >other attribute.  For example, to allow:
>    [... examples snipped]
> 
> Ok, unique per subject.  (But some of the contributors to this list seem
> prepared to treat every certificate as representing a distinct subject, even
> if it only differs in issue date or key.)

What is your definition of a "subject"?  The tautological definition of
"the entity referred to by the subjectName field of a certificate" isn't
useful - it's always unique "per subject".

If you believe that a single issuer should not create more than one
subjectName to refer to a particular flesh-and-blood human, I disagree
with that requirement also.  I as a human may want two different DNs
to refer to two different roles that I perform.

Date: Thu, 05 Jun 1997 10:01:15 -0700
To: [email-masked], "Housley, Russ" <[email-masked]>
From: Ned Smith <[email-masked]>
Subject: Re: X.509 certificate and its subject name field
Cc: [email-masked]

At 12:31 PM 6/5/97 -0700, Denis Pinkas wrote:
>Extracts from part 1
>
>(...)
>
>4.1.2.2  Serial number
>
>   The serial number is an integer assigned by the certification
>   authority to each certificate.  It must be unique for each
>   certificate issued by a given CA (i.e., the issuer name and serial
>   number identify a unique certificate).
>
What entity enforces uniqueness of issuer names? (Is this true relative to
a single TLCA)

>-- 
>
>      Denis Pinkas     Bull S.A.         E-mail : [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

Ned Smith~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Intel Architecture Labs  2111 N.E. 25th Ave.  Hillsboro, OR. 97124
Ph: 503.264.2692 Fax: x1805  Email: mailto:[email-masked]
http://www.intel.com/ial/security/index.htm
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Date: Thu, 05 Jun 1997 12:15:26 -0400
To: [email-masked] (David P. Kemp), [email-masked]
From: Hal Lockhart <[email-masked]>
Subject: Re: X.509 certificate and its subject name field

At 02:08 PM 6/4/97 -0400, David P. Kemp wrote:

>This definition of Name in <draft-ietf-pkix-ipki-part1-04.txt> is identical
>to (i.e. taken directly from) the definition of Name in X.501.  X.509
>imports this definition from X.501.  Not only is the *intent* for PKIX to
>be the same as X.509, the ASN.1 is identical.

Peter gave me to understand that because of an ASN.1 version skew issue, the
definitions in the draft are *not* the same as the ones in the latest X.509
documents.

>I don't understand your comment.  As I read the ASN.1 definition,
>DistinguishedName and RDNSequence are synonymous.  Can you provide an
>example of a sequence of RDNs which is not a Distinguished Name?

Sure.  How about "CN=John Smith"

>I believe it should be allowable for a single issuer to create multiple
>certificates containing the same subject name, but differing in some
>other attribute.  For example, to allow:
>
> * overlapping validity periods (issue a replacement cert slightly before
>   the previous cert expires, to provide a grace period).
>
> * different subjectPublicKeyInfo fields (one certificate with a digital
>   signature key and another with a privacy-enabling key,
>   or two signature certificates with different signature algorithms).
>
> * different privilege-granting extensions (attached to different public
>   keys, of course).

Ok, unique per subject.  (But some of the contributors to this list seem
prepared to treat every certificate as representing a distinct subject, even
if it only differs in issue date or key.)

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

From: Sharon Boeyen <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: X.509 certificate and its subject name field
Date: Thu, 5 Jun 1997 10:13:33 -0400
Encoding: 171 TEXT

Here's my 2 cents worth.

First lets clarify the naming terminology:

In the X.501 spec the general item is Name and it is defined as a choice
of which there is currently only one possibility rdnSequence
RDNSequence. Then we see that DistinguishedName is also defined to be
RDNSequence.  The reason for this is that we needed to leave the
specification of Name open so that if new name forms were later defined
they could be included in this construct. Fortunately standards that
followed (included those for name registration authorities) also adopted
the same choice and we still have no new name forms.  DistinguishedName
was defined so that it could be used within the directory specs and
elsewhere and that if new name forms were later defined we could still
use this specific one. 

Next issue I'd like to clarify is the requirement for uniqueness of
names, regardless of certificates or access control. X.501 states that a
name is a construct that identifies a particular from among the set of
all objects. A name shall be unambiguous, that is, denotes just one
object. However, a name need not be unique, that is, be the only name
that unambiguously denotes an object.  As an example of what is meant
here, my work name might be c=CA; o=Entrust Technologies; cn=Sharon
Boeyen while my name as part of a different group (e.g. if I was a
student taking evening courses) would be very different, however both
identify me.  These names are supposed to be unambiguous among the set
of ALL objects and therefore meet any requirements I've seen discussed
on this list for what is being called "uniqueness".  It is up to the
naming authority (not necessarily the same entity as the CA) to ensure
this unambiguous property. 

When you tie the requirement for unambiguous names to that which a PKI
has  for the non-reuse of a name, adding a numeric identifier as part of
the terminal RDN can satisfy both requirements as well as addressing any
concerns over rogue CAs or naming authorities duplicating names.

I still see this as a simpler way to address the problem that by
combining any two fields together. I see a trend in companies toward DNs
which have fewer rather than more RDNs in them. This reduces the
frequency of DN changes due to organizational changes and also appears
to make directory and database searching more efficient. Multi-valued
RDNs support this 'short DN' approach and, with a serial number type
component, can ensure that DNs (the full DN) are never re-used. All this
can be accomplished in a single structure (the DN) and surely this is
easier to match against than using multiple fields of a certificate. 

I've seen nothing to convince me that use of the subjectUID or issuerUID
fields provide any added value and to the contrary I think their use
overcomplicates matters when matching on a single piece of data (the DN)
can achieve the same thing.  Arguments over  the frequency of change of
DNs are dependent on the name scheme adopted by a naming authority and
can be argued in both directions forever! Similarly, arguments over
whether or not changes to a user's organizational affiliation or other
aspects of their name or any information in a certificate are also
dependent on a number of factors including the information itself, the
access control policy and the nature of decisions (ie identity based or
capability based) and could also go on forever. 

All the above is regardless of the repository issue so let's not get on
the X.500/LDAP bandwagon PLEASE!

Finally, a comment on the one aspect of the discussion that I believe IS
somewhat directory-specific. As for the user friendliness of DNs,
although that used to be a strong position of many, I believe that this
has gone by the wayside. When looking for information, end-users use
search filters not DNs and when retrieving a specific entry from a
directory the user-friendliness of a DN is irrelevant - we don't see DNs
on business cards which was one of the reasons given for
user-friendliness in the past.  I think this is also some of the history
that contributed to the creation of the subject and issuer UIDs in the
first place. Back then, when v2 certificates were defined, many still
believed that DNs were to be user friendly and adding a number to a DN
was not a popular way to go. The X.500 access control scheme identified
a requirement for this and this was the main reason those fields were
defined (however I'm not aware of any X.500 products actually using
this). Residential users is one area where perhaps user-friendliness can
be argued, although as Bob points out an agreed naming scheme for these,
which is also user-friendly, will be difficult to achieve. The reference
to "single women" by Bob was an issue I raised at an NADF meeting. It
was based on a lawsuit that was generated by the family of a woman who
had been killed by an ex-boyfriend. Although she had subscribed to
unlisted phone number, her number and street address had been published
inadvertently in a phone book and the lawsuit was against the company
that published the telephone directory. 

Sharon

------------------
Sharon Boeyen                 
Entrust Technologies
mailto:[email-masked]       Tel: (613) 765-4931
http://www.entrust.com          Fax: (613) 765-3520

         Orchestrating Enterprise Security

>----------
>From: 	[email-masked][SMTP:[email-masked]]
>Sent: 	June 4, 1997 2:08 PM
>To: 	[email-masked]
>Subject: 	Re: X.509 certificate and its subject name field
>
>> From: Hal Lockhart <[email-masked]>
>> 
>> This is directed to the authors of <draft-ietf-pkix-ipki-part1-04.txt>
>> 
>> The recent discussion on X.509 subject name field caused me to examine the
>> definitions in the document closely.  Currently the subject name field is
>> defined (section 4.1 & section 9) as a sequence of RNDs, *NOT* as a DN.
>
>Section 4.1 defines the tbsCertificate.subject field as a "Name", but does
>not include the definition of Name.  (I suggest that definitions for
>AlgorithmIdentifier and Name be included in section 4.1 as well as section
>9.)  Section 4.1.2.6 is silent on the definition of Name, but does say that
>the subject identity may be contained in either the subject field or the
>subjectAltName extension.
>
>Section 9 includes the following:
>
>   Name          ::= CHOICE { rdnSequence RDNSequence -- only one possibility
>}
>
>   RDNSequence   ::= SEQUENCE OF RelativeDistinguishedName
>
>   DistinguishedName ::= RDNSequence
>
>
>> While it is true that all DNs are sequences of RDNs, not all sequences of
>> RDNs are DNs.  Steve Kent, in a private communication, assured me that the
>> intent is to be the same as X.509, which defines the field as a DN. (I
>>don't
>> have ready access to that spec.)
>
>This definition of Name in <draft-ietf-pkix-ipki-part1-04.txt> is identical
>to (i.e. taken directly from) the definition of Name in X.501.  X.509
>imports this definition from X.501.  Not only is the *intent* for PKIX to
>be the same as X.509, the ASN.1 is identical.
>
>I don't understand your comment.  As I read the ASN.1 definition,
>DistinguishedName and RDNSequence are synonymous.  Can you provide an
>example of a sequence of RDNs which is not a Distinguished Name?
>
>Or, disregarding the ASN.1 definition for a moment, what point did
>you wish to make about subject names?  What types of RDN sequences
>do you wish PKIX to disallow?
>
>
>> My inclination is to go further and say that the subject name field is
>> intended to be unique per issuer, but perhaps that is beyond the scope of
>> the document.
>
>I believe it should be allowable for a single issuer to create multiple
>certificates containing the same subject name, but differing in some
>other attribute.  For example, to allow:
>
> * overlapping validity periods (issue a replacement cert slightly before
>   the previous cert expires, to provide a grace period).
>
> * different subjectPublicKeyInfo fields (one certificate with a digital
>   signature key and another with a privacy-enabling key,
>   or two signature certificates with different signature algorithms).
>
> * different privilege-granting extensions (attached to different public
>   keys, of course).
>
>The issuer/serial-number pair is guaranteed to uniquely identify a
>certificate, but I don't see any reason to require issuer/subject-name
>to be unique.  On the contrary, it would be quite harmful for PKIX to
>preclude the above examples.
>

Date: Thu, 05 Jun 1997 12:31:57 -0700
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: "Housley, Russ" <[email-masked]>
Cc: [email-masked]
Subject: Re: X.509 certificate and its subject name field

Housley, Russ wrote:
> 
> Denis:
> 
> What text do you propose to define unique?

At the time being no one recalls a scenario for using the issuer unique
identifier.
Unless there is an argument to support the use of the issuer unique
identifier, I would propose to modify the section 4.1.2.8 of the part 1
as follows:

4.1.2.8  Unique Identifiers

   The subject and issuer unique identifier are intended to handle 
   the possibility of reuse of subject and/or issuer names over time. 

   The subject unique identifier is an integer issued by a 
   certification authority that is unique during the life time of 
   a given certification authority and that is assigned by that 
   certification authority to the entity associated with the public 
   key stored in the subject public key field. It must be identical 
   for each updated certificate issued by a given CA (i.e., the issuer 
   name and the subject unique identifier identify a unique entity).

   When the subject unique identifier is used, end-entity names may be 
   re-used over time. 

   CAs conforming to this profile should not reuse issuer names. 
   Therefore they should not generate cross-certificates that 
   incorporate a subject unique identifier.

   CAs conforming to this profile should either not reuse end-entity 
   names or issue certificates with a subject unique identifier.

   CAs conforming to this profile should not issue certificates that 
   incorporate an issuer unique identifier.

   Applications conforming to this profile should be capable of 
   parsing subject unique identifiers and making comparisons.

----------------------------------------------------------------------

FYI:

Extracts from part 1

(...)

4.1.2.2  Serial number

   The serial number is an integer assigned by the certification
   authority to each certificate.  It must be unique for each
   certificate issued by a given CA (i.e., the issuer name and serial
   number identify a unique certificate).

(...)

4.1.2.6  Subject Name

   The subject name identifies the entity associated with the public key
   stored in the subject public key field. The subject identity may be
   carried in the subject field and/or the subjectAltName extension.  If
   identity information is present only in the subjectAltName extension
   (e.g., a key bound only to an email address or URI), then the subject
   name may be an empty sequence and the subjectAltName extension must
   be critical.

Extracts from part 3

(...)

Where appropriate, the term "end-entity" will be used to refer to end
entities who are not PKI management entities. 

(...)

4.1.8 Certificate Update

When a certificate is due to expire the relevant end entity may request 
that the CA update the certificate - that is, that the CA issue a new 
certificate which differs from the previous one only in terms of PKI 
attributes (serialNumber, validity, some extensions) and is otherwise 
identical.

-- 

      Denis Pinkas     Bull S.A.         E-mail : [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: Thu, 5 Jun 1997 08:21:49 +0200 (MET DST)
From: Jesper Pettersson <[email-masked]>
Cc: [email-masked]
Subject: unsubscribe [email-masked]

Date: Wed, 4 Jun 1997 22:44:45 -0300 (EST)
From: "E. Gerck" <[email-masked]>
To: "C. Bradford Biddle" <[email-masked]>
cc: PKIX List <[email-masked]>, SSL-Talk List <[email-masked]>, Dwight Arthur <[email-masked]>, [email-masked]
Subject: Re: relying-party contract

On Wed, 4 Jun 1997, C. Bradford Biddle wrote:

> 
>  Digital signatures, supported by
> a "public key infrastructure" of certification authorities (CAs)
> and certificate databases, can solve this authentication
> problem. 

This is a common misconception. As explained in the paper 

"Overview of Certification Systems: X.509, CA, PGP and SKIP", In MCG Web
Page, http://novaware.cps.softex.br/mcg/cert.htm, April, 1997. 

the notion that a CA adds trust or that it will magically infuse
"correctness" in otherwise unendorsed information is simply not
true on several counts.  Actually it adds a channel of "implicit spoofing"
by giving the user a sense of security that is simply not there. Also, the
UCC says that CAs are liable only for "methods" -- not for "results". But,
the information in a "certificate" is a result ... sigh! 

And, to the CA's defense defense it must be said that they are not 
hidding -- it is simply not possible to guarantee results with a system 
that depends on trust because a trust system is never 100% right and can 
be 100% wrong. That's life.

Solution? Yes, change the model.

> Ultimately this article argues that digital signature laws which
> impose a particular view of electronic commerce should be
> abandoned. 

Agreed 100%. Anyway, they are not technically correct either.

> Laws which remove specific, well-defined barriers
> to electronic commerce -- such as unnecessary "writing" or
> handwritten signature requirements -- and which allow the
> electronic commerce marketplace to evolve unfettered should
> be encouraged.

Agreed with great care. Current certificate technology cannot guarantee 
that the certified entity is not anonymous, dealing under a pseudonym.

Yours,

Ed Gerck

__________________________________________________________________________
Dr.rer.nat. E. Gerck                             Phone/Fax: +55-19-2429533
[email-masked]                   http://novaware.cps.softex.br
P. O. Box 1201   -   CEP 13001-970    -   Campinas    -   SP    -   Brazil

Date: Wed, 4 Jun 1997 14:49:03 -0700 (PDT)
From: "C. Bradford Biddle" <[email-masked]>
Reply-To: "C. Bradford Biddle" <[email-masked]>
To: PKIX List <[email-masked]>, SSL-Talk List <[email-masked]>, Dwight Arthur <[email-masked]>
cc: [email-masked]
Subject: Re: relying-party contract

I thought I'd de-lurk (uncloak?) from the PKIX list momentarily to chime
in on this topic. As someone coming to the PKI issue from a legal
perspective, I heartily concur with the view that there has been
inadequate cross-fertilization between the legal and technology
communities concerning PKI. This fact is rather striking, really, when you
consider how inexorably linked legal and technical issues are in this
area.

The one truly public list that I'm aware of that addresses legal issues
related to a PKI is [email-masked], but the scope of that list is
theoretically limited to the California digital signature legislation and
newly-released regulations. Nonetheless, for anyone interested, the
relevant info is: "send a mail message to
[email-masked]' with 'help' (no quotations) 
contained in the body of your message." 

The few other legal-oriented lists that I'm aware of where PKI issues are
discussed are closed lists -- i.e., lists associated with particular
American Bar Association committees, that sort of thing.  There's a list
run by the state of Texas which focuses on the efforts of NASIRE (I think
the acronym stands for "the National Association of State Information
Resource Executives") to develop accreditation standards for certification
authorities; this list could be characterized as "semi-public", I suppose. 
(I could provide subscription info privately if anyone's interested.) So,
I think that a public list which addressed PKI legal and policy issues,
and which integrated legal and technical discussions, could be interesting
and useful.

While I'm at it, I thought I'd mention a draft article I recently
completed which does address -- at least peripherally -- some of the
issues which Dwight Arthur raised.  I've appended the introduction to the
article below; the full article (18 double-spaced pages) is available at:

<http://www.acusd.edu/~biddle/LMW.htm> 

or you can start at my home page at:

<http://www.acusd.edu/~biddle>. 

The article is going to be printed in the summer issue of the World Wide
Web Journal in largely its current form. However, the San Diego Law Review
has offered me a slot for an article in their upcoming Internet Symposium
issue, and I'm planning on expanding this current article into a law
review piece for that issue. Thus I'm very interested in receiving
feedback and criticism as I develop this expanded article (June 30 is the
deadline for my next draft). I hope that some of you may have time to
provide your thoughts. 

Regards,
Brad

Brad Biddle <[email-masked]> [<--- PREFERRED ADDRESS]
Cooley Godward LLP <www.cooley.com>
4365 Executive Dr. Ste 1100, San Diego CA 92121
voice: (619) 550-6301  fax: (619) 453-3555

--------------------------------------------------------------

"Legislating Market Winners: Digital Signature Laws and the 
Electronic Commerce Marketplace"
 
The argument goes something like this: Internet commerce is
hampered by the authentication problem. There is no reliable
way to ensure that the sender of an electronic transmission is
in fact who they purport to be. Digital signatures, supported by
a "public key infrastructure" of certification authorities (CAs)
and certificate databases, can solve this authentication
problem. CAs will not emerge under the current legal regime,
however, because they face uncertain and potentially
immense liability exposure. Additionally, the legal status of
digitally signed documents is unclear. Therefore, legislation is
needed which defines and limits CA liability and which
establishes the legality of digitally signed documents.

This argument has captured an influential segment of the legal
community, and has led to the enactment of "digital signature
legislation" in several U.S. states and foreign nations.
Unfortunately, the argument is built on fundamentally flawed
assumptions, and the legislation enacted based upon it is
correspondingly flawed. Much (but not all) of the digital
signature legislation enacted to date presumes a vision of
electronic commerce that simply is not tenable, and which
would not "naturally" evolve in the marketplace. This
legislation poses the risk of profoundly distorting an infant
market and locking in business models which are harmful to
consumers and to the future development of electronic
commerce.

The type of public key infrastructure (PKI) envisioned by many
of the existing digital signature laws is not viable. The problem
is liability. Digital signature legislation drafters have assumed
that the potential liability exposure faced by CAs is somehow a
flaw of the existing legal regime. This is an erroneous
assumption: the liability exposure faced by CAs under the
"open PKI" model envisioned by legislation drafters is a
product of a business model that cannot internalize the costs
associated with its implementation. Moreover, in attempting to
limit the liability exposure of CAs, current digital signature laws
shift an immense liability burden onto consumers who use the
infrastructure envisioned by these laws. Putting this type of
liability burden on consumers violates long-held tenets of
public policy, and is a result which consumers would reject in
any truly "bargained for" transaction.

Digital signatures will undoubtedly play a significant role in
electronic commerce. However, rather than being
implemented in the "open PKI" model envisioned by various
digital signature laws, digital signatures are more likely to be
utilized under a "closed PKI" system. Under a closed PKI
system, the liability problems associated with digital
signatures become much more manageable. This article
describes the differences between open and closed PKI, and
suggests that, in the absence of legislative displacement,
certain marketplace trends indicate that closed PKI is indeed
the likely market winner. 

The open PKI model can and should compete against closed
PKI and other authentication technologies, and should not be
accorded special legal status via legislation. Such legislation is
unnecessary: the "contractual privity problem" which is used
to justify open PKI legislation is a red herring. Commercial CAs
utilizing the open PKI model can compete in the marketplace
without special PKI legislation. These CAs are unlikely to
succeed, not because of flaws with the legal system, but
because the open PKI model is not a winning business model.

Despite raising the very peculiar specter of regulating an
essentially nonexistent industry (CAs), and despite increased
recognition of the problems associated with the very specific
vision of electronic commerce embodied in these digital
signature laws, laws based on the open PKI model continue to
be proposed and implemented. This article suggests that one
of several factors behind the continued momentum of this
legislation, particularly at the federal and international levels, is
its synergy with cryptographic "key escrow" proposals. While
digital signature legislation ostensibly addresses the use of
cryptography only for the purposes of authentication, and not
for confidentiality, the infrastructure created by these laws is
ideal for implementing a key escrow scheme. 

Ultimately this article argues that digital signature laws which
impose a particular view of electronic commerce should be
abandoned. Laws which remove specific, well-defined barriers
to electronic commerce -- such as unnecessary "writing" or
handwritten signature requirements -- and which allow the
electronic commerce marketplace to evolve unfettered should
be encouraged.

Date: Wed, 04 Jun 97 12:10:27 
From: "Housley, Russ" <[email-masked]>
Encoding: 3548 Text
To: [email-masked]
CC: [email-masked]
Subject: Re[2]: X.509 certificate and its subject name field

Denis:

What text do you propose to define unique?

Russ

______________________________ Reply Separator _________________________________
Subject: Re: X.509 certificate and its subject name field
Author:  [email-masked]
Organization: Bull at internet
Date:    6/4/97 9:38 AM

Catching with all the E-mails exchanges in particular when Steve sends 
five E-mails on the same topic the same day (May, 30) is pretty hard. 
However Steve made a good conclusion on that topic, that I would like to 
recall:

Steve Kent wrote :

"Thus, in practice, it may be necessary to qualify ACL entries based on 
the entire cert path used to arrive at the Subject DN, or to impose 
constraints on the range of Subject names that any CA is "trusted" to 
certify. "

This is fine, but I would like to elaborate on it, taking some arguments 
from Shyh-Wei. Shyh-Wei says:

"This is why I think ACL's should be based on Subject UID's" and he 
provides an exemple with two CAs (and a single level of hierarchy) where 
the "target subject" is composed of a UID and a "CA subject".

Thus the proposed structure to place in an ACL would be: SubjectUniqueID 
+ CA name.

This may be considered as a variation of the scheme mentioned by Steve 
where the SubjectDN is replaced by the SubjectUniqueID ... and where the 
CA name may be a FDN or an alternate name.

Shyh-Wei considered only one level on CA hierarchy. When there are more 
either a rule must be used (both at the time of access and at the time 
of writing the ACL) or the certification path must be included (and must 
verified at the time of writing in the ACL). The drawback of the second 
method is to consider only a single path up to a root point and a static 
chain of trust.

This solves the problem of re-use of names at one level, but the problem 
is still there at the next level. However the major difference is that 
the next level is the name of some authority derived from a company or 
organization name and thus collisions of names are much easier to 
handle.

Now, instead of using directly the SubjectUniqueID + CA name a hash of 
it can be used, leading to what every one is looking for a compact : an 
ACL with fixed size entries. 

In addition it is needed to have (in common for several ACLs) not 
"comments" as mentionned by David Kemp but instead  "hints" that can be 
used to find the right up-to-date entries. The advantage is a fast check, 
the disadvantage may be a slow performance for reading ACLs.

The real question is whether this unique number should be part of the DN 
or placed in the SubjectUniqueID. There are advantages to place it in 
the SubjectUniqueID because:

1) a DN is supposed to be user friendly and a unique number is not 
   (this has been the primary argument used by ISO for years),

2) a FDN is long enough, so it is better to avoid adding another 
component,

3) no rules for parsing the FDN or the RDN are needed to extract the 
unique number.

For these reasons, I would propose that we support the SubjectUniqueID 
and that we do not deprecate its use.

Denis

Note: I do not recall why we added (upon a request from Digital) the 
issuerUniqueID. Sharon and Hoyt were both present. Does one of them (or 
some one else) remember ?

-- 

      Denis Pinkas     Bull S.A.         E-mail : [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: Wed, 4 Jun 1997 15:37:51 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: X.509 certificate and its subject name field

> From: Bob Jueneman <[email-masked]>
> 
> Unaccustomed as I am to lurking and reading a thread before jumping in with
> a response, I finally seem to be back on the PKIX mailing list, and would
> like to contribute my 2 cents. 

Welcome back, Bob!

> However, just identifying the individual uniquely is not sufficient, and
> unless I have suddenly had a metal lapse we will need a subjectUniqueID in
> order to differentiate between the different certificates that a single,
> unambiguously identified user may validly possess.

An unambiguously identified user may indeed have multiple certificates, but
what purpose does a subjectUID have in distinguishing between them?  The
serialNumber field is already unique per issuer.  Assuming that the
"multiple humans with the same DN" issue is solved by the
multiple-attribute terminal RDN, what other problem is addressed by
a subjectUID that could not be addressed by using the serialNumber?

>
>  [fascinating naming discussion snipped]
>

From: "Shyh-Wei Luan" <[email-masked]>
Date: Wed, 4 Jun 1997 12:11:11 -0700
To: [email-masked], Shyh-Wei Luan <[email-masked]>
Subject: Re: X.509 certificate and its subject name field
Cc: Stephen Kent <[email-masked]>, [email-masked]

Denis,

Some clarifications ...

On Jun 4,  4:22pm, Denis Pinkas wrote:

> Catching with all the E-mails exchanges in particular when Steve sends
> five E-mails on the same topic the same day (May, 30) is pretty hard.
> However Steve made a good conclusion on that topic, that I would like to
> recall:
>
> Steve Kent wrote :
>
> "Thus, in practice, it may be necessary to qualify ACL entries based on
> the entire cert path used to arrive at the Subject DN, or to impose
> constraints on the range of Subject names that any CA is "trusted" to
> certify. "

This was not a "conclusion" on the topic.  However, this was a premise that
Steve and I agreed upon.  Also note that the certification paths do not
need to be on the ACL's physically.  There can be a mapping scheme from
a certification path and a subject UID to some account number in the
applications, amd ACL's can use account numbers.  One can also map a
certification path and a sequence of name attributes to a *role* ID and
include that on ACL's.

> This is fine, but I would like to elaborate on it, taking some arguments
> from Shyh-Wei. Shyh-Wei says:
....
> Shyh-Wei considered only one level on CA hierarchy.

I have always considered the possiblity of a *certification path*.  My
examples were one-level for the simplicity.

> When there are more
> either a rule must be used (both at the time of access and at the time
> of writing the ACL) or the certification path must be included (and must
> verified at the time of writing in the ACL). The drawback of the second
> method is to consider only a single path up to a root point and a static
> chain of trust.

Applications would/should have a lot of freedom in doing the mapping from
CA paths/Subject IDs/DN attributes to local account ID's.

> This solves the problem of re-use of names at one level, but the problem
> is still there at the next level. However the major difference is that
> the next level is the name of some authority derived from a company or
> organization name and thus collisions of names are much easier to
> handle.

I think the next level up should also include Subject UID's.  For example,
IBM's CA may be certified by Department of Commerce's CA as (International
Business Machines Corportation, registered as xxxx-xxxx-xxxxx).

> Now, instead of using directly the SubjectUniqueID + CA name a hash of
> it can be used, leading to what every one is looking for a compact : an
> ACL with fixed size entries.

Applications can always use any certified identity/local ID mappings that fit
the needs to simplify ACL's.

> Note: I do not recall why we added (upon a request from Digital) the
> issuerUniqueID. Sharon and Hoyt were both present. Does one of them (or
> some one else) remember ?

I think the issuer's Unique ID probably does not make as much sense as the
Subject UID, since I have been arguing that the SUID should be temporally
unique within a CA's context - not a global unique ID.  So, IBM would have
a UID in the context of the Department of Commerce of US, and different UID's
in the contexts of other countries.

Shyh-Wei

Date: Wed, 4 Jun 1997 14:08:46 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: X.509 certificate and its subject name field

> From: Hal Lockhart <[email-masked]>
> 
> This is directed to the authors of <draft-ietf-pkix-ipki-part1-04.txt>
> 
> The recent discussion on X.509 subject name field caused me to examine the
> definitions in the document closely.  Currently the subject name field is
> defined (section 4.1 & section 9) as a sequence of RNDs, *NOT* as a DN.

Section 4.1 defines the tbsCertificate.subject field as a "Name", but does
not include the definition of Name.  (I suggest that definitions for
AlgorithmIdentifier and Name be included in section 4.1 as well as section
9.)  Section 4.1.2.6 is silent on the definition of Name, but does say that
the subject identity may be contained in either the subject field or the
subjectAltName extension.

Section 9 includes the following:

   Name          ::= CHOICE { rdnSequence RDNSequence -- only one possibility }

   RDNSequence   ::= SEQUENCE OF RelativeDistinguishedName

   DistinguishedName ::= RDNSequence

> While it is true that all DNs are sequences of RDNs, not all sequences of
> RDNs are DNs.  Steve Kent, in a private communication, assured me that the
> intent is to be the same as X.509, which defines the field as a DN. (I don't
> have ready access to that spec.)

This definition of Name in <draft-ietf-pkix-ipki-part1-04.txt> is identical
to (i.e. taken directly from) the definition of Name in X.501.  X.509
imports this definition from X.501.  Not only is the *intent* for PKIX to
be the same as X.509, the ASN.1 is identical.

I don't understand your comment.  As I read the ASN.1 definition,
DistinguishedName and RDNSequence are synonymous.  Can you provide an
example of a sequence of RDNs which is not a Distinguished Name?

Or, disregarding the ASN.1 definition for a moment, what point did
you wish to make about subject names?  What types of RDN sequences
do you wish PKIX to disallow?

> My inclination is to go further and say that the subject name field is
> intended to be unique per issuer, but perhaps that is beyond the scope of
> the document.

I believe it should be allowable for a single issuer to create multiple
certificates containing the same subject name, but differing in some
other attribute.  For example, to allow:

 * overlapping validity periods (issue a replacement cert slightly before
   the previous cert expires, to provide a grace period).

 * different subjectPublicKeyInfo fields (one certificate with a digital
   signature key and another with a privacy-enabling key,
   or two signature certificates with different signature algorithms).

 * different privilege-granting extensions (attached to different public
   keys, of course).

The issuer/serial-number pair is guaranteed to uniquely identify a
certificate, but I don't see any reason to require issuer/subject-name
to be unique.  On the contrary, it would be quite harmful for PKIX to
preclude the above examples.

Date: Wed, 4 Jun 1997 09:24:17 -0700 (PDT)
From: Marc Branchaud <[email-masked]>
Reply-To: Marc Branchaud <[email-masked]>
To: Dwight Arthur <[email-masked]>
cc: SSL-Talk List <[email-masked]>, PKIX List <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: relying-party contract

-----BEGIN PGP SIGNED MESSAGE-----

Having worked with lawyers on some certification issues up here in Canada,
my opinion is that it's always better to have an explicit contract than an
implicit agreement.  This is even more important given the novelty of
PKI-based transactions.  A contract would give a court a specific picture
of the intentions of all parties when they entered into the relationship.

That said, note the usual caveat: I am not a lawyer, I'm just a dog who
can type who's pretending to know something about legal matters.  As such,
it's very likely that I'm completely wrong.  :) 

As to a forum for these matters, I think that it's a bit beyond the scope
of either the ssl-talk or the pkix lists.  I don't know of any
PKI-legal-talk list, though...

		Marc

+----------------------------------------------------------------------+
Marc Branchaud            XCERT SOFTWARE INC.        Tel: 1-604-640-6210
Chief PKI Designer    1001-701 West Georgia Street   Fax: 1-604-640-6220
[email-masked]    PO Box 10145, Pacific Centre   Web: www.xcert.com 
                      Vancouver, Canada    V7Y 1C6
+----------------------------------------------------------------------+

On Wed, 4 Jun 1997, Dwight Arthur wrote:
> 
> Scenario one: confidential information
> Alice holds confidential information pertaining to Bob. Bob wishes to
> have Carol, who may be an employee, agent, or customer of Bob, access
> this information. Bob causes his CA to issue a certificate to Carol that
> identifies her and her relationship to Bob. Alice creates a web server
> that publishes this information to anyone with a certificate from Bob's
> CA where the relationship shown in the cert conveys authoriation to
> access this type of data.
> 
> Scenario two: transaction processing
> Same deal, except that Bob's cert enables Carol to enter transactions
> into Alice's systems.
> 
> The question: is there or should there be a legal agreement between Bob
> and Alice regarding the conditions under which Alice should accept Bob's
> certs and the liability that each carries? I understand that the general
> thinking is that the Certificate Policies or Certificate Practice
> Statement covers this, but I am questioning this.
> 
> If this is offtopic, my apologies and could you recommend a more
> appropriate forum?
> 
> IMHO the responsibilities and liabilities are as follows:
> 
> Bob's responsibilities to Alice:
> 1. Provide Alice with the root key of his CA
> 2. Issue certs to authorized persons conveying the accurate
> role/relationship data.
> 3. Promptly revoke certificates of any certified person where changes to
> the persons role or relationship so warrant.
> 4. Promptly make available via an agreed-upon mechanism and at or
> exceeding an agreed-upon frequency, notice of any revokations.
> 5. Take appropriate measures, and require certified persons to do the
> same, to prevent interception, misappropriation, or theft of certs or 
> of the private keys that underlie them.
> 
> Alice's responsibilities to Bob:
> 1. Prevent access to the protected data/transactions against anyone
> other that the holder of a cert (and of the associated private key) 
> signed with Bob's CA's key, that shows an appropriate (as agreed) 
> role or relationship for access to this data/transaction, and has 
> not been revoked.
> 2. Participate in whatever facility Bob's CA designates for notification
> of revokation.
> 
> Alice is liable to Bob for fradulent transactions if
> -Alice accepted an expired cert.
> -Alice accepted a cert from someone other than Bob's CA
> -Alice gave access to a holder of a cert from Bob's CA that did not
> demonstrate posession of the matching private key.
> -Alice gave access to a holder of a cert from Bob's CA that did not
> define the holder as having the role or relationship in Bob's
> organization that was defined as appropriate for access to the
> transaction.
> -Alice failed to reject a revoked cert despite receiving the appropriate
> notification from Bob's CA of the revokation at least X period of time
> before the transaction.
> 
> Bob is liable to Alice for fraudulent transactions if
> -Bob's CA issued a cert (with the appropriate role/relationship 
> shown) to a person who should not have had access to the transaction.
> -Bob's CA, Bob, the certified person, or someone else related to Bob
> permitted the cert and its prive ket to come into the posession of
> someone other than the intended certified person and did not
> revoke the cert.
> -Bob's CA revoked the cert without notifying Alice in time to stop 
> the transaction.
> 
> Question: doesn't there need to be a formal agreement between Bob
> and Alice to create these liabilities?
> Question: is there any prototype of such an agreement in existance?
> Question: what is the right forum for discussion of this issue?
> 
> Dwight Arthur
> Managing Director, Technology Planning
> National Securities Clearing Corporation, NY
> (212) 412-8687
> [email-masked]
> 

From: [email-masked] (Peter williams)
Date: Wed, 4 Jun 1997 09:01:44 -0700
To: [email-masked]
Cc: [email-masked] (SSL-Talk List), [email-masked] (PKIX List), [email-masked], [email-masked], [email-masked]
Subject: Re: relying-party contract

The VeriSIGN CPS (designed for muli-putpose applications in its
structuing) is already capable of governing the relationships, flows,
obligations and liabilities you mention. One would need a slight shift
of perpective to enable  governance in the scenario you mention, but the
design would  still be as intuitively valid as the particular management
system design and oblication/responsibility transfer protocol  your
scenario conceives.

Should there be a relying-party agreement - no, say I, if one was using
the architecture of the VERISIGN CPS - as such notions are reserved for
different semantics to the controls which your scenario is *really*
after instrumenting. (I agree about the terms if one follows your
scenario's management design;s flow and relationship model; but this,
I'm suggesting, would take CPS design into areas which CPS designers
have yet to tread! and it it may be easier to morph the suggested form
of the relationship back into more "conventional" forms, and reuse
existing responsibility-passing protocols embodied in such as the
VeriSign CPS, or equivalents from MISSI, SET and even RFC 1422.))

I suspect it is indeed time we created a CPS/Cert-issuing-policy list
with an internet-style culture, versus the several  semi-closed lists of
"studied legal/technical professionals". Just as finally we managed here
to open up security and CAs/cert to any & all players, getting any
willing players upto speed on technology and systems so they can choose
to do it oneself, or contract out as the economics beg, then so pehaps
we need to begin opening up the "technology" of CPSs and certificate
issuing *policies*, so folk get the capability of writing/specialising
their own "infrastructure practices", should they wish, based on a solid
understanding and sharing of the essentials, experence and knowlege.

Any site want to volunteer a mailing list responder or, Netscape, is it
acceptable to use this list for more than occasional infrastructure and
policy-related thread only semi-related to SSL?

Date: Wed, 4 Jun 1997 08:17:21 -0700
To: [email-masked]
Subject: ietf-pkix: housekeeping - please delete
Cc: [email-masked]
From: [email-masked]

                             /W\ 
                            (Ovo)
                            ))#)) 
-----------------------------m-m--------------------------------------------

Date: Wed, 4 Jun 1997 10:52:37 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked], [email-masked], [email-masked]
Subject: Re: ASN.1 dump/diagnostic utility updated

> From: [email-masked] (Peter Gutmann)
> To: [email-masked], [email-masked], [email-masked]
>  
> I've just updated my ASN.1 dump/diagnostic utility to handle the BER a bit 
> better, which means you can now display things like PKCS #7 objects and (in 
> general) anything else which mixes BER and DER-encoded data.  The program is 
> aware of most of the common crypto-related object identifiers and types, so 
> it'll give you a proper description of what it is you're looking at.  Here's 
> some sample output from the start of a cert:
>  
>    0 30  618: SEQUENCE {
>    4 30  467:   SEQUENCE {
>    8  2    4:     INTEGER 830525701
>   14 30   13:     SEQUENCE {
>   16  6    9:       OBJECT IDENTIFIER
>             :         md5withRSAEncryption (1 2 840 113549 1 1 4)
>   27  5    0:       NULL
>             :       }
>   29 30  125:     SEQUENCE {
>   31 31   11:       SET {
>   33 30    9:         SEQUENCE {
>   35  6    3:           OBJECT IDENTIFIER countryName (2 5 4 6)
>   40 13    2:           PrintableString 'Ca'
>             :           }
>             :         }
>   [etc]

Peter,

Thanks for publicising the program, making it available on your
website, and including an acknowledgement of the original in a
comment.  I had made a few changes since the version I sent you, to
make the output a bit more readable, in addition to supporting BER
data.  The following is what the new output looks like, from a posting
to ietf-pkix on April 15:

 offs tag lenbytes length        value
 ---- -- --------- ---  ----------------------
 0000 30 80        859: SEQUENCE 
 0002 30 82 02 c0  704: . SEQUENCE 
 0006 a0 03          3: . . [0] 
 0008 02 01          1: . . . INTEGER 2
 0011 02 02          2: . . INTEGER 256
 0015 30 0d         13: . . SEQUENCE 
 0017 06 09          9: . . . OID 1.2.840.113549.1.1.2: md2WithRSAEncryption
 0028 05 00          0: . . . NULL 
 0030 30 68        104: . . SEQUENCE 
 0032 31 0b         11: . . . SET 
 0034 30 09          9: . . . . SEQUENCE 
 0036 06 03          3: . . . . . OID 2.5.4.6: C
 0041 13 02          2: . . . . . PrintableString  'ES'

   [etc]

If you agree that the expanded header bytes and the alignment dots
(instead of braces) help readability, you may wish to add them to your
version.  Of course, indentation style is all a matter of taste, so
some people may prefer the earlier format :-).

Regards,
    dpk

Date: Wed, 04 Jun 1997 07:07:28 -0400
To: [email-masked]
From: Rodney Thayer <[email-masked]>
Subject: Re: ASN.1 dump/diagnostic utility updated
Cc: [email-masked]

Thank you!  We have retrieved this and used it at the ANX workshop.  P.s.
compiles with no problem in VC4.2 on Windows 95

At 11:22 AM 6/3/97, you wrote:
>[I've had quite a few requests for this so I'm sending this annoucement to
the 
> three most appropriate lists, apologies if you see it more than once]
> 
>I've just updated my ASN.1 dump/diagnostic utility to handle the BER a bit 
>better, which means you can now display things like PKCS #7 objects and (in 
>general) anything else which mixes BER and DER-encoded data.  The program is 
>aware of most of the common crypto-related object identifiers and types, so 
>it'll give you a proper description of what it is you're looking at.  Here's 
>some sample output from the start of a cert:
> 
>   0 30  618: SEQUENCE {
>   4 30  467:   SEQUENCE {
>   8  2    4:     INTEGER 830525701
>  14 30   13:     SEQUENCE {
>  16  6    9:       OBJECT IDENTIFIER
>            :         md5withRSAEncryption (1 2 840 113549 1 1 4)
>  27  5    0:       NULL
>            :       }
>  29 30  125:     SEQUENCE {
>  31 31   11:       SET {
>  33 30    9:         SEQUENCE {
>  35  6    3:           OBJECT IDENTIFIER countryName (2 5 4 6)
>  40 13    2:           PrintableString 'Ca'
>            :           }
>            :         }
>  [etc]
> 
>Hopefully the program will prove useful for picking apart certs and data 
>objects for debugging and diagnostic purposes, especially now that it
handles 
>BER data properly.  You can get it from 
>http://www.cs.auckland.ac.nz/~pgut001/dumpasn1.c.
> 
>Peter.
> 
>
>
>

                        ---- ----
               Rodney Thayer [email-masked]
Sable Technology Corporation +1 617 332 7292
           246 Walnut Street +1 617 332 7970 (Fax)
            Newton, MA 02160 

Date: Wed, 04 Jun 1997 10:23:39 -0400
To: [email-masked]
From: Hal Lockhart <[email-masked]>
Subject: Re: X.509 certificate and its subject name field
Cc: [email-masked]

This is directed to the authors of <draft-ietf-pkix-ipki-part1-04.txt>

The recent discussion on X.509 subject name field caused me to examine the
definitions in the document closely.  Currently the subject name field is
defined (section 4.1 & section 9) as a sequence of RNDs, *NOT* as a DN.
While it is true that all DNs are sequences of RDNs, not all sequences of
RDNs are DNs.  Steve Kent, in a private communication, assured me that the
intent is to be the same as X.509, which defines the field as a DN. (I don't
have ready access to that spec.)

Therefore, I suggest changing the draft spec to say that subject name (and
issuer name) are specifically DNs.  

My inclination is to go further and say that the subject name field is
intended to be unique per issuer, but perhaps that is beyond the scope of
the document.

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

Date: Wed, 04 Jun 1997 16:22:19 -0700
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: Shyh-Wei Luan <[email-masked]>
Cc: Stephen Kent <[email-masked]>, [email-masked]
Subject: Re: X.509 certificate and its subject name field

Catching with all the E-mails exchanges in particular when Steve sends
five E-mails on the same topic the same day (May, 30) is pretty hard.
However Steve made a good conclusion on that topic, that I would like to
recall:

Steve Kent wrote :

"Thus, in practice, it may be necessary to qualify ACL entries based on
the entire cert path used to arrive at the Subject DN, or to impose
constraints on the range of Subject names that any CA is "trusted" to
certify. "

This is fine, but I would like to elaborate on it, taking some arguments
from Shyh-Wei. Shyh-Wei says:

"This is why I think ACL's should be based on Subject UID's" and he
provides an exemple with two CAs (and a single level of hierarchy) where
the "target subject" is composed of a UID and a "CA subject".

Thus the proposed structure to place in an ACL would be: SubjectUniqueID
+ CA name.

This may be considered as a variation of the scheme mentioned by Steve
where the SubjectDN is replaced by the SubjectUniqueID ... and where the
CA name may be a FDN or an alternate name.

Shyh-Wei considered only one level on CA hierarchy. When there are more
either a rule must be used (both at the time of access and at the time
of writing the ACL) or the certification path must be included (and must
verified at the time of writing in the ACL). The drawback of the second
method is to consider only a single path up to a root point and a static
chain of trust.

This solves the problem of re-use of names at one level, but the problem
is still there at the next level. However the major difference is that
the next level is the name of some authority derived from a company or
organization name and thus collisions of names are much easier to
handle.

Now, instead of using directly the SubjectUniqueID + CA name a hash of
it can be used, leading to what every one is looking for a compact : an
ACL with fixed size entries. 

In addition it is needed to have (in common for several ACLs) not
"comments" as mentionned by David Kemp but instead  "hints" that can be
used to find the right up-to-date entries. The advantage is a fast
check, the disadvantage may be a slow performance for reading ACLs.

The real question is whether this unique number should be part of the DN
or placed in the SubjectUniqueID. There are advantages to place it in
the SubjectUniqueID because:

1) a DN is supposed to be user friendly and a unique number is not 
   (this has been the primary argument used by ISO for years),

2) a FDN is long enough, so it is better to avoid adding another
component,

3) no rules for parsing the FDN or the RDN are needed to extract the
unique number.

For these reasons, I would propose that we support the SubjectUniqueID
and that we do not deprecate its use.

Denis

Note: I do not recall why we added (upon a request from Digital) the
issuerUniqueID. Sharon and Hoyt were both present. Does one of them (or
some one else) remember ?

-- 

      Denis Pinkas     Bull S.A.         E-mail : [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: Wed, 04 Jun 1997 07:23:46 +0400
From: Dwight Arthur <[email-masked]>
Reply-To: [email-masked]
Organization: National Securities Clearing
To: SSL-Talk List <[email-masked]>, PKIX List <[email-masked]>
CC: [email-masked], [email-masked], [email-masked]
Subject: relying-party contract

Scenario one: confidential information
Alice holds confidential information pertaining to Bob. Bob wishes to
have Carol, who may be an employee, agent, or customer of Bob, access
this information. Bob causes his CA to issue a certificate to Carol that
identifies her and her relationship to Bob. Alice creates a web server
that publishes this information to anyone with a certificate from Bob's
CA where the relationship shown in the cert conveys authoriation to
access this type of data.

Scenario two: transaction processing
Same deal, except that Bob's cert enables Carol to enter transactions
into Alice's systems.

The question: is there or should there be a legal agreement between Bob
and Alice regarding the conditions under which Alice should accept Bob's
certs and the liability that each carries? I understand that the general
thinking is that the Certificate Policies or Certificate Practice
Statement covers this, but I am questioning this.

If this is offtopic, my apologies and could you recommend a more
appropriate forum?

IMHO the responsibilities and liabilities are as follows:

Bob's responsibilities to Alice:
1. Provide Alice with the root key of his CA
2. Issue certs to authorized persons conveying the accurate
role/relationship data.
3. Promptly revoke certificates of any certified person where changes to
the persons role or relationship so warrant.
4. Promptly make available via an agreed-upon mechanism and at or
exceeding an agreed-upon frequency, notice of any revokations.
5. Take appropriate measures, and require certified persons to do the
same, to prevent interception, misappropriation, or theft of certs or 
of the private keys that underlie them.

Alice's responsibilities to Bob:
1. Prevent access to the protected data/transactions against anyone
other that the holder of a cert (and of the associated private key) 
signed with Bob's CA's key, that shows an appropriate (as agreed) 
role or relationship for access to this data/transaction, and has 
not been revoked.
2. Participate in whatever facility Bob's CA designates for notification
of revokation.

Alice is liable to Bob for fradulent transactions if
-Alice accepted an expired cert.
-Alice accepted a cert from someone other than Bob's CA
-Alice gave access to a holder of a cert from Bob's CA that did not
demonstrate posession of the matching private key.
-Alice gave access to a holder of a cert from Bob's CA that did not
define the holder as having the role or relationship in Bob's
organization that was defined as appropriate for access to the
transaction.
-Alice failed to reject a revoked cert despite receiving the appropriate
notification from Bob's CA of the revokation at least X period of time
before the transaction.

Bob is liable to Alice for fraudulent transactions if
-Bob's CA issued a cert (with the appropriate role/relationship 
shown) to a person who should not have had access to the transaction.
-Bob's CA, Bob, the certified person, or someone else related to Bob
permitted the cert and its prive ket to come into the posession of
someone other than the intended certified person and did not
revoke the cert.
-Bob's CA revoked the cert without notifying Alice in time to stop 
the transaction.

Question: doesn't there need to be a formal agreement between Bob
and Alice to create these liabilities?
Question: is there any prototype of such an agreement in existance?
Question: what is the right forum for discussion of this issue?

Dwight Arthur
Managing Director, Technology Planning
National Securities Clearing Corporation, NY
(212) 412-8687
[email-masked]

From: "Shyh-Wei Luan" <[email-masked]>
Date: Tue, 3 Jun 1997 16:48:54 -0700
To: "E. Gerck" <[email-masked]>, Shyh-Wei Luan <[email-masked]>
Subject: Re: X.509 certificate and its subject name field
Cc: Stephen Kent <[email-masked]>, [email-masked], [email-masked]

> Shyh (or Shelly)

Please still call me Shyh-Wei.  :-)

> I don't know if you are aware, but there are many countries, such as the
> United Kingdom, where people can change their names without formality or
> official records, and can use several names for different purposes, none
> of which are more truly theirs than any other.  (Authors and entertainers
> commonly use several names.)
>
> So, you don't even need a driver's license ... Just change it! No
> formalities are needed.

My mentioning of a driver license name change was to make it a hypothetical
example analogous to that if I changed my DN on a digital certificate from DMV.

> But this has nothing to do with your "outdated" information, which was the
> reason for my comment above.  Again, you are mixing apples with
> speedboats ;-)

I guess you are very particular on the definition of "outdated information".
Frankly, I feel your use of the "mixing apples with speedboats" comment
itself is probably mixing apples with speedboats.  :-)

Shyh-Wei

Date: Tue, 3 Jun 1997 20:35:27 -0300 (EST)
From: "E. Gerck" <[email-masked]>
To: Shyh-Wei Luan <[email-masked]>
cc: Shyh-Wei Luan <[email-masked]>, Stephen Kent <[email-masked]>, [email-masked], [email-masked]
Subject: Re: X.509 certificate and its subject name field

On Tue, 3 Jun 1997, Shyh-Wei Luan wrote:

> On Jun 3,  5:24pm, E. Gerck wrote:
> > Subject: Re: X.509 certificate and its subject name field
> > On Tue, 3 Jun 1997, Shyh-Wei Luan wrote:
> >
> > > In any case, I don't think this is relevant to my original point that many
> > > businesses *can* tolerate outdated names/addresses.
> > >
> >
> > I have been following this sometimes amusing exchange, on various
> > difficulties with naming spaces, and I thought I could add:
> >
> > 1. so-called "outdated" names/addresses are better called history-lists.
> > That's their sole purpose -- in case you need historical data (either
> > because the current address is not valid anymore and you need another
> > place to start looking or for credit evaluation, etc.). You never would
> > use history-lists as a current-list.
> >
> > 2. so-called "outdated" names/addresses can never be used at par with
> > current names/addresses -- that's what ISO900x is all about. Control your
> > information and don't mix apples with speedboats.
> 
> Say, IF I change my name to "Shelly William Luan" (suggested by a netter
> yesterday :) on my driver license today and do NOT feel like to tell my
> banks.  To the banks, the current name IS "Shyh-Wei Luan".  This will be the
> case until I tell my banks, maybe on my next visit or phone call with them,
> that
> a name change happened.  This is a quite common business practice.  I don't how
> one can force or implement immediate name updates in all places.  Maybe it can
> be done in some anthoritarian countries. :-)
> 

Shyh (or Shelly)

I don't know if you are aware, but there are many countries, such as the
United Kingdom, where people can change their names without formality or
official records, and can use several names for different purposes, none
of which are more truly theirs than any other.  (Authors and entertainers
commonly use several names.)

So, you don't even need a driver's license ... Just change it! No
formalities are needed.

But this has nothing to do with your "outdated" information, which was the
reason for my comment above.  Again, you are mixing apples with 
speedboats ;-)

Yours,

Ed Gerck

__________________________________________________________________________
Dr.rer.nat. E. Gerck                             Phone/Fax: +55-19-2429533
[email-masked]                   http://novaware.cps.softex.br
P. O. Box 1201   -   CEP 13001-970    -   Campinas    -   SP    -   Brazil

From: "Shyh-Wei Luan" <[email-masked]>
Date: Tue, 3 Jun 1997 16:12:04 -0700
To: "E. Gerck" <[email-masked]>, Shyh-Wei Luan <[email-masked]>
Subject: Re: X.509 certificate and its subject name field
Cc: Stephen Kent <[email-masked]>, [email-masked], [email-masked]

On Jun 3,  5:24pm, E. Gerck wrote:
> Subject: Re: X.509 certificate and its subject name field
> On Tue, 3 Jun 1997, Shyh-Wei Luan wrote:
>
> > In any case, I don't think this is relevant to my original point that many
> > businesses *can* tolerate outdated names/addresses.
> >
>
> I have been following this sometimes amusing exchange, on various
> difficulties with naming spaces, and I thought I could add:
>
> 1. so-called "outdated" names/addresses are better called history-lists.
> That's their sole purpose -- in case you need historical data (either
> because the current address is not valid anymore and you need another
> place to start looking or for credit evaluation, etc.). You never would
> use history-lists as a current-list.
>
> 2. so-called "outdated" names/addresses can never be used at par with
> current names/addresses -- that's what ISO900x is all about. Control your
> information and don't mix apples with speedboats.

Say, IF I change my name to "Shelly William Luan" (suggested by a netter
yesterday :) on my driver license today and do NOT feel like to tell my
banks.  To the banks, the current name IS "Shyh-Wei Luan".  This will be the
case until I tell my banks, maybe on my next visit or phone call with them,
that
a name change happened.  This is a quite common business practice.  I don't how
one can force or implement immediate name updates in all places.  Maybe it can
be done in some anthoritarian countries. :-)

Shyh-Wei

From: "Shyh-Wei Luan" <[email-masked]>
Date: Tue, 3 Jun 1997 15:10:33 -0700
To: Stephen Kent <[email-masked]>, Shyh-Wei Luan <[email-masked]>, [email-masked]
Subject: Re: X.509 certificate and its subject name field
Cc: [email-masked]

Steve,

On Jun 3,  3:58pm, Stephen Kent wrote:
> Subject: Re: X.509 certificate and its subject name field
> Shyh-Wei,
>
> We disagree on what the common model of PKIs will be, and maybe that's at
> the heart of some other disagreements as well.  There is no single
> idetifier, nor even a small number of them, that can be put into certs and
> that are ideal for all the transactions in which I engage.

As you noted below, using certificates for authentication does not rule out the
possibility that certified identities get mapped to local account numbers for
transactions.

> One approach is
> to have each business with whom I interact do a mapping from generic certs
> to their databases, but another approach is to have the business issue me a
> cert to facilitate later interactions.

I would rather have fewer ID's that I can use almost anywhere than having
a lot of ID's that become a headache to maintain and recover upon losses.
When my ThinkPad (or my smart card with its PIN) filled with certs from
hundred's of businesses gets stolen, I will be painfully struggling with
remembering all those businesses to ask them to revoke their certs for me.
Are you guys trying to help create a "Cert Sentinel" business? :-)

> The issuance might be predicated on
> use of a generic cert from a governmental org or a third party like
> VeriSign, CertCo, CertiCom, ..., or it may be based on knowledge from an
> existing customer database.  The later approach is what we are seeing now
> in several systems ,e.g., Liberty Financial was among the first, and what I
> expect may become commonplace.  It has numerous advantages relative to
> reliance on certs issued by other orgs, especially orgs that try to
> simultaneously charge for certs and disavow any liability.

If we are not going to have any trustworthy public CA's that can be the basis
of
legality or arbitration, why would you bother to predicate the issuance of
per-business certificates with the public cert's?  False sense of assurance?

> This was the
> focus of my keynote talk at the DIMACS trust management workshop last fall,
> and the subject of a paper that will soon be released.

I will certainly be interested in reading the paper when it's available.

Shyh-Wei

Date: Tue, 3 Jun 1997 17:24:09 -0300 (EST)
From: "E. Gerck" <[email-masked]>
To: Shyh-Wei Luan <[email-masked]>
cc: Stephen Kent <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: X.509 certificate and its subject name field

On Tue, 3 Jun 1997, Shyh-Wei Luan wrote:

> In any case, I don't think this is relevant to my original point that many
> businesses *can* tolerate outdated names/addresses.
> 

I have been following this sometimes amusing exchange, on various 
difficulties with naming spaces, and I thought I could add:

1. so-called "outdated" names/addresses are better called history-lists. 
That's their sole purpose -- in case you need historical data (either 
because the current address is not valid anymore and you need another 
place to start looking or for credit evaluation, etc.). You never would 
use history-lists as a current-list.

2. so-called "outdated" names/addresses can never be used at par with 
current names/addresses -- that's what ISO900x is all about. Control your 
information and don't mix apples with speedboats.

Cheers,

Ed Gerck

__________________________________________________________________________
Dr.rer.nat. E. Gerck                             Phone/Fax: +55-19-2429533
[email-masked]                   http://novaware.cps.softex.br
P. O. Box 1201   -   CEP 13001-970    -   Campinas    -   SP    -   Brazil

Date: Tue, 3 Jun 1997 15:58:12 -0400
To: Shyh-Wei Luan <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: X.509 certificate and its subject name field
Cc: [email-masked], [email-masked]

Shyh-Wei,

We disagree on what the common model of PKIs will be, and maybe that's at
the heart of some other disagreements as well.  There is no single
idetifier, nor even a small number of them, that can be put into certs and
that are ideal for all the transactions in which I engage.  One approach is
to have each business with whom I interact do a mapping from generic certs
to their databases, but another approach is to have the business issue me a
cert to facilitate later interactions.  The issuance might be predicated on
use of a generic cert from a governmental org or a third party like
VeriSign, CertCo, CertiCom, ..., or it may be based on knowledge from an
existing customer database.  The later approach is what we are seeing now
in several systems ,e.g., Liberty Financial was among the first, and what I
expect may become commonplace.  It has numerous advantages relative to
reliance on certs issued by other orgs, especially orgs that try to
simultaneously charge for certs and disavow any liability.  This was the
focus of my keynote talk at the DIMACS trust management workshop last fall,
and the subject of a paper that will soon be released.

Steve

Date: Tue, 3 Jun 1997 15:34:34 -0400
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: Re: X.509 certificate and its subject name field
Cc: [email-masked]

Peter,

	Using a hash of the public key as a search key has some advantages
for individual ACL entries, but does not support group entries that are
tied to the structure of the DN, e.g., granting access to all members of a
department within an org, as has been pointed out in earlier messages.  So,
the question arises as to whether one wants multiple ACL entry types based
on individual vs. group ACL entries.  Also, the key hash is not a very good
way to look up a cert in a large environment, because it does not embody
the name structure that X.500 uses to allow for distriubution of the DIT.

Steve

Date: Tue, 3 Jun 1997 15:41:40 -0400
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: Re: X.509 certificate and its subject name field
Cc: [email-masked], [email-masked]

Kepa,

	Sorry, you (we?) don't ghet to make up our minds on the structure
of "the hierarchy" since there are multiple PKIs out there and more to
come.  DNs are supposed to be unique, and probably will be in general, but
a less than legitimate CA could always intentionally issue a DN that was a
dulplicate, so prudent design always calls for not relying on the
uniqueness of the DN.

Steve

Date: Tue, 3 Jun 1997 15:45:17 -0400
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: Re: X.509 certificate and its subject name field
Cc: [email-masked]

Kepa,

	If one keeps private keys on a hard drive, e.g., encrypted with a
password, then one will eventually get what one deserves!  More reasonable
approaches to multiple certs and different keys are based on crypto
hardware tokens to protect the keys, any maye to hold the certs.  The smart
card folks do have some severe storage limitations, so I acn imagine them
pushing for fewer keys/certs, but PC cards have lots of storage capacity.
So, whether different keys for different certs is attractive relative to
revocation due to compromise is an implementation-specific issue.

Steve

From: "Shyh-Wei Luan" <[email-masked]>
Date: Tue, 3 Jun 1997 12:22:19 -0700
To: Stephen Kent <[email-masked]>, [email-masked], [email-masked]
Subject: Re: X.509 certificate and its subject name field
Cc: [email-masked]

Steve,

On Jun 3,  9:29am, Stephen Kent wrote:

> Shyh-Wie,

My name should be Shyh-Wei.  Isn't that difficult? :-)

>       Your bank, newspaper, etc. won't care about your old vs. new name;
> they care about your account number and that is what they might use to
> uniquely identify you in a cert that each of them might issue to you for
> doing business with them.

I think a PKI, when adequately deployed, will have the potential of
eliminating the certification need/burden from most applications.  Isn't that
a part of the wonderfulness of a PKI?  I will probably be certified by a DMV,
my employer, and a few other places, just like that I don't have many ID's in
my pocession.  Using public, third-party certified certificates/keys would also
provide some advantages in auditing by providing some evidences in some cases
of
repudiation disputes.

My banks and newspapers care about my account number as a key to access my
account.  They prove my identity through other means, e.g., by looking at
my driver license, asking for my SSN, zip code, to verify them against
my account data.  Now they will be provided a new means for on-line identity
verification - a digital certificate that functions like an on-line ID.
They will be able to verify the identity associated with a cited account
number by checking a third-party issued certificate.

In any case, I don't think this is relevant to my original point that many
businesses *can* tolerate outdated names/addresses.

Shyh-Wei

Date: Tue, 3 Jun 1997 09:29:50 -0400
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: Re: X.509 certificate and its subject name field
Cc: [email-masked], [email-masked]

Shyh-Wie,

	Your bank, newspaper, etc. won't care about your old vs. new name;
they care about your account number and that is what they might use to
uniquely identify you in a cert that each of them might issue to you for
doing business with them.

Steve

From: Kepa Zubeldia <[email-masked]>
Subject: Re: X.509 certificate and its subject name field
To: [email-masked] (David P. Kemp)
Date: Mon, 2 Jun 1997 19:19:30 -0600 (MDT)
Cc: [email-masked]
Reply-To: [email-masked]

Dave,

I wasn't trying to make a case for one key per person.  The question
came up as a result of a discussion on how to get a persistent ID that
would work across certificates issued by different CAs for ACL use.  
You have very clearly expressed, and I totally agree, why having one 
key per person is not practical.  Next time I will try to stick closer 
to the subject.

Kepa

Kepa Zubeldia
Arcanvs, Inc.
371 Sanders Lane
Kaysville, UT 84037
[email-masked]

> > Steve,
> > 
> > I understand the problem about using the same key in multiple certs.
> > However, I am becoming increasingly concerned about my ability to
> > maintain a large cert wallet ten years from now.  
> > 
> > In the physical world, if my wallet is stolen, all my credit cards
> > are compromised.  It would be easier for me to carry one smart card
> > with all my accounts and let me decide which account to use for each
> > transaction, instead of having a thick wallet with all the cards.
> > The end result is the same.

> Absolutely.  So what is the real-world requirement for you to maintain
> a large cert wallet, and what is the motivation for using the same key
> on more than one cert?

> It would be easiest if you had a single keypair and a single cert that
> you use for all accounts - writing checks at the bank, checking out a
> video at Blockbuster, charging something at Macy's, etc.  If the strength
> of the cert issuer is greater than the strength requirements of all the
> prospective account issuers, this is possible, and certainly much easier
> on the consumer than having each bank, store, library, etc issuing its
> own certs.

> But if you assume that you will have different certificates for different
> purposes, what precisely is the advantage of sharing keys between any
> of them?  You still need a fat wallet and the administrative burden of
> choosing which cert to use.  It should be no more difficult to choose
> between two certs with different keys than between two certs with the
> same key.  What benefit is there to sharing keys?

> > In the computer world, if one of my private keys is compromised, most
> > likely all of the keys on that hard drive (or storage device) should
> > be revoked, because they are also at risk.

> That's a plausible example.  But why does that argue for sharing
> keys between certs?  If you use different keys for different certs, you
> have the option of revoking one, some, or all of them as circumstances
> dictate.  If you have a single key for all purposes, you lose all
> flexibility for handling them differently.  You can't store some
> private keys more securely than others (on a token vs. a hard drive),
> for example.

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked]
Subject: ASN.1 dump/diagnostic utility updated
Sender: [email-masked]
Reply-To: [email-masked]
Date: Tue, 3 Jun 1997 11:22:48 (NZST)

[I've had quite a few requests for this so I'm sending this annoucement to the 
 three most appropriate lists, apologies if you see it more than once]
 
I've just updated my ASN.1 dump/diagnostic utility to handle the BER a bit 
better, which means you can now display things like PKCS #7 objects and (in 
general) anything else which mixes BER and DER-encoded data.  The program is 
aware of most of the common crypto-related object identifiers and types, so 
it'll give you a proper description of what it is you're looking at.  Here's 
some sample output from the start of a cert:
 
   0 30  618: SEQUENCE {
   4 30  467:   SEQUENCE {
   8  2    4:     INTEGER 830525701
  14 30   13:     SEQUENCE {
  16  6    9:       OBJECT IDENTIFIER
            :         md5withRSAEncryption (1 2 840 113549 1 1 4)
  27  5    0:       NULL
            :       }
  29 30  125:     SEQUENCE {
  31 31   11:       SET {
  33 30    9:         SEQUENCE {
  35  6    3:           OBJECT IDENTIFIER countryName (2 5 4 6)
  40 13    2:           PrintableString 'Ca'
            :           }
            :         }
  [etc]
 
Hopefully the program will prove useful for picking apart certs and data 
objects for debugging and diagnostic purposes, especially now that it handles 
BER data properly.  You can get it from 
http://www.cs.auckland.ac.nz/~pgut001/dumpasn1.c.
 
Peter.

Date: Mon, 02 Jun 1997 16:50:20 -0600
From: Bob Jueneman <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: X.509 certificate and its subject name field

Unaccustomed as I am to lurking and reading a thread before jumping in with
a response, I finally seem to be back on the PKIX mailing list, and would
like to contribute my 2 cents.  Because I believe this is primarily a PKIX
subject, I've deleted the ssl-talk list, but have no objection if someone
wants to repost it there.

Shyh-Wei Luan led off by saying:

>I have some concerns with how people are using X.509 certificates and a
>recommendation of depend ending on non-reusable names.
>
>X.509 certificate has the following two fields that are used to
>define a subject's identity, where the "subject" is the entity being
>authenticated.
>
>    subject
>    subjectUniqueID
>
>The "subject" field identifies the entity with a general name, where
>the subjectUniqueID field is used to handle the possibility of reuse of
>subject's general name.  It is currently suggested in
>draft-ietf-pkix-ipki-part1-04.txt, "Internet Public Key Infrastructure,
Part
>I: X.509 Certificate and CRL Profile," that the subject name should not be
>reused, and the subjectUniqueID should be left unused.
>
>Here are two paragraphs excerpted from the draft:
>
>"The subject name identifies the entity associated with the public key
>stored in the subject public key field.  The subject identity may be
carried
>in the subject field and/or the subjectAltName extension.  If identity
>information is present only in the subjectAltName extension (e.g., a key
bound
>only to an email address or URI), then the subject name may be an empty
>sequence and the subjectAltName extension must be critical."
>
>"The subject and issuer unique identifier are present in the certificate
>to handle the possibility of reuse of subject and/or issuer names over
time.
>This profile recommends that names not be reused and that Internet
certificates
>not make use of unique identifiers.  CAs conforming to this profile should
not
>generate certificated with unique identifiers.  Applications conforming to
>this profile should be capable of parsing unique identifiers and making
>comparisons."
>
I agree with his concern, independent of his rationale.

As several people have pointed out, the use of a multiple-value terminal RDN
in a DN is almost inevitable in any large organization, just because people
sometimes have the same name as others. Within a named organization, which
is a de facto name registration authority, the use of a serial number is
both useful and convenient as a way of differentiating between two people
with the same name. Of course, the serial number by itself doesn't tell you
which one is which -- in the case of a directory you need to look at some
other attribute, such as organizational unit, hair and eye color, a
digitized photograph ,etc., to differentiate between two such individuals. 
In the case of a certificate,  you may or may not have access to the other
qualifying information, depending on what the individual decides to make
available.

Because standards are notorious for specifying the syntax with exactitude,
while remaining silent on the issue of semantics, I would recommend that the
use of a multi-valued RDN as a means of identifying a user be specifically
encouraged. And we should not only address the issue of uniqueness in terms
of space, but also time, and take some kind of position with regard to the
reuse of a DN after the first individual dies or leaves the organization.

However, just identifying the individual uniquely is not sufficient, and
unless I have suddenly had a metal lapse we will need a subjectUniqueID in
order to differentiate between the different certificates that a single,
unambiguously identified user may validly possess. 

I will certainly have at least two certificates -- one for encryption, and
one for signing documents. I may choose to use a number of different
encryption/decryption key pairs to limit the loss in the event one key is
compromised. I may have keys from a variety of CAs, and I may use more than
one algorithm. 

The profile recommends that names not be reused, and then seems to conclude
that if names aren't reused there will be no need to use a uniqueID. But
this isn't true -- I the user can certainly reuse my own name across
multiple certificates, and so a uniqueID is needed.

Now let me return to the issue of what kind of a multi-valued RDN qualifier
should be used to create/guarantee uniqueness.

Except in the case of an organizational person, whose DN includes the name
of the organization which is effectively acting as a name registration
authority, I believe that the terminal RDN should be a triple, consisting of
the user's commonName, THE NAME OF THE NAME REGISTRATION AUTHORITY, and the
serial number assigned by that name registration authority.

As I am sure that Sharon Boyen remembers, during the waning days of its
existence the NADF tried to grapple with the issue of how to assign unique
names to residential persons, when the "natural" geopolitical name
registration authority did not exist or was not prepared to carry out that
function.

In the early days of PEM, we rather blithely assumed that the various states
would inevitably step up to the role of registering the citizens within its
territory and assigning some kind of an ID (like a driver's license number)
to ensure uniqueness.  Unfortunately, it has become obvious that the states
haven't yet seen fit to carry out our mandate.

No sweat, we said -- we'll just put a sufficient amount of information in
the DN as to ensure uniqueness, including the state, city or locality name,
street address, apartment number, etc. I even started a treatise on naming
for all sorts of obscure conditions -- jails and other forms of communal
living, addressing issues in territories such as the Marshall Islands, how
nomadic peoples and Indian tribes are address, what to do about APO
addresses, merchant ships, and quasi-permanent structure beyond the
continental limits (oil towers and ocean mining, etc.). 

Charlie Combs of MCI did an fascinating study of names in one of the popular
phone listing CDS which revealed all sorts of interesting anomalies. (For
example, there were 23,852 Smith's in Tennessee, of which the most popular
first name was Naid, and out of the 46,103 Smith's in Florida, 170 had the
name Riet M?? And in Los Angeles, there were 1098 Smith's registered in the
90000 ZIP (which doesn't exist), most of whom had no first name and no
street address. It turns out that in California, the telephone company
charges you more for an unlisted number, but doesn't check to see if you
name or address are correct, or even meaningful.

But Sharon brought me up short with a feminine perspective that hadn't
occurred to me.  In an X.500 directory, the Distinguished Name is available
for everyone to see, and cannot be subject to access controls. She pointed
out that many people, especially single women, are not likely to want to
have their complete name and street address available for everyone to see,
and routinely list only their first initial.

So for residential users we have a potentially serious privacy problem if we
assume that name resolution will be performed by address qualification. In
addition, as a result of competition, there is no natural monopoly that we
could count on within a given territory. Even local telephone companies
service boundaries do not necessarily correspond to geopolitical boundaries.
And Internet Service Providers and CAs obviously compete for business.

So the best suggestion that I can come up with is to list the name of the de
facto name registration authority as the second element of the terminal RDN,
followed by a unique serial number assigned by that authority.  In many
cases the name registration authority will be the CA, and there is nothing
wrong with that. But at least conceivably the name registration authority
might not be the CA -- it could be the IEEE, or the ACM, or the American Bar
Association, etc. It could even be a different CA, so long as that CA can
still assure name uniqueness. And there are some due diligence issues
involved in using an organization plus a membership number, like what if
that person is no longer a member in good standing.

I almost hesitate to suggest it, but there is one other possibility. I once
wrote a paper on military and commercial computer security issues that
focused on Integrity, and I observed that the Discretionary Access control
requirements for B3 level systems require the ability to not only include a
specif individual, but also to exclude named individuals.  If that
requirement were taken seriously at a network level, it would presumably
mean that such individuals ought to be excluded from access even through
they had changed their name, obtained multiple certificates from different
name registration authorities, etc.

The only scheme that I could come up with that would solve that problem was
the use of a message digest that would be computed over specific elements or
fields in an individual's birth certificate (or record of adoption or
immigration documents in the case of people coming from countries where such
records are not kept). As I recall, I included the subject's birth name, the
mother's maiden name, the date/time and place the birth occurred, and the
name of the person registering the birth (normally the attending physician).
 Except possibly for born-again Christians, this information never changes,
and would apply throughout most of the world.

The reason why I hesitate to suggest it is that although it would be very
powerful, and could be rather easily verified, it could easily become a
ubiquitous international ID number. Anyone without one would effectively be
an "unperson".

Bob

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

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

From: "Shyh-Wei Luan" <[email-masked]>
Date: Mon, 2 Jun 1997 13:15:42 -0700
To: Stephen Kent <[email-masked]>, Shyh-Wei Luan <[email-masked]>
Subject: Re: X.509 certificate and its subject name field
Cc: [email-masked], [email-masked]

Steve,

It is not clear to me which part of my postings you are referring to as a
misunderstanding here.

I know it is necessary to have some way to distinguish identities through the
use of RDN attributes.  What I think was not required was the use of full DNs
*in ACL entries*.  Sometimes we can use Subject UID's for identity-based
access control and some other times we can use name attributes (or partial
DN's, if you will) for role-based access control.

Shyh-Wei
--------

On Jun 2,  9:51am, Stephen Kent wrote:
> Subject: Re: X.509 certificate and its subject name field
> Shyh-Wei,
>
>       I appreciate your arguments.  However, there is one note at the end
> that suggests a misunderstanding re the use of an employee number or
> similar attribute in the terminal RDN.  This is not an optional thing to do
> as an alternative for SUIDs!  Rather, for any large organization, to deal
> with the existance of multiple people with the same name, it often will be
> REQUIRED, since DNs must be unique (and a lack of uniquencess will be
> painfully evident for certs issued within one organization, perhaps under
> one CA.  So, the choice is not whether to put this sort of UID info into
> the DN vs. whether to use the optional SUID field. Good practice in DN
> schema design will call for inclusion of this sort of info into the DN in
> many circumstances, irrespective of ACL conc erns.
>
> Steve
>
>
>-- End of excerpt from Stephen Kent

Date: Mon, 2 Jun 1997 12:48:49 -0700
From: <[email-masked]> (Shyh-Wei Luan)
To: [email-masked]
Subject: Re: X.509 certificate and its subject name field
Cc: [email-masked], [email-masked]

David,

[email-masked] (David P. Kemp) wrote:
>
> In any case, here are the comments Steve was referring to.  I'd draw
> particular attention to your item (4) - if you are going to include
> DNs in ACLs, even for annotation purposes, there is no advantage to
> using SUIDs.  It is worse to include erronious "comments" in an ACL
> (if the DN changes but the SUID/ACL is not updated) than to include
> no annotation at all.

>
> > (4) When authorization is based solely on the Subject UID, the whole name (DN)
> >     can still be included on ACL entries for the ease of browsing and
> >     management.

It is NOT unusual to include some outdated non-crtical information pertaining to
subject identities in today's businesses.   If I am a business owner,
I would rather to be able to keep the old information (such as old addresses,
names before marriages, etc.) until I can get updates, as long as I still have the
correct Subject UID information.  The updates of the annotations in ACLs can be
automated upon accesses based on the names cited in new certificates when used.

There are at least two other potential means for application to update name or
other (non-Subject-UID) attribute information in the ACLs.

(1) Applications may refresh the attribute information through a protocol with
CA's or directories for pulling up-to-date certificates to update annotations to
Subject UID's.

(2) Applications may provide an interface for on-line, user initiated updates
of attributes (except the Subject UID).  Note that these updates can be
automatically verified with the use of the new certificates.  No additional
name-update protocol between CA's and applications is needed.

If an application cannot tolerate outdated ACL annotations at all, it still can
use DN's in ACL entries.  However, other applications that can tolerate outdated
name/attributes or can handle *access-time* updates should be allowed to do so.
Providing a Subject UID (that itself guarantees temporal uniqueness of
identities) in the certificates provides this freedom to applications.

I believe San Jose Mercury, Time, PC Magazine, Consumer Report, all my other
subscriptions, and even my banks *can* tolerate my old name if I decide to get an
official English name.  Can you? :-)

Shyh-Wei

Date: Mon, 02 Jun 1997 14:48:37 -0400
From: Lorraine Camp <[email-masked]>
Reply-To: [email-masked]
Organization: NationsBanc
To: [email-masked]
Subject: unsubscribe

Date: Mon, 02 Jun 1997 18:33:42 +0100
From: Peter Williams <[email-masked]>
To: "David P. Kemp" <[email-masked]>
CC: [email-masked]
Subject: Re: X.509 certificate and its subject name field

:-)

Some X.509 conformant public-key certificates are even known to contain
two public keys/numbers...

David P. Kemp wrote:

> > From: [email-masked] (Peter Gutmann)
> >
> > The idea is that instead of saying "Fetch the cert for this
> incredibly
> > complicated and ambiguous DN" you can say "Fetch the cert for this
> short,
> > unambiguous blob".  Basically the hash acts as a key (in the
> database sense,
> > not the crypto sense) for the cert.
>
> This is entirely an implementation issue, unrelated to the certificate
>
> format.  Every public key certificate contains a public key :-),
> therefore
> every database or application that wants to use the hash of the public
>
> key as the keyID can do so.  No special keyID field is needed in the
> cert itself - it would just be redundant information.
>
> >
> > The drawbacks of this have been pointed out by several people: That
> if the same
> > person/entity switches to a new key and the only identification
> available is
> > the keyID, the change will (for example) invalidate ACL entries
> because they're
> > tied to a keyID and not a person/entity.
> >
> > However I don't think this is such a big problem.  Instead of saying
> "My name
> > is <DN>, grant me access", you say "My keyID is <blob>, grant me
> access", and
> > if any record of the entity associated with the keyID is required,
> the access
> > control software uses it to look up whatever it is that's required
> to record
> > who was granted access (name, employee number, job title, even a DN
> if you
> > insist).
>
> This discussion started with the desire for a *persistent* identifier,
>
> not a *short* identifier. The DN is completely general, and can
> contain
> whatever amount of persistence is desired by the certificate issuer -
> the more information you stuff into a DN, the less it's expected
> lifetime. But the DN is always expected be more persistent than the
> public key / keyID.
>
> The public key (or keyID) has the least persistence because it is (or
> should be) updated every time the certificate is refreshed.  If you
> assume that the public key is the entity's ID and that mapping
> keys/keyIDs to identity/privilege is a local matter, then there is no
> need for certificates at all!   The only service provided by the CA
> in the ACL/Persistent ID scenario is the ability to periodically
> update
> keys.  If you want to use keyID as the ACL identity, then instead you
> should just store the public key in the ACL and forget all about
> certificates.  I believe this was Peter Williams' point that using
> certs as input to ACLs is a pretty rudimentary form of privilege
> management.

Date: Mon, 2 Jun 1997 11:44:19 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: X.509 certificate and its subject name field

> From: [email-masked] (Peter Gutmann)
>  
> The idea is that instead of saying "Fetch the cert for this incredibly
> complicated and ambiguous DN" you can say "Fetch the cert for this short,
> unambiguous blob".  Basically the hash acts as a key (in the database sense,
> not the crypto sense) for the cert.

This is entirely an implementation issue, unrelated to the certificate
format.  Every public key certificate contains a public key :-), therefore
every database or application that wants to use the hash of the public
key as the keyID can do so.  No special keyID field is needed in the
cert itself - it would just be redundant information.

>  
> The drawbacks of this have been pointed out by several people: That if the same
> person/entity switches to a new key and the only identification available is
> the keyID, the change will (for example) invalidate ACL entries because they're
> tied to a keyID and not a person/entity.
>  
> However I don't think this is such a big problem.  Instead of saying "My name
> is <DN>, grant me access", you say "My keyID is <blob>, grant me access", and
> if any record of the entity associated with the keyID is required, the access
> control software uses it to look up whatever it is that's required to record
> who was granted access (name, employee number, job title, even a DN if you
> insist).

This discussion started with the desire for a *persistent* identifier,
not a *short* identifier. The DN is completely general, and can contain
whatever amount of persistence is desired by the certificate issuer -
the more information you stuff into a DN, the less it's expected
lifetime. But the DN is always expected be more persistent than the
public key / keyID.

The public key (or keyID) has the least persistence because it is (or
should be) updated every time the certificate is refreshed.  If you
assume that the public key is the entity's ID and that mapping
keys/keyIDs to identity/privilege is a local matter, then there is no
need for certificates at all!   The only service provided by the CA
in the ACL/Persistent ID scenario is the ability to periodically update
keys.  If you want to use keyID as the ACL identity, then instead you
should just store the public key in the ACL and forget all about
certificates.  I believe this was Peter Williams' point that using
certs as input to ACLs is a pretty rudimentary form of privilege
management.

Date: Mon, 2 Jun 1997 10:04:53 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: X.509 certificate and its subject name field

> From: Kepa Zubeldia <[email-masked]>
> 
> Steve,
> 
> I understand the problem about using the same key in multiple certs.
> However, I am becoming increasingly concerned about my ability to
> maintain a large cert wallet ten years from now.  
> 
> In the physical world, if my wallet is stolen, all my credit cards
> are compromised.  It would be easier for me to carry one smart card
> with all my accounts and let me decide which account to use for each
> transaction, instead of having a thick wallet with all the cards.
> The end result is the same.

Absolutely.  So what is the real-world requirement for you to maintain
a large cert wallet, and what is the motivation for using the same key
on more than one cert?

It would be easiest if you had a single keypair and a single cert that
you use for all accounts - writing checks at the bank, checking out a
video at Blockbuster, charging something at Macy's, etc.  If the strength
of the cert issuer is greater than the strength requirements of all the
prospective account issuers, this is possible, and certainly much easier
on the consumer than having each bank, store, library, etc issuing its
own certs.

But if you assume that you will have different certificates for different
purposes, what precisely is the advantage of sharing keys between any
of them?  You still need a fat wallet and the administrative burden of
choosing which cert to use.  It should be no more difficult to choose
between two certs with different keys than between two certs with the
same key.  What benefit is there to sharing keys?

> In the computer world, if one of my private keys is compromised, most
> likely all of the keys on that hard drive (or storage device) should
> be revoked, because they are also at risk.

That's a plausible example.  But why does that argue for sharing
keys between certs?  If you use different keys for different certs, you
have the option of revoking one, some, or all of them as circumstances
dictate.  If you have a single key for all purposes, you lose all
flexibility for handling them differently.  You can't store some
private keys more securely than others (on a token vs. a hard drive),
for example.

Date: Mon, 2 Jun 1997 09:51:59 -0400
To: Shyh-Wei Luan <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: X.509 certificate and its subject name field
Cc: [email-masked], [email-masked]

Shyh-Wei,

	I appreciate your arguments.  However, there is one note at the end
that suggests a misunderstanding re the use of an employee number or
similar attribute in the terminal RDN.  This is not an optional thing to do
as an alternative for SUIDs!  Rather, for any large organization, to deal
with the existance of multiple people with the same name, it often will be
REQUIRED, since DNs must be unique (and a lack of uniquencess will be
painfully evident for certs issued within one organization, perhaps under
one CA.  So, the choice is not whether to put this sort of UID info into
the DN vs. whether to use the optional SUID field. Good practice in DN
schema design will call for inclusion of this sort of info into the DN in
many circumstances, irrespective of ACL conc erns.

Steve

Date: Sun, 1 Jun 1997 00:00:06 -0700
From: Operator <[email-masked]>
To: [email-masked], [email-masked]
Subject: Monthly reminder (IETF-PKIX list)

Welcome to the ietf-pkix mailing list!

If you ever want to remove yourself from this mailing list, 
send the following command in email to "[email-masked]"
(NOT [email-masked]):

    unsubscribe <your e-mail-id> ietf-pkix

Here's the general information for the list you've subscribed to, in
case you don't already have it:

Welcome to the ietf-pkix list. This list is intended to discuss
matters directly related to  develop Internet standards needed to
support an X.509-based public key infrastructure (PKI). The resulting
PKI is intended to provide a framework which will support a range of
trust/hierarchy environments and a range of usage environments.

If you have any questions about this interest group, you can contact 

                Warwick Ford at [email-masked]  
                             or 
                Jean Pawluk at [email-masked].

If you have any questions about this list service in general, you
can contact [email-masked].